Erros comuns em Docker que você deve evitar
Se você usa Docker no dia a dia, sabe: a ferramenta ajuda muito, mas alguns deslizes deixam seu ambiente frágil, lento ou difícil de manter. Aqui vão os erros mais frequentes (e como corrigir) para você ganhar previsibilidade.
1 Montar imagens “grandes” e lentas (sem estratégia)
Um erro clássico é construir a imagem sem se preocupar com cache, camadas e dependências. O resultado costuma ser: builds lentos, consumo alto de disco e deploys que demoram para repetir.
- Ignorar o cache do Docker — alterou um arquivo “errado” e tudo foi recompilado. Use uma ordem de instruções que privilegie camadas estáveis.
-
Copiar tudo para dentro do container cedo demais —
COPY . .no início destrói a eficiência. Copie primeiro arquivos de dependência (ex.: lockfiles) e só depois o restante. - Base images gigantes — escolher imagens enormes quando bastaria algo menor. Considere bases mais enxutas e revise dependências.
- Não usar multi-stage — você carrega ferramentas de build dentro da imagem final. Compile em uma etapa e gere o runtime só com o necessário.
2 Não tratar configurações e segredos corretamente
Configuração é a parte mais sensível para manter ambientes consistentes. Quando você “quebra” essa regra, o problema aparece como falha intermitente e comportamento inesperado.
- Hardcode de variáveis no Dockerfile Isso vaza credenciais/valores e dificulta mudar por ambiente.
-
Usar
ENVpara segredos Env em imagem pode ficar registrado em camadas e logs. Prefira o fluxo adequado para segredos. - Promover “config padrão” para produção Padronize entradas via variáveis e valide defaults com cuidado.
- Não versionar o que importa Ex.: não manter os arquivos de configuração e templates do app atualizados junto do código.
3 Montar volumes do jeito errado (e perder dados)
Volumes e bind mounts são poderosos — e também perigosos quando mal aplicados. O erro mais comum é achar que “vai persistir sempre” sem entender onde o dado realmente fica.
- Bind mount em caminhos sensíveis sem considerar permissões UID/GID diferentes causam falhas de escrita ou logs que não giram.
- Usar volume para arquivos de build Você troca o comportamento do container e pode “mascarar” dependências.
- Esquecer persistência de dados do app Banco, filas, uploads e caches precisam de estratégia clara.
- Reutilizar dados entre ambientes Dados sujos de staging/produção causam debug infinito.
4 Subir container sem observar limites, healthcheck e logs
Container que “só sobe” não significa que está saudável. O erro aqui é não ter sinais claros de funcionamento, levando a incidentes que demoram para ser diagnosticados.
- Sem healthcheck Orquestradores não conseguem distinguir “processo rodando” de “serviço respondendo”.
- Sem limites de recursos Sem CPU/RAM, um pico vira travamento e degradação para todo o host.
- Logs pouco estruturados Se você não consegue rastrear por request e timestamp, a manutenção vira adivinhação.
- Portas expostas sem necessidade Menos superfície, menos risco. Exponha apenas o que precisa.
✓ Exemplo de Docker Compose com healthcheck e persistência
Use como referência para evitar “container zombie” e garantir que seus dados realmente persistam. Ajuste os comandos e caminhos conforme seu projeto.
# docker-compose.yml
services:
api:
image: my-org/my-api:1.0.0
ports:
- "8080:8080"
environment:
# Evite hardcode; mantenha valores por ambiente
APP_ENV: "production"
volumes:
# Persistência do app (exemplo: uploads)
- api-uploads:/app/uploads
healthcheck:
test: ["CMD-SHELL", "curl -fsS http://localhost:8080/health || exit 1"]
interval: 10s
timeout: 3s
retries: 5
start_period: 20s
restart: unless-stopped
volumes:
api-uploads: {}Quer continuar melhorando seus containers?
Leia outros posts no yurideveloper.com e refine sua stack: boas práticas de Dockerfile, estratégia de imagens, observabilidade e deploys mais previsíveis.