Уже можно твердо констатировать, что контейнеры и, в частности docker, стали стандартом де-факто для разработчиков. Можно еще спорить о применимости контейнеров в продакшене, но уже никто не спорит, что для локальной разработкой и dev инстансов Docker незаменим.
Именно поэтому мы решили раз и навсегда решить головную боль для друпал разработчиков начав open source инициативу Docker4Drupal.org. Тем более, что для друпала окружение довольно стандартизованное.
Собственно в чем заключается иницитива? Мы предоставляем docker compose файл, который содержит описание сервисов (контейнеров), преднастроенных для работы с Drupal (7 и 8 версий). При запуске compose файла (читайте полную инструкцию на сайте) скачиваются и стартуют контейнеры, необходимые для локальной разработки на Drupal. Используются публичные образы, по возможности официальные.
Выглядит все это примерно так:
Весь этот набор контейнеров мы называем bundle и планируем его регулярно обновлять.
Коротко что есть:
- Бандл можно настраивать изменяя compose файл, например опционально включить redis/memcached контейнеры чтобы использовать как хранилище кэша по умолчанию
- Можно поднять поисковую машину Apache Solr с админкой, которая популярна среди друпалистов
- Есть xdebug, composer и drush
- По умолчанию ставится phpMyAdmin
- Можно симпортровать базу при первоначальной развертке подложив файл(ы) с дампом в специальный volume для mariadb контейнера
- По умолчанию есть mailhog для перехвата и просмотра всех писем отправленных с локального окружения
- Можно менять версию PHP (5.6 или 7)
- Можно просматривать логи всех контейнеров сразу или по отдельности
Я не копирую сюда полную инструкцию, потому что мы ее обновляем и дополняем, актуальная версия всегда доступна на гитхабе.
Всех друпалистов агитирую подписываться на гитхаб репозиторий и репортить баги.
Комментарии (22)
SirEdvin
27.07.2016 12:08Возьмите докер для разработки и потом страдайте от того, что это не нормальная виртуалка. Разработчику нужен какой-то инструмент? Пусть страдает или выпрашивает его у администратора. К тому же разность подходов на разных платформах еще и веселые баги создает
wodby
27.07.2016 12:37Сразу возникает несколько вопросов:
- А зачем нужна нормальная виртуалка для локальной разработки?
- Если администратор все таки подгонит какой-то инструмент, то что это будет? Предложите вашу альтернативу
- Можно подробнее про веселые баги на разных платформах? Вдруг мы знаем решение
SirEdvin
27.07.2016 12:53- Суть в том, что, например, при помощи Vagrant можно решить проблемы централизированного обновления требований к окружению разработки (установить новые пакеты, удалить старые и прочее), а так же позволить разработчикам ставить свой софт для разработки, который им нужен. Docker контейнеры лишают их такой возможности (про docker commit я знаю, но мержить твой контейнер с тем, который обновил администратор docker еще не умеет).
- Возможно, Вы меня не так поняли. Я имел ввиду такую ситуацию, когда разработчику нужен отдельный инструмент для разработки, которым он привык пользоватся. Например, ему нужен ipdb или vim, или, возможно, pyflakes. В том время как другим разработчикам оно не нужно совсем. Ему их каждый раз ставить, когда приходят обновления?
- Единственный баг, который я так и не смог решить — это то, что docker-machine на Mac OS игнорирует ключ --insecure-registry. Приходится прописывать их вручную. Так же, было несколько неочевидностей в поведении, скажем, то, что docker-machine прокидывает только папку пользователя по умолчанию, и другие нужно прокидывать вручную.
wodby
27.07.2016 13:161. Централизованное обновление окружения – это как раз один из основных плюсов докера. Если нужен какой-то дополнительный софт, то достаточно создать новый образ на докер хабе, отнаследоваться от нашего и в своем добавить все, что нужно. При обновлении нашего образа, нужно просто пересобрать свой образ, чтобы применилась последняя версия.
2. У нас в качестве базовой ОС стоит легковесный альпайн линукс с бизибоксом, поставить какую-то дополнительную тулзу это обычно несколько килобайт. Памяти она жрать не будет, пусть лежит себе в образе, кому надо тот и пользуется. В вагранте, я так понимаю, все то же самое. Ну и, стандартизация, товарищ, стандартизация в команде разработчиков – это неотъемлемая часть процесса.
3. Тут помочь не смогу, в нашем подходе с новым докером (1.12) никакой докер машин не нужен.SirEdvin
27.07.2016 14:322. Все зависит от компании. Если компания хочет прогнуть разработчиков под себя и заставить использовать только определенные инструменты деббагинга, статического анализа кода и прочего, что не имеет отношения к разработке, то это выглядит дико.
Так же, обычно докер образами управляют не разработчики, а администраторы, у которых нужно будет долго выбивать себе возможность добавить в рабочий контейнер необходимый софт.
Главное отличие Vagrant от docker в том, что Vagrant просто позволяет конфигурироват виртуальные машины, а не создает дополнительную сущность. Так же, при обновлении рабочего окружения достаточно сделать vagrant provision, а не перекачивать докер образ и терять все локальные изменения.
3. Напомню вам про статус «Beta». На win10 этот докер запускается не с первого раза по таинственной для меня причине.
E_STRICT
27.07.2016 15:03Так же, при обновлении рабочего окружения достаточно сделать vagrant provision, а не перекачивать докер образ и терять все локальные изменения.
Локальные изменения можно оформить ввиде баш скрипта и запускать после каждого обновления. Или просто сделать свой образ и унаследовать его от «официального».
andyceo
27.07.2016 12:56Для разработки любых php-проектов, в том числе и друпал я, например, создал образ andyceo/phpdevenv
Поднимаешь, стучишься по ssh — и у тебя готовая почти полноценная виртуалка. «Почти» потому, что вместо процесса init, который используется в Linux для старта ядра и управления всеми остальными процессами, здесь используется supervisord. Поэтому не работают команды
например, а вместо них надо использоватьsudo service restart nginx
. Остальное все как в свежеустановленной Ubuntu на виртуалке.supervisorctl restart nginx
По поводу compose-файла. Для управления контейнерами я использую Ansible вместо compose, потому что compose не может создать нужные папки, файлы с нужными правами (в которых лежат кастомные настройки для Nginx, например) ДО старта контейнеров. Поэтому у меня есть Ansible-роль configurator, которая управляет папками и файлами, и после нее выполняется роль docker, которая поднимает контейнеры. Эта роль в плане управления контейнерами почти как compose, с той разницей, что может еще и установить докер, и compose, и создать пользовательскую docker-сетку (надеюсь, вы уже не линкуете контейнеры через link, а используете встроенный в докер dns?)
И да, я бы тоже не назвал свою работу «open-source инициативой» :)andyceo
27.07.2016 13:06PS: Забыл дописать. В моей роли docker есть примеры с преднастроенными контейнерами. Вот пример для Nginx:
# Nginx
# @see https://hub.docker.com/_/nginx/
# You should copy config files before create container!
# You should place virtual host configs in nginx/conf.d directory
- name: nginx
enabled: yes
image: nginx
tag: 1.10.1
state: started
hostname: nginx
detach: True
restart_policy: always
net: docknet
ports:
- 80:80
- 443:443
volumes:
- /data/ssl:/ssl:ro
- /data/nginx/htpasswds:/etc/nginx/htpasswds:ro
- /data/nginx/conf.d:/etc/nginx/conf.d:ro
- /data/nginx/fastcgi_params:/etc/nginx/fastcgi_params:ro
- /data/nginx/proxy_headers:/etc/nginx/proxy_headers:ro
- /data/nginx/proxy_params:/etc/nginx/proxy_params:ro
- /data/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- /data/nginx/default-content:/usr/share/nginx/html:ro
- /data/nginx/cache:/var/cache/nginx:rw
- /data/nginx/logs:/var/log/nginx:rw
Как видно, синтаксис почти совместим с compose, и можно с минимальными правками поднимать контейнеры compose'ом вместо Ansible.
PavelPrischepa
27.07.2016 13:45+1Докер можно использовать по разному и это хорошо. Можно положить все компоненты в один контейнер, а можно собирать из отдельных модулей с помощью docker-compose, например.
На мой взгляд, модульный подход более перспективный. Он позволяет обновлять и деплоить компоненты независимо, использовать компоненты сторонних разработчиков, гибко менять конфигурацию. Также позволяет держать каждый компонент максимально простым.
Ansible это хорошо, но это дополнительный компонент со всеми вытекающими. Да, в случае с docker-compose при подключении внешних конфигов бывают неудобства с несовпадением User ID в контейнере и на хост машине, но это решается через chown, chmod (или аналоги).
В docker4drupal зашиты все необходимые конфиги для того чтобы можно было поднять окружение для Drupal одной командой:
docker-compose up -d
Если конфиг надо переопределить, то он просто подключается через volume.
И да, я бы тоже не назвал свою работу «open-source инициативой»
Добавьте документацию и можете назвать «open-source инициативой» — почему бы и нет.
надеюсь, вы уже не линкуете контейнеры через link, а используете встроенный в докер dns?
Нет, link не используем.andyceo
27.07.2016 14:18Ansible это хорошо, но это дополнительный компонент со всеми вытекающими.
Если вам надо админить несколько разработческих машин, машины тестировщиков и еще и прод, то Ansible или аналоги необходимы, если не хотите делать все руками. А раз он все равно нужен, то почему бы его и не использовать?
Кстати, compose научился создавать контейнеры на разных хостах и связывать их в одну сетку? А ансиблом эта задача решается, можно сказать, «из коробки».
Да, в случае с docker-compose при подключении внешних конфигов бывают неудобства с несовпадением User ID в контейнере и на хост машине, но это решается через chown, chmod (или аналоги).
Вот тут не понял. Значит надо ДО волшебной команды docker-compose up -d все-таки что-то сделать руками? Ну тогда опять же, Ansible рулит.
Не хочу продвигать этот Ансибл, но он реально позволяет сделать жизнь проще. Как и Докер. Для каждой задачи — свой инструмент.PavelPrischepa
27.07.2016 14:59Если машин несколько, то держите свой образ под каждый проект. В случае с модульным подходом, прийдется кастомизировать только один из модулей, скорее всего nginx. Либо, чтобы не плодить докер образы, оформите нужный конфиг в виде переменной окружения.
Кладите композ файл в корень проекта и, вот, ваша инфрастукра под контролем версий. Понятно, что конфиги специфичные для окружения (пароли, ключи) должны лежить отдельно. Скорее всего, они должны передаваться через окружение либо, через подмонтированные файлы.
Как именно, эти данные передаются и где хранятся, зависит от того чем и куда вы деплоите. В kubernetes, например, для этого есть специальная сущность secret.
Если вы решаете эту задачу через Ansible — не проблема. Тут каждый сам себе выбирает подходящее решение.
По поводу деплоя на несколько машин. Это решается через docker-swarm, kubernetes и пр. На мой взгляд, kubernetes пока очивидный лидер в этом сегменте.
Я не против Ansible, но, на мой взгляд, это тупиковый путь, потому что требует держать в контейнере как минимум 2 процесса. Например, php и sshd (поправьте меня, если это не так).
Это не проблема и даже есть отличный тулзы для запуска нескольких процессов, например, s6-overlay. Но это не вписывается в бест практис 1 контейнер = 1 процесс.andyceo
27.07.2016 16:05Я не против Ansible, но, на мой взгляд, это тупиковый путь, потому что требует держать в контейнере как минимум 2 процесса. Например, php и sshd (поправьте меня, если это не так
sshd был нужен, но теперь благодаря Ansible-container не нужен.
php не был нужен никогда, нужен python — но почти в любой Linux-системе установлен по умолчанию. Вкратце, Ansible работает так: видит таск, генерирует python-скрипт на этот таск и заливает на удаленную машину, затем там его выполняет. Но может и напрямую выполнить любую shell-команду, см. raw module.
Но это не вписывается в бест практис 1 контейнер = 1 процесс.
Ну, не хочу холиворить, но все-таки бест практис или нет, сильно зависит от задачи. Посмотрите например на официальный докер-образ Gitlab. Очень здорово сделали, что упаковали все в один контейнер, и теперь я могу поднять этого монстра одной командой. Если бы все было в разных контейнерах, настройка и установка всего этого было бы таким же адом, как и установка в систему через пакеты.
Да и свой phpdevenv мне нравится — все что надо у разработчика есть. Один процесс в контейнере или несколько — не имеет значения, докер заточен для упаковки и доставки приложений (или если угодно сервисов), и если сервису надо несколько процессов, то пусть так и будет.PavelPrischepa
27.07.2016 18:43Да, я знаю про монолит от Gitlab, но в этом ничего хорошего нет. Этот пример гораздо лучше и его можно скейлить горизонтально в кластере, чего нельзя сказать про монолит.
но почти в любой Linux-системе установлен по умолчанию
Докер официально мигрирует на Alpine. Размер чистого альпайна 6 мегабайт. Естественно, что там нет python по умолчанию. Сравните кстати, размер своего образа и образ на альпайне.
Да и свой phpdevenv мне нравится — все что надо у разработчика есть
Ок, но всем бы я рекомендовать такой подход не стал. Разработчикам много чего бывает нужно. PHP 5.3, 5.6, 7 — не так уж и просто засунуть их в один контейнер. А PHP либы разных версий? Всякие SAS, Less, Compas — они большие и в них легко нарваться на конфликт версий в гемах. И т.д.
Один процесс в контейнере или несколько — не имеет значения
Не соглашусь. Есть продукт и есть идеология в соответсвии с которой он пилится. Если использовать продукт не в соответствии с идеологией, то рано или поздно упрешься в ограничения. Потомучто продукт все дальше уходил в свою сторону, а ты остался на месте или шел в свою. Про некоторые ограничения монолитного подхода я уже писал.
благодаря Ansible-container не нужен
Это хорошо, но есть вопросы. Что если контейнер рестартанули? — обычное дело для контейнера. Как Ansible узнает что надо прогрузить конфиги на определенный контейнер?
В Kubernetes, например, с контейнерами дело иметь практически не приходится. Он все делает сам, а работа ведется через абстракции. А если вы еще включите автоскейл по нагрузке, то Ansible точно не поможет. Контейнеры буду создаваться, удаляться, перемещаться с одной хост машины на другую и т.д.
А если сервер неожиданно ушел в ребут, сколько времени уйдет на то чтобы зайти в каждый контейнер и применить там конфиги? Кто вообще поймет что конфиги надо применять? А если на сервер 200 контейнеров (что кстати совсем не много)?
Итого, мне видится что монолиты на докере и оркестрация через Ansible это решение пригодное для конкретного случая, но рекомендовать его использовать повсеместно я бы не стал.
Несмотря на то что Ansible хорош при традиционном подходе к администрированию серверов, у меня складывается ощущение что он умирает или его рост замедляется, потомучто он не укладывается в тренд с докером. То что они сделали для оркестрации контейнеров, это попытка сесть в уходящий поезд. Лично у меня она не вызывает доверия из-за своих очевидных недостатков.
Естественно, я могу ошибаться. Поживем — увидим :)
Artima
28.07.2016 14:43А если нужно несколько сайтов запустить?
wodby
28.07.2016 14:55Нужно поправить порты в композ файле под разные сайты, например для первого это будет 800(0/1/2/3), для второго 801(0/1/2/3) и т.д. Ну или во время переключения между проектами тушить один композ файл и запускать другой, для локальной разработки не очень критично
Artima
29.07.2016 00:17Сложно. В этом плане хорош образ nginx-proxy. Он налету присоединяет новые контейнеры с нужным доменом, без необходимости ковыряться в конфигурации и шаманить с портами.
PavelPrischepa
29.07.2016 08:16Да, прокси желателен, особенно, когда требуется переключаться между несколькими проектами несколько раз в день. Какой прокси вы используете, если не секрет?
ALexhha
28.07.2016 15:05Но это не вписывается в бест практис 1 контейнер = 1 процесс
я думаю, что не стоит воспринимать это выражение буквально. Например, nginx и php-fpm у вас работают через сокеты, как в таком случае вы будете разносить их в разные контейнеры — named volumes, linked containers? Мне кажется тут все будет зависить от самой задачи и окружения
PavelPrischepa
28.07.2016 15:23Так они уже разнесены, вот репозитории:
- https://github.com/Wodby/drupal-php/tree/master/7.0
- https://github.com/Wodby/drupal-nginx
PHP-FPM настроен на работу через TCP и слушает порт 9000.
zelenin
Громко во вступлении. Банально по факту.
Ну то есть это же просто сборка контейнеров, которые есть для каждой известной cms/cmf, в частности и для друпала.
Должно ли это выглядеть высокопарно как «open source инициатива», или просто «смотрите, пацаны, че сделал — на докере»? yet another drupal docker кароч.
wodby
А вы пробовали использовать официальный контейнер для друпала? https://hub.docker.com/_/drupal/ он ведь не пригоден для разработки, собран чисто для демонстрации функций самой CMF. Или вы про что-то другое?
Мы не пишем «смотрите, пацаны, че сделал — на докере» потому что мы (инициаторы проекта) профессионально занимаемся контейнерной инфраструктурой с большим упором на друпал и регулярно выпускаем новые версии бандлов. Также, начало инициативы связано с тем, что вышла публичная бета докера (1.12) под мак и винду (больше нет тормозного vboxfs под капотом), с которой уже можно нормально работать.