Ответ
Файл docker-compose.yml использует формат YAML и описывает многоконтейнерное приложение. Его структура состоит из нескольких ключевых секций верхнего уровня.
Основные секции:
version(устарело в новых версиях): Ранее указывала версию схемы файла. Сейчас Compose V2 интегрирован в Docker CLI и это поле необязательно.services: Самая важная секция, где описывается каждый контейнер (сервис) приложения. Для каждого сервиса указываются его параметры.networks: Определяет сети, которые будут использоваться сервисами для взаимодействия друг с другом.volumes: Позволяет создавать именованные тома (volumes) для постоянного хранения данных.
Пример структуры:
# Версия опциональна в современных версиях Docker Compose
# version: '3.9'
services: # Описание контейнеров
backend:
build: ./backend # Инструкция по сборке образа
ports:
- "8000:8000"
volumes:
- db_data:/var/lib/postgresql/data
networks:
- app-net
frontend:
image: nginx:1.21-alpine # Использование готового образа
ports:
- "80:80"
networks:
- app-net
volumes: # Определение именованного тома
db_data:
networks: # Определение сети
app-net:
driver: bridgeВнутри секции services для каждого сервиса могут быть определены такие параметры, как image, build, ports, environment, volumes, depends_on и другие.
Ответ 18+ 🔞
А, слушай, про этот ваш docker-compose.yml... Ну, это ж такая бумажка, которая объясняет докеру, как ему целую кучу контейнеров разом поднимать, чтобы они друг с другом не подрались, а наоборот — работали. Как инструкция для сборки мебели, только если её накосячить, у тебя не просто тумбочка кривая будет, а весь сервис ебётся.
Основные штуки, на которые смотреть:
version— это раньше было важно, как версия прошивки. Сейчас, в новых движках, эту хуйню можно вообще не писать, оно само разберётся. Просто знай, что если видишь — это наследие.services— вот это, блядь, самое мясо! Тут ты перечисляешь всех своих подопечных: бэкенд, фронтенд, базу данных, кэш — всех, кто должен встать и начать трудиться. Каждому даёшь имя и прописываешь, чего он хочет.networks— сети. Чтобы контейнеры могли друг друга найти и пообщаться, а не тыкались слепо, как мудаки. Тут создаёшь виртуальные локальные сети для них.volumes— тома. Это такая хитрая жопа, которая позволяет данным пережить перезапуск контейнера. Иначе он проснётся чистым, как младенец, и всё забыл — а ты сиди и охуевай, куда логи делись.
Вот, смотри, как это примерно выглядит:
# version: '3.9' # Эту строку сейчас можно закомментировать, ей богу
services: # Тут живут все наши работяги
backend: # Первый чувак, бэкенд
build: ./backend # Собирай его из исходников в этой папке
ports:
- "8000:8000" # Пробрасывай порт наружу, чтобы мы могли к нему достучаться
volumes:
- db_data:/var/lib/postgresql/data # Цепляй том с данными, чтобы не потерять
networks:
- app-net # Пусть сидит в нашей внутренней сети
frontend: # Второй чувак, фронтенд
image: nginx:1.21-alpine # Бери готовый образ, не мучайся со сборкой
ports:
- "80:80" # Веб-порт на 80-й наружу
networks:
- app-net # И его тоже в ту же сеть
volumes: # Объявляем, что том db_data существует
db_data:
networks: # Объявляем сеть
app-net:
driver: bridge # Самый обычный драйвер, как мост между контейнерамиА внутри каждого сервиса под services можно ещё наворотить: переменные окружения через environment задать, зависимости через depends_on прописать (чтобы база стартанула раньше бэкенда, а то он будет как дурак в пустоту стучаться). В общем, инструмент мощный, ёпта. Главное — начать и не бояться, что всё накроется медным тазом. С первого раза редко у кого получается.