Problem "pametnega" čiščenja slik vsebnika in njegova rešitev v werf

Članek obravnava težave čiščenja slik, ki se kopičijo v registrih vsebnikov (Docker Registry in njegovi analogi) v realnosti sodobnih cevovodov CI/CD za izvorne aplikacije v oblaku, dostavljene Kubernetesu. Podana so glavna merila za ustreznost slik in posledične težave pri avtomatizaciji čiščenja, prihranku prostora in zadovoljevanju potreb timov. Na koncu vam bomo na primeru specifičnega odprtokodnega projekta povedali, kako je te težave mogoče premagati.

Predstavitev

Število slik v registru vsebnikov lahko hitro naraste, zavzame več prostora za shranjevanje in tako znatno poveča stroške. Za nadzor, omejitev ali vzdrževanje sprejemljive rasti prostora, zasedenega v registru, je sprejeto:

1. uporabite fiksno število oznak za slike;
2. na nek način očistite slike.

Prva omejitev je včasih sprejemljiva za majhne ekipe. Če imajo razvijalci dovolj stalnih oznak (latest, main, test, boris itd.), register se ne bo povečal in vam dolgo časa sploh ne bo treba razmišljati o čiščenju. Konec koncev se izbrišejo vse nepomembne slike in preprosto ni več dela za čiščenje (vse opravi običajen zbiralec smeti).

Vendar ta pristop močno omejuje razvoj in je redko uporaben za sodobne CI/CD projekte. Sestavni del razvoja je bil avtomatizacijo, ki vam omogoča veliko hitrejše testiranje, uvajanje in dostavo novih funkcij uporabnikom. Na primer, v vseh naših projektih se cevovod CI samodejno ustvari z vsako potrditvijo. V njem se slika sestavi, preizkusi, razvije v različna vezja Kubernetes za odpravljanje napak in preostala preverjanja, in če je vse v redu, spremembe dosežejo končnega uporabnika. In to ni več raketna znanost, ampak vsakdanji pojav za mnoge – verjetno za vas, saj berete ta članek.

Ker odpravljanje hroščev in razvoj novih funkcionalnosti potekata vzporedno, izdaje pa se lahko izvajajo večkrat na dan, je očitno, da razvojni proces spremlja veliko število potrditev, kar pomeni veliko število slik v registru. Posledično se pojavi vprašanje organizacije učinkovitega čiščenja registra, tj. odstranjevanje nepomembnih slik.

Toda kako sploh ugotoviti, ali je slika ustrezna?

Merila za ustreznost slike

V veliki večini primerov bodo glavna merila:

1. Prvi (najbolj očiten in najbolj kritičen od vseh) so slike, ki trenutno se uporablja v Kubernetesu. Odstranitev teh slik lahko povzroči znatne stroške izpada proizvodnje (slike so na primer morda potrebne za replikacijo) ali izniči prizadevanja skupine za odpravljanje napak v kateri koli od zank. (Iz tega razloga smo naredili celo posebno Prometej izvozniki, ki spremlja odsotnost takih slik v kateri koli gruči Kubernetes.)

2. Drugo (manj očitno, a tudi zelo pomembno in se spet nanaša na izkoriščanje) – slike, ki potrebno za povrnitev v prejšnje stanje v primeru odkritja resnih težav v trenutni različici. Na primer, v primeru Helma so to slike, ki se uporabljajo v shranjenih različicah izdaje. (Mimogrede, v Helmu je privzeta omejitev 256 revizij, vendar je malo verjetno, da bi kdo res moral shraniti takšen veliko število različic?..) Navsezadnje različice shranjujemo predvsem zato, da jih lahko kasneje uporabimo, tj. po potrebi se jim "vrnite nazaj".

3. Tretjič - potrebe razvijalcev: Vse slike, ki so povezane z njihovim trenutnim delom. Na primer, če razmišljamo o PR, potem je smiselno pustiti sliko, ki ustreza zadnji objavi in, recimo, prejšnji objavi: tako se lahko razvijalec hitro vrne k kateri koli nalogi in dela z najnovejšimi spremembami.

4. Četrtič - slike, ki ustrezajo različicam naše aplikacije, tj. so končni izdelek: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra itd.

Opomba: tukaj opredeljena merila so bila oblikovana na podlagi izkušenj v interakciji z desetinami razvojnih skupin iz različnih podjetij. Seveda pa se ti kriteriji lahko razlikujejo glede na posebnosti v razvojnih procesih in uporabljeno infrastrukturo (npr. Kubernetes se ne uporablja).

Upravičenost in obstoječe rešitve

Priljubljene storitve z registri vsebnikov praviloma ponujajo lastne politike čiščenja slik: v njih lahko določite pogoje, pod katerimi se oznaka odstrani iz registra. Vendar so ti pogoji omejeni s parametri, kot so imena, čas ustvarjanja in število oznak*.

* Odvisno od specifičnih implementacij registra vsebnikov. Upoštevali smo možnosti naslednjih rešitev: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - od septembra'2020.

Ta niz parametrov je povsem dovolj za izpolnitev četrtega kriterija - to je za izbiro slik, ki ustrezajo različicam. Za vsa druga merila pa je treba izbrati neko kompromisno rešitev (strožjo ali obratno bolj prizanesljivo politiko) – odvisno od pričakovanj in finančnih zmožnosti.

Na primer, tretje merilo - povezano s potrebami razvijalcev - je mogoče rešiti z organizacijo procesov znotraj timov: specifično poimenovanje slik, vzdrževanje posebnih seznamov dovoljenih in internih dogovorov. Toda na koncu ga je treba še vedno avtomatizirati. In če zmogljivosti že pripravljenih rešitev niso dovolj, morate narediti nekaj svojega.

Situacija s prvima dvema meriloma je podobna: ne moreta ju zadovoljiti brez prejemanja podatkov iz zunanjega sistema – tistega, kjer so nameščene aplikacije (v našem primeru Kubernetes).

Ilustracija poteka dela v Gitu

Recimo, da v Gitu delate nekaj takega:

Ikona z glavo v diagramu označuje slike vsebnika, ki so trenutno razporejene v Kubernetes za katere koli uporabnike (končne uporabnike, preizkuševalce, upravitelje itd.) ali jih uporabljajo razvijalci za odpravljanje napak in podobne namene.

Kaj se zgodi, če pravilniki o čiščenju dovoljujejo samo ohranitev slik (ne brisanje) po danih imenih oznak?

Očitno takšen scenarij ne bo osrečil nikogar.

Kaj se bo spremenilo, če pravilniki dovoljujejo, da se slike ne izbrišejo? glede na dani časovni interval / število zadnjih potrditev?

Rezultat je postal veliko boljši, vendar še vedno daleč od idealnega. Navsezadnje imamo še vedno razvijalce, ki potrebujejo slike v registru (ali celo nameščene v K8s) za odpravljanje napak ...

Če povzamem trenutno situacijo na trgu: funkcije, ki so na voljo v registrih kontejnerjev, ne ponujajo dovolj fleksibilnosti pri čiščenju, glavni razlog za to pa je ni možnosti za interakcijo z zunanjim svetom. Izkazalo se je, da so ekipe, ki potrebujejo takšno prilagodljivost, prisiljene samostojno izvajati brisanje slik »od zunaj« z uporabo API-ja Docker Registry (ali izvornega API-ja ustrezne izvedbe).

Vendar smo iskali univerzalno rešitev, ki bi avtomatizirala čiščenje slik za različne ekipe z uporabo različnih registrov ...

Naša pot do univerzalnega čiščenja slike

Od kod ta potreba? Dejstvo je, da nismo ločena skupina razvijalcev, ampak ekipa, ki služi mnogim od njih hkrati in pomaga pri celovitem reševanju težav CI/CD. In glavno tehnično orodje za to je pripomoček Open Source werf. Njegova posebnost je, da ne opravlja ene same funkcije, ampak spremlja neprekinjene procese dostave na vseh stopnjah: od montaže do uvajanja.

Objava slik v registru* (takoj po njihovi izdelavi) je očitna funkcija takega pripomočka. In ker so slike tam shranjene za shranjevanje, potem - če vaš prostor za shranjevanje ni neomejen - morate biti odgovorni za njihovo naknadno čiščenje. O tem, kako smo pri tem uspeli, ko smo zadostili vsem postavljenim kriterijem, bomo razpravljali naprej.

* Čeprav so registri sami lahko različni (Docker Registry, GitLab Container Registry, Harbor itd.), se njihovi uporabniki srečujejo z enakimi težavami. Univerzalna rešitev v našem primeru ni odvisna od implementacije registra, ker deluje zunaj samih registrov in ponuja enako vedenje za vse.

Čeprav uporabljamo werf kot primer izvedbe, upamo, da bodo uporabljeni pristopi koristni za druge ekipe, ki se soočajo s podobnimi težavami.

Tako smo bili zaposleni zunanji implementacija mehanizma za čiščenje slik – namesto tistih zmožnosti, ki so že vgrajene v registre za vsebnike. Prvi korak je bil uporaba API-ja Docker Registry za ustvarjanje istih primitivnih pravilnikov za število oznak in čas njihovega ustvarjanja (omenjeno zgoraj). Dodano k njim seznam dovoljenih na podlagi slik, uporabljenih v razporejeni infrastrukturi, tj. Kubernetes. Za slednje je bilo dovolj, da uporabite Kubernetes API za ponavljanje vseh razporejenih virov in pridobitev seznama vrednosti image.

Ta nepomembna rešitev je rešila najbolj kritičen problem (merilo št. 1), vendar je bila le začetek naše poti k izboljšanju čistilnega mehanizma. Naslednji - in veliko bolj zanimiv - korak je bila odločitev povežite objavljene slike z zgodovino Git.

Sheme označevanja

Za začetek smo izbrali pristop, pri katerem naj bi končna slika shranila potrebne informacije za čiščenje, in postopek zgradili na shemah označevanja. Pri objavi slike je uporabnik izbral določeno možnost označevanja (git-branch, git-commit ali git-tag) in uporabil ustrezno vrednost. V sistemih CI so bile te vrednosti nastavljene samodejno na podlagi spremenljivk okolja. Pravzaprav končna slika je bila povezana s posebnim primitivom Git, shranjevanje potrebnih podatkov za čiščenje v nalepke.

Rezultat tega pristopa je niz pravilnikov, ki so omogočili uporabo Gita kot edinega vira resnice:

• Pri brisanju veje/oznake v Gitu so bile povezane slike v registru samodejno izbrisane.
• Število slik, povezanih z oznakami in objavami Git, je mogoče nadzorovati s številom oznak, uporabljenih v izbrani shemi, in časom, ko je bila povezana potrditev ustvarjena.

Na splošno je dobljena izvedba zadovoljila naše potrebe, vendar nas je kmalu čakal nov izziv. Dejstvo je, da smo pri uporabi shem označevanja, ki temeljijo na primitivih Git, naleteli na številne pomanjkljivosti. (Ker njihov opis presega obseg tega članka, se lahko vsak seznani s podrobnostmi tukaj.) Zato smo morali ob odločitvi za prehod na učinkovitejši pristop označevanja (vsebinsko označevanje) ponovno razmisliti o implementaciji čiščenja slik.

Nov algoritem

Zakaj? Z označevanjem na podlagi vsebine lahko vsaka oznaka zadovolji več potrditev v Gitu. Pri čiščenju slik ne morete več domnevati Samo iz objave, kjer je bila nova oznaka dodana v register.

Za nov algoritem čiščenja je bilo odločeno, da se odmakne od shem označevanja in gradi proces meta-slike, od katerih vsaka shranjuje kup:

• potrditev, na kateri je bila izvedena objava (ni pomembno, ali je bila slika dodana, spremenjena ali ostala enaka v registru vsebnika);
• in naš notranji identifikator, ki ustreza sestavljeni sliki.

Z drugimi besedami, bilo je zagotovljeno povezovanje objavljenih oznak z zavezami v Gitu.

Končna konfiguracija in splošni algoritem

Pri konfiguraciji čiščenja imajo uporabniki zdaj dostop do pravilnikov, ki izberejo trenutne slike. Vsak tak pravilnik je opredeljen:

• veliko referenc, tj. Oznake Git ali veje Git, ki se uporabljajo med skeniranjem;
• in omejitev iskanih slik za vsako referenco iz niza.

Za ponazoritev, takole je začela izgledati privzeta konfiguracija pravilnika:

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

Ta konfiguracija vsebuje tri pravilnike, ki so v skladu z naslednjimi pravili:

1. Shranite sliko za zadnjih 10 oznak Git (po datumu ustvarjanja oznake).
2. Shranite največ 2 sliki, objavljeni v zadnjem tednu, za največ 10 niti z dejavnostjo v zadnjem tednu.
3. Shranite 10 slik za veje main, staging и production.

Končni algoritem se skrči na naslednje korake:

• Pridobivanje manifestov iz registra vsebnikov.
• Brez slik, uporabljenih v Kubernetesu, ker Z anketiranjem API-ja K8s smo jih že vnaprej izbrali.
• Pregledovanje zgodovine Git in izključevanje slik na podlagi določenih pravilnikov.
• Odstranjevanje preostalih slik.

Če se vrnemo k naši ilustraciji, se to zgodi z werf:

Tudi če ne uporabljate werf, lahko podoben pristop k naprednemu čiščenju slike - v eni ali drugi izvedbi (glede na prednostni pristop k označevanju slike) - uporabite za druge sisteme/pripomočke. Če želite to narediti, je dovolj, da se spomnite težav, ki se pojavljajo, in poiščete tiste priložnosti v svojem kupu, ki vam omogočajo čim bolj gladko integracijo njihove rešitve. Upamo, da vam bo pot, ki smo jo prehodili, pomagala pogledati na vaš primer z novimi podrobnostmi in razmišljanji.

Zaključek

• Prej ali slej se večina ekip sreča s težavo prepolnitve registra.
• Pri iskanju rešitev je najprej treba določiti kriterije za relevantnost slike.
• Orodja, ki jih ponujajo priljubljene storitve registra vsebnikov, vam omogočajo, da organizirate zelo preprosto čiščenje, ki ne upošteva "zunanjega sveta": slik, uporabljenih v Kubernetesu, in posebnosti delovnih tokov ekipe.
• Prilagodljiv in učinkovit algoritem mora razumeti procese CI/CD in delovati ne le s slikovnimi podatki Docker.

PS

Preberite tudi na našem blogu:

• «Označevanje na podlagi vsebine v zbiralniku werf: zakaj in kako deluje?»;
• «3-smerno spajanje z werf: uvedba v Kubernetes s Helmom "na steroidih"»;
• «Podpora za monorepo in multirepo v werf in kaj ima s tem Docker Registry»;
• «izdaja werf 1.1: današnje izboljšave graditelja in načrti za prihodnost".

Vir: www.habr.com