Создание окружения для веб-разработки на основе Docker

Под катом расскажу как я усовершенствовал автоматическое создание и разворачивание окружения для веб-разработки на основе Docker, Fig, DNSMasq и nsenter. По сути, это разворачивание LAMP сервера и запись о нем в DNSMasq, но приоритетами является незасоренность хост-машины ненужным софтом типа web-, db-серверов на хост машине и минимальное количество команд для запуска

Предисловие

В предыдущей статье http://habrahabr.ru/post/236573/ я рассказывал как организовать быстрое разворачивание окружения для веб-разработки на основе VirtualBox, тогда же, более опытные хабрапользователи посоветовали мне посмотреть в сторону Docker. После этого я открыл ман и начал экспериментировать, собрав для себя три контейнера с разными версиями PHP (5.3, 5.4 и 5.5), которыми успешно и удобно пользовался. Было желание в будущем переписать bootstrap-скрипт на более вменяемом языке и как-то все это организовать да написать ман. Но, как всегда, руки к этому не доходили и, скорее всего, никогда бы не дошли если бы на кануне Рождества я случайно не удалил бы домашнюю директорию docker-а. Да, бывает. В итоге все было переписано, переорганизовано и выложено на GitHub.

Что нам потребуется?

1. Docker.IO (https://www.docker.com/)
2. fig (http://www.fig.sh)
3. DNSMasq (http://www.thekelleys.org.uk/dnsmasq/doc.html)
4. nsenter (https://github.com/jpetazzo/nsenter)

Что происходит?

При запуске через скрипт с помощью fig разворачиваются и линкуются все нужные контейнеры. После этого, если указан файл с дампом базы, дамп заливается в созданную БД в контейнере. Далее добавляются записи о контейнерах в конфиг DNSMasq и перезапускается демон.
При выключении с помощью скрипта база данных обратно дампится в файл, убираются записи из конфига DNSMasq и перезапускается демон.

Как это настроить?

Требуется минимальная настройка DNSMasq:

# cat /etc/dnsmasq.conf | grep -E -v '^(#.*)?$'
listen-address=127.0.0.1

Для работы всего этого добра клонируем репозиторий https://github.com/dvapelnik/efig и ищем там папочку .efig, которую кладем в папку с проектом. В этой папке уже есть:

1. logs — директория для логов веб-сервера
2. xd_profile, xd_trace — две директории для файлов XDebug
3. db — директория для работы с базами данных с двумя скриптами для деплоя и бекапа
4. efig.yml — конфиг для fig
5. efig.conf — конфиг самого efig
6. httpd.conf — конфиг apache2
7. efig.sh — сам скрипт efig для работы

В efig.yml нужно указать название базы данных, имя пользователя для базы данных и пароль. Если нужно, то и базу данных для тестов. Для того, база данных корректно разворачивалась и дампилась обратно следует указать как связаны названия баз данных с файлами с дампами.

Если тестовая база данных не нужна, то две последние строки можем комментировать и убрать имя тестовой базы данных из переменной DB_NAME. Файлы с дампами будут искаться относительно папки db.
httpd.conf конфигурируем для своего приложения.
В efig.conf указываются следующие значения

А теперь со всеми этими конфигами, папками и скриптами мы попробуем взлететь попробуем запустить

Для того, чтобы взлететь, нужно перейти в папку .efig и запустить скрипт через sudo:

sudo ./efig.sh

В это время запускаются контейнеры, разворачиваются БД, дописываются в /etc/dnsmasq.conf записи о новых контейнерах и перезапускается демон. После этого можем смело заходить по ссылочке в браузере http://project.doc/ и наблюдать свой проект уже в браузере.
Для того, чтобы отключить-удалить контейнеры и обратно забекапить базы пишем, находять в той же папке (.efig), следующее:

sudo ./efig.sh rm

Базы сдампятся обратно в файлы, контейнеры остановятся и удалятся — все чисто, как и задумывалось.

Какие образы необходимо использовать для контейнеров?

В качестве веб-контейнеров советую использовать образы, которые однообразно конфигурировались (на DockerHub доступны образы, основанные на Debian/Ubuntu с раными версиями PHP (5.3, 5.4, 5.5, 5.6)). Пакеты для PHP подбирались с учетом требованый YiiFramework (1, 2), При необходимости можно добавить и другие, необходимые для разработки, пакеты. В качетсве db-контейнеров я использую образ от sameersbn.

А попрактиковаться?

Можете попробовать развернуть, к примеру, ту же Joomla CMS (она первой пришла мне в голову как CMS, которую легко развернуть и она сама сгенерирует БД):

1. Клонируем репоз efig с гитхаба
2. Тянем архив Joomla CMS
3. Распаковываем
4. Копируем .efig в папку с Joomla CMS
5. Указываем в .efig/efig.yml параметры для БД
6. Запускаем это дело cd .efig/ && sudo bash ./efig.sh
7. Радуемся жизни Смотрим/устанавливаем
8. Останавливаем-удаляем cd .efig/ && sudo bash ./efig.sh rm

Прошлое, настоящее и будущее?

Как минимум, это писалось для себя чтобы умпростить разворачивание приложений хотя бы для того, чтобы запустить. Не знаю как кого, но меня утруждает создавать где-то новый поддомен и выливать туда файлы или использовать подпапки для разных проектов. К тому же хотелось иметь все 4 версии PHP. По мере запросов и своих потребностей я буду допиливать то, что уже есть. Планирую прикрутить поддержуй PostgreSQL, но поскольку сам его пока не использую, то и не прикручивал. Скрипт обкатывался на Ubuntu OS, но я не думаю, что на других Linux-дистрибутивах должны возникнуть проблемы. Проверить на других дистрибутивах возможности не было.

Ссылки?

1. Репозиторий проекта на GitHub: https://github.com/dvapelnik/efig
2. Репозиторий образов для Docker на GitHub: https://github.com/dvapelnik/docker-lap
3. Репозиторий образов для Docker на DockerHub: https://registry.hub.docker.com/u/dvapelnik/docker-lap/

Подводные камни?

1. Если дампа базы нет и база генерируется сама (миграции, разворачивание как у Joomla CSM, прочее), то при отключении контейнеров база сдампится, но сдампится она под пользователем root. Это вызвано тем, что в контейнереми дампим фактически под рутов контейнера. Можно перед запуском создать пустой файл, в который будет сдамплена БД при выключении — вот такой workaroud. Аналогичная ситуация с веб-контейнерами. Если монтировать в контейнер папку, то все файлы, которые будут создаваться из контейнера, будут созданы рутом. Описываю workaround, который использовал я: в контейнере создается пользователь donkey с таким UID и GID, как у моего пользователя, под которым я буду вести разработку. Он у меня равен 1000. Если UID і GID вашего пользователя отличается от 1000, то нужно взять соответствующий Dockerfile и заменить там UID и GID этого пользователя и пересобрать образ. Для э образов баз данных это не особо критично, но при дампе это вылезает боком. Потому такой костыль.
2. Возникает резонный вопрос: как добраться до базы данных внутри контейнера? Логично и именно для этого я сделал опцию для создания доменных имен всем контейнерам SUBDOMAINS_ENABLED. Если флаг установлен 1, то для всех контейнеров будет создано по записи в конфиге DNSMasq в виде http://CONTAINER_NAME.PROJECT_NAME.DNS_ZONE. Контейнер выплевыат наружу порт для доступа к базам и к ним можно добраться, используя этот домен, порт и данные о пользователе, которые были прописаны в efig.conf

Автор: dvapelnik

Источник