Bash scripts seguros: set -euo pipefail, trap y códigos de salida
Publicado el 2026-10-26 por frfrand
Evitar scripts de despliegue que fallen silenciosamente en Linux
Un script de deploy instala dependencias, falla en un comando y sigue adelante como si nada. El resultado puede ser una web a medio actualizar. En Bash conviene tratar los errores como parte del diseño, no como una sorpresa.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa Bash scripts seguros en la práctica
set -e puede hacer que el shell salga ante algunos fallos, -u detecta variables no definidas y pipefail propaga fallos dentro de pipelines. Ninguna opción sustituye revisar condiciones, if, subshells y comandos que admiten errores esperados.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
#!/usr/bin/env bash
set -Eeuo pipefail
trap 'echo "Error en línea $LINENO" >&2' ERR
cd /srv/miapp
python -m pip install -r requirements.txt
python manage.py check
# migraciones y reinicios sólo con plan de recuperaciónLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Definí qué significa éxito para cada paso de despliegue.
- Añadí validaciones explícitas antes de operaciones sobre bases o archivos.
- Probá fallos simulados: dependencia que no se instala, variables faltantes y puerto ocupado.
- Registrá el código de salida y no ocultes stderr.
- Antes de añadir una migración irreversible, diseñá backups y compatibilidad entre versiones.
Después de cada paso, verificá un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encontrás un mensaje inesperado, guardalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
En una aplicación de reservas, un deploy instala paquetes pero falla al construir un módulo. Sin controles, systemd reinicia un proceso con archivos incompatibles. Un script que se detiene y reporta el fallo evita publicar un estado mezclado.
Al final, probá el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
No hagas set -e y asumas que manejaste todos los errores. Los contextos condicionales de Bash tienen excepciones; escribí pruebas que confirmen el comportamiento real.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usá permisos mínimos y documentá quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
Usá los despliegues Git de ArduMaker con pasos de validación, logs y un comando de arranque claro. Automatizar mal puede propagar el fallo a varios VPS más rápido.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documentá primero el procedimiento manual y sus comprobaciones. Después considerá un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sabés recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mirá logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entendé el error, después cambiá una cosa concreta y comprobá su efecto. Esa disciplina te ahorra muchas horas de soporte.