В двух словах, идея canary-релизов состоит в том, чтобы предоставить новую версию программного обеспечения лишь части пользователей, проанализировать результаты и решить, продолжать или нет. Если результаты не соответствуют ожиданиям, откатитесь назад; если да, увеличивайте количество пользователей, пока все пользователи не получат выгоду от новой версии.
В этом посте я хотел бы кратко описать это введение, объяснить различные способы определения дроби и показать, как ее выполнить с помощью Apache APISIX.
Термин «канарейка» происходит из угольной промышленности. При добыче полезных ископаемых нередко выделяются токсичные газы: в небольшом замкнутом пространстве это может означать быструю смерть. Хуже того, газ может не иметь запаха, поэтому шахтеры будут дышать им, пока не станет слишком поздно уходить. Угарный газ довольно распространен в угольных шахтах и не обнаруживается органами чувств человека.
По этой причине шахтеры привозили с собой под землю канареек. Если канарейка внезапно упадет замертво, велика вероятность, что такой газовый карман был прорван, и пора было покинуть это место.
Несколько лет назад мы применили этот подход к выпуску новой версии программного обеспечения. Аналогия звучит так: майнеры — это команда эксплуатации, развертывающая версию, канарейка — это все инструменты для измерения воздействия релиза, а газ — это (критическая) ошибка.
Самая важная часть заключается в том, что вам необходимо измерить влияние выпуска, включая частоту сбоев, коды состояния HTTP и т. д., и сравнить их с показателями предыдущей версии. Это выходит за рамки данной статьи, но, опять же, это важно, если вы хотите извлечь выгоду из канареечных выпусков. Вторая по важности часть — возможность быстрого отката, если новая версия глючит.
Обратите внимание, что канареечные выпуски — не единственный способ управления риском выпуска нового кода. Например, флаги функций — еще один популярный способ:
Флаги функций представляют собой более гибкий подход (в истинном смысле этого слова) к откатам. Если одна функция из 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
Опять же, мы все контролируем и следим за тем, чтобы результаты соответствовали ожиданиям. Затем мы можем увеличить долю трафика, пересылаемого на v2, например :
routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1
Обратите внимание, что 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
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 .
Чтобы пойти дальше:
Первоначально опубликовано на сайте A Java Geek 3 декабря 2023 г.