Что использовать для PHP разработки? Vagrant, Ansible или Docker?

Question

[ettaluni]

Доброго дня! Никак не могу вкурить что использовать для проектов. У меня есть свой хост, отдельный, 16 потоков 16ГБ памяти. На нем Virtual Box в качестве средства виртуализации.
Проблема в том что чем больше я изучаю Docker, Vagrant, Системы конфигурации прихожу к выводу что это одно и тоже.
Ну докер может не может автоустановку.
Дак вот что же собственно юзать? Под разработку на MVC\Symfony, Lavarel? Под разработку на CMS, Bitrix, Wordpress и.т.п.
Для разработки на Node js? Подскажите.

Comments

[Ромзес Панагиотис]

А зачем вообще вы используете виртуализацию Vagrant/Docker?
Зачем на целевом хосте использовать VirtualBox? Почему не на хост машине?

[ettaluni]

Ромзес Панагиотис, У меня WIndows хост. Специально брался чтобы юзать программы которые ну никак в Linux. AMP должно быть LAMP, везде на хостинга Linux. Да и вообще я за чистоту и отказоустойчивость. Для каждого отдельно, если хост упадет я потом virtual box на коленке поднять смогу.

[FanatPHP]

У меня WIndows хост. Специально брался чтобы юзать программы

OMG.
Расходимся. Чувак ошибся сайтом, собирался написать на форум любителей жесткого садо-мазо, а случайно попал на тостер

[Ромзес Панагиотис]

ettaluni, так вопрос в том что использовать для разработки или же для развертывания ПО на сервере?
Если 2-е, то VirtualBox для этих целей не предназначен, по большому счету.

Специально брался чтобы юзать программы которые ну никак в Linux.

какие, например?

[ettaluni]

Ромзес Панагиотис,

вопрос в том что использовать для разработки

Вопрос больше про разработку, но вопрос и про второе. Нужно быстро разворачивать среду, поэтому нужна и система конфигураций.

[shurshur]

ettaluni, vagrant это про раскатывание виртуалок. Виртуалки это само по себе для задачи раскатывания всяких тестовых сайтов чересчур, а тут ещё виртуалки в виртуалке, зачем эти излишества?

Использовать docker и ansible полезно, если есть готовые почти не изменяющиеся разработки или если используемые наработки делаются для прода. Просто ради использования этих инструментов возиться не особо есть смысл. Зачастую проще на хосте делать git pull и запускать сборку скриптом. Конечно, очень много зависит от сложности и состава проекта, тут никогда нет универсальных рецептов.

Answer 1

[index0h]

Это зависит от того, что, куда и как вы будете диплоить.
По хорошему чем ближе окружения для разработки к продакшну - тем лучше.

Лично я работал со следующими связками:
- Vagrant + bash provisioning
Этот способ с самым низким погором вхождения, но он очень требователен к качеству кода И процесса установки и обновления.

- Vagrant + ansible provisioning
Этот способ по сути включает в себя bash provisioning, но в структуре ansible. Работая в команде будьте готовы к тому, что провизионирование далеко не у всех будет нормально работать и это будет источником вашей головной боли. Если базово подтянуть bash у сотрудников еще не вызовет вопросов, то с ansible это процесс будет сложнее.

- Docker
Чистый докер требует далеко не маленькой компетенции. В команде я бы настоятельно не рекомендовал его использовать без дополнительных обвязок. По сути вам прийдется сделать свой docker-compose.

- Docker + docker-compose
Считаю оптимальным решением для dev окружения при работе как в команде, так и без.

Comments

[ettaluni]

Спасибо за подробный ответ.

Это зависит от того, что, куда и как вы будете диплоить.
По хорошему чем ближе окружения для разработки к продакшну - тем лучше.

Я об этом и думал, для полного соответствия, каждому свой экземпляр.

- Docker + docker-compose
Считаю оптимальным решением для dev окружения при работе как в команде, так и без.

Но я пока не так хорошо изучил Docker, не знаю может ли он сразу несколько LAMP вариаций на одном хосте. Ну это про случай если много тасков и они все в разных проектах.

[Ромзес Панагиотис]

ettaluni,

Но я пока не так хорошо изучил Docker, не знаю может ли он сразу несколько LAMP вариаций на одном хосте.

каждый процесс (веб-сервер, СУБД, приложение и т.д.) - в свой контейнер.

[index0h]

Ромзес Панагиотис, Главное без фанатизма))
Пример 1: у вас есть N cron задач. Для каждого поднимать отдельный контейнер - довольно накладно. Вместо этого имеет смысл поднять cron прямо внутри контейнера и уже там ранить ваши задачи.
Пример 2: у вас есть N воркеров. Тут по аналогии, поднимать под каждый контейнер - идея так себе. Вместо этого лучше внутри контейнера поднять supervisor, который уже будет менеджить воркера.

[Ромзес Панагиотис]

index0h,
насчет примера 1 нет спору, а насчет 2-го есть некоторые вопросы:
Не изобретаем ли мы таким образом Docker Swarm?
Вообще, если воркеры работают в постоянном количестве и их жизненный цикл достаточно продолжительный, разве недостаточно просто запустить достаточное количество экземпляров каждый в своем контейнере?

[Dimonchik]

Докер онли

остальное в резюме такое себе

[index0h]

Ромзес Панагиотис,

разве недостаточно просто запустить достаточное количество экземпляров каждый в своем контейнере?

Согласитесь, несколько сотен запущенных процессов в одном контейнере и несколько сотен отдельных контейнеров с одим процессом внутри - несколько отличаются по ресурсам. Причем чем больше воркеров потребуется, тем острее вопрос.
Так же есть отличия в способе управления. Доверить php инженеру управление swarm кластером я бы побоялся. А вот предоставить доступ конкретно к супервизору - вполне нормальное решение.
Так же есть отличия в дебаге, согласитесь, упавший процесс легче дебажить, когда контейнер жив, чем когда контейнер дохнет вместе с ним.

[batyrmastyr]

index0h,
1) на хосте кидаете кроны каждого проекта в cron.d, в кронах docker exec container cmd.
2) вы предлагаете супервизор поверх другого супервизора (php-fpm, roadrunner и т.д.) или над “php serve.php”?
И дебажить на боевом отдельный процесс как-то так себе затея.

[index0h]

batyrmastyr,

1) на хосте кидаете кроны каждого проекта в cron.d, в кронах docker exec container cmd.

когда таких кронов несколько - не вопрос, когда их много - это не удобно, особенно, когда котейнеры поднимаются с опцией `--rm`. Релизный образ может занимать спокойно и 700 и 1000+мб. Это нагрузка по io, как на развертывании контейнера, так и на его сворачивании. Как по мне запустить внутри контейнера cron - на много дешевле.

2) вы предлагаете супервизор поверх другого супервизора (php-fpm, roadrunner и т.д.) или над “php serve.php”?

обычные cli воркера. Для web поднимать супервизором nginx + php-fpm - это не то, что бы плохая идея. Еще могут потребоваться агенты сторонних служб, что тоже вполне допустимо поднимать супервизором.

И дебажить на боевом отдельный процесс как-то так себе затея.

Дебаг в постоянном режиме на проде - это путь в никуда, безусловно.
Тем не менее, бывают ситации, когда это необходимо. Например в 4 утра я предпочту сделать проверку прямо на продакшне, полному циклу релиза, если есть такая возможность.

Answer 2

[Ромзес Панагиотис]

Для первичной настройки и поддержки актуального состояния используются системы управления конфигурациями.

Docker используют чаще для гарантии идентичности среды, как в продакшн. Т.е. локально ведется разработка, тестируется в Docker. Если тесты пройдены - можно выкатывать в продакшн. Можно развертывать вручную, конечно. Но лучше, когда используются системы CI/CD (Jenkins, Gitlab CI/CD, Github Actions и пр.)
В случае Docker такие системы на сборочной машине собирают приложение в контейнер Docker и загружают его в реестр Docker, а затем на целевой машине скачивается контейнер и запускается.
В Jenkins можно использовать тот же Ansible и для разворачивания проекта.

Разве не логичнее использовать Linux в качестве хост машины? Всякие VirtualBox не подходят для этих целей.
Ну и если сильно нужна Windows - установите ее в качестве гостевой ОС.
Вот для сравнения различные системы виртуализации:
https://wiki.openvz.org/Comparison

Comments

[ettaluni]

Спасибо, буду изучать все что ты описал.