🥇Vandamálið við „snjöll“ hreinsun á gámamyndum og lausn þess í werf

Greinin fjallar um vandamálin við að þrífa myndir sem safnast fyrir í gámaskrám (Docker Registry og hliðstæður þess) í raunveruleika nútíma CI/CD leiðslna fyrir skýjaforrit sem send eru til Kubernetes. Gefin eru upp helstu viðmið fyrir mikilvægi mynda og erfiðleikana sem af því leiðir við að gera sjálfvirkan þrif, spara pláss og mæta þörfum teyma. Að lokum, með því að nota dæmi um tiltekið Open Source verkefni, munum við segja þér hvernig hægt er að sigrast á þessum erfiðleikum.

Inngangur

Fjöldi mynda í gámaskrá getur vaxið hratt, tekið meira geymslupláss og þannig aukið kostnað þess verulega. Til að stjórna, takmarka eða viðhalda viðunandi vexti pláss sem er upptekið í skránni er það samþykkt:

nota fastan fjölda merkja fyrir myndir;
hreinsaðu myndirnar á einhvern hátt.

Fyrsta takmörkunin er stundum ásættanleg fyrir lítil teymi. Ef forritarar hafa nóg varanleg merki (latest, main, test, boris o.s.frv.), mun skrásetningin ekki stækka að stærð og í langan tíma þarftu alls ekki að hugsa um að þrífa hana. Þegar öllu er á botninn hvolft er öllum óviðkomandi myndum eytt og það er einfaldlega engin vinna eftir við þrif (allt er gert af venjulegum sorphirðu).

Hins vegar takmarkar þessi nálgun mjög þróun og á sjaldan við um nútíma CI/CD verkefni. Óaðskiljanlegur hluti af þróuninni var sjálfvirkni, sem gerir þér kleift að prófa, dreifa og skila nýjum virkni til notenda mun hraðar. Til dæmis, í öllum verkefnum okkar, er CI leiðsla sjálfkrafa búin til með hverri skuldbindingu. Í henni er myndin sett saman, prófuð, rúllað út í ýmsar Kubernetes hringrásir fyrir villuleit og eftirstöðvar, og ef allt er í lagi ná breytingarnar til endanotandans. Og þetta eru ekki lengur eldflaugavísindi, heldur hversdagslegur viðburður fyrir marga - líklegast fyrir þig, þar sem þú ert að lesa þessa grein.

Þar sem lagfæring á villum og þróun nýrrar virkni fer fram samhliða og hægt er að framkvæma útgáfur nokkrum sinnum á dag, er augljóst að þróunarferlinu fylgir umtalsverður fjöldi skuldbindinga, sem þýðir mikill fjöldi mynda í skránni. Í kjölfarið kemur upp spurningin um að skipuleggja skilvirka hreinsun á skránni, þ.e. að fjarlægja óviðkomandi myndir.

En hvernig ákveður þú hvort mynd sé viðeigandi?

Skilyrði fyrir mikilvægi myndarinnar

Í langflestum tilfellum verða helstu viðmiðin:

1. Sú fyrsta (sú augljósasta og gagnrýnin af öllu) eru myndirnar sem sem nú er notað í Kubernetes. Ef þessar myndir eru fjarlægðar getur það leitt til verulegs kostnaðar við framleiðslu niður í miðbæ (til dæmis, myndirnar gætu verið nauðsynlegar til afritunar) eða afneitað viðleitni liðsins við villuleit á hvaða lykkju sem er. (Af þessum sökum gerðum við meira að segja sérstaka Prometheus útflytjandi, sem rekur fjarveru slíkra mynda í hvaða Kubernetes þyrping sem er.)

2. Í öðru lagi (minna augljóst, en einnig mjög mikilvægt og tengist aftur nýtingu) - myndir sem krafist fyrir afturköllun ef upp koma alvarleg vandamál í núverandi útgáfu. Til dæmis, þegar um Helm er að ræða, eru þetta myndir sem eru notaðar í vistuðum útgáfum útgáfunnar. (Við the vegur, sjálfgefið í Helm er hámarkið 256 endurskoðun, en það er ólíklegt að einhver þurfi raunverulega að vista slíkt fjöldann allan af útgáfum?..) Enda geymum við sérstaklega útgáfur þannig að við getum notað þær síðar, þ.e. „rúlla aftur“ til þeirra ef þörf krefur.

3. Þriðja - þarfir þróunaraðila: Allar myndir sem tengjast núverandi verkum þeirra. Til dæmis, ef við erum að íhuga PR, þá er skynsamlegt að skilja eftir mynd sem samsvarar síðustu skuldbindingunni og, segjum, fyrri skuldbindingunni: þannig getur verktaki fljótt farið aftur í hvaða verkefni sem er og unnið með nýjustu breytingarnar.

4. Í fjórða lagi - myndir sem samsvara útgáfum af umsókn okkar, þ.e. eru lokaafurð: v1.0.0, 20.04.01/XNUMX/XNUMX, Sierra, o.fl.

ATH: Viðmiðin sem skilgreind eru hér voru mótuð út frá reynslu af samskiptum við tugi þróunarteyma frá mismunandi fyrirtækjum. Hins vegar, að sjálfsögðu, eftir sérstöðu í þróunarferlunum og innviðum sem notaðir eru (til dæmis, Kubernetes er ekki notað), geta þessi viðmið verið mismunandi.

Hæfi og fyrirliggjandi lausnir

Vinsæl þjónusta með gámaskrám býður að jafnaði upp á eigin myndhreinsunarstefnu: í þeim er hægt að skilgreina skilyrðin fyrir því að merki sé fjarlægt úr skránni. Hins vegar eru þessi skilyrði takmörkuð af breytum eins og nöfnum, sköpunartíma og fjölda merkja*.

* Fer eftir sérstökum gámaskrárútfærslum. Við skoðuðum möguleikana á eftirfarandi lausnum: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - frá og með september'2020.

Þetta sett af breytum er alveg nóg til að uppfylla fjórðu skilyrðið - það er að velja myndir sem samsvara útgáfunum. Hins vegar, fyrir öll önnur viðmið, þarf að velja einhvers konar málamiðlunarlausn (harðari eða öfugt, mildari stefnu) - allt eftir væntingum og fjárhagslegri getu.

Til dæmis er hægt að leysa þriðja viðmiðið - sem tengist þörfum þróunaraðila - með því að skipuleggja ferla innan teyma: sérstakt nafngift á myndum, viðhalda sérstökum leyfislistum og innri samningum. En að lokum þarf það samt að vera sjálfvirkt. Og ef hæfileikar tilbúinna lausna duga ekki til, verður þú að gera eitthvað sjálfur.

Staðan með fyrstu tveimur viðmiðunum er svipuð: ekki er hægt að fullnægja þeim án þess að fá gögn frá utanaðkomandi kerfi - því þar sem forrit eru sett á (í okkar tilviki, Kubernetes).

Mynd af verkflæði í Git

Segjum að þú sért að vinna eitthvað á þessa leið í Git:

Táknið með haus á skýringarmyndinni gefur til kynna gámamyndir sem eru notaðar í Kubernetes fyrir hvaða notendur sem er (endanotendur, prófunaraðilar, stjórnendur osfrv.) eða eru notaðar af forriturum til villuleitar og svipaðra nota.

Hvað gerist ef hreinsunarreglur leyfa aðeins að geyma myndir (ekki eytt) með tilgreindum merkisnöfnum?

Augljóslega mun slík atburðarás ekki gleðja neinn.

Hvað mun breytast ef reglur leyfa að myndum sé ekki eytt? í samræmi við tiltekið tímabil / fjölda síðustu skuldbindinga?

Útkoman er orðin miklu betri en samt langt frá því að vera ákjósanleg. Þegar öllu er á botninn hvolft erum við enn með forritara sem þurfa myndir í skránni (eða jafnvel notaðar í K8s) til að kemba villur...

Til að draga saman núverandi markaðsaðstæður: aðgerðirnar sem eru tiltækar í gámaskránum bjóða ekki upp á nægan sveigjanleika við hreinsun og aðalástæðan fyrir því er engin leið til að hafa samskipti við umheiminn. Það kemur í ljós að teymi sem þurfa slíkan sveigjanleika neyðast til að innleiða myndeyðingu sjálfstætt „að utan“ með því að nota Docker Registry API (eða innfædda API samsvarandi útfærslu).

Hins vegar vorum við að leita að alhliða lausn sem myndi gera sjálfvirkan myndhreinsun fyrir mismunandi teymi með því að nota mismunandi skrár...

Leið okkar að alhliða myndhreinsun

Hvaðan kemur þessi þörf? Staðreyndin er sú að við erum ekki sérstakur hópur þróunaraðila, heldur teymi sem þjónar mörgum þeirra í einu og hjálpar til við að leysa alhliða CI/CD vandamál. Og helsta tæknilega tólið fyrir þetta er Open Source tólið werf. Sérkenni þess er að það gegnir ekki einni aðgerð heldur fylgir stöðugu afhendingarferli á öllum stigum: frá samsetningu til dreifingar.

Að birta myndir í skránni* (strax eftir að þær eru byggðar) er augljóst hlutverk slíks tóls. Og þar sem myndirnar eru settar þar til geymslu, þá - ef geymsla þín er ekki ótakmörkuð - þarftu að bera ábyrgð á síðari hreinsun þeirra. Nánar verður fjallað um hvernig við náðum árangri í þessu, uppfylltum öll tilgreind skilyrði.

* Þó að skrárnar sjálfar gætu verið mismunandi (Docker Registry, GitLab Container Registry, Harbor, osfrv.), standa notendur þeirra frammi fyrir sömu vandamálum. Alhliða lausnin í okkar tilviki er ekki háð framkvæmd skrárinnar, vegna þess keyrir utan skráninganna sjálfra og býður upp á sömu hegðun fyrir alla.

Þó að við séum að nota werf sem dæmi um útfærslu, vonum við að aðferðirnar sem notaðar eru muni nýtast öðrum teymum sem glíma við svipaða erfiðleika.

Svo við urðum upptekin ytri innleiðing á kerfi til að hreinsa myndir - í stað þeirra eiginleika sem þegar eru innbyggðir í skrár fyrir gáma. Fyrsta skrefið var að nota Docker Registry API til að búa til sömu frumstæðu stefnur fyrir fjölda merkja og stofnun þeirra (sem getið er um hér að ofan). Bætt við þá leyfislisti byggður á myndum sem notaðar eru í uppbyggðum innviðum, þ.e. Kubernetes. Fyrir hið síðarnefnda var nóg að nota Kubernetes API til að endurtaka öll tilföng sem notuð eru og fá lista yfir gildi image.

Þessi léttvæga lausn leysti mikilvægasta vandamálið (viðmiðun nr. 1), en var aðeins upphafið á ferð okkar til að bæta hreinsunarbúnaðinn. Næsta – og miklu áhugaverðara – skref var ákvörðunin tengja birtar myndir við Git sögu.

Merkingarkerfi

Til að byrja með völdum við nálgun þar sem lokamyndin ætti að geyma nauðsynlegar upplýsingar fyrir hreinsun og byggðum ferlið á merkingarkerfum. Þegar mynd var birt valdi notandinn ákveðinn merkingarvalkost (git-branch, git-commit eða git-tag) og notaði samsvarandi gildi. Í CI kerfum voru þessi gildi stillt sjálfkrafa út frá umhverfisbreytum. Reyndar lokamyndin var tengd sérstöku Git frumefni, geymir nauðsynleg gögn fyrir hreinsun í merkimiðum.

Þessi nálgun leiddi til setts stefnu sem gerði kleift að nota Git sem eina uppsprettu sannleikans:

Þegar útibú/tag var eytt í Git var tengdum myndum í skránni sjálfkrafa eytt.
Fjölda mynda sem tengjast Git tags og commits gæti verið stjórnað af fjölda merkja sem notuð eru í völdu skema og tímanum sem tengd commit var búið til.

Á heildina litið uppfyllti útfærslan sem af því varð þörfum okkar, en fljótlega beið okkar ný áskorun. Staðreyndin er sú að á meðan við notuðum merkingarkerfi byggð á Git frumstæðum, lentum við í fjölda annmarka. (Þar sem lýsing þeirra er utan gildissviðs þessarar greinar geta allir kynnt sér smáatriðin hér.) Þar af leiðandi, eftir að hafa ákveðið að skipta yfir í skilvirkari nálgun við merkingu (innhaldsmiðaða merkingu), urðum við að endurskoða útfærslu myndhreinsunar.

Nýtt reiknirit

Hvers vegna? Með innihaldsbundinni merkingu getur hvert merki uppfyllt margar skuldbindingar í Git. Þegar þú hreinsar myndir geturðu ekki lengur gert ráð fyrir aðeins frá commit þar sem nýja merkinu var bætt við skrárinn.

Fyrir nýja hreinsunaralgrímið var ákveðið að hverfa frá merkingarkerfum og byggja meta-mynd ferli, sem hver um sig geymir fullt af:

skuldbindingin sem birtingin var framkvæmd á (það skiptir ekki máli hvort myndinni var bætt við, breytt eða verið óbreytt í gámaskránni);
og innra auðkenni okkar sem samsvarar samsettu myndinni.

Með öðrum orðum, það var veitt tengja birt merki við skuldbindingar í Git.

Lokastilling og almennt reiknirit

Þegar þú stillir hreinsun hafa notendur nú aðgang að stefnum sem velja núverandi myndir. Hver slík stefna er skilgreind:

margar tilvísanir, þ.e. Git merki eða Git greinar sem eru notuð við skönnun;
og takmörk leitarmynda fyrir hverja tilvísun úr settinu.

Til að sýna fram á, er þetta hvernig sjálfgefna stefnustillingin byrjaði að líta út:

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

Þessi uppsetning inniheldur þrjár reglur sem eru í samræmi við eftirfarandi reglur:

Vistaðu myndina fyrir síðustu 10 Git merkin (eftir stofnunardagsetningu).
Vistaðu ekki fleiri en 2 myndir sem birtar voru í síðustu viku fyrir ekki fleiri en 10 þræði með virkni í síðustu viku.
Vistaðu 10 myndir fyrir útibú main, staging и production.

Loka reikniritið snýst um eftirfarandi skref:

Að sækja upplýsingaskrá úr gámaskrá.
Að undanskildum myndum sem notaðar eru í Kubernetes, vegna þess að Við höfum þegar valið þær fyrirfram með því að skoða K8s API.
Skanna Git feril og útiloka myndir byggðar á tilgreindum reglum.
Fjarlægir myndir sem eftir eru.

Ef við snúum aftur að myndinni okkar, þetta er það sem gerist með werf:

Hins vegar, jafnvel þótt þú notir ekki werf, er hægt að nota svipaða nálgun við háþróaða myndhreinsun - í einni útfærslu eða annarri (samkvæmt æskilegri nálgun við myndamerkingar) - á önnur kerfi/tól. Til að gera þetta er nóg að muna vandamálin sem upp koma og finna þau tækifæri í staflanum þínum sem gerir þér kleift að samþætta lausn þeirra eins vel og mögulegt er. Við vonum að leiðin sem við höfum farið muni hjálpa þér að skoða tiltekið mál þitt með nýjum smáatriðum og hugsunum.

Ályktun

Fyrr eða síðar lenda flest lið í vandræðum með yfirflæði skrásetningar.
Þegar leitað er að lausnum er fyrst nauðsynlegt að ákvarða forsendur fyrir mikilvægi myndarinnar.
Verkfærin sem vinsæl gámaskrárþjónusta býður upp á gera þér kleift að skipuleggja mjög einfalda hreinsun sem tekur ekki tillit til „ytri heimsins“: myndirnar sem notaðar eru í Kubernetes og sérkenni vinnuflæðis liðsins.
Sveigjanlegt og skilvirkt reiknirit verður að hafa skilning á CI/CD ferlum og starfa ekki aðeins með Docker myndgögnum.

PS

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Vandamálið við "snjöll" hreinsun á gámamyndum og lausn þess í werf