что такое docker compose
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 — это средство, разработанное для помощи в определении и совместном использовании многоконтейнерных приложений. С помощью средства 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 Engine с 1.0 до 1.7. Введение в Docker Compose
Эти статьи были написаны по Docker 1.1.2. С тех пор в Docker появилось много полезного, о чем мы расскажем в этой статье. Также мы рассмотрим подробнее Docker Compose, утилиту, позволяющую определять мультиконтейнерное приложение со всеми зависимостями в одном файле и запускать это приложение в одну команду. Примеры будут продемонстрированы на облачном сервере в InfoboxCloud.
Установка Docker и Compose в InfoboxCloud
Мы рекомендуем создать виртуальную машину с CentOS 7 для установки Docker в InfoboxCloud. Использование CoreOS/Fedora Atomic/Ubuntu Snappy в продакшне пока слишком рисковано. Для работы Docker сейчас необходима именно виртуальная машина, поэтому при создании сервера обязательно установите галочку «Разрешить управление ядром ОС».
Если у вас еще нет доступа в InfoboxCloud – закажите его.
Использование облака очень удобно тем, что никакой абонентской платы нет. При регистрации вы единовременно пополняете счет минимум на 500 рублей (по аналогии с покупкой sim–карты у мобильного оператора) и далее можете использовать облако по необходимости. Быстро рассчитать сколько примерно будет стоить для вас облачный сервер в месяц можно тут (указывайте правильно размерности, например 2 гигагерца частоты, а не 2000 гигагерц). Оплата производится на почасовой основе и замораживается на вашем счету. Используя автомасштабирование или изменяя объем доступных ресурсов сервера вручную можно оплачивать только за необходимые ресурсы и дополнительно экономить и иметь возможность получить больше ресурсов, когда это необходимо.
После регистрации вы получите данные для доступа к панели управления на email. Войдите в панель управления по адресу: https://panel.infobox.ru
В разделе «Облачная инфраструктура» вашей подписки нажмите «Новый сервер» (при необходимости подписка меняется в правом верхнем углу в выпадающем меню).
Задайте необходимые параметры сервера. Обязательно выделите серверу 1 публичный IP–адрес и установите галочку «Разрешить управление ядром ОС», как показано на скриншоте ниже.
В списке доступных операционных систем выберите CentOS 7 и завершите создание сервера.
После этого данные для доступа к серверу придут к вам на электронную почту.
После создания сервера с CentOS 7 подключитесь к нему по SSH.
Мы подготовили скрипт, который позволит вам установить Docker и полезные утилиты для работы с Docker на такой сервер. Необходимые настройки будут выполнены автоматически.
Выполните команду для установки Docker и Compose:
Обновление Docker и Compose в InfoboxCloud
Для обновления выполните скрипт:
Новые возможности Docker с версии 1.0
В данном разделе мы не будем касаться исправления ошибок и улучшения архитектуры docker, а поговорим только об основных новых возможностях для пользователя. Это поможет обновить знания о возможностях Docker.
Раньше коммит для запущенных контейнеров не рекомендовался, т.к. его целостность при одновременной работе и коммите могла быть нарушена (например, если велась запись в процессе коммита). Теперь в момент коммита контейнеры ставятся на паузу.
Если вам нужно отключить эту возможность, используйте следующую команду:
Теперь вы можете выводить последние строки логов контейнера.
Раньше для просмотра логов использовалась команда, выводящая весь лог:
Теперь можно вывести например последние 10 строк лога командой:
Также вы можете следить за тем, что добавляется в лог сейчас без чтения всего лога:
Теперь в —volumes можно передать корень файловой системы хоста /.
Например:
Тем не менее запрещено монтировать файловую систему хоста в корень файловой системы контейнера /, можно только в какую-то папку в контейнере.
Раньше для каждого контейнера приходилось писать свой скрипт для запуска при загрузке системы. Теперь появилась возможность перезапускать контейнер с помощью Docker–сервиса.
Другой пример: если контейнер не штатно завершился а упал — 5 раз попробует подняться.
Например, для изменения статуса интерфейсов контейнера:
Для запрещения chown в контейнере:
Для разрешения всего кроме mknod:
Ранее вы могли использовать устройства внутри контейнеров, монтируя их с помощью -v в —privileged контейнере. Теперь можно с docker run использовать флаг —device, который позволит вам использовать устройство без флага —privileged.
Например, использование устройства внутри контейнера:
Теперь вы можете редактировать /etc/hosts, /etc/hostname, /etc/resolve.conf в запущенном контейнере. Это полезно, если вам нужно установить bind или другие сервисы, которые могут переписать эти файлы.
Заметьте, что изменения этих файлов не сохраняются в течении сборки контейнера и не будут представлены в результирующих образах. Изменения будут только проявляться в запущенных контейнерах.
Раньше для работы sshd (и не только) в контейнере приходилось запускать процесс sshd с работающим приложением, что создавало дополнительный риск и оверхед. Доступ к контейнеру очень важен для отладки. Поэтому была добавлена новая команда docker exec, которая позволяет пользователю запускать процесс внутри контейнера через docker api и CLI.
Например так выглядит команда, создающая bash–сессию внутри контейнера:
Основной рекомендуемый подход «одно приложение на контейнер» не изменился, но разработчики пошли навстречу пользователям, которые иногда нуждаются в служебных процессах для приложения.
Команда docker run image_name создает контейнер и запускает процесс в нем. Многие пользователи просили разделить эти задачи для более точного контроля за жизненным циклом контейнера. Команда docker create делает это возможным.
Например:
, создает слой контейнера и выводит ID контейнера, но не запускает его.
Для запуска выполните:
Таким образом команда docker create дает пользователю и/или процессу гибкость в использовании docker start и docker stop команд для управления жизненным циклом.
С этим релизом был добавлен новый флаг —security-opt, позволяющий пользователям настраивать произвольные метки и профили SELinux и AppArmor.
Например, ниже показана политика, позволяющая процессу контейнера слушать только порты Apache:
Одно из преимуществ этой функции в том, что теперь пользователи могут запускать контейнеры docker в контейнерах docker без использования привилегированного режима на ядрах, поддерживающих SELinux и AppArmor. Не давая контейнеру права —privileged вы существенно снижаете поверхность атаки потенциальных угроз.
Этот релиз включает в себя существенные улучшения в безопасности.
Теперь набор докер-утилит окончательно сформировался в отдельные Docker Engine, Registry, Compose, Swarm и Machine. О Compose рассказано в следующем разделе статьи. Об остальных утилитах будет рассказано в следующих статьях.
Когда вы скачиваете, строите или запускаете образы, вы можете указать их в форме namespace/repository:tag или просто repository. Теперь возможно скачивать, строить и запускать контейнеры по новому идентификатору, названному «дайджест» с синтаксисом: namespace/repo@digest. Дайджест — неизменяемая ссылка на контент внутри образа.
Отличный юзкейс для использования дайджестов — патчи и обновления. Если вы хотите выпустить обновление безопасности, вы можете указать дайджест образа с обновлением безопасности, гарантируя, что на сервер будет установлено это обновление.
До сих пор контейнеры наследовали настройки ulimit от демона докера. ulimit позволяет ограничить использование процесса. Ограничения могут быть очень высокими для производственных нагрузок, но не идеальными для контейнера. С новой опцией вы можете указывать настройки ulimit для всех контейнеров при настройке докер-демона, например:
Эта команда установит soft limit 1024 и hard limit в 2048 дочерних процессов для всех контейнеров. Можно использовать опцию многократно для разных параметров:
Эти настройки можно перегрузить при создании контейнера:
Этот релиз включает переписанные сетевую подсистему и подсистему томов, а так же повышение стабильности и драйвер ZFS.
Docker Compose
Распределенные приложения состоят как правило из нескольких небольших сервисов, которые работают вместе. Docker преобразует эти приложения в индивидуальные контейнеры и связывает вместе. Вместо построения, запуска и управления каждым контейнером, Docker Compose позволяет вам определять мультиконтейнерное приложение со всеми зависимостями в одном файле и запускать это приложение одной командой up. Хранение структуры и конфигурации приложения вместе позволяет просто и повторяемо запускать его везде.
docker-compose.yml
Файл docker-compose.yml содержит в себе правила развертывания приложений в docker.
Каждый сервис в docker–compose.yml должен включать как минимум один образ (image) или скрипт для сборки (build). Все остальные параметры опциональны по аналогии с параметрами команды docker run.
Как и в случае с docker run, опции, указанные в Dockerfile (такие как CMD, EXPOSE, VOLUME, ENV) выполняются по-умолчанию, нет необходимости повторять их в docker-compose.yml.
Список доступных параметров docker–compose.yml описан в официальной документации.
Давайте сразу перейдем от теории к практике и напишем docker-compose для apache с PHP и MySQL.
Допустим, мы создали сервер в InfoboxCloud и установили docker и compose с помощью одной команды, указанной в начале статьи. Теперь просто скопируем папку lamp с docker–compose.xml, папками сайта и базы данных и запустим команду
Поднимется стек LAMP и в нем уже будет работать наш сайт. Вот так просто! Хотите переместить сайт на другой сервер или развернуть на десяти серверах? Просто скопируйте папку LAMP на другой сервер и запустите docker–compose снова.
Таким образом, docker и compose позволяют вам упаковывать приложения и целые системы в подготовленные окружения и прописывать конфигурацию их развертывания. При этом развертывание происходит в одну команду и это может сделать даже неподготовленный пользователь. Развертывание даже сложных систем в InfoboxCloud (и вообще облака IaaS) происходит с простотой PaaS, но вы контролируете все аспекты работы инфраструктуры. Именно такой способ развертывания использует OnlyOffice
Если при повторном развертывании с compose вы встретились с ошибкой Duplicate bind mount
В этом случае посмотрите, какие контейнеры созданы. Для этого воспользуйтесь командой:
Вы увидите контейнер со странным именем кроме описанных в docker-compose.yml контейнеров. В данном случае имя «335698fa2d_lamp_db_1».
Удалите его командой:
, где 335698fa2d_lamp_db_1 замените на имя вашего контейнера со странным именем.
После этого compose выполнит переразвертывание успешно.
Заключение
В следующих статьях мы рассмотрим и другие полезные утилиты для Docker. Если вы нашли ошибку в статье или у вас есть вопрос, напишите нам в ЛС или на email. Если вы не можете оставлять комментарии на Хабре — напишите в Сообществе.