Məqalədə Kubernetes-ə çatdırılan bulud yerli tətbiqləri üçün müasir CI/CD boru kəmərlərinin reallıqlarında konteyner reyestrlərində (Docker Registry və onun analoqları) yığılan təsvirlərin təmizlənməsi problemləri müzakirə olunur. Şəkillərin aktuallığının əsas meyarları və nəticədə təmizliyin avtomatlaşdırılması, yerə qənaət və komandaların ehtiyaclarını ödəməkdə çətinliklər verilir. Nəhayət, konkret Açıq Mənbə layihəsinin nümunəsindən istifadə edərək, bu çətinliklərin necə aradan qaldırılacağını sizə xəbər verəcəyik.
Giriş
Konteyner reyestrindəki şəkillərin sayı sürətlə arta bilər, daha çox saxlama yeri tutur və bununla da onun dəyərini əhəmiyyətli dərəcədə artırır. Reyestrdə tutulan yerin məqbul artımına nəzarət etmək, məhdudlaşdırmaq və ya saxlamaq üçün qəbul edilir:
- şəkillər üçün müəyyən sayda etiketlərdən istifadə edin;
- şəkilləri bir şəkildə təmizləyin.
İlk məhdudiyyət bəzən kiçik komandalar üçün məqbuldur. Tərtibatçıların kifayət qədər daimi teqləri varsa (latest, main, test, boris və s.), reyestr ölçüsündə şişməyəcək və uzun müddət onu təmizləmək barədə düşünmək məcburiyyətində olmayacaqsınız. Axı, bütün aidiyyətsiz şəkillər silinir və təmizlik üçün sadəcə heç bir iş qalmır (hər şeyi adi bir zibil yığan edir).
Bununla belə, bu yanaşma inkişafı xeyli məhdudlaşdırır və müasir CI/CD layihələrinə nadir hallarda tətbiq olunur. inkişafının tərkib hissəsi idi avtomatlaşdırma, bu, istifadəçilərə yeni funksionallığı daha sürətli sınaqdan keçirməyə, yerləşdirməyə və çatdırmağa imkan verir. Məsələn, bütün layihələrimizdə hər bir öhdəlik ilə avtomatik olaraq CI boru kəməri yaradılır. Orada görüntü yığılır, sınaqdan keçirilir, sazlama və qalan yoxlamalar üçün müxtəlif Kubernetes sxemlərinə yayılır və hər şey qaydasındadırsa, dəyişikliklər son istifadəçiyə çatır. Və bu, artıq raket elmi deyil, çoxları üçün gündəlik bir hadisədir - çox güman ki, bu məqaləni oxuduğunuz üçün sizin üçündür.
Səhvlərin düzəldilməsi və yeni funksionallığın inkişafı paralel olaraq həyata keçirildiyindən və buraxılışlar gündə bir neçə dəfə həyata keçirilə bildiyindən, inkişaf prosesinin əhəmiyyətli sayda öhdəliklərlə müşayiət olunduğu göz qabağındadır. reyestrdə çoxlu sayda şəkillər. Nəticədə, reyestrin effektiv təmizlənməsinin təşkili məsələsi yaranır, yəni. əlaqəsiz şəkilləri silmək.
Ancaq bir görüntünün uyğun olub olmadığını necə müəyyənləşdirmək olar?
Şəklin uyğunluğu meyarları
Əksər hallarda əsas meyarlar aşağıdakılardır:
1. Birincisi (hər şeydən ən bariz və ən tənqidi) obrazlardır ki hazırda Kubernetes-də istifadə olunur. Bu şəkillərin silinməsi əhəmiyyətli istehsal fasiləsi xərcləri ilə nəticələnə bilər (məsələn, şəkillərin təkrarlanması üçün tələb oluna bilər) və ya hər hansı bir döngədə sazlama qrupunun səylərini rədd edə bilər. (Bu səbəbdən hətta xüsusi bir şey etdik , hər hansı Kubernetes klasterində belə təsvirlərin olmamasını izləyir.)
2. İkinci (daha az aşkar, həm də çox vacib və yenidən istismara aiddir) - görüntülər ki ciddi problemlərin aşkarlanması halında geri çəkilmə üçün tələb olunur cari versiyada. Məsələn, Helm vəziyyətində bunlar buraxılışın saxlanmış versiyalarında istifadə olunan şəkillərdir. (Yeri gəlmişkən, Helm-də standart olaraq limit 256 düzəlişdir, lakin çətin ki, kimsə həqiqətən qənaət etməlidir. belə bir çoxlu sayda versiyalar?..) Axı biz, xüsusən, versiyaları saxlayırıq ki, sonradan istifadə edə bilək, yəni. zəruri hallarda onlara "geri döndərin".
3. Üçüncü - developer ehtiyacları: Cari işləri ilə əlaqəli bütün şəkillər. Məsələn, əgər biz PR-ı nəzərdən keçiririksə, o zaman son öhdəliyə və deyək ki, əvvəlki öhdəliyə uyğun bir şəkil buraxmağın mənası var: bu yolla tərtibatçı istənilən tapşırığa tez qayıda və ən son dəyişikliklərlə işləyə bilər.
4. Dördüncüsü - şəkillər tətbiqimizin versiyalarına uyğundur, yəni. son məhsuldur: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra və s.
Qeyd: Burada müəyyən edilmiş meyarlar müxtəlif şirkətlərin onlarla inkişaf komandası ilə qarşılıqlı əlaqədə olan təcrübə əsasında tərtib edilmişdir. Bununla belə, əlbəttə ki, inkişaf proseslərindəki xüsusiyyətlərdən və istifadə olunan infrastrukturdan (məsələn, Kubernetes istifadə edilmir) bu meyarlar fərqli ola bilər.
Uyğunluq və mövcud həllər
Konteyner reyestrləri olan populyar xidmətlər, bir qayda olaraq, öz təsvirin təmizlənməsi siyasətlərini təklif edir: onlarda etiketin reyestrdən çıxarılması şərtlərini təyin edə bilərsiniz. Bununla belə, bu şərtlər adlar, yaratma vaxtı və teqlərin sayı* kimi parametrlərlə məhdudlaşır.
* Xüsusi konteyner reyestrinin tətbiqindən asılıdır. Aşağıdakı həllərin imkanlarını nəzərdən keçirdik: Azure CR, Docker Hub, ECR, GCR, GitHub Paketləri, GitLab Konteyner Registri, Harbour Registry, JFrog Artifactory, Quay.io - 2020-ci ilin sentyabrından.
Bu parametrlər dəsti dördüncü meyara cavab vermək üçün kifayətdir - yəni versiyalara uyğun olan şəkilləri seçmək üçün. Bununla belə, bütün digər meyarlar üçün gözləntilərdən və maliyyə imkanlarından asılı olaraq hansısa kompromis həll yolu (daha sərt və ya əksinə, daha yumşaq siyasət) seçmək lazımdır.
Məsələn, üçüncü meyar - tərtibatçıların ehtiyacları ilə əlaqəli - komandalar daxilində proseslərin təşkili ilə həll edilə bilər: şəkillərin xüsusi adlandırılması, xüsusi icazə siyahılarının və daxili razılaşmaların saxlanması. Ancaq sonda hələ də avtomatlaşdırılmalıdır. Və hazır həllərin imkanları kifayət deyilsə, özünüzdən bir şey etməlisiniz.
İlk iki meyarla bağlı vəziyyət oxşardır: xarici sistemdən məlumat almadan onları qane etmək olmaz - tətbiqlərin yerləşdirildiyi sistem (bizim vəziyyətimizdə Kubernetes).
Git-də iş axınının təsviri
Deyək ki, Git-də belə bir şey işləyirsiniz:
Diaqramda başlığı olan ikona hazırda Kubernetes-də istənilən istifadəçilər (son istifadəçilər, testçilər, menecerlər və s.) üçün yerləşdirilən və ya tərtibatçılar tərəfindən sazlama və oxşar məqsədlər üçün istifadə edilən konteyner şəkillərini göstərir.
Təmizləmə siyasətləri yalnız şəkillərin saxlanmasına icazə verirsə (silinmirsə) nə baş verir verilən etiket adları ilə?
Aydındır ki, belə bir ssenari heç kimi sevindirməyəcək.
Siyasətlər şəkillərin silinməməsinə icazə verərsə, nə dəyişəcək? verilmiş vaxt intervalına / son öhdəliyin sayına görə?
Nəticə daha yaxşı oldu, lakin hələ də idealdan uzaqdır. Axı, hələ də səhvləri aradan qaldırmaq üçün reyestrdə (və ya hətta K8-lərdə yerləşdirilən) şəkillərə ehtiyacı olan tərtibatçılarımız var...
Mövcud bazar vəziyyətini ümumiləşdirmək üçün: konteyner reyestrlərində mövcud olan funksiyalar təmizlik zamanı kifayət qədər çeviklik təklif etmir və bunun əsas səbəbi xarici dünya ilə əlaqə qurmağın heç bir yolu yoxdur. Belə bir çeviklik tələb edən komandaların Docker Registry API-dən (və ya müvafiq tətbiqetmənin yerli API-dən) istifadə edərək, müstəqil şəkildə "xaricidən" şəkillərin silinməsini həyata keçirməyə məcbur olduqları ortaya çıxdı.
Bununla belə, biz müxtəlif registrlərdən istifadə edən müxtəlif komandalar üçün təsvirin təmizlənməsini avtomatlaşdıracaq universal həll axtarırdıq...
Universal görüntünün təmizlənməsinə aparan yolumuz
Bu ehtiyac haradan qaynaqlanır? Məsələ burasındadır ki, biz ayrı-ayrı tərtibatçılar qrupu deyilik, eyni zamanda onların bir çoxuna xidmət edən, CI/CD məsələlərini hərtərəfli həll etməyə kömək edən komandayıq. Bunun üçün əsas texniki vasitə Open Source yardım proqramıdır . Onun özəlliyi ondan ibarətdir ki, o, tək bir funksiyanı yerinə yetirmir, lakin bütün mərhələlərdə fasiləsiz çatdırılma proseslərini müşayiət edir: montajdan tutmuş yerləşdirməyə qədər.
Şəkillərin reyestrdə dərc edilməsi* (onlar qurulduqdan dərhal sonra) belə bir yardım proqramının açıq funksiyasıdır. Şəkillər orada saxlanmaq üçün yerləşdirildiyi üçün - saxlama yeriniz məhdudiyyətsiz deyilsə - onların sonrakı təmizlənməsinə cavabdeh olmalısınız. Müəyyən edilmiş bütün meyarlara cavab verərək bu uğuru necə əldə etdiyimizi daha sonra müzakirə edəcəyik.
* Reyestrlərin özləri fərqli ola bilsələr də (Docker Registry, GitLab Container Registry, Harbor və s.), onların istifadəçiləri eyni problemlərlə üzləşirlər. Bizim vəziyyətimizdə universal həll reyestrin həyata keçirilməsindən asılı deyil, çünki reyestrlərdən kənarda işləyir və hər kəs üçün eyni davranışı təklif edir.
Nümunə olaraq werf-dən istifadə etsək də, istifadə olunan yanaşmaların oxşar çətinliklərlə üzləşən digər komandalar üçün faydalı olacağına ümid edirik.
Beləliklə, məşğul olduq xarici şəkillərin təmizlənməsi mexanizminin tətbiqi - artıq konteynerlər üçün reyestrlərə daxil edilmiş imkanların əvəzinə. İlk addım teqlərin sayı və onların yaradılma vaxtı (yuxarıda qeyd olunub) üçün eyni primitiv siyasətləri yaratmaq üçün Docker Registry API-dən istifadə etmək idi. Onlara əlavə edildi yerləşdirilmiş infrastrukturda istifadə edilən şəkillərə əsaslanan siyahıya icazə verin, yəni. Kubernetes. Sonuncu üçün, bütün yerləşdirilən resursları təkrarlamaq və dəyərlər siyahısını əldə etmək üçün Kubernetes API-dən istifadə etmək kifayət idi. image.
Bu əhəmiyyətsiz həll ən kritik problemi həll etdi (meyar №1), lakin təmizləmə mexanizmini təkmilləşdirmək üçün səyahətimizin yalnız başlanğıcı idi. Növbəti və daha maraqlı addım qərar idi dərc edilmiş şəkilləri Git tarixi ilə əlaqələndirin.
Etiketləmə sxemləri
Başlamaq üçün, son görüntünün təmizləmə üçün lazımi məlumatları saxlamalı olduğu bir yanaşma seçdik və prosesi etiketləmə sxemləri üzərində qurduq. Şəkil dərc edərkən istifadəçi xüsusi etiketləmə seçimini seçdi (git-branch, git-commit və ya git-tag) və müvafiq dəyərdən istifadə etdi. CI sistemlərində bu dəyərlər ətraf mühit dəyişənləri əsasında avtomatik olaraq təyin edilirdi. Faktiki olaraq son görüntü xüsusi Git primitivi ilə əlaqələndirildi, etiketlərdə təmizləmə üçün lazımi məlumatların saxlanması.
Bu yanaşma Git-in tək həqiqət mənbəyi kimi istifadə edilməsinə imkan verən bir sıra siyasətlərlə nəticələndi:
- Git-də filial/teq silinən zaman reyestrdəki əlaqəli şəkillər avtomatik olaraq silinirdi.
- Git teqləri və öhdəliyi ilə əlaqəli şəkillərin sayı seçilmiş sxemdə istifadə olunan teqlərin sayı və əlaqəli öhdəliyin yaradıldığı vaxtla idarə oluna bilər.
Bütövlükdə, nəticədə tətbiq tələblərimizi qane etdi, lakin tezliklə bizi yeni çağırış gözləyirdi. Fakt budur ki, Git primitivləri əsasında etiketləmə sxemlərindən istifadə edərkən bir sıra çatışmazlıqlarla qarşılaşdıq. (Onların təsviri bu məqalənin əhatə dairəsi xaricində olduğundan, hər kəs təfərrüatlarla tanış ola bilər. .) Buna görə də, etiketləmə (məzmun əsaslı etiketləmə) üçün daha səmərəli yanaşmaya keçmək qərarına gələrək, görüntünün təmizlənməsinin həyata keçirilməsinə yenidən baxmalı olduq.
Yeni alqoritm
Niyə? Məzmuna əsaslanan etiketləmə ilə hər bir teq Git-də çoxlu öhdəliyi təmin edə bilər. Şəkilləri təmizləyərkən, artıq güman edə bilməzsiniz yalnız reyestrə yeni etiketin əlavə edildiyi öhdəlikdən.
Yeni təmizləmə alqoritmi üçün etiketləmə sxemlərindən uzaqlaşmaq və qurmaq qərara alındı meta-şəkil prosesi, hər biri bir dəstə saxlayır:
- nəşrin həyata keçirildiyi öhdəlik (şəklin konteyner reyestrində əlavə edilib-edilməməsi, dəyişdirilməsi və ya eyni qalması fərqi yoxdur);
- və yığılmış təsvirə uyğun olan daxili identifikatorumuz.
Başqa sözlə, təmin edilib dərc edilmiş teqləri Git-də öhdəliklərlə əlaqələndirmək.
Yekun konfiqurasiya və ümumi alqoritm
Təmizləməni konfiqurasiya edərkən istifadəçilər indi cari şəkilləri seçən siyasətlərə giriş əldə edə bilərlər. Hər bir belə siyasət müəyyən edilir:
- çoxlu istinadlar, yəni. Skanlama zamanı istifadə olunan Git teqləri və ya Git filialları;
- və dəstdən hər bir istinad üçün axtarılan şəkillərin limiti.
Nümunə etmək üçün defolt siyasət konfiqurasiyası belə görünməyə başladı:
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
Bu konfiqurasiya aşağıdakı qaydalara uyğun gələn üç siyasətdən ibarətdir:
- Şəkli son 10 Git teq üçün yadda saxlayın (teq yaratma tarixinə görə).
- Keçən həftədə dərc edilmiş ən çox 2 şəkli son həftədə aktivliyi olan 10-dan çox olmayan mövzu üçün yadda saxlayın.
- Filiallar üçün 10 şəkil saxla
main,stagingиproduction.
Son alqoritm aşağıdakı addımlara qədər azalır:
- Konteyner reyestrindən manifestlər alınır.
- Kubernetes-də istifadə edilən şəkillər istisna olmaqla, çünki Biz artıq K8s API sorğusu ilə onları əvvəlcədən seçmişik.
- Git tarixçəsinin skan edilməsi və müəyyən edilmiş siyasətlərə əsaslanan şəkillərin xaric edilməsi.
- Qalan şəkillərin silinməsi.
İllüstrasiyamıza qayıdaraq, werf ilə belə olur:
Bununla belə, werf istifadə etməsəniz belə, qabaqcıl təsvirin təmizlənməsinə oxşar yanaşma - bu və ya digər tətbiqdə (şəkil etiketlənməsinə üstünlük verilən yanaşmaya uyğun olaraq) digər sistemlərə/utilitlərə də tətbiq oluna bilər. Bunu etmək üçün ortaya çıxan problemləri xatırlamaq və onların həllini mümkün qədər rəvan şəkildə birləşdirməyə imkan verən yığınınızdakı imkanları tapmaq kifayətdir. Ümid edirik ki, keçdiyimiz yol xüsusi işinizə yeni təfərrüatlar və düşüncələrlə baxmağınıza kömək edəcəkdir.
Nəticə
- Gec və ya tez, əksər komandalar reyestr daşması problemi ilə qarşılaşırlar.
- Həll yollarını axtararkən, ilk növbədə, təsvirin uyğunluğu meyarlarını müəyyən etmək lazımdır.
- Populyar konteyner reyestr xidmətlərinin təklif etdiyi alətlər "xarici dünyanı" nəzərə almayan çox sadə təmizləmə təşkil etməyə imkan verir: Kubernetes-də istifadə olunan şəkillər və komandanın iş axınının xüsusiyyətləri.
- Çevik və səmərəli alqoritm CI/CD proseslərini başa düşməlidir və təkcə Docker təsvir məlumatları ilə deyil.
PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com