werf 1.1 გამოშვება: მშენებლის გაუმჯობესება დღეს და სამომავლო გეგმები

ვერფ არის ჩვენი ღია კოდის GitOps CLI პროგრამა Kubernetes-ში აპლიკაციების შესაქმნელად და მიწოდებისთვის. როგორც დაპირდა, ვერსიის გამოშვება v1.0 აღინიშნა werf-ში ახალი ფუნქციების დამატებისა და ტრადიციული მიდგომების გადახედვის დასაწყისი. ახლა ჩვენ მოხარული ვართ წარმოგიდგინოთ გამოშვება v1.1, რომელიც არის დიდი ნაბიჯი განვითარებისა და მომავლის საფუძველი კოლექციონერი ვერფ. ვერსია ამჟამად ხელმისაწვდომია არხი 1.1 ea.

გამოშვების საფუძველია სცენის შენახვის ახალი არქიტექტურა და ორივე კოლექციონერის მუშაობის ოპტიმიზაცია (Stapel და Dockerfile). ახალი შენახვის არქიტექტურა ხსნის განაწილებული ასამბლეების განხორციელების შესაძლებლობას მრავალი ჰოსტიდან და პარალელური ასამბლეებიდან იმავე ჰოსტზე.

სამუშაოს ოპტიმიზაცია მოიცავს არასაჭირო გამოთვლებისგან თავის დაღწევას ეტაპის ხელმოწერების გაანგარიშების ეტაპზე და ფაილების შემოწმების გაანგარიშების მექანიზმების შეცვლას უფრო ეფექტურზე. ეს ოპტიმიზაცია ამცირებს პროექტის აშენების საშუალო დროს werf-ის გამოყენებით. და idle builds, როდესაც ყველა ეტაპი არსებობს ქეშში ეტაპები-შენახვა, ახლა ნამდვილად სწრაფები არიან. უმეტეს შემთხვევაში, build-ის გადატვირთვას 1 წამზე ნაკლები დასჭირდება! ეს ასევე ეხება გუნდების მუშაობის პროცესში ეტაპების გადამოწმების პროცედურებს. werf deploy и werf run.

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

მოდით უფრო დეტალურად განვიხილოთ werf v1.1-ის ძირითადი ინოვაციები და ამავდროულად მოგიყვეთ სამომავლო გეგმების შესახებ.

რა შეიცვალა werf v1.1-ში?

ახალი ეტაპის დასახელების ფორმატი და ალგორითმი ქეშიდან ეტაპების არჩევისთვის

ახალი სასცენო სახელების თაობის წესი. ახლა ყოველი ეტაპის აშენება ქმნის უნიკალურ სასცენო სახელს, რომელიც შედგება 2 ნაწილისგან: ხელმოწერა (როგორც ეს იყო v1.0-ში) პლუს უნიკალური დროებითი იდენტიფიკატორი.

მაგალითად, სრული სცენის სურათის სახელი შეიძლება ასე გამოიყურებოდეს:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

ან საერთოდ:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Здесь:

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

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

1. ვერფი ითვლის გარკვეული ეტაპის ხელმოწერას.
2. В ეტაპები-შენახვა მოცემული ხელმოწერისთვის შეიძლება იყოს რამდენიმე ეტაპი. Werf ირჩევს ყველა ეტაპს, რომელიც შეესაბამება ხელმოწერას.
3. თუ მიმდინარე ეტაპი დაკავშირებულია Git-თან (git-არქივი, მორგებული ეტაპი Git პატჩებით: install, beforeSetup, setup; ან git-latest-patch), შემდეგ werf ირჩევს მხოლოდ იმ ეტაპებს, რომლებიც ასოცირდება commit-თან, რომელიც არის მიმდინარე commit-ის წინაპარი (რისთვისაც build ეწოდება).
4. დარჩენილი შესაფერისი ეტაპებიდან არჩეულია ერთი - ყველაზე ძველი შექმნის თარიღით.

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

→ დოკუმენტაცია.

ახალი ალგორითმი სასცენო საცავში ეტაპების შექმნისა და შენახვისთვის

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

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

ახლად აწყობილ სურათს გარანტირებული აქვს უნიკალური იდენტიფიკატორი TIMESTAMP_MILLISEC (იხილეთ ახალი ეტაპის დასახელების ფორმატი). იმ შემთხვევაში, თუ in ეტაპები-შენახვა მოიძებნება შესაფერისი სურათი, werf გადააგდებს ახლად შედგენილ სურათს და გამოიყენებს სურათს ქეშიდან.

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

→ დოკუმენტაცია.

გაუმჯობესებული Dockerfile შემქმნელის შესრულება

ამ დროისთვის, Dockerfile-დან აგებული სურათისთვის ეტაპების მილსადენი შედგება ერთი ეტაპისგან - dockerfile. ხელმოწერის გაანგარიშებისას გამოითვლება ფაილების საკონტროლო ჯამი context, რომელიც გამოყენებული იქნება აწყობის დროს. ამ გაუმჯობესებამდე, werf-მა რეკურსიულად მოიარა ყველა ფაილი და მიიღო საკონტროლო ჯამი თითოეული ფაილის კონტექსტისა და რეჟიმის შეჯამებით. v1.1-დან დაწყებული, werf-ს შეუძლია გამოიყენოს გამოთვლილი საკონტროლო ჯამები, რომლებიც ინახება Git-ის საცავში.

ალგორითმი ეფუძნება git ls-ხე. ალგორითმი ითვალისწინებს ჩანაწერებს .dockerignore და კვეთს ფაილის ხეს რეკურსიულად მხოლოდ საჭიროების შემთხვევაში. ამრიგად, ჩვენ გავურბივართ ფაილური სისტემის წაკითხვას და ალგორითმის დამოკიდებულებას ზომაზე context არ არის მნიშვნელოვანი.

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

გაუმჯობესებული შესრულება ფაილების იმპორტისას

werf v1.1 ვერსიები იყენებენ rsync სერვერს, როდესაც ფაილების იმპორტი არტეფაქტებიდან და სურათებიდან. ადრე, იმპორტი ხდებოდა ორ ეტაპად, მასპინძელი სისტემიდან დირექტორიის დამაგრების გამოყენებით.

macOS-ზე იმპორტის შესრულება აღარ შემოიფარგლება Docker-ის მოცულობით და იმპორტი სრულდება იმავე დროს, როგორც Linux-სა და Windows-ში.

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

Werf v1.1 მხარს უჭერს ე.წ. მონიშვნას სურათის შინაარსით - შინაარსზე დაფუძნებული ტეგირება. მიღებული Docker სურათების ტეგები დამოკიდებულია ამ სურათების შინაარსზე.

ბრძანების გაშვებისას werf publish --tags-by-stages-signature ან werf ci-env --tagging-strategy=stages-signature გამოქვეყნდა სურათები ე.წ სასცენო ხელმოწერა გამოსახულება. თითოეულ სურათს მონიშნულია ამ სურათის ეტაპების საკუთარი ხელმოწერა, რომელიც გამოითვლება იმავე წესების მიხედვით, როგორც თითოეული ეტაპის რეგულარული ხელმოწერა ცალკე, მაგრამ არის სურათის ზოგადი იდენტიფიკატორი.

გამოსახულების ეტაპების ხელმოწერა დამოკიდებულია:

1. ამ სურათის შინაარსი;
2. Git ცვლილებების ისტორია, რამაც გამოიწვია ეს შინაარსი.

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

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

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

მნიშვნელოვანია: დღეიდან ეტაპები-ხელმოწერა - რამდენად თეგირების ერთადერთი რეკომენდებული სტრატეგია. ის ნაგულისხმევად გამოყენებული იქნება ბრძანებაში werf ci-env (თუ ცალსახად არ მიუთითებთ მონიშვნის სხვა სქემას).

→ დოკუმენტაცია. ცალკე პუბლიკაცია ასევე დაეთმობა ამ ფუნქციას. განახლებულია (3 აპრილი): სტატია დეტალებით გამოქვეყნდა.

შესვლის დონეები

მომხმარებელს ახლა აქვს შესაძლებლობა გააკონტროლოს გამომავალი, დააყენოს ჟურნალის დონე და იმუშაოს გამართვის ინფორმაციასთან. დამატებულია პარამეტრები --log-quiet, --log-verbose, --log-debug.

ნაგულისხმევად, გამომავალი შეიცავს მინიმალურ ინფორმაციას:

სიტყვიერი გამომავალი გამოყენებისას (--log-verbose) შეგიძლიათ ნახოთ როგორ მუშაობს werf:

დეტალური გამომავალი (--log-debug), გარდა werf გამართვის ინფორმაციისა, ასევე შეიცავს გამოყენებული ბიბლიოთეკების ჟურნალებს. მაგალითად, თქვენ ხედავთ, თუ როგორ ხდება ურთიერთქმედება Docker Registry-თან და ასევე ჩაწერეთ ადგილები, სადაც იხარჯება მნიშვნელოვანი დრო:

შემდგომი გეგმები

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

სრული მხარდაჭერა Docker Registry-ის სხვადასხვა დანერგვისთვის (ახალი)

• ვერსია: v1.1
• თარიღები: მარტი
• Issue

მიზანია მომხმარებელმა გამოიყენოს მორგებული იმპლემენტაცია შეზღუდვების გარეშე werf-ის გამოყენებისას.

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

• ნაგულისხმევი (ბიბლიოთეკა/რეესტრი)*,
• AWS ECR
• ცისფერი *,
• Docker Hub
• GCR*,
• GitHub პაკეტები
• GitLab Registry*,
• Harbor *,
• კეი.

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

ორი ძირითადი პრობლემის იდენტიფიცირება შეიძლება:

• ზოგიერთი გადაწყვეტა არ უჭერს მხარს თეგის ამოღებას Docker Registry API-ის გამოყენებით, რაც მომხმარებლებს უშლის ხელს werf-ის ავტომატური გასუფთავების გამოყენებაში. ეს მართალია AWS ECR, Docker Hub და GitHub პაკეტებისთვის.
• ზოგიერთი გადაწყვეტა არ უჭერს მხარს ეგრეთ წოდებულ ჩადგმულ საცავებს (Docker Hub, GitHub Packages და Quay), მაგრამ მომხმარებელმა უნდა შექმნას ისინი ხელით UI ან API (AWS ECR) გამოყენებით.

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

განაწილებული გამოსახულების აგება (↑)

• ვერსია: v1.2 v1.1 (ამ ფუნქციის განხორციელების პრიორიტეტი გაიზარდა)
• თარიღები: მარტი-აპრილი მარტი
• Issue

ამ დროისთვის, werf v1.0 და v1.1 შეიძლება გამოყენებულ იქნას მხოლოდ ერთ სპეციალურ ჰოსტზე სურათების აშენებისა და გამოქვეყნების ოპერაციებისთვის და აპლიკაციის Kubernetes-ში განსათავსებლად.

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

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

შენიშვნა. ეს ფუნქცია არ მოითხოვს კოლექციონერს მუშაობას Kubernetes pods-ში, რადგან ამისათვის თქვენ უნდა განთავისუფლდეთ დამოკიდებულებისგან ადგილობრივ Docker სერვერზე (Kubernetes pod-ში არ არის წვდომა ადგილობრივ Docker სერვერზე, რადგან თავად პროცესი მიმდინარეობს კონტეინერში და werf არ აქვს და არ უჭერს მხარს მუშაობა Docker სერვერთან ქსელში). Kubernetes-ის გაშვების მხარდაჭერა განხორციელდება ცალკე.

GitHub Actions-ის ოფიციალური მხარდაჭერა (ახალი)

• ვერსია: v1.1
• თარიღები: მარტი
• Issue

მოყვება werf დოკუმენტაცია (სექციები მინიშნება и უხელმძღვანელებს), ასევე ოფიციალური GitHub Action werf-თან მუშაობისთვის.

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

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

აპლიკაციების ლოკალური განვითარება და განთავსება werf-ით (↓)

• ვერსია: v1.1
• თარიღები: იანვარი-თებერვალი აპრილი
• Issue

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

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

დასუფთავების ახალი ალგორითმი (ახალი)

• ვერსია: v1.1
• თარიღები: აპრილი
• Issue

მიმდინარე ვერსიაში werf v1.1 პროცედურაში cleanup არ არის გათვალისწინებული სურათების გაწმენდა კონტენტზე დაფუძნებული თეგის სქემისთვის - ეს სურათები დაგროვდება.

ასევე, werf-ის ამჟამინდელი ვერსია (v1.0 და v1.1) იყენებს სხვადასხვა გაწმენდის პოლიტიკას თეგირების სქემებით გამოქვეყნებული სურათებისთვის: Git branch, Git tag ან Git commit.

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

• შეინახეთ არაუმეტეს N1 გამოსახულებები, რომლებიც დაკავშირებულია N2-ის უახლეს ჩაბარებებთან თითოეული git HEAD-ისთვის (ტოტები და ტეგები).
• შეინახეთ არაუმეტეს N1 ეტაპის სურათები, რომლებიც დაკავშირებულია N2-ის უახლეს დასრულებებთან თითოეული git HEAD-ისთვის (ტოტები და ტეგები).
• შეინახეთ ყველა სურათი, რომელიც გამოიყენება Kubernetes-ის კლასტერულ რესურსებში (კონფიგურაციის ფაილის ყველა kube კონტექსტი და სახელთა სივრცე დასკანირებულია; შეგიძლიათ შეზღუდოთ ეს ქცევა სპეციალური ვარიანტებით).
• შეინახეთ ყველა სურათი, რომელიც გამოიყენება რესურსის კონფიგურაციის მანიფესტებში, რომლებიც შენახულია Helm-ის გამოშვებებში.
• სურათი შეიძლება წაიშალოს, თუ ის არ არის ასოცირებული git-ის რომელიმე HEAD-თან (მაგალითად, იმიტომ, რომ თავად შესაბამისი HEAD წაიშალა) და არ გამოიყენება კუბერნეტის კლასტერში და Helm-ის გამოშვებებში არცერთ მანიფესტში.

პარალელური გამოსახულების აგება (↓)

• ვერსია: v1.1
• თარიღები: იანვარი-თებერვალი აპრილი*

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

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

გადასვლა Helm 3-ზე (↓)

• ვერსია: v1.2
• თარიღები: თებერვალი-მარტი მაისი*

მოიცავს მიგრაციას ახალ კოდების ბაზაზე ჩაფხუტი 3 და არსებული დანადგარების მიგრაციის დადასტურებული, მოსახერხებელი გზა.

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

Jsonnet Kubernetes-ის კონფიგურაციის აღწერისთვის (↓)

• ვერსია: v1.2
• თარიღები: იანვარი-თებერვალი აპრილი-მაისი

Werf მხარს დაუჭერს Kubernetes-ის კონფიგურაციის აღწერილობებს Jsonnet ფორმატში. ამავდროულად, werf დარჩება Helm-თან თავსებადი და იქნება აღწერის ფორმატის არჩევანი.

მიზეზი ის არის, რომ Go შაბლონებს, ბევრი ადამიანის აზრით, მაღალი შესვლის ბარიერი აქვს და ამ შაბლონების კოდის გაგებაც ზარალდება.

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

მუშაობა Kubernetes-ში (↓)

• ვერსია: v1.2
• ვადები: აპრილი-მაისი მაისი-ივნისი

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

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

ის ასევე მოითხოვს მშენებლის ოპერაციული რეჟიმის მხარდაჭერას Docker სერვერის გარეშე (ანუ Kaniko-ს მსგავსი build ან build მომხმარებელთა სივრცეში).

Werf მხარს დაუჭერს Kubernetes-ზე მშენებლობას არა მხოლოდ Dockerfile-ით, არამედ Stapel-ის მშენებლებთან ერთად დამატებითი რეკონსტრუქციით და Ansible-ით.

ნაბიჯი ღია განვითარებისკენ

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

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

• დოკუმენტაცია და საიტი;
• ტესტირება;
• შეცდომები და ცუდი UX;
• 1.1.

ბევრი სამუშაო გაკეთდა საკითხებზე:

• ამოღებულია შეუსაბამოები.
• არსებულები მოყვანილია ერთიან ფორმატში, საკმარისი რაოდენობის დეტალებითა და დეტალებით.
• დაემატა ახალი საკითხები იდეებითა და წინადადებებით.

როგორ ჩართოთ ვერსია v1.1

ვერსია ამჟამად ხელმისაწვდომია არხი 1.1 ea (არხებში სტაბილური и კლდოვანი თუმცა, გამოშვებები გამოჩნდება სტაბილიზაციის დროს ea თავად უკვე საკმარისად სტაბილურია გამოსაყენებლად, რადგან არხებით გაიარა alpha и ბეტა). გააქტიურებულია multiwerf-ის საშუალებით შემდეგი გზით:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

დასკვნა

ახალი ეტაპის შენახვის არქიტექტურა და მშენებლების ოპტიმიზაცია Stapel და Dockerfile მშენებლებისთვის ხსნის განაწილებული და პარალელური კონსტრუქციების განხორციელების შესაძლებლობას werf-ში. ეს ფუნქციები მალე გამოჩნდება იმავე v1.1 გამოშვებაში და ავტომატურად გახდება ხელმისაწვდომი ავტომატური განახლების მექანიზმის მეშვეობით (მომხმარებლებისთვის მულტივერფი).

ამ გამოცემაში დამატებულია თეგის სტრატეგია, რომელიც დაფუძნებულია სურათის კონტენტზე - შინაარსზე დაფუძნებული ტეგირება, რომელიც გახდა ნაგულისხმევი სტრატეგია. მთავარი ბრძანების ჟურნალი ასევე გადამუშავებულია: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

შემდეგი მნიშვნელოვანი ნაბიჯი არის განაწილებული შეკრებების დამატება. განაწილებული კონსტრუქციები უფრო პრიორიტეტული გახდა, ვიდრე პარალელური კონსტრუქციები v1.0-ის შემდეგ, რადგან ისინი მეტ მნიშვნელობას ანიჭებენ werf-ს: ბილდერების ვერტიკალური მასშტაბირება და ეფემერული მშენებლების მხარდაჭერა სხვადასხვა CI/CD სისტემებში, ასევე GitHub Actions-ის ოფიციალური მხარდაჭერის შესაძლებლობა. . ამიტომ, პარალელური შეკრებების განხორციელების ვადები გადაინაცვლა. თუმცა, ჩვენ ვმუშაობთ, რომ ორივე შესაძლებლობა რაც შეიძლება მალე განვახორციელოთ.

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

PS

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

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

წყარო: www.habr.com