Tus scripts ya funcionan. Pero «funcionar» es lo que hacen a mediodía, con tu terminal abierta, tus variables cargadas y tú mirando la salida. Producción es otra cosa: son las 4:20 de la madrugada, no hay nadie delante, el PATH es el pobre de cron, el disco está más lleno que ayer, la red va rara y la única prueba de lo que ocurrió será lo que tu script haya dejado escrito. Esta lección cierra el módulo con la checklist que salva esa distancia y con el proyecto que la demuestra: desplegar.sh, el script de despliegue de Tramontana Reservas, con validación, copia previa, cambio atómico y rollback automático si la aplicación no responde. Es el examen final del módulo, y usa absolutamente todo lo aprendido.

1. La checklist de producción
2. Estructura canónica y main "$@"
3. Configuración: la precedencia, implementada
4. Secretos
5. Registro: qué, cómo y adónde
6. Salida para humanos y para máquinas
7. Bloqueo, tiempos límite y solapamiento
8. Notificaciones: silencio si todo va bien
9. Pruebas, versionado y documentación
10. Cuándo dejar Bash
11. Proyecto: desplegar.sh

Ninguno es opcional en un script que corre solo: los diez juntos son la diferencia entre una automatización y una bomba de relojería.

La plantilla completa, evolución de la de 04-01. Cópiala tal cual:

main al final permite que el fichero se lea de arriba abajo como un texto: primero las constantes, luego las piezas, y al final el resumen de lo que hace el programa. Como Bash necesita que las funciones estén definidas antes de llamarlas, main "$@" tiene que ser la última línea, y ponerla ahí protege además de un fallo real: si el fichero se trunca al copiarlo, Bash no ejecutará un script a medias, porque la llamada a main habrá desaparecido con el resto. Y va con comillas, siempre, por lo que sabes de 04-03: es la única forma de que los argumentos lleguen intactos.

La regla de 04-03 —argumentos > entorno > fichero > defectos— se implementa aplicándola en ese orden, de la más débil a la más fuerte:

${VAR:-$ACTUAL} toma el valor del entorno si existe y, si no, conserva el que ya hubiera: ese pequeño truco es todo el mecanismo. Y registra las claves desconocidas en vez de ignorarlas, porque un umbral_dsico mal escrito que no dice nada es una noche perdida.

Tres reglas, en orden de importancia:

• Nunca en el script. Un fichero versionado en git con una contraseña dentro está comprometido para siempre, aunque la borres: queda en el historial.
• Nunca en la línea de comandos. mysql -p"$CLAVE" es visible en ps aux para cualquier usuario de la máquina mientras dure el comando. Sí en un fichero con permisos 600, propiedad del usuario del servicio, o en una variable de entorno del gestor de servicios.

Un mínimo digno: nada de contraseñas en el código y verificación activa de los permisos. La gestión seria —pass, un gestor de secretos, certificados TLS— es materia de 06-05.

Un script de producción registra cinco cosas: que ha empezado (con su versión y sus parámetros), cada decisión que toma, cada cambio que hace en el sistema, que ha terminado, y cuánto ha tardado. Con eso se reconstruye cualquier incidente.

Tres detalles del formato. La fecha ISO 8601 con zona horaria (%Y-%m-%dT%H:%M:%S%z) se ordena alfabéticamente igual que cronológicamente y no es ambigua en el cambio de hora. El PID entre corchetes permite separar dos ejecuciones entrelazadas. Y el mensaje va a la vez al fichero y a stderr, para que sirva igual en cron que a mano.

La duración se mide con SECONDS, la variable que Bash incrementa sola: SECONDS=0 al empezar y $SECONDS al terminar. Y una nota de frontera: en el Módulo 5 sustituiremos este fichero por el journal, con logger -t tramontana -p daemon.info como puente y journalctl para consultarlo (05-06), más logrotate para que el fichero no crezca sin fin.

Un script útil sirve a dos públicos: Marta quiere leer, la monitorización quiere parsear. La solución no es elegir, es ofrecer ambas:

Con --quiet se suprime todo lo informativo y solo quedan los errores —imprescindible para cron, que envía por correo cualquier salida— y con --json la salida es una sola línea parseable. Si tu JSON empieza a tener estructuras anidadas, esa es la señal del apartado 10: en Bash no hay forma decente de escapar comillas dentro de valores arbitrarios.

Ya tienes el flock sobre el descriptor 9 de 04-06. Falta la otra mitad: qué pasa si una ejecución tarda más que el intervalo entre ejecuciones. La copia nocturna se lanza a las 04:20; si un día tarda 25 horas, la de mañana encontrará el bloqueo. Tres respuestas, en orden de preferencia:

• Abandonar con un código propio (75) y un aviso. Es lo correcto para copias e informes: la de mañana ya lo hará.
• Esperar con flock -w 300 9, si el solapamiento es breve y esperar es aceptable. Y nunca matar la anterior desde la nueva: si hace falta eso, el problema es el intervalo, no el bloqueo.

A la ejecución hay que ponerle techo, porque un proceso colgado no falla: se queda ahí, ocupando el bloqueo para siempre.

timeout devuelve 124 cuando corta por tiempo, lo que permite distinguirlo de un fallo normal. Es la aplicación directa de la regla SIGTERM → esperar → SIGKILL de 03-06.

El principio es corto y se incumple siempre: un script que avisa cuando todo va bien enseña a la gente a ignorar sus avisos. Si Marta recibe cada mañana un correo de «copia correcta», a la tercera semana lo archiva sin leer, y el día que ponga «copia FALLIDA» tampoco lo leerá. La regla operativa: notifica solo cuando haya algo que hacer, y que el mensaje diga qué ha pasado, qué impacto tiene y qué se espera de quien lo lee.

Para que el silencio no se confunda con «el script no se ejecutó», la contrapartida es una marca de éxito: la última línea del log con la fecha de hoy, o un fichero ULTIMO_EXITO con la marca de tiempo. Comprobar «¿la marca es de hoy?» es trivial y detecta el 90 % de los problemas, incluido el peor: que la tarea haya dejado de ejecutarse.

Antes de que un script toque producción:

1. shellcheck sin avisos y bash -n, ambos obligatorios en CI: find scripts -name '*.sh' -exec shellcheck {} +.
2. --dry-run completo contra el sistema real, leyendo la salida entera: es la última oportunidad de ver lo que va a pasar. Y en un entorno de pruebas con los mismos datos y rutas, con snapshot de la VM antes de cada prueba destructiva.
3. El camino de fallo, no solo el de éxito: quita permisos al destino, apunta la URL de salud a un puerto cerrado, interrumpe con Ctrl+C a mitad. Si solo lo has probado cuando todo va bien, no lo has probado.
4. Con el entorno de cron, que es distinto del tuyo: env -i /home/operador/scripts/desplegar.sh -n 3.3.0 /tmp/app.tgz reproduce la pobreza de variables que tendrá a las 4:20.

El versionado no es opcional: ~/scripts es un repositorio git, con un commit por cambio y un mensaje que diga por qué. Desplegar el script es entonces git pull en el servidor —o mejor, copiarlo con rsync desde un repositorio central, sin dejar credenciales de git en el servidor—. Y la documentación mínima son tres cosas: la cabecera con uso y códigos de salida, un --help que funcione siempre, y un README.md en la carpeta que diga qué script hace qué y cuál llama a cuál. Nada más; nada menos.

Bash es excelente para orquestar comandos. Deja de serlo cuando aparece cualquiera de estas señales:

La señal más honesta: si estás escribiendo eval, o escapando comillas dentro de comillas dentro de comillas, ya has pasado el límite. Para Tramontana la frontera natural es Ansible: en el momento en que el despliegue tenga que hacerse en tres servidores a la vez, desplegar.sh se convierte en un rol de Ansible, y este módulo habrá cumplido su función, que era enseñarte exactamente qué hace ese rol por debajo.

El examen final del módulo. Valida, comprueba precondiciones, copia antes de tocar, extrae, verifica, cambia el enlace de forma atómica, comprueba con curl y revierte solo si la aplicación no responde.

El servicio siguió funcionando. Eso es lo que este módulo ha construido: la 3.3.0 no arrancó, el script lo detectó, revirtió al enlace anterior en el mismo segundo, lo registró todo y devolvió un código (69) que dice exactamente qué pasó. Y con -n habrías visto antes lo que iba a intentar, sin tocar nada.

Repasa dónde vive cada lección: el shebang y el exit explícito son de 04-01; ${VAR:-}, los arrays y printf de 04-02; getopts, uso(), stdout frente a stderr y los códigos de salida de 04-03; [[ =~ ]], case y el while de espera de 04-04; SCRIPT_DIR, la librería y morir() de 04-05; y set -euo pipefail, los trap, el bloqueo, la idempotencia y timeout de 04-06. Nada aquí es nuevo: es todo lo anterior, junto.

• Rutas relativas. Funcionan desde tu terminal y fallan desde cron: absolutas siempre, o derivadas de SCRIPT_DIR. Y no supongas el PATH, que en cron es /usr/bin:/bin; si usas algo de /usr/local/bin, ruta completa o PATH= explícito al principio.
• Poner main "$@" sin comillas o en medio del fichero. Lo primero rompe los argumentos con espacios; lo segundo falla porque las funciones aún no están definidas. Y no notifiques el éxito: enseña a ignorar las notificaciones. Silencio si todo va bien, y una marca de éxito comprobable.
• Registrar solo el final. Sin las decisiones intermedias no puedes reconstruir nada; registra también lo que decidiste no hacer. Y pon siempre tiempo límite: un proceso colgado no falla, se queda ahí con el bloqueo cogido hasta que alguien lo mata.
• Desplegar sin --dry-run previo. Treinta segundos de lectura contra media hora de restauración.
• Consejo: guarda ~/scripts en git desde hoy aunque solo seas tú, porque git log responde a «¿desde cuándo hace esto?» mejor que tu memoria. Y haz que todo script imprima su versión en la primera línea del log: cuando dos servidores se comporten distinto, será lo primero que compares.
• Consejo: el mejor momento para escribir el README de la carpeta es hoy, cuando aún recuerdas por qué existe cada script.

Ejercicio 1. Añade a desplegar.sh una opción --json que, al terminar, imprima por stdout una línea con version, previo, estado (desplegado o revertido), codigo y duracion. Debe funcionar también cuando hay rollback, sin duplicar código.

Ejercicio 2. Escribe ~/scripts/comprobar_tareas.sh, que verifique que las tres tareas nocturnas (cron-copia.log, cron-purga.log y el despliegue) han dejado marca de hoy y notifique solo si falta alguna, aplicando el principio de silencio si todo va bien.

Ejercicio 3. Luis quiere meter esta línea en /etc/cron.d/tramontana: 20 4 * * * operador cd ~/scripts && ./desplegar.sh $VERSION /tmp/app.tar.gz. Encuentra los cinco problemas y reescríbela.

Solución 1. La clave es no duplicar: el punto único de salida ya existe —el trap limpiar EXIT— y es ahí donde debe imprimirse el resumen.

El 2>/dev/null deja solo la línea JSON, porque el registro va a stderr: la separación de canales de 04-03 dando su fruto. Y como el exit 0 del camino de éxito también dispara el EXIT, se elimina el printf '%s\n' "$version" del cuerpo de main para no imprimirlo dos veces.

Solución 2.

Sin -v y con todo correcto el script no imprime nada y devuelve 0: cron no manda correo y Marta no recibe ruido. El correo solo se envía en el camino de fallo, diciendo qué pasa y qué revisar, como pide la convención del curso.

Solución 3. Los cinco problemas:

1. ~ no se expande en un crontab de sistema. El campo se pasa a sh -c con un entorno mínimo y HOME puede no estar definido: rutas absolutas.
2. $VERSION está vacía. Cron no hereda tu entorno, así que el script recibiría un argumento donde esperaba dos y la validación lo rechazaría. Menos mal.
3. Falta redirigir la salida. Sin >> log 2>&1, cualquier mensaje se convierte en un correo y cualquier error se pierde si el correo no está configurado.
4. Sin SHELL ni PATH declarados al principio del fichero, y con la hora mal elegida: las 04:20 evitan la franja del cambio horario y el solape con otras tareas.
5. Desplegar automáticamente por cron es una mala idea de fondo. Un despliegue lo aprueba Marta; lo que debe correr solo es la copia.

Rutas absolutas, PATH explícito, MAILTO="" porque el script ya escribe su propio log y solo notifica cuando hace falta, y el despliegue fuera de cron: se lanza a mano cuando Marta lo aprueba. En el Módulo 5 veremos que un timer de systemd hace todo esto con mejor registro y mejor control de solapamiento.

Has cerrado el módulo, y con él la distancia entre «me funciona» y «corre solo».

• Tienes una checklist de producción de diez puntos y una plantilla canónica con main "$@" como última línea, que hace que el script se lea de arriba abajo y no se ejecute a medias si se trunca. Implementas la precedencia de configuración —argumentos > entorno > fichero > defectos— de verdad, registrando incluso las claves desconocidas.
• Mantienes los secretos fuera del código y de la línea de comandos, y verificas los permisos del fichero que los guarda.
• Registras inicio, decisiones, cambios, fin y duración, con fecha ISO y PID, a fichero y a stderr, sabiendo que en 05-06 eso pasará al journal.
• Produces salida para humanos y para máquinas, con --quiet y --json. Controlas el solapamiento con flock, pones techo con timeout sabiendo que 124 significa «se agotó el tiempo», y aplicas el silencio si todo va bien con una marca de éxito comprobable como contrapartida.
• Pruebas con shellcheck, bash -n, --dry-run, entorno de pruebas, env -i y el camino de fallo; versionas en git y documentas con cabecera, --help y README.
• Reconoces cuándo dejar Bash —300 líneas, JSON anidado, concurrencia, eval— y hacia dónde ir. Y desplegar.sh existe: valida, bloquea, copia antes de tocar, extrae con tiempo límite, cambia el enlace de forma atómica, comprueba la salud y revierte solo cuando la 3.3.0 no arranca, dejando el servicio en pie.

En /home/operador/scripts/ hay ahora una caja de herramientas real: revision_salud.sh, informe_reservas.sh, resumen_reservas.sh, purgar_releases.sh, respaldo_tramontana.sh, comprobar_tareas.sh, desplegar.sh, la librería lib/comunes.sh y su test_comunes.sh, todos con la misma estructura, los mismos códigos de salida y la misma disciplina de errores. Eso ya no es «saber Bash»: es saber automatizar.

Pero fíjate en lo que ha ido apareciendo entre líneas y hemos ido aplazando. respaldo_tramontana.sh escribe en /var/log/tramontana/ y nadie rota ese fichero. desplegar.sh cambia el enlace pero no reinicia la aplicación, porque aún no sabes gestionar servicios. La copia va a /srv/tramontana/backups sin que hayamos hablado de cuánto disco hay ni de qué pasa cuando se acabe. El grupo tramontana sigue sin crearse formalmente, svc-tramontana existe por arte de magia, y sudo lo has usado sin preguntarte quién decide qué puedes hacer con él. En el Módulo 5: Administración del Sistema todo eso deja de ser magia: crearás usuarios y grupos de verdad, configurarás sudo y los permisos especiales, instalarás y fijarás versiones de paquetes, gestionarás discos y sistemas de ficheros, convertirás tus scripts en servicios y timers de systemd con arranque, dependencias y reinicio automático, mandarás tus registros al journal con rotación, medirás el rendimiento del servidor, y cerrarás con una estrategia de respaldo y restauración digna de ese nombre. Los scripts que has escrito serán las piezas; el Módulo 5 es el sistema que las sostiene. Actualiza el snapshot de tu VM y nos vemos allí.