Docker Compose у 2026: Багатоконтейнерні застосунки, мережі та питання на співбесідах DevOps

Docker Compose залишається основним інструментом для визначення та запуску багатоконтейнерних Docker-застосунків у 2026 році. Незалежно від того, чи йдеться про оркестрацію локального середовища розробки, чи підготовку до DevOps співбесіди, розуміння мережевої конфігурації Compose, залежностей сервісів та production-патернів відрізняє досвідчених інженерів від початківців.

Архітектура Docker Compose

Docker Compose працює за простим принципом: визначення сервісів застосунку у файлі compose.yaml (сучасна конвенція найменування, що замінила docker-compose.yml), а Compose бере на себе створення контейнерів, налаштування мережі та керування життєвим циклом.

Специфікація Docker Compose визначає три основні концепції:

• Сервіси: Конфігурації контейнерів, що включають образ, контекст збірки, змінні середовища та ліміти ресурсів
• Мережі: Ізольовані канали комунікації між сервісами
• Томи: Постійне сховище даних, що зберігається після перезапуску контейнерів

# compose.yaml
services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/app
    depends_on:
      db:
        condition: service_healthy
    networks:
      - backend

  db:
    image: postgres:16
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=app
      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - db_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - backend

networks:
  backend:
    driver: bridge

volumes:
  postgres_data:

secrets:
  db_password:
    file: ./secrets/db_password.txt

Ця конфігурація демонструє кілька production-ready патернів: health checks для правильного порядку запуску, Docker secrets для чутливих даних, іменовані томи для постійності та явні визначення мереж.

Детальний огляд мереж Docker Compose

За замовчуванням Compose створює єдину мережу для застосунку. Усі сервіси приєднуються до цієї мережі та можуть комунікувати між собою, використовуючи ім'я сервісу як hostname. Розуміння цієї мережевої моделі є фундаментальним для подальшої міграції на Kubernetes.

# compose.yaml
services:
  frontend:
    build: ./frontend
    ports:
      - "80:80"
    networks:
      - frontend-net
      - backend-net

  api:
    build: ./api
    networks:
      - backend-net

  cache:
    image: redis:7-alpine
    networks:
      - backend-net

  db:
    image: postgres:16
    networks:
      - backend-net

networks:
  frontend-net:
    driver: bridge
  backend-net:
    driver: bridge
    internal: true

Прапорець internal: true забороняє backend-мережі доступ до зовнішнього інтернету. Frontend-сервіс з'єднує обидві мережі, виступаючи єдиною точкою входу. Така сегментація мережі відображає production-практики безпеки.

Multi-stage збірки з Compose

Production-образи мають бути мінімальними. Multi-stage збірки в поєднанні з профілями Compose дозволяють використовувати різні конфігурації для розробки та production.

# api/Dockerfile
# Етап 1: Збірка
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Етап 2: Production
FROM node:22-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

# Етап 3: Розробка
FROM node:22-alpine AS development
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
USER node
CMD ["npm", "run", "dev"]

# compose.yaml
services:
  api:
    build:
      context: ./api
      target: ${BUILD_TARGET:-production}
    volumes:
      - ${API_VOLUMES:-./api/dist:/app/dist:ro}
    profiles:
      - ${COMPOSE_PROFILES:-prod}

Виконання BUILD_TARGET=development COMPOSE_PROFILES=dev docker compose up запускає конфігурацію розробки з hot reload.

Залежності сервісів та health checks

Директива depends_on контролює порядок запуску, але запуск контейнерів не означає готовність сервісів. Health checks вирішують цю проблему синхронізації — патерн, який часто обговорюється на DevOps співбесідах.

# compose.yaml
services:
  api:
    build: ./api
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
      migrations:
        condition: service_completed_successfully

  migrations:
    build: ./api
    command: npm run migrate
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5
      start_period: 10s

  cache:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3

Існують три умови залежності:

• service_started: За замовчуванням, контейнер запущено
• service_healthy: Health check пройдено успішно
• service_completed_successfully: Контейнер завершився з кодом 0 (для init-контейнерів)

Docker Compose для локальної розробки

Середовища розробки використовують bind mounts, перевизначення змінних середовища та інструменти налагодження. Файл compose.override.yaml автоматично об'єднується з compose.yaml.

# compose.yaml (базова конфігурація)
services:
  api:
    build: ./api
    environment:
      - NODE_ENV=production

  db:
    image: postgres:16

# compose.override.yaml (перевизначення для розробки)
services:
  api:
    build:
      target: development
    volumes:
      - ./api:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
      - DEBUG=app:*
    ports:
      - "9229:9229"

  db:
    ports:
      - "5432:5432"

Анонімний том /app/node_modules запобігає перезапису встановлених залежностей контейнера node_modules хоста.

Патерни production-розгортання

Docker Compose підходить для production-розгортань на одному хості. Для багатохостової оркестрації Kubernetes з Helm забезпечує краще масштабування, але Compose залишається доречним для менших застосунків.

# compose.prod.yaml
services:
  api:
    image: registry.example.com/api:${VERSION:-latest}
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - api

Ключ deploy налаштовує ліміти ресурсів, кількість реплік та політики перезапуску. Виконання docker compose -f compose.prod.yaml up -d запускає production-стек у фоновому режимі.

Змінні середовища та керування секретами

Чутлива конфігурація потребує належного підходу. Docker Compose підтримує кілька методів, від .env файлів до Docker secrets.

# .env
POSTGRES_PASSWORD=dev_password_only
API_SECRET_KEY=local_dev_key

# compose.yaml
services:
  api:
    environment:
      - API_SECRET_KEY  # Успадковує з shell або .env
      - DATABASE_URL=postgres://user:${POSTGRES_PASSWORD}@db:5432/app
    env_file:
      - ./config/api.env

Для production Docker secrets забезпечує кращу безпеку, монтуючи чутливі дані як файли замість змінних середовища:

# compose.prod.yaml
services:
  api:
    secrets:
      - api_key
      - db_password
    environment:
      - API_KEY_FILE=/run/secrets/api_key

secrets:
  api_key:
    external: true
  db_password:
    file: ./secrets/db_password.txt

Поширені питання на DevOps співбесідах про Docker Compose

Рекрутери перевіряють розуміння концепцій Compose через практичні сценарії. Ці питання часто зустрічаються на співбесідах DevOps та platform engineering.

П: Як контейнери в мережі Compose комунікують між собою?

Docker створює виділену bridge-мережу для кожного Compose-проєкту. Сервіси комунікують, використовуючи імена сервісів як hostnames. Вбудований DNS-сервер резолвить ці імена в IP-адреси контейнерів. Зовнішній трафік досягає сервісів лише через явно опубліковані порти.

П: Що відбувається при виконанні docker compose up з існуючими контейнерами?

Compose порівнює поточну конфігурацію з працюючими контейнерами. Незмінені сервіси продовжують працювати. Модифіковані сервіси перестворюються з новими налаштуваннями. Нові сервіси запускаються з нуля. Видалені сервіси зупиняються та видаляються.

П: Як обробляти міграції бази даних у Compose?

Існують два патерни. Перший використовує init-контейнер із залежністю service_completed_successfully:

services:
  migrate:
    image: api:latest
    command: npm run migrate
    depends_on:
      db:
        condition: service_healthy

  api:
    depends_on:
      migrate:
        condition: service_completed_successfully

Другий полягає у включенні логіки міграції до скрипта запуску застосунку, перевіряючи та застосовуючи очікуючі міграції перед прийомом трафіку.

П: Чим відрізняються томи від bind mounts?

Іменовані томи керуються Docker, зберігаються у /var/lib/docker/volumes та є переносимими між хостами. Bind mounts безпосередньо відображають директорії хоста в контейнери, корисні для розробки, але залежні від середовища. Томи підтримують драйвери для віддаленого сховища, такого як NFS або хмарне block storage.

П: Яка різниця між docker-compose та docker compose?

docker-compose з дефісом був окремим інструментом V1 на базі Python, який тепер застарів. docker compose з пробілом — це реалізація V2 на базі Go, інтегрована в Docker CLI. V2 швидша, повністю підтримує специфікацію Compose та активно розвивається.

Налагодження застосунків Compose

Виправлення проблем у контейнеризованих застосунках потребує специфічних технік. Ці команди розкривають, що відбувається всередині вашого Compose-стеку:

# Переглянути логи всіх сервісів
docker compose logs -f

# Логи конкретного сервісу з мітками часу
docker compose logs -f --timestamps api

# Виконати команду в працюючому контейнері
docker compose exec api sh

# Виконати одноразову команду (запускає новий контейнер)
docker compose run --rm api npm test

# Переглянути використання ресурсів
docker compose top
docker stats

# Перевірити конфігурацію мережі
docker network inspect project_backend

# Валідувати compose-файл
docker compose config

Команда docker compose config об'єднує всі compose-файли та показує фінальну конфігурацію — безцінно для налагодження проблем з інтерполяцією змінних.

Висновок

• Docker Compose визначає багатоконтейнерні застосунки в єдиному YAML-файлі з сервісами, мережами та томами
• Сервіси комунікують через DNS, використовуючи імена сервісів як hostnames у стандартній bridge-мережі
• Health checks з умовою service_healthy забезпечують правильний порядок запуску
• compose.override.yaml використовується для налаштувань розробки, таких як bind mounts та порти налагодження
• Production-розгортання використовують ліміти ресурсів, політики перезапуску та Docker secrets для чутливих даних
• CLI docker compose (V2) замінює застарілий docker-compose (V1) з кращою продуктивністю та функціями