Docker compose что это такое
Использование Docker Compose
Docker Compose — это средство, разработанное для помощи в определении и совместном использовании многоконтейнерных приложений. С помощью средства Compose можно создать файл YAML для определения служб и с помощью одной команды запускать и останавливать все, что нужно.
Большим преимуществом использования Compose является то, что можно определить стек приложения в файле, сохранить его в корне репозитория проекта (теперь поддерживается управление версиями) и легко предоставить другому пользователю возможность участвовать в проекте. Другому пользователю достаточно будет только клонировать репозиторий и начать создание приложения. Фактически в GitHub и GitLab можно увидеть достаточно много проектов, использующих эту возможность.
С чего же начать работу?
Установка Docker Compose
Если вы установили Docker Desktop для Windows или Mac, то у вас уже есть Docker Compose. В экземплярах «Play-with-Docker» уже установлен Docker Compose. Если вы используете компьютер Linux, необходимо установить Docker Compose с помощью приведенных здесь инструкций.
После установки вы сможете запустить следующую команду и просмотреть сведения о версии.
Создание файла Compose
Написание файла Compose начнем с определения версии схемы. В большинстве случаев лучше использовать последнюю поддерживаемую версию. Текущие версии схемы и матрицу совместимости см. в справочнике по файлу Compose.
Затем определим список служб (или контейнеров), которые требуется использовать как часть приложения.
Теперь приступим к переносу службы в файл Compose.
Определение службы приложений
Напомним, что эту команду вы использовали для определения контейнера приложения (замените в Windows PowerShell символы \ на символы ` ).
Сначала определите запись службы и образ для контейнера. Для службы можно выбрать любое имя. Имя будет автоматически преобразовано в сетевой псевдоним, что будет полезно при определении службы MySQL.
Одним из преимуществ определений томов Docker Compose является использование относительных путей из текущего каталога.
Определение службы MySQL
Теперь пора определить службу MySQL. Для этого контейнера использовалась следующая команда (замените в Windows PowerShell символы \ на символы ` ).
Наконец, осталось указать переменные среды.
На этом этапе полный файл docker-compose.yml должен выглядеть следующим образом.
Запуск стека приложений
После запуска должны отобразиться примерно следующие выходные данные.
Вы увидите, что том был создан, так же как и сеть. По умолчанию Docker Compose автоматически создает сеть специально для стека приложений (поэтому мы не определили его в файле Compose).
Если вы еще этого не сделали, вы увидите следующий результат.
Ожидание базы данных перед запуском приложения. При запуске приложения оно фактически ожидает, пока MySQL будет готов к работе, прежде чем попытаться подключиться к нему. В Docker отсутствует встроенная поддержка, позволяющая ожидать, пока другой контейнер будет полностью готов, запущен и подготовится к запуску другого контейнера. Для проектов на основе узлов можно использовать зависимость wait-port. Аналогичные проекты существуют для других языков и платформ.
На этом этапе вы сможете открыть приложение и увидеть, что оно запускается. И постойте! Вы сделали это с помощью одной команды!
Просмотр стека приложений в расширении Docker
Если взглянуть на расширение Docker, там можно изменить параметры группировки с помощью меню «шестеренки» и пункта «Group By» (группировать). В нашем случае необходимо просмотреть контейнеры, сгруппированные по имени проекта Compose.
Если развернуть сеть, вы увидите два контейнера, которые вы определили в файле Compose.
Завершение работы
Когда необходимо завершить работу, просто выполните команду docker-compose down или щелкните правой кнопкой мыши приложение в списке контейнеров в расширении Docker VS Code и выберите Compose Down (завершить Compose). Контейнеры будут остановлены, а сеть удалена.
После завершения работы можно переключиться на другой проект, запустить docker-compose up и подготовиться к работе с этим проектом. На самом деле нет ничего проще!
Резюме
В этом разделе вы узнали о средстве Docker Compose и о том, как оно помогает значительно упростить определение и совместное использование приложений с несколькими службами. Вы создали файл Compose, переведя команды в соответствующий формат.
Сейчас начинается завершающий этап обучения. Однако есть несколько рекомендаций по созданию образов, которые необходимо осветить, поскольку есть большая проблема с Dockerfile, который вы использовали. Так что давайте взглянем на это.
Docker Compose: от разработки до продакшена
Перевод транскрипции подкаста подготовлен в преддверии старта курса «Администратор Linux»
Docker Compose — это удивительный инструмент для создания рабочего
окружения для стека, используемого в вашем приложении. Он позволяет вам определять
каждый компонент вашего приложения, следуя четкому и простому синтаксису в YAML-
файлах.
С появлением docker compose v3 эти YAML-файлы могут использоваться непосредственно в рабочей среде, при работе с кластером Docker Swarm.
Но значит ли это, что вы можете использовать один и тот же docker-compose файл в процессе разработки и в продакшен среде? Или использовать этот же файл для стейджинга? Ну, в целом — да, но для такого функционала нам необходимо следующее:
Различия между файлами для разработки и продакшена
Во время разработки вы, скорее всего, захотите проверять изменения кода в
режиме реального времени. Для этого, обычно, том с исходным кодом монтируется в
контейнер, в котором находится рантайм для вашего приложения. Но для продакшн-среды
такой способ не подходит.
В продакшене у вас есть кластер с множеством узлов, а том является локальным по
отношению к узлу, на котором работает ваш контейнер (или сервис), поэтому вы не
можете монтировать исходный код без сложных операций, которые включают в себя
синхронизацию кода, сигналы и т. д.
Вместо этого мы, обычно, хотим создать образ с конкретной версией вашего кода.
Его принято помечать соответствующим тегом (можно использовать семантическое
версионирование или другую систему на ваше усмотрение).
Переопределение конфигурации
Учитывая различия и то, что ваши зависимости могут отличаться в сценариях
разработки и продакшена, ясно, что нам потребуются разные конфигурационные файлы.
Docker compose поддерживает объединение различных compose-файлов для
получения окончательной конфигурации. Как это работает можно увидеть на примере:
Как было сказано, docker compose поддерживает объединение нескольких compose-
файлов, это позволяет переопределять различные параметры во втором файле. Например:
Такой синтаксис не очень удобен в процессе разработки, когда команду
понадобится выполнять множество раз.
К счастью, docker compose автоматически ищет специальный файл с именем
docker-compose.override.yml для переопределения значений docker-compose.yml. Если
переименовать второй файл, то получится тот же результат, только с помощью изначальной команды:
Хорошо, так запомнить проще.
Интерполяция переменных
Файлы конфигурации поддерживают интерполяцию
переменных и значения по умолчанию. То есть вы можете сделать следующее:
И если вы выполняете docker-compose build (или push) без переменной окружения
$MY_SERVICE_VERSION, будет использовано значение latest, но если вы установите
значение переменной окружения до сборки, оно будет использовано при сборке или пуше
в регистр private.registry.mine.
Мои принципы
Подходы, которые удобны для меня, могут пригодиться и вам. Я следую этим
простым правилам:
Давайте посмотрим на простой пример.
Я могу использовать docker-compose (docker-compose up), чтобы запустить стек в
режиме разработки с исходным кодом, смонтированным в /project/src.
Я могу использовать эти же файлы на продакшене! И я мог бы использовать точно
такой же файл docker-compose.yml для стейджинга. Чтобы развернуть это на
продакшен, мне просто нужно собрать и отправить образ с предопределенным тегом
на этапе CI:
На продакшене это можно запустить с помощью следующих команд:
И если вы хотите сделать то же самое на стейдже, необходимо просто определить
необходимые переменные окружения для работы в среде стейджинга:
В итоге мы использовали два разных docker-compose файла, которые без
дублирования конфигураций могут использоваться для любой вашей среды!
Узнать подробнее о курсе «Администратор Linux»
Docker-compose: идеальное рабочее окружение
Здрасте!
В последнее время все чаще задумываюсь об оптимальности рабочего процесса и хотелось бы поделиться своими изысканиями в данном вопросе.
В данном посте поговорим про docker-compose, который по моему мнению является панацеей в вопросе организации и оптимизации рабочего процесса разработчика.
Описывать все я буду почти на пальцах, поэтому если вы до этого ни разу не слышали про docker (что странно), ни разу с ним не работали и хотите в нем разобраться, то прошу под кат.
Предисловие
В статье я умышленно упрощаю некоторые моменты, не углубляюсь в детали и поверхностно касаюсь многих вопросов.
Делаю я это с полным понимаем своих действий, и считаю, что не нужно лазить под капот, если все работает.
Те, кто считают иначе — это ваше полное право, но только не нужно навязывать свою точку зрения.
Спасибо!
Docker
Технология, позволяющая легко (во всех смыслах) разворачивать необходимое рабочее окружение.
Подробнее можно узнать из ссылок в конце статьи, но лучше сейчас на это не переключаться, чтобы не забивать себе мозг.
Docker-compose
Пакетный менеджер (по аналогии с composer и npm, только у docker — контейнеры), позволяющий описывать необходимую структуру в одном файле (конфиге).
Подробнее также можно узнать из ссылок в конце статьи.
Docker-hub
Репозиторий контейнеров (по аналогии с packagist и npm).
Важное замечание: внимательно читайте описание к образу, 70-80% тупых вопросов там описано, не тратьте время на гугление.
Установка
Переписывать документацию docker я не стану, поэтому просто кину ссылки:
Установка обычного программного обеспечения (ПО), проблем возникнут не должно.
Если все же возникнут, то дальше можете не читать, вероятно вы случайно наткнулись на эту статью и разработку в целом.
Если вы устанавливали docker под Windows, то работать нужно через специальную консоль Docker Quickstart Terminal. После установки, на рабочем столе должен появиться соответствующий ярлык.
Структура проекта
Для начала определимся со структурой проектов:
CMD / Terminal
Для работы с docker и compose мы будем использовать всего несколько команд:
Описание прочих команд, можно найти на официальном сайте.
Перейдем непосредственно к делу.
apache
Начнем, пожалуй, с самого популярного сервера — Apache.
Создадим директорию проекта:
Конфиг будет выглядеть таким образом:
Что здесь происходит:
Создадим файл src/index.html в рабочей директории с содержимым:
Запускаем наш проект:
Переходим в браузер по адресу ПК и наблюдаем приветствие нашего сервера.
Чтобы уничтожить контейнеры нашего проекта, достаточно в консоле выполнить Ctrl+C.
Если докер работает через VirtualBox, то нужно заходить по IP виртуалки. При любом раскладе, если вы работаете через Docker Quickstart Terminal, то адрес выведется при запуске консоли.
Работа в фоновом режиме
Если вам необходимо запустить docker и далее работать в консоле, то можно запустить проект в фоном режиме:
После запуска, консоль будет доступна для работы.
Чтобы в данной ситуации уничтожить контейнер, необходимо его остановить и удалить, но для начала, нужно узнать его ID:
В моем случае получился такой вывод:
Теперь останавливаем и удаляем наш контейнер:
Либо можно поступить грубо и сразу удалить:
nginx
Конфиг nginx строиться по той же самой схеме, что и apache: образ, порты, рабочая директория. Выглядит файл таким образом:
Создаем файл src/index.html в рабочей директории с содержимым:
Заходим в браузер, и видим приветствие очередного сервера.
php + apache
Если говорить про связку PHP и Apache, то для нее уже есть готовый образ, поэтому про линковку контейнеров будем говорить далее. А сейчас просто конфиг:
Создаем файл src/index.php в рабочей директории с содержимым:
Проверяем его работу в браузере.
php + nginx
В данной связке php будет в формате fpm. Схематично это выглядит таким образом:
Соответственно нам нужно будет переписать конфиг сервера.
Для этого нужно будет слинковать помимо рабочей директории, еще и файл конфигурации сервера:
Если мы не укажем depends_on, то можем словить подобную ошибку:
Создаем файл /nginx/nginx.conf в директории нашего проекта. Сам конфиг выглядит таким образом:
После всех действий, директория нашего проекта выглядит таким образом:
Запускаем, проверяем, радуемся!
php + apache + nginx
Наверное, самая популярная связка для веб-проектов. Схематично это выглядит так:
Для того чтобы все настроить нам нужно будет также слинковать конфиг apache, и таким образом docker-compose будет выглядеть так:
Так как на просторах интернета я не нашел нормальный конфиг (оке, я просто не искал), а под рукой как раз docker, то решено было вытаскивать его из стандартного контейнера.
Уложилось все в 3 команды:
После выполнения данных команд, в текущей директории появится файл httpd.conf, который мы и будем использовать в качестве основы.
По сути, это простое копирование из запущенного контейнера.
Создаем файл /httpd/httpd.conf в рабочей директории, который после правок выглядит так:
Создаем файл /nginx/nginx.conf в рабочей директории со следующим содержимым:
В строке proxy_pass http://apache мы опять указываем не IP адрес, а название контейнера (вспоминаем про магию с hosts).
Для тестинга, нам нужно будет проверить, работает ли PHP и работает ли Apache.
Сформируем такую структуру проекта:
Содержимое .htaccess:
Содержимое index.php:
Содержимое index.html:
Если все настроено корректно, то картина должна быть следующей:
mariadb + phpmyadmin
Поговорим про базы данных.
Конфиг для подключения выглядит следующим образом:
Для mariadb и phpmyadmin мы указали директиву environment, которая содержит специфические для конкретного контейнера переменные (подробности можно посмотреть в репозиториях самих контейнеров).
В данном случае, это пароль для пользователя root.
Для phpmyadmin мы вручную указали директиву links:
Сделать это необходимо для того, чтобы phpmyadmin знал с какой базой соединятся.
Если бы контейнер mariadb назывался db, то указывать эту директорию было бы не нужно.
Для mariadb мы слинковали директорию с данными:
Сделано это для того, чтобы данные хранились в директории нашего проекта, а не внутри контейнера.
Если вы работаете не на linux машине, то у вас возникнут проблемы с размещением данных базы на локальной машине.
Эти непреодолимое обстоятельство, к сожалению, на данный момент не преодолено.
У кого есть решение просьба поделиться.
Однако по умолчанию (даже после уничтожения контейнера), данные базы сохраняются и вы можете пересоздавать контейнер сколько угодно раз — данные сохранятся в недрах локальной машины.
php + apache + nginx + mariadb + phpmyadmin
Ну, а теперь совмещаем наши конфиги, и получаем неплохое веб-окружение:
Для php мы добавили директиву build (подробнее), в которой указали директорию php, где хранится Dockerfile со следующим содержанием:
В данном файле мы обновляем репозитории и устанавливаем php модули (подробнее про docker-php-ext-install).
Также мы слинковали конфиг php, чтобы можно было его настроить нужным нам образом.
Содержимое php.ini можно взять, например, здесь.
Запускаем, проверяем, радуемся!
Если все сделано правильно, то index.php отработает без ошибок, а в директории project/mysql появятся служебные файлы базы.
Docker production
По данному вопросу к сожалению я ничего сказать не могу, зато может сказать официальная документация.
Если у вас есть опыт использования docker на боевых проектах, то просьба поделиться своим опытом в комментариях: стоит ли, какие трудности и подводные камни у вас возникли и др. полезную информацию для молодых и неопытных.
Заключение
Вот собственно и все, чем я хотел поделиться.
Как видите необязательно знать принцип работы docker, чтобы успешно с ним работать.
Да, конечно, для тонкой настройки или сложных задач, необходимо уже углубляться в дебри docker, но в средне-статистическом случае — это не нужно.
Если у вас есть что добавить, или вы заметили какой-то косяк, или вы с чем-то не согласны, то прошу в комментарии, обсудим 😉
Полезные ссылки (a.k.a список используемой литературы)
Если честно, я не понимаю откуда столько негатива.
Судя по комментариям, основные претензии к формулировкам и терминологии, и это с учетом того, что в предисловии я написал что умышленно упрощаю многие моменты.
Цель статьи — показать, как просто работать с docker-compose, как вместо того, чтобы разворачивать 100500 окружений и ПО для каждого своего проекта, можно использовать docker-compose и быть довольным.
Тут нет речи про prodUction (одного абзаца хватит), про deploy, про миграцию между dev и prod средой.
Нет, статья не об этом.
Большое спасибо krocos Caravus Vershnik Fesor за дельные комментарии.
Руководство по Docker Compose для начинающих
Автор статьи, перевод которой мы сегодня публикуем, говорит, что она предназначена для тех разработчиков, которые хотят изучить Docker Compose и идут к тому, чтобы создать своё первое клиент-серверное приложение с использованием Docker. Предполагается, что читатель этого материала знаком с основами Docker. Если это не так — можете взглянуть на эту серию материалов, на эту публикацию, где основы Docker рассмотрены вместе с основами Kubernetes, и на эту статью для начинающих.
Что такое Docker Compose?
Docker Compose — это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развёртыванием проектов.
Изучая основы Docker, вы могли столкнуться с созданием простейших приложений, работающих автономно, не зависящих, например, от внешних источников данных или от неких сервисов. На практике же подобные приложения — редкость. Реальные проекты обычно включают в себя целый набор совместно работающих приложений.
Как узнать, нужно ли вам, при развёртывании некоего проекта, воспользоваться Docker Compose? На самом деле — очень просто. Если для обеспечения функционирования этого проекта используется несколько сервисов, то Docker Compose может вам пригодиться. Например, в ситуации, когда создают веб-сайт, которому, для выполнения аутентификации пользователей, нужно подключиться к базе данных. Подобный проект может состоять из двух сервисов — того, что обеспечивает работу сайта, и того, который отвечает за поддержку базы данных.
Технология Docker Compose, если описывать её упрощённо, позволяет, с помощью одной команды, запускать множество сервисов.
Разница между Docker и Docker Compose
Docker применяется для управления отдельными контейнерами (сервисами), из которых состоит приложение.
Docker Compose используется для одновременного управления несколькими контейнерами, входящими в состав приложения. Этот инструмент предлагает те же возможности, что и Docker, но позволяет работать с более сложными приложениями.
Docker (отдельный контейнер) и Docker Compose (несколько контейнеров)
Типичный сценарий использования Docker Compose
Docker Compose — это, в умелых руках, весьма мощный инструмент, позволяющий очень быстро развёртывать приложения, отличающиеся сложной архитектурой. Сейчас мы рассмотрим пример практического использования Docker Compose, разбор которого позволит вам оценить те преимущества, которые даст вам использование Docker Compose.
Представьте себе, что вы являетесь разработчиком некоего веб-проекта. В этот проект входит два веб-сайта. Первый позволяет людям, занимающимся бизнесом, создавать, всего в несколько щелчков мышью, интернет-магазины. Второй нацелен на поддержку клиентов. Эти два сайта взаимодействуют с одной и той же базой данных.
Ваш проект становится всё популярнее, и оказывается, что мощности сервера, на котором он работает, уже недостаточно. В результате вы решаете перевести весь проект на другую машину.
К сожалению, нечто вроде Docker Compose вы не использовали. Поэтому вам придётся переносить и перенастраивать сервисы по одному, надеясь на то, что вы, в процессе этой работы, ничего не забудете.
Если же вы используете Docker Compose, то перенос вашего проекта на новый сервер — это вопрос, который решается выполнением нескольких команд. Для того чтобы завершить перенос проекта на новое место, вам нужно лишь выполнить кое-какие настройки и загрузить на новый сервер резервную копию базы данных.
Разработка клиент-серверного приложения с использованием Docker Compose
Теперь, когда вы знаете о том, для чего мы собираемся использовать Docker Compose, пришло время создать ваше первое клиент-серверное приложение с использованием этого инструмента. А именно, речь идёт о разработке небольшого веб-сайта (сервера) на Python, который умеет выдавать файл с фрагментом текста. Этот файл у сервера запрашивает программа (клиент), тоже написанная на Python. После получения файла с сервера программа выводит текст, хранящийся в нём, на экран.
Обратите внимание на то, что мы рассчитываем на то, что вы владеете основами Docker, и на то, что у вас уже установлена платформа Docker.
Приступим к работе над проектом.
▍1. Создание проекта
Для того чтобы построить ваше первое клиент-серверное приложение, предлагаю начать с создания папки проекта. Она должна содержать следующие файлы и папки:
▍2. Создание сервера
Тут мы, в процессе создания сервера, затронем некоторые базовые вещи, касающиеся Docker.
2a. Создание файлов
Перейдите в папку server и создайте в ней следующие файлы:
2b. Редактирование Python-файла.
Добавим в файл server.py следующий код:
2c. Редактирование HTML-файла
В файл index.html добавим следующий текст:
Этот текст будет передаваться клиенту.
2d. Редактирование файла Dockerfile
Теперь займёмся работой над клиентом.
▍3. Создание клиента
Создавая клиентскую часть нашего проекта, мы попутно вспомним некоторые основы Docker.
3a. Создание файлов
Перейдите в папку вашего проекта client и создайте в ней следующие файлы:
3b. Редактирование Python-файла
Добавим в файл client.py следующий код:
Благодаря этому коду клиентское приложение может загрузить данные с сервера и вывести их на экран.
3c. Редактирование файла Dockerfile
▍4. Docker Compose
Вот код, который нужно поместить в файл docker-compose.yml :
▍5. Сборка проекта
▍6. Запуск проекта
Теперь, когда проект собран, пришло время его запустить. Этот шаг нашей работы соответствует шагу, на котором, при работе с отдельными контейнерами, выполняется команда docker run :
Полезные команды
Рассмотрим некоторые команды, которые могут вам пригодиться при работе с Docker Compose.
Эта команда позволяет останавливать и удалять контейнеры и другие ресурсы, созданные командой docker-compose up :
Эта команда выводит журналы сервисов:
С помощью такой команды можно вывести список контейнеров:
Данная команда позволяет выполнить команду в выполняющемся контейнере:
Такая команда позволяет вывести список образов:
Итоги
Мы рассмотрели основы работы с технологией Docker Compose, знание которых позволит вам пользоваться этой технологией и, при желании, приступить к её более глубокому изучению. Вот репозиторий с кодом проекта, который мы здесь рассматривали.
Уважаемые читатели! Пользуетесь ли вы Docker Compose в своих проектах?