Téma monorepo bylo již mnohokrát diskutováno a obvykle vyvolává velmi aktivní debaty. Když vytváříme jako Open Source nástroj, který má zlepšit procesy sestavení kódu aplikací z Git do Docker obrazů (a jejich následného dodání do Kubernetes), málo přemýšlíme o tom, jaká volba je lepší. Naším primárním cílem je poskytnout všechno potřebné pro zastánce různých názorů (pokud to samozřejmě není v rozporu se zdravým rozumem).
Nedávno se objevila podpora mono-repo ve werf — dobrý příklad toho. Ale nejprve si ujasněme, jak tato podpora vlastně souvisí s používáním werf a co má společného s Docker Registry…
Problematika
Představme si takovou situaci. Ve firmě je mnoho týmů vývojářů, kteří pracují na nezávislých projektech. Většina aplikací funguje v Kubernetes, a tudíž jsou kontejnerizovány. Pro ukládání kontejnerů a obrazů je potřeba registr (registry). Jako takový registr ve firmě slouží Docker Hub s jediným účtem COMPANY. Podobně jako většina systémů pro ukládání zdrojového kódu, Docker Hub neumožňuje vytvářet vnořenou hierarchii repozitářů, jako například COMPANY/PROJECT/IMAGE. Jak tedy s tímto omezením uchovávat v registru nemonolitní aplikace, aniž bychom vytvářeli samostatný účet pro každý projekt?
Možná je uvedená situace někomu známá, ale pojďme se podívat na otázku organizace úložných systémů aplikací obecně, tedy bez vazby na výše uvedený příklad a Docker Hub.
Možnosti řešení
Pokud je aplikace monolitní, dodává se v jednom obraze, pak není žádný problém a jednoduše uchováváme obrazy v registru kontejnerů projektu.
Když je aplikace představena jako několik komponentů, mikroslužby, je třeba zvolit určitou strategii. Na příkladu typické webové aplikace, která se skládá ze dvou obrazů: frontend a backend — možné varianty jsou následující:
- Ukládat obrazy v samostatných vnořených repozitářích:
- Ukládat vše v jednom repozitáři a název obrazu zohledňovat v tagu, například následujícím způsobem:
NB: Existuje také další možnost s ukládáním v různých repozitářích, PROJECT-frontend a PROJECT-backend, ale tu nebudeme rozebírat kvůli složitosti podpory, organizace a rozdělení práv mezi uživateli.
Podpora ve werf
Zpočátku werf pracoval pouze s vnořenými repozitáři — naštěstí většina registrů tuto možnost podporuje. Od verze , byla přidána podpora pro registry, které nepodporují vnořenost, a Docker Hub je jedním z nich. Od té doby měl uživatel možnost vybrat, jak ukládat obrazové soubory aplikace.
Implementace je dostupná v rámci možnosti --images-repo-mode=multirepo|monorepo (výchozí hodnota je multirepo, tedy ukládání v vnořených repozitářích). Určuje vzory, podle kterých jsou obrazy uloženy v registru. Stačí zvolit požadovaný režim při použití základních příkazů, zbytek zůstane nezměněn.
Jelikož většinu voleb werf lze nastavovat pomocí proměnných prostředí, v CI/CD systém byl režim ukládání obvykle snadno nastavit globálně pro celý projekt. Například, v případě GitLab stačí přidat proměnnou prostředí v nastavení projektu: Nastavení -> CI / CD -> Proměnné: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Pokud jde o publikaci obrazů a nasazení aplikací (o těchto procesech si můžete přečíst podrobně v příslušných článcích dokumentace: a ), režim výhradně určuje vzor, podle kterého lze pracovat s obrazem.
Ďábel je v detailech
Rozdíl a hlavní obtíž při přidávání nového způsobu ukládání spočívá v procesu čištění registry (možnosti čištění podporované ve werf, viz ).
). Při čištění werf bere v úvahu obrazy používané v clusterech Kubernetes a také politiky nastavené uživateli. Základem politik je rozdělení tagů na strategie. Momentálně podporované strategie jsou:
- 3 strategie spojené s Git primitivy, jako jsou tag, větev a commity;
- 1 strategie pro libovolné uživatelské tagy.
Informace o strategii tagu uchováváme při publikaci obrazu v etiketách konečného obrazu. Samotná hodnota — tzv. metatag — je potřebná pro aplikaci částí politik. Například, při odstraňování větve nebo tagu z Git repozitáře je logické odstranit také související nepoužívané obrazy z registru, což pokrývá část našich politik.
Při ukládání do jednoho repozitáře (monorepo), v tagu obrazu může kromě metatagu být také uloženo jméno obrazu: PROJEKT:frontend-META-TAG. Pro jejich oddělení jsme nezavedli žádný specifický oddělovač, ale jednoduše jsme přidali požadovanou hodnotu do popisu koncového obrazu při publikaci.
NB: Pokud máte zájem podívat se na vše popsané v zdrojovém kódu werf, může být výchozím bodem .
V tomto článku se nebudeme dále zabývat problematikou a odůvodněním našeho přístupu: o strategiích označování, ukládání dat v popisech a procesu publikace jako celku — o tom všem bylo podrobně pojednáno v nedávné přednášce Dmitrije Stojarova: „».
Shrnuto
Nedostatek podpory registrů bez vnoření nebyl blokujícím faktorem pro nás ani pro známé uživatele werf — vždy je možné zprovoznit samostatný registr obrazů (nebo přejít na jakýsi Container Registry v Google Cloud)... Nicméně, zrušení takového omezení se zdálo logické, aby byl nástroj pohodlnější pro širší DevOps komunitu. Při jeho implementaci jsme narazili na hlavní obtížnost při přepracování mechanismu čištění registru kontejnerů. Nyní, když je vše hotovo, je potěšující vědět, že to někomu usnadnilo práci a nám (jako hlavním vývojářům projektu) se v budoucnosti nejeví žádné významné obtíže při další podpoře této funkce.
Zůstaňte s námi a brzy vám povíme o dalších novinkách v !
P.S.
Přečtěte si také náš blog:
- «»;
- «».
Zdroj: habr.com
