🥇Die probleem van “slim” skoonmaak van houerbeelde en die oplossing daarvan in werf

Die artikel bespreek die probleme van die skoonmaak van beelde wat in houerregisters (Docker Registry en sy analoë) ophoop in die realiteite van moderne CI/CD-pyplyne vir wolk-inheemse toepassings wat aan Kubernetes gelewer word. Die belangrikste kriteria vir die relevansie van beelde en die gevolglike probleme om skoonmaak te outomatiseer, ruimte te bespaar en aan die behoeftes van spanne te voldoen, word gegee. Ten slotte, deur die voorbeeld van 'n spesifieke oopbronprojek te gebruik, sal ons jou vertel hoe hierdie probleme oorkom kan word.

Inleiding

Die aantal beelde in 'n houerregister kan vinnig groei, wat meer stoorplek opneem en sodoende die koste daarvan aansienlik verhoog. Om aanvaarbare groei van ruimte wat in die register beset word te beheer, te beperk of te handhaaf, word dit aanvaar:

gebruik 'n vaste aantal merkers vir beelde;
maak die beelde op een of ander manier skoon.

Die eerste beperking is soms aanvaarbaar vir klein spanne. As ontwikkelaars genoeg permanente etikette het (latest, main, test, boris ens.), sal die register nie in grootte swel nie en vir 'n lang tyd hoef jy glad nie daaraan te dink om dit skoon te maak nie. Alle irrelevante beelde word immers uitgevee, en daar is eenvoudig geen werk oor vir skoonmaak nie (alles word deur 'n gewone vullisverwyderaar gedoen).

Hierdie benadering beperk ontwikkeling egter grootliks en is selde van toepassing op moderne GI/CD-projekte. 'n Integrale deel van die ontwikkeling was outomatisering, wat jou toelaat om nuwe funksionaliteit baie vinniger te toets, te ontplooi en aan gebruikers te lewer. Byvoorbeeld, in al ons projekte word 'n CI-pyplyn outomaties met elke commit geskep. Daarin word die beeld saamgestel, getoets, uitgerol na verskeie Kubernetes-stroombane vir ontfouting en oorblywende kontroles, en as alles goed is, bereik die veranderinge die eindgebruiker. En dit is nie meer vuurpylwetenskap nie, maar 'n alledaagse gebeurtenis vir baie - heel waarskynlik vir jou, aangesien jy hierdie artikel lees.

Aangesien die regstelling van foute en die ontwikkeling van nuwe funksionaliteit parallel uitgevoer word, en vrystellings verskeie kere per dag uitgevoer kan word, is dit duidelik dat die ontwikkelingsproses gepaard gaan met 'n aansienlike aantal commits, wat beteken 'n groot aantal beelde in die register. As gevolg hiervan ontstaan die kwessie van die organisering van effektiewe skoonmaak van die register, d.w.s. verwydering van irrelevante beelde.

Maar hoe bepaal jy selfs of 'n beeld relevant is?

Kriteria vir die relevansie van die beeld

In die oorgrote meerderheid van gevalle sal die hoofkriteria wees:

1. Die eerste (die mees voor die hand liggende en mees kritiese van almal) is die beelde wat word tans in Kubernetes gebruik. Die verwydering van hierdie beelde kan aansienlike produksie-stilstandkoste tot gevolg hê (byvoorbeeld, die beelde kan nodig wees vir replikasie) of die pogings van die span wat op enige van die lusse ontfout, ontken. (Om hierdie rede het ons selfs 'n spesiale gemaak Prometheus uitvoerder, wat die afwesigheid van sulke beelde in enige Kubernetes-groep naspoor.)

2. Tweedens (minder voor die hand liggend, maar ook baie belangrik en hou weer verband met uitbuiting) - beelde wat vereis vir terugrol in geval van opsporing van ernstige probleme in die huidige weergawe. Byvoorbeeld, in die geval van Helm, is dit beelde wat in gestoorde weergawes van die vrystelling gebruik word. (Terloops, by verstek in Helm is die limiet 256 hersienings, maar dit is onwaarskynlik dat iemand regtig moet stoor so 'n 'n groot aantal weergawes?..) Ons stoor immers veral weergawes sodat ons dit later kan gebruik, m.a.w. "rol terug" na hulle indien nodig.

3. Derde - ontwikkelaar se behoeftes: Alle beelde wat verband hou met hul huidige werk. Byvoorbeeld, as ons PR oorweeg, dan maak dit sin om 'n beeld te laat wat ooreenstem met die laaste commit en, sê, die vorige commit: op hierdie manier kan die ontwikkelaar vinnig terugkeer na enige taak en met die nuutste veranderinge werk.

4. Vierde - beelde wat ooreenstem met die weergawes van ons aansoek, d.w.s. is die finale produk: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, ens.

NB: Die kriteria wat hier gedefinieer word, is geformuleer op grond van ervaring in interaksie met dosyne ontwikkelingspanne van verskillende maatskappye. Natuurlik, afhangende van die besonderhede in die ontwikkelingsprosesse en die infrastruktuur wat gebruik word (byvoorbeeld, Kubernetes word nie gebruik nie), kan hierdie kriteria verskil.

Geskiktheid en bestaande oplossings

Gewilde dienste met houerregisters bied as 'n reël hul eie beeldopruimingsbeleide: daarin kan u die voorwaardes definieer waaronder 'n merker uit die register verwyder word. Hierdie toestande word egter beperk deur parameters soos name, skeppingstyd en aantal merkers*.

* Hang af van spesifieke houerregister-implementerings. Ons het die moontlikhede van die volgende oplossings oorweeg: Azure CR, Docker Hub, ECR, GCR, GitHub-pakkette, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - vanaf September'2020.

Hierdie stel parameters is genoeg om aan die vierde kriterium te voldoen - dit wil sê om beelde te kies wat ooreenstem met die weergawes. Vir alle ander kriteria moet 'n mens egter 'n soort kompromie-oplossing kies ('n strenger of, omgekeerd, meer toegeeflike beleid) - afhangende van verwagtinge en finansiële vermoëns.

Die derde maatstaf - wat verband hou met die behoeftes van ontwikkelaars - kan byvoorbeeld opgelos word deur prosesse binne spanne te organiseer: spesifieke benoeming van beelde, die handhawing van spesiale toelaatlyste en interne ooreenkomste. Maar uiteindelik moet dit steeds geoutomatiseer word. En as die vermoëns van klaargemaakte oplossings nie genoeg is nie, moet jy iets van jou eie doen.

Die situasie met die eerste twee kriteria is soortgelyk: hulle kan nie bevredig word sonder om data van 'n eksterne stelsel te ontvang nie - die een waar toepassings ontplooi word (in ons geval, Kubernetes).

Illustrasie van werkvloei in Git

Kom ons sê jy werk so iets in Git:

Die ikoon met 'n kop in die diagram dui houerbeelde aan wat tans in Kubernetes vir enige gebruikers (eindgebruikers, toetsers, bestuurders, ens.) ontplooi word of deur ontwikkelaars vir ontfouting en soortgelyke doeleindes gebruik word.

Wat gebeur as opruimingsbeleide slegs toelaat dat prente behou word (nie uitgevee nie) deur gegewe merkername?

Uiteraard sal so 'n scenario niemand gelukkig maak nie.

Wat sal verander as beleide toelaat dat prente nie uitgevee word nie? volgens 'n gegewe tydinterval / aantal laaste commits?

Die resultaat het baie beter geword, maar is nog lank nie ideaal nie. Ons het immers steeds ontwikkelaars wat beelde in die register benodig (of selfs in K8's ontplooi word) om foute te ontfout ...

Om die huidige marksituasie op te som: die funksies wat in houerregisters beskikbaar is, bied nie genoeg buigsaamheid tydens skoonmaak nie, en die hoofrede hiervoor is geen manier om met die buitewêreld te kommunikeer nie. Dit blyk dat spanne wat sulke buigsaamheid benodig, gedwing word om die verwydering van beelde onafhanklik te implementeer "van buite", met behulp van die Docker Registry API (of die inheemse API van die ooreenstemmende implementering).

Ons was egter op soek na 'n universele oplossing wat beeldopruiming vir verskillende spanne sal outomatiseer deur verskillende registers te gebruik ...

Ons pad na universele beeldskoonmaak

Waar kom hierdie behoefte vandaan? Die feit is dat ons nie 'n aparte groep ontwikkelaars is nie, maar 'n span wat baie van hulle op een slag bedien, wat help om CI/CD-kwessies omvattend op te los. En die belangrikste tegniese hulpmiddel hiervoor is die Open Source-hulpmiddel werf. Die eienaardigheid daarvan is dat dit nie 'n enkele funksie verrig nie, maar deurlopende afleweringsprosesse in alle stadiums vergesel: van samestelling tot ontplooiing.

Om beelde na die register* te publiseer (onmiddellik nadat dit gebou is) is 'n ooglopende funksie van so 'n nutsprogram. En aangesien die beelde daar geplaas word vir berging, dan - as jou berging nie onbeperk is nie - moet jy verantwoordelik wees vir die daaropvolgende skoonmaak. Hoe ons hierin sukses behaal het, wat aan al die gespesifiseerde kriteria voldoen het, sal verder bespreek word.

* Alhoewel die registers self anders kan wees (Docker Registry, GitLab Container Registry, Harbor, ens.), ondervind hul gebruikers dieselfde probleme. Die universele oplossing in ons geval hang nie af van die implementering van die register nie, want loop buite die registers self en bied dieselfde gedrag vir almal.

Alhoewel ons werf as 'n voorbeeldimplementering gebruik, hoop ons dat die benaderings wat gebruik word, nuttig sal wees vir ander spanne wat met soortgelyke probleme te kampe het.

So ons het besig geraak ekstern implementering van 'n meganisme vir die skoonmaak van beelde - in plaas van daardie vermoëns wat reeds in die registers vir houers ingebou is. Die eerste stap was om die Docker Registry API te gebruik om dieselfde primitiewe beleide te skep vir die aantal etikette en die tyd van hul skepping (hierbo genoem). By hulle gevoeg laat lys toe gebaseer op beelde wat in ontplooide infrastruktuur gebruik word, d.w.s. Kubernetes. Vir laasgenoemde was dit genoeg om die Kubernetes API te gebruik om deur alle ontplooide hulpbronne te herhaal en 'n lys van waardes te kry image.

Hierdie onbenullige oplossing het die mees kritieke probleem opgelos (kriterium nr. 1), maar was slegs die begin van ons reis om die skoonmaakmeganisme te verbeter. Die volgende – en baie interessanter – stap was die besluit assosieer gepubliseerde beelde met Git-geskiedenis.

Merk skemas

Om mee te begin, het ons 'n benadering gekies waarin die finale beeld die nodige inligting vir skoonmaak moet stoor, en het die proses op merkskemas gebou. Wanneer 'n prent gepubliseer is, het die gebruiker 'n spesifieke merkopsie gekies (git-branch, git-commit of git-tag) en die ooreenstemmende waarde gebruik. In CI-stelsels is hierdie waardes outomaties ingestel op grond van omgewingsveranderlikes. In werklikheid die finale beeld was geassosieer met 'n spesifieke Git primitief, stoor die nodige data vir skoonmaak in etikette.

Hierdie benadering het gelei tot 'n stel beleide wat toegelaat het dat Git as die enkele bron van waarheid gebruik word:

Wanneer 'n tak/tag in Git uitgevee word, is die geassosieerde beelde in die register outomaties uitgevee.
Die aantal prente wat met Git-merkers en commits geassosieer word, kan beheer word deur die aantal etikette wat in die geselekteerde skema gebruik word en die tyd waarop die verwante commit geskep is.

Oor die algemeen het die gevolglike implementering ons behoeftes bevredig, maar 'n nuwe uitdaging het gou op ons gewag. Die feit is dat ons 'n aantal tekortkominge ondervind het terwyl ons merkskemas gebruik wat op Git-primitiewe gebaseer is. (Aangesien hul beskrywing buite die bestek van hierdie artikel is, kan almal hulself met die besonderhede vergewis hier.) Daarom, nadat ons besluit het om oor te skakel na 'n meer doeltreffende benadering tot merking (inhoud-gebaseerde tagging), moes ons die implementering van beeldskoonmaak heroorweeg.

Nuwe algoritme

Hoekom? Met inhoudgebaseerde etikettering kan elke merker aan verskeie commits in Git voldoen. Wanneer jy beelde skoonmaak, kan jy nie meer aanneem nie slegs vanaf die commit waar die nuwe merker by die register gevoeg is.

Vir die nuwe skoonmaakalgoritme is besluit om weg te beweeg van merkskemas en bou meta-beeld proses, wat elkeen 'n klomp van:

die commit waarop die publikasie uitgevoer is (dit maak nie saak of die beeld bygevoeg, verander of dieselfde gebly het in die houerregister nie);
en ons interne identifiseerder wat ooreenstem met die saamgestelde beeld.

Met ander woorde, dit is voorsien gekoppelde gepubliseerde etikette met commits in Git.

Finale konfigurasie en algemene algoritme

Wanneer skoonmaak gekonfigureer word, het gebruikers nou toegang tot beleide wat huidige beelde kies. Elke sodanige beleid word gedefinieer:

baie verwysings, m.a.w. Git-etikette of Git-takke wat tydens skandering gebruik word;
en die limiet van gesoekte beelde vir elke verwysing uit die stel.

Ter illustrasie, dit is hoe die verstekbeleidkonfigurasie begin lyk het:

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

Hierdie opstelling bevat drie beleide wat aan die volgende reëls voldoen:

Stoor die prent vir die laaste 10 Git-merkers (volgens merkerskeppingsdatum).
Stoor nie meer as 2 beelde wat in die afgelope week gepubliseer is vir nie meer as 10 drade met aktiwiteit in die afgelope week nie.
Stoor 10 beelde vir takke main, staging и production.

Die finale algoritme kom neer op die volgende stappe:

Haal tans manifeste uit die houerregister.
Uitgesluit beelde wat in Kubernetes gebruik word, want Ons het hulle reeds vooraf gekies deur die K8s API te stem.
Skandeer Git-geskiedenis en sluit beelde uit gebaseer op gespesifiseerde beleide.
Verwyder tans oorblywende beelde.

Om terug te keer na ons illustrasie, dit is wat met werf gebeur:

Selfs al gebruik jy egter nie werf nie, kan 'n soortgelyke benadering tot gevorderde beeldskoonmaak - in een of ander implementering (volgens die voorkeurbenadering tot beeldmerking) - op ander stelsels/hulpprogramme toegepas word. Om dit te doen, is dit genoeg om die probleme wat ontstaan te onthou en daardie geleenthede in jou stapel te vind wat jou toelaat om hul oplossing so glad moontlik te integreer. Ons hoop dat die pad wat ons geloop het jou sal help om met nuwe besonderhede en gedagtes na jou spesifieke saak te kyk.

Gevolgtrekking

Vroeër of later ondervind die meeste spanne die probleem van registeroorloop.
As u na oplossings soek, is dit eers nodig om die kriteria vir die relevansie van die beeld te bepaal.
Die gereedskap wat deur gewilde houerregisterdienste aangebied word, laat jou toe om 'n baie eenvoudige opruiming te organiseer wat nie die "buitewêreld" in ag neem nie: die beelde wat in Kubernetes gebruik word en die eienaardighede van die span se werkstrome.
'n Buigsame en doeltreffende algoritme moet 'n begrip hê van CI/CD-prosesse en nie net met Docker-beelddata werk nie.

Die probleem van "slim" skoonmaak van houerbeelde en die oplossing daarvan in werf