канареечный релиз что это
Canary Releases
Что такое канареечный релиз?
Метод снижения риска внедрения новой версии программного обеспечения в “производственную среду”. Происходит путем плавного развертывания изменений для небольшой группы пользователей.
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
В чем основная суть метода?
Новый функционал или его обновлённая часть публикуется для ограниченной аудитории по мере готовности на продакшен окружение. Перед деплоем достаточно убедиться, что код не содержит синтаксических ошибок. Этот шаг может быть частью ci пайплаина. Первые пользователи, которые увидят изменения, могут быть разработчиками или тестировщиками. После проверки функционала, который уже находится в той среде, где с ним начнут взаимодействовать реальные пользователи, можно открыть доступ настоящим пользователям частично или полностью. В случае нахождения ошибок фичу можно моментально закрыть от пользователей и минимизировать потери (репутационные, финансовые).
Использовать предпродакшен среду, на которую сначала публикуются изменения, после этапа проверки и тестирования. Изменения попадают в продакшен среду, где еще раз проверяются на ошибки связанные с интеграцией, которые могли возникнуть из за неточности двух окружений.
Какие плюсы у канареечного релиза?
Какие накладные расходы для использования канареечных релизов?
Почему стоит использовать канареечные релизы?
Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.
Фундаментальные проблемы нескольких предпродакшен окружений: при росте инфраструктуры и сложности приложения сложность поддержки тестовых окружений будет расти, увеличивая стоимость поддержки окружения и снижая частоту релизов. Тестовое окружение не может быть идентичным продакшен, а пользовательский трафик не может быть сопоставим.
Организация безопасного тестирования в продакшене. Часть 2
В этой части статьи мы продолжим рассматривать различные виды тестирования в продакшене. Те, кто пропустил первую часть, могут прочитать её здесь. Остальным — добро пожаловать под кат.
Тестирование на продакшене: релиз
Протестировав сервис после развёртывания, его необходимо подготовить к релизу.
Важно отметить, что на этом этапе откат изменений возможен только в ситуациях устойчивого отказа, например:
Канареечное развёртывание
Канареечное развёртывание – это частичный выпуск сервиса в продакшен. По мере прохождения базовой проверки работоспособности в выпущенные части направляются небольшие объёмы текущего трафика продакшен-среды. Результаты работы частей сервиса отслеживаются по мере обработки трафика, показатели сопоставляются с эталонными (не относящимися к канареечным), и если они выходят за пределы допустимых пороговых значений, то выполняется откат к предыдущему состоянию. Хотя этот подход, как правило, применяется при выпуске серверного программного обеспечения, всё более распространённым становится также канареечное тестирование клиентского программного обеспечения.
Различные факторы влияют на то, какой трафик будет использован для канареечного развёртывания. В ряде компаний выпущенные части сервиса сначала получают только внутренний пользовательский трафик (т.н. dogfooding). Если ошибок не наблюдается, то добавляется небольшая часть трафика продакшен-среды, после чего выполняется полноценное развёртывание. Откат к предыдущему состоянию в случае недопустимых результатов канареечного развёртывания рекомендуется выполнять автоматически, и в таких инструментах, как Spinnaker, предусмотрена встроенная поддержка автоматизированного анализа и функции отката.
С канареечным тестированием связаны некоторые проблемы, и в этой статье представлен достаточно полный их обзор.
Мониторинг
Мониторинг является совершенно необходимой процедурой на каждом этапе развёртывания продукта в продакшене, однако особенно важной эта функция будет на этапе релиза. Мониторинг хорошо подходит для получения сведений об общем уровне работоспособности систем. А вот мониторинг всего на свете может быть не самым лучшим решением. Эффективный мониторинг выполняется точечно, что позволяет выявить небольшой набор режимов устойчивого отказа системы или базового набора показателей. Примерами таких режимов отказа могут быть:
«Задача решается при помощи легконастраиваемого компонента для мониторинга, которому сообщается два базовых показателя (99-й перцентиль времени отклика веб-сервера и частота возникновения неустранимых ошибок HTTP), объективно описывающих качество взаимодействия с пользователями».
Набор показателей системы и приложения, в отношении которых выполняется мониторинг на этапе релиза, лучше всего определять во время проектирования системы.
Отслеживание исключений
Речь идёт об отслеживании исключений на этапе релиза, хотя может показаться, что на этапах развёртывания и после релиза это было бы не менее полезным. Средства отслеживания исключений зачастую не гарантируют такой же тщательности, точности и массовости охвата, как некоторые другие инструменты контроля системы, однако они всё равно могут быть очень полезны.
Инструменты с открытым исходным кодом (например, Sentry) отображают расширенные сведения о поступающих запросах и создают стеки данных о трассировке и локальных переменных, что существенно упрощает процесс отладки, обычно заключающийся в просмотре логов событий. Отслеживание исключений также полезно при сортировке и приоритизации проблем, которые не требуют полного отката к предыдущему состоянию (например, пограничный случай, вызывающий исключение).
Шейпинг трафика
Шейпинг трафика (перераспределение трафика) – это не столько самостоятельная форма тестирования, сколько инструмент для поддержки канареечного подхода и поэтапного выпуска нового кода. По сути, шейпинг трафика обеспечивается за счёт обновления конфигурации балансировщика нагрузки, что позволяет постепенно перенаправлять всё больше трафика в новую выпущенную версию.
Этот метод также полезно использовать при поэтапном развёртывании нового программного обеспечения (отдельно от обычного развёртывания). Рассмотрим пример. Компании imgix в июне 2016 года требовалось развернуть принципиально новую архитектуру инфраструктуры. После первого тестирования новой инфраструктуры с помощью некоторого объёма тёмного трафика они приступили к развёртыванию в продакшене, изначально перенаправив примерно 1% трафика продакшен-среды в новый стек. Затем в течение нескольких недель наращивали объёмы данных, поступающих в новый стек (решая попутно возникающие проблемы), пока он не стал обрабатывать 100% трафика.
Популярность архитектуры service mesh обусловила новый всплеск интереса к прокси-серверам. В результате как в старые (nginx, HAProxy), так и в новые (Envoy, Conduit) прокси-серверы добавили поддержку новых функций в попытке обогнать конкурентов. Мне кажется, что будущее, в котором перераспределение трафика от 0 до 100% на этапе релиза продукта выполняется автоматически, уже не за горами.
Тестирование в продакшене: после релиза
Тестирование после релиза осуществляется в виде проверки, выполняемой после успешного релиза кода. На этом этапе можно быть уверенными в том, что код в целом является верным, он успешно выпущен в продакшен и обрабатывает трафик надлежащим образом. Развёрнутый код непосредственно или косвенно используется в реальных условиях, обслуживая реальных клиентов или выполняя задачи, которые оказывают существенное влияние на бизнес.
Цель любого тестирования на этом этапе сводится в основном к проверке работоспособности системы с учётом возможных различных нагрузок и схем трафика. Лучший способ это сделать – собрать документальные свидетельства обо всём, что происходит в продакшене, и использовать их как для отладки, так и для получения полного представления о системе.
Feature Flagging, или Тёмный запуск
Самая старая публикация об успешном применении feature flags (флагов функций), которую мне удалось найти, опубликована почти десять лет назад. На веб-сайте featureflags.io представлено самое полное руководство по этому вопросу.
«Feature flagging представляет собой метод, используемый разработчиками для маркировки новой функции с помощью операторов if-then, что позволяет более тщательно контролировать её релиз. Пометив функцию флагом и изолировав её таким образом, разработчик получает возможность включать и выключать эту функцию независимо от статуса развёртывания. Это позволяет эффективно отделить выпуск функции от развёртывания кода».
Пометив новый код флагом, можно тестировать его производительность и работоспособность в продакшене по мере необходимости. Feature flagging – один из общепринятых типов тестирования в продакшене, он хорошо известен и часто описывается в различных источниках. Гораздо менее известен тот факт, что этот метод можно использовать и в процессе тестирования переноса баз данных или программного обеспечения для персональных систем.
О чём редко пишут авторы статей, так это о лучших методах разработки и применения флагов функций. Неконтролируемое использование флагов может стать серьёзной проблемой. Отсутствие дисциплины в плане удаления неиспользуемых флагов по истечении заданного периода иногда приводит к тому, что приходится проводить полную ревизию и удалять устаревшие флаги, накопленные за месяцы (если не за годы) работы.
A/B-тестирование
A/B-тестирование зачастую выполняется в рамках экспериментального анализа и не рассматривается как тестирование в продакшене. По этой причине A/B-тесты не только широко (иногда даже сомнительным образом) используют, но и активно изучают и описывают (включая статьи о том, что определяет эффективную систему показателей для онлайн-экспериментов). Гораздо реже A/B-тесты используются для тестирования различных конфигураций оборудования или виртуальных машин. Их часто называют «тюнингом» (например, тюнинг JVM), но не относят к типичным A/B-тестам (хотя тюнинг вполне можно рассматривать как тип A/B-теста, выполняемого с тем же уровнем строгости, когда речь идёт об измерениях).
Логи, события, показатели и трассировка
О так называемых «трёх китах наблюдаемости» – логах, показателях и распределённой трассировке можно почитать здесь.
Профилирование
В отдельных случаях для диагностики проблем производительности необходимо использовать профилирование приложений в продакшене. В зависимости от поддерживаемых языков и сред выполнения профилирование может быть довольно простой процедурой, предполагающей добавление всего одной строки кода в приложение ( import _ «net/http/pprof» в случае с Go). С другой стороны, оно может потребовать применения множества инструментов либо тестирования выполняемого процесса методом чёрного ящика и проверки результатов с помощью таких инструментов, как flamegraphs.
Tee-тест
Многие считают такое тестирование чем-то вроде теневого дублирования данных, поскольку в обоих случаях трафик продакшен-среды отправляется в непроизводственные кластеры или процессы. На мой взгляд, разница заключается в том, что использование трафика в целях тестирования несколько отличается от его использования в целях отладки.
Компания Etsy писала в своём блоге об использовании tee-тестов в качестве инструмента верификации (этот пример действительно напоминает теневое дублирование данных).
«Здесь tee можно воспринимать как команду tee в командной строке. Мы написали правило iRule на основе существующего балансировщика нагрузки F5, чтобы клонировать трафик HTTP, направленный в один из пулов, и переадресовать его в другой пул. Таким образом, мы смогли использовать трафик продакшен-среды, направленный в наш API-кластер, и отправить его копию в экспериментальный кластер HHVM, а также в изолированный PHP-кластер для сравнения.
Этот приём оказался очень эффективным. Он позволил нам сравнить производительность двух конфигураций, используя для этого идентичные профили трафика».
Тем не менее, иногда выполнение tee-теста на основе трафика продакшен-среды в автономной системе требуется для проведения отладки. В таких случаях автономную систему можно изменить, чтобы настроить вывод дополнительной диагностической информации или другую процедуру компиляции (например, с помощью инструмента очистки потока), что существенно упрощает процесс устранения неполадок. В таких случаях tee-тесты следует считать, скорее, инструментами отладки, а не проверки.
Раньше в imgix такие типы отладки встречались сравнительно редко, но всё же применялись, особенно если речь шла о проблемах с отладкой приложений, чувствительных к задержке.
Например, ниже приведено аналитическое описание одного из таких инцидентов, произошедших в 2015 году. Ошибка 400 возникала настолько редко, что её почти не видели, когда пытались воспроизвести проблему. Она появлялась буквально в нескольких случаях из миллиарда. За день их было совсем немного. В итоге оказалось, что надёжно воспроизвести проблему просто невозможно, поэтому потребовалось выполнить отладку с использованием рабочего трафика, чтобы появился шанс отследить возникновение этой ошибки. Вот что написал об этом мой бывший коллега:
«Я выбрал библиотеку, которая должна была быть внутренней, но в конечном счёте пришлось создать собственную на основе библиотеки, предоставленной системой. В версии, предоставленной системой, периодически возникала ошибка, которая никак не проявлялась, пока объём трафика был небольшим. Однако истинной проблемой стало усечённое имя в заголовке.
За следующие два дня я подробно изучил проблему, связанную с повышенной частотой возникновения ложных ошибок 400. Ошибка проявлялась в весьма незначительном количестве запросов, а проблемы такого типа достаточно сложно поддаются диагностике. Всё это было похоже на пресловутую иголку в стоге сена: проблема встречалась в одном случае на миллиард.
Первым шагом в обнаружении источника ошибок было получение всех необработанных исходных данных HTTP-запросов, которые приводили к некорректному отклику. Чтобы выполнить tee-тест входящего трафика при подключении к сокету, я добавил конечную точку сокета домена Unix на сервер визуализации. Идея заключалась в том, чтобы позволить нам быстро и без особых затрат включать и отключать поток тёмного трафика и проводить тестирование непосредственно на компьютере разработчика. Чтобы избежать проблем в продакшене, требовалось разрывать соединение, если возникала проблема back-pressure. Т.е. если дубликат не справлялся с задачей, он отключался. Этот сокет был весьма полезным в ряде случаев во время разработки. На этот раз, однако, мы использовали его для сбора входящего трафика на выбранных серверах, надеясь получить достаточное количество запросов, чтобы выявить закономерность, которая привела к возникновению ложных ошибок 400. С помощью dsh и netcat мне удалось сравнительно легко вывести входящий трафик в локальный файл.
Большая часть среды была потрачена на сбор этих данных. Как только у нас накопилось достаточно данных, я смог использовать netcat, чтобы воспроизвести их в локальной системе, конфигурация которой была изменена для вывода большого объёма информации об отладке. И всё прошло отлично. Следующий шаг – воспроизведение данных на максимально высокой скорости. В этом случае цикл с проверкой условия отправлял необработанные запросы поочерёдно. Примерно через два часа мне удалось достигнуть желаемого результата. Данные в логах демонстрировали отсутствие заголовка!
Для передачи заголовков я использую красно-чёрное дерево. Такие структуры рассматривают сравнимость как идентичность, что само по себе очень полезно при наличии специальных требований к ключам: в нашем случае заголовки HTTP не учитывали регистр. Сначала мы думали, что проблема была в листовом узле используемой библиотеки. Порядок добавления действительно влияет на порядок построения базового дерева, а балансировка красно-чёрного дерева — довольно сложный процесс. И хотя эта ситуация была маловероятной, она не была невозможной. Я переключился на другую реализацию красно-чёрного дерева. Оно было исправлено несколько лет назад, так что я решил встроить его непосредственно в исходник, чтобы точно получить ту версию, которая была необходима. Тем не менее, сборка выбрала иную версию, и поскольку я рассчитывал на более новую, то получил в итоге некорректное поведение.
Из-за этого система визуализации выдавала ошибки 500, что приводило к прерыванию цикла. Вот почему ошибка возникала только с течением времени. После циклической обработки нескольких сборок трафик из них был перенаправлен по другому маршруту, что увеличивало масштаб проблемы на данном сервере. Моё предположение, что проблема заключалась в библиотеке, оказалось неверным, и обратное переключение позволило устранить ошибки 500.
Я вернулся к ошибкам 400: всё ещё оставалась проблема, связанная с ошибкой, для обнаружения которой понадобилось примерно два часа. Смена библиотеки, очевидно, не решала проблему, но я был уверен в том, что выбранная библиотека достаточно надёжна. Не осознавая ошибочность выбора, я ничего не менял. Изучив ситуацию более подробно, я понял, что верное значение хранилось в односимвольном заголовке (например, «h: 12345»). До меня наконец дошло, что h — концевой символ заголовка Content-Length. Вновь просмотрев данные, я понял, что заголовок Content-Length был пустым.
В итоге всё дело было в ошибке смещения на единицу при считывании заголовков. Анализатор HTTP nginx/joyent создаёт частичные данные, и каждый раз, когда поле частичного заголовка оказывалось на один символ короче, чем нужно, я отправлял заголовок без значения и впоследствии получал поле односимвольного заголовка, содержащее верное значение. Это довольно редкая комбинация, поэтому её срабатывание занимает такое продолжительное время. Так что я увеличил объёмы сбора данных при каждом появлении односимвольного заголовка, применил предложенное исправление и успешно выполнял сценарий в течение нескольких часов.
Конечно, могли обнаружиться ещё какие-нибудь подводные камни с упомянутой неисправностью библиотеки, но обе ошибки были устранены».
Инженерам, занимающимся разработкой чувствительных к задержке приложений, нужна возможность отладки с использованием захваченного динамического трафика, поскольку зачастую возникают ошибки, которые невозможно воспроизвести при юнит-тестировании или обнаружить с помощью инструмента мониторинга (особенно если при логировании есть серьёзная задержка).
Подход Chaos Engineering
Chaos Engineering – это подход, основанный на проведении экспериментов над распределённой системой с целью подтвердить её способность противостоять хаотичным условиям продакшен-среды.
Метод Chaos Engineering, впервые ставший известным благодаря инструменту Chaos Monkey от компании Netflix, теперь превратился в самостоятельную дисциплину. Термин Chaos Engineering появился совсем недавно, однако тестирование методом внесения неисправностей — давно существующая практика.
Термином «хаотическое тестирование» обозначаются следующие приемы:
«Особенно важен тот факт, что Chaos Engineering считается научной дисциплиной. В рамках этой дисциплины применяются высокоточные инженерные процессы.
Задача Chaos Engineering — сообщить пользователям что-то новое об уязвимостях системы путём проведения экспериментов над ней. Необходимо выявить все скрытые проблемы, которые могли возникнуть в продакшене, ещё до того, как они вызовут масштабный сбой. Только после этого вы сможете эффективно устранить все слабые места в системе и сделать её действительно отказоустойчивой».
Простой и безопасный способ автоматизации канареечных деплоев с помощью 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), за все эти потрясающие схемы деплоя.