Redes e volumes no Docker: o que quebra ao subir para produção

Container é fácil até tocar em duas coisas: rede e disco. É onde a abstração vaza — o container acha que tem uma máquina só para ele, e a máquina real tem outra opinião sobre endereços, portas, permissões e onde os bytes moram.

Os problemas são sempre os mesmos, e conhecê-los de antemão economiza noites.

Redes: os modos que importam

O Docker oferece alguns modos de rede. Na prática, três aparecem:

A distinção entre as duas primeiras linhas é a que mais confunde iniciante e vale gravar: na bridge padrão, containers não se enxergam por nome. Em uma bridge que você cria, a resolução por nome de serviço funciona automaticamente.

Por isso a regra: crie sempre uma rede própria para o seu conjunto de serviços. O Compose já faz isso sozinho, o que explica por que muita gente nunca encontra o problema — até rodar containers soltos e descobrir que um não acha o outro.

O DNS interno e o nome que não resolve

Dentro de uma rede definida, o Docker resolve nomes de container e de serviço para os endereços internos. Isso é o que permite a aplicação conectar em banco:5432 sem saber endereço nenhum.

O que quebra esse mecanismo:

• Containers em redes diferentes. Não se enxergam. Um container pode estar em mais de uma rede quando precisa alcançar dois grupos.
• Uso do nome do container em vez do nome do serviço no Compose, quando há escala maior que um.
• Cache de DNS da aplicação. Se o container do banco é recriado, ele pode receber outro endereço. Aplicação que resolveu o nome uma vez e guardou para sempre continua tentando o endereço antigo. É a causa de "depois que reiniciei o banco, a aplicação não voltou".

Esse último ponto merece atenção em produção: a correção é do lado da aplicação — respeitar o tempo de vida do registro DNS, ou reconectar em caso de falha. Não é problema do Docker, e reiniciar a aplicação toda vez é contorno, não solução.

Publicar porta: o detalhe que expõe serviço sem querer

Publicar uma porta liga uma porta do host à porta do container. E há uma pegadinha séria: por padrão, a publicação escuta em todas as interfaces do host.

Isso significa que publicar a porta do banco de dados para conseguir acessá-lo de uma ferramenta local pode deixar aquele banco acessível a partir da internet, se o servidor tem endereço público — e, dependendo do sistema, as regras de firewall do host podem não bloquear isso como você espera, porque a publicação de porta manipula o encaminhamento em um nível anterior.

As regras que evitam o acidente:

1. Publique apenas o que precisa ser alcançado de fora. Serviço interno não publica porta nenhuma; ele é alcançado pela rede interna do Docker, pelo nome.
2. Quando publicar, restrinja a interface. Amarre a publicação ao endereço local quando o acesso é só do próprio host.
3. Não confie apenas no firewall do host para proteger porta publicada. Verifique de fora, com varredura, o que realmente está aberto.

Esse último item é um teste que vale fazer em todo servidor de produção com Docker: varra as portas a partir de outra máquina e compare com o que você acredita estar exposto. A diferença costuma surpreender.

Volumes: bind mount e volume nomeado

Duas formas de dar armazenamento persistente ao container, com propósitos diferentes:

Bind mount liga um diretório do host ao container. Você controla exatamente onde os arquivos estão.

• Bom para: configuração, certificados, código em desenvolvimento, dado que outras ferramentas do host precisam ler.
• Cuidado: depende do caminho existir no host; dono e permissão do diretório precisam bater com o usuário do container.

Volume nomeado é gerenciado pelo Docker, em área própria.

• Bom para: dado de aplicação — banco, uploads, estado.
• Vantagens: portável entre hosts com o mesmo Compose, gerenciável pelos comandos do Docker, com desempenho melhor em alguns sistemas operacionais.
• Cuidado: é fácil esquecer que ele existe. Volume órfão ocupa disco em silêncio.

A regra prática: configuração por bind mount, dado por volume nomeado.

A permissão que quebra tudo

O sintoma mais comum em produção: container não consegue escrever no volume.

A causa é quase sempre a mesma. A imagem, corretamente, roda com usuário não-root. O diretório no host pertence a outro usuário. O container tenta escrever e recebe erro de permissão.

As correções, em ordem de preferência:

1. Ajustar o dono do diretório no host para o identificador numérico do usuário do container. O identificador é o que importa — o nome do usuário dentro do container não existe no host.
2. Usar volume nomeado em vez de bind mount, deixando o Docker cuidar disso.
3. Container de inicialização que ajusta permissões antes do principal subir.

E o que não fazer: voltar a rodar como root, ou dar permissão total ao diretório. Resolve o sintoma e cria um problema maior.

Backup de volume: o que quase ninguém faz

Container é descartável; volume não. E a proteção do volume costuma ser esquecida justamente porque a cultura de container enfatiza o descartável.

O que precisa existir:

• Backup do conteúdo do volume, não do container. Container se recria do registry; volume, não.
• Backup de banco de dados feito pela ferramenta do banco, não copiando os arquivos do volume com o banco ligado — isso produz cópia inconsistente.
• Destino fora do host. Backup no mesmo servidor não protege contra a perda do servidor.
• Restauração testada, em host limpo, cronometrada.
• Limpeza de volumes órfãos, monitorando o espaço. Disco cheio por volume esquecido é um incidente comum e evitável.

Log: o volume invisível

O log de container, por padrão, é gravado em disco no host — e cresce sem limite até encher a partição.

É um dos incidentes mais banais e mais frequentes em servidor com Docker: disco cheio, tudo para, e a causa é um container verboso rodando há meses.

A correção é configurar rotação de log — tamanho máximo por arquivo e número de arquivos — no daemon, valendo para todos os containers. Configure uma vez, no servidor, e o problema desaparece para sempre.

Recursos: limite para o container não derrubar o host

Sem limite, um container pode consumir toda a memória do host e levar tudo junto — inclusive os outros containers e o próprio sistema.

Em produção, todo container precisa de limite de memória. Limite de CPU é opcional e depende do caso, como na discussão equivalente em orquestradores.

E vale dimensionar com o pico medido, não com estimativa.

O checklist de produção

1. Rede própria definida para o conjunto de serviços.
2. Apenas o que é externo publica porta.
3. Porta publicada restrita à interface correta.
4. Varredura externa confirmando o que está realmente exposto.
5. Configuração por bind mount, dado por volume nomeado.
6. Dono do volume compatível com o usuário do container, sem rodar como root.
7. Backup do conteúdo dos volumes, fora do host, restaurado em teste.
8. Banco com backup pela ferramenta do banco, não cópia de arquivo quente.
9. Rotação de log configurada no daemon.
10. Limite de memória em todos os containers.
11. Limpeza periódica de volumes e imagens órfãos.
12. Aplicação que reconecta quando a dependência muda de endereço.

Erros comuns

• Usar a bridge padrão e não entender por que o nome não resolve.
• Publicar porta de banco de dados e expor à internet sem perceber.
• Confiar no firewall do host sem verificar de fora o que está aberto.
• Bind mount com dono errado, e voltar a rodar como root para "resolver".
• Permissão total no diretório do volume.
• Copiar arquivos de banco em execução como backup.
• Backup de volume no mesmo host.
• Nunca restaurar um volume para testar.
• Log sem rotação, enchendo o disco do servidor.
• Container sem limite de memória derrubando o host.
• Volumes órfãos acumulando e consumindo disco em silêncio.
• Aplicação com cache de DNS eterno, que não volta após recriar a dependência.

Onde a Solvefy/Cloud entra

Arrumar rede e armazenamento de ambiente containerizado é um trabalho de escopo curto e efeito grande: revisamos exposição real de portas com varredura externa, reorganizamos as redes e a resolução de nomes, corrigimos permissão de volume sem voltar a root, implantamos backup de volume com restauração testada, configuramos rotação de log e limites de recurso. Vale tanto para Docker Compose em servidor único quanto para a base de um cluster maior.

Você sabe quais portas do seu servidor estão abertas agora? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.