Docker compose yml что это
Инструмент Docker Compose для начинающего разработчика
Сейчас читают:
Содержание:
Инструмент Docker Compose входит в комплект официального программного обеспечения для Docker. Он позволяет решать различные задачи, связанные с управлением одновременно несколькими контейнерами, составляющих в целом один проект.
Возможности Docker Compose
В процессе изучения основ Docker разработчики часто имеют дело с самыми простыми программами, способными запускаться в одном контейнере. Ведь, любой проект состоит из целого комплекта синхронно работающих приложений.
Самый очевидный пример – веб-сайт, где для авторизации пользователей необходимо подключение к базе данных. Для такого проекта нужно два сервиса – один отвечает за функционирование сайта, а другой за базу данных. Соответственно, разработчику понадобится средство, позволяющее управлять одновременно двумя контейнерами. И тут на помощь приходит Docker Compose, который позволяет включать два и более сервиса всего одной командой.
В этом и заключается разница между Docker и Docker Compose. Первый используется для работы с контейнерами по отдельности. Второй позволяет одновременно управлять несколькими контейнерами, а следовательно, работать с более сложными проектами.
Практика применения
Практуку использования Docker Compose можно рассмотреть на примере веб-проекта, состоящего из двух сайтов. Первый позволяет создать интернет-магазин буквально за несколько кликов мышью. Второй служит для поддержки клиентов. Оба сайта подключены к общей базе данных.
Допустим, по мере развития проекта становится понятно, что мощностей текущего сервера уже недостаточно. Принимается решение перенести сайты на новый сервер. Без Docker Compose придется переносить и настраивать все сервисы заново. Тогда сама работа займет много времени. Кто же возникает вероятность что-нибудь забыть в процессе.
При помощи Docker Compose можно выполнить перенос сайтов при помощи всего нескольких команд. Потребуется лишь изменить некоторые настройки и перенести на другой сервер резервную копию баз данных.
Создание клиент-серверного приложения
Для примера приведен небольшой сайт (сервер) на Python, умеющий отображать файл с текстом. Запрос на него делает программа-клиент, тоже на Python. Когда файл с сервера будет получен, программа выведет текст из файла на экран.
Подразумевается, что разработчик знаком с основами Docker, у него уже произведена установка этой программы и локального веб-сервера для запуска тестируемого проекта.
Примечание. Этот проект создавался и тестировался на дистрибутивах Ubuntu и CentOS 7. Для выполнения всех приведенных ниже команд используется стандартный терминал Linux.
Разработка проекта
Создание основного каталога
Сборка тестируемого клиент-серверного приложения начинается с создания каталога проекта (в примере — «project»).
Компоненты каталога
Содержимое основного каталога проекта будет отображаться в следующем виде:
Работа с папкой server
Подготовка файлов сервера
Следует открыть каталог «server», чтобы создать в нем следующие файлы:
После создания трех упомянутых выше файлов, содержимое каталога «server» должно выглядеть так:
Работа с файлом server.py
Теперь нужно открыть файл «server.py» предпочитаемым текстовым редактором, чтобы добавить в него следующий код:
Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.
Работа с файлом index.html
Далее потребуется отредактировать index.html, добавив в него такое содержимое:
Работа с Dockerfile
Теперь следует произвести настройку файла Dockerfile. С помощью него будет организована среда выполнения для Python-сервера. В примере основой создаваемого контейнера будет официальный образ для запуска Python-приложений.
Ниже приведено содержимое файла:
Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.
Создание клиент-приложения
Можно приступать к разработке клиента. При создании клиент-приложения проекта будут одновременно использоваться основные возможности Docker.
Файлы клиента
Сначала следует открыть каталог «client» и создать в нем файлы:
После этих операций в каталоге client должны храниться следующие файлы:
Работа с файлом Python
Снова следует открыть текстовый редактор, чтобы добавить в client.py такой код:
Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.
Работа с файлом Dockerfile
Аналогично серверу, для клиент-приложения будет создан небольшой Dockerfile. Он будет формировать среду для работы клиента.
Ниже представлен его код:
Важно! При добавлении информации нужно обязательно сохранять форматирование, как дано в примере.
Работа с Docker Compose
На предыдущих этапах было создано два проекта – серверное и клиент-приложение. Оба они обладают своим файлом Dockerfile. До этого момента применялись только основной функционал Docker. Далее к работе будет подключен Docker Compose — потребуется отредактировать docker-compose.yml, созданный ранее.
В этом примере не стоит задача ознакомиться со всеми возможными командами, доступными для использования в docker-compose.yml. Основная цель – увидеть, как Docker Compose можно применить на практике.
Пример файла docker-compose.yml
Важно! При добавлении информации в файл docker-compose.yml нужно обязательно сохранять форматирование, данное в примере. Это прежде всего касается отступов перед блоками. Если это расстояние нарушить, будет выведена ошибка.
Создание готового образа
Когда docker-compose.yml получит требуемые для работы команды, останется выполнить сборку проекта. Она делается почти аналогично docker build.
Представленная ниже команда позволяет одновременно работать с двумя и более приложениями:
Если все сделано правильно, в терминале будет отображен следующий результат:
Тестирование проекта
Сборка проекта завершена и можно переходить к тестированию проекта. Для этого следует выполнить команду:
Она по сути соответствует команде docker run, используемой в Docker при работе с одним контейнером.
В окне терминала можно увидеть строку «Docker-Compose is magic!». Так клиентская программа сигнализирует, что выполнила запрос на вывод содержимого файла «index.html» серверной программе, после чего вторая передала информацию клиенту. Это значит, что проект успешно запущен и работает.
Аналогичный результат можно получить в окне браузера, после ввода соответствующего веб-адреса (не забыв указать порт 1234):
Дополнительная информация
Ниже приведены несколько часто используемых полезных команд Docker Compose.
Начни экономить на хостинге сейчас — 14 дней бесплатно!
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 рассмотрены вместе с основами 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 в своих проектах?
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 за дельные комментарии.