Scripts Bash seguros: set -euo pipefail, trap e códigos de saída
Publicado em 2026-10-26 por frfrand
Evitar scripts de implantação que falham silenciosamente no Linux
Um script de deploy instala dependências, falha em um comando e segue em frente como se nada tivesse acontecido. O resultado pode ser um site meio atualizado. No Bash, convém tratar os erros como parte do projeto, não como uma surpresa.
Te mostro onde está o problema, como verificá-lo sem chutar e o que eu faria em uma aplicação que realmente tem usuários. Não é preciso decorar um manual inteiro para resolver uma falha específica.
O que significa scripts Bash seguros na prática
set -e pode fazer o shell sair diante de algumas falhas, -u detecta variáveis não definidas e pipefail propaga falhas dentro de pipelines. Nenhuma opção substitui revisar condições, if, subshells e comandos que admitem erros esperados.
Uma esclarecimento antes de tocar no servidor: se o projeto já está em produção, guarde o estado que encontrou e verifique em qual usuário e máquina você vai executar os comandos. Trabalhar como root sem necessidade e mudar várias coisas de uma vez dificulta encontrar a causa de um erro.
Comandos úteis para começar
#!/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ónOs caminhos, nomes de unidades e domínios são exemplos. Adapte-os ao seu serviço. Se um comando exigir permissões de administrador, revise o que muda e por quê. As consultas de diagnóstico devem vir antes das modificações.
Passo a passo, com verificações
- Defina o que significa sucesso para cada etapa de implantação.
- Adicione validações explícitas antes de operações em bancos de dados ou arquivos.
- Teste falhas simuladas: dependência que não é instalada, variáveis ausentes e porta ocupada.
- Registre o código de saída e não oculte o stderr.
- Antes de adicionar uma migração irreversível, projete backups e compatibilidade entre versões.
Após cada etapa, verifique um resultado observável: um estado, um arquivo, uma resposta HTTP ou uma entrada de log. Se encontrar uma mensagem inesperada, salve-a para investigar em vez de ocultá-la com reinicializações repetidas.
Exemplo real: um aplicativo que precisa ser mantido
Em um aplicativo de reservas, uma implantação instala pacotes, mas falha ao construir um módulo. Sem controles, o systemd reinicia um processo com arquivos incompatíveis. Um script que para e relata a falha evita publicar um estado misto.
Ao final, teste o caminho completo: acessar pelo domínio, chamar a API, gravar um dado de teste e verificar se a informação permanece após uma reinicialização controlada. Um servidor que "inicia" nem sempre é um aplicativo que funciona.
Erros que vale a pena evitar
Não use set -e e assuma que tratou todos os erros. Os contextos condicionais do Bash têm exceções; escreva testes que confirmem o comportamento real.
Também é importante que as credenciais não terminem no histórico do terminal, logs, arquivos compartidos ou capturas. Para usuários e serviços, use permissões mínimas e documente quem pode revogar o acesso.
Como o ArduMaker entra neste cenário
Use os deploys Git do ArduMaker com etapas de validação, logs e um comando de inicialização claro. Automatizar mal pode propagar a falha para vários VPS mais rapidamente.
O ArduMaker pode ajudá-lo a administrar os VPS, implantar repositórios e trabalhar com serviços, bancos de dados e domínios na mesma plataforma. Não substitui o que acabamos de explicar sobre o Linux: precisamente por isso convém entender o diagnóstico e ter uma forma de repeti-lo.
Quando convém automatizá-lo
Se a tarefa se repete, documente primeiro o procedimento manual e suas verificações. Depois considere um script ou uma tarefa agendada com erros visíveis, logs e permissões limitadas. Não automatize um comando que você ainda não sabe recuperar quando dá errado.
Perguntas frequentes
Posso testar sem afetar clientes? Em muitos casos, sim: um VPS de staging ou um serviço de teste separado permite validar a configuração antes de alterar a produção.
Como saber se ficou certo? Veja os logs e uma operação funcional, não apenas se o comando terminou com código zero.
Quando preciso de mais recursos? Quando as métricas indicarem saturação de CPU, RAM, disco ou conexões. Uma falha de configuração raramente se resolve contratando mais memória.
Referências
Em uma frase: primeiro entenda o erro, depois altere algo concreto e verifique seu efeito. Essa disciplina economiza muitas horas de suporte.