Создание окружения для веб-разработки на основе 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.
Docker.IO (https://www.docker.com/)
fig (http://www.fig.sh)
DNSMasq (http://www.thekelleys.org.uk/dnsmasq/doc.html)
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, которую кладем в папку с проектом. В этой папке уже есть: logs — директория для логов веб-сервера
xd_profile, xd_trace — две директории для файлов XDebug
db — директория для работы с базами данных с двумя скриптами для деплоя и бекапа
efig.yml — конфиг для fig
efig.conf — конфиг самого efig
httpd.conf — конфиг apache2
efig.sh — сам скрипт efig для работы
В efig.yml нужно указать название базы данных, имя пользователя для базы данных и пароль. Если нужно, то и базу данных для тестов. Для того, база данных корректно разворачивалась и дампилась обратно следует указать как связаны названия баз данных с файлами с дампами.E_DB_DUMP
имя файла для основной базы данных
E_DB_NAME
имя основной базы данных
E_DB_TEST_DUMP
имя файла тестовой базы данных
E_DB_TEST_NAME
имя тестовой базы данных
Если тестовая база данных не нужна, то две последние строки можем комментировать и убрать имя тестовой базы данных из переменной DB_NAME. Файлы с дампами будут искаться относительно папки db.httpd.conf конфигурируем для своего приложения.В efig.conf указываются следующие значенияPROJECT_NAME
название проекта (будет использовано в URL)
FIG_CONF
имя конфига для fig
SUBDOMAINS_ENABLED
нужно ли создавать поддомены для каждого контейнера
DNS_ZONE
DNS зона для проектов, изначально используется .doc
MAIN_CONTAINER_NAME
имя главного контейнера, изначально web (берем с fig-конфига)
DB_CONTAINER_NAME
имя контейнера ДБ, изначально db (берем с fig-конфига)
DNSMASQ_CONFIG_PATH
путь к конфигу DNSMasq
Дополнение к SUBDOMAINS_ENABLED
Например, чтобы к контейнеру БД можно было обращаться по доменному имени (например, http://db.myproject.doc/, а не по IP, который постоянно будет изменять при каждом запуске).
Для того, чтобы взлететь, нужно перейти в папку .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, которую легко развернуть и она сама сгенерирует БД): Клонируем репоз efig с гитхаба Тянем архив Joomla CMS Распаковываем Копируем .efig в папку с Joomla CMS Указываем в .efig/efig.yml параметры для БД Запускаем это дело cd .efig/ && sudo bash ./efig.sh Радуемся жизни Смотрим/устанавливаем Останавливаем-удаляем cd .efig/ && sudo bash ./efig.sh rm Как минимум, это писалось для себя чтобы умпростить разворачивание приложений хотя бы для того, чтобы запустить. Не знаю как кого, но меня утруждает создавать где-то новый поддомен и выливать туда файлы или использовать подпапки для разных проектов. К тому же хотелось иметь все 4 версии PHP. По мере запросов и своих потребностей я буду допиливать то, что уже есть. Планирую прикрутить поддержуй PostgreSQL, но поскольку сам его пока не использую, то и не прикручивал. Скрипт обкатывался на Ubuntu OS, но я не думаю, что на других Linux-дистрибутивах должны возникнуть проблемы. Проверить на других дистрибутивах возможности не было. Репозиторий проекта на GitHub: https://github.com/dvapelnik/efig Репозиторий образов для Docker на GitHub: https://github.com/dvapelnik/docker-lap Репозиторий образов для Docker на DockerHub: https://registry.hub.docker.com/u/dvapelnik/docker-lap/ Если дампа базы нет и база генерируется сама (миграции, разворачивание как у Joomla CSM, прочее), то при отключении контейнеров база сдампится, но сдампится она под пользователем root. Это вызвано тем, что в контейнереми дампим фактически под рутов контейнера. Можно перед запуском создать пустой файл, в который будет сдамплена БД при выключении — вот такой workaroud. Аналогичная ситуация с веб-контейнерами. Если монтировать в контейнер папку, то все файлы, которые будут создаваться из контейнера, будут созданы рутом. Описываю workaround, который использовал я: в контейнере создается пользователь donkey с таким UID и GID, как у моего пользователя, под которым я буду вести разработку. Он у меня равен 1000. Если UID і GID вашего пользователя отличается от 1000, то нужно взять соответствующий Dockerfile и заменить там UID и GID этого пользователя и пересобрать образ. Для э образов баз данных это не особо критично, но при дампе это вылезает боком. Потому такой костыль. Возникает резонный вопрос: как добраться до базы данных внутри контейнера? Логично и именно для этого я сделал опцию для создания доменных имен всем контейнерам SUBDOMAINS_ENABLED. Если флаг установлен 1, то для всех контейнеров будет создано по записи в конфиге DNSMasq в виде http://CONTAINER_NAME.PROJECT_NAME.DNS_ZONE. Контейнер выплевывает наружу порт для доступа к базам и к ним можно добраться, используя этот домен, порт и данные о пользователе, которые были прописаны в efig.conf
