Kubernetes დაიპყრობს მსოფლიოს. როდის და როგორ?

მოლოდინში DevOpsConf ვიტალი ხაბაროვი გამოკითხული დიმიტრი სტოლიაროვი (დისტოლიფლანტის ტექნიკური დირექტორი და თანადამფუძნებელი. ვიტალიმ ჰკითხა დიმიტრის, რას აკეთებს ფლანტი, კუბერნეტესზე, ეკოსისტემის განვითარებაზე, მხარდაჭერაზე. ჩვენ განვიხილეთ, რატომ არის საჭირო Kubernetes და საჭიროა თუ არა ის საერთოდ. ასევე მიკროსერვისების, Amazon AWS-ის, DevOps-ისადმი მიდგომის „მე გამიმართლებს“, თავად Kubernetes-ის მომავალს, რატომ, როდის და როგორ დაიპყრობს ის მთელ მსოფლიოში, DevOps-ის პერსპექტივებსა და რისთვის უნდა მოემზადონ ინჟინრები. ნათელი და ახლო მომავალი გამარტივებითა და ნერვული ქსელებით.

ორიგინალური ინტერვიუ მოუსმინეთ როგორც პოდკასტი DevOps Deflop-ზე - რუსულენოვანი პოდკასტი DevOps-ის შესახებ და ქვემოთ მოცემულია ტექსტური ვერსია.

აქ და ქვემოთ ის სვამს კითხვებს ვიტალი ხაბაროვი ინჟინერი Express42-დან.

"ფლანტის" შესახებ

-გამარჯობა დიმა. შენ ხარ ტექნიკური დირექტორი"ფლანტი“ და ასევე მისი დამფუძნებელი. გთხოვთ, გვითხარით, რას აკეთებს კომპანია და რა ხართ მასში?

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




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

Kubernetes-ის შესახებ

— ბოლო დროს მე ვხედავ ბევრ რეპორტაჟს ფლანტისგან და სტატიები კუბერნეტის შესახებ. როგორ მიხვედი?

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

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

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

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

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

Kubernetes-ის შესახებ

— უშუალოდ ხარ ჩართული თავად კუბერნეტესის განვითარებაში?

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

— ამავდროულად, ავითარებთ თუ არა თქვენს ბევრ ხელსაწყოს Kubernetes-ის გარშემო?

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

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

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

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

Flanta ინსტრუმენტები

— მე ვიცი, რომ Flant-ს ახლა აქვს addon ოპერატორები, shell ოპერატორები და dapp/werf ინსტრუმენტები. როგორც მე მესმის, ეს არის იგივე ინსტრუმენტი სხვადასხვა ინკარნაციებში. მე ასევე მესმის, რომ Flaunt-ში კიდევ ბევრი განსხვავებული ინსტრუმენტია. Ეს მართალია?

დიმიტრი: ჩვენ კიდევ ბევრი გვაქვს GitHub-ზე. რაც ახლა მახსოვს, გვაქვს სტატუსის რუკა - პანელი Grafana-სთვის, რომელიც ყველას წააწყდა. იგი ნახსენებია თითქმის ყოველ მეორე სტატიაში Kubernetes-ის მონიტორინგის შესახებ Medium-ზე. შეუძლებელია მოკლედ ახსნა რა არის სტატუსის რუქა - მას ცალკე სტატია სჭირდება, მაგრამ ეს ძალიან სასარგებლოა დროთა განმავლობაში სტატუსის მონიტორინგისთვის, რადგან Kubernetes-ში ხშირად გვჭირდება სტატუსის ჩვენება დროთა განმავლობაში. ჩვენ ასევე გვაქვს LogHouse - ეს არის ClickHouse-ზე და შავ მაგიაზე დაფუძნებული ნივთი Kubernetes-ში ჟურნალების შეგროვებისთვის.

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

ეკოსისტემის განვითარება

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

დიმიტრი: რუსეთში, იმ კომპანიებიდან, რომლებიც ჩვენს ბაზარზე ოპერირებენ, ახლოსაც კი არავინაა. რა თქმა უნდა, ეს ხმამაღალი განცხადებაა, რადგან არსებობენ ისეთი ძირითადი მოთამაშეები, როგორიცაა Mail და Yandex - ისინი ასევე აკეთებენ რაღაცას Kubernetes-თან, მაგრამ ისინიც კი არ უახლოვდებიან იმ კომპანიების წვლილს მთელ მსოფლიოში, რომლებიც ჩვენზე მეტს აკეთებენ. ძნელია შეადარო ფლანტი, რომელსაც 80 კაციანი პერსონალი ჰყავს და Red Hat, რომელსაც მარტო კუბერნეტესზე 300 ინჟინერი ჰყავს, თუ არ ვცდები. ძნელია შედარება. RnD განყოფილებაში გვყავს 6 ადამიანი, მათ შორის მეც, რომლებიც ჩვენს ყველა ხელსაწყოს ჭრიან. 6 ადამიანი 300 Red Hat-ის ინჟინრის წინააღმდეგ - რაღაცნაირად რთულია შედარება.

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

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

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

ეს არის ჩვენი დიდი სტრატეგიის ნაწილი dapp/werf-თან. არ მახსოვს როდის დავიწყეთ მისი დამზადება, ეტყობა 3 წლის წინ. თავდაპირველად, ის ძირითადად ჭურვიზე იყო. ეს იყო კონცეფციის სუპერ მტკიცებულება, ჩვენ გადავწყვიტეთ ჩვენი ზოგიერთი კონკრეტული პრობლემა - ის მუშაობდა! მაგრამ ჭურვის პრობლემებია, მისი შემდგომი გაფართოება შეუძლებელია, ჭურვიზე პროგრამირება კიდევ ერთი ამოცანაა. ჩვენ გვქონდა რუბიში წერის ჩვევა, შესაბამისად, რაღაც გადავაკეთეთ Ruby-ში, განვავითარეთ, განვავითარეთ, განვავითარეთ და შევეჯახეთ იმ ფაქტს, რომ საზოგადოება, ბრბო, რომელიც არ ამბობს „გვინდა ან არ გვინდა, ”ცხვირს აბრუნებს რუბის, როგორ არ არის ეს სასაცილო? ჩვენ მივხვდით, რომ ეს ყველაფერი უნდა ჩავწეროთ Go-ში მხოლოდ იმისთვის, რომ შევხვდეთ საკონტროლო სიის პირველ პუნქტს: DevOps ინსტრუმენტი უნდა იყოს სტატიკური ორობითი. Go-ში ყოფნა არც ისე მნიშვნელოვანია, მაგრამ Go-ში დაწერილი სტატიკური ორობითი უკეთესია.

ჩვენ დავხარჯეთ ჩვენი ენერგია, გადავწერეთ დაპი Go-ში და დავარქვით მას werf. Dapp აღარ არის მხარდაჭერილი, არ არის განვითარებული, მუშაობს უახლეს ვერსიაში, მაგრამ არის აბსოლუტური განახლების გზა ზევით და შეგიძლიათ მიჰყვეთ მას.

რატომ შეიქმნა dapp?

— შეგიძლიათ მოკლედ გვითხრათ, რატომ შეიქმნა დაპი, რა პრობლემებს წყვეტს იგი?

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

მეორე მიზეზი არის განლაგება. დიახ, არსებობს Helm, მაგრამ ის წყვეტს მხოლოდ ზოგიერთ პრობლემას. სასაცილოდ წერია, რომ „ჰელმი არის კუბერნეტის პაკეტის მენეჯერი“. ზუსტად ის, რაც "ა". ასევე არის სიტყვები „პაკეტის მენეჯერი“ - როგორია ჩვეულებრივი მოლოდინი პაკეტის მენეჯერისგან? ჩვენ ვამბობთ: "პაკეტის მენეჯერი - დააინსტალირეთ პაკეტი!" და ჩვენ ველით, რომ ის გვეტყვის: "ამანათი მიიტანეს".

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

გამოდის, რომ Helm არის მხოლოდ ტექსტის წინასწარი პროცესორი, რომელიც იტვირთავს მონაცემებს Kubernetes-ში.

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

გეგმები

წელს ჩვენ დავიწყებთ ადგილობრივ განვითარებას. ჩვენ გვინდა მივაღწიოთ იმას, რაც ადრე იყო Vagrant-ში - ჩვენ აკრიფეთ "vagrant up" და განვათავსეთ ვირტუალური მანქანები. ჩვენ გვინდა მივიდეთ იქამდე, სადაც არის პროექტი Git-ში, ჩვენ ვწერთ „werf up“-ს და ის აჩენს ამ პროექტის ლოკალურ ასლს, რომელიც განლაგებულია ადგილობრივ მინი-კუბში, სადაც დაკავშირებულია განვითარებისთვის მოსახერხებელი ყველა დირექტორია. . განვითარების ენიდან გამომდინარე, ეს კეთდება განსხვავებულად, მაგრამ მიუხედავად ამისა, ისე, რომ ადგილობრივი განვითარება მოხერხებულად განხორციელდეს დამონტაჟებული ფაილების ქვეშ.

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

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

მთელ ამ ამბავს სხვა გზაც აქვს, ანალოგიებით.

Kubernetes არის მანქანის ჩარჩო ძრავით. არ არის კარები, მინა, რადიო, ნაძვის ხე - საერთოდ არაფერი. მხოლოდ ჩარჩო და ძრავა. და არის Helm - ეს არის საჭე. მაგარი - არის საჭე, მაგრამ თქვენ ასევე გჭირდებათ საჭის ქინძისთავები, საჭის თარო, გადაცემათა კოლოფი და ბორბლები და მათ გარეშე არ შეგიძლიათ.

werf-ის შემთხვევაში, ეს არის Kubernetes-ის კიდევ ერთი კომპონენტი. მხოლოდ ახლა werf-ის ალფა ვერსიაში, მაგალითად, Helm არის შედგენილი werf-ის შიგნით, რადგან დავიღალეთ ამის კეთებით. ამის გაკეთების მრავალი მიზეზი არსებობს, მე დეტალურად გეტყვით, თუ რატომ შევადგინეთ მთელი საჭე ერთად ტილერთან ერთად ანგარიშზე RIT++-ზე.

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

ძნელია კუბერნეტის შენარჩუნება?

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

დიმიტრი: ეს ძალიან რთული კითხვაა და პასუხის გასაცემად უნდა გავიგოთ რა არის მხარდაჭერა და რა გვინდა Kubernetes-ისგან. იქნებ გამიმხილოთ?

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

დიმიტრი: ასეა.

— რამდენად რთულია Kubernetes-ის ნულიდან აღება და დაყენება, რათა ის მზად იყოს?

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

Kubernetes-ის დაყენება და მისი მუშაობა მარტივია: ჩიკ! — დაინსტალირებულია, ინსტალაციის უამრავი მეთოდი არსებობს. მაგრამ რა ხდება, როდესაც პრობლემები წარმოიქმნება?

ყოველთვის ჩნდება კითხვები - რა არ გავითვალისწინეთ ჯერ? რა არ გავაკეთეთ ჯერ? Linux-ის ბირთვის რომელი პარამეტრები იყო მითითებული არასწორად? უფალო, ჩვენ კი ვახსენეთ ისინი?! რომელი Kubernetes კომპონენტები მივაწოდეთ და რომელი არა? ათასობით კითხვა ჩნდება და მათზე პასუხის გასაცემად, თქვენ უნდა გაატაროთ 15-20 წელი ამ ინდუსტრიაში.

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

ნება მომეცით აგიხსნათ რა არის Cilium. Kubernetes-ს აქვს ქსელის ქვესისტემის მრავალი განსხვავებული დანერგვა და ერთ-ერთი მათგანი ძალიან მაგარია - Cilium. რა არის მისი მნიშვნელობა? ბირთვში რამდენიმე ხნის წინ შესაძლებელი გახდა ბირთვისთვის ჰუკების დაწერა, რომლებიც ასე თუ ისე შემოიჭრება ქსელის ქვესისტემაში და სხვადასხვა სხვა ქვესისტემებში და საშუალებას გაძლევთ გვერდის ავლით გვერდის ავლით კერნელის დიდი ნაწილაკები.

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

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

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

რა მოხდება, თუ რამე არასწორედ მოხდება? Ჩვენ არ ვიცით. ამის გასაგებად, თქვენ უნდა წაიკითხოთ მთელი ეს კოდი, გაიგოთ მთელი ლოგიკა და გასაოცარია, რამდენად რთულია ეს. მაგრამ, მეორე მხრივ, არის ეს ხიდები, ქსელის ფილტრები, ip rout - მე არ წამიკითხავს მათი წყაროს კოდი და არც 40 ინჟინერი, რომელიც მუშაობს ჩვენს კომპანიაში. შესაძლოა მხოლოდ რამდენიმეს ესმის ზოგიერთი ნაწილი.

და რა განსხვავებაა? გამოდის, რომ არის ip rout, Linux kernel და არის ახალი ინსტრუმენტი - რა განსხვავებაა, ჩვენ არ გვესმის ერთი ან მეორე. მაგრამ ჩვენ გვეშინია რაიმე ახალი გამოვიყენოთ - რატომ? იმიტომ, რომ თუ ხელსაწყო 30 წლისაა, მაშინ 30 წელიწადში ყველა ხარვეზი იპოვეს, ყველა შეცდომა დაფიქსირდა და არ გჭირდებათ ყველაფრის ცოდნა - ის მუშაობს როგორც შავი ყუთი და ყოველთვის მუშაობს. ყველამ იცის, რომელი სადიაგნოსტიკო ხრახნიანი რომელ ადგილას დააწებოთ, რომელი tcpdump რომელ მომენტში გაუშვას. ყველამ კარგად იცის დიაგნოსტიკური საშუალებები და ესმის, როგორ მუშაობს კომპონენტების ეს ნაკრები Linux-ის ბირთვში - არა როგორ მუშაობს, არამედ როგორ გამოიყენოს იგი.

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

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

"მე გამიმართლებს" მიდგომის შესახებ

— არის კომპანიები, სადაც ეს ნიუანსები თითქმის გარანტირებულია? დავუშვათ, Yandex მოულოდნელად გადასცემს ყველა სერვისს Kubernetes-ზე, იქ იქნება უზარმაზარი დატვირთვა.

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

მე მაქვს Ubuntu 16.04. შეიძლება ითქვას, რომ ეს ძველი ვერსიაა, მაგრამ ჩვენ ჯერ კიდევ მასზე ვართ, რადგან ის არის LTS. არის systemd, რომლის ნიუანსია ის, რომ არ ასუფთავებს C-ჯგუფებს. Kubernetes უშვებს პოდებს, ქმნის C-ჯგუფებს, შემდეგ აშორებს პოდებს და რატომღაც გამოდის - დეტალები არ მახსოვს, ბოდიში - ეს სისტემური ნაჭრები რჩება. ეს იწვევს იმ ფაქტს, რომ დროთა განმავლობაში, ნებისმიერი მანქანა იწყებს ძლიერ შენელებას. ეს არც კი არის შეკითხვა მაღალი დატვირთვის შესახებ. თუ მუდმივი პოდები გაშვებულია, მაგალითად, თუ არის Cron Job, რომელიც მუდმივად წარმოქმნის პოდებს, მაშინ მანქანა Ubuntu 16.04-ით დაიწყებს შენელებას ერთი კვირის შემდეგ. მუდმივად მაღალი დატვირთვის საშუალო იქნება იმის გამო, რომ შეიქმნა C-ჯგუფების თაიგული. ეს არის პრობლემა, რომელსაც შეექმნება ნებისმიერი ადამიანი, ვინც უბრალოდ დააინსტალირებს Ubuntu 16-ს და Kubernetes-ს თავზე.

ვთქვათ, ის როგორღაც განაახლებს systemd-ს ან სხვა რამეს, მაგრამ Linux-ის ბირთვში 4.16-მდე ეს კიდევ უფრო სასაცილოა - როდესაც თქვენ წაშლით C-ჯგუფებს, ისინი გაჟონავს ბირთვში და რეალურად არ იშლება. ამიტომ ამ მანქანაზე მუშაობის ერთი თვის შემდეგ შეუძლებელი იქნება კერების მეხსიერების სტატისტიკის ნახვა. ჩვენ ამოვიღებთ ფაილს, ვაგორებთ პროგრამაში და ერთი ფაილი ტრიალებს 15 წამის განმავლობაში, რადგან ბირთვს ძალიან დიდი დრო სჭირდება, რომ დათვალოს მილიონი C ჯგუფი თავის შიგნით, რომლებიც თითქოს წაშლილია, მაგრამ არა - ისინი ჟონავს. .

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

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

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

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

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

დიმიტრი: ობიექტურად ასეა. პატარა გუნდისთვის Kubernetes-ის ისტორიაში მოხვედრა უამრავ რისკს მოიცავს.

გვჭირდება კონტეინერები?

— შეგიძლიათ გვითხრათ, რამდენად გავრცელებულია Kubernetes რუსეთში?

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

შემდეგ კიდევ ერთი კითხვა - გვჭირდება კონტეინერები? ჩემი პირადი განცდა და ფლანტის კომპანიის საერთო პოზიცია არის ის, რომ Kubernetes არის დე ფაქტო სტანდარტი.

კუბერნეტის გარდა არაფერი იქნება.

ეს არის აბსოლუტური თამაშის შეცვლა ინფრასტრუქტურის მართვის სფეროში. უბრალოდ აბსოლუტური - ეს არის ის, აღარ არის Ansible, Chef, ვირტუალური მანქანები, Terraform. მე არ ვსაუბრობ ძველ კოლმეურნეობის მეთოდებზე. კუბერნეტესი არის აბსოლუტური შემცვლელიდა ახლა მხოლოდ ასე იქნება.

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

— ანუ ის კომპანიები, რომლებიც ჯერ არ გადასულან Kubernetes-ზე, აუცილებლად გადაერთვებიან ან დავიწყებაში დარჩებიან. სწორად გავიგე?

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

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

მიკროსერვისების შესახებ

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

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

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

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

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

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

კუბერნეტესი არ დგას. კიდევ ერთხელ შეკითხვა: კუბერნეტები, ერთი მხრივ, არის 4-5 ორობითი, მეორე მხრივ, ეს არის მთელი ეკოსისტემა. ეს არის ოპერაციული სისტემა, რომელიც ჩვენ გვაქვს ჩვენს აპარატებზე. Ეს რა არის? Ubuntu თუ Curios? ეს არის Linux-ის ბირთვი, დამატებითი კომპონენტების თაიგული. ეს ყველაფერი აქ, ერთი შხამიანი გველი გადმოაგდეს გზიდან, იქ ღობე აღმართეს. Kubernetes ძალიან სწრაფად და დინამიურად ვითარდება და ყოველთვიურად მცირდება რისკების მოცულობა, უცნობის მოცულობა და, შესაბამისად, ეს სასწორები ხელახლა ბალანსდება.

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

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

Amazon-ისა და Google-ის შესახებ

— შეიძლება თუ არა ამაზონის ან გუგლის გადაწყვეტილების ჰოსტი ჩაითვალოს აუთსორსად?

დიმიტრი: დიახ, რა თქმა უნდა, ეს ბევრ საკითხს წყვეტს. მაგრამ ისევ არის ნიუანსები. თქვენ ჯერ კიდევ უნდა გესმოდეთ, როგორ გამოიყენოთ იგი. მაგალითად, Amazon AWS-ის მუშაობაში ათასი წვრილმანია: საჭიროა Load Balancer-ის გაცხელება ან წინასწარ უნდა დაიწეროს მოთხოვნა, რომ „ბიჭებო, ჩვენ მივიღებთ ტრაფიკს, გაათბეთ Load Balancer ჩვენთვის!“ თქვენ უნდა იცოდეთ ეს ნიუანსი.

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

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

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

ვის სჭირდება Kubernetes?

— და მაინც, ვის სჭირდება Kubernetes? ვინ უნდა გადავიდეს უკვე Kubernetes-ზე, რომელიც არის ტიპიური Flaunt კლიენტი, რომელიც სპეციალურად მოდის Kubernetes-ისთვის?

დიმიტრი: ეს საინტერესო კითხვაა, რადგან ახლა, კუბერნეტების გამო, ბევრი ადამიანი მოდის ჩვენთან: "ბიჭებო, ჩვენ ვიცით, რომ თქვენ აკეთებთ კუბერნეტებს, გააკეთეთ ეს ჩვენთვის!" ჩვენ მათ ვპასუხობთ: „ბატონებო, ჩვენ არ ვაკეთებთ კუბერნეტებს, ჩვენ ვაკეთებთ აჟიოტაჟს და ყველაფერს, რაც მას უკავშირდება“. იმიტომ, რომ ამჟამად უბრალოდ შეუძლებელია პროდუქტის დამზადება ყველა CI/CD და მთელი ამ ამბის გარეშე. ყველა ჩამოშორდა იმ დაყოფას, რომ ჩვენ გვაქვს განვითარება განვითარებით, შემდეგ კი ექსპლუატაცია ექსპლუატაციით.

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

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

პასუხი კითხვაზე, ვის სჭირდება Kubernetes - არავის სჭირდება Kubernetes.

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

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

ფორმულირება, რომ ჩვენ ან ვინმეს გვჭირდება Kubernetes, არასწორია.

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

არ არის საჭირო წარმოებასთან თამაში. რასაც კატეგორიულად გირჩევთ არ გააკეთოთ და რასაც ახლა მასობრივად ვხედავ: "ოჰ, ახალი სათამაშო!" — გაიქცნენ მის საყიდლად, იყიდეს და: „ახლა წავიყვანოთ სკოლაში და ვაჩვენოთ ყველა ჩვენს მეგობარს“. არ გააკეთო ეს. ბოდიშს ვიხდი, ჩემი შვილები ახლახან იზრდებიან, მე გამუდმებით ვხედავ რაღაცას ბავშვებში, ვამჩნევ საკუთარ თავში და მერე განზოგადება სხვებზე.

საბოლოო პასუხი არის: თქვენ არ გჭირდებათ Kubernetes. თქვენ უნდა მოაგვაროთ თქვენი პრობლემები.

რისი მიღწევაც შეგიძლიათ არის:

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

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

სერვერის გარეშე

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

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

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

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

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

როგორ განვითარდება კუბერნეტები

— როცა მივდივართ ამ პოტენციურად მშვენიერი შორეული მომავლისკენ, როგორ ფიქრობთ, როგორ განვითარდება Kubernetes და მის გარშემო არსებული ეკოსისტემა?

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

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

საგრძნობლად დაეცემა უცნობის დონე, გადაუჭრელი პრობლემების დონე, რაღაცის შეხვედრის ალბათობის დონე. ეს მნიშვნელოვანი ამბავია. და ოპერატორები - ყველაფერი, რაც დაკავშირებულია ადმინისტრაციის ლოგიკის კოდიფიკაციასთან, საკონტროლო ლოგიკასთან, რათა მივიღოთ მარტივი სერვისი: MySQL მარტივი სერვისი, RabbitMQ მარტივი სერვისი, Memcache easy სერვისი - ზოგადად, ყველა ეს კომპონენტი, რომლის დამუშავებაც გარანტირებული გვჭირდება. ყუთი. ეს უბრალოდ აგვარებს ტკივილს, რომ ჩვენ გვინდა მონაცემთა ბაზა, მაგრამ არ გვინდა მისი ადმინისტრირება, ან გვინდა Kubernetes, მაგრამ არ გვინდა მისი ადმინისტრირება.

ოპერატორის ამა თუ იმ ფორმით განვითარების ეს ისტორია მნიშვნელოვანი იქნება მომდევნო ორი წლის განმავლობაში.

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

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

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

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

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

რა ვუყოთ ინჟინრებს?

— მერე რა დაემართება ინჟინერებსა და სისტემის ადმინისტრატორებს, რომლებიც მხარს უჭერენ Kubernetes-ს?

დიმიტრი: რა დაემართა ბუღალტერს 1C-ის გაჩენის შემდეგ? Დაახლოებით იგივე. მანამდე ქაღალდზე ითვლიდნენ - ახლა პროგრამაშია. შრომის პროდუქტიულობა გაიზარდა მასშტაბების ბრძანებით, მაგრამ თავად შრომა არ გამქრალა. თუ ადრე 10 ინჟინერი სჭირდებოდა ნათურის ჩაკვრას, ახლა ერთიც საკმარისი იქნება.

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

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

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

DevOps ან სისტემების ინჟინერია არ გაქრება - გაიზრდება მაღალი დონის მუშაობა და ეფექტურობა.

— საინტერესო აზრიც მოვისმინე, რომ სამუშაო რეალურად გაიზრდება.

დიმიტრი: რა თქმა უნდა, ასი პროცენტით! იმის გამო, რომ ჩვენს მიერ დაწერილი პროგრამული უზრუნველყოფის რაოდენობა მუდმივად იზრდება. პრობლემების რაოდენობა, რომლებსაც ჩვენ პროგრამული უზრუნველყოფის საშუალებით ვაგვარებთ, მუდმივად იზრდება. სამუშაოს მოცულობა იზრდება. ახლა DevOps ბაზარი საშინლად გადახურებულია. ეს ჩანს ხელფასის მოლოდინში. კარგი კუთხით, დეტალებში შესვლის გარეშე, უნდა იყვნენ უმცროსები, რომლებსაც უნდათ X, საშუალოები, რომლებსაც სურთ 1,5X და უფროსები, რომლებსაც სურთ 2X. ახლა კი, თუ გადავხედავთ მოსკოვის DevOps-ის სახელფასო ბაზარს, უმცროსს სურს X-დან 3X-მდე და უფროსს სურს X-დან 3X-მდე.

არავინ იცის რა ღირს. ხელფასის დონე იზომება თქვენი ნდობით - სრული საგიჟეთი, მართალი გითხრათ, საშინლად გადახურებული ბაზარი.

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

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

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

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

სურვილები და ერთი წუთი რეკლამა

- სურვილი გაქვს?

დიმიტრი: დიახ, რამდენიმე სურვილი მაქვს.

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

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

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

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

- Ძალიან დიდი მადლობა!

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

ინტერვიუში დიმიტრი შეეხო ვერფის საკითხს. ახლა ეს არის უნივერსალური შვეიცარიული დანა, რომელიც წყვეტს თითქმის ყველა პრობლემას. მაგრამ ყოველთვის ასე არ იყო. ჩართულია DevOpsConf  ფესტივალზე RIT++ დიმიტრი სტოლიაროვი დეტალურად გეტყვით ამ ხელსაწყოს შესახებ. მოხსენებაში "werf არის ჩვენი ინსტრუმენტი CI/CD-ისთვის Kubernetes-ში" იქნება ყველაფერი: პრობლემები და კუბერნეტის ფარული ნიუანსი, ამ სირთულეების გადაჭრის ვარიანტები და დეტალურად ვერფის მიმდინარე განხორციელება. შემოგვიერთდით 27 და 28 მაისს, ჩვენ შევქმნით სრულყოფილ ინსტრუმენტებს.

წყარო: www.habr.com