Docker Compose для локальної розробки: чеклист

Навіщо Compose у команді

Один docker-compose.yml замінює довгі README з «спочатку підніми Postgres, потім Redis…». Усі сервіси стартують однією командою, з однаковими версіями образів для всіх розробників.

Мінімальний скелет

Структура проєкту може виглядати так:

project/
  docker-compose.yml
  apps/api/
  apps/web/

Приклад сервісу API з залежністю від бази:

services:
  api:
    build: ./apps/api
    ports:
      - "3001:3001"
    environment:
      DATABASE_URL: postgres://postgres:postgres@db:5432/app
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: app
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 3s
      timeout: 5s
      retries: 5

Порада: depends_on лише впорядковує старт контейнерів; для реальної готовності БД використовуйте healthcheck, як у прикладі.

Що перевірити перед комітом

• Томи для даних БД (volumes), щоб не губити дані після docker compose down
• .env не потрапляє в git; у compose — лише посилання на змінні
• Версії образів зафіксовані (postgres:16-alpine, а не latest)

Корисні команди

Дія	Команда
Зібрати й запустити	docker compose up --build
У фоні	docker compose up -d
Логи сервісу	docker compose logs -f api
Зупинити й прибрати	docker compose down

Коли стек стабільний, той самий compose можна наблизити до продакшену (окремі файли compose.prod.yml, секрети в CI/CD тощо) — але для локалки важливіше передбачуваність, ніж повна відповідність продакшену.