კონტენტზე დაფუძნებული ტეგირება werf builder-ში: რატომ და როგორ მუშაობს?

ვერფ არის ჩვენი ღია კოდის GitOps CLI პროგრამა Kubernetes-ში აპლიკაციების შესაქმნელად და მიწოდებისთვის. IN გამოშვება v1.1 სურათების კოლექციონერში დაინერგა ახალი ფუნქცია: სურათების მონიშვნა შინაარსის მიხედვით ან შინაარსზე დაფუძნებული ტეგირება. აქამდე, Werf-ში თეგების ტიპიური სქემა მოიცავდა Docker სურათების მონიშვნას Git tag, Git branch ან Git commit-ით. მაგრამ ყველა ამ სქემას აქვს უარყოფითი მხარეები, რომლებიც მთლიანად მოგვარებულია ახალი მონიშვნის სტრატეგიით. დეტალები ამის შესახებ და რატომ არის ეს ასე კარგი, ასახულია.

მიკროსერვისების ნაკრების გაშვება ერთი Git საცავიდან

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

არის სიტუაციები, როდესაც სერვისები მართლაც დამოუკიდებელია და არ არის დაკავშირებული ერთ აპლიკაციასთან. ამ შემთხვევაში ისინი განთავსდებიან ცალკეულ პროექტებში და მათი გამოშვება განხორციელდება ცალკეული CI/CD პროცესებით თითოეულ პროექტში.

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

ტეგირება Git-ის ფილიალისა და Git ტეგის მიხედვით

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

როდესაც იქმნება ახალი Git ტეგი, მაგალითად, ახალი ვერსიის გამოშვებისას, Docker-ის ახალი ტეგი შეიქმნება ყველა პროექტის სურათისთვის Docker Registry-ში:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

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

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

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

ტეგირება Git commit-ით

werf-ს ასევე აქვს თეგის სტრატეგია, რომელიც ასოცირდება Git commit-ებთან.

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

თუმცა, Git commit-ის მიერ მონიშვნას იგივე უარყოფითი მხარეები აქვს, რაც Git-ის ფილიალების ან Git ტეგების მიერ მონიშვნას:

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

Git ფილიალის სახელის მონიშვნა არ ასახავს სურათის ვერსიას

არის კიდევ ერთი პრობლემა, რომელიც დაკავშირებულია Git ფილიალების მონიშვნის სტრატეგიასთან.

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

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

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

რა არის კონტენტზე დაფუძნებული ტეგირება?

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

Docker ტეგების შესაქმნელად გამოიყენება არა Git პრიმიტივები (Git ფილიალი, Git tag...), არამედ საკონტროლო ჯამი, რომელიც დაკავშირებულია:

• სურათის შინაარსი. სურათის ID ტეგი ასახავს მის შინაარსს. ახალი ვერსიის შექმნისას, ეს იდენტიფიკატორი არ შეიცვლება, თუ სურათზე ფაილები არ შეცვლილა;
• Git-ში ამ სურათის შექმნის ისტორია. სურათებს, რომლებიც დაკავშირებულია Git-ის სხვადასხვა ფილიალებთან და build-ის სხვადასხვა ისტორიასთან werf-ის საშუალებით, ექნებათ სხვადასხვა ID ტეგები.

ასეთი საიდენტიფიკაციო ტეგი არის ე.წ გამოსახულების ეტაპის ხელმოწერა.

თითოეული სურათი შედგება ეტაპების ნაკრებისგან: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch და ა.შ. თითოეულ ეტაპს აქვს იდენტიფიკატორი, რომელიც ასახავს მის შინაარსს − სასცენო ხელმოწერა (სცენის ხელმოწერა).

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

თითოეული სურათისთვის კონფიგურაციისგან werf.yaml ზოგადად, იქნება საკუთარი ხელმოწერა და, შესაბამისად, Docker tag.

სასცენო ხელმოწერა წყვეტს ყველა ამ პრობლემას:

• მდგრადია ცარიელი Git დავალებების მიმართ.
• Resistant to Git ავალდებულებს შეცვალოს ფაილები, რომლებიც არ შეესაბამება სურათს.
• არ იწვევს სურათის ამჟამინდელი ვერსიის გადახედვის პრობლემას ფილიალის ძველი Git კომითებისთვის ნაგებობების გადატვირთვისას.

ახლა ეს არის რეკომენდირებული მონიშვნის სტრატეგია და ნაგულისხმევია werf-ში ყველა CI სისტემისთვის.

როგორ ჩართოთ და გამოიყენოთ werf-ში

ბრძანებას ახლა აქვს შესაბამისი ვარიანტი werf publish: --tag-by-stages-signature=true|false

CI სისტემაში მონიშვნის სტრატეგია მითითებულია ბრძანებით werf ci-env. ადრე მისთვის პარამეტრი იყო განსაზღვრული werf ci-env --tagging-strategy=tag-or-branch. ახლა თუ დააკონკრეტე werf ci-env --tagging-strategy=stages-signature ან არ მიუთითოთ ეს ვარიანტი, werf გამოიყენებს მონიშვნის სტრატეგიას ნაგულისხმევად stages-signature. გუნდი werf ci-env ავტომატურად დააყენებს ბრძანებისთვის საჭირო დროშებს werf build-and-publish (ან werf publish), ამიტომ ამ ბრძანებებისთვის დამატებითი პარამეტრების მითითება არ არის საჭირო.

მაგალითად, ბრძანება:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...შეგიძლიათ შექმნათ შემდეგი სურათები:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

აქ 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d არის გამოსახულების ეტაპების ხელმოწერა backendხოლო f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - გამოსახულების ეტაპების ხელმოწერა frontend.

სპეციალური ფუნქციების გამოყენებისას werf_container_image и werf_container_env Helm-ის შაბლონებში არაფრის შეცვლა არ არის საჭირო: ეს ფუნქციები ავტომატურად გამოიმუშავებს სურათების სწორ სახელებს.

კონფიგურაციის მაგალითი CI სისტემაში:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

დამატებითი ინფორმაცია კონფიგურაციის შესახებ ხელმისაწვდომია დოკუმენტაციაში:

• დირექტორია → პუბლიკაცია (გამოქვეყნება);
• CI/CD-თან მუშაობა → ზოგადი ინფორმაცია → ეტაპები-ხელმოწერა;
• ინტეგრაცია GitLab CI/CD-თან → .gitlab-ci.yml.

საერთო ჯამში

• ახალი ვარიანტი werf publish --tag-by-stages-signature=true|false.
• ახალი ვარიანტის ღირებულება werf ci-env --tagging-strategy=stages-signature|tag-or-branch (თუ არ არის მითითებული, ნაგულისხმევი იქნება stages-signature).
• თუ ადრე იყენებდით თეგის ვარიანტებს Git commits-ისთვის (WERF_TAG_GIT_COMMIT ან ვარიანტი werf publish --tag-git-commit COMMIT), შემდეგ აუცილებლად გადახვიდეთ მონიშვნის სტრატეგიაზე ეტაპები-ხელმოწერა.
• უმჯობესია დაუყოვნებლივ გადართოთ ახალი პროექტები ახალი ტეგირების სქემაზე.
• werf 1.1-ზე გადატანისას მიზანშეწონილია ძველი პროექტების გადართვა ახალი ტეგირების სქემაზე, მაგრამ ძველზე ტეგ-ან ფილიალი კვლავ მხარდაჭერილია.

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

• Docker tag სახელის წინააღმდეგობა ცარიელი Git commits-ის მიმართ.
• Docker ტეგის სახელის მდგრადობა Git-ს ავალდებულებს, რომ შეცვალოს ფაილები, რომლებიც არ შეესაბამება სურათს.
• არ იწვევს სურათის ამჟამინდელი ვერსიის გადახედვის პრობლემას ძველი Git-ის დავალებების გადატვირთვისას Git ფილიალებისთვის.

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

PS

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

• «werf 1.1 გამოშვება: მშენებლის გაუმჯობესება დღეს და სამომავლო გეგმები»
• «წარმოგიდგენთ werf 1.0 stable: რა კავშირი აქვს GitOps-ს, სტატუსს და გეგმებს»
• «werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)";
• ჩანაწერების სერია ვერფში ინოვაციების შესახებ:
  • «3-მხრივი შერწყმა werf-თან: განლაგება კუბერნეტესში Helm-ით „სტეროიდებზე“";
  • «Werf-ის გამოყენება რთული Helm სქემების შესაქმნელად";
  • «მონორეპოს და მულტირეპოს მხარდაჭერა werf-ში და რა კავშირი აქვს მას Docker Registry-ს";
  • «ახლა თქვენ შეგიძლიათ შექმნათ Docker სურათები werf-ში ჩვეულებრივი Dockerfile-ის გამოყენებით".

წყარო: www.habr.com