🥇Probleem 'nutikast' konteineripiltide puhastamisest ja selle lahendus werf

Artiklis käsitletakse konteinerite registrites (nt Docker Registry) kogunevate piltide puhastamise probleeme kaasaegsete CI/CD torujuhtmete tingimustes, mis on mõeldud Kuberneteses tarnitavatele pilvepõhistele rakendustele. Toome välja peamised piltide aktuaalsuse kriteeriumid ja nendest tulenevad raskused puhastamise automatiseerimisel, ruumi säästmisel ja meeskondade vajaduste rahuldamisel. Lõpuks räägime konkreetse avatud lähtekoodiga projekti näitel, kuidas neid raskusi ületada.

Sissejuhatus

Konteinerite registris olevate piltide arv võib kiiresti kasvada, hõivates rohkem ruumi salvestuses ja suurenedes seeläbi oluliselt selle maksumust. Ruumi kontrollimiseks, piiramiseks või vastuvõetava kasvu säilitamiseks registry's kasutatakse tavaliselt:

fikseeritud arvu silte piltide jaoks;
millelegi muule nagu piltide puhastamine.

Esimene piirang on mõnikord lubatav väikestes meeskondades. Kui arendajatele piisab püsivatest siltest (latest, main, test, boris jne), ei paisu register suuruseks ja saab pikka aega täielikult unustada puhastamisest. Kõik mitteaktuaalsed pildid üksteise üle kirjutatakse ja puhastamiseks ei jää lihtsalt tööd (kõik toimub tavapärase rämpsupüüdja kaudu).

Siiski piirab selline lähenemine tugevalt arendustegevust ja on harva kasutatav kaasaegsetes CI/CD projektides. Arendamise lahutamatuks osaks on saanud automaatika, mis võimaldab uute funktsioonide testimist, juurutamist ja tarnimist kasutajatele palju kiiremini. Näiteks meie kõigis projektides luuakse iga commiti ajal automaatselt CI-pipe. Seal luuakse pilt, testitakse, suunatakse erinevatesse Kubernetes keskkondadesse tõrgete vältimiseks ja ülejäänud kontrollide jaoks, ja kui kõik on hästi, jõuavad muudatused lõppkasutajani. See pole ammu mitte raketiteadus, vaid paljudele igapäevane praktika — tõenäoliselt ka teile, kuna loete seda artiklit.

Kuna vigade kõrvaldamine ja uue funktsionaalsuse arendamine toimub paralleelselt ning väljastamine võib toimuda mitu korda päevas, on ilmselge, et arendusprotsessiga kaasneb märkimisväärne arv commit'e, ja seega - suure arvu piltide olemasolu registry's.Seetõttu kerkib teravalt üles küsimus efektiivse registry puhastamise korraldamisest, st mitteaktuaalsete piltide eemaldamisest.

Kuidas aga kindlaks teha, kas pilt on asjakohane?

Pildi asjakohasuse kriteeriumid

Enamikul juhtudel on peamised kriteeriumid järgmised:

1. Esimene (kõige ilmsem ja kõikidest kõige kriitilisem) — need on pildid, mis hetkel kasutatakse Kuberneteses. Nende eemaldamine võib põhjustada tõsiseid kulusid seoses produktsiooni seiskumisega (näiteks võivad pildid olla vajalikud kopeerimise ajal) või tühistada meeskonna pingutused, kes tegeleb tõrgete tõrkeotsinguga mõnes kontuuris. (Sellepärast tegime eraldi Prometheus eksportija, mis jälgib selliste piltide puudumist igas Kubernetes-klastris.)

2. Teine (vähem ilmne, kuid samuti väga oluline ja jälle seotud kasutamisega) — pildid, mis on vajalikud rikka juhtudel, kui esinevad tõsised probleemid praeguses versioonis. Näiteks, kui rääkida Helm'ist, siis on need pildid, mis on kasutusel salvestatud väljalaskeversioonides. (Muide, Helm'il on vaikimisi 256 revideerimise piirmäär, kuid kas kellelgi on tõeliselt vajadust säilitada nii suurt versioonide arvu?..) Me hoiame versioone just selleks, et neid hiljem kasutada, st et saaksime vajadusel „tagasi pöörduda“.

3. Kolmas — arendajate vajadused: kõik pildid, mis on seotud nende praeguste töödega. Näiteks, kui vaatame PR'i, on mõistlik jätta pilt, mis vastab viimasele commit'ile ja, ütleme, eelmisele commit'ile: nii saab arendaja kiiresti naasta igasse ülesandesse ja töötada viimaste muudatustega.

4. Neljas — pildid, mis vastavad meie rakenduse versioonidele, st on lõpptooted: v1.0.0, 20.04.01, sierra jms.

NB: Siin välja toodud kriteeriumid on formuleeritud loodud on põhinedes kogemustele, mis on saadud koostöös kümnete arendajate meeskondadega erinevatest ettevõtetest. Kuid loomulikult võivad need kriteeriumid erinevalt sõltuda arendusprotsesside ja kasutatava infrastruktuuri (nt kui Kubernetesit ei kasutata) spetsiifikast.

Kriteeriumite vastavus ja olemasolevad lahendused

Populaarsed konteineriregistrite teenused pakuvad tavaliselt oma pildipuhastuspoliitikat: nendes saate määrata tingimused, mille alusel silt kustutatakse registrist. Kuid nende tingimuste võimalused on piiratud selliste parameetritega nagu nimed, loomise aeg ja siltide arv*.

* Sõltub konkreetsest konteineriregistri rakendusest. Oleme uurinud järgmiste lahenduste võimalusi: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io — seisuga septembr ’2020.

Selline parameetrite kogum on piisav, et rahuldada neljandat kriteeriumi — see tähendab valides pilte, mis vastavad versioonidele. Kõikide ülejäänud kriteeriumite puhul peab aga leidma mingisuguse kompromissi (karmema või vastupidi, leebema poliitika) vastavalt ootustele ja rahalistele võimalustele.

Näiteks kolmas kriteerium — arendajate vajadustega seotud — võib lahendada meeskondade sees toimingute korraldamise kaudu: spetsiifiliste piltide nimetamine, spetsiaalsete lubade loetelu koostamine ja sisemised kokkulepped. Kuid lõpuks tuleb see ikkagi automatiseerida. Ja kui valmis lahendused ei rahulda vajadusi, tuleb teha midagi oma kätega.

Sarnane olukord on ka kahe esimese kriteeriumiga: neid ei saa täita ilma andmete saamiseta välisest süsteemist — just sellest, kus rakenduste juurutamine toimub (meie puhul on see Kubernetes).

Töövoo illustratsioon Git-is

Oletame, et töötate umbes sellise skeemi järgi Git-is:

Scheemis märgitud pea ikooniga on konteineripildid, mis on hetkel juurutatud Kuberneteses mõnedele kasutajatele (lõppkasutajatele, testijatele, juhtidele jne) või mida arendajad kasutavad tõrgete tõrkeotsinguks ja muudel eesmärkidel.

Mida juhtub, kui puhastuspoliitikad lubavad jätta (mitte kustutada) pilte ainult määrapidude nimede järgi?

Ilmselgelt ei meeldi see stsenaarium kellelegi.

Mis muutub, kui poliitikad võimaldavad mitte kustutada pilte määratud ajavahemiku / viimaseid commit’e arvu põhjal?

Tulemus on olnud märkimisväärselt parem, kuid on endiselt kaugel ideaalist. Lõppude lõpuks on meil endiselt arendajaid, kellele on vaja pilte registris (või isegi juurutatud K8s-s), et tõrkeid tõrkeotsinguks…

Kokkuvõttes ei paku konteineriregistrite kaudu saadaval olevad funktsioonid piisavat paindlikkust puhastamise osas, mille peamine põhjus on välismaailmaga suhtlemise puudumine. Tulemuseks on see, et meeskonnad, kes vajavad sellist paindlikkust, peavad piltide eemaldamist „väljastpoolt“ ise rakendama, kasutades Docker Registry API-d (või vastava rakenduse natiivset API-d).

Otsisime universaalset lahendust, mis automatiseeriks piltide puhastamise erinevate meeskondade jaoks, kes kasutavad erinevaid registreid…

Meie tee universaalse piltide puhastamiseni

Kust see vajadus tuleb? Asi on selles, et me ei ole üksi arendajate rühm, vaid meeskond, mis teenindab mitmeid selliseid rühmi, aidates komplekselt lahendada CI/CD küsimusi. Ja peamine tehniline tööriist selleks on avatud lähtekoodiga utiliit werf. Selle eripära on see, et see ei täida ainult ühte funktsiooni, vaid toob esile pideva tarnimise protsessid kõigil etappidel: kogumisest kuni juurutamiseni.

Piltide registreerimine* (kohe pärast nende koostamist) on sellise utiliidi ilmne funktsioon. Ja kuna pildid pannakse sinna säilitamiseks, siis — kui teie ladustamine ei ole lõputu — tuleb vastutada ka nende hilisema puhastamise eest. Edasi räägime, kuidas me selles osas edu saavutasime, järgides kõiki ette antud kriteeriume.

* Kuigi registreerimised võivad olla erinevad (Docker Registry, GitLabi konteineri register, Harbor jne), seisavad nende kasutajad silmitsi sama probleemiga. Meie universaalne lahendus ei sõltu registreerimise rakendusest, kuna see tehakse väljaspool registreid ja pakub ühtlast käitumist kõigile.

Kuigi kasutame werfi rakenduse näitena, loodame, et rakendatud lähenemised on kasulikud ka teistele meeskondadele, kes silmitsi seisavad sarnaste raskustega.

Nii et me asusime välis mehhanismi rakendama piltide puhastamiseks — selle asemel, et kasutada konteineriregistrites juba olemasolevaid võimalusi. Esimene samm oli Docker Registry API kasutamine nende lihtsate poliitikate loomiseks, mis käsitlesid siltide arvu ja nende loomise aega (nagu eespool mainitud). Neile lisati lubatud nimekiri põhjal, mida kasutati juurutatud infrastruktuuris, st, Kubernetes. Viimase jaoks oli piisav, et läbi Kubernetes API läbida kõik juurutatud ressursid ja saada väärtuste nimekirja. image.

See lihtne lahendus lahendas kõige kriitilisema probleemi (kriteerium nr 1), kuid see oli vaid meie teekonna algus puhastusmehhanismi parendamiseks. Järgmine ja palju huvitavam samm oli lahendamine seostada avaldatud pildid Git'i ajalooga..

Siltimisplaanid

Alustuseks valisime lähenemise, mille kohaselt peab lõpppilt salvestama vajalikku teavet puhastamiseks ja me ehitasime protsessi siltimisplaanide peale. Pildi avaldamisel valis kasutaja teatud siltimisvõimaluse (git-haru, git-commit või git-silt) ja kasutas vastavat väärtust. CI-süsteemides seadistati need väärtused automaatselt keskkonnamuutujate alusel. Sisuliselt seostati lõpppilt teatud Git'i primitiiviga,hoides vajalikku teavet puhastamiseks silte.

Selle lähenemise raames saadi poliitikate kogum, mis võimaldas Git'i kasutada ainsa tõe allikana:

Kui haru/silt eemaldati Git'is, eemaldati automaatselt ka seotud pildid registrist.
Piltide arv, mis oli seotud Git'i siltide ja commit'idega, sai reguleerida valitud skeemis kasutatud siltide arvu ja seotud commit'i loomise aega.

Kokkuvõttes rahuldas saadud rakendus meie vajadusi, kuid peagi ootas meid uus väljakutse. Asi on selles, et Git'i primitiivide siltimisplaanide kasutamise ajal sattusime mitmete puudustega kokku. (Kuna nende kirjeldamine ületab selle artikli teema, saavad kõik huvilised tutvuda üksikasjadega. siin.) Seetõttu, otsustades üle minna efektiivsemale siltimisvõimalusele (sisu põhine siltimine), pidime meie rakendust piltide puhastamiseks üle vaatama.

Uus algoritm

Miks? Siltimise käigus sisu põhine siltimine võimaldab igal sildil rahuldada mitmeid Git'i commit'e. Piltide puhastamisel ei saa enam lähtuda seda commit'ist, mille põhjal uus silt registrisse lisati.

Uue puhastusalgoritmi jaoks otsustati üle minna siltimisplaanidest ja luua protsess meta-piltide peale,igaüks neist salvestab sideme:

commit, mille avaldamine toimus (ilma et oleks oluline, kas pilt registris konteinerites lisandus, muutus või jäi samaks);
ja meie sisemise identifikaatori, mis vastab kogutud pildile.

Teisisõnu, oli tagatud avaldatud siltide seos Git commitidega.

Lõplik konfiguratsioon ja üldine algoritm

Kasutajatele on konfigureerimise puhastamisel saadaval poliitikad, mille alusel valitakse aktuaalsed pildid. Iga selline poliitika määratletakse:

mitme viite kaudu, st Git-siltide või Git-haru kaudu, mida kasutatakse skannimise ajal;
ja otsitava pildi limiit iga viite jaoks.

Illustratsiooni jaoks – siin on, kuidas vaikimisi poliitikad välja näevad:

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

Selline konfiguratsioon sisaldab kolme poliitikat, mis vastavad järgmistele reeglitele:

Hoida pilti 10 viimase Git-sildi jaoks (sildi loomise kuupäeva järgi).
Hoida mitte rohkem kui 2 pilti, mis on avaldatud viimase nädala jooksul, mitte rohkem kui 10 haru jaoks, mis on aktiivsed viimase nädala jooksul.
Hoida 10 pilti harude jaoks main, staging ja production.

Lõplik algoritm sisaldab järgmisi samme:

Manifestide saamine konteineri registrist.
Piltide eemaldamine, mida kasutatakse Kuberneteses, kuna need on juba eelnevalt väljavalitud, küsides K8s API-lt.
Git-ajaloo skannimine ja piltide eemaldamine antud poliitikate järgi.
Ülejäänud piltide eemaldamine.

Tagasi meie illustratsiooni juurde, siin on, mida werfiga saate:

Kuid isegi kui te ei kasuta werf-i, võib sarnane lähenemine edasisele piltide puhastamisele – ühel või teisel viisil (vastavalt eelistatud piltide sildistamise lähenemisele) – olla rakendatud ka muudes süsteemides/ utiliitides. Sellega piisab, kui meeles pidada, milliseid probleeme võib esineda, ja leida võimalused teie teeninduskeskkonnas, mis võimaldavad nende lahendust sujuvalt integreerida. Loodame, et meie läbipõidud tee aitab teil näha ka teie erijuhtumit uute detailide ja mõtetega.

Kokkuvõte

Varsti või hiljem puutub enamik meeskondi kokku registri ületäitumise probleemiga.
Otsuste tegemisel tuleb esmalt määratleda pildikehtivuse kriteeriumid.
Tuntud konteineriregistrite teenuste pakutavad tööriistad võimaldavad organiseerida väga lihtsa puhastamise, mis ei arvesta 'välist maailma': Kuberneteses kasutatavad pildid ja meeskonna tööprotsesside eripärad.
Paindlik ja tõhus algoritm peaks olema teadlik CI/CD protsessidest, hallates mitte ainult Docker-piltide andmeid.