„Опасността е второто ми име“, обичаше да казва Остин Пауърс, международен човек на мистериите. Но това, което е високо ценено от суперагентите и разузнавателните служби, изобщо не е подходящо за компютърните услуги, където скуката е много по-добра от опасността.
А Istio, заедно с OpenShift и Kubernetes, прави внедряването на микроуслуги наистина скучно и предвидимо – и това е страхотно. Ще говорим за това и много повече в четвъртата и последна публикация от поредицата на Istio.
Когато скуката е правилна
В нашия случай скуката настъпва едва в крайната фаза, когато остава само да седнем и да наблюдаваме процеса. Но за това първо трябва да конфигурирате всичко и тук ви очакват много интересни неща.
Когато внедрявате нова версия на вашия софтуер, струва си да разгледате всички опции за минимизиране на рисковете. Изпълнението паралелно е много мощен и доказан начин за тестване и Istio ви позволява да използвате „тайна услуга“ (скрита версия на вашата микроуслуга), за да направите това, без да се намесвате в производствената система. Дори има специален термин за това - “Dark Launch”, който от своя страна се активира от функция със също толкова шпионско име “traffic mirroring”.
Моля, обърнете внимание, че първото изречение на предишния параграф използва термина „разгръщане“, а не „освобождаване“. Трябва наистина да можете да внедрите — и, разбира се, да използвате — вашата микроуслуга толкова често, колкото искате. Тази услуга трябва да може да получава и обработва трафик, да произвежда резултати, както и да записва в регистрационни файлове и да наблюдава. Но в същото време самата услуга не е задължително да бъде пусната в производство. Внедряването и пускането на софтуер не винаги е едно и също нещо. Можете да разположите, когато пожелаете, но да пуснете само когато сте готови.
Организирането на скуката е интересно
Обърнете внимание на следното правило за маршрутизиране на Istio, което маршрутизира всички HTTP заявки към микроуслугата препоръка v1 (всички примери са взети от ), като едновременно с това ги отразява към микроуслугата препоръка v2:
Обърнете внимание на етикета mirror: в долната част на екрана - това е, което задава отразяване на трафика. Да, толкова е просто!
Резултатът от това правило ще бъде, че вашата производствена система (v1) ще продължи да обработва входящи заявки, но самите заявки ще бъдат асинхронно огледални към v2, тоест техните пълни дубликати ще отидат там. По този начин можете да тествате v2 в реални условия - върху реални данни и трафик - без да се намесвате по никакъв начин в работата на производствената система. Това прави ли организирането на тестове скучно? Да, определено. Но е направено по интересен начин.
Нека добавим драма
Моля, обърнете внимание, че в кода v2 е необходимо да се предвидят ситуации, при които входящите заявки могат да доведат до промени в данните. Самите заявки се отразяват лесно и прозрачно, но изборът на метод на обработка в теста зависи от вас – и това е малко притеснително.
Нека повторим важна точка
Тайно стартиране с дублиране на трафика (Dark Launch/Request Mirroring) може да се извърши, без да се засяга кодът по никакъв начин.
Храна за размисъл
Какво ще стане, ако мястото, където се отразяват заявките, изпраща някои от тях не към v1, а към v2? Например един процент от всички заявки или само заявки от определена група потребители. И след това, вече гледайки как работи v2, постепенно прехвърлете всички заявки към новата версия. Или обратното, върнете всичко към v1, ако нещо се обърка с v2. Мисля, че се казва Canary Deployment. , и ако беше с руски произход сигурно щеше да има препратка към ), и сега ще разгледаме това по-подробно.
Внедряване на Canary в Istio: опростяване на въвеждането в експлоатация
Внимателно и постепенно
Същността на модела за внедряване на Canary Deployment е изключително проста: когато стартирате нова версия на вашия софтуер (в нашия случай микроуслуга), първо давате достъп до нея на малка група потребители. Ако всичко върви добре, бавно увеличавате тази група, докато новата версия започне да действа, или - ако не стане - евентуално да мигрирате всички потребители към нея. Чрез обмислено и постепенно въвеждане на нова версия и превключване на потребителите към нея по контролиран начин, можете да намалите рисковете и да увеличите максимално обратната връзка.
Разбира се, Istio опростява Canary Deployment, като предлага няколко добри опции за интелигентно маршрутизиране на заявки. И да, всичко това може да се направи, без да докосвате изходния код по никакъв начин.
Филтриране на браузъра
Един от най-простите критерии за маршрутизиране е базираното на браузъра пренасочване. Да приемем, че искате само заявки от браузъри Safari да преминават към v2. Ето как се прави:
Нека приложим това правило за маршрутизиране и след това използваме командата curl Ще симулираме реални заявки към микроуслугата в цикъл. Както можете да видите на екранната снимка, всички те отиват на v1:
Къде е трафикът на v2? Тъй като в нашия пример всички заявки идват само от нашия собствен команден ред, той просто не съществува. Но обърнете внимание на долните редове на екрана по-горе: това е реакция на факта, че изпълнихме заявка от браузъра Safari, която на свой ред създаде това:
Неограничена мощност
Вече писахме, че регулярните изрази предоставят много мощни възможности за маршрутизиране на заявки. Разгледайте следния пример (мислим, че ще разберете какво прави):
Досега вероятно имате представа какво могат да правят регулярните изрази.
Действайте разумно
Интелигентното маршрутизиране, по-специално обработката на заглавки на пакети с помощта на регулярни изрази, ви позволява да насочвате трафика по желания от вас начин. И това значително опростява внедряването на нов код - това е просто, не изисква промяна на самия код и ако е необходимо, всичко може бързо да се върне както е било.
Интересувате ли се?
Имате ли желание да експериментирате с Istio, Kubernetes и OpenShift на вашия компютър? Екип подготви отлично по тази тема и направи всички придружаващи файлове публично достъпни. Така че давай и не си отказвай нищо.
Изход от Istio: излезте през магазина за сувенири
Като използвате Istio заедно с Red Hat OpenShift и Kubernetes, можете да направите живота си с микроуслуги много по-лесен. Сервизната мрежа на Istio е скрита в подовете на Kubernetes и вашият код работи (най-вече) изолирано. Ефективност, лесна смяна, проследяване и т.н. – всичко това е лесно за използване благодарение на използването на контейнери с кош. Но какво ще стане, ако вашата микроуслуга трябва да комуникира с други услуги, които се намират извън вашата система OpenShift-Kubernetes?
Тук Istio Egress идва на помощ. Накратко, той просто ви позволява достъп до ресурси (прочетете: „услуги“), които не са част от вашата система от Kubernetes pods. Ако не извършите допълнителна конфигурация, тогава в средата на Istio Egress трафикът се насочва само в рамките на клъстер от подове и между такива клъстери въз основа на вътрешни IP таблици. И такова кученце работи чудесно, стига да не се нуждаете от достъп до услуги отвън.
Egress ви позволява да заобиколите горните IP таблици, или въз основа на правила за изход, или на набор от IP адреси.
Да приемем, че имаме Java програма, която прави GET заявка до httpbin.org/headers.
(httpbin.org е просто удобен ресурс за тестване на изходящи заявки за услуги.)
Ако въведете в командния ред curl http://httpbin.org/headers, ще видим следното:
Или можете да отворите същия адрес в браузъра:
Както можете да видите, услугата, разположена там, просто връща заглавките, предадени към нея.
Заменяме директно вноса
Сега нека вземем Java кода на тази услуга, външен за нашата система, и да го стартираме самостоятелно, където, припомнете си, е инсталиран Istio. (Можете да направите това сами, като се свържете с .) След като изградим подходящото изображение и го стартираме на платформата OpenShift, ще извикаме тази услуга с командата curl egresshttpbin-istioegress.$(minishift ip).nip.io, след което ще видим това на екрана:
Опа, какво стана? Просто всичко работеше. Какво означава Не е намерено? Просто го направихме за него curl.
Разширяване на IP таблици до целия Интернет
Istio трябва да бъде обвинен (или благодарен) за това. В края на краищата, Istio е просто контейнер с кош, който отговаря за откриването и маршрутизирането (и много други неща, за които говорихме по-рано). Поради тази причина IP таблиците знаят само какво има във вашата клъстерна система. А httpbin.org се намира отвън и следователно е недостъпен. И тук Istio Egress идва на помощ - без ни най-малка промяна на вашия изходен код.
Правилото за излизане по-долу принуждава Istio да търси (ако е необходимо, след това в целия Интернет) необходимата услуга, в този случай httpbin.org. Както можете да видите от този файл (egress_httpbin.yml), функционалността тук е доста проста:
Остава само да приложите това правило:
istioctl create -f egress_httpbin.yml -n istioegress
Можете да видите правилата за излизане с командата istioctl get egressrules:
И накрая, изпълняваме командата отново Curl – и виждаме, че всичко работи:
Мислим открито
Както можете да видите, Istio ви позволява да организирате взаимодействие с външния свят. С други думи, все още можете да създавате услуги на OpenShift и да ги управлявате чрез Kubernetes, като държите всичко в подове, които се мащабират нагоре и надолу според нуждите. И в същото време можете безопасно да осъществявате достъп до външни за вашата среда услуги. И да, повтаряме още веднъж, че всичко това може да се направи, без да пипате кода си по никакъв начин.
Това беше последната публикация от поредицата на Istio. Очаквайте - предстоят много интересни неща!
Източник: www.habr.com