Edukiontzien irudien garbiketa "adimentsua"ren arazoa eta bere konponbidea werfean

Artikuluak edukiontzi-erregistroetan (Docker Registry eta bere analogoetan) pilatzen diren irudiak garbitzeko arazoak aztertzen ditu Kubernetes-era bidaltzen diren hodeiko natiboko aplikazioetarako CI/CD kanalizazio modernoen errealitateetan. Irudien garrantziaren irizpide nagusiak eta garbiketa automatizatzeko, espazioa aurrezteko eta taldeen beharrak asetzeko sortzen diren zailtasunak ematen dira. Azkenik, Open Source proiektu zehatz baten adibidea erabiliz, zailtasun horiek nola gaindi daitezkeen esango dizugu.

Sarrera

Edukiontzi-erregistro bateko irudi-kopurua azkar hazi daiteke, biltegiratze leku gehiago hartuz eta, beraz, kostua nabarmen handituz. Erregistroan okupatutako espazioaren hazkunde onargarria kontrolatzeko, mugatzeko edo mantentzeko, hau onartzen da:

1. irudietarako etiketa kopuru finko bat erabili;
2. garbitu irudiak nolabait.

Lehen muga batzuetan talde txikientzat onargarria da. Garatzaileek etiketa iraunkor nahikoa badute (latest, main, test, boris etab.), erregistroa ez da tamainaz hazten eta denbora luzez ez duzu garbitu beharrik izango. Azken finean, garrantzirik gabeko irudi guztiak ezabatu egiten dira, eta garbitzeko lanik ez dago geratzen (dena ohiko zabor-biltzaile batek egiten du).

Hala ere, ikuspegi honek garapena asko mugatzen du eta oso gutxitan aplikatzen da CI/CD proiektu modernoetan. Garapenaren zati bat izan zen automatizazioa, erabiltzaileei askoz azkarrago probatu, zabaldu eta funtzionalitate berriak emateko aukera ematen dizu. Adibidez, gure proiektu guztietan, CI kanalizazio bat sortzen da automatikoki konpromiso bakoitzarekin. Bertan, irudia muntatu, probatu, hainbat Kubernetes zirkuituetara zabaltzen da arazketa eta gainerako egiaztapenak egiteko, eta dena ondo badago, aldaketak azken erabiltzailearengana iristen dira. Eta hori jada ez da suziri zientzia, askorentzat eguneroko gertaera bat baizik - ziurrenik zuretzat, artikulu hau irakurtzen ari zarenetik.

Akatsak konpontzen eta funtzionaltasun berriak garatzen paraleloki egiten direnez eta egunean hainbat aldiz kaleratzeak egin daitezkeenez, bistakoa da garapen-prozesuak konpromiso kopuru handiarekin batera duela, eta horrek esan nahi du. irudi kopuru handi bat erregistroan. Ondorioz, erregistroaren garbiketa eraginkorra antolatzearen auzia sortzen da, hau da. garrantzirik gabeko irudiak kentzea.

Baina nola zehaztu irudi bat garrantzitsua den ala ez?

Irudiaren garrantziaren irizpideak

Kasu gehienetan, irizpide nagusiak hauek izango dira:

1. Lehenengoa (denetan nabariena eta kritikoena) irudiak dira gaur egun Kubernetes-en erabiltzen da. Irudi hauek kentzeak ekoizpen-denbora-kostu handiak eragin ditzake (adibidez, irudiak errepikatzeko beharrezkoak izan daitezke) edo taldeko edozein begiztatan arazketa-esfortzua ezeztatu. (Horregatik, berezi bat ere egin dugu Prometheus esportatzailea, Kubernetes-eko edozein klusteretan halako irudirik ez dagoenaren jarraipena egiten duena.)

2. Bigarren (ez hain agerikoa, baina baita oso garrantzitsua eta berriro ustiapenari dagokio) - irudiak hori atzera egiteko beharrezkoa da arazo larriak hautematen badira egungo bertsioan. Adibidez, Helm-en kasuan, bertsioaren gordetako bertsioetan erabiltzen diren irudiak dira. (Bide batez, Helm-en lehenespenezko muga 256 berrikuspen da, baina nekez gorde behar du inork benetan hala nola bertsio ugari?..) Azken finean, guk, bereziki, bertsioak gordetzen ditugu gero erabili ahal izateko, alegia. "itzuli" horietara behar izanez gero.

3. Hirugarrena - garatzaileen beharrak: Uneko lanarekin zerikusia duten irudi guztiak. Esaterako, PR bat kontuan hartzen ari bagara, orduan zentzuzkoa da azken konpromisuari eta, demagun, aurreko konpromisoari dagokion irudi bat uztea: horrela garatzailea azkar itzuli daiteke edozein zereginetara eta azken aldaketekin lan egin.

4. Laugarren - irudiak duten gure aplikazioaren bertsioei dagokie, hau da. azken produktua dira: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, etab.

OHARRA: Hemen definitutako irizpideak enpresa ezberdinetako dozenaka garapen talderekin elkarreraginean izandako esperientzian oinarrituta formulatu dira. Hala ere, jakina, garapen prozesuen eta erabilitako azpiegituren zehaztasunen arabera (adibidez, Kubernetes ez da erabiltzen), irizpide horiek desberdinak izan daitezke.

Hautagarritasuna eta dauden irtenbideak

Edukiontzien erregistroak dituzten zerbitzu ezagunek, oro har, irudiak garbitzeko politika propioak eskaintzen dituzte: horietan etiketa bat erregistrotik kentzeko baldintzak zehaztu ditzakezu. Hala ere, baldintza hauek parametroek mugatzen dituzte, hala nola, izenak, sorrera denbora eta etiketa kopurua*.

* Edukiontzi-erregistroaren inplementazio espezifikoen araberakoa da. Konponbide hauen aukerak kontuan hartu ditugu: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - 2020ko irailetik aurrera.

Parametro multzo hau nahikoa da laugarren irizpidea betetzeko, hau da, bertsioei dagozkien irudiak hautatzeko. Hala ere, gainerako irizpide guztietarako, konpromezu-konponbideren bat aukeratu behar da (politika gogorragoa edo, alderantziz, arinagoa), itxaropenen eta gaitasun finantzarioen arabera.

Esaterako, hirugarren irizpidea -garatzaileen beharrei lotutakoa- taldeen barruan prozesuak antolatuz konpon daiteke: irudien izendapen zehatza, baimen-zerrenda bereziak eta barne-akordioak mantentzea. Baina azken finean oraindik automatizatu egin behar da. Eta prest egindako irtenbideen gaitasunak nahikoak ez badira, zeure zerbait egin behar duzu.

Lehen bi irizpideen egoera antzekoa da: ezin dira bete kanpoko sistema batetik datuak jaso gabe -aplikazioak zabaltzen direnetik (gure kasuan, Kubernetes-).

Lan-fluxuaren ilustrazioa Git-en

Demagun Git-en horrelako zerbait lantzen ari zarela:

Diagramako burua duen ikonoak Kubernetesen une honetan edozein erabiltzailerentzat (azken erabiltzaileak, probatzaileak, kudeatzaileak, etab.) erabiltzen dituen edukiontzien irudiak adierazten ditu, edo garatzaileek arazketa eta antzeko helburuetarako erabiltzen dituztenak.

Zer gertatzen da garbiketa-politikek irudiak gordetzea soilik onartzen badute (ez ezabatzen) emandako etiketen izenen arabera?

Jakina, horrelako eszenatoki batek ez du inor poztuko.

Zer aldatuko da gidalerroek irudiak ez ezabatzea ahalbidetzen badute? denbora-tarte / azken konpromezu kopuruaren arabera?

Emaitza askoz hobea izan da, baina oraindik idealetik urrun dago. Azken finean, oraindik ere baditugu akatsak arazteko irudiak erregistroan (edo K8etan zabalduta) behar dituzten garatzaileak...

Merkatuaren egungo egoera laburbiltzeko: edukiontzien erregistroetan dauden funtzioek ez dute behar adina malgutasun eskaintzen garbiketan, eta horren arrazoi nagusia da. kanpoko munduarekin elkarreragiteko modurik ez. Ematen du malgutasun hori behar duten taldeak irudien ezabaketa “kanpotik” modu independentean ezabatzera behartuta daudela, Docker Registry APIa erabiliz (edo dagokion inplementazioaren jatorrizko APIa).

Hala ere, talde ezberdinentzako irudien garbiketa automatizatuko zuen irtenbide unibertsal baten bila ari ginen erregistro desberdinak erabiliz...

Irudi garbiketa unibertsalerako gure bidea

Nondik dator behar hori? Kontua da ez garela garatzaile talde bereizi bat, haietako asko aldi berean zerbitzatzen dituen taldea baizik, CI/CD arazoak modu integralean konpontzen laguntzen duena. Eta horretarako tresna tekniko nagusia Open Source utilitatea da werf. Bere berezitasuna da ez duela funtzio bakar bat betetzen, baizik eta etengabeko entrega-prozesuei laguntzen diela fase guztietan: muntatzetik inplementaziora arte.

Irudiak erregistroan* argitaratzea (sortu eta berehala) erabilgarritasun horren funtzio agerikoa da. Eta irudiak bertan gordetzeko jartzen direnez, orduan - biltegiratzea mugagabea ez bada - ondorengo garbiketaz arduratu behar zara. Honetan arrakasta nola lortu genuen, zehaztutako irizpide guztiak betez, gehiago eztabaidatuko da.

* Erregistroak beraiek desberdinak izan daitezkeen arren (Docker Registry, GitLab Container Registry, Harbour, etab.), haien erabiltzaileek arazo berdinak dituzte. Gure kasuan irtenbide unibertsala ez dago erregistroaren ezarpenaren araberakoa, zeren Erregistroetatik kanpo exekutatzen da eta guztientzako portaera bera eskaintzen du.

Inplementazio adibide gisa werf erabiltzen ari garen arren, espero dugu erabilitako planteamenduak antzeko zailtasunak dituzten beste taldeentzat baliagarriak izatea.

Beraz, lanpetuta egon ginen kanpokoa Irudiak garbitzeko mekanismo bat ezartzea - ​​edukiontzien erregistroetan dagoeneko eraikita dauden gaitasun horien ordez. Lehenengo urratsa Docker Registry APIa erabiltzea izan zen etiketa kopuruaren eta sortzeko denboraren (goian aipatutako) politika primitibo berdinak sortzeko. Horiei gehituta inplementatutako azpiegituretan erabilitako irudietan oinarritutako zerrenda baimendu, hau da. Kubernetes. Azken horretarako, nahikoa izan zen Kubernetes APIa erabiltzea inplementatutako baliabide guztiak errepikatzeko eta balioen zerrenda lortzeko. image.

Irtenbide hutsal honek arazo larriena konpondu zuen (1. irizpidea), baina garbiketa mekanismoa hobetzeko gure ibilbidearen hasiera baino ez zen izan. Hurrengo urratsa -eta askoz interesgarriagoa- erabakia izan zen lotu argitaratutako irudiak Git historiarekin.

Etiketatze-eskemak

Hasteko, azken irudiak garbitzeko beharrezko informazioa gorde behar duen ikuspegi bat aukeratu dugu, eta prozesua etiketa-eskemetan eraiki. Irudi bat argitaratzean, erabiltzaileak etiketatze aukera zehatz bat hautatu zuen (git-branch, git-commit edo git-tag) eta dagokion balioa erabili zuen. CI sistemetan, balio horiek automatikoki ezartzen ziren ingurune-aldagaietan oinarrituta. Izan ere azken irudia Git primitibo zehatz batekin lotzen zen, garbiketarako beharrezko datuak etiketetan gordeta.

Ikuspegi honek Git egiaren iturri bakar gisa erabiltzeko aukera ematen zuen politika multzo bat sortu zuen:

• Git-en adar/etiketa bat ezabatzean, erregistroko erlazionatutako irudiak automatikoki ezabatu ziren.
• Git etiketarekin eta konpromezuekin lotutako irudi kopurua hautatutako eskeman erabilitako etiketa kopuruak eta lotutako konpromisoa sortu den unearen arabera kontrola liteke.

Orokorrean, ondoriozko ezarpenak gure beharrak asetu zituen, baina laster erronka berri bat itxaroten zitzaigun. Kontua da Git primitiboetan oinarritutako etiketa-eskemak erabiltzean, hainbat gabezia topatu genituela. (Haien deskribapena artikulu honen esparrutik kanpo dagoenez, guztiek ezagutu ditzakete xehetasunak Hemen.) Horregatik, etiketatzearen ikuspegi eraginkorrago batera aldatzea erabaki genuen (edukietan oinarritutako etiketatzea), irudien garbiketaren ezarpena birplanteatu behar izan genuen.

Algoritmo berria

Zergatik? Edukian oinarritutako etiketatzearekin, etiketa bakoitzak hainbat konpromiso bete ditzake Git-en. Irudiak garbitzean, jada ezin duzu suposatu bakarrik etiketa berria erregistrora gehitu den konpromezutik.

Garbiketa algoritmo berrirako, etiketa-eskemetatik aldendu eta eraikitzea erabaki zen meta-irudiaren prozesua, eta horietako bakoitzak pila bat gordetzen ditu:

• argitalpena egin den konpromisoa (berdin du irudia edukiontzien erregistroan gehitu, aldatu edo berdin mantendu den);
• eta muntatutako irudiari dagokion gure barne identifikatzailea.

Beste era batera esanda, eman zen argitaratutako etiketak Git-en konpromezuekin lotzea.

Azken konfigurazioa eta algoritmo orokorra

Garbiketa konfiguratzerakoan, erabiltzaileek uneko irudiak hautatzen dituzten politiketarako sarbidea dute orain. Horrelako politika bakoitza definitzen da:

• erreferentzia asko, alegia. Eskaneatzean erabiltzen diren Git etiketak edo Git adarrak;
• eta multzoko erreferentzia bakoitzerako bilatutako irudien muga.

Ilustratzeko, hauxe izan zen politika lehenetsiaren konfigurazioa:

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

Konfigurazio honek arau hauek betetzen dituzten hiru politika ditu:

1. Gorde azken 10 Git etiketen irudia (etiketa sortzeko dataren arabera).
2. Ez gorde azken astean argitaratutako 2 irudi baino gehiago azken astean jarduerak izan dituzten 10 hari baino gehiagotan.
3. Gorde 10 irudi adarretarako main, staging и production.

Azken algoritmoa hurrengo urratsetan laburtzen da:

• Manifestuak edukiontzien erregistrotik ateratzen.
• Kubernetesen erabilitako irudiak kenduta, zeren Dagoeneko aurrez hautatu ditugu K8s APIaren galdeketa eginez.
• Git historia eskaneatzea eta zehaztutako politiketan oinarritutako irudiak baztertzea.
• Gainerako irudiak kentzen.

Gure ilustraziora itzuliz, hau da werf-ekin gertatzen dena:

Dena den, werf-a erabiltzen ez baduzu ere, irudien garbiketa aurreratuaren antzeko hurbilketa - inplementazio batean edo bestean (irudien etiketatzearen ikuspegi hobetsiaren arabera) - beste sistema/utilitate batzuetan aplika daiteke. Horretarako, nahikoa da sortzen diren arazoak gogoratzea eta haien konponbidea ahalik eta ondoen integratzea ahalbidetzen dizuten aukera horiek zure pilan aurkitzea. Espero dugu egin dugun bideak zure kasu partikularra xehetasun eta pentsamendu berriekin aztertzen lagunduko dizula.

Ondorioa

• Goiz edo beranduago, talde gehienek erregistroaren gainezkatzearen arazoa aurkitzen dute.
• Irtenbideak bilatzeko orduan, lehenik eta behin irudiaren garrantziaren irizpideak zehaztu behar dira.
• Edukiontzien erregistro-zerbitzu ezagunek eskaintzen dituzten tresnei esker, garbiketa oso sinple bat antola dezakezu, "kanpoko mundua" kontuan hartzen ez duena: Kubernetesen erabiltzen diren irudiak eta taldearen lan-fluxuen berezitasunak.
• Algoritmo malgu eta eraginkor batek CI/CD prozesuen ulermena izan behar du eta Docker irudien datuekin ez ezik funtzionatu behar du.

PS

Irakurri ere gure blogean:

• «Edukietan oinarritutako etiketatzea werf builder-en: zergatik eta nola funtzionatzen du?»;
• «werf-era 3 moduko batuketa: Helm-ekin Kubernetes-en hedatzea "esteroideetan"»;
• «Monorepo eta multirepo-ren laguntza werf-en eta zer egin behar du Docker Erregistroak horrekin»;
• «werf 1.1 bertsioa: gaur egungo eraikitzaileari egindako hobekuntzak eta etorkizunerako planak'.

Iturria: www.habr.com