Как мы делали deploy систему под сайты на yii

Автор: Eugeniy Marilev
Дата публикации: 2014-05-07 10:21:47

В этой статье расскажу как мы сделали свой "велосипед" для deploy проектов production. Работаем мы с GIT, поэтому принцип развертывания проекта освещается в контексте этой VCS.

Итак, из чего должен состоять собственно deploy?

  1. Центральный репозиторий на каком-либо ресурсе.
  2. Local environment - локальная версия на машинах разработчиков.
  3. Staging environment — промежуточное окружение для проверки всегда свежей версии проекта (мы же хотим видеть как проект поведет себя вне локального сервера?).
  4. Preproduction environment — имеет такие же настройки, файлы, БД как и Production, в общем повторяет окружение production сервера.
  5. Production environment - стабильная версия на публично доступном домене.

Применение новой версии - это целая эпопея!

Применяем для Stage:

  1. вытягиваем свежую версию: git pull origin master.
  2. обновляем зависимости: git submodule sync && git submodule update —init —recursive.
  3. применяем миграции.
  4. чистим кэш и assets.
  5. и возможно другое, в зависимости от сложности проекта.

Уф-ф, применили. Смотрим. Красиво!

Применяем для Preproduction:

  1. надо из для стабильной версии тэг. Назовем его, например, v-1.0.0
  2. git fetch и git checkout v-1.0.0
  3. Далее все шаги аналогичны последовательности для stage

Теперь для Production:

Все просто — аналогично как и для preproduction...

Есть ряд вопросов

  1. Но а ведь Production может быть размещен на нескольких серверах!
  2. А если не красиво? Ищем почему приложение не хочет работать правильно на определенном окружении. Находим. И опять все по кругу.
  3. Нужно следить за процессом применения версии, в случае чего делать экстренный откат к последней стабильной версии.

И это все отбирает много времени, также для этого нужны доступы по ssh. В общем было принято решение упростить себе жизнь хотя бы в этом смысле. Так была написана консольная команда DeployCommand...

DeployCommand или как экономить время

Команда помещается в конфигурацию консольного приложения и значительно облегчает обновление версий. Она становиться доступна через консоль linux примерно так:

cd 
protected/yiic deploy pull
protected/yiic deploy upgrade
  • deploy pull - вытягивает версию основного репозитория и синхронизирует зависимости (подмодули).
  • deploy upgrade — выполняет все остальное.

То есть два простых вызова консольной команды и обновление выполнено. Вручную этот подход использовать проще и быстрее.

Для staging окружения мы добавляем в cron вызов вида: */15 * * * * cd /var/www/mysite.com && protected/yiic deploy pull && protected/yiic deploy upgrade

Получает выкладку последней версии веб-приложения каждые 15 минут. Причем в случае возникновения Exception в процессе обновления, fail сообщение отсылается на почту.

Для production используется несколько другая команда для обновления исходного кода проекта: deploy fetchAndSwitch --branch=<branch_name>

А почему бы не сделать из этого сервис?

И правда, почему приложение не может само заботиться о своем обновлении? Принцип самообновления примерно следующий:

  • Через определенные промежутки времени приложение спрашивает у сервиса, а есть ли для него новая версия, сервис просматривает список версий данного приложения и если находит версию со статусом new — отсылает приложению имя тега которым помечен коммит новой версии.
  • приложение выполняет deploy fetchAndSwitch —branch=<branch_name>, deploy upgrade.
  • если версия применилась успешно, то приложение говорит сервису что все в порядке и данную версию можно пометить как done (примененную)
  • если же применение провалилось, то генерируется сообщение об ошибке и на сервисе версия помечается как fail (проваленная). Исходники откатываются при этом к предыдущей активной версии.

Были рассмотрены вопросы безопасности, ведь нехорошо если кто-то сможет случайно (или намеренно) сломать чье-то приложение:

  1. Приложению назначаются уникальные ключ, имя и список серверов на которых оно может находиться.
  2. Пользователь может работать только с теми приложениями, которые ему назначены, или же он является их создателем.

Так в DeployCommand появился action auto.

Теперь стабильные обновления происходят очень просто

Для обеспечения deploy на production добавляется на каждый сервер, где развернуто приложение следующая консольная команда в cron:

*/5 * * * * cd /var/www/mysite.com && protected/yiic deploy auto —key=<app_key_in_deploy_api>

Она будет проверять каждые, 5 минут наличие новой версии, и если что выполнять обновление.

Теперь, шаги для того чтобы выложить версию:

  1. Создаем стабильную версию (тег) в репозитории.
  2. В админке deploy-сервиса добавляем новую версию приложения для preproduction окружения.
  3. Если все хорошо, создаем новую версию приложения для production окружения(й). Причем очень просто поддерживать deploy для приложений, распределенных на несколько серверов-зеркал, к примеру.

И все, приложение обновится.

Выводы

Явными плюсами этой системы являются следующие вещи:

  1. Простота применения версии локально, экономия времени.
  2. Возможность промежуточного deploy на копии production окружения (preproduction).
  3. Система нотификации об ошибках применения релизов.
  4. Встроенная поддержка экстренного отката к последней стабильной версии.

Минусы тоже есть:

  1. Если вследствие выкладывания версии в определенных частях deploy подсистемы возникает php error в результате парсинга исходного кода самого движка deploy, то версионный движок перестанет работать — придется в этом случае для фикса проблемы выложить версию вручную.
  2. На то чтобы разобраться в интеграции системы впервые, нужно потратить дополнительное время.
Комментарии к статье
Комментарии:
Нет результатов.
Только зарегистрированые пользователи могут оставлять комментарии