Introdução
Containers são efêmeros por natureza. Eles nascem, morrem e podem ser recriados a qualquer momento.
E é exatamente aí que mora um dos erros mais perigosos:
tratar containers como se fossem servidores tradicionais.
Quando isso acontece, a perda de dados deixa de ser uma possibilidade — e passa a ser questão de tempo.
O erro clássico
Um cenário comum:
- Banco de dados rodando dentro de um container
- Dados gravados no filesystem interno do container
- Nenhum volume configurado
Tudo funciona bem… até:
- O container reinicia
- Uma nova versão é publicada
- O ambiente é recriado
Resultado:
Todos os dados desaparecem.
Por que isso acontece?
Containers utilizam um filesystem em camadas (overlay).
Isso significa que:
- O estado interno do container não é garantido
- Alterações podem ser perdidas ao recriar o container
- A imagem não é um local persistente
Em outras palavras:
Container não é lugar de armazenar dados.
O conceito correto
Separar claramente:
- Aplicação (container)
- Dados (armazenamento persistente)
Essa separação é obrigatória para qualquer ambiente minimamente confiável.
Tipos de persistência
1. Volumes (Docker)
- Gerenciados pelo Docker
- Melhor performance
- Ideal para ambientes simples
Exemplo:
docker run -v mysql_data:/var/lib/mysql mysql:8.0
2. Bind mounts
- Mapeiam diretórios do host
- Mais controle
- Dependem da estrutura do sistema operacional
Exemplo:
docker run -v /data/mysql:/var/lib/mysql mysql:8.0
3. Storage externo (cloud)
- Azure Files
- AWS EFS
- Google Filestore
Essencial para:
- Ambientes distribuídos
- Alta disponibilidade
- Containers gerenciados (ACA, ECS, etc.)
O caso real: aplicações corporativas
Aplicações como:
- GLPI
- WordPress
- Zabbix
- Vaultwarden
Dependem diretamente de persistência.
Sem isso:
- Uploads somem
- Configurações são perdidas
- Sessões quebram
- Banco pode corromper
O erro mais sutil
Mesmo usando volume, ainda é comum errar:
Montar diretórios errados
Exemplo clássico:
- Montar
/var/www/htmlinteiro no WordPress
Problema:
- Sobrescreve arquivos da aplicação
- Pode causar inconsistências após update
O correto:
- Montar apenas o necessário (ex:
wp-content)
Performance também importa
Nem todo storage é igual.
Problemas comuns:
- Latência alta (Azure Files, dependendo do uso)
- IOPS limitados
- Travamentos em aplicações com muitos arquivos pequenos
Boas práticas:
- Separar dados críticos
- Usar storage adequado para cada carga
- Evitar usar file share para tudo
Um padrão saudável
Uma arquitetura simples e eficiente:
- Container stateless
- Banco de dados externo (MySQL, PostgreSQL)
- Arquivos persistentes em volume ou storage
- Configuração desacoplada
Checklist rápido
Antes de subir qualquer container:
- Onde os dados serão armazenados?
- Esse dado sobrevive a um restart?
- Posso recriar o container sem perder nada?
- O storage atende performance necessária?
Se alguma resposta for “não”, há risco.
Conclusão
Containers trazem velocidade e flexibilidade — mas exigem disciplina.
Persistência mal planejada não falha imediatamente. Ela falha no pior momento possível.
E quando falha, geralmente já é tarde.
---
O próximo pode seguir bem nessa linha prática, por exemplo:
- **“Azure Container Apps na prática: quando ele substitui Kubernetes”**
ou
- **“CI/CD de verdade: por que pipeline quebra mais do que ajuda”**
Quer continuar indo mais para cloud (ACA) ou mais para DevOps/processo?