Канареечный деплой что это

Canary Releases

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

Отрывок из блога Мартина Фаулера

Откуда такой термин?

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

В чем основная суть метода?

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

Альтернативный способ?

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

Какие плюсы у канареечного релиза?

• Отпадает необходимость держать лишние окружения: экономия времени разработчиков на поддержку актуального состояния тестовой среды.
• Снижение финансовых затрат на n-ое количество тестовых окружений.
• Тестирование происходит сразу на продакшен среде — выявляются ошибки интеграции, которые могут не возникать на тестовом окружении.
• Позволяет перейти на Trunk-Based Development(Patterns for Managing Source Code Branches) — подход, когда в системе контроля версий используется одна ветка, в которую сразу попадает весь написанный код. Такой подход избавляет разработчиков от затрат времени на решение больших и сложных конфликтов в коде. А так же исключает ситуацию, когда уже реализованный функционал где-то теряется 🙂
• Бонусом появляется возможность проводить A/B тесты на пользователях и находить лучшее решение, а также быстро проверять гипотезы.
• Возможность демонстрации заказчику будущих изменений сразу на продакшен окружении.
• Ранний доступ для лояльных пользователей и сбор обратной связи позволяют узнать как воспримут будущие изменения реальные пользователи.
• Если есть разные платформы (andord, ios, web) — одновременно для пользователей всех платформ предоставить доступ к новому функционалу — единовременный релиз.
• Культура децентрализованного принятия решений — принимать решения на основе продуктовых или технических метрик. Например, автоматизировать откат новой фичи в случае аномального роста нагрузки после релиза.

Какие накладные расходы для использования канареечных релизов?

• Разработчик должен гарантировать, что его код не содержит синтаксических ошибок и способен запуститься. Решается успешной компиляцией или использованием статического анализатора кода для интерпретируемых языков перед поставкой кода в продакшен среду.
• Использование готового или разработка своего механизма переключения доступа к фичам — Feature Toggles (aka Feature Flags)

Почему стоит использовать канареечные релизы?

Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.

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

Полезные материалы:

• Canary release — блог Мартина Фаулера
• Feature Flags, Toggles, Controls — библиотека для фичтоглинга
• Тестируем на проде: Canary Deployment
• The Facebook Mobile Release Process — видео с доклада
• Facebook — Rapid release at massive scale
• Automated Canary Analysis at Netflix with Kayenta

Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm

Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.

Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:

kind: Deployment metadata: name: app-canary labels: app: app spec: replicas: 1 . image: myapp:canary --- kind: Deployment metadata: name: app labels: app: app spec: replicas: 5 . image: myapp:stable --- kind: Service selector: app: app # Selector will route traffic to both deployments.

Еще проще представить такой вариант можно на kubectl, а в документации по Kubernetes даже есть полноценный туториал по этому сценарий. Но главный вопрос этого поста заключается в том, как мы собираемся автоматизировать этот процесс, используя Helm.

Автоматизация канареечного деплоя

Прежде всего нам понадобится карта чартов Helm, в которую уже внесены обсуждаемые нами выше ресурсы. Выглядеть она должна быть примерно так:

~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml

Основа концепции Helm — управление мультиверсиями релизов. Stable-версия — это наша основная стабильная ветка кода проекта. Но с помощью Helm мы можем развернуть канареечный релиз с нашим экспериментальным кодом. Главное — сохранить обмен трафиком между стабильной версией и канареечным релизом. Управлять всем этим мы будем с помощью специального селектора:

selector: app.kubernetes.io/name: myapp

Наши как «канареечные», так и stable-ресурсы деплоя будут указывать эту метку на модулях. Если все настроить правильно, то во время деплоя канареечной версии нашей карты чартов Helm мы увидим, что трафик будет направляться на свежеразвернутые модули. Стабильная версия этой команды будет выглядеть так:

helm upgrade --install myapp \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v1 \ # Goes into app.kubernetes.io/version --set image.tag=stable \ --set replicaCount=5

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

helm upgrade --install myapp-canary \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v2 \ # Goes into app.kubernetes.io/version --set image.tag=canary \ --set replicaCount=1

Вот, собственно, и все! Если пингануть службу, то можно увидеть, что канареечное обновление маршрутизирует трафик только часть времени.

Если вы ищите инструменты автоматизации деплоя, которые включают в себя описанную логику, то обратите внимание на Deliverybot и на инструменты автоматизации Helm на GitHub. Чарты Helm, используемые для реализации описанного выше способа лежат на Github, вот тут. Вообще, это был теоретический обзор того, как реализовать автоматизацию деплоя канареечных версий на практике, с конкретными концепциями и примерами.

• Блог компании ITSumma
• Тестирование IT-систем
• IT-инфраструктура
• Системы управления версиями
• Kubernetes

Стратегии развертывания в DevOps

Ускорение деплоя приложений и их новых версий — одна из задач DevOps.
Частые развертывания позволяют компаниям ускорить time to market: быстрее доставлять новые функции приложения пользователям, проверять продуктовые гипотезы и оперативно получать обратную связь.

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

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

В этой статье мы кратко рассмотрим различные стратегии деплоя, включая Recreate, Rolling, Multi-version, Blue/Green, Canary, A/B-тестирование:

• сценарии, в которых оптимально использовать ту или иную стратегию;
• ограничения стратегий.

Повторное создание (Recreate)

• удаление текущей версии приложения;
• развертывание новой версии.

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

Постепенное развертывание (Rolling)

В этой стратегии все инстансы приложения будут последовательно обновляться до новой версии. Каждый инстанс проходит следующий цикл:

• удаляется один из инстансов со старой версией приложения (остальные продолжают работать);
• запускается инстанс с новой версией;
• проверяется корректный запуск нового инстанса. Если все хорошо, переходим к следующему инстансу и проделываем то же самое.

Мультиверсии

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

Сине-зеленое развертывание (Blue/Green)

Эта стратегия базируется на двух продуктивных средах:

• «синяя» — там, где живут старые версии приложения;
• «зеленая» — зона, где мы запускаем новую версию приложения.

Когда «зеленая» зона готова стать продуктивом (после тщательного тестирования, конечно же), на нее переключается пользовательский трафик. Если с «зеленой» версией приложения возникают проблемы, трафик снова можно переключить на старую, «синюю» версию.

Канареечное развертывание (Canary)

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

Почему такой деплой называется канареечным?

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

A/B-тестирование

Фактически это вариация канареечного развертывания применительно для фронтенда. Здесь также запускается ограниченное количество инстансов c новой версией приложения, на которую переключается часть пользовательского трафика.

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

6 способов деплоя веб-приложений

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

Если вы еще не знаете, что такое деплой и как его проводить, сначала прочитайте наш гайд, а потом возвращайтесь к статье.

Повторное создание

Способ, при котором разработчик сначала отключает старую версию приложения (V1 на картинке), а затем развертывает новую версию (V2 на картинке). При этом в работе приложения возникает перерыв, длительность которого зависит от скорости отключения и повторного запуска.

• Простота
• Состояние приложения полностью обновляется.

• Пользователь не может использовать сервис во время простоя, длительность которого зависит от скорости проведения работ.

Последовательное развертывание

Разработчики постепенно заменяют экземпляры текущей версии приложения на экземпляры новой версии. Процедура выглядит следующим образом: балансировщик нагрузки распределяет трафик между серверами в пуле экземпляров версии V1. Потом развертывается один экземпляр версии V2. Когда новый экземпляр готов принимать трафик (пользователей, которые заходят в приложение), его включают в пул. Затем удаляют и отключают один экземпляр версии V1.

Чтобы увеличить время развертывания, можно изменять эти максимальные значения:

• Количество экземпляров, которые развертываются одновременно
• Увеличение количества экземпляров во время деплоя
• Количество экземпляров, недоступных во время последовательного развертывания.

• Простота
• Экземпляры приложения заменяются постепенно
• Удобно перераспределять данные приложений, сохраняющих информацию о запросах.

• Развертывание и откат к предыдущей версии занимают много времени
• Сложно реализовать поддержку нескольких API
• Отсутствует контроль за трафиком.

Освойте DevOps на интенсиве Хекслета Научитесь автоматизировать окружение, деплоить приложения одной кнопкой одновременно на любое количество машин и разворачивать облачный кластер на Digital Ocean или Yandex Cloud.

Сине-зеленый деплой

Сине-зеленый деплой означает, что синяя версия V2 развертывается параллельно зеленой версии V1 с одинаковым количеством экземпляров. Убедившись, что новая версия работает исправно, разработчики перенаправляют трафик от версии V1 к версии V2 с помощью балансировщика нагрузки.

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

• Высокая стоимость, так как для такого деплоя требуется вдвое больше ресурсов
• Перед развертыванием нужно тщательно протестировать платформу
• Сложно работать с приложениями, сохраняющими данные о запросах.

Канареечный релиз

Канареечный релиз позволяет постепенно перенаправить трафик от версии V1 к версии V2. Обычно трафик распределяется пропорционально: например, 90% запросов отправляется версии V1, а 10% — версии V2.

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

• Версия доступна части пользователей
• Удобно отслеживать коэффициент ошибок и работу новой версии
• Быстрый откат.

• Медленное развертывание.

A/B-тестирование

Пользователи, которые отвечают заранее определенным условиям, получают доступ к новым функциям. Этот метод похож на стратегию канареечного релиза, но отличается целями. A/B-тестирование — это не только стратегия деплоя, но и способ принятия бизнес-решений на основании статистики. Часто этот способ используется, чтобы оценить эффект изменения и определить, какая версия больше нравится пользователям.

Трафик может распределяться на основании следующих условий:

• Настройки файлов cookie
• Параметры запросов
• Геолокация
• Браузер, размер экрана, ОС и другие технические характеристики
• Язык.

• Параллельная работа нескольких версий
• Полный контроль над распределением трафика.

• Требуется умный балансировщик нагрузки
• Сложно устранять проблемы для конкретного сеанса
• Требуется трассировка распределенных систем.

Скрытое развертывание

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

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

• Работа приложения проверяется на основе реального трафика
• Пользователь не теряет доступ к приложению
• Приложение развертывается только тогда, когда оно отвечает всем требованиям заказчика.

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

Какую из стратегий деплоя использовать

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

Сине-зеленое развертывание и скрытый деплой стоят дороже, так как требуют вдвое больше ресурсов. Если тестирование не проводится в нужном объеме, или есть сомнения в отношении функционирования и стабильности приложения, подойдет канареечный релиз, A/B-тестирование или скрытое развертывание. Чтобы протестировать новую функцию на группе пользователей, можно применить фильтр, используя такие параметры, как геолокация, язык, ОС или настройки браузера. Для этого применяют A/B-тестирование.

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

Эта статья — адаптированный перевод материала разработчика Этьена Тремеля, опубликованного в блоге The New Stack.