De Problem vun der "Smart" Botzen vun Container Biller a seng Léisung an werf

Den Artikel diskutéiert d'Problemer fir d'Biller ze botzen, déi an de Containerregistren accumuléieren (Docker Registry a seng Analoga) an de Realitéite vu modernen CI / CD Pipelines fir Cloud-native Applikatiounen, déi op Kubernetes geliwwert ginn. D'Haaptcritèrë fir d'Relevanz vu Biller an déi resultéierend Schwieregkeete bei der Automatiséierung vun der Botzen, der Plaz spueren an d'Bedierfnesser vun den Équipen entspriechen. Endlech, andeems Dir d'Beispill vun engem spezifesche Open Source Projet benotzt, wäerte mir Iech soen wéi dës Schwieregkeeten iwwerwonne kënne ginn.

Aféierung

D'Zuel vun de Biller an engem Container Registry ka séier wuessen, méi Späicherplatz ophuelen an domat d'Käschte wesentlech erhéijen. Fir e akzeptable Wuesstum vum Raum am Registry ze kontrolléieren, ze limitéieren oder z'erhalen, gëtt et ugeholl:

1. benotzen eng fix Zuel vun Tags fir Biller;
2. botzen d'Biller iergendwéi.

Déi éischt Limitatioun ass heiansdo akzeptabel fir kleng Équipen. Wann d'Entwéckler genuch permanent Tags hunn (latest, main, test, boris etc.), wäert de Registry net an der Gréisst schwellen a fir eng laang Zäit musst Dir guer net iwwer d'Botzen denken. No allem ginn all irrelevant Biller geläscht, an et gëtt einfach keng Aarbecht fir d'Botzen (alles gëtt vun engem normale Müllsammler gemaach).

Wéi och ëmmer, dës Approche limitéiert d'Entwécklung staark an ass selten applicabel fir modern CI / CD Projeten. En integralen Deel vun der Entwécklung war Automatiséierung, wat Iech erlaabt Iech nei Funktionalitéit fir Benotzer vill méi séier ze testen, z'installéieren an ze liwweren. Zum Beispill, an all eise Projete gëtt eng CI Pipeline automatesch mat all Engagement erstallt. An et gëtt d'Bild gesammelt, getest, a verschidde Kubernetes Circuits ausgerullt fir Debugging a verbleiwen Kontrollen, a wann alles gutt ass, erreechen d'Ännerungen den Endbenotzer. An dëst ass net méi Rakéitewëssenschaft, mee en alldeeglechen Optriede fir vill - héchstwahrscheinlech fir Iech, well Dir dësen Artikel liest.

Zënter der Fixéierung vu Bugs an der Entwécklung vun neier Funktionalitéit parallel duerchgefouert gëtt, a Verëffentlechunge kënnen e puer Mol am Dag duerchgefouert ginn, ass et evident datt den Entwécklungsprozess vun enger bedeitender Unzuel vu Verpflichtungen begleet gëtt, dat heescht eng grouss Zuel vu Biller am Registry. Als Resultat entsteet d'Thema vun der Organisatioun vun der effektiver Botzen vum Registry, d.h. irrelevant Biller ewechhuelen.

Awer wéi bestëmmt Dir iwwerhaapt ob e Bild relevant ass?

Critèrë fir d'Relevanz vum Bild

An der grousser Majoritéit vu Fäll sinn d'Haaptkriterien:

1. Déi éischt (déi offensichtlechst a kriteschst vun allem) sinn d'Biller déi aktuell an Kubernetes benotzt. D'Ewechhuele vun dëse Biller kann zu bedeitende Produktiounsstoppkäschte resultéieren (zum Beispill d'Biller kënne fir Replikatioun erfuerderlech sinn) oder d'Efforte vum Team debugging op eng vun de Schleifen negéieren. (Aus dësem Grond hu mir souguer eng speziell gemaach Prometheus Exportateur, déi d'Feele vu sou Biller an all Kubernetes Cluster verfollegt.)

2. Zweetens (manner offensichtlech, awer och ganz wichteg an nees op Ausbeutung bezunn) - Biller déi erfuerderlech fir Réckroll am Fall vun der Detektioun vu schlëmme Probleemer an der aktueller Versioun. Zum Beispill, am Fall vun Helm, sinn dës Biller déi a gespäichert Versioune vun der Verëffentlechung benotzt ginn. (Iwwregens, Par défaut am Helm ass d'Limite 256 Versiounen, awer et ass onwahrscheinlech datt iergendeen wierklech muss späicheren esou eng grouss Unzuel u Versiounen?..) Schliisslech späichere mir virun allem Versioune fir datt mir se spéider benotze kënnen, d.h. "Roll zréck" hinnen wann néideg.

3. Drëtten - Entwéckler brauch: All Biller déi mat hirer aktueller Aarbecht verbonne sinn. Zum Beispill, wa mir e PR berücksichtegen, dann ass et Sënn fir e Bild ze verloossen, deen dem leschte Verpflichtung entsprécht an, sot, de fréiere Verpflichtung: sou kann den Entwéckler séier op all Aufgab zréckkommen a mat de leschten Ännerungen schaffen.

4. Véiert - Biller déi entspriechen de Versioune vun eiser Applikatioun, d.h. sinn d'Finale Produit: v1.0.0, 20.04.01/XNUMX/XNUMX, Sierra, etc.

NB: D'Critèrë, déi hei definéiert sinn, goufen formuléiert op Basis vun der Erfahrung, déi mat Dosende vun Entwécklungsteams aus verschiddene Firmen interagéiert. Wéi och ëmmer, ofhängeg vun de Spezifizitéiten an den Entwécklungsprozesser an der benotzter Infrastruktur (zum Beispill Kubernetes gëtt net benotzt), kënnen dës Critèren ënnerscheeden.

Usproch a bestehend Léisungen

Populär Servicer mat Containerregistrierungen bidden als Regel hir eege Bildreinigungspolitik: an hinnen kënnt Dir d'Konditiounen definéieren, ënner deenen e Tag aus dem Registry geläscht gëtt. Wéi och ëmmer, dës Konditioune si limitéiert duerch Parameteren wéi Nimm, Kreatiounszäit an Zuel vun den Tags *.

* Hänkt vu spezifesche Containerregistrierungsimplementatiounen of. Mir hunn d'Méiglechkeete vun de folgende Léisunge betruecht: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - ab September'2020.

Dëse Set vu Parameteren ass genuch fir de véierte Critère ze erfëllen - dat ass, Biller ze wielen déi mat de Versiounen entspriechen. Fir all aner Kritäre muss een awer eng Aart vu Kompromëssléisung wielen (eng méi haart oder ëmgedréint méi mëll Politik) - jee no Erwaardungen a finanzielle Fäegkeeten.

Zum Beispill kann den drëtte Critère - am Zesummenhang mat de Bedierfnesser vun den Entwéckler - geléist ginn andeems Prozesser bannent Teams organiséiert ginn: spezifesch Benennung vu Biller, Erhalen vun speziellen Erlaabneslëschten an internen Ofkommes. Awer schlussendlech muss et nach automatiséiert ginn. A wann d'Kapazitéite vu fäerdege Léisungen net genuch sinn, musst Dir eppes selwer maachen.

D'Situatioun mat den éischten zwee Critèren ass ähnlech: si kënnen net zefridde ginn ouni Daten aus engem externen System ze kréien - deen wou Uwendungen ofgebaut ginn (an eisem Fall Kubernetes).

Illustratioun vum Workflow am Git

Loosst eis soen datt Dir eppes wéi dëst am Git schafft:

D'Ikon mat engem Kapp am Diagramm weist Containerbiller un, déi momentan an Kubernetes fir all Benotzer (Ennbenotzer, Tester, Manager, etc.) agesat ginn oder vun Entwéckler fir Debugging an ähnlech Zwecker benotzt ginn.

Wat geschitt wann d'Botzpolitik nëmme Biller erlaabt ze behalen (net geläscht) duerch uginn Tag Nimm?

Natierlech wäert esou en Szenario kee glécklech maachen.

Wat ännert sech wann d'Politik erlaabt datt Biller net geläscht ginn? no engem bestëmmten Zäitintervall / Zuel vun de leschte Verpflichtungen?

D'Resultat ass vill besser ginn, awer ass nach wäit vun ideal. Iwwerhaapt hu mir nach ëmmer Entwéckler déi Biller an der Registry brauchen (oder souguer a K8s ofgesat) fir Bugs ze debuggen ...

Fir déi aktuell Maartsituatioun ze resuméieren: d'Funktiounen, déi an de Containerregistre verfügbar sinn, bidden net genuch Flexibilitéit beim Botzen, an den Haaptgrond dofir ass kee Wee fir mat der Äussewelt ze interagéieren. Et stellt sech eraus datt Teams, déi sou Flexibilitéit erfuerderen, gezwongen sinn onofhängeg Bildläsche "vu baussen" ëmzesetzen, mat der Docker Registry API (oder déi gebierteg API vun der entspriechender Implementatioun).

Wéi och ëmmer, mir hunn no enger universeller Léisung gesicht déi d'Bildreinigung fir verschidden Teams automatiséiert mat verschiddene Registratiounen ...

Eise Wee fir eng universell Bildreinigung

Wou kënnt dëse Besoin hier? D'Tatsaach ass, datt mir net eng separat Grupp vun Entwéckler sinn, mä eng Equipe, déi vill vun hinnen op eemol déngt, hëlleft eng ëmfaassend léisen CI / CD Problemer. An dat Haapttechnescht Tool fir dëst ass den Open Source Utility werf. Seng Besonneschheet ass datt et net eng eenzeg Funktioun mécht, awer kontinuéierlech Liwwerprozesser op allen Etappe begleet: vun der Assemblée bis zur Deployment.

D'Verëffentlechung vun Biller an de Registry* (direkt nodeems se gebaut sinn) ass eng offensichtlech Funktioun vun esou engem Utility. A well d'Biller do fir d'Späichere plazéiert sinn, dann - wann Är Späichere net onlimitéiert ass - Dir musst verantwortlech sinn fir hir spéider Botzen. Wéi mir an dësem Erfolleg erreecht hunn, all déi spezifizéiert Critèren ze erfëllen, wäert weider diskutéiert ginn.

* Och wann d'Registrierunge selwer anescht kënne sinn (Docker Registry, GitLab Container Registry, Harbor, etc.), hunn hir Benotzer déiselwecht Probleemer. Déi universell Léisung an eisem Fall hänkt net vun der Ëmsetzung vum Registry of, well leeft ausserhalb vun de Registere selwer a bitt datselwecht Verhalen fir jiddereen.

Och wa mir werf als Beispillimplementatioun benotzen, hoffen mir datt d'Approche benotzt wäerte nëtzlech sinn fir aner Teams mat ähnlechen Schwieregkeeten.

Also hu mir beschäftegt extern Ëmsetzung vun engem Mechanismus fir Biller ze botzen - amplaz vun deene Fäegkeeten, déi scho a Registry fir Container gebaut sinn. Den éischte Schrëtt war d'Docker Registry API ze benotzen fir déiselwecht primitiv Politik fir d'Zuel vun den Tags an d'Zäit vun hirer Schafung ze kreéieren (uewen erwähnt). Zu hinnen dobäigesat Erlaabt Lëscht baséiert op Biller déi an der ofgebauter Infrastruktur benotzt ginn, d.h. Kubernetes. Fir déi lescht war et genuch fir de Kubernetes API ze benotzen fir duerch all ofgebaute Ressourcen ze iteréieren an eng Lëscht vu Wäerter ze kréien image.

Dës trivial Léisung huet de kriteschen Problem geléist (Critère Nr. 1), awer war nëmmen den Ufank vun eiser Rees fir de Botzenmechanismus ze verbesseren. Den nächsten - a vill méi interessanten - Schrëtt war d'Entscheedung publizéiert Biller mat Git Geschicht assoziéiert.

Tagging Scheme

Fir unzefänken, hu mir eng Approche gewielt, an där d'Finale Bild déi néideg Informatioun fir d'Botzen späichere soll, an de Prozess op Tagging Schemaen opgebaut hunn. Beim Verëffentlechung vun engem Bild huet de Benotzer eng spezifesch Taggingoptioun gewielt (git-branch, git-commit oder git-tag) a benotzt den entspriechende Wäert. An CI Systemer goufen dës Wäerter automatesch op Basis vun Ëmfeldvariablen gesat. Tatsächlech d'Finale Bild war mat engem spezifeschen Git primitiv assoziéiert, déi néideg Donnéeën fir d'Botzen an Etiketten ze späicheren.

Dës Approche huet zu enger Rei vu Politiken gefouert, déi Git erlaabt als eenzeg Quell vun der Wourecht ze benotzen:

• Wann Dir eng Branche / Tag am Git geläscht hutt, goufen déi assoziéiert Biller am Registry automatesch geläscht.
• D'Zuel vun de Biller, déi mat Git Tags a Verpflichtungen assoziéiert sinn, kéinte kontrolléiert ginn duerch d'Zuel vun den Tags, déi am gewielte Schema benotzt ginn, an d'Zäit wou de verbonne Verpflichtung erstallt gouf.

Insgesamt huet déi resultéierend Ëmsetzung eis Bedierfnesser zefridden, awer eng nei Erausfuerderung huet eis geschwënn gewaart. D'Tatsaach ass datt wärend mir Tagging Schemae benotzt baséiert op Git Primitiven, mir op eng Rei Mängel begéint sinn. (Well hir Beschreiwung iwwer den Ëmfang vun dësem Artikel ass, kann jiddereen sech mat den Detailer vertraut maachen hei.) Dofir, nodeems mir decidéiert hunn op eng méi effizient Approche fir d'Tagging ze wiesselen (Inhaltsbaséiert Tagging), hu mir d'Ëmsetzung vun der Bildreinigung iwwerpréift.

Neien Algorithmus

Firwat? Mat Inhalt-baséiert Tagging kann all Tag verschidde Verpflichtungen am Git zefridden stellen. Wann Dir Biller botzt, kënnt Dir net méi unhuelen nëmmen aus dem Engagement wou den neien Tag an de Registry bäigefüügt gouf.

Fir den neie Botzalgorithmus gouf décidéiert fir vun Tagging Schemaen ewech ze goen an ze bauen Meta-Bild Prozess, jidderee späichert eng Rëtsch vun:

• d'Verpflichtung, op där d'Publikatioun gemaach gouf (et ass egal ob d'Bild dobäigesat, geännert oder d'selwecht bliwwen ass am Containerregister);
• an eisen internen Identifizéierer entsprécht dem gesammelt Bild.

An anere Wierder, et gouf virgesinn publizéiert Tags mat Verpflichtungen am Git verbannen.

Finale Konfiguratioun an allgemeng Algorithmus

Wann Dir Botzen konfiguréieren, hunn d'Benotzer elo Zougang zu Politiken déi aktuell Biller auswielen. All esou Politik ass definéiert:

• vill Referenzen, d.h. Git Tags oder Git Branchen déi beim Scannen benotzt ginn;
• an d'Limite vu gesichte Biller fir all Referenz aus dem Set.

Fir ze illustréieren, ass dëst wéi d'Standardpolitikkonfiguratioun ugefaang huet ze kucken:

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

Dës Konfiguratioun enthält dräi Politiken déi mat de folgende Reegele entspriechen:

1. Späichert d'Bild fir déi lescht 10 Git Tags (vum Tag Erstellungsdatum).
2. Späichert net méi wéi 2 Biller déi an der leschter Woch publizéiert goufen fir net méi wéi 10 Threads mat Aktivitéit an der leschter Woch.
3. Späichert 10 Biller fir Branchen main, staging и production.

De finalen Algorithmus kacht op déi folgend Schrëtt:

• Recuperéieren Manifestatiounen aus Container Registry.
• Auszeschléissen Biller an Kubernetes benotzt, well Mir hunn se scho virausgewielt andeems Dir de K8s API polling.
• Scannen Git Geschicht an ausgeschloss Biller baséiert op spezifizéierte Politiken.
• Ewechzehuelen verbleiwen Biller.

Zréck op eis Illustratioun, dat ass wat geschitt mat werf:

Wéi och ëmmer, och wann Dir net werf benotzt, kann eng ähnlech Approche fir fortgeschratt Bildreinigung - an enger Ëmsetzung oder aner (no der bevorzugter Approche fir Bildtagging) - op aner Systemer / Utilities applizéiert ginn. Fir dëst ze maachen, ass et genuch fir d'Problemer ze erënneren déi entstinn an déi Méiglechkeeten an Ärem Stack ze fannen, déi Iech erlaben hir Léisung sou glat wéi méiglech z'integréieren. Mir hoffen, datt de Wee, dee mir gereest hunn, Iech hëllefe fir Äre spezifesche Fall mat neien Detailer a Gedanken ze kucken.

Konklusioun

• Fréier oder spéider begéinen déi meescht Teams de Problem vum Registry-Iwwerfluss.
• Wann Dir no Léisungen sicht, ass et als éischt néideg fir d'Critèrë fir d'Relevanz vum Bild ze bestëmmen.
• D'Tools, déi vu populäre Containerregistrierungsservicer ugebuede ginn, erlaaben Iech e ganz einfache Botzen ze organiséieren, deen net d'"Äussewelt" berücksichtegt: d'Biller, déi a Kubernetes benotzt ginn an d'Besonderheet vun de Workflows vum Team.
• E flexibelen an effizienten Algorithmus muss e Verständnis vu CI / CD Prozesser hunn an net nëmme mat Docker Bilddaten funktionnéieren.

PS

Liest och op eisem Blog:

• «Inhaltsbaséiert Tagging am werf Sammler: firwat a wéi funktionnéiert et?";
• «3-Wee Fusioun op werf: Ofbau op Kubernetes mam Helm "op Steroiden"";
• «Ënnerstëtzung fir Monorepo a Multirepo op werf a wat huet den Docker Registry domat ze dinn";
• «werf 1.1 Verëffentlechung: Verbesserunge vum Builder haut a Pläng fir d'Zukunft".

Source: will.com