Téma monorepozitára bola diskutovaná viac ako raz a spravidla vyvoláva veľmi aktívnu polemiku. Vytváraním ako nástroj s otvoreným zdrojovým kódom určený na zlepšenie procesu vytvárania aplikačného kódu z obrázkov Git do obrázkov Docker (a ich následné doručovanie do Kubernetes), veľmi nepremýšľame o tom, ktorá voľba je najlepšia. Pre nás je primárne zabezpečiť všetko potrebné pre zástancov rôznych názorov (ak to samozrejme neodporuje zdravému rozumu).
Nedávna podpora mono-repo od werf je toho dobrým príkladom. Najprv si však poďme zistiť, ako táto podpora vo všeobecnosti súvisí s používaním werf a čo s tým má spoločné register Docker ...
Problémy
Predstavme si takúto situáciu. Spoločnosť má veľa vývojových tímov pracujúcich na nezávislých projektoch. Väčšina aplikácií beží na Kubernetes, a preto sú kontajnerizované. Na ukladanie kontajnerov, obrázkov potrebujete register (register). Ako taký register spoločnosť používa Docker Hub s jediným účtom COMPANY. Podobne ako väčšina systémov na ukladanie zdrojových kódov, Docker Hub vám neumožňuje vytvárať vnorenú hierarchiu úložísk, ako napr COMPANY/PROJECT/IMAGE. V takom prípade... ako môžete ukladať nemonolitické aplikácie do registra s týmto obmedzením bez vytvorenia samostatného účtu pre každý projekt?
Možno je opísaná situácia niekomu známa z prvej ruky, ale zvážme otázku organizácie ukladania aplikácií vo všeobecnosti, t.j. bez odkazu na vyššie uvedený príklad a Docker Hub.
Riešenia
Ak aplikácia monolitický, prichádza v jednom obrázku, potom nie sú žiadne otázky a obrázky jednoducho uložíme do registra kontajnerov projektu.
Keď je aplikácia prezentovaná ako viacero komponentov, mikroslužby, potom je potrebný určitý prístup. Na príklade typickej webovej aplikácie pozostávajúcej z dvoch obrázkov: frontend и backend - možné možnosti sú:
- Ukladajte obrázky v samostatných vnorených úložiskách:
- Uložte všetko do jedného úložiska a zvážte názov obrázka v značke, napríklad takto:
NB: V skutočnosti existuje ďalšia možnosť s ukladaním do rôznych úložísk, PROJECT-frontend и PROJECT-backend, ale nebudeme to zvažovať z dôvodu zložitosti podpory, organizácie a rozdelenia práv medzi používateľov.
podpora werf
Spočiatku sa werf obmedzoval na vnorené úložiská – našťastie väčšina registrov túto funkciu podporuje. Počnúc verziou , pribudla práca s matrikami, v ktorých vnorenie nie je podporovanéa Docker Hub je jedným z nich. Od tohto momentu má používateľ na výber, ako uložiť obrázky aplikácie.
Implementácia dostupná pod možnosťou --images-repo-mode=multirepo|monorepo (predvolené multirepo, t.j. uloženie vo vnorených úložiskách). Definuje vzory, podľa ktorých sú obrázky uložené v registri. Pri používaní základných príkazov stačí zvoliť požadovaný režim a všetko ostatné zostane nezmenené.
Pretože väčšina možností werf sa dá nastaviť premenné prostredia, v systémoch CI / CD sa režim ukladania zvyčajne dá ľahko nastaviť globálne pre celý projekt. Napríklad, v prípade GitLab Stačí pridať premennú prostredia v nastaveniach projektu: Nastavenia -> CI / CD -> Premenné: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ak hovoríme o publikovaní obrázkov a zavádzaní aplikácií (o týchto procesoch si môžete podrobne prečítať v príslušných článkoch dokumentácie: и ), potom režim určuje iba šablónu, podľa ktorej môžete s obrázkom pracovať.
Diabol je v detailoch
Rozdiel a hlavný problém pri pridávaní novej metódy ukladania je v procese čistenia registra (Funkcie čistenia podporované werf nájdete v časti ).
Pri čistení werf berie do úvahy obrázky používané v klastroch Kubernetes, ako aj pravidlá nakonfigurované používateľom. Politiky sú založené na rozdelení značiek do stratégií. Aktuálne podporované stratégie:
- 3 stratégie prepojené primitívami Git, ako sú tag, branch a commit;
- 1 stratégia pre ľubovoľné vlastné značky.
Informáciu o stratégii tagov pri publikovaní obrázka ukladáme do štítkov finálneho obrázka. Samotný význam je tzv meta tag - Vyžaduje sa na uplatnenie niektorých zásad. Napríklad pri odstraňovaní vetvy alebo značky z úložiska Git je logické odstrániť súvisiace nepoužité obrázky z registra, na ktorý sa vzťahuje časť našich zásad.
Pri uložení do jedného úložiska (monorepo), v značke obrázka môže byť okrem metaznačky uložený aj názov obrázka: PROJECT:frontend-META-TAG. Na ich oddelenie sme nezaviedli žiadny konkrétny oddeľovač, ale jednoducho sme pridali potrebnú hodnotu k označeniu výsledného obrázka pri publikovaní.
NB: Ak máte záujem pozrieť si všetko popísané v zdrojovom kóde werf, potom východiskovým bodom môže byť .
V tomto článku nebudeme venovať väčšiu pozornosť problémom a opodstatnenosti nášho prístupu: o stratégiách označovania, ukladaní údajov do štítkov a publikačnom procese ako celku - to všetko je podrobne popísané v nedávnej správe Dmitrija Stolyarova: “".
Zhrnutie
Chýbajúca podpora pre nevnorené registre nebola pre nás ani pre nás známych používateľov werf blokujúcim faktorom – koniec koncov, vždy môžete vytvoriť samostatný register obrázkov (alebo prejsť na podmienený register kontajnerov v službe Google Cloud) ... odstránenie takéhoto obmedzenia sa zdalo logické, aby bol nástroj pohodlnejší pre širšiu komunitu DevOps. Pri jeho implementácii sme čelili hlavným problémom pri prepracovaní mechanizmu čistenia registra kontajnerov. Teraz, keď je všetko pripravené, je pekné si uvedomiť, že pre niekoho to bolo jednoduchšie a my (ako hlavní vývojári projektu) nebudeme mať žiadne výrazné ťažkosti s ďalšou podporou tejto funkcie.
Zostaňte s nami a čoskoro vám povieme o ďalších inováciách v !
PS
Prečítajte si aj na našom blogu:
- «»;
- «".
Zdroj: hab.com