в чем отличие canary release и blue green deployment
Стратегия релиза Canary против Blue / Green
Мое понимание канареечного релиза состоит в том, что это частичный выпуск для подмножества производственных узлов с включенными липкими сессиями. Таким образом, вы можете контролировать и минимизировать количество пользователей/клиентов, на которых будет оказано влияние, если вы в конечном итоге выпустите плохую ошибку.
Мое понимание сине-зеленой версии состоит в том, что у вас есть две зеркальные производственные среды («синяя» и «зеленая»), и вы нажимаете изменения сразу на все узлы синего или зеленого цвета, а затем использовать магию сети для управления тем, в какую среду пользователи направляются через DNS.
Поэтому, прежде чем я начну, если что-то, что я сказал до сих пор, неверно, пожалуйста, начните исправлять меня!
Если предположить, что я более или менее на правильном пути, тогда пара вопросов о двух стратегиях:
Сине-зеленое высвобождение проще и быстрее.
Автоматизация развертывания требует усилий, поэтому большинство организаций планируют использовать одну или другую стратегию каждый раз.
Так что делайте сине-зеленое развертывание, если вы привержены методам, которые позволяют вам быть уверенными в этом. В противном случае отправьте канарейку.
На мой взгляд, разница в том, доступна ли новая «зеленая» версия реальным пользователям. Если это так, то я бы назвал это канарейка. Распространенным способом реализации Canary является обычный Blue/Green с добавлением интеллектуальной маршрутизации конкретных пользователей к новой версии. Прочитайте пост для подробного сравнения
Цвет морской волны: 
Релизы «синий/зеленый» и «канарейка» решают одну и ту же цель тестирования программного обеспечения с целевой аудиторией, прежде чем предоставлять функции программного обеспечения более широкой аудитории. В случае канарейки развертывания могут совместно использовать одну и ту же инфраструктуру, но в случае синего/зеленого вся инфраструктура дублируется маршрутизатором/DNS/reverseproxy впереди для маршрутизации трафика.
В облачной среде, где проще создавать сценарии и воссоздавать инфраструктуру, предпочтение отдается сине-зеленому развертыванию, поскольку оно позволяет инфраструктуре синхронизироваться с автоматизацией. Это прекрасная возможность, когда требуется воссоздать среду.
Вы можете обратиться к следующим статьям для более подробного сравнения:
Канарские
Он собирается получить представление о том, как будет работать новая версия (интеграция с другими приложениями, процессор, память, использование диска и т.д.).
синий/зеленый:
Хорошее начало определений. Я думаю, что это также поможет принять решение для вашей стратегии, если вы разделите определение «релиз» на «развернуть» и «выпуск (функциональность)».
Развертывание (двоичные файлы)
Действие бинарного развертывания вашего продукта в (производственной) системе.
Действие управления доступностью функциональности для (групп) пользователей.
Зачем? При «выпуске» у вас обычно есть (несколько) две проблемы: 1) Ошибки/обратная совместимость/и т.д. 2) Проверка достоверности/применимости новых функций
Затем спросите себя, прежде чем выбрать канарейку, сине-зеленую или любую другую стратегию с серым/смешанным режимом: с какими проблемами мы сталкиваемся при выпуске/развертывании новой версии? И только тогда, если вы знаете свои проблемы, выберите свою стратегию.
Кроме того, можно выполнять более сложные стратегии развертывания/выпуска. Например, в некоторых облаках/инфраструктуре можно иметь несколько производственных серверов и передавать нагрузку в разных пропорциях на разные серверы и версии вашего продукта, а также контролировать надежность перед масштабированием выпуска/развертывания для всех пользователей.
Действие «настройка» (холодная или даже горячая), какая функциональность (не) доступна для какой (группы) пользователей
Если вы также делаете что-то вроде «маркировки функций», вы можете сначала развернуть, измерить надежность вашего релиза с точки зрения обратной совместимости/ошибок и постепенно выпускать новые функции для разных пользователей или наоборот (уменьшать или даже уменьшать функциональность отката и/или двоичные файлы. ). Пометка функций позволяет отделить доступность функциональности от развертывания двоичных файлов и дает гораздо более детальное принятие решений, чем только «развертывание/откат»
Стратегия выпуска канарейки против синего / зеленого
Насколько я понимаю, канареечный выпуск состоит в том, что это частичный выпуск для подмножества производственных узлов с включенными липкими сеансами. Таким образом, вы можете контролировать и минимизировать количество пользователей / клиентов, которых коснется ваша ошибка.
Насколько я понимаю, сине-зеленый выпуск состоит в том, что у вас есть 2 зеркалированные производственные среды («синий» и «зеленый»), и вы отправляете изменения сразу во все узлы синего или зеленого цвета, а затем используете сетевую магию для управления в какую среду пользователи перенаправляются через DNS.
Итак, прежде чем я начну, если что-то из того, что я сказал до сих пор, неверно, пожалуйста, исправьте меня!
Предполагая, что я более или менее на правильном пути, тогда пара вопросов по двум стратегиям:
Сине-зеленый выпуск проще и быстрее.
Автоматизация развертывания требует усилий, поэтому большинство организаций будут каждый раз планировать использовать ту или иную стратегию.
Так что делайте сине-зеленое развертывание, если вы придерживаетесь практики, позволяющей быть уверенным в этом. В противном случае пошлите канарейку.
Суть сине-зеленого развертывания заключается в одновременном развертывании, а сущность канареечного развертывания заключается в постепенном развертывании, поэтому, учитывая единый пул пользователей, я не могу придумать процесс, который я бы описал как выполняющий и то, и другое одновременно. Если у вас есть несколько независимых пулов пользователей, например, с использованием разных региональных центров обработки данных, вы можете использовать сине-зеленый цвет в каждом центре обработки данных и канарейку в центрах обработки данных. Хотя, если вам не нужно развертывание канарейки в центре обработки данных, вам, вероятно, не понадобится в центрах обработки данных.
Русские Блоги
Сине-зеленый, A / B и канареечное развертывание
—— Выдержки из главы 3 «DevOps с OpenShif»
Сине-зеленое развертывание
Стратегия сине-зеленого развертывания сводит к минимуму время переключения приложения между новой и старой версиями, обеспечивая доступность двух версий стека приложений во время развертывания (рис. 3-3). Мы можем использовать связь между сервисами и маршрутами, чтобы легко переключаться между двумя запущенными стеками приложений, поэтому откат версии приложения выполняется просто и быстро.
Рисунок 3-3 Сине-зеленое развертывание
Мы развертываем синий и зеленый стеки приложений в одном проекте OpenShift (сине-зеленый) и указываем маршрут к службам, предоставляемым синим стеком приложений (рисунок 3-4):
[Переводчик]:
Приведенные выше несколько команд создают проект с именем bluegreen; развертывают набор стеков приложений с главной ветвью исходного кода с именем blue и определяют маршрут с именем bluegreen, указывающий на службу, соответствующую этому приложению; затем используйте исходный зеленый Ветвь для развертывания другого набора стека приложений, названного зеленым
Рисунок 3-4 В исходном тексте представлена диаграмма отображения развертывания, когда начальный маршрут указывает на синюю службу стека приложений. Фактически, это диаграмма отображения развертывания после того, как маршрут был сокращен с синего до зеленого.
Рисунок 3-4 Экологичное развертывание
Используя веб-интерфейс или командную строку, вы можете легко переключать точку маршрутизации между синими и зелеными службами приложений:
В архитектуре приложения без сохранения состояния сине-зеленое развертывание довольно просто реализовать, потому что не нужно беспокоиться о:
[Переводчик]:
Развертывание A / B
Развертывание A / B получило свое название от возможности использовать новую версию функции приложения как часть общего развертывания и сосуществовать со старой версией для онлайн-тестирования. Таким образом, вы можете создать предположение, выполнить развертывание A / B, проверить, является ли предположение правильным или неправильным, и вернуться к первоначальному развертыванию приложения (A) или продолжить развертывание приложения новой версии (B).
Рисунок 3-5 A / B-тест
Мы можем использовать уровень маршрутизации OpenShift для развертывания A / B (рис. 3-6).
Рисунок 3-6 Развертывание A / B
Давайте сначала создадим приложение «Кот дня» как версию A:
Затем создайте приложение «Город дня» как версию B:
Нам также нужно использовать annotation (Примечание) Чтобы переопределить и изменить режим балансировки нагрузки HAProxy по умолчанию, из least connection (Минимальное количество подключений) к round-robin (Опрос) режим, а в команде route-backends Укажите вес маршрута в:
[Переводчик]:
На данный момент в системе есть три маршрута, cats Направлено в приложение A / Cats, city Перенаправлен в приложение B / City, ab Произвольный переход к приложению A / B в зависимости от веса: 
Если браузер посещает внешнюю конечную точку маршрута ab, вы увидите содержимое страницы Cats. Давайте снова воспользуемся OpenShift set route-backends Команда для настройки веса маршрутизации так, чтобы 10% трафика приходилось на городскую версию. по curl Команда имитирует 10 нажатий на веб-страницу, а в выходных результатах отображается расположение изображения HTML-страницы. Вы можете видеть, что версия City была посещена 1 из 10 раз (не забудьте заменить имя хоста в URL-адресе в соответствии с вашей реальной средой):
[Переводчик]:
Если мы рады видеть, что пользователи предпочитают больше городов, мы можем направить весь трафик в версию приложения B / city (рисунок 3-7):
Когда мы просматриваем панель статистики трафика в веб-интерфейсе, мы видим:
Рисунок 3-7 Все транспортные потоки (B) города
Конечно, в производственной среде мы предпочитаем автоматически измерять и устанавливать веса маршрутизации с помощью вызовов API.
Канарское развертывание
Если вы посмотрите на пример развертывания A / B, вы увидите, что доступны три маршрута:
Мы можем использовать эти маршруты для разработки стратегии канареечного развертывания:
Как администратор кластера вы также можете использовать аналогичныеКонфигурация шаблона маршрутизации HAProxyПродвинутые технологии.
Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)
Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.
Схема взята из другого обзора стратегий выката, сделанного в Container Solutions
Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.
Более короткие и частые развертывания имеют следующие преимущества:
В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.
Стратегии деплоя
Существует несколько различных типов стратегий развертывания, коими можно воспользоваться в зависимости от цели. Например, вам может потребоваться внести изменения в некое окружение для дальнейшего тестирования, или в подмножество пользователей/клиентов, или возникнет необходимость провести ограниченное тестирование на пользователях, прежде чем сделать некую функцию общедоступной.
Rolling (постепенный, «накатываемый» деплой)
Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.
Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:
Параметры накатываемого обновления можно уточнить в файле манифеста:
Recreate (повторное создание)
В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:
Соответствующий манифест выглядит примерно так:
Blue/Green (сине-зеленые развертывания)
Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:
После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:
Canary (канареечные развертывания)
Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.
Эта стратегия применяется, когда необходимо испытать некую новую функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы создать два практически одинаковых сервера: один обслуживает почти всех пользователей, а другой, с новыми функциями, обслуживает лишь небольшую подгруппу пользователей, после чего результаты их работы сравниваются. Если все проходит без ошибок, новая версия постепенно выкатывается на всю инфраструктуру.
Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.
Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:
Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)
Канареечные развертывания с Weaveworks Flagger
Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.
Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.
На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:
Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.
Dark (скрытые) или А/В-развертывания
Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).
С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.
Flagger и A/B-развертывания
Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.
Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.
Canary release strategy vs. Blue/Green
My understanding of a canary release is that it’s a partial release to a subset of production nodes with sticky sessions turned on. That way you can control and minimize the number of users/customers that get impacted if you end up releasing a bad bug.
My understanding of a blue/green release is that you have 2 mirrored production environments («blue» and «green»), and you push changes out to all the nodes of either blue or green at once, and then use networking magic to control which environment users are routed to via DNS.
So, before I begin, if anything I have said so far is incorrect, please begin by correcting me!
Assuming I’m more or less on track, then a couple of questions about the two strategies:
5 Answers 5
In my opinion, the difference is whether or not the new ‘green’ version is exposed to real users. If it is, then I’d call it Canary. A common way to implement Canary is regular Blue/Green with the addition of smart routing of specific users to the new version. Read the post for a detailed comparison
Blue-green releasing is simpler and faster.
You can do a blue-green release if you’ve tested the new version in a testing environment and are very certain that the new version will function correctly in production. Always using feature toggles is a good way to increase your confidence in a new version, since the new version functions exactly like the old until someone flips a feature toggle. Breaking your application into small, independently releaseable services is another, since there is less to test and less that can break.
You need to do a canary release if you’re not completely certain that the new version will function correctly in production. Even if you are a thorough tester, the Internet is a large and complex place and is always coming up with unexpected challenges. Even if you use feature toggles, one might be implemented incorrectly.
Deployment automation takes effort, so most organizations will plan to use one strategy or the other every time.
So do blue-green deployment if you’re committed to practices that allow you to be confident in doing so. Otherwise, send out the canary.