მონორეპოს და მულტირეპოს მხარდაჭერა werf-ში და რა კავშირი აქვს მას Docker Registry-ს

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

werf-ის ბოლო მონო-რეპო მხარდაჭერა ამის კარგი მაგალითია. მაგრამ პირველ რიგში, მოდით გაერკვნენ, თუ როგორ არის ეს მხარდაჭერა ზოგადად დაკავშირებული werf-ის გამოყენებასთან და რა კავშირი აქვს მას Docker Registry ...

საკითხები

წარმოვიდგინოთ ასეთი სიტუაცია. კომპანიას ჰყავს მრავალი დეველოპერული გუნდი, რომლებიც მუშაობენ დამოუკიდებელ პროექტებზე. აპლიკაციების უმეტესობა მუშაობს Kubernetes-ზე და, შესაბამისად, კონტეინერირებულია. კონტეინერების, სურათების შესანახად გჭირდებათ რეესტრი (რეგისტრი). როგორც ასეთი რეესტრი, კომპანია იყენებს Docker Hub-ს ერთი ანგარიშით COMPANY. კოდის შენახვის სისტემების უმეტესობის მსგავსად, Docker Hub არ დაუშვებს ჩადგმული საცავის იერარქიას, როგორიცაა COMPANY/PROJECT/IMAGE. ამ შემთხვევაში… როგორ შეგიძლიათ შეინახოთ არამონოლითური აპლიკაციები რეესტრში ამ შეზღუდვით თითოეული პროექტისთვის ცალკე ანგარიშის შექმნის გარეშე?

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

გადაწყვეტილებები

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

როდესაც აპლიკაცია წარმოდგენილია რამდენიმე კომპონენტის სახით, მიკროსერვისები, მაშინ საჭიროა გარკვეული მიდგომა. ტიპიური ვებ აპლიკაციის მაგალითზე, რომელიც შედგება ორი სურათისგან: frontend и backend - შესაძლო ვარიანტებია:

1. შეინახეთ სურათები ცალკე დადგმულ საცავებში:

   

2. შეინახეთ ყველაფერი ერთ საცავში და გაითვალისწინეთ სურათის სახელი ტეგში, მაგალითად, შემდეგნაირად:

   

NB: სინამდვილეში, არსებობს სხვა ვარიანტი სხვადასხვა საცავებში შენახვით, PROJECT-frontend и PROJECT-backend, მაგრამ ჩვენ არ განვიხილავთ მას მომხმარებლების შორის უფლებების მხარდაჭერის, ორგანიზებისა და განაწილების სირთულის გამო.

werf მხარდაჭერა

თავდაპირველად, werf შემოიფარგლებოდა მხოლოდ ჩადგმული საცავებით - საბედნიეროდ, რეესტრის უმეტესობა მხარს უჭერს ამ ფუნქციას. ვერსიიდან დაწყებული v1.0.4-ალფა.3, დაამატა მუშაობა რეესტრებთან, რომელშიც ბუდე არ არის მხარდაჭერილიდა Docker Hub ერთ-ერთი მათგანია. ამ მომენტიდან მომხმარებელს აქვს არჩევანი, თუ როგორ შეინახოს აპლიკაციის სურათები.

იმპლემენტაცია ხელმისაწვდომია ვარიანტის ქვეშ --images-repo-mode=multirepo|monorepo (ნაგულისხმევი multirepo, ე.ი. შენახვა ჩადგმულ საცავებში). ის განსაზღვრავს შაბლონებს, რომლითაც სურათები ინახება რეესტრში. საბაზისო ბრძანებების გამოყენებისას საკმარისია სასურველი რეჟიმის არჩევა და დანარჩენი ყველაფერი უცვლელი დარჩება.

იმის გამო, რომ werf ვარიანტების უმეტესობის დაყენება შესაძლებელია გარემოს ცვლადებიCI/CD სისტემებში შენახვის რეჟიმი, როგორც წესი, მარტივია გლობალურად დაყენებული მთელი პროექტისთვის. Მაგალითად, GitLab-ის შემთხვევაში უბრალოდ დაამატეთ გარემოს ცვლადი პროექტის პარამეტრებში: პარამეტრები -> CI / CD -> ცვლადები: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

ეშმაკი დეტალებშია

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

გაწმენდისას werf ითვალისწინებს Kubernetes კლასტერებში გამოყენებულ სურათებს, ასევე მომხმარებლის მიერ კონფიგურირებულ პოლიტიკას. პოლიტიკა ეფუძნება ტეგების სტრატეგიებად დაყოფას. ამჟამად მხარდაჭერილი სტრატეგიები:

1. 3 სტრატეგია, რომლებიც დაკავშირებულია Git პრიმიტივებით, როგორიცაა tag, branch და commit;
2. 1 სტრატეგია თვითნებური მორგებული ტეგებისთვის.

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

როდესაც ინახება ერთ საცავში (monorepo), სურათის ტეგში, მეტა ტეგის გარდა, სურათის სახელიც შეიძლება შეინახოს: PROJECT:frontend-META-TAG. მათ გამოსაყოფად, ჩვენ არ შემოვიღეთ რაიმე კონკრეტული გამყოფი, უბრალოდ, გამოქვეყნებისას დავამატეთ საჭირო მნიშვნელობა საბოლოო სურათის ეტიკეტს.

NB: თუ თქვენ გაინტერესებთ დაათვალიეროთ ყველაფერი, რაც აღწერილია werf-ის საწყის კოდში, მაშინ საწყისი წერტილი შეიძლება იყოს PR 1684.

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

Შეჯამება

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

დარჩით ჩვენთან და ძალიან მალე მოგიყვებით სხვა სიახლეებზე ვერფ!

PS

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

• «ახლა თქვენ შეგიძლიათ შექმნათ Docker სურათები werf-ში ჩვეულებრივი Dockerfile-ის გამოყენებით";
• «werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)".

წყარო: www.habr.com