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

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



В предыдущей статье http://ift.tt/1sypIKW я рассказывал как организовать быстрое разворачивание окружения для веб-разработки на основе 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://ift.tt/WstrdJ)


4. nsenter (http://ift.tt/1pEof26)

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

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

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

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

Для работы всего этого добра клонируем репозиторий http://ift.tt/1sj3nDi и ищем там папочку .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 нужно указать название базы данных, имя пользователя для базы данных и пароль. Если нужно, то и базу данных для тестов. Для того, база данных корректно разворачивалась и дампилась обратно следует указать как связаны названия баз данных с файлами с дампами.

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://ift.tt/1sj3peB, а не по 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, которую легко развернуть и она сама сгенерирует БД):

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: http://ift.tt/1sj3nDi


2. Репозиторий образов для Docker на GitHub: http://ift.tt/1ABYqpG


3. Репозиторий образов для Docker на DockerHub: http://ift.tt/1sj3nDk

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


2. Возникает резонный вопрос: как добраться до базы данных внутри контейнера? Логично и именно для этого я сделал опцию для создания доменных имен всем контейнерам SUBDOMAINS_ENABLED. Если флаг установлен 1, то для всех контейнеров будет создано по записи в конфиге DNSMasq в виде http://ift.tt/1ABYqpI. Контейнер выплевывает наружу порт для доступа к базам и к ним можно добраться, используя этот домен, порт и данные о пользователе, которые были прописаны в efig.conf

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.