Олон улсын нууцлаг хүн Остин Пауэрс "Аюул бол миний хоёрдахь нэр" гэж хэлдэг байсан. Гэхдээ супер агентууд болон тагнуулын албадын өндөр үнэлдэг зүйл нь уйтгартай байх нь аюулаас хамаагүй дээр байдаг компьютерийн үйлчилгээнд огт тохирохгүй юм.
Istio нь OpenShift болон Kubernetes-ийн хамтаар микро үйлчилгээг ашиглах нь үнэхээр уйтгартай, урьдчилан таамаглах боломжтой болгодог бөгөөд энэ нь гайхалтай юм. Бид энэ болон бусад олон зүйлийн талаар Istio цувралын дөрөв дэх буюу сүүлчийн нийтлэлд ярих болно.
Уйдах нь зөв үед
Манай тохиолдолд уйтгар гуниг нь зөвхөн эцсийн шатанд л тохиолддог бөгөөд зөвхөн сууж, үйл явцыг ажиглахад л үлддэг. Гэхдээ үүний тулд та эхлээд бүх зүйлийг тохируулах хэрэгтэй бөгөөд энд олон сонирхолтой зүйл таныг хүлээж байна.
Програм хангамжийнхаа шинэ хувилбарыг ашиглахдаа эрсдэлийг бууруулах бүх хувилбаруудыг авч үзэх нь зүйтэй. Зэрэгцээ ажиллах нь туршилт хийх маш хүчирхэг бөгөөд батлагдсан арга бөгөөд Istio нь үйлдвэрлэлийн системд саад учруулахгүйгээр "нууц үйлчилгээ" (таны бичил үйлчилгээний далд хувилбар) ашиглах боломжийг олгодог. Үүний тулд "Dark Launch" гэсэн тусгай нэр томъёо байдаг бөгөөд энэ нь эргээд "замын хөдөлгөөний толин тусгал" гэсэн тагнуулын нэртэй функцээр идэвхждэг.
Өмнөх догол мөрийн эхний өгүүлбэрт "суллах" гэхээсээ илүү "байруулах" гэсэн нэр томъёог ашигласан болохыг анхаарна уу. Та үнэхээр өөрийн микро үйлчилгээг хүссэн үедээ ашиглах боломжтой байх ёстой. Энэ үйлчилгээ нь траффик хүлээн авах, боловсруулах, үр дүнг гаргах, мөн бүртгэлд бичих, хянах чадвартай байх ёстой. Гэхдээ үүнтэй зэрэгцэн энэ үйлчилгээг өөрөө үйлдвэрлэлд гаргах шаардлагагүй. Програм хангамжийг байршуулах, гаргах нь үргэлж ижил зүйл биш юм. Та хүссэн үедээ байрлуулж болно, гэхдээ бэлэн болсон үедээ л суллана.
Уйтгарыг зохион байгуулах нь сонирхолтой юм
Бүх HTTP хүсэлтийг микро үйлчилгээний зөвлөмж v1 рүү чиглүүлдэг Istio чиглүүлэлтийн дараах дүрмийг харна уу (бүх жишээг эндээс авсан) ), тэдгээрийг зөвлөмжийн v2 микро үйлчилгээнд нэгэн зэрэг толин тусгах:
Шошгон дээр анхаарлаа хандуулаарай mirror: дэлгэцийн доод хэсэгт - энэ нь замын хөдөлгөөний толин тусгалыг тохируулдаг. Тийм ээ, энэ маш энгийн!
Энэ дүрмийн үр дүн нь таны үйлдвэрлэлийн систем (v1) ирж буй хүсэлтийг үргэлжлүүлэн боловсруулах боловч хүсэлтүүд нь v2-д асинхрон байдлаар тусгагдах болно, өөрөөр хэлбэл тэдгээрийн бүрэн хуулбарууд тийшээ очих болно. Ингэснээр та v2-ийг бодит нөхцөлд - бодит өгөгдөл болон урсгал дээр - үйлдвэрлэлийн системийн үйл ажиллагаанд ямар нэгэн байдлаар саад учруулахгүйгээр турших боломжтой. Энэ нь шалгалтыг зохион байгуулах нь уйтгартай болгодог уу? Тийм ээ, гарцаагүй. Гэхдээ энэ нь сонирхолтой байдлаар хийгдсэн.
Жүжиг нэмье
V2 кодонд ирж буй хүсэлт нь өгөгдлийн өөрчлөлтөд хүргэж болзошгүй нөхцөл байдлыг зааж өгөх шаардлагатай гэдгийг анхаарна уу. Хүсэлтүүд нь өөрөө амархан бөгөөд ил тод тусгагдсан байдаг, гэхдээ тестийн боловсруулалтын аргыг сонгох нь танд хамаарна - энэ нь бага зэрэг санаа зовоож байна.
Нэг чухал зүйлийг дахин хэлье
Замын хөдөлгөөний толин тусгал бүхий нууц хөөргөлтийг (Dark Launch/Request Mirroring) кодонд ямар нэгэн байдлаар нөлөөлөхгүйгээр гүйцэтгэж болно.
Бодох хоол
Хүсэлтүүдийг толин тусгал хийдэг газар заримыг нь v1 рүү биш, харин v2 руу илгээвэл яах вэ? Жишээлбэл, нийт хүсэлтийн нэг хувь эсвэл зөвхөн тодорхой бүлгийн хэрэглэгчдийн хүсэлт. Дараа нь v2 хэрхэн ажилладаг талаар аль хэдийн харвал бүх хүсэлтийг аажмаар шинэ хувилбар руу шилжүүлээрэй. Эсвэл эсрэгээр, v1-т ямар нэг зүйл буруу болвол бүгдийг v2 рүү буцаана уу. Би үүнийг Canary Deployment гэж нэрлэдэг гэж бодож байна. , хэрэв энэ нь орос гаралтай байсан бол лавлагаа агуулсан байх магадлалтай ), одоо бид үүнийг илүү нарийвчлан авч үзэх болно.
Istio дахь Canary Deployment: ашиглалтанд оруулах ажлыг хялбарчлах
Болгоомжтой, аажмаар
Canary Deployment deployment загварын мөн чанар нь маш энгийн: та өөрийн программ хангамжийн шинэ хувилбарыг (манай тохиолдолд бичил үйлчилгээ) эхлүүлэхдээ эхлээд цөөн тооны хэрэглэгчдэд хандах эрхийг олгодог. Хэрэв бүх зүйл хэвийн болвол та шинэ хувилбар ажиллаж эхлэх хүртэл энэ бүлгийг аажмаар нэмэгдүүлэх, эсвэл үгүй бол бүх хэрэглэгчдийг түүн рүү шилжүүлнэ. Бодлоготой, аажмаар шинэ хувилбарыг нэвтрүүлж, хэрэглэгчдийг хяналттай сольсноор эрсдэлийг бууруулж, санал хүсэлтийг нэмэгдүүлэх боломжтой.
Мэдээжийн хэрэг, Istio ухаалаг хүсэлтийн чиглүүлэлтийн хэд хэдэн сайн сонголтыг санал болгосноор Canary Deployment-ийг хялбаршуулдаг. Тийм ээ, энэ бүгдийг ямар ч байдлаар таны эх кодыг хөндөхгүйгээр хийж болно.
Хөтөчийг шүүж байна
Чиглүүлэлтийн хамгийн энгийн шалгууруудын нэг бол хөтөч дээр суурилсан дахин чиглүүлэлт юм. Та зөвхөн Safari хөтчөөс v2 руу шилжих хүсэлтийг хүсч байна гэж бодъё. Үүнийг хэрхэн хийснийг энд харуулав.
Энэ чиглүүлэлтийн дүрмийг хэрэгжүүлээд дараа нь тушаалыг ашиглана уу curl Бид микро үйлчилгээний бодит хүсэлтийг давталтын хэлбэрээр загварчлах болно. Дэлгэцийн зургаас харахад тэд бүгд v1 рүү шилждэг:
v2 дээр ачаалал хаана байна вэ? Бидний жишээн дээр бүх хүсэлтүүд зөвхөн бидний командын мөрөөс ирсэн тул энэ нь огт байхгүй. Гэхдээ дээрх дэлгэцийн доод мөрөнд анхаарлаа хандуулаарай: энэ нь Safari хөтчөөс ирсэн хүсэлтийг гүйцэтгэсэн хариу үйлдэл бөгөөд энэ нь эргээд үүнийг үүсгэсэн:
Хязгааргүй хүч
Тогтмол илэрхийлэл нь чиглүүлэлтийн хүсэлтийг маш хүчтэй болгодог гэж бид аль хэдийн бичсэн. Дараах жишээг харна уу (энэ нь юу болохыг та ойлгох болно гэж бид бодож байна):
Одоо та ердийн хэллэгүүд юу хийж чадах талаар ойлголттой болсон байх.
Ухаалаг үйлд
Ухаалаг чиглүүлэлт, ялангуяа ердийн илэрхийлэл ашиглан пакетийн толгойг боловсруулах нь урсгалыг хүссэнээрээ удирдах боломжийг танд олгоно. Энэ нь шинэ кодын хэрэгжилтийг ихээхэн хялбаршуулдаг - энэ нь энгийн, кодыг өөрөө өөрчлөх шаардлагагүй бөгөөд шаардлагатай бол бүх зүйлийг өмнөх шигээ хурдан буцааж өгөх боломжтой.
Сонирхсон уу?
Та компьютер дээрээ Istio, Kubernetes, OpenShift програмуудыг туршиж үзэхийг хүсч байна уу? Баг гайхалтай бэлдсэн Энэ сэдвээр болон дагалдах бүх файлыг олон нийтэд нээлттэй болгосон. Тиймээс урагшаа явж, өөрийгөө юу ч бүү үгүйсгэ.
Istio Egress: бэлэг дурсгалын дэлгүүрээр гарах
Istio-г Red Hat OpenShift болон Kubernetes-тэй хамт ашигласнаар та бичил үйлчилгээний амьдралаа илүү хялбар болгож чадна. Istio-ийн үйлчилгээний тор нь Kubernetes pods дотор нуугдаж байгаа бөгөөд таны код (ихэвчлэн) тусдаа ажилладаг. Гүйцэтгэл, өөрчлөхөд хялбар, мөшгих гэх мэт - энэ бүгдийг хажуугийн савны тусламжтайгаар ашиглахад хялбар байдаг. Хэрэв таны микро үйлчилгээ OpenShift-Kubernetes системээс гадуур байрлах бусад үйлчилгээнүүдтэй холбогдох шаардлагатай бол яах вэ?
Энд Истио Эгресс аврахаар ирдэг. Товчхондоо, энэ нь таны Kubernetes pods системийн нэг хэсэг биш нөөцөд (унш: "үйлчилгээ") хандах боломжийг танд олгоно. Хэрэв та нэмэлт тохиргоо хийхгүй бол Istio Egress орчинд траффик нь зөвхөн дотоод IP хүснэгтүүд дээр суурилсан pods-ийн кластер дотор болон ийм кластеруудын хооронд чиглэгддэг. Мөн гаднаас үйлчилгээ авах шаардлагагүй бол ийм зулзаганууд маш сайн ажилладаг.
Egress нь Egress дүрэм эсвэл олон тооны IP хаягууд дээр үндэслэн дээрх IP хүснэгтүүдийг тойрч гарах боломжийг танд олгоно.
Бид httpbin.org/headers руу GET хүсэлт гаргадаг Java програмтай гэж бодъё.
(httpbin.org бол гадагшаа гарах үйлчилгээний хүсэлтийг шалгахад тохиромжтой эх сурвалж юм.)
Хэрэв та тушаалын мөрөнд орвол curl http://httpbin.org/headers, бид дараахь зүйлийг харах болно.
Эсвэл та хөтөч дээр ижил хаягийг нээж болно:
Таны харж байгаагаар тэнд байрлах үйлчилгээ нь түүнд дамжуулсан толгойг буцааж өгдөг.
Бид импортыг шууд сольж байна
Одоо манай системээс гадуур байгаа энэ үйлчилгээний Java кодыг авч, Istio суулгасан газар өөрөө ажиллуулцгаая. (Холбоо барих замаар үүнийг өөрөө хийж болно .) Тохирох зургийг бүтээж, OpenShift платформ дээр ажиллуулсны дараа бид энэ үйлчилгээг тушаалаар дуудах болно. curl egresshttpbin-istioegress.$(minishift ip).nip.io, үүний дараа бид үүнийг дэлгэцэн дээр харах болно:
Өө, юу болсон бэ? Бүх зүйл зүгээр л ажилласан. Олдсонгүй гэдэг нь юу гэсэн үг вэ? Бид зүгээр л түүний төлөө хийсэн curl.
IP хүснэгтүүдийг бүхэлд нь интернетэд өргөтгөх
Үүний төлөө Истио буруутгах (эсвэл талархах) хэрэгтэй. Эцсийн эцэст, Istio бол илрүүлэх, чиглүүлэх үүрэгтэй хажуугийн сав юм (мөн бидний өмнө нь ярьсан бусад олон зүйл). Ийм учраас IP хүснэгтүүд нь зөвхөн кластерын систем дотор юу байгааг мэддэг. Мөн httpbin.org нь гадна талд байрладаг тул нэвтрэх боломжгүй юм. Эндээс таны эх кодыг өчүүхэн ч өөрчлөхгүйгээр Истио Эгресс аврах ажилд ирдэг.
Доорх Egress дүрэм нь Istio-г шаардлагатай үйлчилгээг хайж олохыг (шаардлагатай бол интернет даяар), энэ тохиолдолд httpbin.org-г шаарддаг. Энэ файлаас (egress_httpbin.yml) харж байгаачлан, энд байгаа функц нь маш энгийн:
Энэ дүрмийг хэрэгжүүлэх л үлдлээ.
istioctl create -f egress_httpbin.yml -n istioegress
Та тушаалаар гарах дүрмийг харах боломжтой istioctl get egressrules:
Эцэст нь бид тушаалыг дахин ажиллуулна curl - мөн бүх зүйл ажиллаж байгааг бид харж байна:
Бид нээлттэй боддог
Таны харж байгаагаар Istio нь гадаад ертөнцтэй харилцах харилцааг зохион байгуулах боломжийг олгодог. Өөрөөр хэлбэл, та OpenShift үйлчилгээг үүсгэж, Kubernetes-ээр дамжуулан тэдгээрийг удирдах боломжтой хэвээр байгаа бөгөөд шаардлагатай бол томрох, багасгах боломжтой бүх зүйлийг pods-д хадгалах боломжтой. Үүний зэрэгцээ та хүрээлэн буй орчныхоо гаднах үйлчилгээнд аюулгүйгээр хандах боломжтой. Тийм ээ, бид дахин нэг удаа давтан хэлэхэд энэ бүгдийг таны кодыг ямар ч байдлаар хөндөхгүйгээр хийж болно.
Энэ бол Istio дээрх цувралын сүүлчийн бичлэг байв. Хамтдаа байгаарай - маш олон сонирхолтой зүйл хүлээж байна!
Эх сурвалж: www.habr.com