ბნელი გაშვება ისტიოში: საიდუმლო სერვისები

"საშიშროება ჩემი მეორე სახელია", - ამბობდა ოსტინ პაუერსი, იდუმალი საერთაშორისო ადამიანი. მაგრამ ის, რასაც სუპერ აგენტები და სადაზვერვო სამსახურები დიდ პატივს სცემენ, საერთოდ არ არის შესაფერისი კომპიუტერული სერვისებისთვის, სადაც მოწყენილობა ბევრად უკეთესია, ვიდრე საფრთხე.

და Istio, OpenShift-თან და Kubernetes-თან ერთად, მიკროსერვისების დანერგვას ნამდვილად მოსაწყენს და პროგნოზირებადს ხდის - და ეს შესანიშნავია. ამაზე და ბევრად მეტზე ვისაუბრებთ ისტიოს სერიის მეოთხე და ბოლო პოსტში.

როცა მოწყენილობა სწორია

ჩვენს შემთხვევაში მოწყენილობა მხოლოდ დასკვნით ფაზაში ჩნდება, როცა რჩება მხოლოდ ჯდომა და პროცესის ყურება. მაგრამ ამისათვის ჯერ ყველაფრის კონფიგურაცია გჭირდებათ და აქ ბევრი საინტერესო რამ გელით.

თქვენი პროგრამული უზრუნველყოფის ახალი ვერსიის განლაგებისას, ღირს რისკების შემცირების ყველა ვარიანტის გათვალისწინება. პარალელურად სირბილი ძალიან მძლავრი და აპრობირებული საშუალებაა შესამოწმებლად და Istio გაძლევთ საშუალებას გამოიყენოთ „საიდუმლო სერვისი“ (თქვენი მიკროსერვისის ფარული ვერსია) ამის გასაკეთებლად წარმოების სისტემაში ჩარევის გარეშე. ამისათვის სპეციალური ტერმინიც კი არსებობს - "Dark Launch", რომელიც, თავის მხრივ, გააქტიურებულია ფუნქციით თანაბრად ჯაშუშური სახელით "ტრაფიკის სარკე".

გთხოვთ გაითვალისწინოთ, რომ წინა პუნქტის პირველი წინადადება იყენებს ტერმინს „განლაგება“ და არა „გათავისუფლება“. თქვენ ნამდვილად უნდა შეგეძლოთ თქვენი მიკროსერვისის დანერგვა და, რა თქმა უნდა, გამოყენება, რამდენჯერაც გსურთ. ამ სერვისს უნდა შეეძლოს ტრაფიკის მიღება და დამუშავება, შედეგების წარმოება და ასევე ჩაწერა ჟურნალებში და მონიტორინგი. მაგრამ ამავდროულად, თავად ამ სერვისს სულაც არ სჭირდება წარმოებაში გაშვება. პროგრამული უზრუნველყოფის დანერგვა და გამოშვება ყოველთვის არ არის იგივე. შეგიძლიათ განათავსოთ როცა გინდათ, მაგრამ გაათავისუფლოთ მხოლოდ მაშინ, როცა მზად იქნებით.

მოწყენილობის ორგანიზება საინტერესოა

გადახედეთ Istio მარშრუტიზაციის შემდეგ წესს, რომელიც მარშრუტებს ყველა HTTP მოთხოვნას მიკროსერვისის რეკომენდაციაზე v1 (ყველა მაგალითი აღებულია Istio Tutorial GitHub რეპო), ხოლო ერთდროულად ასახავს მათ რეკომენდაციას v2 microservice:

ყურადღება მიაქციეთ ეტიკეტს mirror: ეკრანის ბოლოში - ეს არის ის, რაც ადგენს ტრაფიკის სარკეს. დიახ, ეს ასე მარტივია!

ამ წესის შედეგი იქნება ის, რომ თქვენი წარმოების სისტემა (v1) გააგრძელებს შემომავალი მოთხოვნების დამუშავებას, მაგრამ თავად მოთხოვნები ასინქრონულად აირეკლება v2-ზე, ანუ მათი სრული დუბლიკატები იქ წავა. ამ გზით, თქვენ შეგიძლიათ შეამოწმოთ v2 რეალურ პირობებში - რეალურ მონაცემებსა და ტრაფიკზე - წარმოების სისტემის მუშაობაში რაიმე სახის ჩარევის გარეშე. ეს მოსაწყენს ხდის ტესტირების ორგანიზებას? Დიახ აუცილებლად. მაგრამ ეს კეთდება საინტერესო გზით.

დავამატოთ დრამა

გთხოვთ გაითვალისწინოთ, რომ v2 კოდში აუცილებელია გათვალისწინებული იყოს სიტუაციები, როდესაც შემომავალმა მოთხოვნებმა შეიძლება გამოიწვიოს მონაცემების ცვლილება. თავად მოთხოვნები ასახულია მარტივად და გამჭვირვალედ, მაგრამ ტესტში დამუშავების მეთოდის არჩევანი თქვენზეა დამოკიდებული - და ეს ცოტა შემაშფოთებელია.

გავიმეოროთ მნიშვნელოვანი წერტილი

საიდუმლო გაშვება ტრაფიკის ასახვით (Dark Launch/Request Mirroring) შეიძლება შესრულდეს კოდზე რაიმე ზემოქმედების გარეშე.

Საკვები აზრის

რა მოხდება, თუ ადგილი, სადაც მოთხოვნებს ასახავს, ​​ზოგიერთ მათგანს აგზავნის არა v1-ზე, არამედ v2-ზე? მაგალითად, ყველა მოთხოვნის ერთი პროცენტი ან მხოლოდ მომხმარებელთა გარკვეული ჯგუფის მოთხოვნა. და შემდეგ, უკვე ნახეთ როგორ მუშაობს v2, თანდათან გადაიტანეთ ყველა მოთხოვნა ახალ ვერსიაზე. ან პირიქით, დააბრუნეთ ყველაფერი v1-ზე, თუ რამე არასწორია v2-ში. მგონი კანარის განლაგება ქვია. უბრუნდება მაინინგს, და რუსული წარმოშობის რომ ყოფილიყო, ალბათ ცნობას შეიცავდა კატები), ახლა კი ამას უფრო დეტალურად განვიხილავთ.

კანარის განლაგება ისტიოში: ექსპლუატაციის გამარტივება

ფრთხილად და თანდათანობით

Canary Deployment-ის განლაგების მოდელის არსი უკიდურესად მარტივია: როდესაც თქვენ გაუშვით თქვენი პროგრამული უზრუნველყოფის (ჩვენს შემთხვევაში, მიკროსერვისის) ახალ ვერსიას, თქვენ პირველ რიგში აძლევთ მასზე წვდომას მომხმარებელთა მცირე ჯგუფს. თუ ყველაფერი კარგად წავიდა, თქვენ ნელ-ნელა გაზრდით ამ ჯგუფს, სანამ ახალი ვერსია არ დაიწყებს მოქმედებას, ან - თუ ასე არ მოხდა - საბოლოოდ გადაიყვანეთ მასში ყველა მომხმარებელი. ახალი ვერსიის გააზრებული და თანდათანობით დანერგვით და მომხმარებლების მასზე კონტროლირებადი გზით გადართვით, შეგიძლიათ შეამციროთ რისკები და მაქსიმალურად გაზარდოთ გამოხმაურება.

რა თქმა უნდა, Istio ამარტივებს Canary Deployment-ს რამდენიმე კარგი ვარიანტის შეთავაზებით ინტელექტუალური მოთხოვნის მარშრუტიზაციისთვის. დიახ, ეს ყველაფერი შეიძლება გაკეთდეს თქვენი წყაროს კოდის არანაირად შეხების გარეშე.

ბრაუზერის ფილტრაცია

მარშრუტიზაციის ერთ-ერთი უმარტივესი კრიტერიუმია ბრაუზერზე დაფუძნებული გადამისამართება. ვთქვათ, გსურთ მხოლოდ Safari ბრაუზერების მოთხოვნები გადავიდეს v2-ზე. აი, როგორ კეთდება ეს:

მოდით გამოვიყენოთ მარშრუტიზაციის ეს წესი და შემდეგ გამოვიყენოთ ბრძანება curl მიკროსერვისის რეალური მოთხოვნების სიმულაციას მოვახდენთ მარყუჟში. როგორც სკრინშოტში ხედავთ, ისინი ყველა გადადიან v1-ზე:

სად არის ტრაფიკი v2-ზე? ვინაიდან ჩვენს მაგალითში ყველა მოთხოვნა მოვიდა მხოლოდ ჩვენი ბრძანების ხაზიდან, ის უბრალოდ არ არსებობს. მაგრამ ყურადღება მიაქციეთ ზედა ეკრანის ქვედა ხაზებს: ეს არის რეაქცია იმ ფაქტზე, რომ ჩვენ შევასრულეთ მოთხოვნა Safari ბრაუზერისგან, რამაც თავის მხრივ წარმოქმნა ეს:

შეუზღუდავი ძალა

ჩვენ უკვე დავწერეთ, რომ რეგულარული გამონათქვამები იძლევა ძალიან მძლავრ შესაძლებლობებს მარშრუტიზაციის მოთხოვნებისთვის. შეხედეთ შემდეგ მაგალითს (ვფიქრობთ, გესმით, რას აკეთებს):

ახლა თქვენ ალბათ გაქვთ წარმოდგენა იმის შესახებ, თუ რისი გაკეთება შეუძლია რეგულარულ გამონათქვამებს.

იმოქმედე ჭკვიანურად

ჭკვიანი მარშრუტიზაცია, კერძოდ პაკეტების სათაურების დამუშავება რეგულარული გამონათქვამების გამოყენებით, საშუალებას გაძლევთ მართოთ ტრაფიკი ისე, როგორც გსურთ. და ეს მნიშვნელოვნად ამარტივებს ახალი კოდის განხორციელებას - ეს მარტივია, ის არ საჭიროებს თავად კოდის შეცვლას და საჭიროების შემთხვევაში, ყველაფერი შეიძლება სწრაფად დაბრუნდეს ისე, როგორც იყო.

გაინტერესებთ?

გსურთ ექსპერიმენტი ჩაატაროთ Istio, Kubernetes და OpenShift-ით თქვენს კომპიუტერში? გუნდი Red Hat დეველოპერთა გუნდი მოამზადა შესანიშნავი სახელმძღვანელო ამ თემაზე და ყველა თანმხლები ფაილი საჯაროდ ხელმისაწვდომი გახადა. ასე რომ წადით და საკუთარ თავს არაფერს უარვყოფთ.
 

Istio Egress: გასვლა სუვენირების მაღაზიიდან

Istio-ს გამოყენებით Red Hat OpenShift-თან და Kubernetes-თან ერთად, თქვენ შეგიძლიათ გაამარტივოთ თქვენი ცხოვრება მიკროსერვისებით. Istio-ს სერვისული ქსელი იმალება Kubernetes-ის პოდებში და თქვენი კოდი მუშაობს (ძირითადად) იზოლირებულად. შესრულება, სიმარტივე შეცვლა, მიკვლევა და ა.შ. - ეს ყველაფერი მარტივი გამოსაყენებელია გვერდითი კარის კონტეინერების გამოყენების წყალობით. მაგრამ რა მოხდება, თუ თქვენს მიკროსერვისს სჭირდება კომუნიკაცია სხვა სერვისებთან, რომლებიც მდებარეობს თქვენი OpenShift-Kubernetes სისტემის გარეთ?

სწორედ აქ მოდის ისტიო ეგრესი სამაშველოში. მოკლედ, ის უბრალოდ საშუალებას გაძლევთ მიიღოთ წვდომა რესურსებზე (წაიკითხეთ: „სერვისები“), რომლებიც არ არის თქვენი Kubernetes pods სისტემის ნაწილი. თუ არ შეასრულებთ დამატებით კონფიგურაციას, მაშინ Istio Egress გარემოში ტრაფიკი მარშრუტდება მხოლოდ პოდების კლასტერში და ასეთ კლასტერებს შორის შიდა 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, რის შემდეგაც ჩვენ ვნახავთ ამას ეკრანზე:

უი, რა მოხდა? ყველაფერი უბრალოდ მუშაობდა. რას ნიშნავს არ მოიძებნა? ჩვენ ეს მხოლოდ მისთვის გავაკეთეთ curl.

IP ცხრილების გაფართოება მთელ ინტერნეტზე

ისტიოს უნდა დააბრალოს (ან მადლობა გადაუხადოს) ამაში. ყოველივე ამის შემდეგ, Istio არის მხოლოდ გვერდითი კარის კონტეინერები, რომლებიც პასუხისმგებელნი არიან აღმოჩენასა და მარშრუტიზაციაზე (და ბევრი სხვა რამ, რაზეც ადრე ვისაუბრეთ). ამ მიზეზით, IP ცხრილებმა იციან მხოლოდ რა არის თქვენი კლასტერული სისტემის შიგნით. ხოლო httpbin.org მდებარეობს გარეთ და ამიტომ მიუწვდომელია. და სწორედ აქ მოდის Istio Egress სამაშველოში - თქვენი წყაროს კოდის ოდნავი ცვლილების გარეშე.

ქვემოთ მოყვანილი Egress წესი აიძულებს Istio-ს მოძებნოს (საჭიროების შემთხვევაში, მაშინ მთელ ინტერნეტში) საჭირო სერვისი, ამ შემთხვევაში, httpbin.org. როგორც ხედავთ ამ ფაილიდან (egress_httpbin.yml), აქ ფუნქციონირება საკმაოდ მარტივია:

რჩება მხოლოდ ამ წესის გამოყენება:

istioctl create -f egress_httpbin.yml -n istioegress

თქვენ შეგიძლიათ ნახოთ Egress წესები ბრძანებით istioctl get egressrules:

და ბოლოს, ჩვენ კვლავ ვასრულებთ ბრძანებას curl - და ჩვენ ვხედავთ, რომ ყველაფერი მუშაობს:

ჩვენ ღიად ვფიქრობთ

როგორც ხედავთ, ისტიო საშუალებას გაძლევთ მოაწყოთ ურთიერთქმედება გარე სამყაროსთან. სხვა სიტყვებით რომ ვთქვათ, თქვენ კვლავ შეგიძლიათ შექმნათ OpenShift სერვისები და მართოთ ისინი Kubernetes-ის მეშვეობით, შეინახოთ ყველაფერი პოდებში, რომლებიც საჭიროებისამებრ იზრდება და მცირდება. და ამავდროულად, თქვენ შეგიძლიათ უსაფრთხოდ მიიღოთ თქვენი გარემოს გარე სერვისები. დიახ, კიდევ ერთხელ ვიმეორებთ, რომ ეს ყველაფერი შეიძლება გაკეთდეს თქვენს კოდს არანაირად შეხების გარეშე.

ეს იყო ბოლო პოსტი სერიაში ისტიოზე. თვალყური ადევნეთ - წინ ბევრი საინტერესო რამ გველის!

წყარო: www.habr.com