estas nia malfermfonta GitOps CLI-ilaĵo por konstrui kaj liveri aplikojn al Kubernetes. EN nova funkcio estis enkondukita en la bildkolektanto: etikedado de bildoj laŭ enhavo aŭ enhav-bazita etikedado. Ĝis nun, la tipa etikedskemo en werf implikis etikedi Docker-bildojn per Git-etikedo, Git-branĉo aŭ Git-kommit. Sed ĉiuj ĉi tiuj skemoj havas mankojn, kiuj estas tute solvitaj per la nova etikedstrategio. Detaloj pri ĝi kaj kial ĝi estas tiel bona estas sub la tranĉo.
Disvolvado de aro da mikroservoj el unu Git-deponejo
Situacio ofte okazas kiam aplikaĵo estas dividita en multajn pli-malpli sendependajn servojn. Eldonoj de ĉi tiuj servoj povas okazi sendepende: unu aŭ pluraj servoj povas esti liberigitaj samtempe, dum la ceteraj devas daŭre funkcii sen ajnaj ŝanĝoj. Sed el la vidpunkto de koda konservado kaj projekt-administrado, estas pli oportune konservi tiajn aplikaĵservojn en ununura deponejo.
Estas situacioj kiam servoj estas vere sendependaj kaj ne rilataj al ununura aplikaĵo. En ĉi tiu kazo, ili situos en apartaj projektoj kaj ilia liberigo estos efektivigita per apartaj CI/KD-procezoj en ĉiu el la projektoj.
Tamen, fakte, programistoj ofte disigas ununuran aplikaĵon en plurajn mikroservojn, sed krei apartan deponejon kaj projekton por ĉiu... estas klara troo. Estas ĉi tiu situacio kiu estos diskutita plu: pluraj tiaj mikroservoj situas en ununura projekta deponejo kaj eldonoj okazas per ununura procezo en CI/KD.
Etikedado per Git-branĉo kaj Git-etikedo
Ni diru, ke la plej ofta etikedstrategio estas uzata - etikedo-aŭ-branĉo. Por Git-branĉoj, bildoj estas etikeditaj kun la nomo de la branĉo, por unu branĉo samtempe ekzistas nur unu publikigita bildo sub la nomo de tiu branĉo. Por Git-etikedoj, bildoj estas etikeditaj laŭ la etikednomo.
Kiam nova Git-etikedo estas kreita—ekzemple, kiam nova versio estas publikigita—nova Docker-etikedo estos kreita por ĉiuj projektbildoj en la Docker-Registro:
-
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
Ĉi tiuj novaj bildnomoj estas pasigitaj tra Helm-ŝablonoj al la agordo de Kubernetes. Kiam oni komencas la disfaldon per la komando werf deploy kampo estas ĝisdatigita image en Kubernetes rimedo manifestiĝas kaj rekomencante la respondajn rimedojn pro la ŝanĝita bildonomo.
problemo: en la kazo kiam, fakte, la enhavo de la bildo ne ŝanĝiĝis ekde la antaŭa lanĉo (Git-etikedo), sed nur ĝia Docker-etikedo, tio okazas ekstra rekomenci ĉi tiun aplikaĵon kaj, sekve, iom da malfunkcio eblas. Kvankam ne estis vera kialo por fari ĉi tiun rekomencon.
Kiel rezulto, kun la nuna etikedskemo necesas bari plurajn apartajn Git-deponejojn kaj la problemo ekestas organizi la lanĉon de ĉi tiuj pluraj deponejoj. Ĝenerale, tia skemo montriĝas troŝarĝita kaj kompleksa. Pli bone estas kombini multajn servojn en ununuran deponejon kaj krei Docker-etikedojn por ke ne estu nenecesaj rekomencoj.
Etikedado per Git-komisio
werf ankaŭ havas etikedstrategion asociitan kun Git-komisioj.
Git-commit estas identigilo por la enhavo de Git-deponejo kaj dependas de la redakta historio de dosieroj en la Git-deponejo, do ŝajnas logike uzi ĝin por etikedi bildojn en la Docker-Registro.
Tamen, etikedado per Git-komisio havas la samajn malavantaĝojn kiel etikedado per Git-filioj aŭ Git-etikedoj:
- Malplena kommit povus esti kreita, kiu ne ŝanĝas ajnajn dosierojn, sed la Docker-etikedo de la bildo estos ŝanĝita.
- Kunfandigo povus esti kreita, kiu ne ŝanĝas la dosierojn, sed la Docker-etikedo de la bildo estos ŝanĝita.
- Oni povus fari kompromison, kiu ŝanĝas tiujn dosierojn en Git, kiuj ne estas importitaj en la bildon, kaj la Docker-etikedo de la bildo estos ŝanĝita denove.
Etikedado de Git-branĉnomo ne reflektas bildversion
Estas alia problemo asociita kun la etikedstrategio por Git-filioj.
Etikedado de branĉnomo funkcias tiel longe kiel la kommits sur tiu branĉo estas kolektitaj sinsekve en kronologia sinsekvo.
Se en la nuna skemo la uzanto komencas rekonstrui malnovan kommit asociitan kun certa branĉo, tiam werf reverkos la bildon uzante la respondan Docker-etikedon kun lastatempe konstruita versio de la bildo por la malnova kommit. Deplojoj uzantaj ĉi tiun etikedon de nun riskas eltiri malsaman version de la bildo dum rekomencado de podoj, pro tio nia aplikaĵo perdos konekton kun la CI-sistemo kaj malsinkroniĝos.
Krome, kun sinsekvaj puŝoj en unu branĉon kun mallonga tempodaŭro inter ili, la malnova kommit povas esti kompilita poste ol la pli nova: la malnova versio de la bildo anstataŭigos la novan uzante la Git-branĉetikedon. Tiaj problemoj povas esti solvitaj per CI/KD-sistemo (ekzemple, en GitLab CI la dukto de ĉi-lasta estas lanĉita por serio de kommits). Tamen, ne ĉiuj sistemoj subtenas ĉi tion kaj devas esti pli fidinda maniero malhelpi tian fundamentan problemon.
Kio estas enhav-bazita etikedado?
Do, kio estas enhav-bazita etikedado - etikedado de bildoj laŭ enhavo.
Por krei Docker-etikedojn, estas ne Git-primitivoj (Git-branĉo, Git-etikedo...) kiuj estas uzataj, sed ĉeksumo asociita kun:
- enhavo de la bildo. La bilda ID-etikedo reflektas ĝian enhavon. Konstruante novan version, ĉi tiu identigilo ne ŝanĝiĝos se la dosieroj en la bildo ne ŝanĝiĝis;
- historio de kreado de ĉi tiu bildo en Git. Bildoj asociitaj kun malsamaj Git-filioj kaj malsama konstruhistorio per werf havos malsamajn ID-etikedojn.
Tia identiga etikedo estas la tn bildo scenejo subskribo.
Ĉiu bildo konsistas el aro da stadioj: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ktp. Ĉiu etapo havas identigilon kiu reflektas ĝian enhavon − sceneja subskribo (scena subskribo).
La fina bildo, konsistanta el ĉi tiuj etapoj, estas etikedita kun la tielnomita subskribo de la aro de ĉi tiuj stadioj - etapoj subskribo, - kiu ĝeneraligas por ĉiuj etapoj de la bildo.
Por ĉiu bildo de la agordo werf.yaml en la ĝenerala kazo, estos sia propra subskribo kaj, sekve, Docker-etikedo.
La sceneja subskribo solvas ĉiujn ĉi tiujn problemojn:
- Imuna al malplenaj Git-komisioj.
- Resistant al Git faras ŝanĝajn dosierojn kiuj ne rilatas al la bildo.
- Ne kondukas al la problemo de revizio de la nuna versio de la bildo dum rekomenco de konstruoj por malnovaj Git-komisioj de branĉo.
Ĉi tio nun estas la rekomendita etikedstrategio kaj estas la defaŭlta en werf por ĉiuj CI-sistemoj.
Kiel ebligi kaj uzi en werf
La komando nun havas respondan opcion werf publish: --tag-by-stages-signature=true|false
En CI-sistemo, la etikedstrategio estas precizigita per la komando werf ci-env. Antaŭe, la parametro estis difinita por ĝi werf ci-env --tagging-strategy=tag-or-branch. Nun, se vi specifas werf ci-env --tagging-strategy=stages-signature aŭ ne specifu ĉi tiun opcion, werf uzos la etiked-strategion defaŭlte stages-signature. Teamo werf ci-env aŭtomate starigos la necesajn flagojn por la komando werf build-and-publish (aŭ werf publish), do neniuj aldonaj opcioj devas esti specifitaj por ĉi tiuj komandoj.
Ekzemple, la komando:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature...povas krei la jenajn bildojn:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
estas 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d estas subskribo de la etapoj de la bildo backendkaj f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - subskribo de bildaj etapoj frontend.
Kiam oni uzas specialajn funkciojn werf_container_image и werf_container_env Ne necesas ŝanĝi ion ajn en la Helm-ŝablonoj: ĉi tiuj funkcioj aŭtomate generos la ĝustajn bildnomojn.
Ekzempla agordo en CI-sistemo:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployPliaj informoj pri agordo haveblas en la dokumentado:
- ;
- ;
- .
Tuta
- Nova opcio
werf publish --tag-by-stages-signature=true|false. - Nova opciovaloro
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(se ne specifita, la defaŭlta estosstages-signature). - Se vi antaŭe uzis la etikedajn opciojn por Git-komisioj (
WERF_TAG_GIT_COMMITaŭ opciowerf publish --tag-git-commit COMMIT), tiam nepre ŝanĝu al la etikedstrategio etapoj-signaturo. - Pli bone estas tuj ŝanĝi novajn projektojn al la nova etikedskemo.
- Dum transdono al werf 1.1, estas konsilinde ŝanĝi malnovajn projektojn al la nova etikedskemo, sed la malnova etikedo-aŭ-branĉo estas ankoraŭ subtenata.
Enhav-bazita etikedado solvas ĉiujn problemojn kovritajn en la artikolo:
- Docker-etikedo-nomo-rezisto al malplenaj Git-komisioj.
- Rezisto de la nomo de la etikedo Docker al Git faras ŝanĝajn dosierojn senrilatajn al la bildo.
- Ne kondukas al la problemo de revizio de la nuna versio de la bildo dum rekomenco de konstruoj por malnovaj Git-komisioj por Git-filioj.
Uzi ĝin! Kaj ne forgesu viziti nin ĉe krei aferon aŭ trovi ekzistantan, aldoni pluson, krei PR aŭ simple rigardi la evoluon de la projekto.
PS
Legu ankaŭ en nia blogo:
- «»
- «»
- «»;
- Serio de notoj pri novigoj en werf:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com