Пошук уроків, статей та іншого контенту
Повний приклад: застосунок, база даних, мережа й volumes разом в одному файлі.
Цей урок об'єднує images, Dockerfile, volumes, networks і змінні середовища з попередніх уроків у один реалістичний docker-compose.yml для типового веб-застосунку з власним сервером і базою даних:
services:
app:
build: . # збірка образу з локального Dockerfile
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://appuser:apppass@db:5432/appdb
NODE_ENV: production
depends_on:
- db
db:
image: postgres:16-alpine
environment:
POSTGRES_USER: appuser
POSTGRES_PASSWORD: apppass
POSTGRES_DB: appdb
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:app: build: . — Docker Compose сам збирає образ із Dockerfile у поточній папці, замість того, щоб посилатись на вже готовий опублікований образ.
app звертається до бази даних за іменем сервісу db у DATABASE_URL — та сама спільна мережа й вбудований DNS Docker Compose, розібрані в попередньому модулі, а не localhost чи хардкоджена IP-адреса.
Лише app має проброшений порт назовні (ports) — db навмисно доступний тільки всередині спільної мережі Compose, а не ззовні, зменшуючи поверхню атаки (принцип із уроку про networks).
pgdata volume гарантує, що дані PostgreSQL переживають docker compose down і повторний docker compose up.
Реальні проєкти часто мають кілька файлів Compose — базовий docker-compose.yml плюс docker-compose.override.yml для локальної розробки (наприклад, bind mount вихідного коду для живого перезавантаження) — Docker Compose автоматично об'єднує їх, якщо файл override присутній поруч з основним.
Секрети (POSTGRES_PASSWORD, DATABASE_URL вище) в реальному проєкті не хардкодять прямо в docker-compose.yml, якщо цей файл потрапляє в git, — використовують підстановку змінних оточення хоста (синтаксис ${VARIABLE} у YAML) чи env_file (попередній модуль), щоб сам файл конфігурації лишався безпечним для коміту, а реальні значення підставлялись ззовні.
Прокидати порт бази даних назовні (ports для сервісу db) без реальної потреби — розширює поверхню атаки там, де до бази даних насправді має звертатись лише сервіс app усередині тієї самої мережі Compose.
Хардкодити реальні секрети продакшн-середовища прямо в закомічений у git docker-compose.yml — той самий ризик, що й з .env файлами.
Забувати про depends_on-обмеження (гарантує лише порядок запуску, не готовність) — застосунок app може спробувати підключитись до db раніше, ніж PostgreSQL усередині справді готовий приймати з'єднання.
Практичний docker-compose.yml поєднує все з цього курсу: build для власного образу застосунку чи image для готового образу бази даних, ports лише там, де сервіс справді має бути доступний ззовні мережі Compose, volumes для персистентних даних, і змінні середовища для конфігурації без хардкодження секретів прямо у файл, що потрапляє в git.