Téma monorepozitára bola už viackrát diskutovaná a zvyčajne vyvoláva veľmi aktívne debaty. Pri vytváraní ako nástroja Open Source, ktorý má zlepšiť procesy zostavovania kódu aplikácií z Git do Docker obrazov (a ich následného dodávania do Kubernetes), málo premýšľame o tom, ktorá voľba je lepšia. Pre nás je primárne zabezpečiť všetko potrebné pre podporovateľov rôznych názorov (ak to samozrejme nie je v rozpore so zdravým rozumom).
Nedávno zavedená podpora mono-repo vo werf je dobrým príkladom. Ale najprv si poďme objasniť, ako je táto podpora vôbec spojená s používaním werf a aký to má súvis s Docker Registry…
Problém
Predstavme si takú situáciu. V spoločnosti existuje množstvo tímov vývojárov, ktorí pracujú na nezávislých projektoch. Väčšina aplikácií funguje v Kubernetes, a teda sú kontajnerizované. Na uchovávanie kontajnerov, obrazov, je potrebný registr. COMPANY. Podobne ako vo väčšine systémov správy zdrojového kódu, Docker Hub neumožňuje vytvárať vnorenú hierarchiu repozitárov, takú ako COMPANY/PROJECT/IMAGE. V takom prípade… ako teda s týmto obmedzením uchovávať v registri nemetóne aplikácie, bez vytvárania samostatného účtu pre každý projekt?
Možno je opísaná situácia niekomu známa, ale poďme zvážiť otázku organizovania uchovávania aplikácií vo všeobecnosti, t.j. bez spojenia s vyššie popísaným príkladom a Docker Hub.
Možnosti riešenia
Ak je aplikácia monolitná, dodáva sa v jednom obraze, takže nevznikajú žiadne otázky a jednoducho uchovávame obrazy v registri kontajnerov projektu.
Keď je aplikácia prezentovaná vo forme niekoľkých komponentov, mikroslužby, je potrebné zvoliť určitý prístup. Na príklade typickej webovej aplikácie, ktorá sa skladá z dvoch obrazov: frontend a backend — možné varianty sú nasledujúce:
- Uchovávať obrazy v samostatných vnorených repozitároch:
- Uchovávať všetko v jednom repozitári a názov obrazu zohľadniť v tage, napríklad takto:
Poznámka: Vlastne existuje ešte možnosť s uložením v rôznych repozitároch, PROJECT-frontend a PROJECT-backend, ale ten nebudeme zvažovať z dôvodu zložitosti podpory, organizácie a rozdelenia práv medzi používateľmi.
Podpora v werf
Pôvodne werf obmedzoval na vnútorné repozitáre — našťastie väčšina registri túto možnosť podporuje. Od verzie , bola pridaná podpora registri, v ktorých nie je podpora vnútornosti, vrátane Docker Hub. Od tejto chvíle má používateľ na výber, ako uchovávať obrazy aplikácie.
Realizácia je dostupná v rámci možnosti --images-repo-mode=multirepo|monorepo (predvolene multirepo, t.j. uchovávanie vo vnútorných repozitároch). Určuje šablóny, podľa ktorých sú obrazy uchovávané v registri. Stačí zvoliť požadovaný režim pri používaní základných príkazov, a všetko ostatné zostane nezmenené.
Keďže väčšinu možností werf je možné nastaviť premennými prostredia, v CI/CD systémoch je režim uchovávania zvyčajne ľ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í obrazov a nasadení aplikácií (o týchto procesoch sa môžete podrobne dočítať v príslušných článkoch dokumentácie: a ), režim rozhodne určuje šablónu, podľa ktorej môžete pracovať s obrazom.
Diabol je v detailoch
Rozdiel a hlavná zložitost pri pridávaní nového spôsobu uchovávania — v procese čistenia registry (možnosti čistenia, podporované vo werf, pozri v ).
Pri čistení werf zohľadňuje obrazy používané v klastroch Kubernetes a taktiež politiky, ktoré si používateľ prispôsobuje. Základom politík je rozdelenie tagov na stratégie. Takže, momentálne sú podporované tri stratégie:
- 3 stratégie, ktoré súvisia s Git primitívami, ako sú tag, vetva a commit;
- 1 stratégia pre ľubovoľné používateľské tagy.
Informácie o stratégii tagu uchovávame pri publikovaní obrazu v štítkoch konečného obrazu. Samotná hodnota — takzvaný metatag — je potrebná na uplatnenie časti politík. Napríklad, pri odstraňovaní vetvy alebo tagu z Git repozitára je logické odstrániť aj súvisiace nevyužité obrazy z registru, čo je pokryté časťou našich politík.
Pri uchovávaní v jednom repozitári (monorepo), v tagu obrazu môže byť okrem metatagu uložené aj meno obrazu: PROJEKT:frontend-META-TAG. Na ich rozdelenie sme nezaviedli žiadny špecifický oddelovač, ale jednoducho sme pridali potrebnú hodnotu do štítku konečného obrazu pri publikovaní.
Poznámka: Ak máte záujem pozrieť sa na všetko popísané v zdrojovom kóde werf, potom východiskovým bodom môže byť .
V tomto článku sa nebudeme venovať viac problematike a odôvodneniu nášho prístupu: o stratégiách tagovania, ukladaní údajov v štítkoch a procese publikovania celkovo — o všetkom tomto podrobne hovoril v nedávnej správe Dmitrij Stoljaro v: „».
Zhrňujúc
Nedostatok podpory pre registry bez vnorenia nebol pre nás ani pre známych používateľov werf blokujúcim faktorom — veď vždy je možné nastaviť samostatný registry obrázkov (alebo prejsť na podmienkový Container Registry v Google Cloud)… Avšak zrušenie takéhoto obmedzenia sa zdalo logické, aby bol nástroj pohodlný pre širšiu komunitu DevOps. Pri jeho realizácii sme sa stretli s hlavnou komplikáciou v prepracovaní mechanizmu čistenia registry kontajnerov. Teraz, keď je všetko pripravené, je príjemné si uvedomiť, že niekomu sa to uľahčilo, a u nás (ako hlavných vývojárov projektu) sa v ďalšej podpore tejto funkcie nepredpokladajú žiadne výrazné ťažkosti.
Zostaňte s nami a čoskoro vám povieme o ďalších novinkách v !
P.S.
Prečítajte si tiež na našom blogu:
- «»;
- «».
Zdroj: habr.com
