La artikolo diskutas la problemojn de purigado de bildoj, kiuj amasiĝas en kontenaj registroj (Docker Registry kaj ĝiaj analogoj) en la realaĵoj de modernaj CI/CD-duktoj por nubaj denaskaj aplikoj liveritaj al Kubernetes. La ĉefaj kriterioj por la graveco de bildoj kaj la rezultaj malfacilaĵoj por aŭtomatigi purigadon, ŝpari spacon kaj renkonti la bezonojn de teamoj estas donitaj. Fine, uzante la ekzemplon de specifa Open Source projekto, ni rakontos al vi kiel ĉi tiuj malfacilaĵoj povas esti venkitaj.
Enkonduko
La nombro da bildoj en ujo-registro povas kreski rapide, okupante pli da stoka spaco kaj tiel signife pliigante ĝian koston. Por kontroli, limigi aŭ konservi akcepteblan kreskon de spaco okupita en la registro, ĝi estas akceptita:
- uzu fiksan nombron da etikedoj por bildoj;
- purigu la bildojn iel.
La unua limigo foje estas akceptebla por malgrandaj teamoj. Se programistoj havas sufiĉe da permanentaj etikedoj (latest, main, test, boris ktp.), la registro ne ŝveliĝos kaj dum longa tempo vi tute ne devos pensi pri purigado de ĝi. Post ĉio, ĉiuj sensignivaj bildoj estas forigitaj, kaj simple restas neniu laboro por purigado (ĉio estas farita de regula rubkolektisto).
Tamen, tiu aliro multe limigas evoluon kaj malofte estas uzebla al modernaj CI/CD-projektoj. Integra parto de la evoluo estis aŭtomatigo, kiu permesas vin testi, deploji kaj liveri novajn funkciojn al uzantoj multe pli rapide. Ekzemple, en ĉiuj niaj projektoj, CI-dukto estas aŭtomate kreita kun ĉiu kommit. En ĝi, la bildo estas kunvenita, provita, disvastigita al diversaj Kubernetes-cirkvitoj por elpurigado kaj ceteraj kontroloj, kaj se ĉio estas bona, la ŝanĝoj atingas la finuzanton. Kaj ĉi tio ne plu estas raketscienco, sed ĉiutaga okazo por multaj - plej verŝajne por vi, ĉar vi legas ĉi tiun artikolon.
Ĉar ripari erarojn kaj disvolvi novajn funkciojn okazas paralele, kaj eldonoj povas esti faritaj plurfoje tage, estas evidente, ke la disvolva procezo estas akompanata de signifa nombro da komitoj, kio signifas. granda nombro da bildoj en la registro. Kiel rezulto, la temo organizi efikan purigadon de la registro ekestas, t.e. forigante palajn bildojn.
Sed kiel vi eĉ determinas ĉu bildo estas grava?
Kriterioj por la graveco de la bildo
En la granda plimulto de kazoj, la ĉefaj kriterioj estos:
1. La unua (la plej evidenta kaj plej kritika el ĉiuj) estas la bildoj kiuj nuntempe uzata en Kubernetes. Forigi ĉi tiujn bildojn povas rezultigi signifajn produktajn malfunkciajn kostojn (ekzemple, la bildoj povas esti postulataj por reproduktado) aŭ neas la klopodojn de la teamo senarariganta sur iu el la bukloj. (Tial ni eĉ faris specialaĵon , kiu spuras la foreston de tiaj bildoj en iu ajn Kubernetes-areto.)
2. Due (malpli evidenta, sed ankaŭ tre grava kaj denove rilatas al ekspluatado) - bildoj kiuj bezonata por retroigo en kazo de detekto de gravaj problemoj en la nuna versio. Ekzemple, en la kazo de Helm, ĉi tiuj estas bildoj, kiuj estas uzataj en konservitaj versioj de la eldono. (Cetere, defaŭlte en Helm la limo estas 256 revizioj, sed estas neverŝajne ke iu vere bezonas konservi tia granda nombro da versioj?..) Finfine ni precipe konservas versiojn, por ke ni povu uzi ilin poste, t.e. "reiru" al ili se necese.
3. Tria - bezonoj de programistoj: Ĉiuj bildoj kiuj rilatas al ilia nuna laboro. Ekzemple, se ni konsideras PR, tiam havas sencon lasi bildon respondan al la lasta kompromiso kaj, ekzemple, la antaŭa kompromiso: tiamaniere la programisto povas rapide reveni al ajna tasko kaj labori kun la lastaj ŝanĝoj.
4. Kvara - bildoj kiuj respondas al la versioj de nia aplikaĵo, t.e. estas la fina produkto: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, ktp.
NB: La kriterioj ĉi tie difinitaj estis formulitaj surbaze de sperto interaganta kun dekoj da evoluigaj teamoj de malsamaj kompanioj. Tamen, kompreneble, depende de la specifaĵoj en la evoluprocezoj kaj la infrastrukturo uzata (ekzemple Kubernetes ne estas uzata), ĉi tiuj kriterioj povas malsami.
Kvalifiko kaj ekzistantaj solvoj
Popularaj servoj kun kontenaj registroj, kiel regulo, ofertas siajn proprajn bildpurigajn politikojn: en ili vi povas difini la kondiĉojn sub kiuj etikedo estas forigita de la registro. Tamen ĉi tiuj kondiĉoj estas limigitaj de parametroj kiel nomoj, krea tempo kaj nombro da etikedoj*.
* Dependas de specifaj ujregistraj efektivigoj. Ni konsideris la eblecojn de la sekvaj solvoj: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - ekde septembro 2020.
Ĉi tiu aro da parametroj sufiĉas por kontentigi la kvaran kriterion - tio estas, elekti bildojn, kiuj respondas al la versioj. Tamen, por ĉiuj aliaj kriterioj, oni devas elekti ian kompromisan solvon (pli malmola aŭ, male, pli milda politiko) - depende de atendoj kaj financaj kapabloj.
Ekzemple, la tria kriterio - rilata al la bezonoj de programistoj - povas esti solvita organizante procezojn ene de teamoj: specifa nomado de bildoj, konservado de specialaj permesilistoj kaj internaj interkonsentoj. Sed finfine ĝi ankoraŭ bezonas esti aŭtomatigita. Kaj se la kapabloj de pretaj solvoj ne sufiĉas, vi devas fari ion propran.
La situacio kun la unuaj du kriterioj estas simila: ili ne povas esti kontentigitaj sen ricevi datumojn de ekstera sistemo - tiu, kie aplikaĵoj estas deplojitaj (en nia kazo, Kubernetes).
Ilustraĵo de laborfluo en Git
Ni diru, ke vi laboras ion tian en Git:
La ikono kun kapo en la diagramo indikas ujajn bildojn, kiuj estas nuntempe disfalditaj en Kubernetes por iuj uzantoj (finuzantoj, testistoj, administrantoj, ktp.) aŭ estas uzataj de programistoj por sencimigado kaj similaj celoj.
Kio okazas se purigaj politikoj nur permesas konservi bildojn (ne forigitaj) per donitaj etikednomoj?
Evidente, tia scenaro ne feliĉigos iun ajn.
Kio ŝanĝiĝos se politikoj permesas ne forigi bildojn? laŭ donita tempintervalo / nombro da lastaj komitaĵoj?
La rezulto fariĝis multe pli bona, sed ankoraŭ estas malproksima de ideala. Post ĉio, ni ankoraŭ havas programistojn, kiuj bezonas bildojn en la registro (aŭ eĉ deplojitaj en K8s) por sencimigi cimojn...
Por resumi la nunan merkatan situacion: la funkcioj disponeblaj en kontenaj registroj ne ofertas sufiĉe da fleksebleco dum purigado, kaj la ĉefa kialo por tio estas neniu maniero interagi kun la ekstera mondo. Rezultas, ke teamoj, kiuj postulas tian flekseblecon, estas devigitaj sendepende efektivigi forigon de bildoj "de ekstere", uzante la Docker Registry API (aŭ la indiĝenan API de la responda efektivigo).
Tamen, ni serĉis universalan solvon, kiu aŭtomatigus bildopurigon por malsamaj teamoj uzante malsamajn registrojn...
Nia vojo al universala bildpurigado
De kie venas ĉi tiu bezono? La fakto estas, ke ni ne estas aparta grupo de programistoj, sed teamo, kiu servas multajn el ili samtempe, helpante amplekse solvi CI/CD-problemojn. Kaj la ĉefa teknika ilo por ĉi tio estas la Malfermfonta ilo . Ĝia propreco estas, ke ĝi ne plenumas unu solan funkcion, sed akompanas kontinuajn liverajn procezojn en ĉiuj stadioj: de muntado ĝis disfaldo.
Eldoni bildojn al la registro* (tuj post kiam ili estas konstruitaj) estas evidenta funkcio de tia ilo. Kaj ĉar la bildoj estas metitaj tie por stokado, tiam - se via konservado ne estas senlima - vi devas esti respondeca pri ilia posta purigado. Kiel ni atingis sukceson en ĉi tio, kontentigante ĉiujn specifitajn kriteriojn, estos diskutita plu.
* Kvankam la registroj mem povas esti malsamaj (Docker Registry, GitLab Container Registry, Harbour, ktp.), iliaj uzantoj alfrontas la samajn problemojn. La universala solvo en nia kazo ne dependas de la efektivigo de la registro, ĉar funkcias ekster la registroj mem kaj ofertas la saman konduton por ĉiuj.
Kvankam ni uzas werf kiel ekzempla efektivigo, ni esperas, ke la uzataj aliroj estos utilaj al aliaj teamoj alfrontitaj kun similaj malfacilaĵoj.
Do ni okupiĝis ekstera efektivigo de mekanismo por purigado de bildoj - anstataŭ tiuj kapabloj kiuj jam estas konstruitaj en registroj por ujoj. La unua paŝo estis uzi la Docker Registry API por krei la samajn primitivajn politikojn por la nombro da etikedoj kaj la tempo de ilia kreado (menciite supre). Aldonita al ili permesi liston bazitan sur bildoj uzitaj en deplojita infrastrukturo, t.e. Kubernetes. Por ĉi-lasta, sufiĉis uzi la Kubernetes API por ripeti ĉiujn disfalditajn rimedojn kaj akiri liston de valoroj. image.
Ĉi tiu bagatela solvo solvis la plej kritikan problemon (kriterio n-ro 1), sed estis nur la komenco de nia vojaĝo por plibonigi la purigan mekanismon. La sekva – kaj multe pli interesa – paŝo estis la decido asocii publikigitajn bildojn kun Git-historio.
Skemoj de etikedado
Komence, ni elektis aliron en kiu la fina bildo devus konservi la necesajn informojn por purigado, kaj konstruis la procezon sur etikedskemoj. Dum publikigado de bildo, la uzanto elektis specifan etikedopcion (git-branch, git-commit aŭ git-tag) kaj uzis la respondan valoron. En CI-sistemoj, ĉi tiuj valoroj estis aŭtomate fiksitaj surbaze de mediaj variabloj. Fakte la fina bildo estis asociita kun specifa Git-primitivo, konservante la necesajn datumojn por purigado en etikedoj.
Tiu aliro rezultigis aron de politikoj kiuj permesis al Git esti utiligita kiel la ununura fonto de vero:
- Dum forigo de branĉo/etikedo en Git, la rilataj bildoj en la registro estis aŭtomate forigitaj.
- La nombro da bildoj asociitaj kun Git-etikedoj kaj kommits povus esti kontrolita per la nombro da etikedoj uzataj en la elektita skemo kaj la tempo kiam la rilata kommit estis kreita.
Entute, la rezulta efektivigo kontentigis niajn bezonojn, sed nova defio baldaŭ atendis nin. La fakto estas, ke dum uzado de etikedskemoj bazitaj sur Git-primitivoj, ni renkontis kelkajn mankojn. (Ĉar ilia priskribo estas ekster la amplekso de ĉi tiu artikolo, ĉiuj povas konatiĝi kun la detaloj .) Tial, decidinte ŝanĝi al pli efika aliro al etikedado (enhav-bazita etikedado), ni devis rekonsideri la efektivigon de bildpurigado.
Nova algoritmo
Kial? Kun enhav-bazita etikedado, ĉiu etikedo povas kontentigi plurajn kommitaĵojn en Git. Purigante bildojn, vi ne plu povas supozi nur de la kommit kie la nova etikedo estis aldonita al la registro.
Por la nova puriga algoritmo, estis decidite malproksimigi de etikedskemoj kaj konstrui meta-bilda procezo, ĉiu el kiuj stokas amason da:
- la devo sur kiu la publikigo estis farita (ne gravas ĉu la bildo estis aldonita, ŝanĝita aŭ restis sama en la ujo-registro);
- kaj nia interna identigilo responda al la kunmetita bildo.
Alivorte, ĝi estis provizita ligante publikigitajn etikedojn kun kommits en Git.
Fina agordo kaj ĝenerala algoritmo
Kiam oni agordas purigadon, uzantoj nun havas aliron al politikoj, kiuj elektas aktualajn bildojn. Ĉiu tia politiko estas difinita:
- multaj referencoj, t.e. Git-etikedoj aŭ Git-branĉoj kiuj estas uzataj dum skanado;
- kaj la limo de serĉitaj bildoj por ĉiu referenco de la aro.
Por ilustri, jen kiel la defaŭlta politika agordo komencis aspekti:
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
Ĉi tiu agordo enhavas tri politikojn, kiuj konformas al la sekvaj reguloj:
- Konservu la bildon por la lastaj 10 Git-etikedoj (laŭ etiked-kreaddato).
- Konservu ne pli ol 2 bildojn publikigitajn en la lasta semajno por ne pli ol 10 fadenoj kun agado en la lasta semajno.
- Konservu 10 bildojn por branĉoj
main,stagingиproduction.
La fina algoritmo resumas al la sekvaj paŝoj:
- Prenante manifestojn de kontenera registro.
- Ekskludante bildojn uzatajn en Kubernetes, ĉar Ni jam antaŭselektis ilin per sondado de la K8s API.
- Skanante Git-historion kaj ekskludante bildojn laŭ specifitaj politikoj.
- Forigante ceterajn bildojn.
Revenante al nia ilustraĵo, jen kio okazas kun werf:
Tamen, eĉ se vi ne uzas werf, simila aliro al altnivela purigado de bildoj - en unu efektivigo aŭ alia (laŭ la preferata aliro al bilda markado) - povas esti aplikata al aliaj sistemoj/utiloj. Por fari tion, sufiĉas memori la problemojn kiuj ŝprucas kaj trovi tiujn ŝancojn en via stako, kiuj ebligas al vi integri ilian solvon kiel eble plej glate. Ni esperas, ke la vojo, kiun ni vojaĝis, helpos vin rigardi vian apartan kazon kun novaj detaloj kaj pensoj.
konkludo
- Pli aŭ malpli frue, plej multaj teamoj renkontas la problemon de registra superfluo.
- Serĉante solvojn, unue necesas determini la kriteriojn por la graveco de la bildo.
- La iloj ofertitaj de popularaj ujregistraj servoj permesas al vi organizi tre simplan purigadon, kiu ne konsideras la "ekstera mondo": la bildoj uzataj en Kubernetes kaj la proprecoj de la laborfluoj de la teamo.
- Fleksebla kaj efika algoritmo devas havi komprenon pri CI/KD-procezoj kaj funkcii ne nur kun bildaj datumoj de Docker.
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com