A mono-tár témáját többször megvitatták, és általában nagyon aktív vitákat vált ki. A teremtéssel mint egy nyílt forráskódú eszköz, amelyet arra terveztek, hogy javítsa az alkalmazáskód Gitből a Docker képfájlokba való felépítését (majd a Kubernetesbe való eljuttatását), nem sokat gondolkodunk azon, hogy melyik a legjobb választás. Számunkra elsődleges, hogy a különböző vélemények támogatói számára minden szükségeset megadjunk (persze, ha ez nem mond ellent a józan észnek).
A werf legutóbbi mono-repo támogatása jó példa erre. De először nézzük meg, hogy ez a támogatás általában hogyan kapcsolódik a werf használatához, és mi köze van a Docker Registry-hez...
Problémák
Képzeljünk el egy ilyen helyzetet. A cégnél számos fejlesztőcsapat dolgozik független projekteken. A legtöbb alkalmazás Kubernetesen fut, ezért konténerbe van helyezve. A konténerek, képek tárolásához rendszerleíró adatbázisra (nyilvántartásra) van szükség. Ilyen nyilvántartásként a vállalat egyetlen fiókkal használja a Docker Hubot COMPANY. A legtöbb forráskód-tároló rendszerhez hasonlóan, A Docker Hub nem engedélyezi a beágyazott lerakathierarchiát, mint például COMPANY/PROJECT/IMAGE. Ebben az esetben… hogyan tárolhat nem monolitikus alkalmazásokat a rendszerleíró adatbázisban ezzel a korlátozással anélkül, hogy minden projekthez külön fiókot hozna létre?
Lehet, hogy a leírt szituáció valakinek első kézből ismerős, de nézzük meg általánosságban az alkalmazástárolás megszervezésének kérdését, pl. a fenti példára és a Docker Hubra való hivatkozás nélkül.
Megoldások
Ha az alkalmazás monolitikus, egy képben érkezik, akkor nincs kérdés, és egyszerűen elmentjük a képeket a projekt konténer-nyilvántartásába.
Ha egy alkalmazás több összetevőként jelenik meg, mikroszolgáltatások, akkor bizonyos megközelítésre van szükség. Egy tipikus webalkalmazás példáján, amely két képből áll: frontend и backend - a lehetséges lehetőségek a következők:
- Tárolja a képeket külön beágyazott tárolókban:
- Tároljon mindent egy tárolóban, és vegye figyelembe a kép nevét a címkében, például az alábbiak szerint:
NB: Valójában van egy másik lehetőség a különböző adattárakba való mentéssel, PROJECT-frontend и PROJECT-backend, de nem vesszük figyelembe a támogatás, a szervezés és a jogok felhasználók közötti elosztása bonyolultsága miatt.
werf támogatás
Kezdetben a werf a beágyazott tárolókra korlátozódott – szerencsére a legtöbb nyilvántartás támogatja ezt a funkciót. Verziótól kezdve , hozzáadott munka regiszterekkel, amelyekben a beágyazás nem támogatott, és a Docker Hub az egyik ilyen. Ettől kezdve a felhasználó választhat, hogyan tárolja az alkalmazásképeket.
Megvalósítás opcióként elérhető --images-repo-mode=multirepo|monorepo (alapértelmezett multirepo, azaz tárolás beágyazott tárolókban). Meghatározza azokat a mintákat, amelyek alapján a képek a rendszerleíró adatbázisban tárolódnak. Az alapparancsok használatakor elég kiválasztani a kívánt módot, és minden más változatlan marad.
Mert a legtöbb werf beállítás beállítható Környezeti változókCI / CD rendszerekben a tárolási mód általában könnyen beállítható globálisan a teljes projektre vonatkozóan. Például, a GitLab esetében csak adjon hozzá egy környezeti változót a projektbeállításokhoz: Beállítások -> CI / CD -> Változók: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ha már a képek közzétételéről és az alkalmazások bevezetéséről beszélünk (ezekről a folyamatokról részletesen a vonatkozó dokumentációs cikkekben olvashat: и ), akkor a mód kizárólag azt a sablont határozza meg, amellyel a képpel dolgozhat.
Az ördög a részletekben rejlik
A különbség és a fő nehézség egy új tárolási módszer hozzáadásakor a rendszerleíró adatbázis tisztításának folyamata (a werf által támogatott tisztítási funkciókat lásd ).
A tisztítás során a werf figyelembe veszi a Kubernetes-fürtökben használt képeket, valamint a felhasználó által konfigurált házirendeket. Az irányelvek a címkék stratégiákra való felosztásán alapulnak. Jelenleg támogatott stratégiák:
- 3 Git primitívekkel összekapcsolt stratégia, mint például a tag, a branch és a commit;
- 1 stratégia tetszőleges egyéni címkék számára.
A címkézési stratégiával kapcsolatos információkat a kép közzétételekor a végleges kép címkéibe mentjük. Maga a jelentés az ún meta tag - Egyes irányelvek alkalmazásához szükséges. Például, amikor töröl egy ágat vagy címkét egy Git-tárhelyről, logikus a kapcsolódó törlése felhasználatlan képeket a rendszerleíró adatbázisból, amelyre szabályzatunk egy része vonatkozik.
Egy lerakatba mentve (monorepo), a képcímkében a metatag mellett a kép neve is tárolható: PROJECT:frontend-META-TAG. Ezek elkülönítésére nem vezettünk be konkrét elválasztót, hanem publikáláskor egyszerűen hozzáadtuk a szükséges értéket a végleges kép címkéjéhez.
NB: Ha érdekel mindent, amit a werf forráskódban leírtak, akkor a kiindulópont lehet .
Ebben a cikkben nem fordítunk nagyobb figyelmet megközelítésünk problémáira és indokoltságára: 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 folyamat egészéről - mindezt Dmitrij Stolyarov közelmúltbeli jelentésében részletesen leírja: "".
Összegezve
A nem beágyazott regisztrációs adatbázisok támogatásának hiánya sem számunkra, sem az általunk ismert werf-felhasználók számára nem volt blokkoló tényező – elvégre mindig lehet külön képregisztrát emelni (vagy átváltani a Google Cloud feltételes Container Registry-re)... egy ilyen korlátozás megszüntetése logikusnak tűnt annak érdekében, hogy az eszköz kényelmesebb legyen a szélesebb DevOps közösség számára. Ennek megvalósítása során a konténer-nyilvántartás-tisztítási mechanizmus átdolgozása során szembesültünk a fő nehézséggel. Most, hogy minden készen van, jó felismerni, hogy valakinek könnyebbé vált, és nekünk (mint a projekt fő fejlesztőinek) nem lesz észrevehető nehézsége ennek a funkciónak a további támogatása.
Tartson velünk, és hamarosan további újdonságokról is beszámolunk !
PS
Olvassa el blogunkon is:
- «";
- «".
Forrás: will.com