Стратегия выпуска канарейки против синего / зеленого

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

Насколько я понимаю, сине-зеленый выпуск состоит в том, что у вас есть 2 зеркалированные производственные среды («синий» и «зеленый»), и вы отправляете изменения сразу во все узлы синего или зеленого цвета, а затем используете сетевую магию для управления в какую среду пользователи перенаправляются через DNS.

Итак, прежде чем я начну, если что-то из того, что я сказал до сих пор, неверно, пожалуйста, исправьте меня!

Предполагая, что я более или менее на правильном пути, тогда пара вопросов по двум стратегиям:

• Существуют ли сценарии, в которых канарейка предпочтительнее сине-зеленой, и наоборот?
• Существуют ли сценарии, в которых модель развертывания может реализовывать обе стратегии одновременно?

Сине-зеленый выпуск проще и быстрее.

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

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

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

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

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

Я написал подробное эссе на эту тему здесь: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

На мой взгляд, разница в том, доступна ли новая «зеленая» версия реальным пользователям. Если да, то я бы назвал это Канарейкой. Обычный способ реализации Canary - это обычный синий / зеленый с добавлением интеллектуальной маршрутизации конкретных пользователей в новую версию. Прочтите пост для подробного сравнения

Цвет морской волны:

Канарейки:

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

канарейка

1. Канарский выпуск - это метод снижения риска внедрения новой версии программного обеспечения в производственную среду путем медленного развертывания изменения для небольшой группы пользователей перед его развертыванием во всей инфраструктуре.

2. Он собирается получить представление о том, как будет работать новая версия (интеграция с другими приложениями, процессором, памятью, использованием диска и т. Д.).

Цвет морской волны:

1. Это больше о предсказуемой версии с нулевым временем простоя при развертывании.
2. Легкий откат в случае неудачи.
3. Полностью автоматизированный процесс развертывания

Вот несколько встроенных определений -

• Сине-зеленое развертывание - при развертывании новой версии приложения создается вторая среда. После тестирования новой среды она заменяет старую версию. Затем старую среду можно отключить.

   

• A / B-тестирование. Две версии приложения работают одновременно. Каждому из них идет порция запросов. Затем разработчики могут сравнить версии.  
• Canary Release - вместе со старыми версиями запускается новая версия микросервиса. Затем эта новая версия может принять часть запросов, и команда сможет проверить, как эта новая версия взаимодействует с системой в целом.

Хорошее начало определений. Я думаю, что если вы разделите определение «выпуск» на «развертывание» и «выпуск (функциональность)», это также поможет в принятии решения по вашей стратегии.

Развертывание (двоичные файлы)

Действие двоичного развертывания вашего продукта в (производственной) системе.

Релиз (функциональность)

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

Зачем? Обычно при «выпуске» у вас возникают (несколько) две проблемы: 1) Ошибки / обратная совместимость и т. Д. 2) Проверка допустимости / удобства использования новых функций.

Затем задайте себе вопрос, прежде чем выбрать канареечный или синий / зеленый или любую другую стратегию серого / смешанного режима: какие проблемы мы испытываем при выпуске / развертывании новой версии? И только тогда, если вы знаете, что вас беспокоит, выберите свою стратегию.

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

Пометка функции

Действие «настройка» (холодная или даже горячая), какая функциональность (недоступна) для какой (группы) пользователей

Если вы также выполняете что-то вроде «пометки функций», вы можете сначала развернуть, измерить надежность вашего выпуска с точки зрения обратной совместимости / ошибок и постепенно выпускать новые функции для разных пользователей, или наоборот (масштабировать или даже откатывать функциональность и / или двоичные файлы ). Пометка функций позволяет отделить доступность функциональности от развертывания двоичных файлов и дает гораздо более детализированные решения, чем только «развертывание / откат»