Пролог
Во время разработки мы стараемся автоматизировать как можно больше рутинных вещей, таких как проверка стиля кода, прогон тестов, разворачивание рабочей среды, и прочих. Одним из самых важных пунктов в этом списке является деплой, показывающий миру результат нашей работы. О том, какое решение мы выбрали для нашего рабочего процесса, повествует данная статья.
Завязка
Точка зрения официальной документации Symfony
Большинство наших проектов сделано на фреймворке Symfony ❤️. C выходом четвертой его версии некоторые старые методы деплоя перестали работать. Это заставило нас заново изучить, как же именно должен происходить деплой согласно документации Symfony и какие новые инструменты для этого появились.
Согласно официальным Symfony докам от 13 апреля 2018 года, процесс деплоя состоит из следующих этапов:
- Проверка конфигурации сервера
- Задание переменных окружения
- Получение актуальной версии кода (обычно через git)
- Установка/обновление зависимостей вендоров через composer
- Очистка symfony-кэша
- Проброс ассетов
- Запуск миграций для БД
- Очистка APC-кэша
- Добавление/редактирование CRON-джобов
Чтобы не делать весь этот список вручную, документация предлагает несколько готовых скриптов и тулз, позволяющих автоматизировать эти действия. Рассмотрим их бегло вместе с нашими комментариями:
- EasyDeployBundle
Отдельный бандл, достаточно удобный и кастомизируемый. На момент написания статьи не работает с четвертой версией symfony. Github - Deployer
Удобная внешняя тулза, поставляемая в качестве отдельного .phar файла. На момент написания статьи тоже не работает с четвертой версией symfony. Сайт - Ansistrano
Роль Ansible для управления деплоем приложений на PHP, Python и Ruby. Является портом Capistrano для Ansible. При изучении показалась нам наиболее подходящим вариантом. Сайт - Magallanes
Не самое распространённое, но простое и гибкое решение, написанное на php. Не адаптировано под четвертую версию фреймворка. Github - Fabric
Библиотека на Python (2.7, 3.4+), разработанная для выполнения удаленных команд по ssh. Не подошла нам, так как мы не хотели увеличивать общий парк технологий, добавляя в него питон. Сайт - Capistrano with Symfony plugin
Старый добрый гем на ruby, который мы использовали до прихода в нашу жизнь ансибла. В данный момент не адаптирован под четвертую версию symfony. Github - sf2debpkg
Отдельный debian-пакет, который, судя по его гитхабу, 6 лет не обновлялся. Остался вне фокуса нашего рассмотрения.
Наша история использования разных средств
Как уже говорилось выше, изначально мы использовали Capistrano вместе с плагином Capifony.
После этого, чтобы избавиться от зависимости в ruby, мы попробовали Deployer. Он показался нам довольно удобным для небольших проектов. Также он легко настраивался самими разработчиками.
После внедрения Ansible для настройки серверов, мы также нашли специальную роль и для деплоя — https://github.com/servergrove/ansible-symfony2, однако с выходом четвертой версии symfony, она перестала работать.
Кульминация
Изучаем Ansistrano. Деплой Symfony через Ansistrano
Постепенно наши поиски привели нас к Ansistrano. К нашей радости, у него даже существовала готовая роль, подходящая для нашего случая — https://github.com/cbrunnkvist/ansistrano-symfony-deploy. Поэкспериментировав на одном из своих проектов, мы успешно настроили и запустили деплой через неё. Далее приводим список необходимых команд для её использования:
Установка роли
$ ansible-galaxy install cbrunnkvist.ansistrano-symfony-deploy
Создание файла со списком ip-адресов серверов (в нашем случае это config/inventory.yml)
webservers:
hosts:
prod:
ansible_ssh_host: 195.111.111.13
ansible_user: deployer
Создание файла с настройками конфига (у нас это deploy.yml)
- name: Deploy script for some server
hosts: webserver
remote_user: deployer
gather_facts: false
environment:
APP_ENV: prod
APP_SECRET: some_app_secret
DATABASE_URL: 'pgsql://root:password@localhost:5432/test'
roles:
- cbrunnkvist.ansistrano-symfony-deploy
vars:
ansistrano_allow_anonymous_stats: false
ansistrano_deploy_to: /var/www/some_project_path
ansistrano_deploy_via: git
ansistrano_git_repo: [email protected]:myaccount/myproject.git
ansistrano_git_branch: master
ansistrano_keep_releases: 3
ansistrano_shared_paths:
- 'public/images'
symfony_console_path: 'bin/console'
symfony_run_assetic_dump: false
symfony_run_doctrine_migrations: false
symfony_doctrine_options: '--no-interaction'
Запуск деплоя
$ ansible-playbook -i config/inventory.yml deploy.yml
Избавление от parameters.yml
В четвертой версии symfony авторами было решено отказано от задания параметров приложения через parameters.yml в пользу их задания через переменные окружения ( http://fabien.potencier.org/symfony4-best-practices.html).
В файле deploy.yml в секции environment также задаются переменные окружения, но действуют они только во время сеанса пользователя, осуществляющего деплой. Для того чтобы во время выполнения серверного кода, ему были доступны эти же переменные окружения, мы дополнительно предварительно вручную прописываем их для серверного пользователя в .bashrc:
export APP_ENV=prod
export APP_SECRET=some_app_secret
export DATABASE_URL= pgsql://root:password@localhost:5432/test
Заключение
В итоге Ansistrano рецепт нас полностью устраивает и является достаточно гибким для изменения и кастомизации. Теперь мы используем Ansible и для настройки серверов и для деплоя, не тратя ресурсы на ввод и обслуживание дополнительных инструментов.
Update 1
25.05.2108
На момент публикации некоторые скрипты из списка все таки адаптировали под четвертую версию symfony. О результатах их тестирования мы непременно еще напишем.