Реализация Canary-релизов с помощью Apache APISIX

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

В этом посте я хотел бы кратко описать это введение, объяснить различные способы определения дроби и показать, как ее выполнить с помощью Apache APISIX.

Введение в канареечные релизы

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

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

Несколько лет назад мы применили этот подход к выпуску новой версии программного обеспечения. Аналогия звучит так: майнеры — это команда эксплуатации, развертывающая версию, канарейка — это все инструменты для измерения воздействия релиза, а газ — это (критическая) ошибка.

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

Релизы Canary и флаги функций

Обратите внимание, что канареечные выпуски — не единственный способ управления риском выпуска нового кода. Например, флаги функций — еще один популярный способ:

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

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

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

Подходы к канареечным релизам

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

Первым шагом может быть разрешение только проверенным пользователям проверять, что развертывание в производственной среде работает должным образом. В этом случае вы можете перенаправить на новую версию только определенный набор внутренних пользователей, например тестировщиков. Если вы заранее знаете людей и система аутентифицирует пользователей, вы можете настроить их по личности; если нет, вам нужно вернуться к какому-то общему способу, например , к заголовкам HTTP — X-Canary: Let-Me-Go-To-v2 .

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

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

Опять же, отслеживайте и сравнивайте на этом этапе.

Все девять ярдов

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

Вот как это сделать с помощью Apache APISIX. Apache APISIX предлагает архитектуру на основе плагинов и плагин, отвечающий нашим потребностям, а именно плагин traffic-split .

Плагин traffic-split можно использовать для динамического направления частей трафика на различные восходящие сервисы.

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

-- разделение трафика

Начнем с некоторых основных восходящих потоков, по одному для каждой версии:

 upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1

Мы можем использовать плагин traffic-split , чтобы перенаправить большую часть трафика на v1 и часть на v2:

 routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3

1. Определите всеобъемлющий маршрут
2. Настройте разделение трафика; вот, весы
3. Перенаправить 99% трафика на v1 и 1% на v1. Обратите внимание, что веса указаны относительно друг друга. Для достижения 50/50 можно установить веса 1 и 1, 3 и 3, 50 и 50 и т.д.

Опять же, мы все контролируем и следим за тем, чтобы результаты соответствовали ожиданиям. Затем мы можем увеличить долю трафика, пересылаемого на v2, например :

 routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1

1. Увеличить трафик до v2 до 5%

Обратите внимание, что Apache APISIX перезагружает изменения в файл выше каждую секунду. Таким образом, вы разделяете трафик практически в реальном времени. Альтернативно вы можете использовать API администратора для достижения того же.

Более контролируемые выпуски

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

 routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95

1. Разделяйте трафик только в том случае, если HTTP-заголовок X-Canary имеет настроенное значение.

Следующая команда всегда перенаправляет на v1:

 curl http://localhost:9080

Следующая команда также всегда перенаправляет на v1:

 curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080

Следующая команда разделяет трафик в соответствии с настроенными весами, т. е . 95/5:

 curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080

Заключение

В этом посте рассказывается о канареечных выпусках и о том, как их настроить через Apache APISIX. Вы можете начать с нескольких маршрутов с разными приоритетами и перейти к плагину traffic-split . Последний можно даже настроить дополнительно, чтобы обеспечить более сложные варианты использования.

Полный исходный код этого поста можно найти на GitHub .

Чтобы пойти дальше:

• Внедрение решения canary-релиза на базе Apache APISIX.
• Canary-релиз в Kubernetes с использованием Apache APISIX Ingress
• Плавный выпуск Canary с использованием входного контроллера APISIX с флаггером