L'articulu discute i prublemi di a pulizia di l'imaghjini chì s'acumulanu in i registri di cuntenituri (Registru Docker è i so analoghi) in a realità di i pipeline CI / CD muderni per l'applicazioni native di nuvola consegnate à Kubernetes. I criterii principali per a pertinenza di l'imaghjini è e difficultà resultanti in l'automatizazione di a pulizia, di risparmià spaziu è di risponde à i bisogni di e squadre sò datu. Infine, usendu l'esempiu di un prughjettu Open Source specificu, vi diceremu cumu si ponu esse superati sti difficultà.
Introduzione
U numaru d'imaghjini in un registru di cuntainer pò cresce rapidamente, pigghiannu più spaziu di almacenamiento è cusì aumentendu significativamente u so costu. Per cuntrullà, limità o mantene a crescita accettabile di u spaziu occupatu in u registru, hè accettatu:
- aduprà un numeru fissu di tags per l'imaghjini;
- pulisce l'imaghjini in qualchì modu.
A prima limitazione hè qualchì volta accettata per i picculi squadre. Se i sviluppatori anu abbastanza tag permanenti (latest, main, test, boris etc.), u registru ùn stende micca in grandezza è per un bellu pezzu ùn avete micca bisognu di pensà à pulizziari. Dopu tuttu, tutte l'imaghjini irrilevanti sò sguassati, è ùn ci hè simplicemente micca travagliu per a pulizia (tuttu hè fattu da un cullettore di basura regulare).
Tuttavia, stu approcciu limita assai u sviluppu è hè raramente applicabile à i prughjetti moderni di CI / CD. Una parte integrale di u sviluppu era automatizazione, chì vi permette di pruvà, implementà è furnisce una nova funziunalità à l'utilizatori assai più veloce. Per esempiu, in tutti i nostri prughjetti, un pipeline CI hè automaticamente creatu cù ogni cummit. In questu, l'imaghjini hè assemblatu, pruvatu, sbulicatu à diversi circuiti Kubernetes per debugging è cuntrolli rimanenti, è se tuttu hè bè, i cambiamenti ghjunghjenu à l'utilizatore finale. È questu ùn hè più a scienza rocket, ma un avvenimentu di ogni ghjornu per parechji - più prubabile per voi, postu chì site leghje stu articulu.
Siccomu a correzione di bugs è u sviluppu di novi funziunalità hè realizatu in parallelu, è e versioni ponu esse realizati parechje volte à ghjornu, hè ovvi chì u prucessu di sviluppu hè accumpagnatu da un numeru significativu di impegni, chì significa. un gran numaru di imagine in u registru. In u risultatu, u prublema di urganizà una pulizia efficace di u registru nasce, i.e. caccià l'imaghjini irrilevanti.
Ma cumu si determina ancu se una maghjina hè pertinente?
Criterium per a pertinenza di l'imaghjini
In a maiò parte di i casi, i criterii principali seranu:
1. U primu (u più ovvi è più criticu di tutti) hè l'imaghjini chì attualmente utilizatu in Kubernetes. L'eliminazione di sti imaghjini pò risultà in costi significativi di downtime di pruduzzione (per esempiu, l'imaghjini ponu esse necessarii per a replicazione) o nega l'sforzi di a squadra di debugging in qualsiasi di i loops. (Per questu mutivu avemu ancu fattu un speciale , chì traccia l'assenza di tali imagine in qualsiasi cluster Kubernetes.)
2. Siconda (menu evidenti, ma ancu assai impurtante è torna torna à u sfruttamentu) - imagine chì necessariu per rollback in casu di rilevazione di prublemi seri in a versione attuale. Per esempiu, in u casu di Helm, questi sò l'imaghjini chì sò usati in versioni salvate di a liberazione. (A propositu, per difettu in Helm u limitu hè 256 revisioni, ma hè improbabile chì qualchissia hà veramente bisognu di salvà un tali un gran numaru di versioni? ..) Dopu tuttu, noi, in particulare, magazzini versioni in modu chì pudemu usà dopu, i.e. "Ritorna" à elli se ne necessariu.
3. Terzu - bisogni di u sviluppatore: Tutte l'imaghjini chì sò ligati à u so travagliu attuale. Per esempiu, se avemu cunsideratu un PR, allora hè sensu di lascià una maghjina chì currisponde à l'ultimu impegnu è, per dì, l'impegnu precedente: cusì u sviluppatore pò vultà rapidamente à qualsiasi attività è travaglià cù l'ultimi cambiamenti.
4. Quartu - imagine chì currisponde à e versioni di a nostra applicazione, i.e. sò u pruduttu finali: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, etc.
NB: I criteri definiti quì sò stati formulati in basa di l'esperienza chì interagiscenu cù decine di squadre di sviluppu di diverse cumpagnie. In ogni casu, sicuru, sicondu i specifichi in i prucessi di sviluppu è l'infrastruttura utilizata (per esempiu, Kubernetes ùn hè micca utilizatu), sti criterii ponu differisce.
Eligibilità è soluzioni esistenti
I servizii populari cù i registri di cuntainer, in regula, offrenu e so propiu pulitiche di pulizia di l'imaghjini: in elli pudete definisce e cundizioni in quale una tag hè eliminata da u registru. Tuttavia, sti cundizioni sò limitati da paràmetri cum'è nomi, tempu di creazione è numeru di tag *.
* Dipende da implementazioni specifiche di u registru di u containeru. Avemu cunsideratu e pussibilità di e seguenti soluzioni: Azure CR, Docker Hub, ECR, GCR, Pacchetti GitHub, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - da settembre di u 2020.
Stu settore di paràmetri hè abbastanza abbastanza per suddisfà u quartu criteriu - vale à dì per selezziunà l'imaghjini chì currispondenu à e versioni. In ogni casu, per tutti l'altri criterii, unu deve sceglie un tipu di suluzione di cumprumissu (una pulitica più dura o, à u cuntrariu, più indulgente) - secondu l'aspettattivi è e capacità finanziarie.
Per esempiu, u terzu criteriu - in relazione à i bisogni di i sviluppatori - pò esse risoltu da l'urganizazione di prucessi ind'è squadre: nominazione specifica di l'imaghjini, mantenenu listi di permessi speciali è accordi interni. Ma in fine, deve ancu esse automatizatu. È se e capacità di suluzione pronti ùn sò micca abbastanza, avete da fà qualcosa di u vostru propiu.
A situazione cù i primi dui criterii hè simile: ùn ponu esse soddisfatti senza riceve dati da un sistema esternu - quellu induve l'applicazioni sò implementate (in u nostru casu, Kubernetes).
Illustrazione di u flussu di travagliu in Git
Diciamu chì stai travagliendu qualcosa cum'è questu in Git:
L'icona cù un capu in u diagramma indica l'imaghjini di u containeru chì sò attualmente implementati in Kubernetes per qualsiasi utilizatori (utenti finali, testatori, gestori, etc.) o sò usati da sviluppatori per debugging è scopi simili.
Cosa succede se e pulitiche di pulizia permettenu solu di mantene l'imaghjini (micca eliminati) da i nomi di tag dati?
Ovviamente, un tali scenariu ùn farà micca felice à nimu.
Chì cambierà se e pulitiche permettenu micca di sguassà l'imaghjini? secondu un intervallu di tempu / numeru di l'ultimi cummissioni?
U risultatu hè diventatu assai megliu, ma hè sempre luntanu da l'ideale. Dopu tuttu, avemu sempre sviluppatori chì anu bisognu d'imaghjini in u registru (o ancu implementati in K8s) per debug bugs...
Per sintetizà a situazione attuale di u mercatu: e funzioni dispunibuli in i registri di u containeru ùn offrenu micca abbastanza flessibilità in a pulizia, è u mutivu principale per questu hè nisun modu per interagisce cù u mondu esternu. Risulta chì e squadre chì necessitanu una tale flessibilità sò obligate à implementà indipindentamente l'eliminazione di l'imaghjini "da l'esternu", utilizendu l'API Docker Registry (o l'API nativa di l'implementazione currispondente).
Tuttavia, avemu cercatu una suluzione universale chì automatizà a pulizia di l'imaghjini per diverse squadre chì utilizanu diversi registri...
A nostra strada per a pulizia universale di l'imaghjini
Da induve vene stu bisognu? U fattu hè chì ùn simu micca un gruppu separatu di sviluppatori, ma una squadra chì serve parechji di elli à una volta, aiutendu à risolve in modu cumpletu i prublemi CI / CD. È u principale strumentu tecnicu per questu hè l'utilità Open Source . A so peculiarità hè chì ùn eseguisce micca una sola funzione, ma accumpagna i prucessi di spedizione cuntinui in tutte e tappe: da l'assemblea à a distribuzione.
A publicazione di l'imaghjini à u registru * (subitu dopu chì sò custruiti) hè una funzione evidenti di una tale utilità. E postu chì l'imaghjini sò posti quì per u almacenamentu, allora - se u vostru almacenamentu ùn hè micca illimitatu - avete bisognu à esse rispunsevuli di a so pulizia successiva. Cume avemu ottinutu successu in questu, satisfacendu tutti i criteri specificati, serà discututu in più.
* Ancu se i registri stessi ponu esse sfarenti (Registru Docker, Registru di Container GitLab, Harbour, etc.), i so utilizatori facenu i stessi prublemi. A suluzione universale in u nostru casu ùn dipende micca di l'implementazione di u registru, perchè corre fora di i registri stessi è offre u listessu cumpurtamentu per tutti.
Ancu se usemu werf cum'è un esempiu di implementazione, speremu chì l'approcciu utilizatu serà utile à l'altri squadre chì sò cunfruntati cù difficultà simili.
Allora ci avemu occupatu esternu implementazione di un mecanismu per a pulizia di l'imaghjini - invece di quelli capacità chì sò digià integrati in i registri per i cuntenituri. U primu passu era di utilizà l'API di u Registru Docker per creà e stesse pulitiche primitive per u numeru di tag è u tempu di a so creazione (mintuatu sopra). Aggiuntu à elli permette a lista basatu annantu à l'imaghjini utilizati in l'infrastruttura implementata, i.e. Kubernetes. Per l'ultime, era abbastanza d'utilizà l'API Kubernetes per iterà tutte e risorse implementate è uttene una lista di valori. image.
Sta suluzione triviale risolviu u prublema più criticu (criteriu n ° 1), ma era solu u principiu di u nostru viaghju per migliurà u mecanismu di pulizia. U passu prossimu - è assai più interessante - era a decisione associà l'imaghjini publicati cù a storia di Git.
Schemi di tagging
Per principià, avemu sceltu un approcciu in quale l'imaghjini finali deve guardà l'infurmazioni necessarii per a pulizia, è hà custruitu u prucessu nantu à schemi di tagging. Quandu pubblicà una maghjina, l'utilizatore hà sceltu una opzione di tagging specifica (git-branch, git-commit o git-tag) è hà utilizatu u valore currispundente. In i sistemi CI, sti valori sò stati stabiliti automaticamente in basa di variabili ambientali. In fattu l'imaghjini finali era assuciata cù una primitiva Git specifica, almacenà i dati necessarii per a pulizia in etichette.
Stu approcciu hà risultatu in un inseme di pulitiche chì permettenu Git per esse usatu cum'è a sola fonte di verità:
- Quandu sguassate una filiera / tag in Git, l'imaghjini assuciati in u registru sò stati automaticamente eliminati.
- U nùmeru d'imaghjini assuciati cù tags Git è commits puderanu esse cuntrullati da u numeru di tags utilizati in u schema selezziunatu è l'ora in quale u cummissu assuciatu hè statu creatu.
In generale, l'implementazione risultante hà sappiutu i nostri bisogni, ma una nova sfida ci aspetta prestu. U fattu hè chì mentre utilizendu schemi di tagging basati in primitivi Git, avemu scontru una quantità di difetti. (Siccomu a so descrizzione hè fora di u scopu di stu articulu, ognunu pò familiarizà cù i dettagli .) Dunque, dopu avè decisu di passà à un accostu più efficau à l'etichettatura (tagging basatu in cuntenutu), avemu avutu à ricunsiderà l'implementazione di a pulizia di l'imaghjini.
Novu algoritmu
Perchè? Cù l'etichettatura basata in cuntenutu, ogni tag pò suddisfà parechje cummissioni in Git. Quandu si pulisce l'imaghjini, ùn pudete micca più assume solu da u commit induve a nova tag hè stata aghjuntu à u registru.
Per u novu algoritmu di pulizia, hè statu decisu di alluntanassi da i schemi di tagging è di custruisce prucessu di meta-imagine, ognuna di quale almacena una mansa di:
- l'impegnu nantu à quale a publicazione hè stata realizata (ùn importa se l'imaghjina hè stata aghjunta, cambiata o restava a stessa in u registru di u container);
- è u nostru identificatore internu chì currisponde à l'imaghjini assemblati.
In altri palori, hè stata furnita ligà e tag publicati cù commit in Git.
Cunfigurazione finale è algoritmu generale
Quandu cunfigurà a pulizia, l'utilizatori anu avà accessu à e pulitiche chì selezziunate l'imaghjini attuali. Ogni tali pulitica hè definita:
- assai riferimenti, i.e. Git tags o rami Git chì sò usati durante a scanning;
- è u limitu di l'imaghjini cercati per ogni riferimentu da u settore.
Per illustrà, questu hè ciò chì a cunfigurazione di pulitica predeterminata hà cuminciatu à vede:
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
Sta cunfigurazione cuntene trè pulitiche chì rispettanu e regule seguenti:
- Salvà l'imaghjini per l'ultimi 10 tags Git (per data di creazione di tag).
- Salvà micca più di 2 imagine publicate in l'ultima settimana per micca più di 10 fili cù attività in l'ultima settimana.
- Salvà 10 imagine per i rami
main,stagingиproduction.
L'algoritmu finale si riduce à i seguenti passi:
- Recuperazione di manifesti da u registru di u containeru.
- Escludendu l'imaghjini utilizati in Kubernetes, perchè L'avemu digià pre-selezziunatu da u sondaghju di l'API K8s.
- Scansione di a storia di Git è escludendu l'imaghjini basatu nantu à e pulitiche specificate.
- Eliminazione di l'imaghjini rimanenti.
Riturnendu à a nostra illustrazione, questu hè ciò chì succede cù werf:
In ogni casu, ancu s'ellu ùn aduprate micca werf, un approcciu simili à a pulizia avanzata di l'imaghjini - in una implementazione o l'altru (sicondu l'approcciu preferitu à l'etichettatura di l'imaghjini) - pò esse appiicata à altri sistemi / utilità. Per fà questu, hè abbastanza per ricurdà i prublemi chì si sviluppanu è truvà quelli opportunità in a vostra pila chì vi permettenu di integrà a so suluzione u più liscia pussibule. Speremu chì a strada chì avemu viaghjatu vi aiuterà à vede u vostru casu particulari cù novi ditagli è pinsamenti.
cunchiusioni
- Prima o dopu, a maiò parte di e squadre scontranu u prublema di u overflow di u registru.
- Quandu cercate suluzioni, hè primurosu di determinà i criterii per a pertinenza di l'imaghjini.
- L'arnesi pruposti da i servizii di registru di cuntainer populari permettenu di urganizà una pulizia assai simplice chì ùn piglia micca in contu u "mondu esternu": l'imaghjini utilizati in Kubernetes è e peculiarità di i flussi di travagliu di a squadra.
- Un algoritmu flexible è efficiente deve avè una cunniscenza di i prucessi CI / CD è opera micca solu cù e dati di l'imaghjini Docker.
PS
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com