Variáveis de ambiente e volumes

Variáveis de ambiente — configuração fora da imagem

Uma imagem Docker é construída uma vez e roda em vários lugares (local, staging, produção) — cada lugar com um DATABASE_URL, uma chave de API diferente. Isso não pode estar escrito dentro da imagem (senão você precisaria de uma imagem por ambiente); tem que ser injetado na hora de rodar o container.

docker run -e DATABASE_URL=postgres://... -e SECRET_KEY=abc123 minha-api

services:
  api:
    build: .
    env_file: .env    # lê as variáveis desse arquivo, que NUNCA vai pro git

O .env entra no .gitignore sempre — é exatamente o tipo de arquivo que, se commitado sem querer, vaza credencial de produção pro histórico do repositório pra sempre.

Volumes — dado que sobrevive ao container

Por padrão, tudo que um container escreve no próprio sistema de arquivos some quando ele é removido. Isso é ótimo pra código (você quer sempre a versão da imagem, não o que sobrou de execuções antigas) e péssimo pra dado de banco. Um volume é uma pasta que existe fora do ciclo de vida do container, montada dentro dele.

services:
  db:
    image: postgres:16-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data   # nomeado — Docker gerencia onde fica

volumes:
  postgres_data:

Existe também o bind mount: em vez de um volume nomeado, você monta uma pasta real da sua máquina — útil em desenvolvimento, pra editar código local e ver o container refletir na hora, sem rebuild.

services:
  api:
    build: .
    volumes:
      - .:/app          # bind mount: pasta do projeto local dentro do container
      - /app/node_modules # exceção: node_modules do container, não da máquina local