Téma monorepozitáře bylo diskutováno více než jednou a zpravidla vyvolává velmi aktivní kontroverze. Tvořením jako nástroj s otevřeným zdrojovým kódem určený ke zlepšení procesu vytváření aplikačního kódu z obrázků Git do obrázků Docker (a jejich následného dodání do Kubernetes) moc nepřemýšlíme o tom, která volba je nejlepší. Pro nás je primární zajistit vše potřebné pro zastánce odlišných názorů (pokud to samozřejmě neodporuje zdravému rozumu).
Nedávná podpora mono-repo od werfu je toho dobrým příkladem. Nejprve si ale ujasněme, jak tato podpora obecně souvisí s používáním werf a co s tím má společného Docker Registry ...
Problémy
Představme si takovou situaci. Společnost má mnoho vývojových týmů pracujících na nezávislých projektech. Většina aplikací běží na Kubernetes, a jsou tedy kontejnerizované. K ukládání kontejnerů, obrázků potřebujete registr (registr). Jako takový registr společnost používá Docker Hub s jediným účtem COMPANY. Podobně jako u většiny systémů pro ukládání zdrojového kódu, Docker Hub neumožňuje vnořenou hierarchii úložiště, jako COMPANY/PROJECT/IMAGE. V tom případě… jak můžete ukládat nemonolitické aplikace do registru s tímto omezením, aniž byste pro každý projekt vytvořili samostatný účet?
Možná, že popsaná situace je někomu známá z první ruky, ale podívejme se na otázku organizace úložiště aplikací obecně, tj. bez odkazu na výše uvedený příklad a Docker Hub.
Řešení
Pokud aplikace monolitické, přichází v jednom obrázku, pak nejsou žádné otázky a obrázky jednoduše uložíme do registru kontejnerů projektu.
Když je aplikace prezentována jako více komponent, mikroslužby, pak je vyžadován určitý přístup. Na příkladu typické webové aplikace sestávající ze dvou obrázků: frontend и backend - možné možnosti jsou:
- Ukládejte obrázky do samostatných vnořených úložišť:
- Uložte vše do jednoho úložiště a zvažte název obrázku ve značce, například takto:
NB: Ve skutečnosti existuje další možnost s ukládáním do různých úložišť, PROJECT-frontend и PROJECT-backend, ale nebudeme o tom uvažovat kvůli složitosti podpory, organizace a rozdělení práv mezi uživatele.
podpora werf
Zpočátku se werf omezoval na vnořená úložiště – naštěstí tuto funkci podporuje většina registrů. Počínaje verzí , přidána práce s registry, ve kterých vnoření není podporovánoa Docker Hub je jedním z nich. Od tohoto okamžiku má uživatel na výběr, jak uložit obrázky aplikace.
Implementace dostupná pod opcí --images-repo-mode=multirepo|monorepo (výchozí multirepo, tj. úložiště ve vnořených úložištích). Definuje vzory, podle kterých jsou obrázky uloženy v registru. Stačí při používání základních příkazů zvolit požadovaný režim a vše ostatní zůstane beze změny.
Protože většinu možností werf lze nastavit proměnné prostředí, v systémech CI / CD je režim úložiště obvykle snadno nastavitelný globálně pro celý projekt. Například, v případě GitLabu stačí přidat proměnnou prostředí v nastavení projektu: Nastavení -> CI / CD -> Proměnné: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Pokud mluvíme o publikování obrázků a zavádění aplikací (o těchto procesech si můžete podrobně přečíst v příslušných článcích dokumentace: и ), pak režim určuje pouze šablonu, podle které můžete s obrázkem pracovat.
Ďábel je v detailech
Rozdíl a hlavní problém při přidávání nové metody ukládání je v procesu čištění registru (funkce čištění podporované werf viz ).
Při čištění bere werf v úvahu obrázky používané v clusterech Kubernetes a také zásady nakonfigurované uživatelem. Politiky jsou založeny na rozdělení značek do strategií. Aktuálně podporované strategie:
- 3 strategie propojené primitivy Git, jako je tag, branch a commit;
- 1 strategie pro libovolné vlastní značky.
Informace o strategii tagů při publikování obrázku ukládáme do popisků finálního obrázku. Samotný význam je tzv meta tag - Vyžaduje použití některých zásad. Například při odstraňování větve nebo značky z úložiště Git je logické odstranit související nepoužitý obrázky z registru, na který se vztahuje část našich zásad.
Při uložení do jednoho úložiště (monorepo), ve značce obrázku lze kromě značky metadat také uložit název obrázku: PROJECT:frontend-META-TAG. Abychom je oddělili, nezavedli jsme žádný konkrétní oddělovač, ale jednoduše jsme při publikování přidali potřebnou hodnotu štítku výsledného obrázku.
NB: Pokud máte zájem podívat se na vše popsané ve zdrojovém kódu werf, pak výchozím bodem může být .
V tomto článku nebudeme věnovat více pozornosti problémům a zdůvodnění našeho přístupu: o strategiích označování, ukládání dat do štítků a publikačním procesu jako celku - to vše je podrobně popsáno v nedávné zprávě Dmitrije Stolyarova: “".
Shrnutí
Nedostatek podpory nevnořených registrů nebyl pro nás ani pro nás známé uživatele werf blokujícím faktorem – vždyť můžete vždy vytvořit samostatný registr bitových kopií (nebo přejít na podmíněný registr kontejnerů v Google Cloud) ... Nicméně, odstranění takového omezení se zdálo logické, aby byl nástroj pohodlnější pro širší komunitu DevOps. Při jeho implementaci jsme čelili hlavnímu problému při přepracování mechanismu čištění registru kontejnerů. Nyní, když je vše připraveno, je příjemné si uvědomit, že se to pro někoho stalo jednodušší a my (jako hlavní vývojáři projektu) nebudeme mít žádné znatelné potíže s další podporou této funkce.
Zůstaňte s námi a velmi brzy vám povíme o dalších novinkách v !
PS
Přečtěte si také na našem blogu:
- «";
- «".
Zdroj: www.habr.com