🥇Konteinerite "nutika" puhastamise probleem ja selle lahendus werf

Artiklis käsitletakse konteinerite registrites (Docker Registry ja sarnastes) kogunevate piltide puhastamise probleemistikku, arvestades tänapäevaseid CI/CD torujuhtmeid cloud native rakenduste jaoks, mis on tarnitud Kubernetesesse. Esitatakse peamised kriteeriumid piltide asjakohasuse osas ja nendest tulenevad raskused puhastamise automatiseerimisel, ruumi säästmisel ja meeskondade vajaduste rahuldamisel. Lõpuks, kasutades konkreetse Open Source projekti näidet, räägime, kuidas neid raskusi ületada.

Sissejuhatus

Konteinerite registris olevate piltide arv võib kiiresti suureneda, kulutades rohkem ruumi salvestusmahule ning seeläbi suurendades oluliselt selle maksumust. Registris ruumi kontrollimise, piiramise või vastuvõetava kasvu säilitamise jaoks on tavaks:

kasutada fikseeritud arvu silte piltidele;
mingil moel piltide puhastamine.

Esimene piirang on mõnikord lubatav väikestes meeskondades. Kui arendajatele piisab pidevatest siltidest (latest, main, test, boris ja jne), register ei suureneks, ja pikalt ei pea üldse muretsema puhastamise pärast. Kõik aegumatud kujutised asendatakse, ning puhastamiseks ei jää lihtsalt tööd (kõik toimub tavalise prügikoguja kaudu).

Kuid selline lähenemine piirab arendust ja sageli ei ole see rakendatav kaasaegse CI/CD projektide puhul. Arenduse lahutamatu osa on automatiseerimine, mis võimaldab palju kiiremini testida, juurutada ja edastada uusi funktsioone kasutajatele. Näiteks meie kõigis projektides luuakse igal commitil automaatselt CI-pipeline. Seal kogutakse pilt, testitakse, juurutatakse erinevatesse Kubernetes'i keskkondadesse tõrgeteotsimiseks ja järelejäänud kontrollide läbiviimiseks, ning kui kõik on hästi, jõuavad muudatused lõppkasutajani. See ei ole ammu enam rocket science, vaid iga päevane praktika paljudele — tõenäoliselt ka teile, kui loete seda artiklit.

Kuna vigade kõrvaldamine ja uute funktsioonide arendamine toimub paralleelselt ning väljalasked võivad toimuda mitu korda päevas, on ilmne, et arendusprotsessiga kaasneb märkimisväärne hulk commit'e, seega — registreerimises on palju pilte. Seetõttu tekib terav küsimus tõhusast registri puhastamisest, st mittesobivate piltide eemaldamisest.

Aga kuidas üldse määrata, kas pilt on asjakohane?

Pildi asjakohasuse kriteeriumid

Enamikul juhtudel on põhikriteeriumid järgmised:

1. Esimene (kõige ilmsem ja kriitilisem) — see on pildid, mis on hetkel kasutusel Kuberneteses. Nende piltide eemaldamine võib põhjustada tõsiseid kulusid seoses tootmise seiskumisega (näiteks võivad need pildid olla vajalikud replikatsiooniks) või tühistada meeskonna pingutused, mis tegeleb silumine ühe või teise kontuuri peal. (Sel põhjusel oleme isegi loonud spetsiaalse Prometheuse eksportija, mis jälgib selliste piltide puudumist igas Kubernetesi klastris.)

2. Teine (vähem ilmne, kuid samuti väga oluline ja jälle tootmisega seotud) — pildid, mis on vajalikud tagasipöördumiseks tõsiste probleemide ilmnemisel praeguses versioonis. Näiteks, Helmiga seoses on need pildid, mida kasutatakse salvestatud versioonides. (Muide, Helmil on vaikimisi 256 versiooni piirmäär, kuid tõenäoliselt pole kellelgi tegelikult vajadust salvestada sellist suur hulk versioone?..) Just selleks me versioone salvestame, et saaksime neid hiljem kasutada, st „tagasi kerida”, kui on vaja.

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

4. Neljas — pildid, mis vastavad meie rakenduse versioonidele, st on lõpp-produkt: v1.0.0, 20.04.01, sierra jne.

NB: Siin määratletud kriteeriumid on koostatud kogenud arendustiimide koostöökogemuse põhjal erinevatest ettevõtetest. Kuid loomulikult võivad need kriteeriumid varieeruda sõltuvalt arendusprotsesside ja kasutatava infrastruktuuri (nt Kubernetes'i mittekasutamine) spetsiifilisusest.

Kriteeriumite vastavus ja olemasolevad lahendused

Populaarsed container registry teenused pakuvad tavaliselt oma imagede puhastusreegleid: nendes on võimalik määrata tingimusi, mille kohaselt silt registry's kustutatakse. Kuid nende tingimuste võimalused on piiratud selliste parameetritega nagu nimed, loomise aeg ja siltide arv*.

* Sõltub konkreetsete container registry rakenduste võimalustest. Oleme vaadanud järgmiste lahenduste funktsioone: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io — seisuga september 2020.

Selliste parameetrite kogum on täiesti piisav, et täita neljas kriteerium — see tähendab valida pilte, mis vastavad versioonidele. Kuid kõigi teiste kriteeriumide puhul tuleb teha mingisugune kompromisslahendus (rangem või vastupidi, leebem poliitika) — sõltuvalt ootustest ja rahalistest võimalustest.

Näiteks kolmandat kriteeriumi — mis on seotud arendajate vajadustega — saab lahendada protsesside korraldamise kaudu meeskondades: spetsiifilised pildinimed, spetsiaalsete lubatud loendite koostamine ja sisemised kokkulepped. Kuid lõpuks on vaja see ikkagi automatiseerida. Ja kui valmis lahenduste võimalused ei piisa, tuleb midagi oma kätega teha.

Sama kehtib kahe esimese kriteeriumi kohta: neid ei saa täita, saamata andmeid välisest süsteemist — just sealt, kus rakenduste juurutamine toimub (meie puhul on see Kubernetes).

Workflowsi illustreerimine Git-is

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

Kujutise ikooniga on näidatud konteinerite pildid, mis on praegu Kuberneteses kasutuses mõne kasutaja (lõppkasutajad, testijad, juhendajad jne) jaoks või mida arendajad kasutavad tõrgete silumiseks ja sarnaste eesmärkide jaoks.

Mis juhtub, kui puhastuspoliitikad lubavad jätta (mitte kustutada) pildid ainult määratud sildinimede järgi.?

Ilmselgelt ei meeldi selline stsenaarium kellelegi.

Mis muutub, kui poliitikad lubavad mitte kustutada pilte määratud ajavahemiku / viimaste commitide arvu järgi.?

Tulemus on märgatavalt parem, kuid siiski kaugel ideaalist. Meil on endiselt arendajaid, kellele on vajalikud registris olevad pildid (või isegi Kuberneteses kasutatavad) tõrkeotsingu jaoks...

Kokkuvõttes valitsev olukord turul: konteineriregistrites pakutavad funktsioonid ei paku puhastamiseks piisavalt paindlikkust ja peamine põhjus on — puudub võimalus suhelda välismaailmaga.. Tundub, et meeskonnad, kellele on vajalik selline paindlikkus, peavad ise teostama piltide eemaldamise „väljastpoolt”, kasutades Docker Registry API-d (või vastava teostuse natiivset API-d).

Kuid me otsisime universaalset lahendust, mis automatiseeriks piltide puhastamise erinevate meeskondade jaoks, kes kasutavad erinevaid registrite...

Meie tee universaalse piltide puhastamise suunal

Kust see vajadus tuleb? Asi on selles, et me ei ole eraldi arendajate rühm, vaid meeskond, mis teenindab korraga mitut sellist, aidates lahendada CI/CD küsimusi terviklikult. Ja peamine tehniline tööriist selle jaoks on avatud lähtekoodiga utiliit. werf. Selle eripära on see, et see ei täida ühteainust funktsiooni, vaid toetab pideva kohaletoimetamise protsesse kõigil etappidel: kogumisest kuni juurutamiseni.

Piltide avaldamine registris* (vahetult pärast nende kogumist) on sellise utiliidi ilmselge funktsioon. Ja kuna pildid pannakse sinna hoidmiseks, siis — kui teie salvestusruum ei ole piiramatud — peate vastutama ka nende edasise puhastamise eest. Edasi räägime sellest, kuidas me oleme selles edukad, rahuldades kõik seatud kriteeriumid.

* Kuigi registrid võivad olla erinevad (Docker Registry, GitLabi konteineri register, Harbor jne), seisavad nende kasutajad silmitsi samade probleemidega. Universaalne lahendus meie puhul ei sõltu registri rakendusest, kuna see teostatakse registritest väljaspool ja pakub kõigile sama käitumist.

Kuigi kasutame werfi näitena rakendusest, loodame, et rakendatud lähenemisviisid on kasulikud ka teistele meeskondadele, kes seisavad silmitsi sarnaste keerukustega.

Nii et me võtsime käsile välise mehhanismi piltide puhastamiseks — erinevalt neist võimalustest, mis on juba konteinerite registrites sisse ehitatud. Esimene samm oli Docker Registry API kasutamine, et luua endiselt primitiivseid poliitikaid siltide arvu ja nende loomise aja kohta (nagu juba mainitud). Neile lisati lubamise nimekiri, mis põhineb rakendatud infrastruktuuris kasutatavatel piltidel, st Kubernetes. Viimase jaoks oli piisav, kui Kubernetes API kaudu läbi käia kõik juurutatud ressursid ja saada nimekiri väärtustest. pilt.

See lihtne 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 seostada avaldatud pildid Git'i ajalooga.

Märgistamisstrateegiad

Alguses valisime lähenemise, kus lõplik pilt peab sisaldama vajalikku teavet puhastamiseks, ja üles ehitasime protsessi märgistusstrateegiate põhjal. Pildi avaldamisel valis kasutaja kindla 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 alusel. Sisuliselt seoti lõplik pilt kindla Git'i primitiiviga, hoides puhastamiseks vajalikke andmeid etikettides.

Selle lähenemise raames loodi poliitikate kogum, mis võimaldas kasutada Git'i kui ainust tõepädevuse allikat:

Kui Git'is kustutati haru/tag, kustutati automaatselt ka seotud pildid registrist.
Git-tägidega ja commit'idega seotud piltide arvu saab reguleerida valitud skeemis kasutatud etiketide arvuga ja seotud commit'i loomise ajaga.

Kokkuvõttes vastas valminud teostus meie vajadustele, kuid peagi ootas meid uus väljakutse. Asi on selles, et Git'i primitiivide põhiste etiketiskeemide kasutamise ajal oleme kokku puutunud mitmete puudustega. (Kuna nende kirjeldus jääb käesoleva artikli teemast välja, võivad kõik huvilised tutvuda üksikasjadega siit.) Seetõttu, otsustades liikuda tõhusama lähenemise suunas etiketiseerimise (sisupõhine etikettimine) osas, pidime läbi vaatama ka piltide puhastamise teostuse.

Uus algoritm

Miks? Sisupõhises etikettimises võib iga etikett rahuldada mitmeid commit'e Git'is. Piltide puhastamisel ei saa enam lähtuda ainult commit'ist, mille alusel uus etikett registrisse lisati.

Uue puhastuse algoritmi jaoks otsustati loobuda etiketiseerimise skeemidest ja luua protsess meta-piltide põhjal, millest igaühes hoitakse sidet:

kommiit, millega tehti avaldamine (ilmtingimata ei oma tähtsust, kas pilt konteinerristis lisandus, muutus või jäi samaks);
ja meie sisemise identifikaatori, mis vastab koostatud pildile.

Teisisõnu, tagati avaldatud siltide ja Git'i kommintide seos.

Lõplik konfigureerimine ja üldine algoritm

Kasutajad said puhastuskonfiguratsioonis kätte poliitikad, mille alusel valitakse aktuhed pildid. Iga selline poliitika määratletakse:

rohke reference'iga, st Git'i siltide või Git'i harudega, mida kasutatakse skannimisel;
ja otsitava pildi limiidiga iga reference'i jaoks.

Ilustratsiooniks — siin on, kuidas vaikimisi poliitikate konfiguratsioon välja nägi:

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 pilt 10 viimase Git-sildi jaoks (sildi loomise kuupäeva alusel).
Säilitada mitte rohkem kui 2 pilti, mis on avaldatud viimase nädala jooksul, kuni 10 haru tegevusega viimase nädala jooksul.
Säilitada 10 pilti harude jaoks. main, staging ja tootmisse.

Kokkuvõtlik algoritm koosneb järgmistest sammudest:

Manifestide saamine konteineri registrist.
Piltide välistamine, mida kasutatakse Kuberneteses, kuna need on juba eelnevalt valitud, küsides K8s API-lt.
Git-i ajaloos skaneerimine ja piltide välistamine vastavalt määratud poliitikatele.
Järelejäänud piltide kustutamine.

Naastes meie illustratsiooni juurde, siin on see, mis juhtub werfiga:

Kuid isegi kui te ei kasuta werf'i, võib sarnane lähenemine piltide edasisele puhastamisele — mis tahes rakenduses (vastavalt eelistatud piltide sildistamise lähenemisele) — olla rakendatav ka muudes süsteemides/utiliitides. Piisab, kui mäletada neid probleeme, mis võivad tekkida, ja leida need võimalused oma tehnoloogias, mis võimaldavad nende lahendusi sujuvalt integreerida. Loodame, et meie läbitud tee aitab vaadata ka teie konkreetset juhtumit uute detailide ja mõtetega.

Kokkuvõte

Varem või hiljem puutub enamik meeskondi kokku registri täitumise probleemiga.
Lahenduste otsimisel on esmalt vaja määratleda piltide asjakohasuse kriteeriumid.
Populaarsete konteineriregistri teenuste pakkumised võimaldavad korraldada väga lihtsa puhastuse, mis ei arvesta "välist maailma": pildid, mida kasutatakse Kuberneteses, ja meeskonna tööprotsesside eripärad.
Paindlik ja tõhus algoritm peaks arvestama CI/CD-protsessidega, töötlema mitte ainult Docker-pilte.