🥇Označovanie založené na obsahu v staviteľovi werf: prečo a ako to funguje?

werf — náš GitOps CLI nástroj s otvoreným kódom na zostavovanie a dodávanie aplikácií do Kubernetes. V verzii v1.1 bola predstavená nová funkcia v zostavovači obrazov: označovanie obrazov na základe obsahu alebo content-based tagging. Doteraz typická schéma označovania v werf predpokladala označovanie Docker obrazov na základe Git značiek, Git vetiev alebo Git commitov. Avšak všetky tieto schémy majú nedostatky, ktoré sú úplne vyriešené novou stratégiou označovania. Podrobnosti o nej a čo ju robí takou dobrou — pod katom.

Nasadenie súboru mikroslužieb z jedného Git repozitára

Často sa vyskytuje situácia, keď je aplikácia rozdelená na množstvo viac-menej nezávislých služieb. Uvoľnenia týchto služieb môžu prebiehať nezávisle: naraz môže byť uvoľnený jeden alebo viacero služieb, zvyšné musia pritom naďalej fungovať bez akýchkoľvek zmien. Ale z pohľadu ukladania kódu a správy projektu je pohodlnejšie držať takéto služby aplikácie v jednotnom repozitári.

Sú situácie, keď sú služby skutočne nezávislé a nie sú spojené s jednou aplikáciou. V takom prípade budú umiestnené v samostatných projektoch a ich uvoľnenie bude realizované cez samostatné procesy CI/CD v každom z projektov.

Avšak v skutočnosti vývojári často rozdeľujú jednotnú aplikáciu na niekoľko mikroslužieb, ale zakladať pre každú samostatný repozitár a projekt… — je zjavný overkill. Práve o tejto situácii bude ďalej reč: niekoľko takýchto mikroslužieb sa nachádza v jednotnom repozitári projektu a uvoľnenia prebiehajú prostredníctvom jedného procesu v CI/CD.

Označovanie podľa Git vetvy a Git značky

Povedzme, že sa používa najrozšírenejšia stratégia označovania — tag-or-branch. Pre Git vetvy sú obrazy označované názvom vetvy, pre jednu vetvu existuje v jednom momente iba jeden publikovaný obraz s názvom tejto vetvy. Pre Git značky sú obrazy označované príslušným menom značky.

Pri vytvorení novej Git značky — napríklad pri vydaní novej verzie — pre všetky obrazy projektu v Docker Registry bude vytvorený nový Docker tag:

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

Tieto nové názvy obrazov sa prenášajú cez Helm šablóny do konfigurácie Kubernetes. Pri spustení nasadenia príkazom werf deploy sa aktualizuje pole obrázok v manifestoch zdrojov Kubernetes a reštartujú sa príslušné zdroje kvôli zmenenému názvu obrazu.

Problém: v prípade, že sa obsah obrazu reálne nezmenil od predchádzajúceho nasadenia (Git-tag), ale len jeho Docker-tag, dochádza k zbytočnému reštartu tejto aplikácie a môže nastat nejaký výpadok. Hoci neexistovali žiadne skutočné dôvody na vykonanie tohto reštartu.

Ako dôsledok, pri aktuálnej schéme značkovania je potrebné mať niekoľko samostatných Git-repozitárov a objavuje sa problém s organizáciou nasadenia týchto viacerých repozitárov. Celkovo sa taká schéma javí ako preťažená a zložitá. Je lepšie zlúčiť viac služieb do jedného repozitára a vytvárať také Docker-tagy, aby sa zabránilo zbytočným reštartom.

Značkovanie podľa Git-commit

V werf existuje aj stratégia značkovania súvisiaca s Git-commitmi.

Git-commit je identifikátor obsahu Git-repozitára a závisí od histórie zmien súborov v Git-repozitári, preto sa zdá logické používať ho na značkovanie obrazov v Docker Registry.

Avšak značkovanie podľa Git-commitu má tie isté nevýhody ako pri Git-branch alebo Git-tagoch:

Mohol byť vytvorený prázdny commit, ktorý nemení súbory, ale Docker-tag obrazu sa zmení.
Mohol byť vytvorený merge-commit, ktorý nemení súbory, ale Docker-tag obrazu sa zmení.
Mohol byť vytvorený commit, ktorý mení tie súbory v Git, ktoré sa do obrazu neprenášajú, a Docker-tag obrazu sa opäť zmení.

Značkovanie podľa názvu Git-branch neodráža verziu obrazu

Existuje aj ďalší problém súvisiaci so stratégiou značkovania podľa Git-branch.

Značkovanie podľa názvu vetvy funguje tak dlho, pokiaľ sú commity tejto vetvy zhromažďované postupne v chronologickom poradí.

Ak v aktuálnej schéme používateľ spustí znova zostavenie starého commitu spojeného s nejakou vetvou, werf prepíše obraz podľa zodpovedajúceho Docker-tagu novovytvorenou verziou obrazu pre starý commit. Deploymenty, ktoré používajú tento tag, riskujú, že počas reštartu podov stiahnu inú verziu obrazu, v dôsledku čoho naša aplikácia stratí spojenie s CI-systémom a sa desynchronizuje.

Okrem toho, pri sériových push-och do jednej vetvy s malým odstupom času medzi nimi môže starý commit byť spracovaný neskôr ako novší: staršia verzia obrazu prepisuje novú podľa tagu Git-vetvy. Takéto problémy môže riešiť CI/CD systém (napríklad v GitLab CI pre sériu commitov sa spúšťa pipeline posledného). Avšak, nie všetky systémy to podporujú a mal by existovať spoľahlivejší spôsob, ako zabrániť takejto základnej problémy.

Čo je to označovanie na základe obsahu?

Takže, čo presne znamená označovanie na základe obsahu — tagovanie obrazov podľa obsahu.

Na vytvorenie Docker-tagov sa používajú nie primitívy Git-u (Git-vetva, Git-tag…), ale kontrolná suma súvisiaca s:

obsahom obrazu. Identifikátor-tagu obrazu odráža jeho obsah. Pri zostavovaní novej verzie tento identifikátor nezmení, ak sa v obraze nezmenili súbory;
históriou vytvárania tohto obrazu v Gite. Obrazy, ktoré súvisia s rôznymi Git-vetvami a rôznou históriou zostavovania prostredníctvom werf, budú mať rôzne tag-identifikátory.

Ako taký tag-identifikátor slúži tzv. podpis fáz obrazu.

Každý obraz pozostáva z množiny fáz: z, before-install, git-archive, install, imports-after-install, before-setup,… git-latest-patch atď. Každá fáza má identifikátor, ktorý odráža jej obsah, — podpis fázy (podpis fázy).

Finálny obraz, pozostávajúci z týchto fáz, je tagovaný tzv. podpisom súboru týchto fáz — podpis fáz, — ktorý je zovšeobecňujúci pre všetky fázy obrazu.

Každý obraz z konfigurácie werf.yaml v zásade bude mať svoj vlastný taký podpis a, podľa toho, Docker-tag.

Podpis fáz rieši všetky uvedené problémy:

Je odolný voči prázdnym Git-commitom.
Je odolný voči Git-commitom, ktoré menia súbory, ktoré nie sú relevantné pre obraz.
Nevedie k problému s prepisovaním aktuálnej verzie obrazu pri opätovnom spustení zostavení pre staré Git-commity vetvy.

Teraz je to odporúčaná stratégia tagovania a používa sa predvolene v werf pre všetky CI systémy.

Ako zapnúť a používať v werf

Príslušná možnosť sa objavila u príkazu werf publish: --tag-by-stages-signature=true|false

V CI systéme sa stratégia tagovania nastavuje príkazom werf ci-env. Predtým bol pre ňu definovaný parameter werf ci-env --tagging-strategy=tag-or-branch. Teraz, ak je zadané werf ci-env --tagging-strategy=stages-signature alebo neudávať túto možnosť, werf predvolene použije stratégiu označovania stages-signature. Príkaz werf ci-env automaticky nastaví potrebné značky pre príkaz werf build-and-publish (alebo werf publish), preto nie je potrebné udávať žiadne ďalšie možnosti pre tieto príkazy.

Napríklad príkaz:

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

… môže vytvoriť nasledujúce obrazy:

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

Tu 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d — je to podpis fázy obrazu backend, a f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 — podpis fázy obrazu frontend.

Pri použití špeciálnych funkcií werf_container_image a werf_container_env v šablónach Helm nie je potrebné nič meniť: tieto funkcie automaticky vygenerujú správne názvy obrazov.

Príklad konfigurácie v CI systéme:

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

Viac informácií o konfigurácii je k dispozícii v dokumentácii:

Spolu

Nová možnosť werf publish --tag-by-stages-signature=true|false.
Nová hodnota možnosti werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ak nie je zadané, predvolene bude stages-signature).
Ak sa predtým používali možnosti označovania podľa Git commitov (WERF_TAG_GIT_COMMIT alebo možnosť werf publish --tag-git-commit COMMIT), je nevyhnutné prepnúť na stratégiu označovania stages-signature.
Nové projekty je najlepšie okamžite prepínať na novú schému označovania.
Staré projekty pri prechode na werf 1.1 je vhodné prepínať na novú schému označovania, avšak stará tag-or-branch je stále podporovaná.

Označovanie založené na obsahu vyrieši všetky problémy uvedené v článku:

Odolnosť názvu Docker tagu proti prázdnym Git commitom.
Odolnosť názvu Docker tagu proti Git commitom, ktoré menia pre obraz irelevantné súbory.
Nespôsobuje problém s prepísaním aktuálnej verzie obrazu pri opätovnom spustení zostáv pre staré Git commity pre Git vetvy.

Používajte! A nezabudnite nás navštíviť na GitHub, aby ste vytvorili issue alebo našli už existujúce, pridelili plus, vytvorili PR alebo jednoducho sledovali vývoj projektu.