„Опасността е моето второ име“, казваше Остин Пауърс, човекът-мистерия с международен мащаб. Но нещата, които са ценени от суперагентите и разузнаването, съвсем не подхождат на компютърните служби, където скуката е много по-добра от опасностите.
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 е внедрена в pod-овете на Kubernetes, а вашият код се изпълнява (в основната част) изолирано. Производителността, леснотата на промени, трасировка и други – всичко това е лесно за използване именно благодарение на прилагането на sidecar контейнери. Но какво да правим, ако вашият микросервиз трябва да комуникира с другите услуги, разположени извън вашата система OpenShift-Kubernetes?
Тук на помощ идва Istio Egress. С две думи, той просто позволява достъп до ресурси (чети: „услуги“), които не влизат в вашата система с подове на Kubernetes. Ако не се извърши допълнителна конфигурация, в средата на Istio Egress трафикът се маршрутизира само вътре в кластера на подовете и между такива клъстери на базата на вътрешните 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:
И накрая стартираме пакета отново curl – и виждаме, че всичко работи:
Мислим открито
Както виждате, Istio позволява взаимодействие и с външния свят. С други думи, можете да създавате услуги в OpenShift и да ги управлявате чрез Kubernetes, като държите всичко в pod-ове, които мащабират нагоре-надолу при необходимост. А в същото време спокойно можете да се свързвате с услуги, които са извън вашата среда. И да, да повторим, че всичко това може да се прави, без да засягате кода си.
Това беше последната публикация от серията за Istio. Останете с нас – напред има много интересни неща!
Източник: habr.com
