წარმოგიდგენთ Helm 3-ს

Შენიშვნა. თარგმნა: ამ წლის 16 მაისი აღნიშნავს მნიშვნელოვან ეტაპს Kubernetes-ის პაკეტის მენეჯერის განვითარებაში - Helm. ამ დღეს გაიმართა პროექტის მომავალი ძირითადი ვერსიის - 3.0 - პირველი ალფა გამოშვების პრეზენტაცია. მისი გამოშვება მნიშვნელოვან და დიდი ხნის ნანატრი ცვლილებებს მოუტანს Helm-ს, რაზეც კუბერნეტის საზოგადოებაში ბევრს დიდი იმედი აქვს. ჩვენ თვითონ ვართ ერთ-ერთი მათგანი, რადგან აქტიურად ვიყენებთ Helm-ს აპლიკაციის განსათავსებლად: ჩვენ ის ინტეგრირებული გვაქვს ჩვენს ინსტრუმენტში CI/CD-ის დანერგვისთვის. ვერფ და დროდადრო ჩვენ შევიტანთ ჩვენს წვლილს ზემოთ ნაკადის განვითარებაში. ეს თარგმანი აერთიანებს 7 ნოტს Helm-ის ოფიციალური ბლოგიდან, რომელიც ეძღვნება Helm 3-ის პირველ ალფა გამოშვებას და საუბრობს პროექტის ისტორიასა და Helm 3-ის ძირითად მახასიათებლებზე. მათი ავტორია Matt “bacongobbler” Fisher, Microsoft-ის თანამშრომელი. და ჰელმის ერთ-ერთი მთავარი მცველი.

15 წლის 2015 ოქტომბერს დაიბადა პროექტი, რომელიც ახლა ცნობილია როგორც Helm. დაარსებიდან სულ რაღაც ერთი წლის შემდეგ, Helm-ის საზოგადოება შეუერთდა Kubernetes-ს, სანამ აქტიურად მუშაობდა Helm 2-ზე. 2018 წლის ივნისში, Helm შეუერთდა CNCF-ს როგორც განვითარებადი (ინკუბაციური) პროექტი. იჩქარეთ აწმყომდე და ახალი Helm 3-ის პირველი ალფა გამოშვება უკვე გზაზეა. (ეს გამოშვება უკვე შედგა მაისის შუა რიცხვებში - დაახლ. თარგმანი.).

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

რეზიუმე:

• ჰელმის შექმნის ისტორია;
• ტილერთან ნაზი დამშვიდობება;
• დიაგრამების საცავი;
• გამოშვების მართვა;
• დიაგრამის დამოკიდებულებების ცვლილებები;
• ბიბლიოთეკის სქემები;
• რა არის შემდეგი?

ჰელმის ისტორია

დაბადება

Helm 1 დაიწყო როგორც Deis-ის მიერ შექმნილი ღია კოდის პროექტი. ჩვენ პატარა სტარტაპი ვიყავით შეიწოვება Microsoft 2017 წლის გაზაფხულზე. ჩვენს სხვა ღია კოდის პროექტს, ასევე სახელად Deis, ჰქონდა ინსტრუმენტი deisctl, რომელიც გამოიყენებოდა (სხვა საკითხებთან ერთად) დეის პლატფორმის ინსტალაციისა და მუშაობისთვის ფლოტის კასეტური. იმ დროს ფლოტი იყო ერთ-ერთი პირველი კონტეინერის ორკესტრირების პლატფორმა.

2015 წლის შუა რიცხვებში გადავწყვიტეთ შეგვეცვალა კურსი და Deis (იმ დროს დაარქვეს Deis Workflow) ფლოტიდან Kubernetes-ში გადავიყვანეთ. ერთ-ერთი პირველი, რომელიც გადაკეთდა, იყო ინსტალაციის ინსტრუმენტი. deisctl. ჩვენ გამოვიყენეთ იგი ფლოტის კლასტერში Deis Workflow-ის ინსტალაციისა და მართვისთვის.

Helm 1 შეიქმნა ცნობილი პაკეტის მენეჯერების იმიჯით, როგორიცაა Homebrew, apt და yum. მისი მთავარი მიზანი იყო ამოცანების გამარტივება, როგორიცაა შეფუთვა და აპლიკაციების ინსტალაცია Kubernetes-ზე. Helm ოფიციალურად დაინერგა 2015 წელს სან-ფრანცისკოში KubeCon კონფერენციაზე.

ჩვენი პირველი მცდელობა ჰელმთან მუშაობდა, მაგრამ ეს არ იყო სერიოზული შეზღუდვების გარეშე. მან აიღო Kubernetes-ის მანიფესტების ნაკრები, გენერატორებით არომატიზებული, როგორც შესავალი YAML ბლოკები. (წინა მატერია)* და ჩაიტვირთა შედეგები Kubernetes-ში.

* Შენიშვნა. თარგმნა: Helm-ის პირველი ვერსიიდან, YAML სინტაქსი შეირჩა Kubernetes რესურსების აღსაწერად, ხოლო Jinja შაბლონები და პითონის სკრიპტები მხარდაჭერილი იყო კონფიგურაციების დაწერისას. ამის შესახებ და ზოგადად ჰელმის პირველი ვერსიის სტრუქტურის შესახებ უფრო მეტი დავწერეთ თავში „ჰელმის მოკლე ისტორია“ ამ მასალას.

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

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

მშვენიერია, რომ შაბლონის ძრავები არსებობს დღეს, არა?

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

წარსული შეცდომების გამოცდილებიდან გამომდინარე, ჩვენ დავიწყეთ Helm 2-ის შემუშავება.

ჩაფხუტის დამზადება 2

2015 წლის ბოლოს Google-ის გუნდი დაგვიკავშირდა. ისინი მუშაობდნენ მსგავს ინსტრუმენტზე Kubernetes-ისთვის. Kubernetes-ისთვის განლაგების მენეჯერი იყო არსებული ხელსაწყოს პორტი, რომელიც გამოიყენებოდა Google Cloud Platform-ისთვის. „გვინდა,“ ჰკითხეს მათ, „რამოდენიმე დღე გავატაროთ მსგავსებებისა და განსხვავებების განხილვაზე?

2016 წლის იანვარში Helm და Deployment Manager გუნდები შეხვდნენ სიეტლში იდეების გაცვლის მიზნით. მოლაპარაკებები დასრულდა ამბიციური გეგმით: ორივე პროექტის გაერთიანება Helm 2-ის შესაქმნელად. Deis-თან და Google-თან ერთად, ბიჭები SkippBox (ახლა ბიტნამის ნაწილი - დაახლ. თარგმანი.)და დავიწყეთ Helm 2-ზე მუშაობა.

ჩვენ გვინდოდა შეგვენარჩუნებინა ჰელმის გამოყენების სიმარტივე, მაგრამ დავამატეთ შემდეგი:

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

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

2 წელს Helm 2016-ის გამოსვლის შემდეგ, Kubernetes-მა დაამატა რამდენიმე ძირითადი ინოვაცია. დამატებულია როლებზე დაფუძნებული წვდომის კონტროლი (RBAC), რომელმაც საბოლოოდ შეცვალა ატრიბუტზე დაფუძნებული წვდომის კონტროლი (ABAC). დაინერგა რესურსების ახალი ტიპები (განლაგება ჯერ კიდევ ბეტა რეჟიმში იყო იმ დროს). მორგებული რესურსების განმარტებები (თავდაპირველად ეწოდებოდა მესამე მხარის რესურსებს ან TPRs) გამოიგონეს. და რაც მთავარია, გაჩნდა საუკეთესო პრაქტიკის ნაკრები.

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

ნაზი დამშვიდობება ტილერთან

Helm 2-ის შემუშავებისას, ჩვენ წარმოვადგინეთ Tiller, როგორც Google-ის განლაგების მენეჯერთან ინტეგრაციის ნაწილი. ტილერმა მნიშვნელოვანი როლი შეასრულა საერთო კლასტერში მომუშავე გუნდებისთვის: ის საშუალებას აძლევდა სხვადასხვა სპეციალისტებს, რომლებიც მუშაობდნენ ინფრასტრუქტურით, ურთიერთქმედებოდნენ ერთსა და იმავე კომპლექტთან.

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

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

ტილერის მთავარი მიზნის მიღწევა შეიძლებოდა ტილერის გარეშე, ამიტომ ჩვენი ერთ-ერთი პირველი გადაწყვეტილება Helm 3-თან დაკავშირებით იყო ტილერის მთლიანად მიტოვება.

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

სქემების საცავი

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

მიუხედავად იმისა, რომ Charts Repository API-ს აქვს გარკვეული უპირატესობები, რომლებიც აკმაყოფილებს შენახვის ძირითად მოთხოვნებს, ასევე არსებობს რამდენიმე უარყოფითი მხარე:

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

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

მაგრამ იცით თუ არა, რომ Distribution Project შექმნილია ნებისმიერი ფორმის შინაარსის გასავრცელებლად და არა მხოლოდ კონტეინერის სურათების?

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

ხელმისაწვდომია Helm დიაგრამის საცავებში მომავალი ცვლილებების უფრო დეტალური აღწერა по ссылке.

გამოშვების მენეჯმენტი

Helm 3-ში აპლიკაციის მდგომარეობა თვალყურს ადევნებს კლასტერში წყვილი ობიექტის მიერ:

• გამოშვების ობიექტი - წარმოადგენს განაცხადის ინსტანციას;
• გამოშვების ვერსიის საიდუმლო - წარმოადგენს აპლიკაციის სასურველ მდგომარეობას დროის კონკრეტულ მომენტში (მაგალითად, ახალი ვერსიის გამოშვება).

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

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

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

Helm 2-ში გადასინჯვები უკიდურესად თანმიმდევრული იყო. დარეკეთ helm install შეიქმნა v1, შემდგომი განახლება (განახლება) - v2 და ა.შ. გამოშვებისა და გამოშვების ვერსიის საიდუმლო იშლება ერთ ობიექტად, რომელიც ცნობილია როგორც რევიზია. რევიზიები ინახებოდა იმავე სახელთა სივრცეში, როგორც Tiller, რაც ნიშნავდა, რომ თითოეული გამოცემა იყო „გლობალური“ სახელთა სივრცის თვალსაზრისით; შედეგად, სახელის მხოლოდ ერთი ინსტანციის გამოყენება შეიძლებოდა.

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

Tiller-ის მიტოვების შემდეგ, Helm 3 ინახავს მონაცემებს იმავე სახელების სივრცეში, როგორც გამოცემა. ეს ცვლილება საშუალებას გაძლევთ დააინსტალიროთ დიაგრამა იგივე გამოშვების სახელით სხვა სახელთა სივრცეში და მონაცემები შეინახება კლასტერის განახლებებს/გადატვირთვებს შორის და ა.შ. მაგალითად, შეგიძლიათ დააინსტალიროთ WordPress "foo" სახელთა სივრცეში და შემდეგ "bar" სახელთა სივრცეში და ორივე გამოშვებას შეიძლება დაერქვას "wordpress".

ცვლილებები დიაგრამაზე დამოკიდებულებებში

დიაგრამები შეფუთულია (გამოყენებით helm package) Helm 2-თან გამოსაყენებლად შეიძლება დაინსტალირდეს Helm 3-თან ერთად, თუმცა დიაგრამის განვითარების სამუშაო პროცესი მთლიანად გადაიხედა, ამიტომ გარკვეული ცვლილებები უნდა განხორციელდეს ჩარტების შემუშავების გასაგრძელებლად Helm 3-ით. კერძოდ, შეიცვალა დიაგრამის დამოკიდებულების მართვის სისტემა.

დიაგრამის დამოკიდებულების მართვის სისტემა გადავიდა requirements.yaml и requirements.lock on Chart.yaml и Chart.lock. ეს ნიშნავს, რომ სქემები, რომლებიც იყენებდნენ ბრძანებას helm dependency, საჭიროა გარკვეული კონფიგურაცია Helm 3-ში მუშაობისთვის.

მოდით შევხედოთ მაგალითს. მოდით დავამატოთ დამოკიდებულება დიაგრამაზე Helm 2-ში და ვნახოთ, რა იცვლება Helm 3-ზე გადასვლისას.

Helm 2-ში requirements.yaml ასე გამოიყურებოდა:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Helm 3-ში იგივე დამოკიდებულება აისახება თქვენსში Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

დიაგრამები კვლავ გადმოწერილია და განთავსებულია დირექტორიაში charts/, ასე რომ, ქვესქემები (ქვესქემები), დევს კატალოგში charts/, განაგრძობს მუშაობას ცვლილებების გარეშე.

ბიბლიოთეკის სქემების გაცნობა

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

განყოფილებაში გამოცხადებულია ბიბლიოთეკის სქემები dependencies ფაილში Chart.yaml. მათი ინსტალაცია და მართვა არ განსხვავდება სხვა სქემებისგან.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

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

რა არის შემდეგი?

Helm 3.0.0-alpha.1 არის საფუძველი, რომელზედაც ჩვენ ვიწყებთ Helm-ის ახალი ვერსიის აგებას. სტატიაში მე აღვწერე Helm 3-ის რამდენიმე საინტერესო თვისება. ბევრი მათგანი ჯერ კიდევ განვითარების ადრეულ ეტაპზეა და ეს ნორმალურია; ალფა გამოშვების მიზანია იდეის ტესტირება, ადრეული მომხმარებლებისგან გამოხმაურების შეგროვება და ჩვენი ვარაუდების დადასტურება.

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

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

თუ ფიქრობთ, რომ რაღაც გამოგვრჩა, სიამოვნებით მოვისმენთ თქვენს აზრებს!

შეუერთდით ჩვენს დისკუსიას მოდუნებული არხები:

• #helm-users კითხვებისთვის და საზოგადოებასთან მარტივი კომუნიკაციისთვის;
• #helm-dev განიხილოს pull მოთხოვნები, კოდი და შეცდომები.

თქვენ ასევე შეგიძლიათ ესაუბროთ ჩვენს ყოველკვირეულ საჯარო დეველოპერის ზარებს ხუთშაბათს, 19:30 MSK. შეხვედრები ეძღვნება იმ საკითხების განხილვას, რომლებზეც მუშაობენ ძირითადი დეველოპერები და საზოგადოება, ასევე კვირის განხილვის თემები. შეხვედრაში მონაწილეობა და მონაწილეობა ნებისმიერ მსურველს შეუძლია. ბმული ხელმისაწვდომია Slack არხზე #helm-dev.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «პაკეტის მენეჯერი Kubernetes - Helm: წარსული, აწმყო, მომავალი";
• «ფხიზელი მზერა ჰელმ 2-ზე: "ეს არის ის, რაც არის..."";
• «პრაქტიკული გაცნობა პაკეტის მენეჯერთან Kubernetes - Helm";
• «Kubernetes-ის რჩევები და ხრიკები: კლასტერში გაშვებული რესურსების გადატანა Helm 2-ის მენეჯმენტზე";
• «ივარჯიშეთ dapp-ით. ნაწილი 2. დოკერის სურათების განლაგება Kubernetes-ზე Helm-ის გამოყენებით".

წყარო: www.habr.com