Deploy: do compose local a um ambiente real

O maior ganho de containerizar não é só "organizar serviço" — é que a mesma imagem testada localmente é a que vai pra produção, sem reconstruir nada nem torcer pra "bater" com o ambiente do servidor.

1. Build e publicação da imagem

docker build -t registry.exemplo.com/minha-api:latest .
docker push registry.exemplo.com/minha-api:latest

build gera a imagem local; push envia pra um registry (Docker Hub, GitHub Container Registry, ou um privado) — de onde o servidor de produção vai baixá-la, sem precisar do código-fonte nem do processo de build rodando lá.

2. No servidor: puxar e subir

docker pull registry.exemplo.com/minha-api:latest
docker compose up -d

Isso é a diferença entre deploy "clássico" (copiar código pro servidor, instalar dependência lá, torcer pra versão do Ruby/Node bater) e deploy com container: o servidor só executa uma imagem já pronta e testada — ele nunca precisa ter o ambiente de build instalado.

Variável de ambiente muda por ambiente, a imagem não

# staging
docker run --env-file .env.staging registry.exemplo.com/minha-api:latest

# produção
docker run --env-file .env.production registry.exemplo.com/minha-api:latest

A imagem minha-api:latest é idêntica nos dois casos — só o que muda é a configuração externa (lição 5), exatamente como deveria ser.

Health check — o orquestrador precisa saber se o container está bem

services:
  api:
    image: registry.exemplo.com/minha-api:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 10s
      retries: 3

Sem health check, um container "rodando" pode estar travado, sem responder — o orquestrador não tem como saber e continuar mandando tráfego pra ele. Com health check, ele é reiniciado automaticamente se parar de responder.