Comments 23
Громко во вступлении. Банально по факту.
Ну то есть это же просто сборка контейнеров, которые есть для каждой известной cms/cmf, в частности и для друпала.
Должно ли это выглядеть высокопарно как «open source инициатива», или просто «смотрите, пацаны, че сделал — на докере»? yet another drupal docker кароч.
Ну то есть это же просто сборка контейнеров, которые есть для каждой известной cms/cmf, в частности и для друпала.
Должно ли это выглядеть высокопарно как «open source инициатива», или просто «смотрите, пацаны, че сделал — на докере»? yet another drupal docker кароч.
А вы пробовали использовать официальный контейнер для друпала? https://hub.docker.com/_/drupal/ он ведь не пригоден для разработки, собран чисто для демонстрации функций самой CMF. Или вы про что-то другое?
Мы не пишем «смотрите, пацаны, че сделал — на докере» потому что мы (инициаторы проекта) профессионально занимаемся контейнерной инфраструктурой с большим упором на друпал и регулярно выпускаем новые версии бандлов. Также, начало инициативы связано с тем, что вышла публичная бета докера (1.12) под мак и винду (больше нет тормозного vboxfs под капотом), с которой уже можно нормально работать.
Мы не пишем «смотрите, пацаны, че сделал — на докере» потому что мы (инициаторы проекта) профессионально занимаемся контейнерной инфраструктурой с большим упором на друпал и регулярно выпускаем новые версии бандлов. Также, начало инициативы связано с тем, что вышла публичная бета докера (1.12) под мак и винду (больше нет тормозного vboxfs под капотом), с которой уже можно нормально работать.
Возьмите докер для разработки и потом страдайте от того, что это не нормальная виртуалка. Разработчику нужен какой-то инструмент? Пусть страдает или выпрашивает его у администратора. К тому же разность подходов на разных платформах еще и веселые баги создает
Сразу возникает несколько вопросов:
- А зачем нужна нормальная виртуалка для локальной разработки?
- Если администратор все таки подгонит какой-то инструмент, то что это будет? Предложите вашу альтернативу
- Можно подробнее про веселые баги на разных платформах? Вдруг мы знаем решение
- Суть в том, что, например, при помощи Vagrant можно решить проблемы централизированного обновления требований к окружению разработки (установить новые пакеты, удалить старые и прочее), а так же позволить разработчикам ставить свой софт для разработки, который им нужен. Docker контейнеры лишают их такой возможности (про docker commit я знаю, но мержить твой контейнер с тем, который обновил администратор docker еще не умеет).
- Возможно, Вы меня не так поняли. Я имел ввиду такую ситуацию, когда разработчику нужен отдельный инструмент для разработки, которым он привык пользоватся. Например, ему нужен ipdb или vim, или, возможно, pyflakes. В том время как другим разработчикам оно не нужно совсем. Ему их каждый раз ставить, когда приходят обновления?
- Единственный баг, который я так и не смог решить — это то, что docker-machine на Mac OS игнорирует ключ --insecure-registry. Приходится прописывать их вручную. Так же, было несколько неочевидностей в поведении, скажем, то, что docker-machine прокидывает только папку пользователя по умолчанию, и другие нужно прокидывать вручную.
1. Централизованное обновление окружения – это как раз один из основных плюсов докера. Если нужен какой-то дополнительный софт, то достаточно создать новый образ на докер хабе, отнаследоваться от нашего и в своем добавить все, что нужно. При обновлении нашего образа, нужно просто пересобрать свой образ, чтобы применилась последняя версия.
2. У нас в качестве базовой ОС стоит легковесный альпайн линукс с бизибоксом, поставить какую-то дополнительную тулзу это обычно несколько килобайт. Памяти она жрать не будет, пусть лежит себе в образе, кому надо тот и пользуется. В вагранте, я так понимаю, все то же самое. Ну и, стандартизация, товарищ, стандартизация в команде разработчиков – это неотъемлемая часть процесса.
3. Тут помочь не смогу, в нашем подходе с новым докером (1.12) никакой докер машин не нужен.
2. У нас в качестве базовой ОС стоит легковесный альпайн линукс с бизибоксом, поставить какую-то дополнительную тулзу это обычно несколько килобайт. Памяти она жрать не будет, пусть лежит себе в образе, кому надо тот и пользуется. В вагранте, я так понимаю, все то же самое. Ну и, стандартизация, товарищ, стандартизация в команде разработчиков – это неотъемлемая часть процесса.
3. Тут помочь не смогу, в нашем подходе с новым докером (1.12) никакой докер машин не нужен.
2. Все зависит от компании. Если компания хочет прогнуть разработчиков под себя и заставить использовать только определенные инструменты деббагинга, статического анализа кода и прочего, что не имеет отношения к разработке, то это выглядит дико.
Так же, обычно докер образами управляют не разработчики, а администраторы, у которых нужно будет долго выбивать себе возможность добавить в рабочий контейнер необходимый софт.
Главное отличие Vagrant от docker в том, что Vagrant просто позволяет конфигурироват виртуальные машины, а не создает дополнительную сущность. Так же, при обновлении рабочего окружения достаточно сделать vagrant provision, а не перекачивать докер образ и терять все локальные изменения.
3. Напомню вам про статус «Beta». На win10 этот докер запускается не с первого раза по таинственной для меня причине.
Так же, обычно докер образами управляют не разработчики, а администраторы, у которых нужно будет долго выбивать себе возможность добавить в рабочий контейнер необходимый софт.
Главное отличие Vagrant от docker в том, что Vagrant просто позволяет конфигурироват виртуальные машины, а не создает дополнительную сущность. Так же, при обновлении рабочего окружения достаточно сделать vagrant provision, а не перекачивать докер образ и терять все локальные изменения.
3. Напомню вам про статус «Beta». На win10 этот докер запускается не с первого раза по таинственной для меня причине.
Так же, при обновлении рабочего окружения достаточно сделать vagrant provision, а не перекачивать докер образ и терять все локальные изменения.Локальные изменения можно оформить ввиде баш скрипта и запускать после каждого обновления. Или просто сделать свой образ и унаследовать его от «официального».
Для разработки любых php-проектов, в том числе и друпал я, например, создал образ andyceo/phpdevenv
Поднимаешь, стучишься по ssh — и у тебя готовая почти полноценная виртуалка. «Почти» потому, что вместо процесса init, который используется в Linux для старта ядра и управления всеми остальными процессами, здесь используется supervisord. Поэтому не работают команды
По поводу compose-файла. Для управления контейнерами я использую Ansible вместо compose, потому что compose не может создать нужные папки, файлы с нужными правами (в которых лежат кастомные настройки для Nginx, например) ДО старта контейнеров. Поэтому у меня есть Ansible-роль configurator, которая управляет папками и файлами, и после нее выполняется роль docker, которая поднимает контейнеры. Эта роль в плане управления контейнерами почти как compose, с той разницей, что может еще и установить докер, и compose, и создать пользовательскую docker-сетку (надеюсь, вы уже не линкуете контейнеры через link, а используете встроенный в докер dns?)
И да, я бы тоже не назвал свою работу «open-source инициативой» :)
Поднимаешь, стучишься по ssh — и у тебя готовая почти полноценная виртуалка. «Почти» потому, что вместо процесса init, который используется в Linux для старта ядра и управления всеми остальными процессами, здесь используется supervisord. Поэтому не работают команды
sudo service restart nginxsupervisorctl restart nginxПо поводу compose-файла. Для управления контейнерами я использую Ansible вместо compose, потому что compose не может создать нужные папки, файлы с нужными правами (в которых лежат кастомные настройки для Nginx, например) ДО старта контейнеров. Поэтому у меня есть Ansible-роль configurator, которая управляет папками и файлами, и после нее выполняется роль docker, которая поднимает контейнеры. Эта роль в плане управления контейнерами почти как compose, с той разницей, что может еще и установить докер, и compose, и создать пользовательскую docker-сетку (надеюсь, вы уже не линкуете контейнеры через link, а используете встроенный в докер dns?)
И да, я бы тоже не назвал свою работу «open-source инициативой» :)
PS: Забыл дописать. В моей роли docker есть примеры с преднастроенными контейнерами. Вот пример для Nginx:
Как видно, синтаксис почти совместим с compose, и можно с минимальными правками поднимать контейнеры compose'ом вместо Ansible.
# 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.
Докер можно использовать по разному и это хорошо. Можно положить все компоненты в один контейнер, а можно собирать из отдельных модулей с помощью docker-compose, например.
На мой взгляд, модульный подход более перспективный. Он позволяет обновлять и деплоить компоненты независимо, использовать компоненты сторонних разработчиков, гибко менять конфигурацию. Также позволяет держать каждый компонент максимально простым.
Ansible это хорошо, но это дополнительный компонент со всеми вытекающими. Да, в случае с docker-compose при подключении внешних конфигов бывают неудобства с несовпадением User ID в контейнере и на хост машине, но это решается через chown, chmod (или аналоги).
В docker4drupal зашиты все необходимые конфиги для того чтобы можно было поднять окружение для Drupal одной командой:
Если конфиг надо переопределить, то он просто подключается через volume.
Добавьте документацию и можете назвать «open-source инициативой» — почему бы и нет.
Нет, link не используем.
На мой взгляд, модульный подход более перспективный. Он позволяет обновлять и деплоить компоненты независимо, использовать компоненты сторонних разработчиков, гибко менять конфигурацию. Также позволяет держать каждый компонент максимально простым.
Ansible это хорошо, но это дополнительный компонент со всеми вытекающими. Да, в случае с docker-compose при подключении внешних конфигов бывают неудобства с несовпадением User ID в контейнере и на хост машине, но это решается через chown, chmod (или аналоги).
В docker4drupal зашиты все необходимые конфиги для того чтобы можно было поднять окружение для Drupal одной командой:
docker-compose up -d
Если конфиг надо переопределить, то он просто подключается через volume.
И да, я бы тоже не назвал свою работу «open-source инициативой»
Добавьте документацию и можете назвать «open-source инициативой» — почему бы и нет.
надеюсь, вы уже не линкуете контейнеры через link, а используете встроенный в докер dns?
Нет, link не используем.
Ansible это хорошо, но это дополнительный компонент со всеми вытекающими.
Если вам надо админить несколько разработческих машин, машины тестировщиков и еще и прод, то Ansible или аналоги необходимы, если не хотите делать все руками. А раз он все равно нужен, то почему бы его и не использовать?
Кстати, compose научился создавать контейнеры на разных хостах и связывать их в одну сетку? А ансиблом эта задача решается, можно сказать, «из коробки».
Да, в случае с docker-compose при подключении внешних конфигов бывают неудобства с несовпадением User ID в контейнере и на хост машине, но это решается через chown, chmod (или аналоги).
Вот тут не понял. Значит надо ДО волшебной команды docker-compose up -d все-таки что-то сделать руками? Ну тогда опять же, Ansible рулит.
Не хочу продвигать этот Ансибл, но он реально позволяет сделать жизнь проще. Как и Докер. Для каждой задачи — свой инструмент.
Если машин несколько, то держите свой образ под каждый проект. В случае с модульным подходом, прийдется кастомизировать только один из модулей, скорее всего nginx. Либо, чтобы не плодить докер образы, оформите нужный конфиг в виде переменной окружения.
Кладите композ файл в корень проекта и, вот, ваша инфрастукра под контролем версий. Понятно, что конфиги специфичные для окружения (пароли, ключи) должны лежить отдельно. Скорее всего, они должны передаваться через окружение либо, через подмонтированные файлы.
Как именно, эти данные передаются и где хранятся, зависит от того чем и куда вы деплоите. В kubernetes, например, для этого есть специальная сущность secret.
Если вы решаете эту задачу через Ansible — не проблема. Тут каждый сам себе выбирает подходящее решение.
По поводу деплоя на несколько машин. Это решается через docker-swarm, kubernetes и пр. На мой взгляд, kubernetes пока очивидный лидер в этом сегменте.
Я не против Ansible, но, на мой взгляд, это тупиковый путь, потому что требует держать в контейнере как минимум 2 процесса. Например, php и sshd (поправьте меня, если это не так).
Это не проблема и даже есть отличный тулзы для запуска нескольких процессов, например, s6-overlay. Но это не вписывается в бест практис 1 контейнер = 1 процесс.
Кладите композ файл в корень проекта и, вот, ваша инфрастукра под контролем версий. Понятно, что конфиги специфичные для окружения (пароли, ключи) должны лежить отдельно. Скорее всего, они должны передаваться через окружение либо, через подмонтированные файлы.
Как именно, эти данные передаются и где хранятся, зависит от того чем и куда вы деплоите. В kubernetes, например, для этого есть специальная сущность secret.
Если вы решаете эту задачу через Ansible — не проблема. Тут каждый сам себе выбирает подходящее решение.
По поводу деплоя на несколько машин. Это решается через docker-swarm, kubernetes и пр. На мой взгляд, kubernetes пока очивидный лидер в этом сегменте.
Я не против Ansible, но, на мой взгляд, это тупиковый путь, потому что требует держать в контейнере как минимум 2 процесса. Например, php и sshd (поправьте меня, если это не так).
Это не проблема и даже есть отличный тулзы для запуска нескольких процессов, например, s6-overlay. Но это не вписывается в бест практис 1 контейнер = 1 процесс.
Я не против Ansible, но, на мой взгляд, это тупиковый путь, потому что требует держать в контейнере как минимум 2 процесса. Например, php и sshd (поправьте меня, если это не так
sshd был нужен, но теперь благодаря Ansible-container не нужен.
php не был нужен никогда, нужен python — но почти в любой Linux-системе установлен по умолчанию. Вкратце, Ansible работает так: видит таск, генерирует python-скрипт на этот таск и заливает на удаленную машину, затем там его выполняет. Но может и напрямую выполнить любую shell-команду, см. raw module.
Но это не вписывается в бест практис 1 контейнер = 1 процесс.
Ну, не хочу холиворить, но все-таки бест практис или нет, сильно зависит от задачи. Посмотрите например на официальный докер-образ Gitlab. Очень здорово сделали, что упаковали все в один контейнер, и теперь я могу поднять этого монстра одной командой. Если бы все было в разных контейнерах, настройка и установка всего этого было бы таким же адом, как и установка в систему через пакеты.
Да и свой phpdevenv мне нравится — все что надо у разработчика есть. Один процесс в контейнере или несколько — не имеет значения, докер заточен для упаковки и доставки приложений (или если угодно сервисов), и если сервису надо несколько процессов, то пусть так и будет.
Да, я знаю про монолит от Gitlab, но в этом ничего хорошего нет. Этот пример гораздо лучше и его можно скейлить горизонтально в кластере, чего нельзя сказать про монолит.
Докер официально мигрирует на Alpine. Размер чистого альпайна 6 мегабайт. Естественно, что там нет python по умолчанию. Сравните кстати, размер своего образа и образ на альпайне.
Ок, но всем бы я рекомендовать такой подход не стал. Разработчикам много чего бывает нужно. PHP 5.3, 5.6, 7 — не так уж и просто засунуть их в один контейнер. А PHP либы разных версий? Всякие SAS, Less, Compas — они большие и в них легко нарваться на конфликт версий в гемах. И т.д.
Не соглашусь. Есть продукт и есть идеология в соответсвии с которой он пилится. Если использовать продукт не в соответствии с идеологией, то рано или поздно упрешься в ограничения. Потомучто продукт все дальше уходил в свою сторону, а ты остался на месте или шел в свою. Про некоторые ограничения монолитного подхода я уже писал.
Это хорошо, но есть вопросы. Что если контейнер рестартанули? — обычное дело для контейнера. Как Ansible узнает что надо прогрузить конфиги на определенный контейнер?
В Kubernetes, например, с контейнерами дело иметь практически не приходится. Он все делает сам, а работа ведется через абстракции. А если вы еще включите автоскейл по нагрузке, то Ansible точно не поможет. Контейнеры буду создаваться, удаляться, перемещаться с одной хост машины на другую и т.д.
А если сервер неожиданно ушел в ребут, сколько времени уйдет на то чтобы зайти в каждый контейнер и применить там конфиги? Кто вообще поймет что конфиги надо применять? А если на сервер 200 контейнеров (что кстати совсем не много)?
Итого, мне видится что монолиты на докере и оркестрация через Ansible это решение пригодное для конкретного случая, но рекомендовать его использовать повсеместно я бы не стал.
Несмотря на то что Ansible хорош при традиционном подходе к администрированию серверов, у меня складывается ощущение что он умирает или его рост замедляется, потомучто он не укладывается в тренд с докером. То что они сделали для оркестрации контейнеров, это попытка сесть в уходящий поезд. Лично у меня она не вызывает доверия из-за своих очевидных недостатков.
Естественно, я могу ошибаться. Поживем — увидим :)
но почти в любой Linux-системе установлен по умолчанию
Докер официально мигрирует на Alpine. Размер чистого альпайна 6 мегабайт. Естественно, что там нет python по умолчанию. Сравните кстати, размер своего образа и образ на альпайне.
Да и свой phpdevenv мне нравится — все что надо у разработчика есть
Ок, но всем бы я рекомендовать такой подход не стал. Разработчикам много чего бывает нужно. PHP 5.3, 5.6, 7 — не так уж и просто засунуть их в один контейнер. А PHP либы разных версий? Всякие SAS, Less, Compas — они большие и в них легко нарваться на конфликт версий в гемах. И т.д.
Один процесс в контейнере или несколько — не имеет значения
Не соглашусь. Есть продукт и есть идеология в соответсвии с которой он пилится. Если использовать продукт не в соответствии с идеологией, то рано или поздно упрешься в ограничения. Потомучто продукт все дальше уходил в свою сторону, а ты остался на месте или шел в свою. Про некоторые ограничения монолитного подхода я уже писал.
благодаря Ansible-container не нужен
Это хорошо, но есть вопросы. Что если контейнер рестартанули? — обычное дело для контейнера. Как Ansible узнает что надо прогрузить конфиги на определенный контейнер?
В Kubernetes, например, с контейнерами дело иметь практически не приходится. Он все делает сам, а работа ведется через абстракции. А если вы еще включите автоскейл по нагрузке, то Ansible точно не поможет. Контейнеры буду создаваться, удаляться, перемещаться с одной хост машины на другую и т.д.
А если сервер неожиданно ушел в ребут, сколько времени уйдет на то чтобы зайти в каждый контейнер и применить там конфиги? Кто вообще поймет что конфиги надо применять? А если на сервер 200 контейнеров (что кстати совсем не много)?
Итого, мне видится что монолиты на докере и оркестрация через Ansible это решение пригодное для конкретного случая, но рекомендовать его использовать повсеместно я бы не стал.
Несмотря на то что Ansible хорош при традиционном подходе к администрированию серверов, у меня складывается ощущение что он умирает или его рост замедляется, потомучто он не укладывается в тренд с докером. То что они сделали для оркестрации контейнеров, это попытка сесть в уходящий поезд. Лично у меня она не вызывает доверия из-за своих очевидных недостатков.
Естественно, я могу ошибаться. Поживем — увидим :)
А если нужно несколько сайтов запустить?
Нужно поправить порты в композ файле под разные сайты, например для первого это будет 800(0/1/2/3), для второго 801(0/1/2/3) и т.д. Ну или во время переключения между проектами тушить один композ файл и запускать другой, для локальной разработки не очень критично
Но это не вписывается в бест практис 1 контейнер = 1 процесс
я думаю, что не стоит воспринимать это выражение буквально. Например, nginx и php-fpm у вас работают через сокеты, как в таком случае вы будете разносить их в разные контейнеры — named volumes, linked containers? Мне кажется тут все будет зависить от самой задачи и окружения
Так они уже разнесены, вот репозитории:
PHP-FPM настроен на работу через TCP и слушает порт 9000.
- https://github.com/Wodby/drupal-php/tree/master/7.0
- https://github.com/Wodby/drupal-nginx
PHP-FPM настроен на работу через TCP и слушает порт 9000.
Sign up to leave a comment.
Open source инициатива Docker4Drupal.org