Docker Compose em produção: até onde vai e quando começa a doer

Existe um consenso de internet de que Docker Compose é "só para desenvolvimento" e que produção séria exige Kubernetes. É um conselho que já causou mais estrago do que ajudou. Uma quantidade enorme de aplicações roda em produção com Compose, com uptime excelente e custo operacional baixíssimo — e uma quantidade parecida de times adotou Kubernetes cedo demais e passou a gastar a maior parte da energia mantendo a plataforma em vez de entregando produto.

A pergunta certa não é "Compose serve para produção?". É "até onde ele serve, e quais são os sinais de que passou da hora de sair?".

O que o Compose realmente entrega

Um arquivo declarativo descrevendo serviços, redes, volumes e variáveis. Um comando sobe tudo, outro derruba. O arquivo mora no repositório, versionado.

Isso já cobre, com competência:

• Reprodutibilidade. O ambiente é o mesmo em qualquer host com Docker.
• Reinício automático de container que morre, com política declarada.
• Rede interna entre os serviços, com descoberta por nome.
• Volumes nomeados para o estado que precisa sobreviver.
• Verificação de saúde por serviço, com dependência de inicialização.
• Limites de CPU e memória por container.

Para uma aplicação com quatro ou cinco serviços em um servidor, isso é praticamente tudo que se precisa. Adicionar um orquestrador distribuído nesse cenário não traz resiliência — traz uma segunda coisa para dar errado.

O que falta, e que você vai precisar resolver por fora

Compose não é orquestrador. Ele não distribui carga entre máquinas, não reprograma container quando o host morre e não faz deploy sem interrupção sozinho. Quatro lacunas, com soluções conhecidas:

1. Deploy interrompe o serviço

Recriar um container derruba o antigo antes de o novo estar pronto. Numa API interna, alguns segundos passam despercebidos. Numa API pública com tráfego constante, não passam.

A solução prática é um proxy reverso na frente — Traefik, Caddy ou Nginx — e subir a nova versão ao lado da antiga, trocar o destino e só então remover a anterior. Dá para automatizar isso em script de deploy com pouco esforço. Não é elegante como um rolling update nativo, mas resolve.

2. Se o host morrer, tudo morre junto

Essa é a lacuna estrutural e não tem contorno dentro do Compose. Um servidor, um ponto de falha.

O que importa aqui é ser honesto sobre o requisito. Se o negócio tolera trinta minutos de indisponibilidade em um evento raro, e você tem backup testado e um procedimento de restauração cronometrado, um host é aceitável. Se não tolera, você precisa de mais de um host — e aí a conversa muda de ferramenta.

Vale lembrar que "mais de um host" também pode significar rodar o Compose sobre VMs em um cluster de virtualização com alta disponibilidade: se o nó físico cai, a VM sobe em outro nó automaticamente. É uma resposta legítima e muito mais simples que orquestrador de container, e é o desenho que recomendamos com frequência para carga de porte médio.

3. Segredo em arquivo

.env ao lado do docker-compose.yml é o padrão de fato e é um problema — ele vaza para o repositório, para o backup e para o histórico de comandos com facilidade.

O mínimo aceitável: .env fora do repositório, com permissão restrita, e o arquivo no .gitignore desde o primeiro commit. O desejável: buscar os segredos de um cofre no momento do deploy, para que eles não fiquem em repouso no disco do servidor.

4. Observabilidade não vem junto

docker logs e docker stats resolvem diagnóstico pontual e não resolvem operação. Sem log centralizado, você perde a informação quando o container é recriado. Sem métrica com histórico, você não sabe se a lentidão de hoje é nova.

Um coletor de log e um par de coletores de métrica no mesmo Compose resolvem, e o esforço é de um dia.

Onde o Compose é a escolha certa

Seja direto consigo mesmo. Compose é adequado quando:

• A aplicação cabe em um servidor e vai continuar cabendo pelos próximos doze meses.
• Interrupção curta e planejada no deploy é aceitável, ou você montou o proxy na frente.
• O time é pequeno e não tem ninguém dedicado a plataforma.
• O número de serviços é da ordem de unidades, não de dezenas.
• Você tem backup testado e sabe quanto tempo leva restaurar.

Nesse cenário, Kubernetes não te dá nada que você não tenha — e te dá um cluster para manter, atualizar e diagnosticar.

Os sinais de que chegou a hora de sair

Não é uma questão de tamanho absoluto, e sim de sintomas. Quando dois ou três destes aparecem juntos, a mudança compensa:

1. Um servidor não aguenta mais, e você já subiu um segundo com Compose separado, copiando configuração na mão entre eles.
2. Indisponibilidade no deploy virou reclamação recorrente, e o contorno com proxy está ficando complicado.
3. A carga varia muito e você quer escalar por demanda em vez de dimensionar para o pico.
4. Times diferentes precisam de isolamento, quota e permissão separada no mesmo ambiente.
5. O número de serviços passou de uma dezena e a coordenação entre eles virou problema.
6. A queda de um host deixou de ser tolerável pelo negócio, com número escrito de RTO.

Se nenhum desses aparece, o desejo de migrar provavelmente é de currículo, não de operação. Vale dizer isso em voz alta na reunião.

As opções quando é hora de sair

Não é Compose ou Kubernetes. Existe um meio:

A primeira linha é a mais subestimada e a que resolve o caso mais comum: a preocupação era a queda do servidor físico, não a escala da aplicação.

Se for ficar no Compose, faça direito

O checklist que separa Compose de produção de Compose de tutorial:

1. Arquivo versionado no repositório, com sobreposição separada para produção.
2. Imagens com tag fixa de versão, nunca latest — latest torna o deploy irreprodutível e o rollback impossível.
3. Política de reinício declarada em todos os serviços.
4. Verificação de saúde em todos os serviços que têm como respondê-la.
5. Limites de CPU e memória definidos, para um serviço não derrubar o host.
6. Volumes nomeados para todo estado, e backup desses volumes testado com restauração cronometrada.
7. Segredos fora do repositório, com permissão restrita no disco.
8. Proxy reverso na frente, com TLS e renovação automática de certificado.
9. Log centralizado e métricas com histórico.
10. Deploy por script versionado, não por comando digitado no SSH.
11. Host com atualização de segurança automática e acesso restrito.
12. Procedimento de restauração escrito e testado — o servidor inteiro, do zero.

O item 12 é o que decide se um host é aceitável. Se você consegue reconstruir o ambiente em vinte minutos a partir do repositório e do backup, um servidor é um risco administrado. Se ninguém nunca tentou, é uma aposta.

Erros comuns

• Migrar para Kubernetes sem um sintoma real que justifique.
• Ficar no Compose sem backup testado do volume de dados.
• Usar latest nas imagens e perder a capacidade de reverter.
• Deixar .env versionado no repositório.
• Não definir limite de memória e ver um serviço derrubar o host inteiro.
• Não ter proxy na frente e interromper o serviço a cada deploy.
• Fazer deploy por comando digitado no servidor, sem script versionado.
• Copiar configuração na mão entre dois hosts com Compose separado.
• Confundir "roda em container" com "é resiliente".
• Nunca ter testado a reconstrução completa do servidor.

A conclusão

Docker Compose em produção é uma decisão defensável e frequentemente a mais inteligente. O que não é defensável é rodar Compose sem backup testado, sem limites, sem observabilidade e sem saber quanto tempo leva para voltar. Esses itens não são de Kubernetes — são de produção, e valem em qualquer ferramenta.

Onde a Solvefy/Cloud entra

Ajudamos os dois lados dessa decisão. Para quem fica no Compose, arrumamos a casa: proxy com TLS, deploy sem interrupção, segredos fora do disco, log e métricas, backup de volume testado e procedimento de reconstrução cronometrado — frequentemente com a aplicação rodando sobre VM em cluster Proxmox com alta disponibilidade, que resolve a queda do host físico sem adicionar orquestrador. Para quem precisa sair, conduzimos a migração para Swarm, Nomad ou Kubernetes com base no sintoma real, não na moda.

Não sabe se o seu ambiente aguenta produção? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.