კონტეინერის სურათების "ჭკვიანი" გაწმენდის პრობლემა და მისი გადაწყვეტა ვერფში

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

შესავალი

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

1. გამოიყენეთ ტეგების ფიქსირებული რაოდენობა სურათებისთვის;
2. გაასუფთავეთ სურათები გარკვეული გზით.

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

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

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

მაგრამ როგორ განვსაზღვროთ არის თუ არა სურათი შესაბამისი?

გამოსახულების შესაბამისობის კრიტერიუმები

უმეტეს შემთხვევაში, ძირითადი კრიტერიუმები იქნება:

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

2. მეორე (ნაკლებად აშკარა, მაგრამ ასევე ძალიან მნიშვნელოვანი და კვლავ ეხება ექსპლუატაციას) - სურათები, რომლებიც საჭიროა უკან დაბრუნება სერიოზული პრობლემების გამოვლენის შემთხვევაში მიმდინარე ვერსიაში. მაგალითად, Helm-ის შემთხვევაში, ეს არის სურათები, რომლებიც გამოიყენება გამოშვების შენახულ ვერსიებში. (სხვათა შორის, Helm-ში ნაგულისხმევად, ლიმიტი არის 256 გადახედვა, მაგრამ ნაკლებად სავარაუდოა, რომ ვინმეს ნამდვილად სჭირდება დაზოგვა ასეთი ვერსიების დიდი რაოდენობა?..) ჩვენ, კერძოდ, ვინახავთ ვერსიებს, რათა მოგვიანებით გამოვიყენოთ, ე.ი. საჭიროების შემთხვევაში „უბრუნდეთ“ მათ.

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

4. მეოთხე – სურათები რომ შეესაბამება ჩვენი განაცხადის ვერსიებს, ე.ი. არის საბოლოო პროდუქტი: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra და ა.შ.

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

დასაშვებობა და არსებული გადაწყვეტილებები

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

* დამოკიდებულია კონტეინერის რეესტრის კონკრეტულ განხორციელებაზე. ჩვენ განვიხილეთ შემდეგი გადაწყვეტილებების შესაძლებლობები: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - 2020 წლის სექტემბრის მდგომარეობით.

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

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

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

სამუშაო პროცესის ილუსტრაცია Git-ში

ვთქვათ, თქვენ მუშაობთ მსგავს რაღაცას Git-ში:

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

რა მოხდება, თუ გასუფთავების წესები მხოლოდ სურათების შენარჩუნების საშუალებას იძლევა (არ წაიშალოს) მოცემული ტეგების სახელებით?

ცხადია, ასეთი სცენარი არავის გაახარებს.

რა შეიცვლება, თუ წესები სურათების არ წაშლის საშუალებას იძლევა? მოცემული დროის ინტერვალის/ბოლო ჩადენების რაოდენობის მიხედვით?

შედეგი ბევრად უკეთესი გახდა, მაგრამ ჯერ კიდევ შორს არის იდეალურისგან. ბოლოს და ბოლოს, ჩვენ ჯერ კიდევ გვყავს დეველოპერები, რომლებსაც სჭირდებათ სურათები რეესტრში (ან თუნდაც განლაგებული K8s-ში) შეცდომების გამართვის მიზნით...

შევაჯამოთ ამჟამინდელი ბაზრის მდგომარეობა: კონტეინერების რეესტრებში არსებული ფუნქციები არ გვთავაზობენ საკმარის მოქნილობას გაწმენდისას და ამის მთავარი მიზეზი არის გარე სამყაროსთან ურთიერთობის საშუალება არ არის. გამოდის, რომ გუნდები, რომლებიც საჭიროებენ ასეთ მოქნილობას, იძულებულნი არიან დამოუკიდებლად განახორციელონ სურათის წაშლა "გარედან", Docker Registry API-ის (ან შესაბამისი განხორციელების მშობლიური API) გამოყენებით.

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

ჩვენი გზა გამოსახულების უნივერსალური გაწმენდისაკენ

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

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

* მიუხედავად იმისა, რომ თავად რეესტრები შეიძლება იყოს განსხვავებული (Docker Registry, GitLab Container Registry, Harbor და ა.შ.), მათი მომხმარებლები იგივე პრობლემების წინაშე დგანან. უნივერსალური გადაწყვეტა ჩვენს შემთხვევაში არ არის დამოკიდებული რეესტრის განხორციელებაზე, რადგან გადის თავად რეესტრებს გარეთ და ყველას ერთსა და იმავე ქცევას სთავაზობს.

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

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

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

მარკირების სქემები

დასაწყისისთვის, ჩვენ ავირჩიეთ მიდგომა, რომელშიც საბოლოო გამოსახულება უნდა ინახებოდეს დასუფთავებისთვის საჭირო ინფორმაციას და ავაშენეთ პროცესი ტეგის სქემებზე. სურათის გამოქვეყნებისას მომხმარებელმა აირჩია მონიშვნის კონკრეტული ვარიანტი (git-branch, git-commit ან git-tag) და გამოიყენა შესაბამისი მნიშვნელობა. CI სისტემებში ეს მნიშვნელობები დაყენებულია ავტომატურად გარემოს ცვლადების საფუძველზე. Სინამდვილეში საბოლოო სურათი ასოცირებული იყო კონკრეტულ Git პრიმიტიულთან, ეტიკეტებში დასუფთავებისთვის საჭირო მონაცემების შენახვა.

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

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

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

ახალი ალგორითმი

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

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

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

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

საბოლოო კონფიგურაცია და ზოგადი ალგორითმი

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

• ბევრი მითითება, ე.ი. Git ტეგები ან Git ტოტები, რომლებიც გამოიყენება სკანირების დროს;
• და მოძებნილი სურათების ლიმიტი თითოეული მითითებისთვის ნაკრებიდან.

საილუსტრაციოდ, ასე დაიწყო პოლიტიკის ნაგულისხმევი კონფიგურაცია:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

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

1. შეინახეთ სურათი ბოლო 10 Git ტეგისთვის (ტეგის შექმნის თარიღის მიხედვით).
2. შეინახეთ ბოლო კვირაში გამოქვეყნებული არაუმეტეს 2 სურათისა არაუმეტეს 10 თემისათვის ბოლო კვირის აქტივობით.
3. შეინახეთ 10 სურათი ფილიალებისთვის main, staging и production.

საბოლოო ალგორითმი ემყარება შემდეგ ნაბიჯებს:

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

ჩვენს ილუსტრაციას რომ დავუბრუნდეთ, აი რა ხდება werf-თან:

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

დასკვნა

• ადრე თუ გვიან, გუნდების უმეტესობას აწყდება რეესტრის გადინების პრობლემა.
• გადაწყვეტილებების ძიებისას, პირველ რიგში, აუცილებელია გამოსახულების შესაბამისობის კრიტერიუმების დადგენა.
• პოპულარული კონტეინერების რეესტრის სერვისების მიერ შემოთავაზებული ხელსაწყოები საშუალებას გაძლევთ მოაწყოთ ძალიან მარტივი გაწმენდა, რომელიც არ ითვალისწინებს „გარე სამყაროს“: Kubernetes-ში გამოყენებულ სურათებს და გუნდის სამუშაო პროცესების თავისებურებებს.
• მოქნილ და ეფექტურ ალგორითმს უნდა ჰქონდეს CI/CD პროცესების გაგება და ფუნქციონირებს არა მხოლოდ Docker გამოსახულების მონაცემებით.

PS

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

• «კონტენტზე დაფუძნებული ტეგირება werf builder-ში: რატომ და როგორ მუშაობს?";
• «3-მხრივი შერწყმა werf-თან: განლაგება კუბერნეტესში Helm-ით „სტეროიდებზე“";
• «მონორეპოს და მულტირეპოს მხარდაჭერა werf-ში და რა კავშირი აქვს მას Docker Registry-ს";
• «werf 1.1 გამოშვება: მშენებლის გაუმჯობესება დღეს და სამომავლო გეგმები".

წყარო: www.habr.com