Beynəlxalq sirr adamı Austin Pauers deyirdi: "Təhlükə mənim ikinci adımdır". Ancaq super agentlər və kəşfiyyat xidmətləri tərəfindən yüksək qiymətləndirilən şey kompüter xidmətləri üçün heç də uyğun deyil, burada cansıxıcılıq təhlükədən daha yaxşıdır.
Istio, OpenShift və Kubernetes ilə birlikdə mikroservislərin yerləşdirilməsini həqiqətən darıxdırıcı və proqnozlaşdırıla bilən edir - və bu, əladır. Bu və daha çox şey haqqında Istio seriyasındakı dördüncü və son yazıda danışacağıq.
Darıxmaq doğru olanda
Bizdə isə cansıxıcılıq yalnız son mərhələdə baş verir, o zaman ki, oturub prosesi izləmək qalır. Ancaq bunun üçün əvvəlcə hər şeyi konfiqurasiya etməlisiniz və sizi burada çox maraqlı şeylər gözləyir.
Proqramınızın yeni versiyasını yerləşdirərkən riskləri minimuma endirmək üçün bütün variantları nəzərdən keçirməyə dəyər. Paralel işləmək sınaq üçün çox güclü və sübut olunmuş üsuldur və Istio istehsal sisteminə müdaxilə etmədən bunu etmək üçün “gizli xidmətdən” (mikroservisinizin gizli versiyası) istifadə etməyə imkan verir. Bunun üçün hətta xüsusi bir termin var - "Dark Launch", bu da öz növbəsində eyni dərəcədə casus adı olan "trafik aynası" funksiyası ilə aktivləşdirilir.
Nəzərə alın ki, əvvəlki bəndin birinci cümləsində “buraxmaq” deyil, “yerləşdirmək” ifadəsi işlədilir. Siz həqiqətən mikroservisinizi istədiyiniz qədər yerləşdirə və əlbəttə ki, istifadə edə bilməlisiniz. Bu xidmət trafiki qəbul etməyi və emal etməyi, nəticələr çıxarmağı, həmçinin qeydlərə yazmağı və monitorinqi bacarmalıdır. Ancaq eyni zamanda, bu xidmətin özünün istehsala buraxılması mütləq deyil. Proqram təminatının yerləşdirilməsi və buraxılması həmişə eyni şey deyil. İstədiyiniz zaman yerləşdirə bilərsiniz, ancaq hazır olduqda buraxın.
Darıxmağın təşkili maraqlıdır
Bütün HTTP sorğularını mikroservis tövsiyəsi v1-ə yönləndirən aşağıdakı Istio marşrutlaşdırma qaydasına nəzər salın (bütün nümunələr buradan götürülüb) ), eyni zamanda onları tövsiyə v2 mikro xidmətinə əks etdirərkən:
Etiketə diqqət yetirin mirror: ekranın aşağı hissəsində - trafikin əks olunmasını təyin edən budur. Bəli, bu qədər sadədir!
Bu qaydanın nəticəsi o olacaq ki, istehsal sisteminiz (v1) gələn sorğuları emal etməyə davam edəcək, lakin sorğuların özləri asinxron olaraq v2-yə əks olunacaq, yəni onların tam dublikatları ora gedəcək. Bu yolla, istehsal sisteminin işinə heç bir şəkildə müdaxilə etmədən v2-ni real şəraitdə - real məlumatlarda və trafikdə sınaqdan keçirə bilərsiniz. Bu, sınaqların təşkilini darıxdırıcı edir? Bəli, mütləq. Ancaq maraqlı bir şəkildə edilir.
Drama əlavə edək
Nəzərə alın ki, v2 kodunda daxil olan sorğuların məlumat dəyişikliyinə səbəb ola biləcəyi vəziyyətləri təmin etmək lazımdır. Sorğuların özləri asanlıqla və şəffaf şəkildə əks olunur, lakin testdə emal metodunun seçimi sizin ixtiyarınızdadır - və bu bir az narahatdır.
Bir vacib məqamı təkrar edək
Trafik aynası ilə gizli işə salma (Dark Launch/Request Mirroring) koda heç bir şəkildə təsir etmədən həyata keçirilə bilər.
Düşünmək üçün yemək
Əgər sorğuların əks olunduğu yer onlardan bəzilərini v1-ə deyil, v2-yə göndərirsə? Məsələn, bütün sorğuların bir faizi və ya yalnız müəyyən bir istifadəçi qrupunun sorğuları. Və sonra, artıq v2-nin necə işlədiyinə baxaraq, bütün sorğuları tədricən yeni versiyaya köçürün. Və ya əksinə, v1 ilə bir şey səhv olarsa, hər şeyi v2-ə qaytarın. Məncə, buna Canary Deployment deyilir. , və rus mənşəli olsaydı, yəqin ki, istinad ehtiva edərdi ) və indi buna daha ətraflı baxacağıq.
Istio-da Canary Deployment: istismara vermənin sadələşdirilməsi
Diqqətlə və tədricən
Canary Deployment yerləşdirmə modelinin mahiyyəti olduqca sadədir: proqram təminatınızın yeni versiyasını (bizim vəziyyətimizdə mikroservis) işə saldığınız zaman əvvəlcə kiçik bir istifadəçi qrupuna ona giriş imkanı verirsiniz. Hər şey qaydasındadırsa, siz yeni versiya işə başlayana qədər bu qrupu yavaş-yavaş artırırsınız və ya yoxsa, bütün istifadəçiləri ona köçürürsünüz. Düşüncəli və tədricən yeni versiyanı təqdim etməklə və istifadəçiləri idarə olunan şəkildə ona keçid etməklə siz riskləri azalda və rəyi maksimum dərəcədə artıra bilərsiniz.
Əlbəttə ki, Istio, ağıllı sorğu yönləndirməsi üçün bir neçə yaxşı seçim təklif edərək Canary Deployment-i asanlaşdırır. Bəli, bütün bunlar heç bir şəkildə mənbə kodunuza toxunmadan edilə bilər.
Brauzerin filtrlənməsi
Ən sadə marşrutlaşdırma meyarlarından biri brauzer əsaslı yönləndirmədir. Tutaq ki, siz yalnız Safari brauzerlərindən gələn sorğuların v2-yə keçməsini istəyirsiniz. Bunun necə edildiyi belədir:
Bu marşrutlaşdırma qaydasını tətbiq edək və sonra əmrdən istifadə edək curl Mikroservisə real sorğuları dövrədə simulyasiya edəcəyik. Ekran görüntüsündə gördüyünüz kimi, hamısı v1-ə keçir:
v2-də trafik haradadır? Nümunəmizdə bütün sorğular yalnız öz komanda xəttimizdən gəldiyi üçün o, sadəcə mövcud deyil. Ancaq yuxarıdakı ekrandakı alt sətirlərə diqqət yetirin: bu, Safari brauzerindən bir sorğu yerinə yetirdiyimizə reaksiyadır, o da öz növbəsində bunu yaradıb:
Limitsiz güc
Biz artıq yazmışdıq ki, müntəzəm ifadələr marşrutlaşdırma sorğuları üçün çox güclü imkanlar verir. Aşağıdakı nümunəyə nəzər salın (zənn edirik ki, bunun nə etdiyini başa düşəcəksiniz):
İndi yəqin ki, müntəzəm ifadələrin nə edə biləcəyi barədə bir fikrə sahibsiniz.
Ağıllı hərəkət edin
Ağıllı marşrutlaşdırma, xüsusən də müntəzəm ifadələrdən istifadə edərək paket başlıqlarının işlənməsi trafiki istədiyiniz şəkildə idarə etməyə imkan verir. Və bu, yeni kodun tətbiqini xeyli asanlaşdırır - sadədir, kodun özünü dəyişdirməyi tələb etmir və lazım olduqda hər şeyi olduğu kimi tez qaytarmaq olar.
Maraqlıdır?
Kompüterinizdə Istio, Kubernetes və OpenShift ilə sınaqdan keçirməyə can atırsınız? Komanda əla hazırladı Bu mövzuda və bütün müşayiət olunan faylları ictimaiyyətə təqdim etdi. Buna görə də davam edin və özünüzdən heç nəyi inkar etməyin.
Istio Egress: suvenir mağazasından çıxın
Red Hat OpenShift və Kubernetes ilə birlikdə Istio-dan istifadə edərək, mikroservislərlə həyatınızı çox asanlaşdıra bilərsiniz. Istio-nun xidmət şəbəkəsi Kubernetes podlarının içərisində gizlənir və kodunuz (əsasən) təcrid olunmuş vəziyyətdə işləyir. Performans, dəyişdirmə asanlığı, izləmə və s. - bütün bunlar yan qutuların istifadəsi sayəsində asan istifadə olunur. Bəs mikroservisinizin OpenShift-Kubernetes sisteminizdən kənarda yerləşən digər xidmətlərlə əlaqə saxlaması lazımdırsa nə etməli?
Istio Egressin köməyə gəldiyi yer budur. Bir sözlə, o, sadəcə olaraq Kubernetes pod sisteminizin bir hissəsi olmayan resurslara (oxu: “xidmətlər”) daxil olmağa imkan verir. Əgər siz əlavə konfiqurasiya yerinə yetirmirsinizsə, onda Istio Egress mühitində trafik yalnız podlar klasteri daxilində və daxili IP cədvəlləri əsasında belə klasterlər arasında yönləndirilir. Kənardan xidmətlərə çıxışa ehtiyacınız olmadığı müddətcə bu cür pupasiya əla işləyir.
Egress sizə ya Çıxış qaydalarına, ya da bir sıra IP ünvanlarına əsaslanaraq yuxarıdakı İP cədvəllərindən yan keçməyə imkan verir.
Tutaq ki, httpbin.org/headers ünvanına GET sorğusu göndərən Java proqramımız var.
(httpbin.org, gedən xidmət sorğularını sınamaq üçün sadəcə əlverişli mənbədir.)
Komanda xəttinə daxil olsanız curl http://httpbin.org/headers, biz aşağıdakıları görəcəyik:
Və ya eyni ünvanı brauzerdə aça bilərsiniz:
Gördüyünüz kimi, orada yerləşən xidmət sadəcə ona ötürülən başlıqları qaytarır.
Biz idxalı baş-başa əvəz edirik
İndi sistemimizə xas olan bu xidmətin Java kodunu götürək və onu Istio-nun quraşdırıldığı özümüz işə salaq. (Əlaqə saxlayaraq bunu özünüz edə bilərsiniz .) Müvafiq təsviri qurub OpenShift platformasında işə saldıqdan sonra biz bu xidmətə əmrlə zəng edəcəyik. curl egresshttpbin-istioegress.$(minishift ip).nip.io, bundan sonra bunu ekranda görəcəyik:
Vay, nə oldu? Hər şey sadəcə işlədi. Tapılmadı nə deməkdir? Biz bunu sadəcə onun üçün etdik curl.
IP cədvəllərinin bütün İnternetə genişləndirilməsi
Bunun üçün Istio günahlandırılmalı (və ya təşəkkür edilməlidir). Axı, Istio yalnız aşkarlama və marşrutlaşdırma üçün cavabdeh olan yan qutu konteynerləridir (və əvvəllər haqqında danışdığımız bir çox başqa şey). Bu səbəbdən, IP cədvəlləri yalnız klaster sisteminizdə nə olduğunu bilir. Və httpbin.org kənarda yerləşir və buna görə də əlçatmazdır. Və burada Istio Egress köməyə gəlir - mənbə kodunuza ən kiçik dəyişiklik etmədən.
Aşağıdakı Çıxış qaydası Istio-nu tələb olunan xidməti axtarmağa (lazım olduqda, bütün İnternetdə) məcbur edir, bu halda httpbin.org. Bu fayldan (egress_httpbin.yml) gördüyünüz kimi, burada funksionallıq olduqca sadədir:
Bu qaydanı tətbiq etmək qalır:
istioctl create -f egress_httpbin.yml -n istioegress
Çıxış qaydalarına əmrlə baxa bilərsiniz istioctl get egressrules:
Və nəhayət, əmri yenidən icra edirik curl – və biz hər şeyin işlədiyini görürük:
Biz açıq düşünürük
Gördüyünüz kimi, Istio sizə xarici dünya ilə qarşılıqlı əlaqəni təşkil etməyə imkan verir. Başqa sözlə, siz hələ də OpenShift xidmətləri yarada və onları Kubernetes vasitəsilə idarə edə bilərsiniz, hər şeyi lazım olduqda miqyasını artıran və aşağı salan podlarda saxlaya bilərsiniz. Və eyni zamanda, ətrafınızdan kənar xidmətlərə təhlükəsiz şəkildə daxil ola bilərsiniz. Bəli, bir daha təkrar edirik ki, bütün bunlar heç bir şəkildə kodunuza toxunmadan edilə bilər.
Bu, Istio-da seriyanın son yazısı idi. İzləmədə qalın - qarşıda çox maraqlı şeylər var!
Mənbə: www.habr.com