habrahabr

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

  • понедельник, 12 января 2015 г. в 02:11:06
http://habrahabr.ru/post/247547/

Под катом расскажу как я усовершенствовал автоматическое создание и разворачивание окружения для веб-разработки на основе 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 нужно указать название базы данных, имя пользователя для базы данных и пароль. Если нужно, то и базу данных для тестов. Для того, база данных корректно разворачивалась и дампилась обратно следует указать как связаны названия баз данных с файлами с дампами.
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, которую легко развернуть и она сама сгенерирует БД):
  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