Označování založené na obsahu v nástroji pro tvorbu werf: proč a jak funguje?

werf je náš open source nástroj GitOps CLI pro vytváření a dodávání aplikací do Kubernetes. V vydání v1.1 ve sběrači obrázků byla zavedena nová funkce: označování obrázků podle obsahu popř značkování založené na obsahu. Až dosud typické schéma značkování ve werf zahrnovalo značkování obrázků Docker pomocí značky Git, větve Git nebo commitu Git. Všechna tato schémata však mají nevýhody, které zcela řeší nová strategie značkování. Podrobnosti o něm a proč je tak dobrý jsou pod řezem.

Zavedení sady mikroslužeb z jednoho úložiště Git

Často nastává situace, kdy je aplikace rozdělena do mnoha více či méně nezávislých služeb. Uvolnění těchto služeb může probíhat nezávisle: jedna nebo více služeb může být uvolněno najednou, zatímco ostatní musí nadále fungovat bez jakýchkoli změn. Ale z hlediska ukládání kódu a projektového řízení je pohodlnější mít takové aplikační služby v jediném úložišti.

Existují situace, kdy jsou služby skutečně nezávislé a nejsou spojeny s jedinou aplikací. V tomto případě budou umístěny v samostatných projektech a jejich vydání bude probíhat prostřednictvím samostatných procesů CI/CD v každém z projektů.

Ve skutečnosti však vývojáři často rozdělují jednu aplikaci do několika mikroslužeb, ale vytvoření samostatného repozitáře a projektu pro každou... je jasná nadsázka. Právě o této situaci se bude diskutovat dále: několik takových mikroslužeb je umístěno v jediném úložišti projektu a k vydáním dochází prostřednictvím jediného procesu v CI/CD.

Tagování podle větve Git a tagu Git

Řekněme, že se používá nejběžnější strategie značkování – tag-or-branch. Pro větve Git jsou obrázky označeny názvem větve, pro jednu větev je vždy publikován pouze jeden obrázek podle názvu této větve. U značek Git jsou obrázky označeny podle názvu značky.

Když je vytvořena nová značka Git – například když je vydána nová verze – vytvoří se nová značka Docker pro všechny obrazy projektu 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

Tyto nové názvy obrázků jsou předány přes šablony Helm do konfigurace Kubernetes. Při spuštění nasazení příkazem werf deploy pole se aktualizuje image v manifestech prostředku Kubernetes a restartování odpovídajících prostředků kvůli změněnému názvu obrázku.

problém: v případě, kdy se ve skutečnosti od předchozího zavedení nezměnil obsah obrázku (tag Git), ale pouze jeho tag Docker, stane se to zbytečné restartování této aplikace a v důsledku toho je možný určitý výpadek. I když k provedení tohoto restartu nebyl žádný reálný důvod.

V důsledku toho je při současném schématu označování nutné ohradit několik samostatných úložišť Git a vyvstává problém s organizací zavádění těchto několika úložišť. Obecně se takové schéma ukazuje jako přetížené a složité. Je lepší spojit mnoho služeb do jednoho úložiště a vytvořit Docker tagy, aby nedocházelo ke zbytečným restartům.

Označování pomocí commitu Git

werf má také strategii označování spojenou s Git commity.

Git-commit je identifikátor obsahu úložiště Git a závisí na historii úprav souborů v úložišti Git, takže se zdá logické použít jej pro označování obrázků v registru Docker.

Tagování pomocí Git commit má však stejné nevýhody jako tagování pomocí větví Git nebo tagů Git:

• Mohlo by být vytvořeno prázdné potvrzení, které nezmění žádné soubory, ale změní se Docker tag obrázku.
• Mohlo by být vytvořeno slučovací potvrzení, které nezmění soubory, ale změní se Docker tag obrázku.
• Mohlo by být provedeno potvrzení, které změní ty soubory v Gitu, které nejsou importovány do obrázku, a značka Docker obrázku se znovu změní.

Označení názvu větve Git neodráží verzi obrázku

Se strategií značkování pro větve Git souvisí další problém.

Označování podle názvu větve funguje, pokud jsou odevzdání na této větvi shromažďována postupně v chronologickém pořadí.

Pokud v aktuálním schématu uživatel zahájí přestavbu starého odevzdání spojeného s určitou větví, pak werf přepíše obrázek pomocí odpovídajícího tagu Docker s nově vytvořenou verzí obrázku pro staré potvrzení. Nasazení využívající tuto značku od nynějška riskují, že při restartování modulů natáhnou jinou verzi obrazu, v důsledku čehož naše aplikace ztratí spojení se systémem CI a dojde k desynchronizaci.

Navíc při postupných přesunech do jedné větve s krátkým časovým odstupem mezi nimi může být staré potvrzení zkompilováno později než novější: stará verze obrazu přepíše novou pomocí tagu větve Git. Takové problémy lze vyřešit pomocí systému CI/CD (například v GitLab CI je spuštěn kanál CI pro řadu potvrzení). Ne všechny systémy to však podporují a musí existovat spolehlivější způsob, jak takovému zásadnímu problému předejít.

Co je značkování založené na obsahu?

Takže, co je obsahově orientované značkování - značkování obrázků podle obsahu.

K vytvoření značek Docker se nepoužívají primitiva Git (větev Git, značka Git...), ale kontrolní součet spojený s:

• obsah obrázku. Značka ID obrázku odráží její obsah. Při vytváření nové verze se tento identifikátor nezmění, pokud se nezměnily soubory v obraze;
• historie vytváření tohoto obrázku v Gitu. Obrázky spojené s různými větvemi Git a různou historií sestavení přes werf budou mít různé ID tagy.

Takovým identifikačním štítkem je tzv podpis obrazové scény.

Každý obrázek se skládá ze sady fází: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch atd. Každá fáze má identifikátor, který odráží její obsah − jevištní podpis (podpis).

Konečný obrázek, který se skládá z těchto fází, je označen takzvaným podpisem sady těchto fází - fáze podpisu, - což je zobecnění pro všechny fáze obrazu.

Pro každý obrázek z konfigurace werf.yaml v obecném případě bude mít svůj vlastní podpis a podle toho i značku Docker.

Podpis fáze řeší všechny tyto problémy:

• Odolné vůči vyprázdnění Git commitů.
• Resistant to Git odevzdává, které mění soubory, které nejsou relevantní pro obraz.
• Nevede k problému s přepracováním aktuální verze obrazu při restartování sestavení pro staré Git commity větve.

Toto je nyní doporučená strategie značkování a je výchozí ve werf pro všechny systémy CI.

Jak povolit a používat ve werf

Příkaz má nyní odpovídající volbu werf publish: --tag-by-stages-signature=true|false

V systému CI je strategie označování specifikována příkazem werf ci-env. Dříve pro něj byl parametr definován werf ci-env --tagging-strategy=tag-or-branch. Nyní, pokud specifikujete werf ci-env --tagging-strategy=stages-signature nebo tuto možnost nezadávejte, werf použije strategii značkování ve výchozím nastavení stages-signature. tým werf ci-env automaticky nastaví potřebné příznaky pro příkaz werf build-and-publish (nebo werf publish), takže pro tyto příkazy není třeba zadávat žádné další možnosti.

Například příkaz:

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

...může vytvořit následující obrázky:

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

Zde 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d je podpis fází obrazu backenda f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - podpis fází obrazu frontend.

Při použití speciálních funkcí werf_container_image и werf_container_env V šablonách Helm není potřeba nic měnit: tyto funkce automaticky vygenerují správné názvy obrázků.

Příklad konfigurace v systému CI:

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

Více informací o konfiguraci je k dispozici v dokumentaci:

• Adresář → Publikace (publikovat);
• Práce s CI/CD → Obecné informace → fáze-podpis;
• Integrace s GitLab CI/CD → .gitlab-ci.yml.

Celkem

• Nová možnost werf publish --tag-by-stages-signature=true|false.
• Nová hodnota opce werf ci-env --tagging-strategy=stages-signature|tag-or-branch (pokud není uvedeno, výchozí bude stages-signature).
• Pokud jste dříve používali možnosti označování pro odevzdání Git (WERF_TAG_GIT_COMMIT nebo možnost werf publish --tag-git-commit COMMIT), pak nezapomeňte přejít na strategii označování etapy-podpis.
• Je lepší okamžitě přepnout nové projekty na nové schéma označování.
• Při převodu na werf 1.1 je vhodné přepnout staré projekty na nové schéma označování, ale staré tag-or-branch je stále podporován.

Označování založené na obsahu řeší všechny problémy popsané v článku:

• Odolnost názvu značky Docker vůči prázdným potvrzením Git.
• Odolnost názvu značky Docker vůči systému Git, který změní soubory, které nejsou pro obrázek relevantní.
• Nevede k problému s přepracováním aktuální verze obrazu při restartování sestavení pro staré Git commity pro Git větve.

Použij to! A nezapomeňte nás navštívit na GitHubvytvořit problém nebo najít existující, přidat plus, vytvořit PR nebo jednoduše sledovat vývoj projektu.

PS

Přečtěte si také na našem blogu:

• «Vydání werf 1.1: dnešní vylepšení stavitele a plány do budoucna»
• «Představujeme stabilní verzi werf 1.0: co s tím má společného GitOps, stav a plány»
• «werf - náš nástroj pro CI / CD v Kubernetes (přehled a videoreportáž)";
• Řada poznámek o inovacích ve werf:
  • «Třícestné sloučení do werf: nasazení do Kubernetes s Helmem „na steroidech“";
  • «Použití werf k zavedení složitých Helmových diagramů";
  • «Podpora pro monorepo a multirepo ve werf a co s tím má společného Docker Registry";
  • «Nyní můžete vytvářet obrazy Docker ve werf pomocí běžného souboru Docker".

Zdroj: www.habr.com