Introdução
Passar um container para produção exige um nível de cuidado que a gente não tem no dev. Se você quer parar de apagar incêndio em deploy de sexta-feira, precisa entender que "funcionar" é o mínimo; o objetivo aqui é resiliência e segurança.
1. Imagens: O regime de atleta
Em produção, imagem gorda é alvo fácil. Quanto mais coisa instalada dentro do seu container, maior a sua superfície de ataque.
Multi-stage Build: É a técnica de usar um container para compilar o código e outro, muito menor, apenas para rodar o binário final.
Não seja root: Rodar processo como root no container é pedir para ser invadido. Sempre crie um usuário sem privilégios.
Dockerfile
# Exemplo de Multi-stage e Segurança
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .
# Imagem final mínima
FROM alpine:3.18
RUN adduser -D operario
USER operario
COPY --from=builder /app/main /main
CMD ["./main"]
2. Onde guardar o que é sensível?
Pelo amor de Deus, nunca coloque senhas ou chaves de API no seu Dockerfile ou no docker-compose.yml. Se você der um docker history, qualquer um vê o que você tentou esconder.
Use variáveis de ambiente ou Docker Secrets.
Em infraestruturas maiores, o HashiCorp Vault é o seu melhor amigo.
3. Orquestração e CI/CD
Se você tem um servidor só, o Docker Compose dá conta. Se a coisa crescer e você precisar de alta disponibilidade (o container cair e subir sozinho em outra máquina), aí o jogo muda para Docker Swarm ou Kubernetes.
A regra é clara: o deploy deve ser automatizado.
Build: Gera a imagem no commit.
Push: Envia para um registro privado (segurança em primeiro lugar!).
Deploy: O servidor atualiza sem derrubar o serviço para o usuário (Rolling Update).
Conclusão
Levar Docker para produção não é um bicho de sete cabeças, mas exige disciplina. Imagens leves, segredos protegidos e automação total são o que garantem que você vai dormir tranquilo à noite.
Dúvidas sobre como configurar seu pipeline? Me chama no LinkedIn ou deixa um comentário.