Ang problema sa "smart" nga paglimpyo sa mga imahen sa sudlanan ug ang solusyon niini sa werf

Gihisgutan sa artikulo ang mga problema sa paglimpyo sa mga imahe nga natipon sa mga rehistro sa sulud (Docker Registry ug mga analogue niini) sa mga katinuud sa modernong mga pipeline sa CI / CD alang sa mga lumad nga aplikasyon sa panganod nga gihatag sa Kubernetes. Gihatag ang panguna nga pamatasan alang sa kalabotan sa mga imahe ug ang sangputanan nga mga kalisud sa pag-automate sa paglimpyo, pagtipig sa wanang ug pagtagbo sa mga panginahanglanon sa mga koponan gihatag. Sa katapusan, gamit ang panig-ingnan sa usa ka piho nga proyekto sa Open Source, isulti namon kanimo kung giunsa kini nga mga kalisud mabuntog.

Pasiuna

Ang gidaghanon sa mga hulagway sa usa ka container registry mahimong paspas nga motubo, mokuha ug dugang storage space ug sa ingon makadugang sa gasto niini. Aron makontrol, limitahan o mapadayon ang madawat nga pagtubo sa luna nga giokupar sa rehistro, kini gidawat:

1. gamita ang usa ka piho nga gidaghanon sa mga tag alang sa mga imahe;
2. limpyo ang mga imahe sa usa ka paagi.

Ang una nga limitasyon usahay madawat alang sa gagmay nga mga koponan. Kung ang mga developer adunay igo nga permanente nga mga tag (latest, main, test, boris ug uban pa), ang rehistro dili modako sa gidak-on ug sa dugay nga panahon dili nimo kinahanglan nga hunahunaon ang paglimpyo niini. Pagkahuman, ang tanan nga wala’y kalabotan nga mga imahe gipapas, ug wala’y nahabilin nga trabaho alang sa paglimpyo (ang tanan gihimo sa usa ka regular nga tigkolekta sa basura).

Bisan pa, kini nga pamaagi labi nga naglimite sa pag-uswag ug panagsa ra magamit sa modernong mga proyekto sa CI / CD. Usa ka importante nga bahin sa kalamboan mao ang automation, nga nagtugot kanimo sa pagsulay, pag-deploy ug paghatud sa bag-ong pagpaandar sa mga tiggamit nga mas paspas. Pananglitan, sa tanan namong mga proyekto, usa ka pipeline sa CI ang awtomatik nga gihimo sa matag commit. Diha niini, ang hulagway gitigom, gisulayan, gilukot ngadto sa lain-laing mga Kubernetes nga mga sirkito para sa pag-debug ug nahibiling mga tseke, ug kon ang tanan maayo, ang mga kausaban makaabot sa end user. Ug kini dili na rocket science, apan usa ka adlaw-adlaw nga panghitabo alang sa kadaghanan - lagmit alang kanimo, tungod kay imong gibasa kini nga artikulo.

Tungod kay ang pag-ayo sa mga bug ug pagpalambo sa bag-ong pag-andar gihimo nga managsama, ug ang mga pagpagawas mahimo’g daghang beses sa usa ka adlaw, klaro nga ang proseso sa pag-uswag giubanan sa usa ka hinungdanon nga gidaghanon sa mga pasalig, nga nagpasabut nga usa ka dako nga gidaghanon sa mga larawan sa registry. Ingon usa ka sangputanan, ang isyu sa pag-organisar sa epektibo nga paglimpyo sa rehistro mitungha, i.e. pagtangtang sa wala'y kalabutan nga mga imahe.

Apan giunsa nimo pagtino kung ang usa ka imahe may kalabotan?

Mga sukaranan alang sa kalabutan sa imahe

Sa kadaghanan sa mga kaso, ang panguna nga pamatasan mao ang:

1. Ang una (ang labing klaro ug labing kritikal sa tanan) mao ang mga imahe nga gigamit karon sa Kubernetes. Ang pagtangtang niini nga mga hulagway mahimong moresulta sa mahinungdanong mga gasto sa downtime sa produksyon (pananglitan, ang mga hulagway mahimong gikinahanglan alang sa pagkopya) o isalikway ang mga paningkamot sa pag-debug sa team sa bisan unsa nga mga loop. (Tungod niini nga hinungdan naghimo pa kami usa ka espesyal Exporter sa Prometheus, nga nagsubay sa pagkawala sa maong mga hulagway sa bisan unsang Kubernetes cluster.)

2. Ikaduha (dili kaayo klaro, apan importante usab kaayo ug may kalabutan usab sa pagpahimulos) - mga hulagway nga gikinahanglan alang sa rollback sa kaso sa detection sa seryoso nga mga problema sa kasamtangan nga bersyon. Pananglitan, sa kaso sa Helm, kini ang mga imahe nga gigamit sa gitipig nga mga bersyon sa pagpagawas. (By the way, by default sa Helm ang limit kay 256 revisions, pero dili siguro nga naay kinahanglan mag save. ingon niana usa ka dako nga gidaghanon sa mga bersyon?..) Human sa tanan, kami, sa partikular, nagtipig mga bersyon aron magamit namo kini sa ulahi, i.e. “ibalik” ngadto kanila kon gikinahanglan.

3. Ikatulo - panginahanglan sa developer: Tanan nga mga hulagway nga may kalabutan sa ilang trabaho karon. Pananglitan, kung atong gikonsiderar ang usa ka PR, nan makatarunganon nga ibilin ang usa ka imahe nga katumbas sa katapusan nga pasalig ug, ingnon ta, ang miaging pasalig: niining paagiha ang developer dali nga makabalik sa bisan unsang buluhaton ug magtrabaho sa labing bag-ong mga pagbag-o.

4. Ikaupat - mga larawan nga katumbas sa mga bersyon sa among aplikasyon, i.e. mao ang katapusan nga produkto: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, etc.

NB: Ang mga pamatasan nga gihubit dinhi giporma base sa kasinatian nga nakig-uban sa daghang mga grupo sa pagpauswag gikan sa lainlaing mga kompanya. Bisan pa, siyempre, depende sa mga detalye sa mga proseso sa pag-uswag ug ang gigamit nga imprastraktura (pananglitan, wala gigamit ang Kubernetes), kini nga mga pamatasan mahimong magkalainlain.

Kwalipikado ug kasamtangan nga mga solusyon

Ang mga sikat nga serbisyo nga adunay mga rehistro sa sulud, ingon usa ka lagda, nagtanyag sa ilang kaugalingon nga mga palisiya sa paglimpyo sa imahe: sa kanila mahimo nimong ipasabut ang mga kondisyon diin ang usa ka tag gikuha gikan sa rehistro. Bisan pa, kini nga mga kondisyon limitado sa mga parameter sama sa mga ngalan, oras sa paghimo, ug gidaghanon sa mga tag*.

* Nagdepende sa piho nga mga pagpatuman sa rehistro sa sudlanan. Among gikonsiderar ang mga posibilidad sa mosunod nga mga solusyon: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - as of September'2020.

Kini nga hugpong sa mga parameter igo na aron matagbaw ang ikaupat nga sukdanan - nga mao, ang pagpili sa mga imahe nga katumbas sa mga bersyon. Bisan pa, alang sa tanan nga uban nga mga pamatasan, ang usa kinahanglan nga mopili sa usa ka matang sa kompromiso nga solusyon (usa ka mas lig-on o, sa kasukwahi, mas humok nga palisiya) - depende sa mga gilauman ug pinansyal nga kapabilidad.

Pananglitan, ang ikatulo nga sukdanan - nga may kalabutan sa mga panginahanglan sa mga developers - mahimong masulbad pinaagi sa pag-organisar sa mga proseso sulod sa mga grupo: espesipikong pagngalan sa mga hulagway, pagmintinar sa mga espesyal nga lista sa pagtugot ug mga internal nga kasabutan. Apan sa katapusan kini kinahanglan pa nga awtomatiko. Ug kung ang mga kapabilidad sa andam nga mga solusyon dili igo, kinahanglan nimo nga buhaton ang imong kaugalingon.

Ang sitwasyon sa unang duha ka criteria susama: dili sila matagbaw nga wala makadawat og datos gikan sa usa ka eksternal nga sistema - ang usa diin ang mga aplikasyon gipakatap (sa among kaso, Kubernetes).

Ilustrasyon sa workflow sa Git

Ingnon ta nga nagtrabaho ka sama niini sa Git:

Ang icon nga adunay ulo sa diagram nagpaila sa mga laragway sa sudlanan nga karon gi-deploy sa Kubernetes para sa bisan kinsa nga tiggamit (mga end user, tester, manager, ug uban pa) o gigamit sa mga developer alang sa pag-debug ug parehas nga katuyoan.

Unsa ang mahitabo kung ang mga palisiya sa paglimpyo nagtugot lamang sa mga imahe nga mapadayon (dili matangtang) pinaagi sa gihatag nga mga ngalan sa tag?

Dayag, ang maong senaryo dili makapahimuot kang bisan kinsa.

Unsa ang mabag-o kung ang mga palisiya nagtugot sa mga imahe nga dili mapapas? sumala sa gihatag nga agwat sa oras / gidaghanon sa katapusang mga nahimo?

Ang resulta nahimong mas maayo, apan layo pa sa ideal. Human sa tanan, aduna pa kami'y mga developers nga nagkinahanglan og mga hulagway sa registry (o gani gi-deploy sa K8s) aron sa pag-debug sa mga bug...

Sa pag-summarize sa karon nga kahimtang sa merkado: ang mga gimbuhaton nga magamit sa mga rehistro sa sulud wala maghatag igo nga pagka-flexible kung nanglimpyo, ug ang panguna nga hinungdan niini mao ang walay paagi sa pagpakig-uban sa gawas nga kalibutan. Kini nahimo nga ang mga koponan nga nanginahanglan sa ingon nga pagka-flexible napugos nga independente nga ipatuman ang pagtangtang sa imahe "gikan sa gawas", gamit ang Docker Registry API (o ang lumad nga API sa katugbang nga pagpatuman).

Bisan pa, nangita kami usa ka unibersal nga solusyon nga mag-automate sa paglimpyo sa imahe alang sa lainlaing mga koponan gamit ang lainlaing mga rehistro ...

Ang among agianan padulong sa unibersal nga paglimpyo sa imahe

Diin gikan kini nga panginahanglan? Ang tinuod mao nga dili kami usa ka bulag nga grupo sa mga developer, apan usa ka team nga nagserbisyo sa kadaghanan kanila sa usa ka higayon, nagtabang sa komprehensibo nga pagsulbad sa mga isyu sa CI / CD. Ug ang nag-unang teknikal nga himan alang niini mao ang Open Source utility werf. Ang pagkatalagsaon niini mao nga kini wala maghimo usa ka function, apan nag-uban sa padayon nga mga proseso sa paghatud sa tanan nga mga yugto: gikan sa asembliya hangtod sa pag-deploy.

Ang pagpatik sa mga hulagway ngadto sa rehistro* (diha-diha dayon human kini matukod) usa ka dayag nga katungdanan sa maong utility. Ug tungod kay ang mga imahe gibutang didto alang sa pagtipig, nan - kung ang imong pagtipig dili limitado - kinahanglan nimo nga responsable sa ilang sunod nga pagpanglimpyo. Kung giunsa namo pagkab-ot ang kalampusan niini, nga nagtagbaw sa tanan nga gipiho nga pamatasan, hisgutan pa.

* Bisan kung ang mga rehistro mismo mahimong lahi (Docker Registry, GitLab Container Registry, Harbor, ug uban pa), ang ilang mga tiggamit nag-atubang sa parehas nga mga problema. Ang unibersal nga solusyon sa among kaso wala magdepende sa pagpatuman sa rehistro, tungod kay nagdagan sa gawas sa mga rehistro sa ilang kaugalingon ug nagtanyag sa parehas nga pamatasan alang sa tanan.

Bisan kung gigamit namon ang werf ingon usa ka pananglitan nga pagpatuman, nanghinaut kami nga ang mga pamaagi nga gigamit mahimong mapuslanon sa ubang mga koponan nga nag-atubang sa parehas nga mga kalisud.

So nagka busy mi gawas pagpatuman sa usa ka mekanismo alang sa paglimpyo sa mga imahe - imbes sa mga kapabilidad nga gitukod na sa mga rehistro alang sa mga sudlanan. Ang una nga lakang mao ang paggamit sa Docker Registry API sa paghimo sa parehas nga primitive nga mga palisiya alang sa gidaghanon sa mga tag ug ang oras sa ilang paglalang (gihisgot sa ibabaw). Gidugang kanila tugoti ang lista base sa mga imahe nga gigamit sa gipakatap nga imprastraktura, i.e. Kubernetes. Alang sa naulahi, igo na nga gamiton ang Kubernetes API aron mabag-o ang tanan nga gipakatap nga mga kapanguhaan ug makakuha usa ka lista sa mga kantidad. image.

Kining gamay nga solusyon nakasulbad sa labing kritikal nga problema (kriterya Num. 1), apan mao lamang ang sinugdanan sa among panaw aron mapaayo ang mekanismo sa pagpanglimpyo. Ang sunod - ug mas makapaikag - nga lakang mao ang desisyon i-asoy ang gipatik nga mga imahe sa kasaysayan sa Git.

Mga laraw sa pag-tag

Sa pagsugod, gipili namon ang usa ka pamaagi diin ang katapusan nga imahe kinahanglan magtipig sa kinahanglan nga kasayuran alang sa paglimpyo, ug gitukod ang proseso sa mga laraw sa pag-tag. Sa pagmantala sa usa ka hulagway, ang user mipili ug usa ka espesipikong opsyon sa pag-tag (git-branch, git-commit o git-tag) ug gigamit ang katumbas nga kantidad. Sa mga sistema sa CI, kini nga mga kantidad awtomatiko nga gitakda base sa mga variable sa palibot. Sa pagkatinuod ang kataposang hulagway nalangkit sa usa ka espesipikong Git primitive, pagtipig sa gikinahanglan nga datos alang sa paglimpyo sa mga label.

Kini nga pamaagi miresulta sa usa ka hugpong sa mga palisiya nga nagtugot sa Git nga gamiton isip usa ka tinubdan sa kamatuoran:

• Kung gitangtang ang usa ka sanga/tag sa Git, ang mga kauban nga imahe sa rehistro awtomatiko nga natangtang.
• Ang gidaghanon sa mga hulagway nga nalangkit sa Git tag ug commit mahimong kontrolahon pinaagi sa gidaghanon sa mga tag nga gigamit sa pinili nga schema ug sa panahon diin ang nalambigit nga commit gihimo.

Sa kinatibuk-an, ang resulta nga pagpatuman nakatagbaw sa among mga panginahanglan, apan usa ka bag-ong hagit sa wala madugay naghulat kanamo. Ang tinuod mao nga samtang naggamit sa mga laraw sa pag-tag base sa mga primitibo sa Git, nakasugat kami daghang mga kakulangan. (Tungod kay ang ilang paghulagway lapas pa sa kasangkaran niini nga artikulo, ang tanan mahimong pamilyar sa mga detalye dinhi.) Busa, nga nakahukom nga mobalhin sa usa ka mas episyente nga pamaagi sa pag-tag (pag-tag nga nakabase sa sulud), kinahanglan namon nga hunahunaon pag-usab ang pagpatuman sa paglimpyo sa imahe.

Bag-ong algorithm

Ngano man? Uban sa content-based tagging, ang matag tag makatagbaw sa daghang mga commit sa Git. Kung nanglimpyo sa mga imahe, dili ka na maka-assume lamang gikan sa commit diin ang bag-ong tag gidugang sa rehistro.

Alang sa bag-ong algorithm sa paglimpyo, nakahukom nga mobalhin gikan sa mga laraw sa pag-tag ug magtukod proseso sa meta-imahe, nga ang matag usa nagtipig usa ka hugpong sa:

• ang pasalig diin gihimo ang publikasyon (dili igsapayan kung ang imahe gidugang, gibag-o o nagpabilin nga parehas sa rehistro sa sudlanan);
• ug ang among internal nga identifier nga katumbas sa gitigum nga imahe.

Sa laing pagkasulti, gihatag kini pag-link sa gipatik nga mga tag nga adunay mga commit sa Git.

Katapusan nga pagsumpo ug kinatibuk-ang algorithm

Kung gi-configure ang paglimpyo, ang mga tiggamit karon adunay access sa mga palisiya nga nagpili sa karon nga mga imahe. Ang matag polisiya gihubit:

• daghang mga pakisayran, i.e. Git tag o Git nga mga sanga nga gigamit sa pag-scan;
• ug ang limitasyon sa gipangita nga mga hulagway alang sa matag reperensiya gikan sa set.

Sa pag-ilustrar, mao kini ang hitsura sa default policy configuration:

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

Kini nga configuration adunay tulo ka mga palisiya nga nagsunod sa mosunod nga mga lagda:

1. I-save ang imahe para sa katapusang 10 ka Git tags (sa petsa sa paghimo sa tag).
2. Pagtipig og dili mosobra sa 2 ka mga hulagway nga gipatik sa miaging semana alang sa dili mosobra sa 10 ka mga thread nga adunay kalihokan sa miaging semana.
3. Tipigi ang 10 ka hulagway para sa mga sanga main, staging и production.

Ang katapusan nga algorithm gibahin ngadto sa mosunod nga mga lakang:

• Pagkuha sa mga manifests gikan sa container registry.
• Wala'y labot ang mga hulagway nga gigamit sa Kubernetes, tungod kay Gipili na namo sila daan pinaagi sa pagboto sa K8s API.
• Pag-scan sa kasaysayan sa Git ug dili iapil ang mga imahe base sa piho nga mga palisiya.
• Pagtangtang sa nahabilin nga mga imahe.

Pagbalik sa among ilustrasyon, mao kini ang mahitabo sa werf:

Bisan pa, bisan kung dili nimo gamiton ang werf, ang parehas nga pamaagi sa advanced nga paglimpyo sa imahe - sa usa ka pagpatuman o lain (sumala sa gusto nga pamaagi sa pag-tag sa imahe) - mahimong magamit sa ubang mga sistema/utilidad. Aron mahimo kini, igo na nga hinumdoman ang mga problema nga mitungha ug pangitaa ang mga oportunidad sa imong stack nga nagtugot kanimo sa paghiusa sa ilang solusyon nga hapsay kutob sa mahimo. Kami nanghinaut nga ang dalan nga among giagian makatabang kanimo sa pagtan-aw sa imong partikular nga kaso nga adunay bag-ong mga detalye ug mga hunahuna.

konklusyon

• Sa madugay o sa madali, kadaghanan sa mga team makasugat sa problema sa registry overflow.
• Kung nangita alang sa mga solusyon, kinahanglan una nga mahibal-an ang mga pamatasan alang sa kalabutan sa imahe.
• Ang mga himan nga gitanyag sa mga sikat nga serbisyo sa rehistro sa container nagtugot kanimo sa pag-organisar sa usa ka yano kaayo nga paglimpyo nga wala magtagad sa "gawas nga kalibutan": ang mga imahe nga gigamit sa Kubernetes ug ang mga peculiarities sa mga workflows sa team.
• Ang usa ka flexible ug episyente nga algorithm kinahanglan adunay pagsabut sa mga proseso sa CI / CD ug molihok dili lamang sa datos sa imahe sa Docker.

PS

Basaha usab sa among blog:

• «Ang pag-tag nga nakabase sa sulud sa werf builder: ngano ug giunsa kini paglihok?";
• «3-way merge to werf: deployment sa Kubernetes nga adunay Helm "sa mga steroid"";
• «Suporta alang sa monorepo ug multirepo sa werf ug unsa ang kalabotan sa Docker Registry niini";
• «werf 1.1 release: mga kalamboan sa magtutukod karon ug mga plano alang sa umaabot".

Source: www.habr.com