თანამედროვე ინფრასტრუქტურა: პრობლემები და პერსპექტივები

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

მონაწილეთა რაოდენობა:

• ევგენი პოტაპოვი, ITSumma-ს აღმასრულებელი დირექტორი. მისი მომხმარებლების ნახევარზე მეტი ან უკვე გადადის ან სურს Kubernetes-ზე გადასვლა.
• დიმიტრი სტოლიაროვი, CTO "Flant". აქვს კონტეინერულ სისტემებთან მუშაობის 10+ წლიანი გამოცდილება.
• დენის რემჩუკოვი (ანუ ერიკ ოლდმანი), COO argotech.io, ყოფილი RAO UES. „სისხლიან“ საწარმოში შემთხვევებზე საუბარი დაჰპირდა.
• ანდრეი ფედოროვსკი, CTO "News360.com"სხვა მოთამაშის მიერ კომპანიის შეძენის შემდეგ, ის პასუხისმგებელია ML და AI პროექტებზე და ინფრასტრუქტურაზე.
• ივან კრუგლოვი, სისტემების ინჟინერი, ყოფილი Booking.com.იგივე ადამიანი, რომელმაც ბევრი რამ გააკეთა კუბერნეტესთან საკუთარი ხელით.

თემები:

• მონაწილეთა შეხედულებები კონტეინერებისა და ორკესტრირების შესახებ (Docker, Kubernetes და ა.შ.); რაც პრაქტიკაში სცადეს ან გაანალიზეს.
• საქმე: კომპანია წლების განმავლობაში აშენებს ინფრასტრუქტურის განვითარების გეგმას. როგორ მიიღება გადაწყვეტილება, აშენდეს (ან გადაიტანოს ამჟამინდელი) ინფრასტრუქტურა კონტეინერებსა და კუბერში?
• პრობლემები ღრუბლიან სამყაროში, რა აკლია, წარმოვიდგინოთ რა იქნება ხვალ.

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

არის Kubernetes უკვე სტანდარტული თუ შესანიშნავი მარკეტინგი?

„ჩვენ მივედით მასზე (Kubernetes. - რედ.), როდესაც ჯერ არავინ იცოდა ამის შესახებ. ჩვენ მასთან მაშინაც მივედით, როცა იქ არ იყო. ადრე გვინდოდა" - დიმიტრი სტოლიაროვი

ფოტო Reddit.com-დან

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

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

Kubernetes არ არის მხოლოდ კონტეინერების ორკესტრირება, ეს არის კონფიგურაციის მართვის სისტემა განვითარებული API, ქსელის კომპონენტი, L3 ბალანსირება და Ingress კონტროლერები, რაც შედარებით მარტივს ხდის რესურსების მართვას, მასშტაბებს და ინფრასტრუქტურის ქვედა ფენებიდან აბსტრაქტს.

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

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

მონაცემთა ბაზების პრობლემა მოქალაქეობის არმქონეებში

ფოტო Twitter: @jankolario Unsplash-ზე

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

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

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

შეხვედრის მონაწილეები ორ ბანაკად დაიყვნენ.

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

თანამედროვე ღრუბლოვანი მონაცემთა ბაზებიც კი, როგორიცაა MongoDB და Cassandra, ან შეტყობინებების რიგები, როგორიცაა Kafka ან RabbitMQ, საჭიროებს მონაცემთა მუდმივ მაღაზიებს Kubernetes-ის გარეთ.

ევგენი აპროტესტებს: ”კუბერას ბაზები არის თითქმის რუსული ან საწარმოს დაზიანება, რაც დაკავშირებულია იმ ფაქტთან, რომ რუსეთში ღრუბლების მიღება არ არის.” დასავლეთში მცირე თუ საშუალო კომპანიები Cloud არიან. Amazon RDS მონაცემთა ბაზები უფრო ადვილი გამოსაყენებელია, ვიდრე თავად Kubernetes-თან შეხება. რუსეთში ისინი იყენებენ კუბერს „ინტერნატში“ და ბაზებს გადასცემენ მას, როცა ცდილობენ ზოოპარკის მოშორებას.

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

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

შემთხვევა 1. „მეგარეგულატორის“ კიბერუსაფრთხოება კუბერას გარეთ ბაზებით

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

შემთხვევა 2. Booking.com-ის მონაცემთა ბაზების ნაწილობრივი მიგრაცია Kubernetes-ში

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

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

მონაცემთა ბაზების მესამე კლასი არის Booking.com საძიებო სერვისი, სადაც თითოეული სერვისის კვანძი არის მონაცემთა ბაზა. საძიებო სერვისის Kuber-ზე გადაცემის მცდელობა ვერ მოხერხდა, რადგან თითოეული კვანძი შეიცავს 60-80 გბ ლოკალურ მეხსიერებას, რომლის „აწევა“ და „გახურება“ რთულია.

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

ინფრასტრუქტურის შერჩევა, როგორც ამოცანა ზოგადი გადაწყვეტის გარეშე

ფოტო მანუელ გეისინჯერი Pexels-დან

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

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

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

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

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

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

დენისმა გამოავლინა ორი ძირითადი კრიტერიუმი - მასშტაბურობა და მუშაობის სტაბილურობა. ის შეარჩევს იმ ინსტრუმენტებს, რომლებიც საუკეთესოდ შეეფერება დავალებას. „ეს შეიძლება იყოს თქვენს მუხლებზე აწყობილი ნონამი და მასზე აქვს Nutanix Community Edition. ეს შეიძლება იყოს მეორე სტრიქონი Kuber-ზე აპლიკაციის სახით, მონაცემთა ბაზაზე, რომელიც ტირაჟირებულია და აქვს მითითებული RTO და RPO პარამეტრები" (აღდგენის დრო/პუნქტის მიზნები - დაახლ.).

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

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

Kubernetes-ის გამოყენების შეფასება

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

ფოტო ტატიანა ერემინა Unsplash-ზე

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

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

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

რა გველოდება

ფოტო დრიუ ბიმერი Unsplash-ზე

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

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

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

დენისმა ასევე ახსენა Nutanix და VMWare vRealize Suite პროდუქტით, რომლებსაც შეუძლიათ გაუმკლავდნენ მსგავს ამოცანას კონტეინერიზაციის გარეშე.

დიმიტრიმ გაიზიარა თავისი მოსაზრება, რომ „ტკივილის“ შემცირება და გადასახადების შემცირება არის ორი სფერო, სადაც გაუმჯობესებას შეიძლება ველოდოთ.

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

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

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

  
  ფოტო გაბრიელ სანტოს ფოტოგრაფია Pexels-დან

  მინდა ვისარგებლო შემთხვევით და მივესალმო დედაჩემს და შეგახსენოთ, რომ ჩვენ გვაქვს ფეისბუქ ჯგუფი "დიდი IT პროექტების მართვა და განვითარება", არხი @feedmeto საინტერესო პუბლიკაციებით სხვადასხვა ტექნიკური ბლოგებიდან. და ჩემი არხი @rybakalexey, სადაც მე ვსაუბრობ განვითარების მენეჯმენტზე პროდუქტის კომპანიებში.

წყარო: www.habr.com