"Небяспека - маё другое імя", - гаварыў Осцін Паўэрс, чалавек-загадка міжнароднага маштабу. Але тое, што ў пашане ў суперагентаў і спецслужбаў, зусім не падыходзіць для службаў камп'ютарных, дзе нуда значна лепшая за небяспекі.
І 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