====== docker-compose шпаргалка ====== Базовый шаблон Создаем файл: nano docker-compose.yml version: "3.9" services: : image: container_name: hostname: restart: unless-stopped environment: TZ: "Europe/Moscow" networks: - default networks: default: ipam: driver: default config: - subnet: 172.28.0.0/16 * где: version — версия спецификации файла. Начиная с docker-compose v1.27.0 является опциональной. services — основной раздел, где мы будем создавать и описывать наши сервисы (контейнеры docker). В данном примере сервис один. Для добавления еще одного добавляем еще строчки . — название для нашего сервиса, на основе которого будет создан контейнер. image — имя образа, который будет использоваться для создания контейнера. container_name — имя, которое получен созданный контейнер. hostname — имя хоста внутри контейнера. restart — поведения контейнера при падении. В нашем примере мы указываем на необходимость автоматической перезагрузки, за исключением случаев, когда мы его сами остановили командой stop. environment — задаем переменные окружения. В нашем примере только одна, которая указывает на часовой пояс (московское время). networks — привязываем наш контейнер к сети. Опционально, но лучше определять самому подсеть. Это упрощает настройку некоторых сервисов, например, мы можем ограничить доступ для определенных подсетей и не желательно, чтобы подсети задавалась случайным образом. networks — описание для сети. В нашем примере используются стандартные настройки, но указывается конкретная подсеть 172.28.0.0/16. ====== Сервисы ====== В данном разделе рассмотрим примеры настроек сервисов (контейнеров). Синтаксис: services: <имя сервиса>: <настройки сервиса> 1. **Создание контейнера из готового образа**. Образ указывается с помощью директивы image: image: nginx * в данном примере будет взят образ **nginx** для поднятия контейнера. 2. **Сборка контейнера из Dockerfile**. Для этого используем опцию build: build: context: ./web-server/ args: buildno: 22042001 * где: build — указание на необходимость сборки из Dockerfile. context — путь, где нужно искать Dockerfile относительно места, где находится docker-compose файл. buildno — номер для сборки. 3. **Проброс папок (volumes)**. Настраивается с помощью опции volumes: volumes: - /data/mysql:/var/lib/mysql * в нашем примере мы смонтируем локальный каталог /data/mysql на хосте внутрь контейнера в качестве каталога /var/lib/mysql. 4. **Работа с портами**. С помощью опции ports мы можем указывать, на каких портах должен слушать контейнер и на какие порты должны пробрасываться запросы: ports: - 8080:80 * в данном примере наш контейнер будет слушать запросы на порту 8080 и передавать их внутрь контейнера на порт 80. 5. **Переменные окружения**. В нашей универсальной заготовке мы уже использовали одну системную переменную: environment: TZ: "Europe/Moscow" Чтобы передать несколько переменных, просто их перечисляем: environment: TZ: "Europe/Moscow" MYSQL_ROOT_PASSWORD=password Для каждого приложения есть свой набор системных переменных, которые оно понимает и интерпретирует. Например, MYSQL_ROOT_PASSWORD поймет СУБД и установит значение в качестве пароля для пользователя root. Также системные переменные можно передать не в сценарии docker-compose, а в файле .env — просто создадим этот файл в одной директории с файлом docker-compose.yml: vi .env MYSQL_ROOT_PASSWORD=secret MYSQL_PWD=secret 6. **Зависимости для контейнеров**. Мы можем указать с помощью опции depends_on, от какого контейнера зависит сервис: depends_on: - db * в конкретном примере, контейнер не запустится, пока не поднимется db. 7. **Переопределить команду**. С помощью директивы command мы можем переопределить команду для запуска, например: command: [ "redis-server", "/usr/local/etc/redis/redis.conf" ] * в данном примере мы запустим redis-server с альтернативным конфигурационным файлом. 8. **Метки**. С помощью опции labels мы можем указывать дополнительную информацию для ориентирования или фильтров при поиске контейнеров: labels: MAINTAINER: ${MAINTAINER_EMAIL} SITE_URL: ${SITE_URL} * данные могут быть произвольные. Обратите внимание, что в качестве значений мы указали переменные, которые можно просто передать из системного окружения. ====== Healthcheck ====== Данная директива, хоть и является частью сервиса, мы рассмотрим ее в отдельном разделе. Синтаксис: services: <имя сервиса>: ... healthcheck: test: