ProHoster > Blog > Administrim > Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

Artikulli shqyrton problematikën e pastrimit të imazheve që grumbullohen në regjistrat e kontejnerëve (Docker Registry dhe homologët e tij) në realitetin e pipelines moderne CI/CD për aplikacione cloud native që dorëzohen në Kubernetes. Janë paraqitur kriteret kryesore për relevancën e imazheve dhe vështirësitë që lindin nga ato gjatë automatizimit të pastrimit, ruajtjes së hapësirës dhe përmbushjes së kërkesave të skuadrave. Së fundi, me shembuj konkretë nga një projekt Open Source, do të tregojmë se si këto vështirësi mund të tejkalohen.

Hyrje

Numri i imazheve në regjistrin e kontejnerëve mund të rritet shpejt, duke zënë më shumë hapësirë në ruajtje dhe, për pasojë, duke shtuar ndjeshëm kostot e saj. Për të kontrolluar, kufizuar ose mbajtur një rritje të pranueshme të hapësirës së zënë në registry, është e zakonshme:

  1. të përdoren një numër fikse etiketash për imazhet;
  2. të pastrohen imazhet në njëfarë mënyre.


Kufizimi i parë ndonjëherë është i pranueshëm për ekipe të vogla. Nëse zhvilluesve u mjaftojnë etiketat e vazhdueshme (latest, main, test, boris etj.), regjistri nuk do të fryhet në madhësi dhe për një kohë të gjatë nuk do të mendohet as për pastrimin. Në fund të fundit, të gjithë imazhet jo-relevante përzihen dhe për pastrimin thjesht nuk mbetet punë (gjithçka bëhet nga mbledhësi standard i mbeturinave).

MegjithatĂ«, ky qasje e kufizon shumĂ« zhvillimin dhe rrallĂ« zbatohet nĂ« CI/CD tĂ« projekteve moderne. NjĂ« pjesĂ« e pandashme e zhvillimit Ă«shtĂ« automatizimi, i cili lejon qĂ« tĂ« testohet, zhvillohet dhe dorĂ«zohet shumĂ« mĂ« shpejt funksionaliteti i ri pĂ«r pĂ«rdoruesit. PĂ«r shembull, nĂ« tĂ« gjitha projektet tona, me çdo commit, krijohet automatikisht njĂ« pipeline CI. NĂ« tĂ«, nd gathered imazhi, testohet, shpĂ«rndahet nĂ« konture tĂ« ndryshme Kubernetes pĂ«r debug dhe kontrollet e tjera, dhe nĂ«se gjithçka shkon mirĂ« — ndryshimet arrijnĂ« te pĂ«rdoruesi i fundit. Dhe kjo nuk Ă«shtĂ« mĂ« njĂ« shkencĂ« raketore, por njĂ« pĂ«rditshmĂ«ri pĂ«r shumĂ« — ndoshta edhe pĂ«r ju, pasi po lexoni kĂ«tĂ« artikull.

Duke pasur parasysh se eliminimi i bug-eve dhe zhvillimi i funksionalitetit tĂ« ri bĂ«het paralelisht, dhe lĂ«shimet mund tĂ« realizohen disa herĂ« nĂ« ditĂ«, Ă«shtĂ« e qartĂ« se procesi i zhvillimit shoqĂ«rohet me njĂ« numĂ«r tĂ« konsiderueshĂ«m commit-esh, dhe pĂ«r pasojĂ« — njĂ« numĂ«r tĂ« madh imazhesh nĂ« registry. Si rezultat, ndodhet nĂ« mĂ«nyrĂ« urgjente nevoja pĂ«r organizimin e njĂ« pastrimi efektiv tĂ« registry-t, dmth. eliminimin e imazheve jo-relevante.

Poros si të përcaktohet nëse një imazh është aktual?

Kriteret e aktualitetit të imazhit

Në shumicën dërrmuese të rasteve, kriteret kryesore do të jenë këto:

1. E para (mĂ« e dukshme dhe mĂ« kritike nga tĂ« gjitha) — janĂ« imazhet qĂ« po pĂ«rdoren nĂ« Kubernetes. Eliminimi i kĂ«tyre imazheve mund tĂ« çojĂ« nĂ« kosto tĂ« mĂ«dha pĂ«r shkak tĂ« pushimit tĂ« production (pĂ«r shembull, imazhet mund tĂ« nevojiten gjatĂ« replikimit) ose tĂ« shfuqizojĂ« pĂ«rpjekjet e ekipit qĂ« merret me debug nĂ« ndonjĂ« nga linjat. (PĂ«r kĂ«tĂ« arsye, ne madje kemi bĂ«rĂ« njĂ« Prometheus exporter, qĂ« monitoron mungesĂ«n e kĂ«tyre imazheve nĂ« çdo klaster Kubernetes.)

2. E dyta (mĂ« pak e dukshme, por gjithashtu shumĂ« e rĂ«ndĂ«sishme dhe pĂ«rsĂ«ri lidhet me operimin) — janĂ« imazhet qĂ« nevojiten pĂ«r rikthim nĂ« rast se shfaqen probleme serioze nĂ« versionin aktual. PĂ«r shembull, nĂ« rastin e Helm-it, kĂ«to janĂ« imazhet qĂ« pĂ«rdoren nĂ« versionet e ruajtura tĂ« lĂ«shimit. (PĂ«r t'u thĂ«nĂ«, si parazgjedhje nĂ« Helm, ka njĂ« kufi prej 256 rishikimesh, por vĂ«shtirĂ« se dikush ka nevojĂ« reale pĂ«r ruajtjen e njĂ« kaq shumĂ« versioneve?..) Sepse ne, pĂ«r shembull, ruajmĂ« versionet, qĂ« tĂ« mund t'i pĂ«rdorim mĂ« pas, dmth. 'tĂ« rikthemi' nĂ« to kur tĂ« jetĂ« e nevojshme.

3. E treta — nevojat e zhvilluesve: tĂ« gjithĂ« imazhet qĂ« lidhen me punĂ«t e tyre aktuale. PĂ«r shembull, nĂ«se po shqyrtojmĂ« njĂ« PR, ka shumĂ« kuptim tĂ« lĂ«mĂ« njĂ« imazh qĂ« korrespondon me commit-in e fundit dhe, le tĂ« themi, commit-in e mĂ«parshĂ«m: kĂ«shtu zhvilluesi mund tĂ« rikthehet shpejt te çdo detyrĂ« dhe tĂ« punojĂ« me ndryshimet e fundit.

4. E katĂ«rta — imazhet qĂ« korrespondoni me versionet e aplikacionit tonĂ«, dmth. janĂ« produkti pĂ«rfundimtar: v1.0.0, 20.04.01, sierra etj.

NB: Kriteret e përcaktuara këtu janë formuluar mbi përvojën e bashkëpunimit me dhjetëra ekipe zhvillimi nga kompani të ndryshme. Megjithatë, sigurisht, në varësi të veçorive në proceset e zhvillimit dhe infrastrukturës së përdorur (për shembull, nëse nuk përdoret Kubernetes), këto kritere mund të ndryshojnë.

Përputhshmëria me kriteret dhe zgjidhjet ekzistuese

Shërbimet e njohura me container registry zakonisht ofrojnë politikat e tyre të pastrimit të imazheve: në to mund të përcaktoni kushtet nën të cilat etiketa fshihet nga registry. Megjithatë, mundësitë e këtyre kushteve janë të kufizuara nga parametra si emrat, koha e krijimit dhe numri i etiketimeve*.

* Varet nga zbatimet specifike tĂ« container registry. Ne shqyrtuam mundĂ«sitĂ« e zgjidhjeve tĂ« mĂ«poshtme: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io — deri nĂ« shtator 2020.

Ky grup parametrash Ă«shtĂ« mjaft i mjaftueshĂ«m pĂ«r tĂ« pĂ«rmbushur kriterin e katĂ«rt — domethĂ«nĂ«, pĂ«r tĂ« filtruar imazhet qĂ« pĂ«rkojnĂ« me versionet. MegjithatĂ«, pĂ«r tĂ« gjitha kriteret e tjera duhet tĂ« zgjidhni ndonjĂ« zgjidhje kompromisi (njĂ« politikĂ« mĂ« tĂ« ashpĂ«r ose pĂ«rkundrazi, mĂ« tĂ« butĂ«) — nĂ« varĂ«si tĂ« pritshmĂ«rive dhe mundĂ«sive financiare.

PĂ«r shembull, kriteri i tretĂ« — i lidhur me nevojat e zhvilluesve — mund tĂ« zgjidhet nĂ«pĂ«rmjet organizimit tĂ« proceseve brenda ekipeve: emĂ«rtimi specifik i imazheve, mbajtja e listave tĂ« miratuara dhe marrĂ«veshjeve tĂ« brendshme. Por nĂ« fund tĂ« fundit, pĂ«rsĂ«ri duhet ta automatizoni. Dhe nĂ«se mundĂ«sitĂ« e zgjidhjeve tĂ« gatshme nuk janĂ« tĂ« mjaftueshme, duhet tĂ« bĂ«ni diçka tĂ« vetĂ«zhbĂ«suar.

Situata Ă«shtĂ« e ngjashme me dy kriteret e para: ato nuk mund tĂ« pĂ«rmbushen pa marrĂ« tĂ« dhĂ«na nga njĂ« sistem tĂ« jashtĂ«m — ai i njĂ«jtĂ« ku ndodh implementimi i aplikacioneve (nĂ« rastin tonĂ«, kjo Ă«shtĂ« Kubernetes).

Ilustrimi i workflow në Git

Supozoni se punoni në një skemë të tillë në Git:

Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

Imazhet e kontejnerëve që janë aktualisht të implementuara në Kubernetes për ndonjë përdorues (përdoruesit përfundimtarë, testuesit, menaxherët etj.) ose përdoren nga zhvilluesit për debagimin dhe qëllime të ngjashme shënohen me një ikonë të kokës në diagram.

ÇfarĂ« do tĂ« ndodhte nĂ«se politikat e pastrimit lejojnĂ« lĂ«nien (mosfshirjen) e imazheve vetĂ«m nĂ«n emrat e caktuar tĂ« etiketimeve?

Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

Sigurisht, një skenar i tillë nuk do të kënaqte askënd.

ÇfarĂ« do tĂ« ndryshonte nĂ«se politikat lejojnĂ« qĂ« imazhet tĂ« mos fshihen nĂ«n njĂ« interval tĂ« caktuar kohor / numrin e komiteteve tĂ« fundit?

Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

Rezultati është përmirësuar ndjeshëm, megjithatë, ende është larg nga ideali. Sepse kemi ende zhvillues që kanë nevojë për imazhe në registrin (ose madje të implementuara në K8s) për të debaguar gabimet...

Përmbledhshëm, situata e tregut tregon se funksionalitetet e disponueshme në regjistrat e konteinerëve nuk ofrojnë mjaft fleksibilitet në pastrimin, dhe arsyeja kryesore për këtë është mungesa e mundësisë për të ndërvepruar me botën e jashtme. Ndërsa ekipet që kanë nevojë për një fleksibilitet të tillë, detyrohen të realizojnë vetë fshirjen e imazheve "nga jashtë", duke përdorur API-në e Docker Registry (ose API-në natyrore të implementimit përkatës).

Megjithatë, ne kërkonim një zgjidhje universale që do të automatizonte pastrimin e imazheve për ekzistencë të ndryshme ekipesh që përdorin regjistra të ndryshëm


Rruga jonë drejt pastrimit universale të imazheve

Nga ka lindur kjo nevojĂ«? ËshtĂ« se ne nuk jemi njĂ« grup zhvilluesish tĂ« veçantĂ«, por njĂ« ekip qĂ« shĂ«rben njĂ« sĂ«rĂ« grupeve tĂ« tilla, duke ndihmuar nĂ« zgjidhjen e problemeve CI/CD nĂ« mĂ«nyrĂ« gjithĂ«pĂ«rfshirĂ«se. Dhe instrumenti ynĂ« teknik kryesor pĂ«r kĂ«tĂ« Ă«shtĂ« utilitarja Open Source werf. Veçoria e saj Ă«shtĂ« se ajo nuk realizon njĂ« funksion tĂ« vetĂ«m, por shoqĂ«ron proceset e dĂ«rgimit tĂ« vazhdueshĂ«m nĂ« tĂ« gjitha fazat: nga ndĂ«rtimi deri tek vendosja.

Publikimi i imazheve në regjistër* (menjëherë pas ndërtimit të tyre) është një funksion i qartë i një utilitare të tillë. Dhe për sa kohë që imazhet ruhen aty, nëse ruajtja juaj nuk është e pafund, është e nevojshme të merret gjithashtu me pastrimin e tyre të mëvonshëm. Si arritëm suksese në këtë, duke plotësuar të gjitha kriteret e caktuara, do të flasim më poshtë.

* Edhe pse regjistrat vetë mund të jenë të ndryshëm (Docker Registry, GitLab Container Registry, Harbor etj.), përdoruesit e tyre përballen me të njëjtat probleme. Zgjidhja universale në rastin tonë nuk varet nga implementimi i regjistrit, pasi realizohet jashtë vetë regjistrave dhe ofron një sjellje të njëjtë për të gjithë.

Megjithëse ne përdorim werf si një shembull të implementimit, shpresojmë që qasjet e përdorura do të jenë të dobishme për ekipe të tjera që hasin vështirësi të ngjashme.

Pra, ne u angazhuam nĂ« implementimin e mekanizmit pĂ«r pastrimin e imazheve — nĂ« vend tĂ« mundĂ«sive qĂ« tashmĂ« janĂ« tĂ« integruara nĂ« regjistrat e konteinerĂ«ve. Hapi i parĂ« ishte pĂ«rdorimi i API-sĂ« sĂ« Docker Registry pĂ«r tĂ« krijuar disa politika primitive nĂ« lidhje me numrin e etiketave dhe kohĂ«n e krijimit tĂ« tyre (tĂ« pĂ«rmendura mĂ« lart). KĂ«tyre iu shtua lista e lejuar bazuar nĂ« imazhet qĂ« pĂ«rdoren nĂ« infrastrukturĂ«n e vendosur, pra Kubernetes. PĂ«r tĂ« fundit, ishte e mjaftueshme tĂ« kalonim pĂ«rmes API-sĂ« Kubernetes pĂ«r tĂ« skanuar tĂ« gjithĂ« burimet e derdhura dhe pĂ«r tĂ« marrĂ« njĂ« listĂ« me vlera. image.

Ky zgjidhje triviale zgjidhi problemin mĂ« kritik (kriteri nr. 1), por ishte vetĂ«m fillimi i rrugĂ«timit tonĂ« pĂ«r tĂ« pĂ«rmirĂ«suar mekanizmin e pastrimit. Hapi tjetĂ«r — dhe mĂ« interesanti — ishte zgjidhja pĂ«r tĂ« lidhur imazhet publikuese me historinĂ« e Git..

Skemat e etiketimit.

Në fillim, ne zgjodhëm një qasje ku imazhi përfundimtar duhet të mbante informacionin e nevojshëm për pastrimin dhe organizuam procesin mbi skemat e etiketimit. Kur bëhej publikimi i imazhit, përdoruesi zgjidhte një opsion të veçantë etiketimi (git-branch, git-commit ose git-tag) dhe përdorte vlerën përkatëse. Në sistemet CI, vendosja e këtyre vlerave bëhej automatikisht në bazë të variablave të ambientit. Në thelb imazhi përfundimtar lidhej me një primitiv të caktuar të Git, duke ruajtur të dhënat e nevojshme për pastrimin në etiketa.

Në kuadër të kësaj qasje, u krijua një grup politikash që lejonin përdorimin e Git si burimi i vetëm i së vërtetës:

  • Kur dekretohej njĂ« degĂ«/tag nĂ« Git, imazhet e lidhura nĂ« registry fshiheshin automatikisht.
  • Numri i imazheve tĂ« lidhura me etiketat dhe komitetet e Git mund tĂ« rregullohej me numrin e etiketave tĂ« pĂ«rdorura nĂ« skemĂ«n e pĂ«rzgjedhur dhe kohĂ«n e krijimit tĂ« komitetit tĂ« lidhur.

Në përgjithësi, realizimi që do të rezultonte përmbushte nevojat tona, por së shpejti na priste një sfidë të re. Faktikisht, gjatë përdorimit të skemave të etiketimit mbi primitivët e Git, ne përballeshim me një numër të defekteve. (Për shkak se përshkrimi i tyre kalon jashtë temës së këtij artikulli, të gjithë ata që kanë interes mund të informohen mbi detajet. këtu.) Prandaj, duke marrë vendimin për kalimin në një qasje më efikase ndaj etiketimit (etiketimi i bazuar në përmbajtje), na duhej të rishikonim edhe realizimin e pastrimit të imazheve.

Algoritmi i ri.

Pse? Kur etiketimi bëhet në kuadër të etiketimit të bazuar në përmbajtje, çdo etiketë mund të plotësojë një shumëllojshmëri komitetesh në Git. Në pastrimin e imazheve nuk mund të fillojmë më të nga komiteti në të cilin u shtua një etiketë e re në registry.

Për algoritmin e ri të pastrimit u vendos të largohej nga skemat e etiketimit dhe të organizohej procesi mbi meta-imazhe, çdo një nga të cilat ruan lidhjen nga:

  • komitit, nĂ« tĂ« cilin u publikua publikimi (nuk ka rĂ«ndĂ«si nĂ«se u shtua, ndryshua apo qĂ«ndroi i njĂ«jtĂ« imazhi nĂ« regjistrin e konteinerĂ«ve);
  • dhe identifikuesi ynĂ« tĂ« brendshĂ«m, pĂ«rkatĂ«s pĂ«r imazhin e mbledhur.

Me fjalë të tjera, u siguruar lidhi etiketat e publikuara me komitetet në Git.

Konfigurimi përfundimtar dhe algoritmi i përgjithshëm

PĂ«rdoruesit nĂ« konfigurimin e pastrimit kanĂ« akses nĂ« politikat, sipas tĂ« cilave realizohet pĂ«rzgjedhja e imazheve aktuale. Çdo politikĂ« e tillĂ« pĂ«rcaktohet:

  • nga njĂ« grup referencesh, pra etiketa Git ose degĂ« Git, tĂ« cilat pĂ«rdoren gjatĂ« skanimit;
  • dhe njĂ« kufi pĂ«r imazhet e kĂ«rkuara pĂ«r çdo reference nga grupa.

PĂ«r ilustrovimin — ja si duket konfigurimi i politikave pĂ«r default:

pastrimi:
  mbajPolitikat:
  - referencat:
      etiketa: \/.*\/ 
      kufiri:
        i fundit: 10
  - referencat:
      dega: \/.*\/ 
      kufiri:
        i fundit: 10
        në: 168h
        operator: Dhe
    imazhetPërReferencë:
      i fundit: 2
      në: 168h
      operator: Dhe
  - referencat:
      dega: \/^(main|staging|production)$\/
    imazhetPërReferencë:
      i fundit: 10

Kjo konfigurim përmban tre politika, të cilat përmbushin këto rregulla:

  1. Të ruajmë imazhin për 10 etiketat e fundit Git (sipas datës së krijimit të etikës).
  2. Të ruajmë për më shumë se 2 imazhe, të publikuara javën e fundit, për më shumë se 10 degë me aktivitet në javën e fundit.
  3. Të ruajmë për 10 imazhe për degët main, staging dhe production.

Algoritmi përfundimtar përfshin hapat e mëposhtëm:

  • Marrja e manifestave nga container registry.
  • PĂ«rjashtimi i imazheve qĂ« pĂ«rdoren nĂ« Kubernetes, pasi qĂ« i kemi pĂ«rzgjedhur mĂ« parĂ«, duke pyetur K8s API.
  • Skanimi i historisĂ« Git dhe pĂ«rjashtimi i imazheve sipas politikave tĂ« caktuara.
  • Fshirja e imazheve tĂ« mbetura.

Duke u rikthyer te ilustërimi ynë, ja çfarë ndodh me werf:

Problemi i pastrimit “inteligjent” tĂ« imazheve tĂ« kontejnerĂ«ve dhe zgjidhja e tij nĂ« werf

MegjithatĂ«, edhe nĂ«se nuk e pĂ«rdorni werf, njĂ« qasje e ngjashme pĂ«r pastrimin e avancuar tĂ« imazheve — nĂ« njĂ« zbatim tĂ« tillĂ« apo tjetĂ«r (nĂ« pĂ«rputhje me qasjen e preferuar pĂ«r etiketimin e imazheve) — mund tĂ« aplikohet edhe nĂ« sisteme / mjete tĂ« tjera. Mjafton tĂ« mbani nĂ« mend problemet qĂ« lindin dhe tĂ« gjeni ato mundĂ«si nĂ« stekĂ«n tuaj qĂ« lejojnĂ« integrimin e zgjidhjeve mĂ« tĂ« pĂ«rshtatshme. ShpresojmĂ« se rruga qĂ« kaluam do tĂ« ndihmojĂ« nĂ« shqyrtimin e rastit tuaj tĂ« veçantĂ« me detaje dhe mendime tĂ« reja.

PĂ«rfundim

  • PĂ«r njĂ« kohĂ« tĂ« gjatĂ« ose vonĂ«, problemi i mbushjes sĂ« regjistrit pĂ«rballet me shumicĂ«n e ekipeve.
  • Kur kĂ«rkoni zgjidhje, Ă«shtĂ« e nevojshme tĂ« pĂ«rcaktoni kriteret e relevancĂ«s sĂ« imazhit.
  • Mjetet e ofruara nga shĂ«rbimet popullore tĂ« container registry lejojnĂ« organizimin e njĂ« pastrimi shumĂ« tĂ« thjeshtĂ«, i cili nuk merr parasysh "botĂ«n e jashtme": imazhet qĂ« pĂ«rdoren nĂ« Kubernetes dhe veçoritĂ« e proceseve tĂ« punĂ«s nĂ« ekip.
  • NjĂ« algoritĂ«m fleksibĂ«l dhe efektiv duhet tĂ« ketĂ« njohuri pĂ«r proceset CI/CD, duke operuar jo vetĂ«m me tĂ« dhĂ«nat e imazheve Docker.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster