Ответ
Docker Compose — это инструмент для определения и запуска мультиконтейнерных Docker-приложений. Он позволяет управлять всем жизненным циклом приложения (сборка, запуск, остановка) с помощью одной команды, используя конфигурационный YAML-файл.
Основной файл — docker-compose.yml. В нем описываются:
services: Конфигурации отдельных контейнеров (веб-сервер, база данных, кэш).networks: Виртуальные сети для взаимодействия сервисов.volumes: Места для постоянного хранения данных (например, для БД).
Пример docker-compose.yml для связки Nginx + PostgreSQL:
version: '3.8'
services:
# Сервис веб-сервера
web:
image: nginx:alpine
ports:
- "8080:80" # Проброс порта 8080 хоста на 80 контейнера
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro # Монтирование конфига в режиме read-only
depends_on:
- db
# Сервис базы данных
db:
image: postgres:14-alpine
restart: always
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
volumes:
- postgres_data:/var/lib/postgresql/data # Использование именованного volume для данных
# Определение именованного volume
volumes:
postgres_data:
Ключевые моменты:
depends_on: Гарантирует порядок запуска контейнеров, но не ожидает полной готовности сервиса внутри контейнера.- Именованные volumes: Предпочтительный способ хранения данных, так как ими проще управлять, чем bind mounts.
Ответ 18+ 🔞
Да ты посмотри, какая удобная хуйня придумана! Docker Compose, блядь. Это ж как пульт от всего твоего зоопарка с контейнерами, ёпта! Вместо того чтобы вручную каждый раз эти docker run с километровыми флагами вбивать, ты пишешь один файлик на YAML — и вся твоя банда из сервисов встаёт как по маслу.
Вот этот самый файл — docker-compose.yml, священный свиток, блядь. В нём три главных раздела, которые надо знать:
services: Это наши главные герои, отдельные контейнеры. Веб-сервер, база данных, кеш — все тут, как на подбор.networks: Виртуальные сети, чтобы эти сервисы между собой болтали, а не через весь интернет кричали.volumes: Места, куда данные складываются насовсем, а то контейнер помрёт — и всё, прощай, информация. Особенно для баз данных актуально, ядрёна вошь.
Смотри, какой простой пример для связки Nginx и PostgreSQL:
version: '3.8'
services:
# Сервис веб-сервера
web:
image: nginx:alpine
ports:
- "8080:80" # Проброс порта 8080 хоста на 80 контейнера
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro # Монтирование конфига в режиме read-only
depends_on:
- db
# Сервис базы данных
db:
image: postgres:14-alpine
restart: always
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
volumes:
- postgres_data:/var/lib/postgresql/data # Использование именованного volume для данных
# Определение именованного volume
volumes:
postgres_data:
А теперь, внимание, важные нюансы, про которые все спотыкаются, сука:
depends_on: Этот ключ — тот ещё обманщик, блядь. Он гарантирует только порядок запуска контейнеров. То естьdbзапустится раньше, чемweb. Но он нихуя не ждёт, пока внутриdbPostgreSQL реально поднимется и скажет «можно работать». Контейнер-то запустился, а база ещё бултыхается. Так что если твоему веб-серверу сразу надо коннектиться — будут ошибки, пиздец. Для настоящей проверки готовности нужны healthcheck'и.- Именованные volumes: Вот это — дело, блядь. Гораздо лучше, чем эти
bind mounts(привязка к папке на хосте). Ими управлять проще, мигрировать, бэкапить. Для данных БД — идеально, в рот меня чих-пых.
Короче, инструмент охуенный, но читай документацию, а не просто копируй примеры, а то на ровном месте волосы на жопе поседеют.