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

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

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

Введение в Canary-релизы

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

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

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

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

Выпуски Canary и флаги функций

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

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

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

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

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

Идея 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 % трафика на версию 1 и 1 % на версию 1. Обратите внимание, что веса указаны относительно друг друга. Для достижения 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. Увеличить трафик до версии 2 до 5 %

Обратите внимание, что Apache APISIX перезагружает изменения в файл выше каждую секунду. Таким образом, вы разделяете трафик практически в реальном времени. Альтернативно вы можете использовать Admin 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 Ingress Controller с Flagger

---

:::информация Первоначально опубликовано на сайте A Java Geek 3 декабря 2023 г.

:::

---

Оригинал