Artiklis käsitletakse konteinerregistritesse (Docker Registry ja selle analoogid) kogunevate piltide puhastamise probleeme Kubernetesesse tarnitavate pilvepõhiste rakenduste jaoks mõeldud kaasaegsete CI/CD torujuhtmete tegelikkuses. Antakse peamised kriteeriumid piltide asjakohasuse ja sellest tulenevate raskuste automatiseerimisel puhastamisel, ruumi säästmisel ja meeskondade vajaduste rahuldamisel. Lõpuks räägime konkreetse avatud lähtekoodiga projekti näitel teile, kuidas neid raskusi ületada.
Sissejuhatus
Konteinerregistris olevate piltide arv võib kiiresti kasvada, võttes rohkem salvestusruumi ja suurendades seega oluliselt selle maksumust. Registris hõivatud ruumi vastuvõetava kasvu kontrollimiseks, piiramiseks või säilitamiseks aktsepteeritakse järgmist:
- kasutage piltide jaoks kindlat arvu silte;
- mingil moel pilte puhastada.
Esimene piirang on mõnikord väikeste meeskondade jaoks vastuvõetav. Kui arendajatel on piisavalt püsivaid silte (latest, main, test, boris jne), register ei paisu ja pikka aega ei pea te üldse selle puhastamisele mõtlema. Kõik ebaolulised pildid ju kustutatakse ja puhastamiseks lihtsalt ei jää enam tööd (kõik teeb tavaline prügivedaja).
See lähenemine piirab aga suuresti arengut ja on harva rakendatav tänapäevaste CI/CD projektide puhul. Arengu lahutamatu osa oli automatiseerimine, mis võimaldab teil palju kiiremini uusi funktsioone testida, juurutada ja kasutajatele pakkuda. Näiteks kõigis meie projektides luuakse iga commitiga automaatselt CI konveier. Selles monteeritakse pilt kokku, testitakse, rullitakse erinevatesse Kubernetese vooluringidesse silumiseks ja järelejäänud kontrollideks ning kui kõik on korras, jõuavad muudatused lõppkasutajani. Ja see pole enam raketiteadus, vaid paljude jaoks igapäevane nähtus - tõenäoliselt teie jaoks, kuna loete seda artiklit.
Kuna vigade parandamine ja uute funktsionaalsuste väljatöötamine toimub paralleelselt ning väljalaseid saab teha mitu korda päevas, siis on ilmne, et arendusprotsessiga kaasneb märkimisväärne hulk commit’e, mis tähendab suur hulk pilte registris. Sellest tulenevalt kerkib küsimus registri tõhusa puhastamise korraldamisest, s.o. ebaoluliste piltide eemaldamine.
Kuid kuidas teha kindlaks, kas pilt on asjakohane?
Pildi asjakohasuse kriteeriumid
Enamikul juhtudel on peamised kriteeriumid järgmised:
1. Esimene (kõige ilmsem ja kriitilisem kõigist) on pildid, mis praegu kasutusel Kubernetes. Nende kujutiste eemaldamine võib kaasa tuua märkimisväärseid tootmisseisakukulusid (näiteks võivad kujutised olla vajalikud replikatsiooniks) või tühistada meeskonna pingutused mis tahes ahela silumisel. (Sel põhjusel tegime isegi spetsiaalse , mis jälgib selliste piltide puudumist üheski Kubernetese klastris.)
2. Teiseks (vähem ilmselge, aga ka väga oluline ja on jällegi seotud ekspluateerimisega) – pildid, mis vajalik tagasipööramiseks tõsiste probleemide avastamisel praeguses versioonis. Näiteks Helmi puhul on need pildid, mida kasutatakse väljalase salvestatud versioonides. (Muide, Helmis on vaikimisi limiit 256 versiooni, kuid on ebatõenäoline, et keegi peaks tõesti salvestama selline suur hulk versioone?..) Me ju talletame ju eelkõige versioone, et saaksime neid hiljem kasutada, s.t. Vajadusel "tagasi" nende juurde.
3. Kolmas – arendaja vajadustele: kõik pildid, mis on seotud nende praeguse tööga. Näiteks kui kaalume PR-i, siis on mõttekas jätta viimasele ja näiteks eelmisele kinnistamisele vastav pilt: nii saab arendaja kiiresti naasta mis tahes ülesande juurde ja töötada viimaste muudatustega.
4. Neljandaks – pildid, mis vastavad meie rakenduse versioonidele, st. on lõpptoode: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra jne.
NB: Siin määratletud kriteeriumid on sõnastatud kümnete erinevate ettevõtete arendusmeeskondadega suhtlemise kogemuse põhjal. Sõltuvalt arendusprotsesside spetsiifikast ja kasutatavast infrastruktuurist (näiteks ei kasutata näiteks Kubernetest) võivad need kriteeriumid siiski erineda.
Abikõlblikkus ja olemasolevad lahendused
Populaarsed konteineriregistritega teenused pakuvad reeglina oma pildipuhastusreegleid: neis saate määratleda tingimused, mille korral silt registrist eemaldatakse. Neid tingimusi piiravad aga sellised parameetrid nagu nimed, loomise aeg ja siltide* arv.
* Sõltub konkreetsetest konteineriregistri rakendustest. Kaalusime järgmiste lahenduste võimalusi: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io – 2020. aasta septembri seisuga.
See parameetrite komplekt on täiesti piisav neljanda kriteeriumi täitmiseks - see tähendab versioonidele vastavate piltide valimiseks. Kõigi muude kriteeriumide puhul tuleb aga valida mingi kompromisslahendus (karmim või vastupidi, leebem poliitika) – olenevalt ootustest ja rahalistest võimalustest.
Näiteks kolmandat – arendajate vajadustega seotud – kriteeriumi saab lahendada meeskondades protsesse korraldades: piltide konkreetne nimetamine, spetsiaalsete lubade nimekirjade ja sisemiste kokkulepete pidamine. Kuid lõpuks tuleb see ikkagi automatiseerida. Ja kui valmislahenduste võimalustest ei piisa, tuleb midagi ise ette võtta.
Kahe esimese kriteeriumiga on olukord sarnane: neid ei saa rahuldada ilma andmeid saamata välisest süsteemist - sellest, kus rakendused on juurutatud (meie puhul Kubernetes).
Giti töövoo illustratsioon
Oletame, et töötate Gitis midagi sellist:
Diagrammil olev peaga ikoon tähistab konteineri kujutisi, mis on praegu Kubernetesis kõigi kasutajate jaoks (lõppkasutajad, testijad, haldurid jne) juurutatud või mida arendajad kasutavad silumiseks ja sarnastel eesmärkidel.
Mis juhtub, kui puhastusreeglid lubavad ainult pilte säilitada (mitte kustutada) antud sildinimede järgi?
Ilmselgelt ei tee selline stsenaarium kedagi õnnelikuks.
Mis muutub, kui poliitika lubab pilte mitte kustutada? vastavalt etteantud ajaintervallile / viimaste sooritamiste arvule?
Tulemus on muutunud palju paremaks, kuid on endiselt ideaalsest kaugel. Lõppude lõpuks on meil endiselt arendajaid, kes vajavad vigade silumiseks registris (või isegi K8-s juurutatud) pilte...
Kokkuvõtteks hetke turuolukorrast: konteinerite registrites saadaolevad funktsioonid ei paku puhastamisel piisavalt paindlikkust ja selle peamiseks põhjuseks on mingit võimalust välismaailmaga suhelda. Selgub, et sellist paindlikkust vajavad meeskonnad on sunnitud iseseisvalt rakendama piltide kustutamist "väljastpoolt", kasutades Dockeri registri API-d (või vastava rakenduse natiivset API-d).
Otsisime aga universaalset lahendust, mis automatiseeriks piltide puhastamise erinevatele meeskondadele, kasutades erinevaid registreid...
Meie tee universaalse pildipuhastuse poole
Kust see vajadus tuleb? Fakt on see, et me ei ole eraldiseisev arendajate rühm, vaid meeskond, kes teenindab paljusid neist korraga, aidates CI/CD probleeme igakülgselt lahendada. Ja selle peamine tehniline tööriist on avatud lähtekoodiga utiliit . Selle eripära on see, et see ei täida ühte funktsiooni, vaid saadab pidevaid tarneprotsesse kõigil etappidel: alates kokkupanekust kuni kasutuselevõtuni.
Piltide avaldamine registris* (kohe pärast nende koostamist) on sellise utiliidi ilmselge funktsioon. Ja kuna pildid paigutatakse sinna ladustamiseks, siis - kui teie salvestusruum pole piiramatu - peate vastutama nende hilisema puhastamise eest. Sellest, kuidas me selles edu saavutasime, täites kõik määratletud kriteeriumid, arutatakse edasi.
* Kuigi registrid ise võivad olla erinevad (Docker Registry, GitLab Container Registry, Harbor jne), seisavad nende kasutajad silmitsi samade probleemidega. Universaalne lahendus meie puhul ei sõltu registri rakendamisest, sest töötab väljaspool registreid ja pakub kõigile sama käitumist.
Kuigi me kasutame werfi näidet, loodame, et kasutatud lähenemisviisid on kasulikud teistele sarnaste raskustega silmitsi seisvatele meeskondadele.
Nii et meil oli kiire väline piltide puhastamise mehhanismi rakendamine - nende võimaluste asemel, mis on juba konteinerite registritesse sisse ehitatud. Esimene samm oli kasutada Dockeri registri API-d, et luua samad primitiivsed poliitikad siltide arvu ja nende loomise aja jaoks (mainitud eespool). Neile lisatud lubade loend, mis põhineb juurutatud infrastruktuuris kasutatavatel piltidel, st. Kubernetes. Viimase jaoks piisas Kubernetes API kasutamisest kõigi juurutatud ressursside läbimiseks ja väärtuste loendi saamiseks image.
See triviaalne lahendus lahendas kõige kriitilisema probleemi (kriteerium nr 1), kuid oli alles meie teekonna algus puhastusmehhanismi täiustamiseks. Järgmine – ja palju huvitavam – samm oli otsus seostada avaldatud pilte Giti ajalooga.
Märgistusskeemid
Alustuseks valisime lähenemisviisi, kus lõplik pilt peaks salvestama puhastamiseks vajaliku teabe, ja ehitasime protsessi üles märgistamisskeemidele. Pildi avaldamisel valis kasutaja konkreetse märgistamisvaliku (git-branch, git-commit või git-tag) ja kasutas vastavat väärtust. CI-süsteemides määrati need väärtused automaatselt keskkonnamuutujate põhjal. Tegelikult lõplik pilt seostati konkreetse Git primitiiviga, salvestades etikettidesse puhastamiseks vajalikud andmed.
Selle lähenemisviisi tulemuseks oli poliitika, mis võimaldas Giti kasutada tõe allikana:
- Gitis filiaali/sildi kustutamisel kustutati registris olevad seotud pildid automaatselt.
- Git-märgendite ja sissekannetega seotud piltide arvu saab juhtida valitud skeemis kasutatud siltide arvu ja seotud sissekande loomise aja järgi.
Kokkuvõttes rahuldas teostus meie vajadused, kuid peagi ootas meid ees uus väljakutse. Fakt on see, et Git-primitiividel põhinevaid märgistamisskeeme kasutades avastasime mitmeid puudusi. (Kuna nende kirjeldus jääb sellest artiklist välja, saavad kõik üksikasjadega tutvuda .) Seetõttu, olles otsustanud minna üle tõhusamale märgistamise lähenemisviisile (sisupõhine märgistamine), pidime piltide puhastamise rakendamise uuesti läbi vaatama.
Uus algoritm
Miks? Sisupõhise sildistamise korral suudab iga silt Gitis täita mitut kohustust. Piltide puhastamisel ei saa enam eeldada ainult kinnitusest, kus uus silt registrisse lisati.
Uue puhastusalgoritmi puhul otsustati sildistamisskeemidest eemalduda ja ehitada metakujutise protsess, millest igaüks salvestab hulga:
- commit, mille alusel avaldamine tehti (ei ole oluline, kas pilt lisati, muudeti või jäi konteineriregistris samaks);
- ja meie sisemine identifikaator, mis vastab kokkupandud pildile.
Teisisõnu, see oli ette nähtud avaldatud märgendite linkimine Gitis tehtud kohustustega.
Lõplik konfiguratsioon ja üldine algoritm
Puhastamise konfigureerimisel on kasutajatel nüüd juurdepääs poliitikatele, mis valivad praegused pildid. Iga selline poliitika on määratletud:
- palju viiteid, st. Git-sildid või Git-harud, mida skannimise ajal kasutatakse;
- ja otsitavate piltide limiit iga komplekti viite jaoks.
Näitlikustamiseks hakkas poliitika vaikekonfiguratsioon välja nägema järgmine:
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
See konfiguratsioon sisaldab kolme poliitikat, mis vastavad järgmistele reeglitele.
- Salvestage pilt viimase 10 Giti sildi jaoks (sildi loomise kuupäeva järgi).
- Salvestage kuni 2 eelmisel nädalal avaldatud pilti kuni 10 viimase nädala tegevust sisaldava lõime jaoks.
- Salvestage okste jaoks 10 pilti
main,stagingиproduction.
Lõplik algoritm taandub järgmistele etappidele:
- Manifestide toomine konteineri registrist.
- Kubernetes kasutatavad pildid välja arvatud, kuna Oleme need juba K8s API küsitledes eelvalinud.
- Giti ajaloo skannimine ja piltide välistamine määratud reeglite alusel.
- Ülejäänud piltide eemaldamine.
Tulles tagasi meie illustratsiooni juurde, siis werfiga juhtub nii:
Kuid isegi kui te ei kasuta werfi, saab sarnast lähenemist täiustatud pildipuhastusele – ühes või teises teostuses (vastavalt eelistatud lähenemisviisile pildimärgistamisele) – rakendada ka teistes süsteemides/utiliitides. Selleks piisab, kui meeles pidada tekkivaid probleeme ja leida oma virust need võimalused, mis võimaldavad nende lahenduse võimalikult sujuvalt integreerida. Loodame, et meie läbitud tee aitab teil vaadata oma konkreetset juhtumit uute detailide ja mõtetega.
Järeldus
- Varem või hiljem puutub enamik meeskondi kokku registri ületäitumise probleemiga.
- Lahendusi otsides on esmalt vaja määrata pildi asjakohasuse kriteeriumid.
- Populaarsete konteinerite registriteenuste pakutavad tööriistad võimaldavad korraldada väga lihtsa puhastuse, mis ei võta arvesse “välismaailma”: Kubernetes kasutatavaid pilte ja meeskonna töövoogude iseärasusi.
- Paindlik ja tõhus algoritm peab mõistma CI/CD protsesse ja töötama mitte ainult Dockeri pildiandmetega.
PS
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com