Docker Compose em produção: volumes, redes e segredos sem surpresas

Publicado em 2026-10-26 por frfrand

Exemplo de Compose com API e banco, persistência e logs

Docker Compose em produção: volumes, redes e segredos sem surpresas

Uma API, PostgreSQL e Redis podem rodar juntos com Docker Compose. É conveniente para desenvolvimento e para alguns ambientes de produção, mas se você não projetar os volumes e segredos, vai descobrir o problema quando o primeiro contêiner for recriado.

Vamos transformar isso em um procedimento que você pode usar em um VPS real. O objetivo é entender por que funciona, como testar e qual problema aparece se uma parte estiver mal configurada.

O que significa Docker Compose em produção e quando você precisa dele

O Compose descreve serviços, redes e volumes em um arquivo YAML. Um contêiner é substituível; as informações importantes devem viver em armazenamento persistente ou em um serviço externo gerenciado. As variáveis não são automaticamente segredos seguros por estarem dentro de um arquivo YAML.

Antes de mudar qualquer coisa em produção, anote o estado atual: IP, domínio, porta, serviço afetado e hora do último deploy. Uma modificação isolada é fácil de verificar; cinco mudanças simultâneas tornam mais difícil reconstruir o que aconteceu.

Configuração ou comandos de exemplo

services:
  api:
    image: mi-api:1.4.0
    ports:
      - '127.0.0.1:8000:8000'
    depends_on:
      - db
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      # Inyectar PASSWORD de forma segura; no subir a Git
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:

Os domínios, IPs, caminhos e nomes são ilustrativos. Não copie uma configuração inteira sobre a atual sem comparar primeiro. Nos exemplos que incluem portas ou firewall, certifique-se de manter o acesso administrativo.

Como eu faria passo a passo

Preparação. Defina imagens com tags versionadas e verifique a compatibilidade da versão do PostgreSQL.
Passo 2. Crie volumes para bancos de dados e uploads de usuários; não armazene dados apenas em camadas efêmeras.
Passo 3. Restrinja portas: no exemplo, a API é publicada apenas no localhost para um proxy.
Passo 4. Configure credenciais com o mecanismo apropriado e evite segredos literais no Compose.
Verificação. Execute docker compose config, inicie os serviços, verifique os healthchecks e teste a restauração.

Quando terminar, verifique a operação real a partir de outra conexão. Por exemplo, para uma API não basta abrir o navegador: execute uma requisição de leitura, uma gravação em um banco de teste e consulte os logs do processo.

Exemplo de um projeto de verdade

Um projeto de aluguéis usa FastAPI, worker Celery, Redis e PostgreSQL. Se os quatro viverem em contêineres, você pode atualizar a API sem alterar o banco de dados; mas uma migração de esquema requer coordenação e backup igualmente.

A lição é simples: uma configuração de infraestrutura não vive isolada da aplicação. O frontend, o servidor, o banco de dados e os workers se conectam, então medir onde começa a falha é mais útil do que reiniciar tudo.

O erro que evitaria

depends_on não garante por si só que o PostgreSQL esteja pronto para aceitar conexões: são necessários healthchecks ou retentativas da aplicação. Também não use o exemplo sem definir uma senha segura nem adaptar as versões.

Quando trabalha com servidores de clientes, guarde um backup ou procedimento de reversão antes de mudanças que afetem dados, rede ou certificados. E se não souber quais permissões uma operação precisa, evite executar como root apenas para parar de mostrar erros.

Como se relaciona com o ArduMaker?

No ArduMaker você pode operar Docker sobre o VPS junto a domínios, serviços e bancos. Evite misturar volumes de clientes diferentes e documente qual Compose corresponde a cada projeto.

Em um caso típico você pode criar um VPS para a aplicação, implantar do Git, associar domínio HTTPS e administrar o backend e os bancos necessários. As ferramentas ajudam a centralizar operações, mas é preciso entender qual porta e processo cumpre cada função.

Perguntas que aparecem quando você testa

Como saber se a falha é de DNS ou do serviço? Consulte primeiro a resolução, depois a conexão à porta e finalmente a resposta da aplicação. Essa ordem evita confundir problemas diferentes.

Posso expor um banco para facilitar a manutenção? Melhor projetar acesso privado ou túneis autenticados quando possível. Expor uma porta não substitui as permissões do mecanismo nem o firewall.

O que devo documentar? A configuração esperada, como verificar e como voltar ao estado anterior. Esse documento ajuda mais do que uma lista de comandos sem contexto.

Referências

Em resumo: uma boa configuração de rede ou servidor é aquela que você consegue explicar, verificar e recuperar quando algo falha.