"Danger is my middle name," sabi ni Austin Powers, ang international man of mystery. Ngunit kung ano ang pinapaboran ng mga super-agents at mga ahensya ng paniktik ay ganap na hindi angkop para sa cybersecurity, kung saan ang pagkabagot ay mas pinipili kaysa sa panganib.
Ang Istio, kasama ang OpenShift at Kubernetes, ay ginagawang tunay na boring at predictable ang pag-deploy ng microservice—at iyon ay isang kahanga-hangang bagay. Tatalakayin natin ito at marami pang iba sa ikaapat at huling post sa seryeng Istio.
Kapag tama na ang pagkabagot
Sa aming kaso, ang pagkabagot ay nangyayari lamang sa huling yugto, kapag ang magagawa mo lang ay umupo at panoorin ang proseso. Ngunit para magawa iyon, kailangan mo munang i-set up ang lahat, at maraming kawili-wiling bagay ang naghihintay para sa iyo doon.
Kapag nagde-deploy ng bagong bersyon ng iyong software, sulit na isaalang-alang ang lahat ng opsyon sa pagbabawas ng panganib. Ang pagpapatakbo nang magkatulad ay isang napakalakas at napatunayang paraan ng pagsubok, at pinapayagan ka ng Istio na gumamit ng isang "lihim na serbisyo" (isang nakatagong bersyon ng iyong microservice) para sa layuning ito nang hindi nakakasagabal sa sistema ng produksyon. Mayroong kahit isang espesyal na termino para dito: "Madilim na Paglulunsad," na pinagana naman ng isang tampok na may pantay na pangalan ng "traffic mirroring."
Tandaan na ang unang pangungusap ng nakaraang talata ay gumagamit ng terminong "deploy" sa halip na "release." Talagang magagawa mong i-deploy—at, siyempre, gamitin—ang iyong microservice nang madalas hangga't gusto mo. Ang serbisyong ito ay dapat na makatanggap at makapagproseso ng trapiko, makagawa ng mga resulta, at makapag-log at masubaybayan. Gayunpaman, ang serbisyo mismo ay hindi kinakailangang ilabas sa produksyon. Ang pag-deploy at pagpapalabas ng software ay hindi palaging pareho. Maaari kang mag-deploy kahit kailan mo gusto, ngunit maaari mo lang i-release kapag handa ka na.
Ang pag-aayos ng inip ay kawili-wili
Tingnan ang sumusunod na panuntunan sa pagruruta ng Istio, na nagruruta sa lahat ng kahilingan sa HTTP sa rekomendasyong v1 microservice (lahat ng mga halimbawa ay kinuha mula sa ), sabay-sabay na sinasalamin ang mga ito sa rekomendasyong v2 microservice:
Pakitandaan ang label mirror: Ang button sa ibaba ng screen ay kung ano ang nagse-set up ng pag-mirror ng trapiko. Oo, ganoon kasimple!
Ang resulta ng panuntunang ito ay patuloy na ipoproseso ng iyong production system (v1) ang mga papasok na kahilingan, ngunit ang mga kahilingan mismo ay asynchronous na isasalamin sa v2, ibig sabihin, ipapadala ang mga ito bilang mga kumpletong duplicate. Sa ganitong paraan, masusubok mo ang v2 sa mga totoong kondisyon—na may totoong data at trapiko—nang hindi nakikialam sa sistema ng produksyon. Ginagawa ba nitong isang gawain ang pagsubok? Oo, ganap. Pero nakakatuwang gawin.
Dagdagan natin ng drama
Pakitandaan na dapat isaalang-alang ng v2 code ang mga sitwasyon kung saan ang mga papasok na kahilingan ay maaaring magresulta sa pagbabago ng data. Ang mga kahilingan mismo ay nasasalamin nang madali at malinaw, ngunit ang pagpili kung paano haharapin ang mga ito sa kapaligiran ng pagsubok ay nasa iyo—at diyan ang mga bagay-bagay ay nagiging medyo nakakapanghina.
Ulitin natin ang isang mahalagang punto
Madilim na Paglunsad/Kahilingang Pag-mirror ay maaaring isagawa nang hindi hinahawakan ang anumang code.
Pagkain para sa pag-iisip
Paano kung ang lokasyon ng pag-mirror ng kahilingan ay ipadala ang ilan sa mga ito sa v2 sa halip na v1? Halimbawa, isang porsyento ng lahat ng mga kahilingan, o mga kahilingan lamang mula sa isang partikular na pangkat ng mga user. At pagkatapos, batay sa kung paano gumaganap ang v2, unti-unting i-migrate ang lahat ng kahilingan sa bagong bersyon. O, sa kabaligtaran, ibalik ang lahat sa v1 kung may mali sa v2. Naniniwala ako na ito ay tinatawag na Canary Deployment. , at kung ito ay nagmula sa Ruso, malamang na naglalaman ito ng sanggunian sa ), at ngayon ay titingnan natin ito nang mas detalyado.
Canary Deployment sa Istio: pinapasimple ang pag-commissioning
Maingat at unti-unti
Ang modelo ng Canary Deployment ay simple: kapag naglunsad ka ng bagong bersyon ng iyong software (sa aming kaso, isang microservice), ibibigay mo muna ito sa isang maliit na grupo ng mga user. Kung magiging maayos ang lahat, dahan-dahan mong dinadagdagan ang pangkat na ito hanggang sa magsimulang mag-malfunction ang bagong bersyon, o – kung hindi iyon mangyayari – sa kalaunan ay ililipat mo ang lahat ng user dito. Sa pamamagitan ng maingat at unti-unting paglulunsad ng bagong bersyon at paglipat ng mga user dito sa isang kontroladong paraan, maaari mong pagaanin ang mga panganib at i-maximize ang feedback.
Siyempre, pinapasimple ng Istio ang Canary Deployment sa pamamagitan ng pag-aalok ng maraming magagandang opsyon para sa matalinong pagruruta ng kahilingan. At oo, lahat ng ito ay maaaring gawin nang hindi hinahawakan ang iyong source code.
Pag-filter ng browser
Ang isa sa pinakasimpleng pamantayan sa pagruruta ay ang pag-redirect na tukoy sa browser. Sabihin nating gusto mo lang ang mga kahilingan mula sa mga Safari browser na pumunta sa v2. Narito kung paano ito gawin:
Ilapat natin ang panuntunang ito sa pagruruta at pagkatapos ay gamitin ang command curl Gagawin namin ang mga tunay na kahilingan sa microservice sa isang loop. Gaya ng nakikita mo sa screenshot, lahat sila ay pumupunta sa v1:
Nasaan ang trapiko sa v2? Dahil ang lahat ng mga kahilingan sa aming halimbawa ay nagmula lamang sa aming command line, wala ito doon. Ngunit pansinin ang mga ilalim na linya sa screenshot sa itaas: ito ang tugon sa aming kahilingan mula sa Safari browser, na ibinalik naman ito:
Walang limitasyong kapangyarihan
Nagsulat na kami tungkol sa kung gaano kalakas ang mga regular na expression para sa mga kahilingan sa pagruruta. Tingnan ang sumusunod na halimbawa (sa tingin namin ay malalaman mo kung ano ang ginagawa nito):
Sa ngayon, malamang na mayroon kang ideya kung ano ang kaya ng mga regular na expression.
Kumilos nang matalino
Ang matalinong pagruruta, kabilang ang pagpoproseso ng packet header gamit ang mga regular na expression, ay nagbibigay-daan sa iyong pamahalaan ang trapiko nang eksakto sa gusto mo. Ito ay makabuluhang pinapasimple ang pagpapatupad ng bagong code – ito ay simple, hindi nangangailangan ng anumang mga pagbabago sa mismong code, at maaaring mabilis na maibalik kung kinakailangan.
Interesado?
Sabik ka bang mag-eksperimento sa Istio, Kubernetes, at OpenShift sa sarili mong makina? Ang koponan naghanda ng isang mahusay Nai-publish ko ang lahat ng mga nauugnay na file sa paksang ito at ginawa itong available sa publiko. Kaya sige at tamasahin ang lahat ng iyong makakaya.
Istio Egress: lumabas sa souvenir shop
Ang paggamit ng Istio sa Red Hat OpenShift at Kubernetes ay maaaring gawing mas madali ang buhay sa mga microservice. Ang Istio service mesh ay nakatago sa loob ng mga Kubernetes pod, at ang iyong code ay tumatakbo (karamihan) nang nakahiwalay. Ang pagganap, kadalian ng pagbabago, pagsubaybay, at higit pa ay madaling pinagsamantalahan sa pamamagitan ng paggamit ng mga sidecar container. Ngunit paano kung ang iyong microservice ay kailangang makipag-ugnayan sa iba pang mga serbisyo na matatagpuan sa labas ng iyong OpenShift-Kubernetes system?
Dito pumapasok ang Istio Egress. Sa madaling salita, pinapayagan ka nitong ma-access ang mga mapagkukunan (basahin ang: "mga serbisyo") na hindi bahagi ng iyong Kubernetes pod system. Nang walang anumang karagdagang configuration, ang Istio Egress ay nagruruta lamang ng trapiko sa loob at pagitan ng mga pod cluster batay sa mga panloob na IP table. Ang cocooning na ito ay mahusay na gumagana hangga't hindi mo kailangang i-access ang mga serbisyo mula sa labas.
Binibigyang-daan ka ng Egress na i-bypass ang mga IP table sa itaas, batay man sa mga panuntunan ng Egress o sa isang hanay ng mga IP address.
Sabihin nating mayroon kaming Java program na gumagawa ng kahilingan sa GET sa httpbin.org/headers.
(Ang httpbin.org ay isang maginhawang mapagkukunan lamang para sa pagsubok ng mga papalabas na kahilingan sa serbisyo.)
Kung pumasok ka sa command line curl http://httpbin.org/headers, makikita natin ang sumusunod:
O maaari mong buksan ang parehong address sa iyong browser:
Tulad ng nakikita natin, ibinabalik lamang ng serbisyong matatagpuan doon ang mga header na ipinasa dito.
Kami ay import substitution head-on
Ngayon, kunin natin ang Java code para sa serbisyong ito sa labas ng aming system at patakbuhin ito sa aming system, kung saan, bilang paalala, naka-install ang Istio. (Maaari mong gawin ito sa iyong sarili sa pamamagitan ng pagsangguni sa .) Pagkatapos buuin ang naaangkop na imahe at patakbuhin ito sa OpenShift platform, tatawagin namin ang serbisyong ito gamit ang command curl egresshttpbin-istioegress.$(minishift ip).nip.io, pagkatapos nito ay makikita natin ito sa screen:
Oops, anong nangyari? Ito ay gumagana lamang. Ano ang ibig sabihin ng "Not Found"? May ginawa lang kami para dito. curl.
Pagpapalawak ng mga IP table sa buong Internet
Si Istio ang dapat sisihin (o pasalamatan) para dito. Pagkatapos ng lahat, ang Istio ay isang sidecar container lang na responsable para sa pagtuklas at pagruruta (at marami pang bagay na natalakay na namin dati). Samakatuwid, alam lang ng mga IP table kung ano ang nasa loob ng iyong cluster system. Ang httpbin.org ay matatagpuan sa labas at samakatuwid ay hindi naa-access. Dito pumapasok ang Istio Egress – nang walang kaunting pagbabago sa iyong source code.
Pinipilit ng Egress rule sa ibaba si Istio na maghanap (kung kinakailangan, sa buong internet) para sa kinakailangang serbisyo, sa kasong ito, httpbin.org. Tulad ng nakikita mo mula sa file na ito (egress_httpbin.yml), ang pag-andar dito ay medyo simple:
Ang natitira na lang ay ilapat ang panuntunang ito:
istioctl create -f egress_httpbin.yml -n istioegress
Maaari mong tingnan ang mga panuntunan sa Paglabas gamit ang utos istioctl get egressrules:
At sa wakas, pinapatakbo namin muli ang command kulutan - at nakikita namin na gumagana ang lahat:
Mag-isip nang bukas
Tulad ng nakikita mo, pinapayagan ka ng Istio na makipag-ugnayan sa labas ng mundo. Sa madaling salita, maaari ka pa ring lumikha ng mga serbisyo ng OpenShift at pamahalaan ang mga ito sa pamamagitan ng Kubernetes, na pinapanatili ang lahat sa mga pod na pataas at pababa kung kinakailangan. At sa parehong oras, madali mong ma-access ang mga serbisyong panlabas sa iyong kapaligiran. At oo, muli, magagawa mo ang lahat ng ito nang hindi hinahawakan ang iyong code.
Ito ang huling post sa serye ng Istio. Manatiling nakatutok—marami pang darating!
Pinagmulan: www.habr.com
