🥇Կոնտեյների պատկերների «խելացի» մաքրման խնդիրը և դրա լուծումը werf

Հոդվածում քննարկվում են պատկերների մաքրման խնդիրները, որոնք կուտակվում են կոնտեյներային ռեգիստրներում (Docker Registry և դրա անալոգները) ժամանակակից CI/CD խողովակաշարերի իրականության մեջ՝ ամպային բնիկ հավելվածների համար, որոնք առաքվում են Kubernetes-ին: Ներկայացված են պատկերների համապատասխանության հիմնական չափանիշները և դրանց արդյունքում առաջացած դժվարությունները մաքրման ավտոմատացման, տարածքի խնայողության և թիմերի կարիքների բավարարման հարցում: Վերջապես, օգտագործելով կոնկրետ բաց կոդով նախագծի օրինակը, մենք ձեզ կասենք, թե ինչպես կարելի է հաղթահարել այս դժվարությունները:

Ներածություն

Կոնտեյներների գրանցամատյանում պատկերների թիվը կարող է արագ աճել՝ ավելի շատ պահեստային տարածք գրավելով և այդպիսով զգալիորեն մեծացնելով դրա արժեքը: Ռեեստրում զբաղեցրած տարածքի ընդունելի աճը վերահսկելու, սահմանափակելու կամ պահպանելու համար ընդունվում է.

օգտագործել պատկերների համար ֆիքսված թվով պիտակներ;
ինչ-որ կերպ մաքրել պատկերները:

Առաջին սահմանափակումը երբեմն ընդունելի է փոքր թիմերի համար: Եթե մշակողները ունեն բավականաչափ մշտական պիտակներ (latest, main, test, boris և այլն), ռեեստրը չափերով չի ուռչի և երկար ժամանակ ընդհանրապես ստիպված չեք լինի մտածել այն մաքրելու մասին: Չէ՞ որ բոլոր անկապ պատկերները ջնջվում են, իսկ մաքրման գործ ուղղակի չի մնում (ամեն ինչ անում է սովորական աղբահանը)։

Այնուամենայնիվ, այս մոտեցումը մեծապես սահմանափակում է զարգացումը և հազվադեպ է կիրառելի ժամանակակից CI/CD նախագծերի համար: Զարգացման անբաժանելի մասն էր ավտոմատացում, որը թույլ է տալիս շատ ավելի արագ փորձարկել, տեղակայել և նոր գործառույթներ մատուցել օգտատերերին: Օրինակ, մեր բոլոր նախագծերում CI խողովակաշարը ավտոմատ կերպով ստեղծվում է յուրաքանչյուր կատարման հետ: Դրանում պատկերը հավաքվում է, փորձարկվում, տարածվում է Kubernetes-ի տարբեր սխեմաների վրա՝ վրիպազերծման և մնացած ստուգումների համար, և եթե ամեն ինչ լավ է, փոփոխությունները հասնում են վերջնական օգտագործողին: Եվ սա այլևս հրթիռային գիտություն չէ, այլ շատերի համար ամենօրյա երևույթ, ամենայն հավանականությամբ ձեզ համար, քանի որ կարդում եք այս հոդվածը:

Քանի որ սխալների շտկումը և նոր ֆունկցիոնալության մշակումը կատարվում են զուգահեռ, իսկ թողարկումները կարող են իրականացվել օրական մի քանի անգամ, ակնհայտ է, որ մշակման գործընթացն ուղեկցվում է զգալի թվով պարտավորություններով, ինչը նշանակում է. մեծ թվով պատկերներ ռեեստրում. Արդյունքում առաջանում է ռեգիստրի արդյունավետ մաքրման կազմակերպման հարցը, այսինքն. անհամապատասխան պատկերների հեռացում:

Բայց ինչպե՞ս կարելի է նույնիսկ որոշել, թե արդյոք պատկերը տեղին է:

Պատկերի համապատասխանության չափանիշներ

Դեպքերի ճնշող մեծամասնությունում հիմնական չափանիշները կլինեն.

1. Առաջինը (բոլորից ամենաակնհայտն ու ամենաքննադատականը) այն պատկերներն են, որոնք ներկայումս օգտագործվում է Kubernetes-ում. Այս պատկերների հեռացումը կարող է հանգեցնել արտադրության ժամանակի զգալի ծախսերի (օրինակ, պատկերները կարող են պահանջվել կրկնօրինակման համար) կամ ժխտել խմբի ջանքերը, որոնք վրիպազերծում են օղակներից որևէ մեկում: (Այս պատճառով մենք նույնիսկ հատուկ պատրաստեցինք Պրոմեթևսի արտահանող, որը հետևում է Kubernetes-ի ցանկացած կլաստերում նման պատկերների բացակայությանը։)

2. Երկրորդ (պակաս ակնհայտ, բայց նաև շատ կարևոր և կրկին վերաբերում է շահագործմանը) - պատկերներ, որոնք լուրջ խնդիրների հայտնաբերման դեպքում անհրաժեշտ է հետ վերադարձի համար ընթացիկ տարբերակում։ Օրինակ, Helm-ի դեպքում սրանք պատկերներ են, որոնք օգտագործվում են թողարկման պահպանված տարբերակներում: (Ի դեպ, Helm-ում լռելյայն սահմանաչափը 256 վերանայում է, բայց քիչ հավանական է, որ ինչ-որ մեկին իսկապես պետք է խնայել այդպիսին մեծ թվով տարբերակներ?..) Չէ՞ որ մենք, մասնավորապես, պահում ենք տարբերակները, որ հետո կարողանանք օգտագործել, այսինքն. Անհրաժեշտության դեպքում «վերադարձեք» նրանց:

3. Երրորդ - մշակողի կարիքներըԲոլոր պատկերները, որոնք կապված են իրենց ընթացիկ աշխատանքի հետ: Օրինակ, եթե մենք դիտարկում ենք PR-ը, ապա իմաստ ունի թողնել վերջին commit-ին և, ասենք, նախորդ commit-ին համապատասխան պատկեր. այս կերպ ծրագրավորողը կարող է արագ վերադառնալ ցանկացած առաջադրանքի և աշխատել վերջին փոփոխություններով:

4. Չորրորդ - պատկերներ, որոնք համապատասխանում են մեր հավելվածի տարբերակներին, այսինքն. վերջնական արտադրանքն են՝ v1.0.0, 20.04.01/XNUMX/XNUMX, sierra և այլն:

NB: Այստեղ սահմանված չափանիշները ձևակերպվել են տարբեր ընկերությունների տասնյակ մշակողների թիմերի հետ շփվելու փորձի հիման վրա: Այնուամենայնիվ, իհարկե, կախված զարգացման գործընթացների առանձնահատկություններից և օգտագործվող ենթակառուցվածքից (օրինակ, Kubernetes-ը չի օգտագործվում), այս չափանիշները կարող են տարբերվել:

Համապատասխանությունը և առկա լուծումները

Կոնտեյներային ռեգիստրներով հայտնի ծառայությունները, որպես կանոն, առաջարկում են պատկերի մաքրման իրենց քաղաքականությունը. դրանցում կարող եք սահմանել այն պայմանները, որոնց դեպքում պիտակը հանվում է ռեեստրից: Այնուամենայնիվ, այս պայմանները սահմանափակված են այնպիսի պարամետրերով, ինչպիսիք են անունները, ստեղծման ժամանակը և պիտակների քանակը*:

* Կախված է կոնտեյների ռեեստրի կոնկրետ իրականացումներից: Մենք դիտարկել ենք հետևյալ լուծումների հնարավորությունները՝ Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - սեպտեմբերի 2020-ի դրությամբ:

Պարամետրերի այս փաթեթը բավական է չորրորդ չափանիշը բավարարելու համար՝ այն է՝ ընտրել տարբերակներին համապատասխանող պատկերներ։ Այնուամենայնիվ, մնացած բոլոր չափանիշների համար պետք է ընտրել ինչ-որ փոխզիջումային լուծում (ավելի կոշտ կամ, հակառակը, ավելի մեղմ քաղաքականություն)՝ կախված ակնկալիքներից և ֆինանսական հնարավորություններից։

Օրինակ, երրորդ չափանիշը, որը կապված է մշակողների կարիքների հետ, կարող է լուծվել թիմերի ներսում գործընթացներ կազմակերպելու միջոցով. պատկերների հատուկ անվանումներ, հատուկ թույլտվությունների ցուցակների պահպանում և ներքին համաձայնագրեր: Բայց, ի վերջո, այն դեռ պետք է ավտոմատացված լինի: Իսկ եթե պատրաստի լուծումների հնարավորությունները չեն բավարարում, ապա պետք է սեփական գործով զբաղվել։

Առաջին երկու չափանիշների հետ կապված իրավիճակը նման է. դրանք չեն կարող բավարարվել առանց արտաքին համակարգից տվյալների ստանալու՝ այն, որտեղ տեղադրվում են հավելվածները (մեր դեպքում՝ Kubernetes):

Աշխատանքային հոսքի նկարազարդում Git-ում

Ենթադրենք, դուք աշխատում եք նման բան Git-ում.

Դիագրամում գլխով պատկերակը ցույց է տալիս կոնտեյների պատկերներ, որոնք ներկայումս տեղակայված են Kubernetes-ում ցանկացած օգտատերերի համար (վերջնական օգտվողներ, փորձարկողներ, կառավարիչներ և այլն) կամ օգտագործվում են մշակողների կողմից վրիպազերծման և նմանատիպ նպատակներով:

Ի՞նչ կլինի, եթե մաքրման կանոնները թույլ են տալիս պահպանել միայն պատկերները (չջնջվել) տրված պիտակների անուններով?

Ակնհայտ է, որ նման սցենարը ոչ մեկին չի ուրախացնի։

Ի՞նչ կփոխվի, եթե կանոնները թույլ տան պատկերները չջնջել: ըստ տրված ժամանակային միջակայքի / վերջին պարտավորությունների քանակի?

Արդյունքը շատ ավելի լավ է դարձել, բայց դեռ հեռու է իդեալական լինելուց: Ի վերջո, մենք դեռ ունենք ծրագրավորողներ, ովքեր կարիք ունեն պատկերների ռեեստրում (կամ նույնիսկ տեղակայված K8-ում) սխալները վերացնելու համար...

Շուկայի ներկայիս իրավիճակը ամփոփելու համար. կոնտեյներային ռեգիստրներում առկա գործառույթները բավարար ճկունություն չեն տալիս մաքրման ժամանակ, և դրա հիմնական պատճառը. արտաքին աշխարհի հետ շփվելու ոչ մի ձև. Պարզվում է, որ նման ճկունություն պահանջող թիմերը ստիպված են ինքնուրույն իրականացնել պատկերի ջնջում «դրսից»՝ օգտագործելով Docker Registry API-ն (կամ համապատասխան իրականացման բնիկ API):

Այնուամենայնիվ, մենք փնտրում էինք ունիվերսալ լուծում, որը կավտոմատացներ պատկերների մաքրումը տարբեր թիմերի համար՝ օգտագործելով տարբեր ռեգիստրներ...

Պատկերի համընդհանուր մաքրման մեր ուղին

Որտեղի՞ց է գալիս այս անհրաժեշտությունը: Փաստն այն է, որ մենք մշակողների առանձին խումբ չենք, այլ թիմ, որը սպասարկում է նրանցից շատերին միանգամից՝ օգնելով համակողմանիորեն լուծել CI/CD խնդիրները։ Եվ դրա համար հիմնական տեխնիկական գործիքը Open Source կոմունալն է վերֆ. Դրա առանձնահատկությունն այն է, որ այն չի կատարում մեկ գործառույթ, այլ ուղեկցում է շարունակական առաքման գործընթացները բոլոր փուլերում՝ հավաքումից մինչև տեղակայում:

Պատկերների հրապարակումը գրանցամատյանում* (դրանք կառուցվելուց անմիջապես հետո) նման օգտակար ծառայության ակնհայտ գործառույթն է: Եվ քանի որ պատկերները տեղադրվում են այնտեղ պահեստավորման համար, ապա, եթե ձեր պահեստը անսահմանափակ չէ, դուք պետք է պատասխանատու լինեք դրանց հետագա մաքրման համար: Թե ինչպես մենք դրանում հաջողության հասանք՝ բավարարելով բոլոր նշված չափանիշները, կքննարկվի հետագա:

* Թեև ռեգիստրներն իրենք կարող են տարբեր լինել (Docker Registry, GitLab Container Registry, Harbor և այլն), դրանց օգտատերերը բախվում են նույն խնդիրների հետ: Համընդհանուր լուծումը մեր դեպքում կախված չէ ռեեստրի իրականացումից, քանի որ աշխատում է ռեգիստրներից դուրս և առաջարկում է նույն վարքագիծը բոլորի համար:

Թեև մենք օգտագործում ենք werf-ը որպես իրականացման օրինակ, մենք հուսով ենք, որ օգտագործված մոտեցումները օգտակար կլինեն նմանատիպ դժվարությունների բախված այլ թիմերի համար:

Այսպիսով, մենք զբաղված էինք արտաքին պատկերների մաքրման մեխանիզմի ներդրում - այն հնարավորությունների փոխարեն, որոնք արդեն ներկառուցված են բեռնարկղերի ռեեստրներում: Առաջին քայլը եղել է Docker Registry API-ի օգտագործումը՝ պիտակների քանակի և դրանց ստեղծման ժամանակի համար նույն պարզունակ քաղաքականությունը ստեղծելու համար (վերևում նշված): Ավելացվել է նրանց թույլատրել ցուցակը, որը հիմնված է տեղակայված ենթակառուցվածքում օգտագործվող պատկերների վրա, այսինքն. Կուբերնետես. Վերջինիս համար բավական էր օգտագործել Kubernetes API-ն՝ բոլոր տեղակայված ռեսուրսների միջոցով կրկնելու և արժեքների ցուցակ ստանալու համար։ image.

Այս չնչին լուծումը լուծեց ամենակարևոր խնդիրը (չափանիշ թիվ 1), բայց մաքրման մեխանիզմը բարելավելու մեր ճանապարհի միայն սկիզբն էր: Հաջորդ և շատ ավելի հետաքրքիր քայլը որոշումն էր հրապարակված պատկերները կապել 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

Այս կոնֆիգուրացիան պարունակում է երեք քաղաքականություն, որոնք համապատասխանում են հետևյալ կանոններին.

Պահպանեք պատկերը վերջին 10 Git թեգերի համար (ըստ պիտակի ստեղծման ամսաթվի):
Պահպանեք վերջին շաբաթվա ընթացքում հրապարակված ոչ ավելի, քան 2 պատկեր, ոչ ավելի, քան 10 թեմա՝ վերջին շաբաթվա ակտիվությամբ:
Պահպանեք 10 պատկեր մասնաճյուղերի համար main, staging и production.

Վերջնական ալգորիթմը հանգում է հետևյալ քայլերին.

Մանիֆեստների առբերում կոնտեյների գրանցամատյանից:
Բացառելով Kubernetes-ում օգտագործվող պատկերները, քանի որ Մենք արդեն նախապես ընտրել ենք դրանք՝ հարցում կատարելով K8s API-ում:
Git պատմության սկանավորում և պատկերների բացառում՝ հիմնված նշված քաղաքականության վրա:
Մնացած պատկերների հեռացում:

Վերադառնալով մեր նկարազարդմանը, ահա թե ինչ է տեղի ունենում werf-ի հետ.

Այնուամենայնիվ, նույնիսկ եթե դուք չեք օգտագործում werf-ը, պատկերի առաջադեմ մաքրման նմանատիպ մոտեցումը՝ այս կամ այն իրագործման դեպքում (ըստ պատկերների պիտակավորման նախընտրելի մոտեցման) կարող է կիրառվել այլ համակարգերի/կոմունալ ծառայությունների համար: Դա անելու համար բավական է հիշել ծագած խնդիրները և գտնել այն հնարավորությունները, որոնք թույլ են տալիս հնարավորինս սահուն կերպով ինտեգրել դրանց լուծումը: Հուսով ենք, որ մեր անցած ճանապարհը կօգնի ձեզ նոր մանրամասներով և մտքերով նայել ձեր կոնկրետ գործին:

Ամփոփում

Վաղ թե ուշ թիմերի մեծամասնությունը բախվում է ռեգիստրի արտահոսքի խնդրին:
Լուծումներ փնտրելիս նախ անհրաժեշտ է որոշել պատկերի համապատասխանության չափանիշները։
Կոնտեյներների ռեեստրի հանրահայտ ծառայությունների կողմից առաջարկվող գործիքները թույլ են տալիս կազմակերպել շատ պարզ մաքրում, որը հաշվի չի առնում «արտաքին աշխարհը»՝ Kubernetes-ում օգտագործվող պատկերները և թիմի աշխատանքային հոսքերի առանձնահատկությունները:
Ճկուն և արդյունավետ ալգորիթմը պետք է իմանա CI/CD գործընթացները և գործի ոչ միայն Docker պատկերի տվյալների հետ:

PS

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Կոնտեյների պատկերների «խելացի» մաքրման խնդիրը և դրա լուծումը werf-ում