Правильный deploy Symfony2 проекта при наличии bower.json и grunt?

Question

[igormukhin]

Здравствуйте!

Есть проект на Symfony2/PHP, в нем используются Bower и Grunt для разработки front-end.

Разумеется, содержание bower_components и разные минифицированные Grunt-ом файлы (js, css) не попадают в репозиторий - ровно по той же причине, почему туда не попадает папка vendor и файлы вроде bootstrap.php.cache.

Но мы же не хотим на боевом сервере иметь зоопарк nodejs, npm, grunt, bower и т.д.? Нет.
Значит остается единственный вариант - отдельная машина-deployer, на которой будут установлены все наши nodejs-штуки. Она при появлении изменений в репозитории будет выкачивать их, собирать, компилировать/минифицировать все и только потом rsync-ом выкладывать все файлы на production-сервер, где нет никаких nodejs - только сугубо то, что нужно для работы приложения.

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

ЗЫЖ Сейчас все собирается на моей девелоперской машине (т.к. весь зоопарк установлен) и rsync-ом публикуется на сервер. Хочется чтобы делалось само по git push.

Answer 1

[Сергей Протько]

на CI-сервере делаем билд (tar.gz/deb/rpm) по git push и деплоим его. Для деплоя, коль уж вы rsync-ом пользуетесь. можно воспользоваться штуками типа капистрано/капифони.

p.s. рекомендую посмотреть в сторону vagrant + ansible для автоматизации управления инфраструктурой. Или вообще на docker.

Comments

[igormukhin]

Спасибо.

ЗЫ Я использую rsync как раз в процессе работы ansible-роли: https://github.com/ansible-roles/ansible-role-symf...

Docker было бы вообще замечательно - сразу готовые образы делать и на сервере просто делать pull. Это в перспективе :)

[wittyrider]

Сергей Протько Есть какой-то готовый роль для анзибла похожее на капистрано? и как быть с parameters.yml?

[Сергей Протько]

wittyrider: https://github.com/ansistrano/deploy

по поводу parameters.yml - я бы порекомендовал рассмотреть вариант с .env файликами и настройкой через параметры окружения (симфони это умеет). В противном случае вам надо просто генерить parameters.yml из шаблона.

[igormukhin]

wittyrider: Поскольку parameters.yml тоже в формате yml - они просто копируются в файл с настройками. Выглядит как-то так: https://github.com/ansible-roles/ansible-role-symf...

[wittyrider]

Сергей Протько: спасибо за ansistrano;
Сейчас использую вариант с шаблоном. Но этот подход мне не очень нравятся т.к. пароли нужно хранит на хосте.

[wittyrider]

igormukhin: 1 вопрос(не искал в гугле): Возможно ли средствами анзибла сделать так чтобы он спрашивал каждый пункт в parameters.yml только в том случае если parameters.yml еще не сушествеут?

[Сергей Протько]

igormukhin: это не ок подход, так как это все же разные yaml.

wittyrider: у меня все (инвентори, ключи, переменные) хранятся в gpg архиве подписанном моим публичным ключем (+ публичным ключем CI-ки). В итоге доступ только у меня и у того у кого есть доступ по ssh на ci сервер.

[igormukhin]

Сергей Протько: Файл не копируется. Копируются параметры с одного файла в другой - как показано по ссылке. И все очень ОК. Даже вот такие вложенные штуки отлично работают после копи-паста: https://github.com/Sylius/Sylius/blob/master/app/c...

wittyrider: Можно заранее какие-то параметры запрашивать: docs.ansible.com/ansible/playbooks_prompts.html. Если Вам нужно что-то вроде того, что делает https://github.com/Incenteev/ParameterHandler - можно попробовать придумать, но я считаю это плохой идеей - все должно быть прописано и не зависеть от человеческого фактора.

[Сергей Протько]

igormukhin: да я понимаю что все работает ОК, мне не нравится подход с файлами, он сложный. ENV для этого подходит куда лучше.

[wittyrider]

igormukhin: Я имел ввиду такой подход: анзибл проверяет deploy_vars.yml (на хосте!) если файл не существует то задает вопросы и генерит файл. если есть с этого файла берет переменные.
Насколько я понял по вашей ссылке vars_promt работает только на уровне плейбука и проверит файл(deploy_vars.yml) не получиться.

[Сергей Протько]

wittyrider: Почему не получится? А еще проще просто перезаписать переменные окружения)

[wittyrider]

Сергей Протько: vars_promt сработает прежде чем анзибл собирает факты. значит не получится проверит наличие файла(поправьте если я неправ).

Answer 2

[Константин]

У нас файлом /etc/project_name.yml заведует Puppet. Сам проект собирается на CI-сервере в deb-пакет (там же делается bower install, gulp build etc). В postinstall-скрипте пакета с сайтом написано что-то вроде

cp /etc/project_name.yml /var/www/project_name/app/config/parameters.yml

.
То есть, нужная конфигурация уже лежит на сервере и пакет при установке просто себе ее копирует. Если нужно добавить новый параметр в файл, то сначала правится json-файл в hiera соответствующего хоста, он раскатывается на фронты, а потом уже накатывается пакет с сайтом, требующий новый ключ конфига.
В том же postinstall выполняется скрипт проверки соответствия ключей в parameters.yml.dist и свежепоявившемся parameters.yml и если ключи расходятся, то установка считается неудачной (читай, как разработчики накосячили с конфигом, ситуация требует ручного вмешательства).
Ключевой пойнт в том, что ни разработчики, ни CI-сервер ничего не знают про параметры боевого сервера и ограничены свой областью ответственности.
Ну а Puppet и так "слишком много знает" об инфраструктуре, поэтому, ему этот файл доверять не страшно.