Tatizo la kusafisha "smart" ya picha za chombo na ufumbuzi wake katika werf

Nakala hiyo inajadili shida za kusafisha picha ambazo hujilimbikiza kwenye sajili za kontena (Msajili wa Docker na analogi zake) katika hali halisi ya mabomba ya kisasa ya CI/CD kwa programu asilia za wingu zinazowasilishwa kwa Kubernetes. Vigezo kuu vya umuhimu wa picha na ugumu unaosababishwa katika kusafisha kiotomatiki, kuokoa nafasi na kukidhi mahitaji ya timu hutolewa. Hatimaye, kwa kutumia mfano wa mradi maalum wa Open Source, tutakuambia jinsi matatizo haya yanaweza kuondokana.

Utangulizi

Idadi ya picha katika rejista ya chombo inaweza kukua kwa kasi, kuchukua nafasi zaidi ya kuhifadhi na hivyo kuongeza gharama yake kwa kiasi kikubwa. Ili kudhibiti, kupunguza au kudumisha ukuaji unaokubalika wa nafasi iliyochukuliwa kwenye Usajili, inakubaliwa:

1. tumia idadi maalum ya vitambulisho kwa picha;
2. safisha picha kwa njia fulani.

Kizuizi cha kwanza wakati mwingine kinakubalika kwa timu ndogo. Ikiwa watengenezaji wana vitambulisho vya kutosha vya kudumu (latest, main, test, boris nk), Usajili hautavimba kwa ukubwa na kwa muda mrefu hautalazimika kufikiria juu ya kusafisha kabisa. Baada ya yote, picha zote zisizo na maana zinafutwa, na hakuna kazi iliyobaki ya kusafisha (kila kitu kinafanywa na mtozaji wa kawaida wa takataka).

Hata hivyo, mbinu hii inazuia sana maendeleo na haitumiki kwa miradi ya kisasa ya CI/CD. Sehemu muhimu ya maendeleo ilikuwa otomatiki, ambayo hukuruhusu kujaribu, kupeleka na kutoa utendakazi mpya kwa watumiaji haraka zaidi. Kwa mfano, katika miradi yetu yote, bomba la CI huundwa kiotomatiki kwa kila ahadi. Ndani yake, picha imekusanywa, imejaribiwa, imevingirwa kwa nyaya mbalimbali za Kubernetes kwa ajili ya kurekebisha na hundi iliyobaki, na ikiwa kila kitu kiko sawa, mabadiliko yanafikia mtumiaji wa mwisho. Na hii sio sayansi ya roketi tena, lakini tukio la kila siku kwa wengi - uwezekano mkubwa kwako, kwani unasoma nakala hii.

Kwa kuwa kurekebisha mende na kukuza utendakazi mpya hufanywa kwa sambamba, na kutolewa kunaweza kufanywa mara kadhaa kwa siku, ni dhahiri kwamba mchakato wa maendeleo unaambatana na idadi kubwa ya ahadi, ambayo inamaanisha. idadi kubwa ya picha katika Usajili. Matokeo yake, suala la kuandaa kusafisha kwa ufanisi wa Usajili hutokea, i.e. kuondoa picha zisizo na maana.

Lakini unawezaje kuamua ikiwa picha inafaa?

Vigezo vya umuhimu wa picha

Katika idadi kubwa ya kesi, vigezo kuu vitakuwa:

1. Ya kwanza (ya wazi zaidi na muhimu zaidi kuliko zote) ni picha ambazo kwa sasa inatumika Kubernetes. Kuondoa picha hizi kunaweza kusababisha gharama kubwa za muda wa chini wa uzalishaji (kwa mfano, picha zinaweza kuhitajika ili kurudiwa) au kukanusha juhudi za utatuzi wa timu kwenye misururu yoyote. (Kwa sababu hii hata tulifanya maalum Prometheus nje, ambayo hufuatilia kutokuwepo kwa picha kama hizo katika nguzo yoyote ya Kubernetes.)

2. Pili (chini ya wazi, lakini pia ni muhimu sana na tena inahusiana na unyonyaji) - picha ambazo inahitajika kwa urejeshaji katika kesi ya kugundua matatizo makubwa katika toleo la sasa. Kwa mfano, katika kesi ya Helm, hizi ni picha zinazotumiwa katika matoleo yaliyohifadhiwa ya kutolewa. (Kwa njia, kwa chaguo-msingi katika Helm kikomo ni marekebisho 256, lakini kuna uwezekano kwamba mtu yeyote anahitaji kuokoa. vile vile idadi kubwa ya matoleo? ..) Baada ya yote, sisi, hasa, tunahifadhi matoleo ili tuweze kuitumia baadaye, i.e. "rudi nyuma" kwao ikiwa ni lazima.

3. Tatu - mahitaji ya msanidi: Picha zote ambazo zinahusiana na kazi yao ya sasa. Kwa mfano, ikiwa tunazingatia PR, basi inaeleweka kuacha picha inayolingana na ahadi ya mwisho na, sema, ahadi ya awali: kwa njia hii msanidi anaweza kurudi kwa kazi yoyote na kufanya kazi na mabadiliko ya hivi karibuni.

4. Nne - picha ambazo yanahusiana na matoleo ya programu yetu, i.e. ndizo bidhaa za mwisho: v1.0.0, 20.04.01/XNUMX/XNUMX, Sierra, nk.

NB: Vigezo vilivyofafanuliwa hapa viliundwa kulingana na uzoefu wa kuingiliana na timu kadhaa za maendeleo kutoka kwa kampuni tofauti. Hata hivyo, bila shaka, kulingana na maalum katika michakato ya maendeleo na miundombinu inayotumiwa (kwa mfano, Kubernetes haitumiwi), vigezo hivi vinaweza kutofautiana.

Kustahiki na ufumbuzi zilizopo

Huduma maarufu zilizo na sajili za vyombo, kama sheria, hutoa sera zao za kusafisha picha: ndani yao unaweza kufafanua hali ambayo lebo huondolewa kwenye Usajili. Hata hivyo, masharti haya yanadhibitiwa na vigezo kama vile majina, muda wa uundaji na idadi ya lebo*.

* Inategemea utekelezaji wa sajili ya kontena mahususi. Tulizingatia uwezekano wa suluhu zifuatazo: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - kuanzia Septemba'2020.

Seti hii ya vigezo ni ya kutosha kukidhi kigezo cha nne - yaani, kuchagua picha zinazofanana na matoleo. Hata hivyo, kwa vigezo vingine vyote, mtu anapaswa kuchagua aina fulani ya ufumbuzi wa maelewano (sera kali au, kinyume chake, sera ya upole zaidi) - kulingana na matarajio na uwezo wa kifedha.

Kwa mfano, kigezo cha tatu - kinachohusiana na mahitaji ya watengenezaji - kinaweza kutatuliwa kwa kuandaa michakato ndani ya timu: majina maalum ya picha, kudumisha orodha maalum za kuruhusu na makubaliano ya ndani. Lakini hatimaye bado inahitaji kuwa automatiska. Na ikiwa uwezo wa ufumbuzi tayari hautoshi, unapaswa kufanya kitu chako mwenyewe.

Hali na vigezo viwili vya kwanza ni sawa: hawawezi kuridhika bila kupokea data kutoka kwa mfumo wa nje - ule ambapo maombi yanatumwa (kwa upande wetu, Kubernetes).

Mchoro wa mtiririko wa kazi katika Git

Wacha tuseme unafanya kazi kama hii katika Git:

Aikoni iliyo na kichwa kwenye mchoro inaonyesha picha za kontena ambazo kwa sasa zimetumwa katika Kubernetes kwa watumiaji wowote (watumiaji wa mwisho, wanaojaribu, wasimamizi, n.k.) au hutumiwa na wasanidi programu kwa utatuzi na madhumuni sawa.

Nini kitatokea ikiwa sera za kusafisha zinaruhusu tu kuhifadhi picha (zisifutwe) kwa majina ya lebo?

Kwa wazi, hali kama hiyo haitafurahisha mtu yeyote.

Nini kitabadilika ikiwa sera zitaruhusu picha zisifutwe? kulingana na muda fulani / idadi ya ahadi za mwisho?

Matokeo yamekuwa bora zaidi, lakini bado ni mbali na bora. Baada ya yote, bado tuna wasanidi programu wanaohitaji picha kwenye sajili (au hata kutumwa katika K8s) kutatua hitilafu...

Kwa muhtasari wa hali ya sasa ya soko: kazi zinazopatikana katika sajili za vyombo hazitoi kubadilika kwa kutosha wakati wa kusafisha, na sababu kuu ya hii ni. hakuna njia ya kuingiliana na ulimwengu wa nje. Inabadilika kuwa timu zinazohitaji ubadilikaji kama huo zinalazimika kutekeleza ufutaji wa picha kwa uhuru "kutoka nje", kwa kutumia API ya Usajili wa Docker (au API asili ya utekelezaji unaolingana).

Walakini, tulikuwa tunatafuta suluhisho la ulimwengu wote ambalo lingefanya usafishaji wa picha kiotomatiki kwa timu tofauti kwa kutumia sajili tofauti...

Njia yetu ya kusafisha picha kwa wote

Hitaji hili linatoka wapi? Ukweli ni kwamba sisi si kundi tofauti la wasanidi programu, lakini timu inayohudumia wengi wao kwa wakati mmoja, kusaidia kutatua kwa kina masuala ya CI/CD. Na chombo kikuu cha kiufundi kwa hili ni matumizi ya Open Source werf. Upekee wake ni kwamba haifanyi kazi moja, lakini inaambatana na michakato ya utoaji wa kuendelea katika hatua zote: kutoka kwa mkusanyiko hadi kupelekwa.

Kuchapisha picha kwenye sajili* (mara tu baada ya kujengwa) ni kazi dhahiri ya matumizi hayo. Na kwa kuwa picha zimewekwa pale kwa ajili ya kuhifadhi, basi - ikiwa hifadhi yako haina ukomo - unahitaji kuwajibika kwa kusafisha kwao baadae. Jinsi tulivyofanikiwa katika hili, kukidhi vigezo vyote vilivyoainishwa, itajadiliwa zaidi.

* Ingawa sajili zenyewe zinaweza kuwa tofauti (Msajili wa Docker, Usajili wa Vyombo vya GitLab, Bandari, n.k.), watumiaji wao wanakabiliwa na matatizo sawa. Suluhisho la ulimwengu wote katika kesi yetu haitegemei utekelezaji wa Usajili, kwa sababu huendesha nje ya sajili zenyewe na hutoa tabia sawa kwa kila mtu.

Ingawa tunatumia werf kama mfano wa utekelezaji, tunatumai kuwa mbinu zitakazotumiwa zitakuwa na manufaa kwa timu nyingine zinazokabiliwa na matatizo kama hayo.

Kwa hiyo tukawa na shughuli nyingi ya nje utekelezaji wa utaratibu wa kusafisha picha - badala ya uwezo huo ambao tayari umejengwa kwenye rejista za vyombo. Hatua ya kwanza ilikuwa kutumia API ya Usajili wa Docker kuunda sera za awali zilezile za idadi ya lebo na wakati wa kuundwa kwao (zilizotajwa hapo juu). Imeongezwa kwao ruhusu orodha kulingana na picha zinazotumiwa katika miundombinu iliyotumika, i.e. Kubernetes. Kwa mwisho, ilitosha kutumia API ya Kubernetes kurudia kupitia rasilimali zote zilizotumika na kupata orodha ya maadili. image.

Suluhisho hili lisilo na maana lilitatua tatizo muhimu zaidi (kigezo Na. 1), lakini ilikuwa tu mwanzo wa safari yetu ya kuboresha utaratibu wa kusafisha. Hatua inayofuata - na ya kufurahisha zaidi - ilikuwa uamuzi shirikisha picha zilizochapishwa na historia ya Git.

Mipango ya kuweka alama

Kuanza, tulichagua njia ambayo picha ya mwisho inapaswa kuhifadhi habari muhimu ya kusafisha, na tukaunda mchakato kwenye miradi ya kuweka alama. Wakati wa kuchapisha picha, mtumiaji alichagua chaguo maalum la kuweka lebo (git-branch, git-commit au git-tag) na kutumia thamani inayolingana. Katika mifumo ya CI, maadili haya yaliwekwa kiotomatiki kulingana na anuwai ya mazingira. Kwa kweli picha ya mwisho ilihusishwa na primitive maalum ya Git, kuhifadhi data muhimu kwa ajili ya kusafisha katika maandiko.

Mbinu hii ilisababisha seti ya sera ambazo ziliruhusu Git kutumika kama chanzo kimoja cha ukweli:

• Wakati wa kufuta tawi/lebo kwenye Git, picha zinazohusiana kwenye sajili zilifutwa kiotomatiki.
• Idadi ya picha zinazohusishwa na lebo za Git na ahadi zinaweza kudhibitiwa na idadi ya lebo zilizotumiwa kwenye utaratibu uliochaguliwa na wakati ambapo ahadi husika iliundwa.

Kwa ujumla, utekelezaji uliopatikana ulitosheleza mahitaji yetu, lakini changamoto mpya ilitungoja hivi karibuni. Ukweli ni kwamba wakati wa kutumia miradi ya kuweka alama kulingana na primitives ya Git, tulikutana na mapungufu kadhaa. (Kwa kuwa maelezo yao ni zaidi ya upeo wa kifungu hiki, kila mtu anaweza kujijulisha na maelezo hapa.) Kwa hiyo, baada ya kuamua kubadili njia ya ufanisi zaidi ya kuweka alama (kuweka alama za maudhui), tulipaswa kuzingatia upya utekelezaji wa kusafisha picha.

Algorithm mpya

Kwa nini? Kwa uwekaji tagi kulingana na yaliyomo, kila lebo inaweza kukidhi ahadi nyingi kwenye Git. Wakati wa kusafisha picha, huwezi kudhani tena tu kutoka kwa ahadi ambapo lebo mpya iliongezwa kwenye usajili.

Kwa algorithm mpya ya kusafisha, iliamuliwa kuachana na miradi ya kuweka alama na kujenga mchakato wa meta-picha, ambayo kila moja huhifadhi rundo la:

• ahadi ambayo uchapishaji ulifanywa (haijalishi ikiwa picha iliongezwa, kubadilishwa au kubaki vile vile kwenye rejista ya kontena);
• na kitambulisho chetu cha ndani kinacholingana na picha iliyokusanyika.

Kwa maneno mengine, ilitolewa kuunganisha vitambulisho vilivyochapishwa na ahadi katika Git.

Usanidi wa mwisho na algorithm ya jumla

Wakati wa kusanidi kusafisha, watumiaji sasa wanaweza kufikia sera zinazochagua picha za sasa. Kila sera kama hiyo imefafanuliwa:

• marejeleo mengi, i.e. Vitambulisho vya Git au matawi ya Git ambayo hutumiwa wakati wa skanning;
• na kikomo cha picha zilizotafutwa kwa kila kumbukumbu kutoka kwa seti.

Kwa mfano, hivi ndivyo usanidi chaguo-msingi wa sera ulianza kuonekana kama:

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

Usanidi huu una sera tatu zinazotii sheria zifuatazo:

1. Hifadhi picha kwa lebo 10 za mwisho za Git (kwa tarehe ya kuunda lebo).
2. Hifadhi si zaidi ya picha 2 zilizochapishwa katika wiki iliyopita kwa si zaidi ya nyuzi 10 zenye shughuli katika wiki iliyopita.
3. Hifadhi picha 10 kwa matawi main, staging и production.

Algorithm ya mwisho inategemea hatua zifuatazo:

• Inarejesha maonyesho kutoka kwa sajili ya kontena.
• Ukiondoa picha zinazotumiwa katika Kubernetes, kwa sababu Tayari tumezichagua mapema kwa kupigia kura API ya K8s.
• Inachanganua historia ya Git na kutojumuisha picha kulingana na sera zilizobainishwa.
• Inaondoa picha zilizobaki.

Kurudi kwa mfano wetu, hii ndio hufanyika na werf:

Walakini, hata ikiwa hutumii werf, mbinu sawa ya kusafisha picha ya hali ya juu - katika utekelezaji mmoja au mwingine (kulingana na mbinu inayopendekezwa ya kuweka tagi ya picha) - inaweza kutumika kwa mifumo/huduma zingine. Ili kufanya hivyo, ni kutosha kukumbuka matatizo yanayotokea na kupata fursa hizo katika stack yako ambayo inakuwezesha kuunganisha suluhisho lao vizuri iwezekanavyo. Tunatumahi kuwa njia ambayo tumesafiri itakusaidia kutazama kesi yako kwa maelezo na mawazo mapya.

Hitimisho

• Hivi karibuni au baadaye, timu nyingi hukutana na tatizo la kufurika kwa usajili.
• Wakati wa kutafuta ufumbuzi, ni muhimu kwanza kuamua vigezo vya umuhimu wa picha.
• Zana zinazotolewa na huduma za usajili wa vyombo maarufu hukuwezesha kuandaa usafishaji rahisi sana ambao hauzingatii "ulimwengu wa nje": picha zinazotumiwa katika Kubernetes na upekee wa mtiririko wa kazi wa timu.
• Algorithm inayoweza kunyumbulika na bora lazima iwe na uelewa wa michakato ya CI/CD na ifanye kazi sio tu na data ya picha ya Docker.

PS

Soma pia kwenye blogi yetu:

• «Uwekaji tagi kulingana na yaliyomo kwenye mkusanyaji wa werf: kwa nini na inafanya kazi vipi?";
• «Njia 3 za kuunganisha kwa werf: kupelekwa kwa Kubernetes na Helm "kwenye steroids"";
• «Msaada wa monorepo na multirepo kwenye werf na Usajili wa Docker una uhusiano gani nayo";
• «toleo la werf 1.1: maboresho kwa mjenzi leo na mipango ya siku zijazo'.

Chanzo: mapenzi.com