5 საღი აზრის პრინციპი Cloud-Native აპების შესაქმნელად

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

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

პროგრამული უზრუნველყოფის დიზაინის პრინციპები

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

• KISS (Seep it simple, stupid) – არ გაართულო;
• მშრალი (არ გაიმეორო) - არ გაიმეორო;
• YAGNI (თქვენ არ დაგჭირდებათ) - ნუ შექმნით იმას, რაც დაუყოვნებლივ არ არის საჭირო;
• SoC საზრუნავების გამიჯვნა - პასუხისმგებლობის გაზიარება.

როგორც ხედავთ, ეს პრინციპები არ ადგენს რაიმე კონკრეტულ წესებს, მაგრამ მიეკუთვნება ეგრეთ წოდებული საღი აზრის მოსაზრებების კატეგორიას, რომელიც დაფუძნებულია პრაქტიკულ გამოცდილებაზე, რომელსაც იზიარებს მრავალი დეველოპერი და რომელსაც ისინი რეგულარულად მიმართავენ.
გარდა ამისა, არსებობს ᲛᲧᲐᲠᲘ – ობიექტზე ორიენტირებული პროგრამირებისა და დიზაინის პირველი ხუთი პრინციპის ნაკრები, ჩამოყალიბებული რობერტ მარტინის მიერ. SOLID მოიცავს ფართო, ღია დასრულებულ, შემავსებელ პრინციპებს, რომლებიც ერთობლივად გამოყენებისას ხელს უწყობს უკეთესი პროგრამული სისტემების შექმნას და მათ უკეთ შენარჩუნებას გრძელვადიან პერსპექტივაში.

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

ღრუბლოვანი კონტეინერები: Red Hat მიდგომა

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

ერთიანი შეშფოთების პრინციპი (SCP)

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

SCP-ში ჩვენ ვიყენებთ სიტყვას „შეშფოთება“ სიტყვის „პასუხისმგებლობის“ ნაცვლად, რათა მიუთითოთ კონტეინერის აბსტრაქციის უფრო მაღალი დონე და უფრო ფართო დანიშნულება OOP კლასთან შედარებით. და თუ SRP-ის მიზანია ცვლილების მხოლოდ ერთი მიზეზი ჰქონდეს, მაშინ SCP-ის უკან დგას კონტეინერების ხელახალი გამოყენებისა და შეცვლის უნარის გაფართოების სურვილი. SRP-ის მიყოლებით და კონტეინერის შექმნით, რომელიც აგვარებს ერთ პრობლემას და აკეთებს მას ფუნქციურად სრულყოფილად, თქვენ გაზრდით ამ კონტეინერის გამოსახულების ხელახლა გამოყენების შანსებს აპლიკაციის სხვადასხვა კონტექსტში.

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

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

მაღალი დაკვირვებადობის პრინციპი (HOP)

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

პრაქტიკაში, კონტეინერულ აპლიკაციას უნდა ჰქონდეს მინიმუმ API ჯანმრთელობის სხვადასხვა ტიპის შემოწმებისთვის: სიცოცხლისუნარიანობის ტესტები და მზადყოფნის ტესტები. თუ აპლიკაცია აცხადებს, რომ მეტის გაკეთებას აპირებს, მან უნდა უზრუნველყოს მისი მდგომარეობის მონიტორინგის სხვა საშუალებები. მაგალითად, მნიშვნელოვანი მოვლენების აღრიცხვა STDERR-ისა და STDOUT-ის მეშვეობით ჟურნალის აგრეგაციისთვის Fluentd, Logstash და სხვა მსგავსი ხელსაწყოების გამოყენებით. ასევე ინტეგრაცია ტრასინგისა და მეტრიკის კოლექციების ბიბლიოთეკებთან, როგორიცაა OpenTracing, Prometheus და ა.შ.

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

სიცოცხლის ციკლის შესაბამისობის პრინციპი (LCP)

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

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

ნათელია, რომ ზოგიერთი მოვლენა უფრო მნიშვნელოვანია, ვიდრე სხვები. მაგალითად, თუ აპლიკაცია კარგად არ მოითმენს ავარიას, მან უნდა მიიღოს სიგნალი: შეწყვიტოს (SIGTERM) შეტყობინებები და დაიწყოს მისი შეწყვეტის რუტინა რაც შეიძლება სწრაფად, რათა დაიჭიროს სიგნალი: kill (SIGKILL), რომელიც მოდის SIGTERM-ის შემდეგ.

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

გამოსახულების უცვლელობის პრინციპი (IIP)

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

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

პროცესის განკარგვის პრინციპი (PDP)

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

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

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

თვითშეკავების პრინციპი (S-CP)

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

გამონაკლისი დაშვებულია კონფიგურაციებისთვის, რომლებიც განსხვავდება გარემოდან გარემოში და უნდა იყოს მოწოდებული გაშვების დროს, მაგალითად, Kubernetes ConfigMap-ის მეშვეობით.

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

Runtime Confinement Principle (RCP)

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

და აქ გამოდგება RCP პრინციპი, რომლის მიხედვითაც, კონტეინერმა უნდა ამოიღოს თავისი მოთხოვნები სისტემის რესურსებზე და გადაიტანოს ისინი პლატფორმაზე. თითოეული კონტეინერის რესურსის პროფილებით (რამდენი CPU, მეხსიერება, ქსელი და დისკის რესურსები სჭირდება), პლატფორმას შეუძლია ოპტიმალურად შეასრულოს დაგეგმვა და ავტოსკალირება, მართოს IT მოცულობა და შეინარჩუნოს SLA დონეები კონტეინერებისთვის.

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

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

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

• შეეცადეთ შეამციროთ სურათების ზომა: წაშალეთ დროებითი ფაილები და არ დააინსტალიროთ არასაჭირო პაკეტები - რაც უფრო მცირეა კონტეინერის ზომა, მით უფრო სწრაფად იკრიბება და კოპირდება სამიზნე ჰოსტში ქსელში.
• ფოკუსირება თვითნებურ მომხმარებლის ID-ებზე: არ გამოიყენოთ sudo ბრძანება ან რაიმე სპეციალური მომხმარებლის ID თქვენი კონტეინერების გასაშვებად.
• მნიშვნელოვანი პორტების მონიშვნა: თქვენ შეგიძლიათ დააყენოთ პორტის ნომრები გაშვების დროს, მაგრამ უმჯობესია მიუთითოთ ისინი EXPOSE ბრძანების გამოყენებით - ეს გაუადვილებს სხვა ადამიანებსა და პროგრამებს თქვენი სურათების გამოყენებას.
• შეინახეთ მუდმივი მონაცემები ტომებზე: მონაცემები, რომლებიც უნდა დარჩეს კონტეინერის განადგურების შემდეგ, უნდა ჩაიწეროს ტომებში.
• დაწერეთ სურათის მეტამონაცემები: ტეგები, ეტიკეტები და ანოტაციები აადვილებს გამოსახულების გამოყენებას - სხვა დეველოპერები მადლობას მოგახსენებთ.
• ჰოსტისა და სურათების სინქრონიზაცია: ზოგიერთი კონტეინერიზებული აპლიკაცია მოითხოვს კონტეინერის სინქრონიზაციას ჰოსტთან გარკვეული ატრიბუტებით, როგორიცაა დრო ან მანქანის ID.
• დასასრულს, ჩვენ ვიზიარებთ შაბლონებს და საუკეთესო პრაქტიკას, რომელიც დაგეხმარებათ უფრო ეფექტურად განახორციელოთ ზემოთ ჩამოთვლილი პრინციპები:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

ვებინარი OpenShift კონტეინერის პლატფორმის ახალ ვერსიაზე – 4
11 ივნისს, 11.00 საათზე

რას ისწავლით:

• შეუცვლელი Red Hat Enterprise Linux CoreOS
• OpenShift სერვისის ბადე
• ოპერატორის ჩარჩო
• ნატიური ჩარჩო

წყარო: www.habr.com