Trabalhar com contentores em 2024–2025 é transformar o ciclo “build → run → atualizar → reverter” em algo previsível, limpo e observável. O objetivo não é apenas empacotar a app: é encurtar builds, fixar dependências, reduzir superfície de ataque, separar dados de runtime e manter atualizações e rollbacks como ações de baixo risco. Este guia é prático e direto. Explica como produzir imagens pequenas e repetíveis, executar com segurança e limites claros, isolar rede e segredos, atualizar sem tempo de indisponibilidade e voltar atrás em segundos quando algo foge do esperado. A linha condutora é “limpeza e ordem”: menos camadas, menos privilégios, menos surpresas.
Imagens pequenas, reproduzíveis e fáceis de auditar
Comece por uma base minimalista adequada à sua stack, preferindo variantes “slim”, distroless ou runtime-only para reduzir tamanho e CVEs. Congele versões de sistema e de pacotes no build para evitar variações invisíveis entre ambientes. Use multi-stage build para compilar numa imagem rica e copiar apenas binários e artefactos finais para a imagem de produção. Garanta reprodutibilidade definindo timezone, locale e ordens de cópia estáveis, e evite “apt upgrade” genérico; instale só o necessário. Crie um utilizador não root no build e defina-o como padrão na imagem final. Adicione um healthcheck simples que prove que o processo principal responde, em vez de apenas verificar se a porta está aberta. Gere e publique um SBOM junto com a imagem e integre uma etapa de scan no pipeline para bloquear bibliotecas vulneráveis antes de irem ao registo. Etiquete imagens com esquema consistente de versão e commit, adotando tags imutáveis para releases e reservando “latest” apenas para desenvolvimento local.
Execução segura e com limites claros de recursos
Ao executar, privilegie mínimos privilégios. Evite root, monte o sistema de ficheiros como read-only e só escreva em volumes explícitos. Remova capabilities desnecessárias e desligue a partilha do PID e IPC com o host se não precisa. Defina limites de CPU e memória compatíveis com o perfil da app, e estabeleça reservas para impedir competição agressiva em hosts partilhados. Use políticas de reinício que diferenciem falhas transitórias de crash loops, e mantenha logs a sair para stdout e stderr para coleta centralizada; não escreva logs intermináveis dentro do contentor. Para jobs de curta duração, prefira contentores efémeros que arrancam, trabalham e terminam, mantendo o host limpo de processos órfãos. Se a aplicação spawna sub-processos, confirme que o PID 1 reencaminha sinais e reaprove zumbis corretamente, garantindo shutdowns rápidos e previsíveis em deploys e reverts.
Rede, dados persistentes e segredos fora da imagem
Separe o tráfego entre serviços em redes virtuais internas e exponha portas ao exterior apenas no ponto de entrada. Evite publicar em 0.0.0.0 quando não é necessário e use nomes de serviço para descoberta interna, reduzindo acoplamento a IPs. Os dados pertencem a volumes, não à imagem; defina um layout simples com diretórios de escrita claros e faça backups a partir dos volumes, não do sistema de ficheiros do contentor. Para migrações de base de dados, acople o ciclo ao deploy com uma etapa controlada que execute scripts idempotentes antes de expor a nova versão. Segredos nunca devem viver em variáveis de ambiente permanentes ou em ficheiros dentro da imagem. Use mecanismos nativos de secrets e injete-os apenas em runtime, com permissões mínimas e rotação periódica. Em ambientes híbridos, isole contentores que falam com redes locais e aplique firewalls por host para conter movimentos laterais.
Atualizações previsíveis e reversões em segundos
Trate cada release como um conjunto versionado de imagem, configuração e migrações. Promova a mesma imagem entre ambientes, alterando apenas variáveis e endpoints, para evitar “funciona na pré, falha na prod”. Em ambientes de uma só máquina, faça rolling com duas pilhas lógicas: suba a nova pilha em portas internas, passe healthchecks, troque o tráfego através do proxy e desligue a antiga depois do período de observação. Em clusters, use rollouts com limites de replicas simultâneas, janelas de readiness e probes de liveness afinadas; canary gradual reduz risco em alterações grandes. A reversão precisa de estar ensaiada: mantenha ao menos duas versões prontas a arrancar, registe o comando de rollback no runbook e garanta que voltar atrás não tenta refazer migrações destrutivas. Evite dependências escondidas em “latest” no registo; fixe digests ou tags de release, expira artefactos antigos com política de retenção e limpe imagens não utilizadas no host para manter discos e caches saudáveis.
Pipeline, registo e observabilidade que evitam surpresas
Automatize o ciclo build-push-scan-assinar-implantar. Cada commit que toca código ou Dockerfile deve produzir uma imagem, gerar SBOM, passar por scans e receber assinatura de proveniência. Publique em registo privado com papéis claros de leitura e escrita, políticas de retenção e replicação entre regiões quando necessário. No arranque, exponha métricas e sirva um endpoint de health interno que reflete dependências essenciais como base de dados e filas. Consolide logs com correlação de request ID entre serviços para facilitar diagnósticos. Monitore consumo de CPU, memória e IO por contentor, alertando por tendências e não só por picos. Documente em poucas linhas como subir localmente, como parametrizar credenciais, como executar migrações e como reverter. Esta documentação viva evita “herança tribal” e reduz o tempo de recuperação quando algo falha no pior momento.
Leave a Reply