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

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


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.