Canary релиз стратегии против Blue/Green

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

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

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

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

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

7 ответов

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

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

Цвет морской волны: введите описание изображения здесь

Канарейки: введите описание изображения здесь

Сине-зеленое высвобождение проще и быстрее.

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

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

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

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

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

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

канарейка

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

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

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

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

Обновление за май 2022 г.:

Разница между Blue-Green Deployment (Blue-Green Release) и Canary Deployment (Canary Release) заключается в следующем:

  • Сине-зеленое развертывание выполняется быстро
  • Canary Развертывание постепенное

Сине-зеленое развертывание:

Существует две среды: синяя среда, которая является «старой» и содержит одно или несколько приложений (экземпляров или контейнеров), и зеленая среда, которая является «новой» и содержит одно или несколько приложений (экземпляров или контейнеров).

Затем 100% трафика сразу же быстро переключается из синей среды в зеленую , как показано ниже, и вы можете сказать, что сине-зеленое развертывание — это быстрый способ канареечного развертывания .:

Это изображение выше взято с сайта https://www.encora.com/insights/zero-downtime-deployment-techniques-blue-green-deployments , изначально созданного компанией Encora.

Канарское развертывание:

Существует две среды: синяя среда, которая является «старой» и содержит одно или несколько приложений (экземпляров или контейнеров), и зеленая среда, которая является «новой» и содержит одно или несколько приложений (экземпляров или контейнеров).

Затем 100% трафика постепенно переключается из синей среды в зеленую , что занимает больше времени (30 минут, часов или дней), чем сине-зеленое развертывание , как показано ниже, и вы можете сказать, что канареечное развертывание — это постепенный способ сине-зеленого развертывания. :

Это изображение выше взято с сайта https://www.encora.com/insights/zero-downtime-deployment-techniques-canary-deployments , изначально созданного компанией Encora.

Релизы "синий / зеленый" и "канарейка" решают одну и ту же цель тестирования программного обеспечения с целевой аудиторией, прежде чем предоставлять функции программного обеспечения более широкой аудитории. В случае канарейки развертывания могут совместно использовать одну и ту же инфраструктуру, но в случае синего / зеленого вся инфраструктура дублируется маршрутизатором /DNS/reverseproxy впереди для маршрутизации трафика.

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

Вы можете обратиться к следующим статьям для более подробного сравнения:

Развертывание BlueGreen: http://martinfowler.com/bliki/BlueGreenDeployment.html

Развертывание канарейки: http://martinfowler.com/bliki/CanaryRelease.html

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

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

    Â

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

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

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

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

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

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

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

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

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

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

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

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