A monorepo téma már több alkalommal is napirendre került, és általában rendkívül élénk vitákat vált ki. Amikor létrehozzuk mint egy nyílt forráskódú eszköz, amely a Gitből Docker képekbe történő alkalmazásforrás-kód buildelési folyamatainak javítására van hivatva (és azok későbbi továbbítására Kubernetesbe), ritkán gondolkodunk azon, hogy melyik opció a legjobb. Számunkra az elsődleges cél, hogy minden szükséges erőforrást biztosítsunk a különböző vélemények támogatói számára (ha ez nem ütközik az egészséges ész érvével, természetesen).
A werf mono-repo támogatásának nemrégiben bevezetett példája jól mutatja ezt. De először is, nézzük meg, hogyan kapcsolódik ez a támogatás a werf használatához és mi köze van a Docker Registryhez…
Problématika
Képzeljünk el egy ilyen helyzetet. Egy vállalatnál számos fejlesztőcsapat dolgozik független projekteken. Többnyire az alkalmazások Kubernetesben működnek, így konténerizálva vannak. A konténerek, képek tárolásához szükséges egy registry. A vállalat Docker Hubot használ egyetlen fiókkal CÉG. A legtöbb forráskód-tároló rendszerhez hasonlóan a Docker Hub nem engedi meg a beágyazott tárolói hierarchia létrehozását, mint például CÉG/PROJEKT/KÉP. Ilyen esetben… hogyan tárolhatjuk a registryben a nem monolitikus alkalmazásokat anélkül, hogy minden projekthez külön fiókot kellene létrehoznunk?
Lehetséges, hogy az itt leírt helyzet valakinek ismerős, de nézzük meg a kérdést az alkalmazások tárolásának megszervezéséről általánosságban, azaz anélkül, hogy kötődnénk a fent leírt példához és a Docker Hubhoz.
Megoldási javaslatok
Ha az alkalmazás monolitikus, egy képként kerül kiadásra, akkor nincsenek kérdések, és egyszerűen a projekt konténer registryjében tároljuk a képeket.
Amikor az alkalmazás több komponensből áll, mikroszolgáltatásokhoz, akkor bizonyos megközelítést kell választani. Például egy tipikus webalkalmazás esetén, amely két képből áll: frontend és backend — lehetséges lehetőségek a következők:
- Képek tárolása külön beágyazott tárolókban:
- Mindent egyetlen tárolóban tárolni, a képnév figyelembevételével a címkén, például így:
NB: Egyébként, van még egy lehetőség különböző tárolókból történő tárolásra, PROJEKT-frontend és PROJEKT-backend, de ezt nem fogjuk figyelembe venni a támogatás bonyolultsága, a szervezeté és a felhasználók közötti jogok elosztása miatt.
Támogatás a werf-ben
Eredetileg a werf a beágyazott tárolókra korlátozódott – szerencsére a legtöbb tároló ezt a lehetőséget támogatja. Az -tól kezdődően lehetőség nyílt olyan tárolókkal való munkára is, amelyek nem támogatják a beágyazást, köztük a Docker Hub is. Ezt követően a felhasználóknak lehetőségük nyílt választani, hogy hogyan tárolják az alkalmazás képeit.
A megvalósítás a következő opció keretein belül érhető el: --images-repo-mode=multirepo|monorepo (alapértelmezett multirepo, azaz képek tárolása beágyazott tárolókban). Ez határozza meg a mintákat, amelyek szerint a képek a tárolóban tárolódnak. Csak a szükséges módot kell kiválasztani a fő parancsok használatakor, és minden más változatlan marad.
Mivel a werf legtöbb opcióját lehet környezeti változókként beállítani, CI/CD rendszerekben a tárolási módot általában könnyű globálisan beállítani az egész projektre. PéldáulGitLab esetében elég egy környezeti változót hozzáadni a projekt beállításaiban: Beállítások -> CI / CD -> Változók: WERF_IMAGES_REPO_MODE: multirepo|monorepo Ha a képek kiadásáról és az alkalmazások telepítéséről beszélünk (erről a folyamatokról részletesen olvashatsz a megfelelő dokumentációs cikkekben:.
Kiadási folyamat és A részletek rejlenek a dologban
A legfőbb különbség és probléma egy új tárolási mód hozzáadásakor a registry tisztítási folyamata
(a werf által támogatott tisztítási lehetőségekről lásd a Tisztítási folyamat ).
3 stratégia, amelyek Git primitívjeivel, például taggel, branchnel és commit-tal kapcsolatosak;
- 1 stratégia tetszőleges felhasználói tagek számára.
- A tag stratégia információit a kép kiadása során mentjük el a végső kép címkéinél. Maga az érték – úgynevezett
metatag – szükséges egyes politikák alkalmazásához. Például, amikor egy branch vagy tag törölve van a Git tárolóból, logikus, hogy a kapcsolódó nem használt képek is törlésre kerüljenek a tárolóból, ami egy részét képezi politikáinknak. Amikor egy tárolóban mentünk el (
monorepo), a kép címkéjén a metatag mellett a kép neve is tárolható:), a képtagban a metacímkén kívül a kép nevét is tárolhatja: PROJEKT:frontend-META-JEGY. Nem vezettünk be speciális elválasztót a részek elválasztására, hanem egyszerűen hozzáadtuk a szükséges értéket a végső kép címkéjéhez a közzététel során.
NB: Ha érdekesnek találja a werf forráskódjában leírtakat, akkor kiindulópontként szolgálhat .
Ebben a cikkben nem fogunk további figyelmet szentelni a problémának és a megközelítésünk indoklásának: a címkézési stratégiákról, az adatok tárolásáról a címkékben és a közzétételi folyamatról általában - mindezekről részletesen számot adott Dmitrij Sztojlarov legutóbbi előadásában: „».
Összefoglalva
A többszintű tárolók támogatásának hiánya nem jelentett blokkoló tényezőt számunkra vagy a számunkra ismert werf felhasználók számára - hiszen mindig fel lehet állítani egy külön tárolót (vagy áttérni egy feltételes Container Registry-re a Google Cloud-ban)... Azonban ennek a korlátozásnak a megszüntetése logikusnak tűnt, hogy az eszköz kényelmesebb legyen a szélesebb DevOps közösség számára. A megvalósítás során a legfőbb nehézséget a konténer tároló tisztítási mechanizmusának átdolgozása jelentette. Most, hogy minden kész, öröm tudni, hogy valakinek könnyebb lett, és nekünk (mint a projekt fő fejlesztőinek) a jövőbeli támogatására ezen funkció tekintetében nem valószínűsíthetők komoly nehézségek.
Maradjanak velünk, és hamarosan mesélünk más újításokról a !
P.S.
Olvasson további információkat a blogunkban:
- «»;
- «».
Forrás: habr.com
