"Небезпека - моє друге ім'я", - говорив Остін Пауерс, людина-загадка міжнародного масштабу. Але те, що в пошані у суперагентів і спецслужб, зовсім не годиться для служб комп'ютерних, де нудьги набагато кращі за небезпеки.
І Istio разом OpenShift і Kubernetes перетворюють розгортання мікросервісів у справу по-справжньому нудне та передбачуване – і це чудово. Про це і багато іншого поговоримо в четвертому і останньому пості з серії про Istio.
Коли нудьга – це правильно
У нашому випадку нудьга виникає тільки в кінцевій фазі, коли залишається тільки сидіти і спостерігати за процесом. Але для цього треба все попередньо налаштувати, і тут на вас чекає багато цікавого.
При розгортанні нової версії вашого софту варто розглянути всі варіанти мінімізації ризиків. Робота в паралельному режимі – це дуже потужний та перевірений спосіб тестування, і Istio дозволяє задіяти для цього «секретну службу» (приховану від сторонніх очей версію вашого мікросервісу) без втручання у роботу продакшн-системи. Для цього є навіть спеціальний термін - "Таємний запуск" (Dark Launch), який у свою чергу активується функцією з не менш шпигунською назвою "дзеркалювання трафіку".
Зверніть увагу, що у першому реченні попереднього абзацу використовується термін «розгортання» (deploy), а не «запуск» (release). Ви дійсно повинні мати можливість розгортати - і, зрозуміло, використовувати свій мікросервіс так часто, як забажаєте. Цей сервіс повинен бути здатний приймати та обробляти трафік, видавати результати, а також писати в логі та моніторитися. Але при цьому сам цей сервіс необов'язково випускати в продакшн. Розгортання та випуск ПЗ – це не завжди одне й те саме. Розгортання ви можете виконувати завжди, коли захочете, а ось випуск – тільки тоді, коли остаточно будете готові.
Організація нудьги – це цікаво
Погляньте на наступне правило маршрутизації Istio, яке направляє всі HTTP-запити на мікросервіс recommendation v1 (всі приклади взяті з ), одночасно дзеркуючи їх на мікросервіс 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 на своєму комп'ютері? Команда підготувала чудовий з цієї теми і виклала у спільний доступ усі супутні файли. Так що вперед і ні в чому собі не відмовляйте.
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. (Ви можете зробити це самостійно, звернувшись до .) Виконавши збірку відповідного образу та запустивши його на платформі 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:
І нарешті, знову запускаємо команду витися - І бачимо, що все працює:
Думаємо відкрито
Як бачите, Istio дозволяє організувати взаємодію та із зовнішнім світом. Іншими словами, ви можете створювати сервіси OpenShift і керувати ними через Kubernetes, тримаючи все в pod'ах, які масштабуються вгору-вниз при необхідності. І при цьому ви можете спокійно звертатися до зовнішніх по відношенню до вашого середовища сервісів. І так, ще раз повторимося, що все це можна робити, не чіпаючи ваш код.
Це був останній пост із серії Istio. Залишайтесь з нами – попереду багато цікавого!
Джерело: habr.com