Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

• шаблоны релиза на основе среды: в этом случае мы имеем две или более сред, где выполняется развертывание, но только одна из них получает реальный трафик от клиентов (например, благодаря настройкам средств балансировки нагрузки). Новый код развертывается в среде без реальной нагрузки, и релиз будет произведен перенаправлением трафика к этой среде. Это исключительно эффективные шаблоны, поскольку они обычно не требуют внесения каких-либо изменений в наши приложения. Они включают в себя сине-зеленое (blue-green) развертывание, канареечное развертывание[94] и кластерные иммунные системы (claster immune systems), все они будут обсуждаться ниже;

• шаблоны релизов на основе приложений: в этом случае мы изменяем наше приложение, с тем чтобы мы могли выборочно разблокировать и выпускать отдельные функциональности приложения путем небольших изменений конфигурации. Например, мы можем реализовать флаги функций, чтобы постепенно открывать новые возможности в производственной среде для команды разработчиков, или всех наших сотрудников, или 1 % наших клиентов, или, когда мы уверены в том, что релиз будет работать, как запланировано, для всей нашей клиентской базы. Как обсуждалось ранее, это делает возможным использование метода, называющегося теневым запуском, когда мы запускаем в производственной среде все функциональные возможности и проверяем их на клиентском трафике до релиза. Например, мы можем скрытно проверить новую функциональность на реальном трафике в течение нескольких недель перед запуском для выявления проблем, чтобы их можно было исправить до официального запуска.

Шаблоны релиза на основе среды

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

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

Шаблон Blue-Green развертывания

Наиболее простой шаблон из трех называется сине-зеленым развертыванием. В этом шаблоне есть две производственные среды: синяя и зеленая. В любое время только одна обслуживает трафик клиента, на рис. 20 рабочая среда — зеленая.

Рис. 20. Шаблон сине-зеленого развертывания (источник: Джез Хамбл, Дэвид Фарли «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ»)

Для релиза новой версии сервиса мы развертываем его в неактивную среду, где можно выполнить тестирование, не прерывая работу пользователей. Когда мы уверены в том, что все работает нормально, то выполняем релиз, направляя трафик к голубой среде. Таким образом, эта среда становится рабочей, а зеленая — подготовительной. Откат можно выполнить перенаправлением трафика опять к зеленой среде[95].

Сине-зеленая схема развертывания — простой шаблон, его также чрезвычайно легко встроить в существующие системы. Он имеет огромные преимущества, например возможность выполнить развертывания в рабочее время и провести простые переналадки (например, изменение настроек маршрутизатора, изменение символьных ссылок) в часы непиковых нагрузок. Одно это может существенно улучшить условия работы команды, выполняющей развертывание.

Управление сменой баз данных

Проблему создает наличие двух версий приложения в производстве, зависящих от общей базы данных: когда при развертывании требуется изменить схему базы данных или в самой базе добавить, изменить либо удалить таблицу или колонку, она не в состоянии поддерживать обе версии приложения. Есть два общих подхода к решению: