Canary Releases
Что такое канареечный релиз?
Метод снижения риска внедрения новой версии программного обеспечения в “производственную среду”. Происходит путем плавного развертывания изменений для небольшой группы пользователей.
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
В чем основная суть метода?
Новый функционал или его обновлённая часть публикуется для ограниченной аудитории по мере готовности на продакшен окружение. Перед деплоем достаточно убедиться, что код не содержит синтаксических ошибок. Этот шаг может быть частью ci пайплаина. Первые пользователи, которые увидят изменения, могут быть разработчиками или тестировщиками. После проверки функционала, который уже находится в той среде, где с ним начнут взаимодействовать реальные пользователи, можно открыть доступ настоящим пользователям частично или полностью. В случае нахождения ошибок фичу можно моментально закрыть от пользователей и минимизировать потери (репутационные, финансовые).
Использовать предпродакшен среду, на которую сначала публикуются изменения, после этапа проверки и тестирования. Изменения попадают в продакшен среду, где еще раз проверяются на ошибки связанные с интеграцией, которые могли возникнуть из за неточности двух окружений.
Какие плюсы у канареечного релиза?
Какие накладные расходы для использования канареечных релизов?
Почему стоит использовать канареечные релизы?
Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.
Фундаментальные проблемы нескольких предпродакшен окружений: при росте инфраструктуры и сложности приложения сложность поддержки тестовых окружений будет расти, увеличивая стоимость поддержки окружения и снижая частоту релизов. Тестовое окружение не может быть идентичным продакшен, а пользовательский трафик не может быть сопоставим.
Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm
Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.
Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:
Еще проще представить такой вариант можно на kubectl, а в документации по Kubernetes даже есть полноценный туториал по этому сценарий. Но главный вопрос этого поста заключается в том, как мы собираемся автоматизировать этот процесс, используя Helm.
Автоматизация канареечного деплоя
Прежде всего нам понадобится карта чартов Helm, в которую уже внесены обсуждаемые нами выше ресурсы. Выглядеть она должна быть примерно так:
Основа концепции Helm — управление мультиверсиями релизов. Stable-версия — это наша основная стабильная ветка кода проекта. Но с помощью Helm мы можем развернуть канареечный релиз с нашим экспериментальным кодом. Главное — сохранить обмен трафиком между стабильной версией и канареечным релизом. Управлять всем этим мы будем с помощью специального селектора:
Наши как «канареечные», так и stable-ресурсы деплоя будут указывать эту метку на модулях. Если все настроить правильно, то во время деплоя канареечной версии нашей карты чартов Helm мы увидим, что трафик будет направляться на свежеразвернутые модули. Стабильная версия этой команды будет выглядеть так:
Теперь давайте проверим наш канареечный релиз. Чтобы задеплоить канареечную версию, нам надо помнить о двух вещах. Название релиза должно отличаться, чтобы мы не накатили апдейт на текущую stable-версию. Версия и тег также должны отличаться, чтобы мы могли развернуть другой код и определить различия по меткам ресурсов.
Вот, собственно, и все! Если пингануть службу, то можно увидеть, что канареечное обновление маршрутизирует трафик только часть времени.
Если вы ищите инструменты автоматизации деплоя, которые включают в себя описанную логику, то обратите внимание на Deliverybot и на инструменты автоматизации Helm на GitHub. Чарты Helm, используемые для реализации описанного выше способа лежат на Github, вот тут. Вообще, это был теоретический обзор того, как реализовать автоматизацию деплоя канареечных версий на практике, с конкретными концепциями и примерами.
Стратегии деплоя в 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), за все эти потрясающие схемы деплоя.
Словарь терминов по DevOps
Собрали небольшой словарик часто употребляемых терминов и сокращений DevOps-инженерами.
Agile (Гибкая разработка программного обеспечения)- методология доставки программного обеспечения, основанная на коротких итерационных этапах разработки, где каждый спринт должен приводить к эксплуатационному продукту. Это позволяет легко корректировать требования проекта в случае необходимости и дает возможность творчества и гибкости в командах разработчиков.
Amazon AWS — Amazon Web Services — самый популярный поставщик облачных услуг (CSP) согласно отчету о состоянии DevOps за 2017 год, предлагающий широкий спектр услуг облачных вычислений для предприятий любого масштаба.
Apache — один из самых популярных веб-серверов с открытым исходным кодом (уступает только NGINX), кроссплатформенный инструмент для запуска веб-сайтов и приложений.
ALB — Балансировка нагрузки приложений — сервис AWS, используемый для разделения входящего трафика между несколькими экземплярами приложений в нескольких зонах доступности для обеспечения бесперебойной работы вашего приложения.
ASG — Auto Scaling Group — сервис AWS, используемый для объединения нескольких экземпляров EC2 в логические группы в целях проектирования инфраструктуры и простоты управления; группа состоит из идентичных экземпляров, которые добавляются или удаляются в соответствии с требованиями рабочей нагрузки.
AWS CLI — интерфейс командной строки AWS — инструмент AWS для управления различными сервисами и продуктами AWS из терминала командной строки.
Bastion host — специальный сервер, используемый для доступа к частным сетям и противостояния хакерским атакам. Обычно размещает одно приложение (например, прокси-сервер) и ключи SSH для доступа и управления базовой облачной инфраструктурой.
Ветвление — ветви представляют собой отдельные копии кода проекта на GitHub или другой системе контроля версий кода, что позволяет многим разработчикам работать над проектом одновременно.
Bucket — логическая единица в Amazon S3 (Simple Storage Service), используемая для хранения нескольких типов объектов (в основном, различных данных и метаданных, которые их описывают).
Back-end — программный движок, к которому у пользователя нет прямого доступа. Этот механизм получает запросы от пользовательского интерфейса и выполняет определенные операции, включая загрузку и сохранение данных в базе данных и т.д.
Сборка — это конкретная версия программного кода, в основном называемая этапом разработки новых функций. Наиболее важными являются сборки Canary, где новый код тестируется на соответствие существующим функциональным возможностям приложения в рабочей среде.
Bare-metal — случай, когда программное обеспечение установлено на физических устройствах (жестких дисках), пропуская уровень виртуализации.
Canary release — промежуточный сервер, который является точной копией производственной среды. Там запускаются новые сборки программного обеспечения, чтобы обеспечить соответствие существующим функциям и коду перед развертыванием их для всей пользовательской базы.
CI / CD — Непрерывная интеграция / Непрерывная доставка — основа современной культуры DevOps. CI гарантирует, что новый код передается в централизованное хранилище кода несколько раз в день, чтобы пройти автоматические модульные тесты и ускорить сборку нового программного обеспечения. Если тесты пройдены успешно, CD гарантирует, что новая версия приложения будет автоматически отправлена в промежуточную и производственную среды без простоев службы. Рабочий процесс CI / CD гарантирует, что все ошибки будут найдены и исправлены на ранней стадии, а продукт будет доступен в любое время.
Commit (Комит) — процесс отправки кода в репозиторий Git и полученный фрагмент кода.
Управление конфигурацией — процесс установки и поддержания требуемых параметров программной экосистемы с помощью инструментов автоматического управления конфигурацией, таких как Kubernetes, Ansible, Puppet, Chef, Saltstack и т. Д.
DevOps — методология доставки программного обеспечения, а также набор практик, рабочих процессов и инструментов, необходимых для обеспечения надежной автоматизации ИТ-операций с постоянным повышением качества.
Dark launch (Темный запуск) — практика выпуска кода в производственную среду без уведомления пользователей о новых доступных функциях. Код запускается в производство для заключительного этапа тестирования, затем объявляется о выпуске новой функции, а сама функция уже доступна.
Docker — платформа с открытым исходным кодом для создания, доставки и запуска контейнеров приложений. Docker является основой современных облачных вычислений, поскольку он позволяет максимально эффективно использовать облачные ресурсы, обеспечивая повсеместный уровень для построения облачной инфраструктуры.
Фреймворк Django — это высокоуровневый фреймворк Python, ориентированный на чистый дизайн, быструю разработку и высокую производительность приложений. Нашел широкое применение в веб-разработке и обработке больших данных.
Datadog — эффективный сервис облачного мониторинга, позволяющий анализировать процессы в любой инфраструктуре, базе данных или приложении в любом масштабе, используя платформу на основе SaaS.
Среда (Environment) — все ресурсы сервера (ОС, библиотеки, API, инструменты и платформы и т. Д.), Необходимые для запуска программного обеспечения на различных этапах его жизненного цикла (разработка, тестирование, подготовка, производство).
ElasticSearch — RESTful, распределенный движок для поиска и анализа данных, построенный на Apache Lucene. Как ядро стека Elastic, Elasticsearch позволяет хранить и обрабатывать данные из нескольких облачных инструментов мониторинга и ведения журналов.
Envoy — мощный прокси C ++ для обработки трафика между микросервисами.
FluentD — инструмент для сбора и обработки данных с открытым исходным кодом, написанный на Ruby. Он позволяет вводить данные из огромного количества инструментов, таких как ElasticSearch, и выводить данные на широкий выбор панелей мониторинга, настроенных с использованием нескольких плагинов.
Fargate — Amazon Fargate — это сервис Amazon для запуска контейнеров Docker в управляемой инфраструктуре, такой как EKS, без необходимости что-либо настраивать. Он работает по схеме выставления счетов без сервера — вы указываете, что необходимо сделать, и оплачиваете потребляемые ресурсы без какой-либо ручной настройки кластера.
Helm — менеджер приложений, работающий поверх Kubernetes. Этот инструмент позволяет управлять микросервисами в масштабе с помощью удобных диаграмм Хелма и обеспечивает бесперебойную работу сложной инфраструктуры Kubernetes.
Инфраструктура — весь комплекс оборудования, программного обеспечения и процессов, необходимых для запуска приложений, а также для сбора, управления и хранения данных.
IaC — Инфраструктура как код — один из базовых принципов DevOps. Это означает, что конфигурация инфраструктуры выполняется с помощью машиночитаемых декларативных файлов, а не вручную или с использованием интерактивных инструментов. Эти файлы (например, манифесты Kubernetes или Terraform ) могут храниться в репозиториях GitHub, настраиваться и корректироваться так же, как и код, что обеспечивает эффективную автоматизацию обеспечения инфраструктуры.
IaaS — инфраструктура как услуга, модель управления ИТ, в которой вычислительные ресурсы и службы, необходимые для их работы, предоставляются в качестве службы, обеспечивающей функционирование различных платформ и приложений.
Пропускная способность ввода / вывода — количество операций ввода / вывода в секунду, характеристика пропускной способности сети или накопителя.
Ingress controller — программный модуль, используемый для обеспечения балансировки нагрузки в модулях Kubernetes.
Jenkins — Java-сервер с открытым исходным кодом, позволяющий автоматизировать доставку программного обеспечения.
Работа в Jenkins — процесс в Jenkins, необходимый для сборки кода, запуска модульных тестов, генерации метрик качества кода, развертывания новых версий приложений в рабочей среде и т. д.
Kibana — часть стека Elastic, отвечающая за визуализацию данных и навигацию по кластеру ELK.
Lead time (Время выполнения) — время, необходимое для перемещения нового пакета кода из коммита в релиз.
MTTR — среднее время до восстановления — среднее ожидаемое время, когда отказавший системный компонент снова заработает; основной параметр сценариев восстановления после сбоев, системного стресс-тестирования и проверки производительности.
Node (узел, нода) — физическая или виртуальная машина в кластере Kubernetes, используемая для размещения модулей, которые запускают контейнеры Docker.
Node pool (Пул узлов) — пул узлов Kubernetes — это группа из нескольких точек кластера, объединяющих машины с одинаковой конфигурацией, которые по сути можно рассматривать и управлять ими как одним объектом.
Nexus3 — платформа управления выпуском от Sonatype, созданная для объединения входных сигналов от нескольких модулей с открытым исходным кодом, чтобы обеспечить быстрый, безопасный и эффективный жизненный цикл доставки программного обеспечения.
OpenStack — платформа с открытым исходным кодом для создания локальных облачных инфраструктур.
OpenShift — платформа управления контейнерами корпоративного уровня для Kubernetes, работающая в локальных облачных инфраструктурах, разработанная Red Hat.
PaaS — платформа как услуга, модель доставки программного обеспечения, когда разработчики получают все необходимые библиотеки, инструменты и сервисы для разработки программного обеспечения со всей базовой инфраструктурой, которая обрабатывается платформой, предоставляющей сервис.
Prometheus — решение для облачного мониторинга с открытым исходным кодом с мощным языком запросов, базой данных временных рядов, моделью данных измерений и возможностями интеллектуального оповещения.
Pod — базовое структурное подразделение Kubernetes, группа контейнеров Docker, развернутых на одном хосте.
Playbook — Ansible playbook — это инструкции по развертыванию инфраструктуры с подробными руководствами по выполнению серии команд для выполнения конкретных задач.
ProxMox — основанная на Debian платформа с открытым исходным кодом для развертывания и управления виртуальными машинами.
Production environment (PROD, Производственная среда)- среда, в которой программный продукт или услуга используется целевой аудиторией.
Rollback (Откат) — ручное или автоматическое восстановление ранее сохраненного состояния программы или базы данных.
Regression testing (Регрессионное тестирование) — комплексное тестирование обновленной версии продукта, чтобы убедиться, что последняя сборка не оказала негативного влияния на уже имеющуюся функциональность.
RabbitMQ — брокер сообщений, программное обеспечение, используемое для сбора сообщений из ваших приложений и их хранения до тех пор, пока они не потребуются для операций.
S3 — Amazon Simple Storage Service — сервис облачных вычислений для хранения любых объектов данных, необходимых для стабильной работы ваших приложений.
Snapshot (Amazon EBS snapshot EBS) — команда для создания статической копии содержимого вашего экземпляра EC2 в целях резервного копирования и восстановления.
Staging environment (Stage, промежуточная среда) — контролируемая копия вашей производственной среды, максимально напоминающая ее. Это позволяет тестировать новые версии программного обеспечения, чтобы находить ошибки перед выпуском в эксплуатацию.
Technical debt (Технический долг) — концепция нежелательного количества работы разработчиков, необходимого для исправления простого кода, используемого для быстрого получения результатов, вместо того, чтобы тратить время на разработку и внедрение наилучшего решения.
Модульное тестирование (Unit testing) — основа CI / CD, модульное тестирование — это практика тестирования кода приложения небольшими блоками на основе кода автоматизированного тестирования перед сборкой приложения, чтобы минимизировать время, необходимое для обнаружения и исправления ошибок, сокращая время выхода на рынок.
VPC peering — AWS VPC — это сервис, который логически изолирует определенное количество общедоступного облака AWS для создания виртуальных частных облаков. AWS VPC peering позволяет объединить ресурсы нескольких таких облаков в случае необходимости.
Vault — продукт Hashicorp для безопасного хранения таких секретов, как ключи SSH, токены, пароли, ключи API и другие важные элементы инфраструктуры Kubernetes.
Zabbix — сервис мониторинга облачной инфраструктуры с открытым исходным кодом для отслеживания состояния различных сетевых ресурсов и сервисов. Состоит из сервера и агентов, которые обеспечивают интеллектуальное оповещение для распределенных систем.
