Dark Launch в Istio: секретные службы

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

И Istio вместе OpenShift и Kubernetes превращают развертывание микросервисов в дело по-настоящему скучное и предсказуемое – и это прекрасно. Об этом и о многом другом поговорим в четвертом и последнем посте из серии про Istio.

Когда скукотища – это правильно

В нашем случае скукотища возникает только в конечной фазе, когда остается только сидеть и наблюдать за процессом. Но для этого надо всё предварительно настроить, и здесь вас ждет много интересного.

При развертывании новой версии вашего софта стоит рассмотреть все варианты минимизации рисков. Работа в параллельном режиме – это очень мощный и проверенный способ тестирования, и Istio позволяет задействовать для этого «секретную службу» (скрытую от посторонних глаз версию вашего микросервиса) без вмешательства в работу продакшн-системы. Для этого есть даже специальный термин – «Тайный запуск» (Dark Launch), который в свою очередь активируется функцией с не менее шпионским названием «зеркалирование трафика».

Обратите внимание, что в первом предложении предыдущего абзаца используется термин «развертывание» (deploy), а не «запуск» (release). Вы действительно должны иметь возможность развертывать – и, разумеется, использовать – свой микросервис так часто, как пожелаете. Этот сервис должен быть способен принимать и обрабатывать трафик, выдавать результаты, а также писать в логи и мониториться. Но при этом сам этот сервис вовсе необязательно выпускать в продакшн. Развертывание и выпуск ПО – это не всегда одно и то же. Развертывание вы можете выполнять всегда, когда захотите, а вот выпуск – только тогда, когда будете окончательно готовы.

Организация скуки – это интересно

Взгляните на следующее правило маршрутизации Istio, которое направляет все HTTP-запросы на микросервис recommendation v1 (все примеры взяты из Istio Tutorial GitHub repo), одновременно зеркалируя их на микросервис recommendation v2:

Обратите внимание на метку mirror: внизу скрина – именно она задает зеркалирование трафика. Да, вот так просто!

Результатом работы этого правила станет то, что ваша продакшн-система (v1) будет по-прежнему обрабатывать поступающие запросы, но сами запросы при этом будут асинхронно зеркалиться на v2, то есть туда будут уходить их полные дубликаты. Таким образом, вы сможете протестировать работу v2 в реальных условиях – на настоящих данных и трафике, – никак не вмешиваясь в работу продакшн-системы. Превращает ли это организацию тестирования в скукотищу? Да, безусловно. Но делается это интересно.

Добавим драмы

Обратите внимание, что в коде v2 надо предусмотреть ситуации, когда поступающие запросы могут приводить к изменению данных. Сами запросы зеркалятся легко и прозрачно, но вот выбор способа обработки в тестовой остается за вами – а вот это уже немного волнительно.

Повторим важный момент

Тайный запуск с зеркалированием трафика (Dark Launch/Request Mirroring) можно выполнять, никак не затрагивая код.

Пища для размышления

А что, если место зеркалирования запросов отправлять часть из них не на v1, а на v2? Например, один процент от всех запросов или только запросы от определенной группы пользователей. И потом, уже глядя на то, как работает v2, постепенно переводить на новую версию все запросы. Или наоборот вернуть всё на v1, если с v2 что-то пойдет не так. Кажется, это называется Canary Deployment («канареечное развертывание» – термин восходит к горному делу, и будь у него русское происхождение, он вероятно содержал бы отсылку к кошкам), и сейчас мы это рассмотрим подробнее.

Canary Deployment в Istio: упрощаем ввод в строй

Осторожно и постепенно

Суть модели развертывания Canary Deployment предельно проста: при запуске новой версии своего софта (в нашем случае – микросервиса) вы сначала даете к ней доступ небольшой группе пользователей. Если всё идет нормально, вы медленно увеличиваете эту группу до тех пор, пока новая версия не начинает барахлить, или – если этого так и не происходит – в итоге переводите на нее всех пользователей. Продуманно и постепенно вводя в строй новую версию и контролируемо переключая на нее пользователей, можно снизить риски и максимизировать обратную связь.

Разумеется, Istio упрощает Canary Deployment, предлагая сразу несколько хороших вариантов для интеллектуальной маршрутизации запросов. И да, все это можно сделать, никак не трогая ваш исходный код.

Фильтруем браузер

Один из самых простых критериев маршрутизации – это перенаправление в зависимости от браузера. Допустим, вы хотите, чтобы на v2 уходили только запросы из браузеров Safari. Вот как это делается:

Применим это правило маршрутизации и затем командой curl будем в цикле имитировать реальные запросы к микросервису. Как видно на скриншоте, все они уходят на v1:

А где же трафик на v2? Поскольку в нашем примере все запросы шли только из нашей же командной строки, то его попросту нет. Но обратите внимание на нижние строчки на скрине выше: это реакция на то, что мы выполнили запрос из браузера Safari, который в свою очередь выдал вот что:

Неограниченная власть

Мы уже писали, что регулярные выражения дают очень мощные возможности для маршрутизации запросов. Взгляните на следующий пример (думаем, вы и сами поймете, что он делает):

Теперь вы, вероятно, уже представляете, на что способны регулярные выражения.

Действуйте умно

Умная маршрутизация, в частности обработка заголовки пакетов с использованием регулярных выражений, позволяет рулить трафиком так, как вам хочется. И это значительно упрощает ввод в строй нового кода – это просто, это не требует изменения самого кода, и при необходимости все можно быстро вернуть как было.

Заинтересовались?

Загорелись желанием поэкспериментировать с Istio, Kubernetes и OpenShift на своем компьютере? Команда Red Hat Developer Team подготовила отличный учебник по этой теме и выложила в общий доступ все сопутствующие файлы. Так что вперед, и ни в чем себе не отказывайте.
 

Istio Egress: выход через сувенирную лавку

Применяя Istio вместе с Red Hat OpenShift и Kubernetes, можно значительно облегчить себе жизнь с микросервисами. Сервисная сетка Istio упрятана внутрь Kubernetes’овских pod’ов, а ваш код выполняется (в основном) изолированно. Производительность, простота изменения, трассировка и прочее – все это легко использовать именно за счет применения sidecar-контейнеров. Но что делать, если ваш микросервис должен общаться с другим сервисами, которые расположены за пределами вашей системы OpenShift-Kubernetes?

Здесь на помощь приходит Istio Egress. Если в двух словах, то он просто позволяет получить доступ к ресурсам (читай: «сервисам»), которые не входят в вашу систему Kubernetes’овских pod’ов. Если не выполнять дополнительную настройку, то в среде Istio Egress трафик маршрутизируется только внутри кластера pod’ов и между такими кластерами исходя из внутренних IP-таблиц. И такое закукливание прекрасно работает до тех пор, пока вам не нужен доступ к сервисам снаружи.

Egress позволяет обойти вышеупомянутые IP-таблицы, либо на основе правил Egress, либо для диапазона IP-адресов.

Допустим, у нас есть Java-программа, которая выполняет GET-запрос к httpbin.org/headers.

(httpbin.org – это просто удобный ресурс для тестирования исходящих сервис-запросов.)

Если ввести в командной строке curl http://httpbin.org/headers, мы увидим следующее:

Или можно открыть этот же адрес в браузере:

Как видим, расположенный там сервис просто возвращает переданные ему заголовки.

Импортозамещаем в лоб

Теперь возьмем Java-код этого внешнего по отношению к нашей системе сервиса и запустим его у себя, где, напомним, стоит Istio. (Вы можете сделать это самостоятельно, обратившись к нашему учебнику по Istio.) Выполнив сборку соответствующего образа и запустив его на платформе OpenShift, мы вызовем этот сервис командой curl egresshttpbin-istioegress.$(minishift ip).nip.io, после чего увидим на экране вот что:

Опа, а что произошло? Всё же только что работало. Что значит Not Found? Мы же только что сделали для него curl.

Расширяем IP-таблицы на весь интернет

Винить (или благодарить) за это надо Istio. Ведь Istio – это просто sidecar- контейнеры, который отвечают за обнаружение и маршрутизацию (ну и за массу других вещей, о которых мы рассказывали ранее). По этой причине IP-таблицы знают только о том, что находится внутри вашей системы кластеров. А httpbin.org расположен снаружи и, следовательно, недоступен. И вот тут на помощь приходит Istio Egress – без малейших изменений в вашем исходном коде.

Приведенное ниже Egress-правило заставляет Istio искать (если надо, то и во всем всемирном интернете) нужный сервис, в данном случае, httpbin.org. Как видно из этого файла (egress_httpbin.yml), функциональность здесь довольно простая:

Осталось только применить это правило:

istioctl create -f egress_httpbin.yml -n istioegress

Просмотреть правила Egress можно командой istioctl get egressrules:

И наконец, опять запускаем команду curl – и видим, что все работает:

Мыслим открыто

Как видите, Istio позволяет организовать взаимодействие и с внешним миром. Иными словами, вы можете всё так же создавать сервисы OpenShift и рулить ими через Kubernetes, держа всё в pod’ах, которые масштабируются вверх-вниз по мере надобности. И при этом вы спокойно можете обращаться к внешним по отношению к вашей среде сервисам. И да, еще раз повторимся, что все это можно делать, никак не трогая ваш код.

Это был последний пост из серии по Istio. Оставайтесь с нами – впереди много интересного!

Источник: habr.com