Как запустить docker compose

Запуск подмножества служб Compose

При наличии приложения, состоящего из нескольких служб и использующего Docker Compose, можно настроить, какие службы будут запущены и отлажены, путем создания или изменения существующего профиля запуска в параметрах запуска Docker Compose. Профили запуска позволяют динамически запускать только службы, которые имеют отношение к текущему сценарию. Вы можете создавать и выбирать профили запуска, чтобы настроить процесс отладки и задать определенные действия запуска, такие как Browser Launch URL . Кроме того, можно выбрать каждую службу по отдельности или выбрать профиль Docker Compose, который также будет искать файл Compose, чтобы определить какую группу служб следует запустить.

Дополнительные сведения о профилях Docker Compose см. в разделе Использование профилей с Compose.

Необходимые компоненты

• Visual Studio 2019 версии 16.10 или более поздней.
• Решение .NET с Согласованием контейнеров с Docker Compose.

• Visual Studio 2022, Visual Studio 2019 версии 16.10 или более поздней.
• Решение .NET с Согласованием контейнеров с Docker Compose.

Управление параметрами запуска

Рассмотрим следующий проект Docker Compose, в котором docker-compose.yml имеет пять служб и три профиля Compose (web, web1 и web2).

version: '3.9' services: webapplication1: image: $webapplication1 profiles: [web, web1] build: context: . dockerfile: WebApplication1/Dockerfile webapplication2: image: $webapplication2 profiles: [web, web2] build: context: . dockerfile: WebApplication2/Dockerfile webapplication3: image: $webapplication3 profiles: [web] build: context: . dockerfile: WebApplication3/Dockerfile external1: image: redis external2: image: redis 

Диалоговое окно параметров запуска Docker Compose можно открыть несколькими способами:

В Visual Studio выберите Отладка>Управление параметрами запуска Docker Compose.

В приведенном ниже примере выбирается профиль Compose web1 , который фильтрует список Службы до трех из пяти включенных в этот профиль:

Раздел профилей Docker Compose отображается только в том случае, если в файлах docker-compose.yml определены профили.

В следующем примере показано, как выбирать отдельные службы вместо фильтрации служб в профиле создания. Здесь мы покажем, как будет выглядеть диалоговое окно, если создать новый профиль запуска с именем test2 , который запускает только две из пяти служб, webapplication1 при отладке и webapplication2 без отладки. Этот профиль запуска также запускает браузер при запуске приложения и открывает его на домашней странице webapplication1 .

Эти сведения будут сохранены в launchSettings.json, как показано ниже.

< "profiles": < "test2": < "commandName": "DockerCompose", "composeLaunchServiceName": "webapplication1", "serviceActions": < "external1": "DoNotStart", "external2": "DoNotStart", "webapplication1": "StartDebugging", "webapplication2": "StartWithoutDebugging", "webapplication3": "DoNotStart" >, "composeLaunchAction": "LaunchBrowser", "commandVersion": "1.0", "composeLaunchUrl": "://localhost:" > > > 

Создание профиля запуска, использующего профиль Docker Compose

Кроме того, можно дополнительно настроить поведение при запуске, создав профили запуска Visual Studio, которые используют профили Compose.

Чтобы создать другой профиль, который использует профиль Compose, выберите Использовать профили Docker Compose, а затем web1 . Теперь профиль запуска включает три службы: webapplication1 (которая принадлежит к профилям Compose web и web1 ) external1 и external2 . По умолчанию службы без исходного кода, такие как external1 и external2 , имеют действие по умолчанию Запуск без отладки. Приложения .NET с исходным кодом будут по умолчанию запускать отладку.

Если служба не задает профиль Compose, она будет включена во все профили Compose.

Эти сведения будут сохранены, как показано в следующем коде. Настройка службы и ее действие по умолчанию не сохраняются, если не изменить действие по умолчанию.

< "profiles": < "test1": < "commandName": "DockerCompose", "composeProfile": < "includes": [ "web1" ] >, "commandVersion": "1.0" > > > 

Можно также изменить действие webapplication1 на Запуск без отладки. Параметры в launchSettings.json этом примере выглядят следующим образом:

 < "profiles": < "test1": < "commandName": "DockerCompose", "composeProfile": < "includes": [ "web1" ], "serviceActions": < "webapplication1": "StartWithoutDebugging" >>, "commandVersion": "1.0" > > > 

Свойства

Ниже приведено описание каждого свойства в launchSettings.json:

Свойство	Description
Commandname	Имя команды. По умолчанию используется «DockerCompose».
commandVersion	Номер версии, используемый для управления схемой профиля запуска DockerCompose.
composeProfile	Родительское свойство, дающее определение профиля запуска. Его дочерними свойствами являются includes и serviceActions .
composeProfile — включает	Список имен профилей Compose, составляющих профиль запуска.
composeProfile — serviceActions	Список выбранных профилей Compose, служб и действия запуска каждой службы.
serviceActions	Выводит список выбранных служб и действие запуска.
composeLaunchAction	Указывает действие запуска, выполняемое при нажатии F5 или CTRL+F5. Допустимые значения: None, LaunchBrowser и LaunchWCFTestClient.
composeLaunchUrl	URL-адрес, используемый при запуске браузера. Допустимые токены замены: «», «» и «». Пример: ://:
composeLaunchServiceName	Позволяет указать службу, используемую для замены токенов в composeLaunchUrl.

Связанный контент

• Общие сведения о сборке и отладке средств контейнеров Visual Studio
• Параметры запуска средств контейнеров Visual Studio
• Параметры сборки Docker Compose

Как создать проект в Docker Compose

Проект в Docker Compose позволяет упаковать и запустить несколько связанных сервисов вместе. Это может быть полезно, когда ваше приложение состоит из нескольких компонентов, таких как веб-сервер, база данных и кэш-сервер, которые должны работать вместе.

Для чего нужен проект?

Docker Compose позволяет определить все необходимые сервисы и их настройки в файле docker-compose.yml. Затем вы можете использовать команду docker-compose up для запуска всех сервисов одновременно.

Проект в Docker Compose обеспечивает изолированную и повторяемую среду разработки и развертывания. Он также упрощает масштабирование и обновление приложения, так как вы можете легко добавлять или изменять сервисы в файле docker-compose.yml.

Как создать проект?

Для создания проекта в Docker Compose выполните следующие простые шаги:

1, Установите Docker Compose, если у вас его еще нет. Вы можете найти инструкции по установке на официальном сайте Docker:

2. Создайте новую директорию для вашего проекта и перейдите в нее.

3. Создайте файл docker-compose.yml в директории проекта. В этом файле вы будете определять сервисы, контейнеры и настройки вашего проекта.

4. Определите сервисы и контейнеры, которые вы хотите запустить в вашем проекте, в файле docker-compose.yml. Пример:

version: ‘3’
services:
web:
build: .
ports:
— «8000:8000»
volumes:
— .:/app
db:
image: postgres
environment:
POSTGRES_PASSWORD: example

В этом примере мы определяем два сервиса: web и db. Сервис web собирается из текущей директории и проксирует порт 8000 на хостовую машину. Сервис db использует образ postgres и устанавливает переменную окружения POSTGRES_PASSWORD.

4. Запустите проект с помощью команды docker-compose up. Docker Compose автоматически соберет и запустит все сервисы, определенные в файле docker-compose.yml.

5. Проверьте работу вашего проекта, открыв веб-браузер и перейдя по адресу http://localhost:8000 (если вы использовали пример из шага 4).

Это основы создания проекта в Docker Compose. Вы можете узнать больше о Docker Compose и его возможностях в официальной документации.

Продвинутая работа с Docker — Docker-compose

Docker-compose — это надстройка над докером, приложение написанное на Python, которое позволяет запускать множество контейнеров одновременно и маршрутизировать потоки данных между ними. Для каждого проекта (кластера контейнеров) Docker создаёт свою сеть, где контейнеры могут обращаться друг к другу по именам, которые мы укажем в docker-compose.yml. Все настройки запуска кластера контейнеров находятся в этом же файле, который располагается в корневой директории проекта. Docker-compose.yml мало чем похож на знакомые нам уже docker-файлы. В отличие от них, docker-compose.yml записан не в декларативном ini-стиле как docker-файлы, а в древовидном YAML. Если вы ещё не знакомы с YAML — рекомендуем потратить 10-15 минут и ознакомиться с нашим кратким мануалом по YAML. С ним всё нижеизложенное станет куда более понятным.

Создаем проект для запуска в Docker-compose

Наш проект состоит из двух связанных контейнеров: Nginx и php. Структура нашего проекта выглядит так:

• www — каталог содержит index.html, index.php, подкаталог phpinfo. Эти файлы нужны для корректной работы Nginx и php-fpm. www также скопировано в каталоги nginx и php, из которых будут собираться контейнеры;
• nginx — директория содержит конфигурационный файл nginx custom.conf, Dockerfile, по которому будет собираться nginx-контейнер и подкаталог www (копию корневого www), который будет скопирован в контейнер для проверки работоспособности и подменен в будущем;
• php — директория содержит Dockerfile по которому будет собираться php-контейнер и аналогичный подкаталог www.

Такая структура проекта продиктована логикой сборки проекта. Сначала собираются образы Nginx и php из docker-файлов, расположенных в одноименных директориях, затем запускаются контейнеры в соответствии с инструкциями в Docker-compose.yml

Dockerfile Nginx

FROM nginx:mainline-alpine #Берем родительский образ Nginx
EXPOSE 80 # Открываем 80 порт
COPY custom.conf /etc/nginx/conf.d #Подменяем конфиг Nginx conf.d в контейнере на custom.conf
COPY ./www /var/www #Копируем содержимое www в /var/www
CMD [«nginx», «-g», «daemon off;»] #Запускаем Nginx как процесс.

Dockerfile php

FROM php:7.4-fpm #Берем родительский образ php:7.4-fpm
EXPOSE 9000 #Открываем 9000 порт
WORKDIR /var/www/ # Устанавливаем рабочим каталогом контейнера /var/www/
COPY ./www/ /var/www/ #Копируем содержимое хостового каталога www в директорию var/www/
CMD [«php-fpm»] #Выполняем команду php-fpm

В Docker-файле Nginx есть два ключевых момента для нашего проекта, которые нужно разобрать:

• инструкция COPY custom.conf /etc/nginx/conf.d копирует custom.conf из локальной папки nginx и подменяет им conf.d в контейнере Nginx. Без него Nginx не отработает.
• инструкция CMD с параметром [«nginx», «-g», «daemon off;»] запускает Nginx как процесс, а не как демон.

Кстати, в составлении Docker-файлов есть свои best practice. О некоторых из них, вы можете узнать из нашего небольшого мануала по оптимизации сборки Docker-образов.

Теперь, чтобы были понятны наши следующие действия нужно обратиться к настройкам Nginx, тому самому конфигурационному файлу custom.conf, которым мы подменяли стандартный conf.d, находящийся в Nginx-контейнере.

Внутри custom.conf выглядит так:

server < listen 80;
server_name 5.101.77.54;
root /var/www;
index index.html index.php;
location ~ \.php$ try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass php:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
>
>

Нас интересуют следующие параметры:

• server_name — имя сервера, к которому мы обращаемся. В нашем случае, это IP-адрес нашей VPS.
• root — корневая папка, в которой Nginx будет искать файлы для исполнения. Мы её будем подменять в дальнейшем через docker-compose.yml для визуализации процесса разработки.
• fastcgi_pass php:9000 — проброс запроса на отдачу динамического контента в контейнер php на порт 9000.

Со структурой проекта, docker-файлами и настройками Nginx разобрались. Переходим к ключевому — разбираемся с docker-compose.yml.

docker-compose.yml — центр управления полётами

Docker-compose файл описывает процесс загрузки и настройки контейнеров. Разберём Docker-compose.yml, который мы подготовили для нашего проекта. Код нашего файла выглядит так:

version: «2.3» #Задаем версию docker-compose.yml
services: #Задаем контейнеры
nginx: #Задаем название первого контейнера — nginx и настраиваем его
build: ./nginx #Указываем откуда будет вестись сборка
ports: # Указываем какие порты нужно пробросить наружу
— «80:80»
volumes: #Подключаем рабочий каталог с кодом проекта
— ./www:/var/www
depends_on: #Устанавливаем последовательность загрузки контейнеров
php: # php-контейнер запуститься раньше Nginx
condition: service_healthy #Устанавливаем условия при котором запуститься контейнер nginx
php: #Задаем название первого контейнера — php и настраиваем его
build: ./php #Указываем откуда будет вестись сборка
volumes: #Подключаем тот же рабочий каталог с кодом проекта
— ./www:/var/www
healthcheck: #Проверка работы приложения внутри контейнера
test: [«CMD»,»php-fpm»,»-t»] #Команда теста, которую мы хотим выполнить
interval: 3s #Интервал попыток запуска теста
timeout: 5s #Отложенность запуска команды
retries: 5 #Количество повторений
start_period: 1s #Через сколько стартовать тест после запуска контейнера

Наш Docker-compose.yml невелик, однако он может быть огромным и иметь сложную структуру из разных типов организации данных: строк, списков, словарей. По началу даже в не очень сложном Docker-compose.yml можно наделать ошибок, которые на глаз не видны, поэтому перед запуском сборки проекта — проверьте код, каким-нибудь YAML-валидатором, например, yamllint.

В начале файла мы задали инструкцию version со значением 2.3 — это сделано специально, так как разные версии Docker-compose.yml содержат разный набор инструкций. Так в версии 3 нет инструкции healthcheck, а она критически важна для нас в этом проекте.

Инструкция healthcheck (блок php-контейнера) позволяет нам проверить работоспособность приложения в контейнере, указав с помощью другой инструкции test команду для тестирования. Смежные инструкции interval, timeout, retries, start_period устанавливают временные условия выполнения инструкции test.

Следующая логически связанная с healthcheck инструкция — depends_on (блок nginx-контейнера) — контроль порядка запуска. Логика работы depends_on такова: пока успешно не закончатся все действия указанные в блоке condition над контейнером заданным выше строчкой, контейнер, в котором расположена инструкция depends_on не запустится.

В нашем случае пока успешно не выполнится тест php-контейнера, Nginx-контейнер не запустится. Это сделано для правильной очередности загрузки инфраструктурных элементов нашего проекта.

depends_on: #Устанавливаем последовательность загрузки контейнеров
php: # php-контейнер запуститься раньше Nginx
condition: service_healthy #Устанавливаем условия при котором запуститься контейнер nginx

Скажем еще несколько слов об инструкциях build и volumes:

• build — указывает на директорию из которой будет собран контейнер, в ней должен быть dockerfile;
• volumes — прокидывает локальную папку в контейнер. В нашем случае все изменения внесенные в файлы директории www будут автоматически доступны в контейнерах по пути /var/www.

Обратимся к логической блок-схеме для полного понимания процесса сборки и запуска нашего проекта, а потом перейдём непосредственно к сборке проекта.

Схема взаимодействия структурных элементов проекта и их свойств

Теперь, когда мы понимаем внутренние взаимосвязи внутри проекта — настало время его собрать. Для запуска контейнеров через docker-compose используются следующие команды:

• docker-compose build — собрать проект
• docker-compose up -d — запустить проект
• docker-compose down — остановить проект
• docker-compose logs -f [service name] — посмотреть логи сервиса
• docker-compose ps — вывести список контейнеров
• docker-compose exec [service name] [command» — выполнить команду в контейнере
• docker-compose images — список образов

Находясь в корневом каталоге проекта вызовем команду docker-compose up -d. Вот какие действия будут выполнены docker-compose: 1) Сборка образа php; 2) Сборка образа Nginx; 3) Запуск контейнера php; 4) Тест php; 5) Запуск контейнера Nginx. Проверим, запустились контейнеры командой docker ps. В ответ команда вернет сообщение следующего вида:

Если запустились не все контейнеры — введите docker ps -a и docker logs . Вывод будет содержать коды и наименования ошибок. В нашем случае оба контейнера запустились и работают на нужных портах.

Проверим работу Nginx и php с помощью команды curl:

curl -I http://5.101.77.54/ 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2
curl -I http://5.101.77.54/phpinfo/ 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2

В обоих случаях curl нам вернул код ответа 200. Это значит, что Nginx нашёл нужную страницу и отдал ее нам.

На этом сборка и тестирование проекта завершена, можно подводить итоги.

Что получается в итоге

Docker-compose — это система сборки, запуска и управления множеством контейнеров. Docker-compose не входит в единый пакет поставки Docker и устанавливается отдельно. Для сборки кластера контейнеров используется docker-compose.yml.

Docker-compose.yml — конфигурационный файл в YAML-формате, описывающий логику запуска и взаимодействия контейнеров между собой и внешним миром. В сущности инструкции заложенные в docker-compose.yml по логике работы идентичны ключам команды docker run.

На первое место при работе с Docker-compose выходит структура проекта. Она должна следовать правилам работы Docker-контейнеров — в одном контейнере должен быть только один процесс. Хорошей практикой является составление процессной карты взаимодействия элементов вашего проекта между собой и её перенос на логику работы Docker-compose.

В статье мы показали базовые возможности и основные взаимодействия с docker-compose, которых вполне будет достаточно для самостоятельной практики и экспериментов. Лучше всего для этого использовать заранее подготовленные виртуальные серверы.

Если материал этой статьи вам показался непонятным — рекомендуем ознакомиться с предыдущими нашими публикациями, они помогут заполнить возможные пробелы по теории контейнеризации и по работе Docker в частности.

Введение в Docker

Разбираемся в том, что такое Docker, из каких компонентов состоит и какие технологии контейнеризации использует.

История контейнеризации

Краткая история контейнеризации и разбор конкретных технологий: chroot, jail, namespaces и cgroups.

Шпаргалка по работе с docker-compose

Обновлено: 22.10.2023 Опубликовано: 27.04.2022

В данной инструкции мы приведем различные примеры по работе с docker-compose без подробного описания принципа работы. Данный материал можно использовать в качестве шпаргалки.

Базовый шаблон

В первую очередь, предлагаю заготовку для docker-compose файла, на основе которой можно начинать писать свой сценарий для docker. Создаем файл для работы с контейнерами:

vi docker-compose.yml

:
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

• services — основной раздел, где мы будем создавать и описывать наши сервисы (контейнеры docker). В данном примере сервис один. Для добавления еще одного добавляем еще строчки .
  • — название для нашего сервиса, на основе которого будет создан контейнер.
  • image — имя образа, который будет использоваться для создания контейнера.
  • container_name — имя, которое получен созданный контейнер.
  • hostname — имя хоста внутри контейнера.
  • restart — поведения контейнера при падении. В нашем примере мы указываем на необходимость автоматической перезагрузки, за исключением случаев, когда мы его сами остановили командой stop.
  • environment — задаем переменные окружения. В нашем примере только одна, которая указывает на часовой пояс (московское время).
  • networks — привязываем наш контейнер к сети. Опционально, но лучше определять самому подсеть. Это упрощает настройку некоторых сервисов, например, мы можем ограничить доступ для определенных подсетей и не желательно, чтобы подсети задавалась случайным образом.

  Сервисы

  В данном разделе рассмотрим примеры настроек сервисов (контейнеров). Синтаксис:

  1. Создание контейнера из готового образа. Образ указывается с помощью директивы image:

  * в данном примере будет взят образ nginx для поднятия контейнера.

  2. Сборка контейнера из Dockerfile. Для этого используем опцию build:

  build:
  context: ./web-server/
  args:
  buildno: 22042001

  • build — указание на необходимость сборки из Dockerfile. Пример создания последнего читайте в инструкции Создание собственного образа Docker.
  • context — путь, где нужно искать Dockerfile относительно места, где находится docker-compose файл.
  • buildno — номер для сборки.

  3. Проброс папок (volumes). Настраивается с помощью опции volumes:

  * в нашем примере мы смонтируем локальный каталог /data/mysql на хосте внутрь контейнера в качестве каталога /var/lib/mysql.

  Также мы можем смонтировать папку только на чтение, например:

  4. Работа с портами. Рассмотрим несколько вариантов работы с портами.

  а) Ports (внешняя публикация). С помощью данной опции мы можем указывать, на каких портах должен слушать контейнер и на какие порты должны пробрасываться запросы:

  * в данном примере наш контейнер будет слушать запросы на порту 8080 и передавать их внутрь контейнера на порт 80.

  Или можно прописать так:

  * в этом примере будет настроен проброс на порт 80. Внешний порт будет выбран docker автоматически.

  При необходимости прикрепить проброс с конкретному IP-адресу хостовой машины, используем нотацию:

  * хост docker будет слушать на порту 80 на адресе 192.168.15.15.

  б) Expose (внутрення публикация). Данная опция задает порт, на котором должно слушать приложение внутри контейнера, но проброса с внешнего адреса не будет — отправить запрос по сети на данный порт можно с другого контейнера:

  5. Переменные окружения. В нашей универсальной заготовке мы уже использовали одну системную переменную:

  environment:
  TZ: «Europe/Moscow»

  Чтобы передать несколько переменных, просто их перечисляем:

  environment:
  TZ: «Europe/Moscow»
  MYSQL_ROOT_PASSWORD=password

  Для каждого приложения есть свой набор системных переменных, которые оно понимает и интерпретирует. Например, MYSQL_ROOT_PASSWORD поймет СУБД и установит значение в качестве пароля для пользователя root.

  Также системные переменные можно передать не в сценарии docker-compose, а в файле .env — просто создадим этот файл в одной директории с файлом docker-compose.yml:

  6. Зависимости для контейнеров. Мы можем указать с помощью опции depends_on, от какого контейнера зависит сервис:

  * в конкретном примере, контейнер не запустится, пока не поднимется db.

  7. Переопределить команду. С помощью директивы command мы можем переопределить команду для запуска, например:

  command: [ «redis-server», «/usr/local/etc/redis/redis.conf» ]

  * в данном примере мы запустим redis-server с альтернативным конфигурационным файлом.

  Или можно написать так:

  command:
  — redis-server
  — /usr/local/etc/redis/redis.conf

  Но если нам понадобиться запустить несколько последовательных команд, рабочий вариант с использованием bash:

  command: bash -c «yarn install && yarn start»

  или если в контейнере нет bash:

  command: sh -c «yarn install && yarn start»

  8. Метки. С помощью опции labels мы можем указывать дополнительную информацию для ориентирования или фильтров при поиске контейнеров:

  * данные могут быть произвольные. Обратите внимание, что в качестве значений мы указали переменные, которые можно просто передать из системного окружения.

  9. Пользователь. Директива user позволяет задать конкретного пользователя, от которого будет запускаться и работать контейнер:

  10. Домашняя директория. Определяет положение по умолчанию, откуда будут выполняться команды.

  Healthcheck

  Данная директива, хоть и является частью сервиса, мы рассмотрим ее в отдельном разделе. Синтаксис:

  • test — наш скрипт, который должен вернуть 0, если все хорошо, или 1 — если все плохо.
  • interval — как часто запускать проверку.
  • timeout — как долго нужно ждать ответа.
  • retries — сколько раз тест должен вернуть отрицательный результат, чтобы контейнер перешел в состояние «unhealthy».

  1. Проверка работы веб-портала. Рассмотрим пример, когда сайт при правильной работы должен возвращать слово works:

  healthcheck:
  test: curl -s http://127.0.0.1 | grep works
  interval: 30s
  timeout: 2s
  retries: 10

  * в данном примере мы запросим у нашего сервера страницу по http и выведем строку, в которой есть слово works. Если такой строки не найдется, команда вернет код 1.

  2. Проверка СУБД mysql. Проверку можно выполнить с помощью запроса SELECT 1. В композ-файле это выглядит так:

  healthcheck:
  test: [«CMD», «mysql» ,»-h», «mysql», «-P», «3306», «-u», «root», «-e», «SELECT 1», «cache»]
  interval: 30s
  timeout: 2s
  retries: 10

  Networks

  Отдельно рассмотрим варианты сетевых настроек.

  Список сетей, созданных для docker можно увидеть командой:

  docker network ls

  Получить подробную информацию по сети можно командой:

  docker network inspect

  1. Указать определенную подсеть. Задается с помощью опции subnet в отдельной секции networks. В последней мы создаем конфигурацию для определенной сети (в данном примере, default). Для конкретного сервиса мы также задаем привязку к созданной сети default в подразделе networks:

  networks:
  default:
  ipam:
  driver: default
  config:
  — subnet: 172.28.0.0/16

  * где 172.28.0.0/16 — подсеть, в которой будут работать все контейнеры, которые привязаны к созданной сети default.

  2. Алиасы. Данная настройка позволит видеть контейнеры по альтернативным именам (по умолчанию, они обнаруживаются по имени контейнера). Настройка указывается в подразделе networks сервиса:

  * в данном примере наш контейнер будет также резолвиться по имени .

  3. Внешняя сеть. Если необходимо, чтобы наши контейнеры могли видеть по сети другие контейнеры, создаем сеть external:

  networks:
  dnet:
  external:
  name: dnet

  4. Статические IP-адреса. По docker идеологии все контейнеры должны получать IP-адреса автоматически. Но все же, метод для указания контейнерам статических адресов предусмотрен. Рассмотрим на примере:

  networks:
  vpcbr:
  driver: bridge
  ipam:
  config:
  — subnet: 172.28.0.0/24
  gateway: 172.28.0.1

  * в нашем примере будет создана подсеть 172.28.0.0/24, а контейнеру будет присвоен адрес 172.28.0.2.

  5. Добавить сопоставление имя — IP-адрес (на подобие локального файла hosts). С помощью данной настройки мы можем указать отдельно для контейнеров, в какой IP-адрес должен разрешаться определенный хост. Задается с помощью директивы extra_hosts:

  * в данном примере имени foo будет соответствовать адрес 1.2.3.4, а bar — 5.6.7.8.

  Запуск docker-compose

  Рассмотрим различные примеры выполнения команды docker-compose.

  1. Посмотреть версию:

  2. Создание и запуск контейнеров:

  docker-compose up -d

  * напомним, что в текущем каталоге находится созданный файл с названием docker-compose.yml.

  С указанием альтернатнативного файла docker-compose.

  docker-compose -f /foo/bar/other-docker-compose.yml up -d

  3. Перечитать файл docker-compose:

  docker-compose up -d

  * на самом деле, команда такая же, как для запуска. Система если определит, что есть изменения, пересоздаст контейнер.

  Перечитать и пересобрать контейнеры, если есть инструкция build:

  docker-compose up -d —build

  4. Остановить контейнеры.

  Только остановить контейнеры:

  Остановить контейнеры с удаление данных (в volumes):

  docker-compose down —volumes

  Возможные ошибки

  Network _default Error

  При попытке запустить compose получаем ошибку:

  Network _default Error
  failed to create network _default: Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

  Причина: при запуске композа автоматически создается сеть с префиксом _default. Данная ошибка означает, что такую сеть не удалось создать, так как существует лимит на пулы IP-адресов и данный лимит был исчерпан.

  Решение: быстрее всего выполнить чистку docker от неиспользуемых сетей. Для этого выполняем команду:

  docker network prune

  Читайте также

  Другие инструкции, связанные с Docker:

  Похожие публикации:

  1. Anti aliasing это что
  2. Swift ui что это
  3. Где разрабатывать telegram bot на python
  4. Как прошептать сообщение в телеграмме в чате