a nyílt forráskódú GitOps CLI segédprogramunk, amely alkalmazások készítésére és Kubernetes számára történő szállítására szolgál. Ígéret szerint, a werf új funkciókkal való kiegészítésének és a hagyományos megközelítések átdolgozásának kezdetét jelentette. Örömmel mutatjuk be a v1.1-es kiadást, amely nagy lépést jelent a fejlesztésben és a jövő alapja gyűjtő werf. A verzió jelenleg itt érhető el .
A kiadás alapja az új színpadi tárolási architektúra és mindkét gyűjtő munkájának optimalizálása (a Stapel és a Dockerfile esetében). Az új tárolóarchitektúra megnyitja a lehetőséget több gazdagépről származó elosztott összeállítások és párhuzamos összeállítások megvalósítására ugyanazon a gazdagépen.
A munka optimalizálása magában foglalja a szükségtelen számítások megszüntetését a szakasz-aláírások kiszámításának szakaszában, és a fájl-ellenőrző összegek kiszámításának mechanizmusait hatékonyabbra cserélik. Ez az optimalizálás csökkenti a projektek werf használatával történő felépítésének átlagos idejét. És tétlen buildek, amikor minden szakasz létezik a gyorsítótárban színpadok-tárolás, most nagyon gyorsak. A legtöbb esetben a build újraindítása kevesebb, mint 1 másodpercet vesz igénybe! Ez vonatkozik a munkacsoportok munkafolyamatának szakaszainak ellenőrzésére szolgáló eljárásokra is. werf deploy и werf run.
Ebben a kiadásban is megjelent a képek tartalom szerinti címkézésére vonatkozó stratégia - tartalom alapú címkézés, amely most alapértelmezés szerint engedélyezve van, és az egyetlen ajánlott.
Nézzük meg közelebbről a werf v1.1 legfontosabb újításait, és egyúttal meséljünk a jövőre vonatkozó tervekről.
Mi változott a werf v1.1-ben?
Új szakaszelnevezési formátum és algoritmus a szakaszok gyorsítótárból történő kiválasztásához
Új művésznévgenerálási szabály. Mostantól minden szakaszos összeállítás egyedi színpadnevet generál, amely 2 részből áll: egy aláírásból (ahogyan a v1.0-ban volt) és egy egyedi ideiglenes azonosítóból.
Például a színpadkép teljes neve így nézhet ki:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...vagy általában:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
itt:
-
SIGNATUREegy színpadi aláírás, amely a színpadi tartalom azonosítóját jelenti, és a Gitben végzett szerkesztések előzményeitől függ, amelyek ehhez a tartalomhoz vezettek; -
TIMESTAMP_MILLISECegy garantáltan egyedi képazonosító, amely egy új kép készítésekor jön létre.
A szakaszok gyorsítótárból történő kiválasztásának algoritmusa a Git commitok kapcsolatának ellenőrzésén alapul:
- Werf kiszámítja egy bizonyos szakasz aláírását.
- В színpadok-tárolás Egy adott aláíráshoz több szakasz is tartozhat. Werf kiválasztja az összes olyan szakaszt, amely megfelel az aláírásnak.
- Ha az aktuális szakasz Githez van kapcsolva (git-archívum, egyéni szakasz Git javításokkal:
install,beforeSetup,setup; vagy git-latest-patch), akkor a werf csak azokat a szakaszokat választja ki, amelyek egy olyan véglegesítéshez vannak társítva, amely az aktuális commit elődje (amelyhez a buildet hívják). - A fennmaradó megfelelő szakaszok közül kiválaszt egyet - a létrehozás dátuma szerint a legrégebbi.
A különböző Git-ágak szakasza ugyanazzal az aláírással rendelkezhet. A werf azonban megakadályozza, hogy a különböző ágakhoz társított gyorsítótárat ezek között az ágak között használják fel, még akkor is, ha az aláírások egyeznek.
.
Új algoritmus a szakaszok létrehozásához és mentéséhez a szakasztárolóban
Ha a szakaszok gyorsítótárból történő kiválasztásakor a werf nem talál megfelelő szakaszt, akkor elindul egy új szakasz összeállításának folyamata.
Vegye figyelembe, hogy több folyamat (egy vagy több gazdagépen) körülbelül ugyanabban az időben kezdheti el ugyanazt a szakaszt. A Werf optimista blokkoló algoritmust használ színpadok-tárolás a frissen gyűjtött kép mentésének pillanatában színpadok-tárolás. Így, amikor az új színpadi build készen áll, a werf blokkolja színpadok-tárolás és csak akkor menti el a frissen gyűjtött képet, ha ott már nem létezik megfelelő kép (aláírás és egyéb paraméterek alapján - lásd az új algoritmust a szakaszok gyorsítótárból történő kiválasztásához).
A frissen összeállított képnek garantáltan egyedi azonosítója lesz TIMESTAMP_MILLISEC (lásd az új színpadi elnevezési formátumot). Abban az esetben, ha be színpadok-tárolás megfelelő képet talál, a werf eldobja a frissen összeállított képet, és a gyorsítótárból használja a képet.
Más szóval: az első folyamat, amely befejezi a kép elkészítését (a leggyorsabb), megkapja a jogot a szakaszos tárolására (majd ezt az egyetlen képet fogja használni az összes összeállításhoz). A lassú felépítési folyamat soha nem akadályozza meg, hogy egy gyorsabb folyamat elmentse az aktuális szakasz összeállítási eredményeit, és továbblépjen a következő buildre.
.
Továbbfejlesztett Dockerfile-készítő teljesítmény
Jelenleg a Dockerfile-ból épített kép szakaszainak folyamata egy szakaszból áll - dockerfile. Az aláírás kiszámításakor a fájlok ellenőrző összege kerül kiszámításra context, amelyet az összeszerelés során használni fognak. A fejlesztés előtt a werf rekurzív módon végigjárta az összes fájlt, és az egyes fájlok kontextusának és módjának összegzésével ellenőrző összeget kapott. A v1.1-től kezdve a werf használhat egy Git-lerakatban tárolt számított ellenőrző összegeket.
Az algoritmus azon alapul . Az algoritmus figyelembe veszi a benne lévő rekordokat .dockerignore és csak szükség esetén járja be rekurzívan a fájlfát. Így elválasztottuk a fájlrendszer olvasását, és az algoritmus mérettől való függését context nem jelentős.
Az algoritmus a nem követett fájlokat is ellenőrzi, és szükség esetén figyelembe veszi az ellenőrző összegben.
Jobb teljesítmény fájlok importálásakor
A werf v1.1 verziói rsync kiszolgálót használnak, amikor . Korábban az importálás két lépésben történt, a gazdarendszerről származó könyvtárbeillesztés segítségével.
Az importálási teljesítményt macOS-en már nem korlátozzák a Docker-kötetek, és az importálás ugyanannyi idő alatt fejeződik be, mint a Linux és a Windows.
Tartalom alapú címkézés
A Werf v1.1 támogatja az úgynevezett képtartalom szerinti címkézést - tartalom alapú címkézés. Az eredményül kapott Docker-képek címkéi ezeknek a képeknek a tartalmától függenek.
A parancs futtatásakor werf publish --tags-by-stages-signature vagy werf ci-env --tagging-strategy=stages-signature megjelent képeket az ún színpadi aláírás kép. Minden kép a kép szakaszainak saját aláírásával van ellátva, amely ugyanazon szabályok szerint kerül kiszámításra, mint az egyes szakaszok szokásos aláírása külön-külön, de a kép általános azonosítója.
A képi szakaszok aláírása a következőktől függ:
- a kép tartalma;
- az ehhez a tartalomhoz vezető Git-változások történetét.
A Git-tárak mindig tartalmaznak hamis véglegesítéseket, amelyek nem változtatják meg a képfájlok tartalmát. Például csak megjegyzésekkel vagy egyesítéssel, vagy olyan véglegesítésekkel, amelyek megváltoztatják azokat a fájlokat a Gitben, amelyek nem lesznek importálva a képbe.
A tartalom alapú címkézés használatakor a Kubernetes alkalmazás podjainak a képnév változása miatti szükségtelen újraindítási problémái megoldódnak, még akkor is, ha a kép tartalma nem változott. Mellesleg, ez az egyik oka annak, hogy egy alkalmazás számos mikroszolgáltatása nem tárolható egyetlen Git-tárolóban.
Ezenkívül a tartalom alapú címkézés megbízhatóbb címkézési módszer, mint a Git ágakon történő címkézés, mivel az eredményül kapott képek tartalma nem függ attól, hogy a CI-rendszerben milyen sorrendben futnak le a folyamatok az ugyanazon ág több véglegesítésének összeállításához.
Fontos: mostantól kezdve szakaszok-aláírás - Van az egyetlen ajánlott címkézési stratégia. Alapértelmezés szerint ez lesz használva a parancsban werf ci-env (hacsak nem ad meg kifejezetten más címkézési sémát).
. Ennek a funkciónak külön kiadványt is szentelünk. FRISSÍTVE (április 3.): Cikk a részletekkel .
Naplózási szintek
A felhasználónak most lehetősége van a kimenet szabályozására, a naplózási szint beállítására és a hibakeresési információkkal való munkavégzésre. Opciók hozzáadva --log-quiet, --log-verbose, --log-debug.
Alapértelmezés szerint a kimenet a minimális információkat tartalmazza:
Bőbeszédű kimenet használatakor (--log-verbose) láthatja, hogyan működik a werf:
Részletes kimenet (--log-debug), a werf hibakeresési információkon kívül a használt könyvtárak naplóit is tartalmazza. Például megtekintheti, hogyan történik az interakció a Docker Registry-vel, és rögzítheti azokat a helyeket is, ahol jelentős időt töltenek:
Jövőbeli tervek
Figyelem! Az alábbiakban ismertetett opciók meg vannak jelölve v1.1 ebben a verzióban lesz elérhető, sok közülük a közeljövőben. A frissítések automatikus frissítésen keresztül érkeznek . Ezek a funkciók nem érintik a v1.1 funkciók stabil részét, megjelenésük nem igényel manuális felhasználói beavatkozást a meglévő konfigurációkban.
Teljes támogatás a különböző Docker Registry implementációkhoz (ÚJ)
- Verzió: v1.1
- Időpontok: március
A cél az, hogy a werf használatakor a felhasználó korlátozások nélkül használjon egyéni megvalósítást.
Jelenleg a következő megoldásokat azonosítottuk, amelyekhez teljes körű támogatást fogunk garantálni:
- Alapértelmezett (könyvtár/nyilvántartás)*,
- AWS ECR
- Égszínkék*,
- Docker Hub
- GCR*,
- GitHub csomagok
- GitLab Registry*,
- Kikötő*,
- Rakpart.
A werf által jelenleg teljes mértékben támogatott megoldások csillaggal vannak jelölve. Mások számára van támogatás, de korlátozásokkal.
Két fő probléma azonosítható:
- Egyes megoldások nem támogatják a címke eltávolítását a Docker Registry API használatával, ami megakadályozza, hogy a felhasználók használják a werf automatikus tisztítását. Ez igaz az AWS ECR, a Docker Hub és a GitHub csomagokra.
- Egyes megoldások nem támogatják az úgynevezett beágyazott adattárakat (Docker Hub, GitHub Packages és Quay), de a felhasználónak manuálisan kell létrehoznia azokat a felhasználói felület vagy API (AWS ECR) segítségével.
Ezeket és más problémákat a megoldások natív API-jaival fogjuk megoldani. Ez a feladat magában foglalja a werf működés teljes ciklusának lefedését is, mindegyik teszttel.
Elosztott képfelépítés (↑)
- Verzió: v1.2 v1.1 (a funkció megvalósításának prioritása megnövekedett)
- Időpontok: március-április március
Jelenleg a werf v1.0 és v1.1 csak egy dedikált gazdagépen használható képek készítésére és közzétételére, valamint az alkalmazás Kubernetes rendszerbe történő telepítésére.
A werf elosztott munkájának lehetőségeinek megnyitásához, amikor az alkalmazások felépítése és telepítése a Kubernetesben több tetszőleges gazdagépen indul el, és ezek a gazdagépek nem mentik el állapotukat a felépítések között (ideiglenes futtatók), a werf-nek meg kell valósítania a a Docker Registry mint színpadi tároló.
Korábban, amikor a werf projektet még dappnak hívták, volt rá ilyen lehetőség. Azonban számos olyan problémával találkoztunk, amelyeket figyelembe kell venni, amikor ezt a funkciót a werf-ben implementáljuk.
Megjegyzés. Ez a funkció nem követeli meg, hogy a gyűjtő a Kubernetes podokon belül működjön, mert Ehhez meg kell szabadulnia a helyi Docker-kiszolgálótól való függőségtől (a Kubernetes podban nincs hozzáférés a helyi Docker-kiszolgálóhoz, mert maga a folyamat egy tárolóban fut, és a werf nem támogatja és nem is fogja támogatni dolgozik a Docker szerverrel a hálózaton keresztül). A Kubernetes futtatásának támogatása külön kerül megvalósításra.
A GitHub Actions hivatalos támogatása (ÚJ)
- Verzió: v1.1
- Időpontok: március
Tartalmazza a werf dokumentációt (szakaszokat referencia и útmutató), valamint a hivatalos GitHub-akció a werf-fel való együttműködéshez.
Ezenkívül lehetővé teszi a werf számára, hogy az efemer futókon dolgozzon.
A CI-rendszerrel való felhasználói interakció mechanikája azon fog alapulni, hogy címkéket helyeznek el a lekérési kéréseken, hogy bizonyos műveleteket kezdeményezzenek az alkalmazás felépítéséhez/kiterjesztéséhez.
Alkalmazások helyi fejlesztése és telepítése werf segítségével (↓)
- Verzió: v1.1
- Időpontok: január-február április
A fő cél egyetlen egységes konfiguráció elérése az alkalmazások helyi és éles üzembe helyezéséhez, bonyolult műveletek nélkül, a dobozból.
A werf-nek olyan üzemmóddal is rendelkeznie kell, amelyben kényelmesen szerkeszthető az alkalmazás kódja, és azonnal visszajelzést kaphat a futó alkalmazástól a hibakereséshez.
Új tisztítási algoritmus (ÚJ)
- Verzió: v1.1
- Időpontok: április
A werf v1.1 jelenlegi verziójában az eljárásban cleanup A tartalom alapú címkézési séma esetén nincs lehetőség a képek tisztítására – ezek a képek felhalmozódnak.
Ezenkívül a werf jelenlegi verziója (v1.0 és v1.1) különböző tisztítási irányelveket használ a címkézési sémák alatt közzétett képekhez: Git branch, Git tag vagy Git commit.
Feltaláltak egy új algoritmust a képek tisztítására a Gitben végrehajtott véglegesítések előzményein alapulva, és egységesítették az összes címkézési sémát:
- Az egyes git HEAD-ekhez (ágak és címkék) legfeljebb N1 képet tartsanak társítva az N2 legutóbbi commit-okhoz.
- Az egyes git HEAD-ekhez (ágak és címkék) legfeljebb N1 szakaszképet tárolhat, amelyek az N2 legutóbbi commitokhoz vannak társítva.
- Tárolja az összes Kubernetes-fürterőforrásban használt képet (a konfigurációs fájl és a névterek összes kube-környezete vizsgálatra kerül; ezt a viselkedést speciális beállításokkal korlátozhatja).
- Tárolja a Helm kiadásokban mentett erőforrás-konfigurációs jegyzékekben használt összes képet.
- Egy kép törölhető, ha nincs társítva egyetlen HEAD-hez sem a gitből (például azért, mert magát a megfelelő HEAD-et törölték), és nem használják a Kubernetes-fürtben és a Helm-kiadásokban semmilyen manifestben.
Párhuzamos imázsépítés (↓)
- Verzió: v1.1
- Időpontok: január-február április*
A werf jelenlegi verziója a cikkben leírt képeket és tárgyakat gyűjti össze werf.yaml, egymás után. Párhuzamba kell állítani a képek és műtárgyak független szakaszainak összeállításának folyamatát, valamint kényelmes és informatív kimenetet kell biztosítani.
* Megjegyzés: a határidő eltolódott az elosztott összeállítás megvalósításának megnövekedett prioritása miatt, amely több vízszintes skálázási képességet, valamint a werf GitHub-műveletekkel való használatát eredményezi. A párhuzamos összeszerelés a következő optimalizálási lépés, amely függőleges skálázhatóságot biztosít egy projekt összeállításakor.
Átállás a Helm 3-ra (↓)
- Verzió: v1.2
- Időpontok: február-március május*
Tartalmazza az új kódbázisra való áttérést és egy bevált, kényelmes módja a meglévő telepítések migrációjának.
* Megjegyzés: a Helm 3-ra való váltás nem ad jelentősebb funkciókat a werf-hez, mivel a Helm 3 összes kulcsfontosságú funkciója (3-way-merge és nincs kormánymű) már implementálva van a werf-ben. Ráadásul a werf rendelkezik a jelzetteken kívül. Ez az átállás azonban továbbra is a terveink között szerepel, és meg fogjuk valósítani.
Jsonnet a Kubernetes konfiguráció leírásához (↓)
- Verzió: v1.2
- Időpontok: január-február április-május
A Werf támogatja a Kubernetes konfigurációs leírását Jsonnet formátumban. Ugyanakkor a werf továbbra is kompatibilis marad a Helmmel, és választható a leírási formátum.
Ennek az az oka, hogy a Go sablonok sokak szerint magas belépési korláttal rendelkeznek, és ezen sablonok kódjának érthetősége is csorbát szenved.
Más Kubernetes konfigurációleíró rendszerek (például Kustomize) bevezetésének lehetőségét is fontolgatják.
Munka a Kubernetesen belül (↓)
- Verzió: v1.2
- Időpontok: április-május május-június
Cél: Győződjön meg arról, hogy a képek összeállítása és az alkalmazás futtatása a Kubernetesben futó futtatókkal történik. Azok. Új képek készíthetők, publikálhatók, tisztíthatók és telepíthetők közvetlenül a Kubernetes podokból.
Ennek a képességnek a megvalósításához először képesnek kell lennie elosztott képek készítésére (lásd a fenti pontot).
Szüksége van a Docker-kiszolgáló nélküli fejlesztői működési mód támogatására is (azaz Kaniko-szerű build vagy build in userspace).
A Werf nem csak a Dockerfile-lal, hanem a Stapel builderével is támogatja a Kubernetes-re való építkezést fokozatos átépítésekkel és az Ansible-vel.
Egy lépés a nyitott fejlődés felé
Szeretjük közösségünket (, ), és azt szeretnénk, hogy egyre többen segítsenek a werf jobbá tételében, megértsék az irányt, amerre haladunk, és vegyenek részt a fejlesztésben.
Nemrég úgy döntöttek, hogy át kell váltani csapatunk munkafolyamatának feltárása érdekében. Most megtekintheti a közvetlen terveket, valamint az aktuális munkákat a következő területeken:
- ;
- ;
- ;
- .
Sok munka történt a következő problémákkal:
- A lényegteleneket eltávolítottuk.
- A meglévőket egységes formátumba hozzuk, kellő számú részlettel és részlettel.
- Új, ötletekkel és javaslatokkal ellátott problémák kerültek be.
A v1.1 verzió engedélyezése
A verzió jelenleg itt érhető el (csatornákban stabil и sziklaszilárd a kibocsátások azonban megjelennek a stabilizálódás során ea maga már elég stabil a használatra, mert átment a csatornákon alfa и beta). Aktív a következő módon:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Következtetés
Az új szakaszos tárolóarchitektúra és a Stapel és Dockerfile builderek optimalizálása lehetővé teszi az elosztott és párhuzamos buildek werf-ben való megvalósítását. Ezek a funkciók hamarosan ugyanabban a v1.1-es kiadásban jelennek meg, és automatikusan elérhetővé válnak az automatikus frissítési mechanizmus révén (felhasználók számára ).
Ebben a kiadásban egy képtartalomon alapuló címkézési stratégia került hozzáadásra - tartalom alapú címkézés, amely az alapértelmezett stratégiává vált. A fő parancsnaplót is átdolgozták: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
A következő jelentős lépés az elosztott összeállítások hozzáadása. Az elosztott buildek fontosabb prioritássá váltak, mint a párhuzamos buildek a v1.0 óta, mert nagyobb értéket adnak a werf-nek: a builderek vertikális skálázása és az efemer builderek támogatása a különböző CI/CD rendszerekben, valamint a GitHub Actions hivatalos támogatásának lehetősége. . Emiatt a párhuzamos szerelvények megvalósítási határideje eltolódott. Mindazonáltal azon dolgozunk, hogy mindkét lehetőséget minél előbb megvalósítsuk.
Kövesd a híreket! És ne felejtsen el ellátogatni hozzánk probléma létrehozásához, keressen egy meglévőt, és adjon hozzá pluszt, hozzon létre PR-t, vagy egyszerűen nézze meg a projekt fejlődését.
PS
Olvassa el blogunkon is:
- «»
- «";
- Egy sor megjegyzés a werf újításairól:
- «";
- «";
- «";
- «".
Forrás: will.com