„Protingo“ konteinerių vaizdų valymo problema ir jos sprendimas werf

Straipsnyje aptariamos vaizdų, kaupiančių konteinerių registruose („Docker Registry“ ir jo analoguose), valymo problemos šiuolaikinių CI/CD vamzdynų, skirtų „Kubernetes“ pristatomoms debesų vietinėms programoms, realybėje. Pateikiami pagrindiniai vaizdų aktualumo kriterijai ir iš to kylantys sunkumai automatizuojant valymą, taupant erdvę ir tenkinant komandų poreikius. Galiausiai, naudodamiesi konkretaus atvirojo kodo projekto pavyzdžiu, papasakosime, kaip šiuos sunkumus galima įveikti.

įvedimas

Vaizdų skaičius konteinerio registre gali sparčiai augti, užimti daugiau vietos saugykloje ir taip žymiai padidinti jo kainą. Norint kontroliuoti, apriboti arba palaikyti priimtiną registro užimamos vietos augimą, leidžiama:

1. naudoti fiksuotą skaičių žymų vaizdams;
2. kaip nors išvalyti vaizdus.

Pirmasis apribojimas kartais yra priimtinas mažoms komandoms. Jei kūrėjai turi pakankamai nuolatinių žymų (latest, main, test, boris ir t.t.), registras nepadidės ir ilgą laiką jums nereikės galvoti apie jo valymą. Juk ištrinami visi nereikšmingi vaizdai, o valymui tiesiog nebelieka darbo (viską atlieka eilinis šiukšlių surinkėjas).

Tačiau šis metodas labai riboja plėtrą ir retai taikomas šiuolaikiniams CI / CD projektams. Neatsiejama plėtros dalis buvo automatizavimas, kuri leidžia daug greičiau išbandyti, įdiegti ir vartotojams teikti naujas funkcijas. Pavyzdžiui, visuose mūsų projektuose su kiekvienu įsipareigojimu automatiškai sukuriamas CI vamzdynas. Jame vaizdas surenkamas, išbandomas, iškeliamas į įvairias Kubernetes grandines derinimui ir likusiems patikrinimams, o jei viskas gerai, pakeitimai pasiekia galutinį vartotoją. Ir tai jau ne raketų mokslas, o kasdienis reiškinys daugeliui – greičiausiai jums, nes skaitote šį straipsnį.

Kadangi klaidų taisymas ir naujų funkcijų kūrimas vykdomas lygiagrečiai, o leidimai gali būti atliekami kelis kartus per dieną, akivaizdu, kad kūrimo procesą lydi nemažas įsipareigojimų skaičius, o tai reiškia daug vaizdų registre. Dėl to iškyla efektyvaus registro valymo organizavimo klausimas, t.y. pašalinant nesusijusius vaizdus.

Bet kaip nustatyti, ar vaizdas yra aktualus?

Vaizdo aktualumo kriterijai

Daugeliu atvejų pagrindiniai kriterijai bus:

1. Pirmasis (akivaizdžiausias ir kritiškiausias iš visų) yra vaizdai, kurie šiuo metu naudojamas Kubernetes. Pašalinus šiuos vaizdus, ​​gali atsirasti didelių gamybos prastovos sąnaudų (pavyzdžiui, vaizdų gali prireikti replikuoti) arba panaikinti komandos pastangas derinant bet kurią kilpą. (Dėl šios priežasties mes netgi sukūrėme specialų „Prometheus“ eksportuotojai, kuris stebi tokių vaizdų nebuvimą bet kuriame Kubernetes klasteryje.)

2. Antras (mažiau akivaizdus, ​​bet taip pat labai svarbus ir vėlgi susijęs su išnaudojimu) – vaizdai, kurie reikalingas grąžinimui aptikus rimtų problemų dabartinėje versijoje. Pavyzdžiui, Helm atveju tai yra vaizdai, naudojami išsaugotose leidimo versijose. (Beje, pagal numatytuosius nustatymus Helme limitas yra 256 versijos, bet vargu ar kam nors tikrai reikės išsaugoti tokia daug versijų?..) Juk mes ypač saugome versijas, kad vėliau galėtume jas naudoti, t.y. Jei reikia, „grįžkite“ prie jų.

3. Trečia – kūrėjo poreikius: visi vaizdai, susiję su dabartiniu jų darbu. Pavyzdžiui, jei svarstome apie PR, prasminga palikti vaizdą, atitinkantį paskutinį ir, tarkime, ankstesnį įsipareigojimą: tokiu būdu kūrėjas gali greitai grįžti prie bet kokios užduoties ir dirbti su naujausiais pakeitimais.

4. Ketvirta – vaizdai, kurie atitinka mūsų programos versijas, t.y. yra galutinis produktas: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra ir kt.

NB: Čia apibrėžti kriterijai buvo suformuluoti remiantis patirtimi, įgyta bendraujant su daugybe skirtingų įmonių kūrėjų komandų. Tačiau, žinoma, priklausomai nuo kūrimo procesų specifikos ir naudojamos infrastruktūros (pavyzdžiui, nenaudojama Kubernetes), šie kriterijai gali skirtis.

Tinkamumas ir esami sprendimai

Populiarios paslaugos su konteinerių registrais, kaip taisyklė, siūlo savo vaizdo valymo politiką: jose galite apibrėžti sąlygas, kuriomis žyma pašalinama iš registro. Tačiau šias sąlygas riboja tokie parametrai kaip pavadinimai, sukūrimo laikas ir žymų skaičius*.

* Priklauso nuo konkrečių konteinerių registro diegimų. Apsvarstėme šių sprendimų galimybes: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io – nuo ​​2020 m. rugsėjo mėn.

Šio parametrų rinkinio visiškai pakanka, kad būtų patenkintas ketvirtasis kriterijus - tai yra, kad būtų atrinkti vaizdai, atitinkantys versijas. Tačiau pagal visus kitus kriterijus tenka rinktis kokį nors kompromisinį sprendimą (griežtesnę arba, atvirkščiai, švelnesnę politiką) – priklausomai nuo lūkesčių ir finansinių galimybių.

Pavyzdžiui, trečiąjį kriterijų – susijusį su kūrėjų poreikiais – galima išspręsti organizuojant procesus komandose: konkretų vaizdų įvardijimą, specialių leidimų sąrašų ir vidinių susitarimų tvarkymą. Bet galiausiai tai vis tiek turi būti automatizuota. O jei jau paruoštų sprendimų galimybių neužtenka, tenka ką nors padaryti savo.

Situacija su pirmaisiais dviem kriterijais yra panaši: jie negali būti patenkinti negavus duomenų iš išorinės sistemos - tos, kurioje yra įdiegtos programos (mūsų atveju, Kubernetes).

Git darbo eigos iliustracija

Tarkime, kad dirbate kažką panašaus į Git:

Diagramoje esanti piktograma su galvute nurodo konteinerio vaizdus, ​​​​kuriuo šiuo metu yra įdiegta „Kubernetes“ bet kuriems vartotojams (galutiniams vartotojams, bandytojams, valdytojams ir kt.) arba kuriuos kūrėjai naudoja derindami ir panašiais tikslais.

Kas atsitiks, jei valymo politika leidžia išsaugoti tik vaizdus (neištrinti) pagal duotus žymų pavadinimus?

Akivaizdu, kad toks scenarijus nieko nenudžiugins.

Kas pasikeis, jei politika leis vaizdų neištrinti? pagal tam tikrą laiko intervalą / paskutinių įsipareigojimų skaičių?

Rezultatas tapo daug geresnis, bet vis dar toli nuo idealo. Juk vis dar turime kūrėjų, kuriems reikia vaizdų registre (ar net įdiegtų K8s), kad būtų galima derinti klaidas...

Apibendrinant dabartinę rinkos situaciją: konteinerių registruose esančios funkcijos nesuteikia pakankamai lankstumo valant, o pagrindinė to priežastis yra jokio būdo bendrauti su išoriniu pasauliu. Pasirodo, komandos, kurioms reikalingas toks lankstumas, yra priverstos savarankiškai įgyvendinti vaizdo ištrynimą „iš išorės“, naudojant „Docker“ registro API (arba atitinkamo diegimo savąją API).

Tačiau mes ieškojome universalaus sprendimo, kuris automatizuotų vaizdo valymą skirtingoms komandoms naudojant skirtingus registrus...

Mūsų kelias į universalų vaizdo valymą

Iš kur toks poreikis? Faktas yra tai, kad mes nesame atskira kūrėjų grupė, o komanda, kuri aptarnauja daug jų vienu metu, padedanti kompleksiškai spręsti CI/CD problemas. Ir pagrindinis techninis įrankis tam yra atvirojo kodo įrankis werf. Jo ypatumas yra tai, kad jis neatlieka vienos funkcijos, bet lydi nuolatinius pristatymo procesus visuose etapuose: nuo surinkimo iki diegimo.

Vaizdų paskelbimas registre* (iš karto po jų sukūrimo) yra akivaizdi tokios programos funkcija. O kadangi vaizdai ten patalpinami saugojimui, tuomet – jei jūsų saugykla nėra neribota – turite būti atsakingi už vėlesnį jų valymą. Apie tai, kaip mums pavyko tai pasiekti, tenkinant visus nurodytus kriterijus, bus aptarta toliau.

* Nors patys registrai gali skirtis (Docker Registry, GitLab Container Registry, Harbor ir kt.), jų vartotojai susiduria su tomis pačiomis problemomis. Universalus sprendimas mūsų atveju nepriklauso nuo registro įdiegimo, nes veikia už pačių registrų ribų ir siūlo tą patį elgesį visiems.

Nors mes naudojame werf kaip įgyvendinimo pavyzdį, tikimės, kad naudojami metodai bus naudingi kitoms komandoms, susiduriančioms su panašiais sunkumais.

Taigi mes užsiėmėme išorinis vaizdų valymo mechanizmo įgyvendinimas - vietoj tų galimybių, kurios jau yra integruotos į konteinerių registrus. Pirmasis žingsnis buvo naudoti Docker registro API, kad būtų sukurtos tokios pačios primityvios žymų skaičiaus ir jų sukūrimo laiko strategijos (minėtos aukščiau). Prie jų pridėta leidimų sąrašas, pagrįstas įdiegtoje infrastruktūroje naudojamais vaizdais, t.y. Kubernetes. Pastariesiems pakako naudoti Kubernetes API, kad būtų galima kartoti visus įdiegtus išteklius ir gauti verčių sąrašą. image.

Šis trivialus sprendimas išsprendė svarbiausią problemą (kriterijus Nr. 1), tačiau buvo tik mūsų kelionės tobulinti valymo mechanizmą pradžia. Kitas – ir daug įdomesnis – žingsnis buvo sprendimas susieti paskelbtus vaizdus su „Git“ istorija.

Žymėjimo schemos

Pirmiausia pasirinkome metodą, pagal kurį galutiniame vaizde turėtų būti saugoma valymui reikalinga informacija, ir sukūrėme procesą pagal žymėjimo schemas. Skelbdamas vaizdą vartotojas pasirinko konkrečią žymėjimo parinktį (git-branch, git-commit arba git-tag) ir naudojo atitinkamą reikšmę. CI sistemose šios reikšmės buvo nustatytos automatiškai, atsižvelgiant į aplinkos kintamuosius. Faktiškai galutinis vaizdas buvo susietas su konkrečiu Git primityvu, išsaugodami etiketėse reikalingus valymui duomenis.

Šis metodas lėmė politikos rinkinį, leidžiantį naudoti „Git“ kaip vienintelį tiesos šaltinį:

• Ištrinant šaką / žymą „Git“, susieti vaizdai registre buvo automatiškai ištrinti.
• Vaizdų, susietų su „Git“ žymomis ir įsipareigojimais, skaičių galima valdyti pagal pasirinktoje schemoje naudojamų žymų skaičių ir laiką, kada buvo sukurtas susietas įsipareigojimas.

Apskritai, sukurtas įgyvendinimas patenkino mūsų poreikius, tačiau netrukus mūsų laukė naujas iššūkis. Faktas yra tas, kad naudodami žymėjimo schemas, pagrįstas Git primityvais, susidūrėme su daugybe trūkumų. (Kadangi jų aprašymas nepatenka į šio straipsnio taikymo sritį, kiekvienas gali susipažinti su detalėmis čia.) Todėl nusprendę pereiti prie efektyvesnio požiūrio į žymėjimą (turinio žymėjimą), turėjome persvarstyti vaizdo valymo įgyvendinimą.

Naujas algoritmas

Kodėl? Naudojant turiniu pagrįstą žymėjimą, kiekviena žyma gali patenkinti kelis Git įsipareigojimus. Valydami vaizdus nebegalite manyti tik iš įsipareigojimo, kai nauja žyma buvo įtraukta į registrą.

Dėl naujojo valymo algoritmo buvo nuspręsta atsisakyti žymėjimo schemų ir kurti metavaizdo procesas, kurių kiekvienoje saugoma krūva:

• įvykdymas, kuriuo buvo paskelbtas (nesvarbu, ar vaizdas buvo pridėtas, pakeistas ar išliko toks pat konteinerio registre);
• ir mūsų vidinis identifikatorius, atitinkantis surinktą vaizdą.

Kitaip tariant, buvo suteikta paskelbtų žymų susiejimas su įsipareigojimais „Git“..

Galutinė konfigūracija ir bendras algoritmas

Konfigūruodami valymą vartotojai dabar turi prieigą prie politikos, kuri pasirenka esamus vaizdus. Kiekviena tokia politika yra apibrėžta:

• daug nuorodų, t.y. „Git“ žymos arba „Git“ šakos, kurios naudojamos nuskaitymo metu;
• ir kiekvienos rinkinio nuorodos ieškomų vaizdų limitas.

Norėdami iliustruoti, štai kaip pradėjo atrodyti numatytoji politikos konfigūracija:

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

Šioje konfigūracijoje yra trys strategijos, atitinkančios šias taisykles:

1. Išsaugokite 10 paskutinių „Git“ žymų vaizdą (pagal žymos sukūrimo datą).
2. Išsaugokite ne daugiau kaip 2 vaizdus, ​​paskelbtus per paskutinę savaitę, ne daugiau nei 10 gijų su veikla pastarąją savaitę.
3. Išsaugokite 10 filialų vaizdų main, staging и production.

Galutinis algoritmas susideda iš šių veiksmų:

• Nuskaitomi aprašai iš konteinerio registro.
• Išskyrus vaizdus, ​​naudojamus Kubernetes, nes Mes jau iš anksto juos pasirinkome apklausdami K8s API.
• „Git“ istorijos nuskaitymas ir vaizdų išskyrimas pagal nurodytą politiką.
• Pašalinami likę vaizdai.

Grįžtant prie iliustracijos, štai kas atsitinka su werf:

Tačiau net jei nenaudojate werf, panašus požiūris į išplėstinį vaizdo valymą – vienokiu ar kitokiu įgyvendinimu (pagal pageidaujamą vaizdo žymėjimo metodą) – gali būti taikomas ir kitoms sistemoms/paslaugoms. Norėdami tai padaryti, pakanka prisiminti kylančias problemas ir rasti savo krūvoje tas galimybes, kurios leidžia kuo sklandžiau integruoti jų sprendimą. Tikimės, kad mūsų nueitas kelias padės jums pažvelgti į jūsų konkretų atvejį su naujomis detalėmis ir mintimis.

išvada

• Anksčiau ar vėliau dauguma komandų susiduria su registro perpildymo problema.
• Ieškant sprendimų pirmiausia reikia nustatyti vaizdo aktualumo kriterijus.
• Populiarių konteinerių registro paslaugų siūlomos priemonės leidžia suorganizuoti labai paprastą valymą, neatsižvelgiant į „išorinį pasaulį“: „Kubernetes“ naudojamus vaizdus ir komandos darbo eigos ypatumus.
• Lankstus ir efektyvus algoritmas turi suprasti CI/CD procesus ir veikti ne tik su Docker vaizdo duomenimis.

PS

Taip pat skaitykite mūsų tinklaraštyje:

• «Turiniu pagrįstas žymėjimas werf kolekcionieriuje: kodėl ir kaip tai veikia?»;
• «Trijų krypčių sujungimas su werf: diegimas į Kubernetes su Helm „naudojant steroidus“»;
• «„Monorepo“ ir „multirepo“ palaikymas „werf“ ir ką su tuo turi „Docker“ registras»;
• «werf 1.1 leidimas: statybininko patobulinimai šiandien ir ateities planai".

Šaltinis: www.habr.com