GitOps: აწევისა და დაძაბვის მეთოდების შედარება

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

გასულ წელს, (ფაქტობრივად, ფორმალურად ეს მოხდა 2017 წლის აგვისტოში - დაახლ. თარგმანი.) Kubernetes-ში აპლიკაციების განლაგების ახალი მიდგომაა. მას ჰქვია GitOps და ის ეფუძნება ძირითად იდეას, რომ განლაგების ვერსიები თვალყურს ადევნებენ Git საცავის უსაფრთხო გარემოში.

ამ მიდგომის ძირითადი უპირატესობები შემდეგია::

1. განლაგების ვერსიები და ცვლილებების ისტორია. მთელი კლასტერის მდგომარეობა ინახება Git-ის საცავში და განლაგება განახლდება მხოლოდ კომიტების მეშვეობით. გარდა ამისა, ყველა ცვლილების თვალყურის დევნება შესაძლებელია ჩადენის ისტორიის გამოყენებით.
2. უკან დაბრუნება ნაცნობი Git ბრძანებების გამოყენებით. მარტივი git reset საშუალებას გაძლევთ გადატვირთოთ ცვლილებები განლაგებაში; წარსული მდგომარეობები ყოველთვის ხელმისაწვდომია.
3. მზა წვდომის კონტროლი. როგორც წესი, Git სისტემა შეიცავს უამრავ მგრძნობიარე მონაცემს, ამიტომ კომპანიების უმეტესობა განსაკუთრებულ ყურადღებას აქცევს მის დაცვას. შესაბამისად, ეს დაცვა ასევე ვრცელდება განლაგებით ოპერაციებზე.
4. განლაგების პოლიტიკა. Git სისტემების უმეტესობა ბუნებრივად მხარს უჭერს ფილიალების პოლიტიკებს - მაგალითად, მხოლოდ pull-ის მოთხოვნებს შეუძლია განაახლოს მასტერი, ხოლო ცვლილებები უნდა განიხილებოდეს და დაეთანხმოს გუნდის სხვა წევრს. როგორც წვდომის კონტროლის შემთხვევაში, იგივე პოლიტიკა ვრცელდება განლაგების განახლებებზე.

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

განლაგების მეთოდები

ბოლო წლებში Kubernetes-მა ჩამოაყალიბა განლაგების სხვადასხვა მეთოდი და ინსტრუმენტები:

1. დაფუძნებულია მშობლიურ Kubernetes/Customize შაბლონებზე. ეს არის Kubernetes-ზე აპლიკაციების განლაგების უმარტივესი გზა. დეველოპერი ქმნის ძირითად YAML ფაილებს და იყენებს მათ. ერთი და იგივე შაბლონების მუდმივი გადაწერისგან თავის დასაღწევად შეიქმნა Kustomize (ის კუბერნეტის შაბლონებს აქცევს მოდულებად). Შენიშვნა. თარგმნა: Kustomize ინტეგრირებულია kubectl-ში Kubernetes 1.14-ის გამოშვება.
2. Helm Charts. ჩაფხუტის დიაგრამები საშუალებას გაძლევთ შექმნათ შაბლონების ნაკრები, საწყის კონტეინერები, გვერდითი კარები და ა.შ., რომლებიც გამოიყენება აპლიკაციების განსათავსებლად უფრო მოქნილი პერსონალიზაციის ვარიანტებით, ვიდრე შაბლონზე დაფუძნებული მიდგომით. ეს მეთოდი ეფუძნება შაბლონურ YAML ფაილებს. Helm ავსებს მათ სხვადასხვა პარამეტრით და შემდეგ უგზავნის Tiller-ს, კლასტერულ კომპონენტს, რომელიც ათავსებს მათ კლასტერში და საშუალებას აძლევს განახლებებსა და უკან დაბრუნებას. მთავარია, რომ Helm არსებითად უბრალოდ ათავსებს სასურველ მნიშვნელობებს შაბლონებში და შემდეგ იყენებს მათ ისევე, როგორც ეს ხდება ტრადიციულ მიდგომაში. (დაწვრილებით იმის შესახებ, თუ როგორ მუშაობს ეს ყველაფერი და როგორ შეგიძლიათ გამოიყენოთ იგი ჩვენს საიტზე ჰელმის სტატია - დაახლ. თარგმანი.). არსებობს მზა Helm სქემების ფართო არჩევანი, რომელიც მოიცავს ამოცანების ფართო სპექტრს.
3. ალტერნატიული ინსტრუმენტები. ბევრი ალტერნატიული ინსტრუმენტია. რაც მათ საერთო აქვთ არის ის, რომ ისინი აქცევენ შაბლონის ზოგიერთ ფაილს Kubernetes-ის წასაკითხად YAML ფაილებად და შემდეგ იყენებენ მათ.

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

Მოქაჩვა მიწოლა

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

NB! GitOps–ის გამოყენების ყველა უპირატესობა იგივე რჩება ორივე მიდგომისთვის.

მიდგომაზე დაფუძნებული მიდგომა

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

დადებითი:

1. არცერთ გარე კლიენტს არ აქვს კლასტერში ცვლილებების შეტანის უფლება; ყველა განახლება ხდება შიგნიდან.
2. ზოგიერთი ინსტრუმენტი ასევე საშუალებას გაძლევთ სინქრონიზაცია მოახდინოთ Helm სქემის განახლებებისა და კლასტერთან დაკავშირების მიზნით.
3. Docker Registry-ის სკანირება შესაძლებელია ახალი ვერსიებისთვის. თუ ახალი სურათი ხელმისაწვდომია, Git საცავი და განლაგება განახლდება ახალ ვერსიაზე.
4. Pull ინსტრუმენტები შეიძლება განაწილდეს სხვადასხვა სახელების სივრცეში სხვადასხვა Git საცავებით და ნებართვებით. ამის წყალობით, მრავალბინიანი მოდელის გამოყენება შესაძლებელია. მაგალითად, გუნდმა A შეიძლება გამოიყენოს სახელთა სივრცე A, გუნდმა B შეიძლება გამოიყენოს სახელთა სივრცე B და ინფრასტრუქტურის გუნდმა გამოიყენოს გლობალური სივრცე.
5. როგორც წესი, ხელსაწყოები ძალიან მსუბუქია.
6. კომბინირებულია ისეთ ინსტრუმენტებთან, როგორიცაა ოპერატორი ბიტნამის დალუქული საიდუმლოებები, საიდუმლოების შენახვა შესაძლებელია დაშიფრული Git-ის საცავში და მოძიება კლასტერში.
7. არ არის კავშირი CD მილსადენებთან, რადგან განლაგება ხდება კლასტერში.

Cons:

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

ბიძგზე დაფუძნებული მიდგომა

Push მიდგომისას, გარე სისტემა (ძირითადად CD მილსადენები) იწყებს განლაგებას კლასტერში Git-ის საცავში ჩაბარების შემდეგ ან თუ წინა CI მილსადენი წარმატებულია. ამ მიდგომით, სისტემას აქვს წვდომა კლასტერზე.

დადებითი:

1. უსაფრთხოება განისაზღვრება Git საცავი და build pipeline.
2. Helm სქემების დაყენება უფრო ადვილია და მხარს უჭერს Helm დანამატებს.
3. საიდუმლოების მართვა უფრო ადვილია, რადგან საიდუმლოების გამოყენება შესაძლებელია მილსადენებში და ასევე შეიძლება შენახული იყოს დაშიფრული Git-ში (დამოკიდებულია მომხმარებლის პრეფერენციებზე).
4. არ არსებობს კავშირი კონკრეტულ ინსტრუმენტთან, რადგან ნებისმიერი ტიპის გამოყენება შესაძლებელია.
5. კონტეინერის ვერსიის განახლებების ინიცირება შესაძლებელია build pipeline-ით.

Cons:

1. კლასტერული წვდომის მონაცემები არის build სისტემის შიგნით.
2. განლაგების კონტეინერების განახლება ჯერ კიდევ უფრო ადვილია გაყვანის პროცესით.
3. დიდი დამოკიდებულება CD სისტემაზე, რადგან ჩვენ გვჭირდება მილსადენები შეიძლება თავდაპირველად იყოს დაწერილი Gitlab Runners-ისთვის, შემდეგ კი გუნდი გადაწყვეტს გადავიდეს Azure DevOps-ში ან Jenkins-ში... და მოუწევს დიდი რაოდენობის სამშენებლო მილსადენების მიგრაცია.

შედეგები: დააწექი თუ ამოიყვანე?

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

გარკვეული ფიქრის შემდეგ მივედი მოულოდნელ დასკვნამდე, რომ ეს ასე არ არის. თუ ვსაუბრობთ კომპონენტებზე, რომლებიც საჭიროებენ მაქსიმალურ დაცვას, ამ სიაში შედის საიდუმლო საცავი, CI/CD სისტემები და Git საცავი. მათში არსებული ინფორმაცია ძალიან დაუცველია და მაქსიმალურ დაცვას საჭიროებს. გარდა ამისა, თუ ვინმე მოხვდება თქვენს Git საცავში და შეუძლია იქ დააყენოს კოდი, მათ შეუძლიათ განათავსონ ის, რაც უნდათ (იქნება ეს მოზიდვა თუ დაძაბვა) და შეაღწიონ კლასტერის სისტემებში. ამრიგად, ყველაზე მნიშვნელოვანი კომპონენტები, რომლებიც უნდა იყოს დაცული, არის Git საცავი და CI/CD სისტემები და არა კლასტერული რწმუნებათა სიგელები. თუ თქვენ გაქვთ კარგად კონფიგურირებული პოლიტიკა და უსაფრთხოების კონტროლი ამ ტიპის სისტემებისთვის, და კლასტერული სერთიფიკატები ამოღებულია მხოლოდ მილსადენებში, როგორც საიდუმლო, pull მიდგომის დამატებითი უსაფრთხოება შეიძლება არ იყოს ისეთი ღირებული, როგორც თავდაპირველად ეგონათ.

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

ჩემი აზრით (როგორც ყოველთვის), თქვენ უნდა გამოიყენოთ ის, რაც ყველაზე შესაფერისია კონკრეტული შემთხვევისთვის ან კომბინირებული. პირადად მე ვიყენებ ორივე მიდგომას: Weave Flux-ს pull-ზე დაფუძნებული განლაგებისთვის, რომელიც ძირითადად მოიცავს ჩვენს საკუთარ სერვისებს, და Push მიდგომა Helm-თან და დანამატებთან, რაც აადვილებს Helm-ის დიაგრამების გამოყენებას კლასტერში და საშუალებას გაძლევთ შექმნათ საიდუმლოებები შეუფერხებლად. ვფიქრობ, ვერასოდეს იქნება ყველა შემთხვევისთვის შესაფერისი ერთი გამოსავალი, რადგან ყოველთვის არის ბევრი ნიუანსი და ისინი დამოკიდებულია კონკრეტულ აპლიკაციაზე. როგორც ითქვა, მე უაღრესად გირჩევ GitOps - ის ცხოვრებას ბევრად აადვილებს და აუმჯობესებს უსაფრთხოებას.

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

PS შენიშვნა თარჯიმანისგან

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

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

ჩვენ ვცადეთ ორივე მოდელი და მივედით იმავე დასკვნამდე, როგორც სტატიის ავტორი:

1. pull მოდელი ჩვენთვის შესაფერისია სისტემის კომპონენტების განახლებების ორგანიზებისთვის კლასტერების დიდ რაოდენობაზე (იხ. სტატია დანამატების ოპერატორის შესახებ).
2. Push მოდელი, რომელიც დაფუძნებულია GitLab CI-ზე, კარგად შეეფერება Helm სქემების გამოყენებით აპლიკაციების გასაშლელად. ამავდროულად, მილსადენებში განლაგების გავრცელების მონიტორინგი ხდება ხელსაწყოს გამოყენებით ვერფ. სხვათა შორის, ჩვენი ამ პროექტის კონტექსტში, ჩვენ მოვისმინეთ მუდმივი "GitOps", როდესაც განვიხილეთ DevOps ინჟინრების მწვავე პრობლემები ჩვენს სტენდზე KubeCon Europe'19-ზე.

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

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

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

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

იყენებთ GitOps-ს?

• დიახ, გაიყვანეთ მიდგომა

• დიახ, ბიძგი

• დიახ, გაიყვანეთ + ბიძგი

• დიახ, რაღაც სხვა

• არარის

მისცა ხმა 30 მომხმარებელმა. 10-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com