====== 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: