— a GitOps CLI utility with open source for building and delivering applications in Kubernetes. As promised, marked the beginning of adding new features to werf and rethinking traditional approaches. Now we are pleased to present the release v1.1, which is a significant step forward and lays the foundation for the future of the builder werf. The version is currently available in .
The core of the release is a new stages storage architecture and optimization of both builders (for Stapel and Dockerfile). The new storage architecture opens up opportunities for implementing distributed builds from multiple hosts and parallel builds on a single host.
The optimization includes eliminating unnecessary computations at the stage signature calculation phase and changing the checksum calculation mechanisms for files to more efficient ones. This optimization reduces the average build time of a project using werf. Cold builds, when all stages exist in cache stages-storage, are now truly fast. In most cases, restarting the build will take less than 1 second! This also applies to stage verification procedures during the work of teams werf deploy és werf run.
Additionally, this release introduced a content-based image tagging strategy — tartalmi alapú címkézés, which is now enabled by default and is the only recommended option.
Let's take a closer look at the key innovations in werf v1.1, and at the same time, we will discuss future plans.
What has changed in werf v1.1?
A new naming format for stages and an algorithm for fetching stages from cache
A new rule for generating stage names. Now, each stage build generates a unique stage name, which consists of 2 parts: a signature (as it was in v1.0) plus a unique time identifier.
For example, the full name of a stage image could look like this:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… or in general form:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Itt:
-
SIGNATURE— is the stage signature, which represents the identifier of the stage's content and depends on the history of Git edits that led to this content; -
TIMESTAMP_MILLISEC— is a guaranteed unique image identifier generated at the time of building a new image.
The algorithm for fetching stages from cache is based on checking the lineage of Git commits:
- A Werf kiszámítja egy bizonyos szakasz aláírását.
- A stages-storage Több szakasz is létezhet ezen aláírás alapján. A Werf kiválasztja az összes, aláírás alapján megfelelő szakaszt.
- Ha az aktuális szakasz kapcsolódik a Git-hez (git-archívum, felhasználói szakasz Git-patch-ekkel:
install,beforeSetup,setup; vagy git-legfrissebb-patch), akkor a Werf csak azokat a szakaszokat választja, amelyek kapcsolódnak a jelenlegi commit őséhez (amelyre a build-et hajtják végre). - A fennmaradó, megfelelő szakaszok közül egyet választ ki — a legkorábban létrehozottat.
Különböző Git ágak számára azonos aláírású szakaszok létezhetnek. De a Werf megakadályozza, hogy a különböző ágak közötti cache-vel kapcsolatos felhasználást végezzen, még akkor is, ha az aláírások egyeznek.
.
Új algoritmus a szakaszok létrehozására és tárolására a szakasztárolóban
Ha a Werf nem talál megfelelő szakaszt a cache-ből, akkor egy új szakasz build folyamatát indítja el.
Megjegyezzük, hogy több folyamat (egy vagy több hoszton) egy és ugyanazon szakasz buildelésébe kezdhet kb. egyszerre. A Werf optimista zárolási algoritmust használ stages-storage az újonnan épített image mentésekor stages-storage. Így, amikor új szakasz build-je elkészül, a Werf zárolja stages-storage és csak akkor menti az újonnan épített image-t, ha ott még nem létezik megfelelő image (aláírás és egyéb paraméterek alapján — lásd az új szakasz kereső algoritmust a cache-ből).
Az újonnan épített image garantáltan egyedi azonosítóval rendelkezik TIMESTAMP_MILLISEC (lásd az új szakasznév-formátumot). Amennyiben a stages-storage -ban található megfelelő image, a Werf elveti az újonnan épített image-t, és a cache-ből lévő image-et fogja használni.
Más szavakkal: az első folyamat, amely befejezi az image építését (a leggyorsabb), joga lesz azt eltárolni a stages-storage-ban (és utána ez az egyetlen image fog használatban lenni minden build során). A lassabb build folyamat soha nem fogja blokkolni a gyorsabb folyamatot az aktuális szakasz buildjének eredményeinek mentésétől és a következő build-re való áttéréstől.
.
Javult a Dockerfile buildelési teljesítménye
Jelenleg a Dockerfile-ból épített image szakaszainak csatornája egy szakaszból áll — dockerfile. Az aláírás számításakor a fájlok ellenőrzőösszege kerül figyelembevételre. context, amelyeket a gyűjtés során használnak. E fejlesztés előtt a werf rekurzívan végigjárta az összes fájlt és ellenőrző összeget kapott, a kontextus és minden fájl módjának összegzésével. Az v1.1-es verzióktól kezdve a werf használhatja a Git-reposzitoriumban tárolt előre kiszámított ellenőrző összegeket.
Az algoritmus alapja — . Az algoritmus figyelembe veszi a fájlokban található bejegyzéseket, .dockerignore és csak szükség esetén járja be fájlok fáját. Ezzel leválasztottuk a fájlrendszer olvasásáról, és az algoritmus függősége a mérettől context nem lényeges.
Az algoritmus azt is ellenőrzi, hogy vannak-e nyomkövetetlen fájlok, és ha szükséges, figyelembe veszi őket az ellenőrző összegben.
Javítva lett a fájlok importálásának teljesítménye.
A werf v1.1-es verziójában rsync szervert használunk a Korábban az importálás két lépésben történt, a host rendszer könyvtárának csatolásával.
Az importálás teljesítménye macOS-en már nem korlátozódik a Docker volumes-ra, és az importálások ugyanolyan sebességgel történnek, mint Linuxon és Windows-on.
Tartalom alapú címkézés
A Werf v1.1 támogatja az úgynevezett tartalom alapú címkézést a képek esetében — tartalmi alapú címkézés. A létrejövő Docker-képek címkéi az ezen képek tartalmától függenek.
A parancs futtatásakor werf publish --tags-by-stages-signature vagy werf ci-env --tagging-strategy=stages-signature a megjelölt képek úgynevezett stádiumok aláírása szerint lesznek. Minden képet a saját stádiumának aláírása címkéz, amely ugyanazokkal a szabályokkal számítható, mint minden egyes stádium normál aláírása, de egy általánosító azonosító a kép számára.
A kép stádiumának aláírása a következőktől függ:
- ennek a képnek a tartalmától;
- a Git-ben végrehajtott módosítások történetétől, amelyek ehhez a tartalomhoz vezettek.
A Git-reposzitoriumban mindig vannak üres elköteleződéseket, amelyek nem változtatják meg a képfájlok tartalmát. Például, elkötelezések csak megjegyzésekkel vagy merge-elkötelezések, vagy olyan elkötelezések, amelyek módosítják a Git fájlokat, amelyeket nem fognak importálni a képbe.
A tartalom alapú címkézés problémákat old meg a Kubernetes alkalmazás podjainak felesleges újraindításával kapcsolatban a képnév módosítása miatt, még akkor is, ha a kép tartalma nem változott. Egyébként ez az egyik oka annak, hogy nehezen tárolható sok mikroszerviz egyetlen Git-reposzitoriumban.
A content-based tagging is a more reliable method of tagging than Git branch tagging because the contents of the resulting images do not depend on the execution order of pipelines in the CI system for building multiple commits of the same branch.
Fontos: starting from this moment stages-signature — ez the only recommended tagging strategy. It will be used by default in the team werf ci-env (unless another tagging scheme is explicitly specified).
. This feature will also be addressed in a separate publication. UPDATED (April 3): Article with details .
Logging levels
The user now has the ability to control the output, set the logging level, and work with debug information. Added options --log-quiet, --log-verbose, --log-debug.
By default, the output contains minimal information:
When using detailed output (--log-verbose) you can trace how werf operates:
Detailed output (--log-debug), in addition to werf's debug information, also contains logs of the libraries used. For example, you can see how interaction with Docker Registry occurs, as well as pinpoint where significant time is spent:
Further plans
Figyelem! The features described below marked v1.1 will be available in this version, many of them — in the near future. Updates will come via auto-updates . These features do not affect the stable part of the v1.1 functions, their appearance will not require manual intervention from the user in already existing configurations.
Full support for various Docker Registry implementations (NEW)
- Version: v1.1
- Timeline: March
Goal — the user should be able to use any implementation without restrictions when using werf.
Currently, we have identified the following set of solutions for which we plan to guarantee full support:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Solutions marked with an asterisk are currently fully supported by werf. For others, support exists but with limitations.
Two main issues can be highlighted:
- Some solutions do not support tag deletion via the Docker Registry API, preventing users from utilizing the automatic cleanup implemented in werf. This is true for AWS ECR, Docker Hub, and GitHub Packages.
- Egyes megoldások nem támogatják az úgynevezett, nested repositories-t (Docker Hub, GitHub Packages és Quay), vagy támogatják, de a felhasználónak manuálisan kell létrehoznia őket UI vagy API segítségével (AWS ECR).
Ezeket és egyéb problémákat a natív API-k felhasználásával kívánjuk megoldani. Ebbe a feladatba beletartozik a werf teljes ciklusának tesztelése mindegyik esetében.
Elosztott image-összeszerelés (↑)
- Verzió: v1.2 v1.1 (a funkció megvalósításának prioritása nőtt)
- Időkeret: március-április március
Jelenleg a werf v1.0 és v1.1 csak egy dedikált hoszton használható az image-összeszerelési és publikálási műveletekhez, valamint az alkalmazás Kubernetes-be való telepítéséhez.
Ahhoz, hogy megnyissuk a werf elosztott működésének lehetőségeit, amikor az alkalmazások összeállítása és telepítése a Kubernetes-ben több tetszőleges hoszton történik, és ezek a hosztok nem őrzik meg állapotukat az összeszerelések között (ideiglenes runner-ek), a werf-nek implementálnia kell a Docker Registry-t mint szakaszok tárolóját.
Korábban, amikor a werf projekt még dapp néven futott, volt egy ilyen lehetőség. Azonban számos problémával szembesültünk, amelyeket figyelembe kell venni a funkció werf-ben való megvalósításakor.
Megjegyzés. Ez a lehetőség nem feltételezi a kötegek működését a Kubernetes pod-jaiban, mivel ehhez meg kell szüntetni a helyi Docker-szerverre való függőséget (a Kubernetes podban nincs hozzáférés a helyi Docker-szerverhez, mert a folyamat maga egy konténerben fut, és a Docker-szerverrel való hálózati kapcsolatot a werf nem támogatja és nem is fogja támogatni). A Kubernetes támogatását külön fogják megvalósítani.
Hivatalos támogatás a GitHub Actions-hoz (ÚJ)
- Version: v1.1
- Timeline: March
Tartalmazza a werf dokumentációját (szakaszok reference és útmutató), valamint a hivatalos GitHub Action-t a werf-hez való munkához.
Ezenkívül lehetővé teszi a werf működését efemer runner-ek alatt.
A felhasználó interakciójának a CI-rendszerrel a pull-requestek címkézésén alapul, a bizonyos telepítési/csomagolási műveletek kezdeményezésére.
Helyi fejlesztés és alkalmazások telepítése werf-fel (↓)
- Version: v1.1
- Időkeret: január-február április
Fő cél — egy egységes, egységesített konfiguráció elérése az alkalmazások telepítéséhez, akár helyben, akár production környezetben, bonyolult lépések nélkül, „dobozból ki”,.
A werf-től elvárják, hogy olyan működési módot biztosítson, amely lehetővé teszi az alkalmazás kódjának kényelmes szerkesztését, és az alkalmazás működésével azonnali visszajelzést kapjunk a hibakereséshez.
Új tisztítási algoritmus (ÚJDONSÁG)
- Version: v1.1
- Határidők: április
A jelenlegi werf v1.1 verzióban a tisztítási folyamatban nem rendelkezik tisztítási lehetőséggel a tartalom-alapú címkézési séma alapján, így ezek az képek felhalmozódnak.
A jelenlegi werf verziókban (v1.0 és v1.1) eltérő tisztítási politikák érvényesek a címkézési sémák szerint publikált képekre: Git-ág, Git-címke vagy Git-commit.
Kitalálták az összes címkézési séma számára egységes képtisztítási algoritmust, amely a Git commitok története alapján működik:
- Tartsunk meg legfeljebb N1 képet, amelyek a legutolsó N2 commit-hoz kapcsolódnak minden git HEAD (ágak és címkék) esetén.
- Tartsunk meg legfeljebb N1 képkénti szakaszt, amelyek a legutolsó N2 commit-hoz kapcsolódnak minden git HEAD (ágak és címkék) esetén.
- Tartsuk meg az összes képet, amelyet a Kubernetes klaszter bármely erőforrásának konfigurációs fájljaiban használnak (az összes kube-kontekstust és namespace-t megvizsgálják a konfigurációs fájlban; ezt a viselkedést speciális opciókkal lehet korlátozni).
- Tartsuk meg az összes képet, amelyet a Helm-kiadásokban mentett erőforrások konfigurációs manifestjeiben használnak.
- A kép eltávolítható, ha nem kapcsolódik egyetlen git HEAD-hez sem (például mert az adott HEAD is eltávolításra került), és nem használják a Kubernetes klaszterben vagy a Helm-kiadásokban található egyetlen manifestben sem.
Párhuzamos képszerkesztés (↓)
- Version: v1.1
- Határidők: január-február április*
A jelenlegi werf verzió egymás után gyűjti a képeket és artefaktumokat, amelyek a werf.yamlbenne foglaltak. Szükséges a független képfázisok és artefaktumok gyártási folyamatának párhuzamosítása, valamint kényelmes és informatív kimenet biztosítása.
* Megjegyzés: a határidő eltolódott, mivel prioritást élvez a párhuzamos gyártás megvalósítása, amely több lehetőséget ad a horizontális skálázásra, valamint a werf használatára a GitHub Actions-szal. A párhuzamos gyártás a következő lépés az optimalizálásban, amely vertikális skálázhatóságot eredményez egyetlen projekt gyártása során.
Átállás a Helm 3-ra (↓)
- Verzió: v1.2
- Határidők: február-március május*
Tartalmazza az új kódalapra való átmenetet és egy tesztelt, kényelmes megoldást a meglévő telepítések migrálására.
* Megjegyzés: az átállás a Helm 3-ra nem ad jelentős új képességeket a werf-hez, mivel a Helm 3 kulcsfontosságú funkciói (3-way-merge és a tiller hiánya) már megvalósultak a werf-ben. Sőt, a werf rendelkezik is a felsoroltakon kívül. Az átállás azonban a terveink között szerepel és meg fogjuk valósítani.
Jsonnet a Kubernetes konfiguráció leírásához (↓)
- Verzió: v1.2
- Határidők: január-február április-május
A Werf támogatni fogja a Kubernetes konfiguráció leírását Jsonnet formátumban. Emellett a werf továbbra is kompatibilis lesz a Helm-mel, és lesz lehetőség a leírási formátum választására.
Az ok az, hogy sokak véleménye szerint a Go nyelv mintái magasan álló belépési küszöbbel rendelkeznek, és a kód érthetősége is szenved a minták miatt.
Továbbá más Kubernetes konfigurációs leíró rendszerek (például Kustomize) bevezetésének lehetősége is vizsgálat alatt áll.
Munkavégzés a Kubernetes-en belül (↓)
- Verzió: v1.2
- Határidők: április-május május-június
Cél: a képek összeállítása és az alkalmazás szállítása Kubernetes-ben runner-ek használatával. Tehát az új képek összeállítása, publikálása, takarítása és telepítése közvetlenül a Kubernetes pod-okból történhet.
Ehhez a lehetőséghez első lépésként elengedhetetlen a képek elosztott összeállításának lehetősége (lásd a fenti pontot).
Továbbá szükséges a compiler működésének támogatása Docker szerver nélkül (azaz Kaniko-szerű építés vagy felhasználói térben történő építés).
A Werf nemcsak Dockerfile, hanem saját Stapel compiler-jével is támogatni fogja a Kubernetes-ben történő összeállítást, amely inkrementális újraépítéseket és Ansible-t is tartalmaz.
Lépés a nyílt fejlesztés felé
Szeretjük a közösségünket (, ) és azt akarjuk, hogy egyre több ember segítse a werf javítását, értsék, merre tartunk, és részt vegyenek a fejlesztésben.
Nemrégiben döntést hoztunk az átállásról hogy nyitottabbá tegyük a csapatunk munkafolyamatát. Most már láthatók a közeljövő tervei, valamint a jelenlegi munkák a következő területeken:
- ;
- ;
- ;
- .
Sok munkát végeztünk el az issues-zal kapcsolatban:
- A nem relevánsak eltávolításra kerültek.
- A meglévőket egységes formátumba, elegendő részletességgel és információval láttuk el.
- Új issues kerültek hozzáadásra ötletekkel és javaslatokkal.
Hogyan aktiválható a v1.1-es verzió
A verzió jelenleg elérhető a (csatornákban stable és rock-solid kiadások érkeznek, ahogy stabilizálódik, azonban ea maga már elég stabil használatra, mivel átment a csatornákon. alpha és beta). Aktiválva a következő módon:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Zárás
Az új szakaszos tárolási architektúra és a Stapel és Dockerfile építők számára optimalizált munkafolyamat lehetővé teszi a párhuzamos és elosztott építési feladatok megvalósítását a werf-en belül. Ezek a lehetőségek hamarosan elérhetők lesznek az 1.1-es verzióban és automatikusan elérhetők lesznek az automatikus frissítések révén (felhasználóknak) ).
Ebben a verzióban hozzáadtunk egy tartalom alapú címkézési stratégiát — tartalmi alapú címkézés, — amely az alapértelmezett stratégiává vált. Átdolgoztuk a fő parancsok naplózását is: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
A következő jelentős lépés az elosztott építések hozzáadása lesz. Az elosztott építések a v1.0 óta prioritást kaptak a párhuzamos építésekkel szemben, mivel nagyobb értéket adnak a werf-nek: a gyártók függőleges skálázását és az efemer gyártók támogatását különböző CI/CD rendszerekben, valamint a GitHub Actions hivatalos támogatásának lehetőségét. Ezért a párhuzamos építések megvalósításának időpontját elhalasztottuk. Mindazonáltal azon dolgozunk, hogy mindkét lehetőséget mihamarabb megvalósítsuk.
Kövessen minket a hírekért! Ne felejtsen el ellátogatni hozzánk a , hogy létrehozhasson issue-t, megtalálhassa a már meglévőt és pluszt adhasson hozzá, PR-t készíthessen, vagy egyszerűen figyelemmel kísérhesse a projekt fejlődését.
P.S.
Olvasson további információkat a blogunkban:
- «»
- «»;
- A werf újdonságairól szóló jegyzetek ciklusa:
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
