DevOpsQuest
0 XP
Módulo 4 · Docker e Compose

Docker Compose: o stack do CloudShop em um comando

Intermediário 50 min+25 XPDocker ComposeVueNodePostgreSQL

Objetivos desta aula

  • Declarar múltiplos serviços
  • Usar healthcheck e depends_on condicionado
  • Separar configuração por ambiente

Compose descreve o ambiente inteiro em YAML: serviços, redes, volumes e dependências. O ganho real não é digitar menos, é reprodutibilidade: qualquer pessoa clona o repositório, roda um comando e tem o mesmo ambiente — fim do onboarding de dois dias.

depends_on sozinho apenas ordena a inicialização; ele não espera o serviço ficar pronto. Para isso existe healthcheck combinado com condition: service_healthy. Sem isso, a API sobe antes do PostgreSQL aceitar conexões e entra em laço de reinício — o erro mais comum de quem está começando.

Separe o que muda por ambiente: um docker-compose.yml base e um override para desenvolvimento com bind mount e hot reload. Em produção você não usa Compose com bind mount do código; usa a imagem construída no pipeline.

1. Compose descreve o sistema

Um compose.yaml declara serviços, redes e volumes. docker compose up cria tudo na ordem certa; down remove. É infraestrutura como código para o seu ambiente local.

2. depends_on com healthcheck

depends_on sozinho só espera o container iniciar, não ficar pronto. Combine com condition: service_healthy e um healthcheck no banco.

3. Perfis e overrides

compose.override.yaml é aplicado automaticamente em dev (bind mounts, hot reload). Perfis (profiles: [tools]) ligam serviços opcionais como Adminer.

4. Comandos do dia a dia

compose ps, logs -f api, exec api sh, up -d --build api, down -v (apaga volumes — cuidado).

5. Checagem final

Um colega clona o repositório, roda um comando e tem frontend, API e banco funcionando.

Na prática

docker-compose.yml do CloudShop

yaml

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: cloudshop
      POSTGRES_USER: cloudshop
      POSTGRES_PASSWORD_FILE: /run/secrets/pg_password
    secrets: [pg_password]
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U cloudshop -d cloudshop"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks: [backend]

  api:
    build:
      context: ./api
      target: runtime
    environment:
      NODE_ENV: production
      DATABASE_HOST: db
      DATABASE_PORT: "5432"
      DATABASE_NAME: cloudshop
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3000/health"]
      interval: 15s
      timeout: 3s
      retries: 3
    networks: [backend, frontend]
    restart: unless-stopped

  web:
    build:
      context: ./web
    ports:
      - "8080:80"
    depends_on:
      api:
        condition: service_healthy
    networks: [frontend]
    restart: unless-stopped

volumes:
  pgdata:

networks:
  frontend:
  backend:
    internal: true

secrets:
  pg_password:
    file: ./secrets/pg_password.txt

Nota de segurança: A rede backend é internal: o banco não tem rota para a internet. secrets/ deve estar no .gitignore.

Operação diária com Compose

bash

docker compose up -d --build
docker compose ps
docker compose logs -f api
docker compose exec db psql -U cloudshop -d cloudshop -c '\dt'
docker compose config          # valida e resolve o arquivo final
docker compose down            # mantem volumes
docker compose down -v         # remove volumes: apaga o banco

Banco com healthcheck e API esperando

yaml

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: dev-only
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10
    volumes: [pgdata:/var/lib/postgresql/data]
  api:
    build: ./api
    depends_on:
      db:
        condition: service_healthy   # so sobe com o banco pronto
    ports: ["3000:3000"]
volumes:
  pgdata:

Por que isso importa

Compose é o ambiente de desenvolvimento padrão de times que entregam containers — e o degrau natural para Kubernetes.

Erro comum

Confiar em depends_on sem healthcheck e culpar a aplicação pelo CrashLoop.

Dica de produção

Rode docker compose config no CI para detectar YAML inválido antes do merge.

Alerta de segurança

docker compose down -v apaga volumes. Nunca digite isso em ambiente com dado real.

Pergunta de entrevista

Como você garante que a API só inicia depois que o banco aceita conexões?

Glossário

healthcheck
Comando periódico que determina se o container está saudável.
override
Arquivo Compose complementar que ajusta a configuração por ambiente.
healthcheck
Comando periódico que indica se o container está saudável.
profile
Grupo de serviços do Compose ativado sob demanda.

Conexão com o CloudShop

Entregar o ambiente completo do CloudShop com um docker compose up.

Quiz da aula

  1. 1. O que faz condition: service_healthy?

  2. 2. depends_on sem condição garante que o banco está pronto?

  3. 3. O que docker compose down -v faz a mais?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima