Označevanje na podlagi vsebine v zbiralniku werf: zakaj in kako deluje?

werf je naš odprtokodni pripomoček GitOps CLI za izdelavo in dostavo aplikacij v Kubernetes. IN izdaja v1.1 v zbiralniku slik je bila uvedena novost: označevanje slik po vsebini oz označevanje na podlagi vsebine. Do zdaj je tipična shema označevanja v werf vključevala označevanje slik Docker z oznako Git, Git vejo ali Git commit. Toda vse te sheme imajo pomanjkljivosti, ki jih nova strategija označevanja popolnoma odpravi. Podrobnosti o tem in zakaj je tako dober so pod rezom.

Uvajanje nabora mikrostoritev iz enega repozitorija Git

Pogosto pride do situacije, ko je aplikacija razdeljena na veliko bolj ali manj neodvisnih storitev. Izdaje teh storitev se lahko zgodijo neodvisno: ena ali več storitev se lahko sprostijo hkrati, ostale pa morajo delovati brez sprememb. Toda z vidika shranjevanja kode in vodenja projektov je bolj priročno hraniti takšne storitve aplikacij v enem samem repozitoriju.

Obstajajo situacije, ko so storitve resnično neodvisne in niso povezane z eno samo aplikacijo. V tem primeru bodo locirani v ločenih projektih, njihova izdaja pa bo izvedena prek ločenih procesov CI/CD v vsakem od projektov.

Vendar v resnici razvijalci pogosto razdelijo eno aplikacijo na več mikrostoritev, vendar je ustvarjanje ločenega repozitorija in projekta za vsako ... očitno pretirano. O tej situaciji bomo razpravljali še naprej: več takšnih mikrostoritev se nahaja v enem samem projektnem repozitoriju in izdaje se zgodijo prek enega samega procesa v CI/CD.

Označevanje po veji Git in oznaki Git

Recimo, da je uporabljena najpogostejša strategija označevanja – oznaka ali veja. Za veje Git so slike označene z imenom veje, za eno vejo naenkrat je objavljena samo ena slika z imenom te veje. Za oznake Git so slike označene glede na ime oznake.

Ko je ustvarjena nova oznaka Git – na primer, ko je izdana nova različica – bo ustvarjena nova oznaka Docker za vse slike projekta v registru Docker:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

Ta nova imena slik se posredujejo prek Helmovih predlog v konfiguracijo Kubernetes. Ko začnete razmestitev z ukazom werf deploy polje se posodablja image v manifestih virov Kubernetes in ponovnem zagonu ustreznih virov zaradi spremenjenega imena slike.

problem: v primeru, ko se dejansko vsebina slike ni spremenila od prejšnjega uvajanja (oznaka Git), ampak samo njena oznaka Docker, se to zgodi dodatno ponovnega zagona te aplikacije in posledično možnih nekaj izpadov. Čeprav ni bilo pravega razloga za ta ponovni zagon.

Posledično je pri trenutni shemi označevanja potrebno ograditi več ločenih repozitorijev Git in nastane težava pri organizaciji uvajanja teh več repozitorijev. Na splošno se takšna shema izkaže za preobremenjeno in zapleteno. Bolje je združiti veliko storitev v en sam repozitorij in ustvariti oznake Docker, da ne bo nepotrebnih ponovnih zagonov.

Označevanje s potrditvijo Git

werf ima tudi strategijo označevanja, povezano z Git commits.

Git-commit je identifikator za vsebino repozitorija Git in je odvisen od zgodovine urejanja datotek v repozitoriju Git, zato se zdi logično, da ga uporabite za označevanje slik v registru Docker.

Vendar ima označevanje s potrditvijo Git enake slabosti kot označevanje z vejami Git ali oznakami Git:

• Lahko se ustvari prazna potrditev, ki ne spremeni nobene datoteke, vendar bo spremenjena oznaka Docker slike.
• Ustvari se lahko potrditev združevanja, ki ne spremeni datotek, vendar bo spremenjena oznaka Docker slike.
• Izvede se lahko potrditev, ki spremeni tiste datoteke v Gitu, ki niso uvožene v sliko, in oznaka Docker slike bo znova spremenjena.

Označevanje imena veje Git ne odraža različice slike

S strategijo označevanja za veje Git je povezana še ena težava.

Označevanje po imenu veje deluje, dokler so objave na tej veji zbrane zaporedno v kronološkem vrstnem redu.

Če v trenutni shemi uporabnik začne znova graditi staro objavo, povezano z določeno vejo, bo werf prepisal sliko z uporabo ustrezne oznake Docker z novo zgrajeno različico slike za staro objavo. Razmestitve, ki bodo od zdaj naprej uporabljale to oznako, tvegajo, da bodo ob ponovnem zagonu podov potegnile drugo različico slike, zaradi česar bo naša aplikacija izgubila povezavo s sistemom CI in postala desinhronizirana.

Poleg tega se lahko z zaporednimi potiskanji v eno vejo s kratkim časovnim obdobjem med njimi stara potrditev prevede pozneje kot novejša: stara različica slike bo prepisala novo z uporabo oznake veje Git. Takšne težave je mogoče rešiti s sistemom CI/CD (na primer, v GitLab CI se cevovod slednjega zažene za niz potrditev). Vendar pa vsi sistemi tega ne podpirajo in obstajati mora zanesljivejši način za preprečevanje tako temeljne težave.

Kaj je označevanje na podlagi vsebine?

Torej, kaj je vsebinsko označevanje – označevanje slik po vsebini.

Za ustvarjanje oznak Docker se ne uporabljajo primitivi Git (veja Git, oznaka Git ...), temveč kontrolna vsota, povezana z:

• vsebino slike. Oznaka ID slike odraža njeno vsebino. Pri gradnji nove različice se ta identifikator ne bo spremenil, če se datoteke na sliki niso spremenile;
• zgodovino ustvarjanja te slike v Gitu. Slike, povezane z različnimi vejami Git in različno zgodovino gradnje prek werf, bodo imele različne ID oznake.

Takšna identifikacijska oznaka je t.i slikovni odrski podpis.

Vsaka slika je sestavljena iz niza stopenj: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch itd. Vsaka stopnja ima identifikator, ki odraža njeno vsebino − odrski podpis (odrski podpis).

Končna slika, sestavljena iz teh stopenj, je označena s tako imenovanim podpisom nabora teh stopenj – stopnje podpis, - ki je posplošen za vse stopnje slike.

Za vsako sliko iz konfiguracije werf.yaml v splošnem primeru bo obstajal lasten podpis in s tem oznaka Docker.

Stage signature rešuje vse te težave:

• Odporen na prazne Git potrditve.
• Odporen na Git zaveze, ki spreminjajo datoteke, ki niso pomembne za sliko.
• Ne povzroča težave s prenovo trenutne različice slike pri ponovnem zagonu gradenj za stare objave Git veje.

To je zdaj priporočena strategija označevanja in je privzeta v werf za vse sisteme CI.

Kako omogočiti in uporabljati v werf

Ukaz ima zdaj ustrezno možnost werf publish: --tag-by-stages-signature=true|false

V sistemu CI je strategija označevanja določena z ukazom werf ci-env. Prej je bil zanj določen parameter werf ci-env --tagging-strategy=tag-or-branch. Zdaj, če določite werf ci-env --tagging-strategy=stages-signature ali ne določite te možnosti, bo werf privzeto uporabil strategijo označevanja stages-signature. Ekipa werf ci-env samodejno nastavi potrebne zastavice za ukaz werf build-and-publish (Ali werf publish), zato za te ukaze ni treba podati dodatnih možnosti.

Na primer ukaz:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... lahko ustvari naslednje slike:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Tukaj 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d je podpis stopenj slike backendIn f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - podpis faz slike frontend.

Pri uporabi posebnih funkcij werf_container_image и werf_container_env V predlogah Helm ni treba ničesar spreminjati: te funkcije bodo samodejno ustvarile pravilna imena slik.

Primer konfiguracije v sistemu CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Več informacij o konfiguraciji je na voljo v dokumentaciji:

• Imenik → Objava (objavi);
• Delo s CI/CD → Splošne informacije → faze-podpis;
• Integracija z GitLab CI/CD → .gitlab-ci.yml.

Skupno

• Nova možnost werf publish --tag-by-stages-signature=true|false.
• Nova vrednost opcije werf ci-env --tagging-strategy=stages-signature|tag-or-branch (če ni navedeno, bo privzeto stages-signature).
• Če ste predhodno uporabljali možnosti označevanja za Git commits (WERF_TAG_GIT_COMMIT ali možnost werf publish --tag-git-commit COMMIT), potem obvezno preklopite na strategijo označevanja stopnje-podpis.
• Nove projekte je bolje takoj preklopiti na novo shemo označevanja.
• Pri prehodu na werf 1.1 je priporočljivo preklopiti stare projekte na novo shemo označevanja, vendar staro oznaka ali veja je še vedno podprt.

Označevanje na podlagi vsebine rešuje vse težave, obravnavane v članku:

• Odpornost imen oznake Docker na prazne potrditve Git.
• Odpornost imena oznake Docker na potrditev Git, ki spremeni datoteke, ki niso pomembne za sliko.
• Ne povzroča težave pri prenovi trenutne različice slike pri ponovnem zagonu gradenj za stare Git potrditev za Git veje.

Uporabi! In ne pozabite nas obiskati na GitHubustvariti težavo ali poiskati obstoječo, dodati plus, ustvariti PR ali preprosto opazovati razvoj projekta.

PS

Preberite tudi na našem blogu:

• «izdaja werf 1.1: današnje izboljšave graditelja in načrti za prihodnost»
• «Predstavljamo werf 1.0 stable: kaj ima GitOps s tem, stanje in načrti»
• «werf - naše orodje za CI/CD v Kubernetesu (pregled in video poročilo)»;
• Niz opomb o novostih v werf:
  • «3-smerno spajanje z werf: uvedba v Kubernetes s Helmom "na steroidih"»;
  • «Uporaba werf za uvajanje kompleksnih grafikonov Helm»;
  • «Podpora za monorepo in multirepo v werf in kaj ima s tem Docker Registry»;
  • «Zdaj lahko gradite slike Docker v werf z uporabo običajne datoteke Docker".

Vir: www.habr.com