ass eisen Open Source GitOps CLI Utility fir Uwendungen op Kubernetes ze bauen an ze liwweren. Wéi versprach, markéiert den Ufank fir nei Features op werf ze addéieren an traditionell Approche ze iwwerschaffen. Elo si mir frou d'Verëffentlechung v1.1 ze presentéieren, wat e grousse Schrëtt an der Entwécklung an e Fundament fir d'Zukunft ass Sammler werf. D'Versioun ass de Moment verfügbar an .
D'Basis vun der Verëffentlechung ass déi nei Architektur vun der Bühnespäicherung an der Optimiséierung vun der Aarbecht vu béide Sammler (fir Stapel an Dockerfile). Déi nei Späicherarchitektur mécht d'Méiglechkeet op fir verdeelt Versammlungen vu multiple Hosten a parallele Versammlungen op de selwechte Host ëmzesetzen.
Optimiséierung vun der Aarbecht beinhalt d'Ofdreiwung vun onnéidege Berechnungen op der Bühn vun der Berechnung vun der Etapp Ënnerschrëften an d'Verännerung vun de Mechanismen fir d'Berechnung vun de Dateichecksummen op méi effizient. Dës Optimiséierung reduzéiert d'Duerchschnëttszäit vum Projet baut mat werf. An Idle baut, wann all Etappen am Cache existéieren Etappen-Lagerung, sinn elo wierklech séier. An deene meeschte Fäll wäert de Bau nei starten manner wéi 1 Sekonn daueren! Dëst gëllt och fir Prozedure fir d'Etappen am Prozess vun der Aarbecht vun den Teams z'iwwerpréiwen. werf deploy и werf run.
Och an dëser Verëffentlechung erschéngt eng Strategie fir Biller no Inhalt ze taggen - Inhalt-baséiert Tagging, déi elo als Standard aktivéiert ass an déi eenzeg recommandéiert ass.
Loosst eis d'Schlësselinnovatiounen am werf v1.1 méi no kucken, a gläichzäiteg iwwer Pläng fir d'Zukunft erzielen.
Wat huet geännert an werf v1.1?
Neie Bühnbenennungsformat an Algorithmus fir Bühnen aus Cache ze wielen
Nei Etapp Numm Generatioun Regel. Elo generéiert all Etappebau en eenzegaartegen Bühnnumm, deen aus 2 Deeler besteet: eng Ënnerschrëft (wéi et an v1.0 war) plus en eenzegaartegen temporäre Identifizéierer.
Zum Beispill kann de komplette Bühnbildnumm esou ausgesinn:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... oder allgemeng:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Hei:
-
SIGNATUREass eng Bühnsignatur, déi den Identifizéierer vum Bühninhalt duerstellt an hänkt vun der Geschicht vun den Ännerungen am Git of, déi zu dësem Inhalt gefouert hunn; -
TIMESTAMP_MILLISECass e garantéierten eenzegaartege Bildidentifizéierer deen generéiert gëtt wann en neit Bild gebaut gëtt.
Den Algorithmus fir Etappen aus dem Cache ze wielen baséiert op der Iwwerpréiwung vun der Bezéiung vu Git Verpflichtungen:
- Werf berechent d'Ënnerschrëft vun enger bestëmmter Etapp.
- В Etappen-Lagerung Et kann e puer Etappe fir eng bestëmmte Ënnerschrëft ginn. Werf wielt all Etappen, déi mat der Ënnerschrëft passen.
- Wann déi aktuell Etapp mat Git verlinkt ass (git-Archiv, personaliséiert Etapp mat Git Patches:
install,beforeSetup,setup; oder git-läscht-Patch), da wielt werf nëmmen déi Etappen aus, déi mat engem Verpflichtung assoziéiert sinn, deen en Vorfahre vum aktuelle Verpflichtung ass (fir deen de Bau genannt gëtt). - Vun de verbleiwen gëeegent Etappe gëtt een ausgewielt - déi eelst no Kreatiounsdatum.
Eng Bühn fir verschidde Git Branchen kann déiselwecht Ënnerschrëft hunn. Awer werf verhënnert datt de Cache verbonne mat verschiddene Branchen tëscht dëse Branchen benotzt gëtt, och wann d'Ënnerschrëfte passen.
.
Neie Algorithmus fir Etappen an der Bühnlagerung ze kreéieren an ze späicheren
Wann, wann Dir Etappen aus dem Cache auswielen, werf keng gëeegent Etapp fënnt, da gëtt de Prozess fir eng nei Etapp ze sammelen.
Notéiert datt verschidde Prozesser (op engem oder méi Hosten) kënnen ufänken déi selwecht Bühn op ongeféier gläichzäiteg ze bauen. Werf benotzt en optimistesche Späralgorithmus Etappen-Lagerung am Moment vum späicheren dat frësch gesammelt Bild an Etappen-Lagerung. Op dës Manéier, wann den neie Bühnbau fäerdeg ass, blockéiert d'werf Etappen-Lagerung a späichert e frësch gesammelt Bild do nëmmen wann e passende Bild do net méi gëtt (duerch Ënnerschrëft an aner Parameteren - kuckt den neien Algorithmus fir Etappen aus dem Cache ze wielen).
E frësch versammelt Bild ass garantéiert en eenzegaartegen Identifizéierer ze hunn TIMESTAMP_MILLISEC (kuckt neit Bühnbenennungsformat). Am Fall an Etappen-Lagerung e gëeegent Bild gëtt fonnt, werf werft dat frësch kompiléiert Bild ewech a benotzt d'Bild aus dem Cache.
An anere Wierder: den éischte Prozess fir d'Bild fäerdeg ze bauen (de schnellsten) kritt d'Recht et an Etappen ze späicheren (an dann ass dat eenzegt Bild dat fir all Builds benotzt gëtt). E luesen Bauprozess blockéiert ni e méi séiere Prozess fir d'Bauresultater vun der aktueller Etapp ze späicheren an op déi nächst Build weiderzekommen.
.
Verbesserte Dockerfile Builder Leeschtung
Am Moment besteet d'Pipeline vun de Bühnen fir e Bild aus engem Dockerfile aus enger Bühn - dockerfile. Beim Berechnung vun der Ënnerschrëft gëtt d'Kontrollsum vun de Fichier berechent context, déi während der Montage benotzt ginn. Virun dëser Verbesserung ass werf rekursiv duerch all Dateie gaangen an e Checksum kritt andeems de Kontext an de Modus vun all Datei zesummegeet. Vun v1.1 un, werf kann berechent Kontrollsumme benotzen, déi an engem Git Repository gespäichert sinn.
Den Algorithmus baséiert op . Den Algorithmus berücksichtegt records an .dockerignore an duerch de Fichier Bam rekursiv nëmmen wann néideg. Also hu mir vum Liesen vum Dateiesystem entkoppelt, an d'Ofhängegkeet vum Algorithmus vun der Gréisst context ass net bedeitend.
Den Algorithmus iwwerpréift och net verfollegt Dateien an, wann néideg, berücksichtegt se am Checksum.
Verbesserte Leeschtung beim Import vun Dateien
Versioune vun werf v1.1 benotzen engem rsync Server wann . Virdru gouf den Import an zwee Schrëtt gemaach mat engem Verzeechnesmount vum Hostsystem.
D'Importleistung op macOS ass net méi limitéiert duerch Docker Bänn, an d'Importer komplett an der selwechter Zäit wéi Linux a Windows.
Inhalt-baséiert Tagging
Werf v1.1 ënnerstëtzt sougenannte Tagging duerch Bildinhalt - Inhalt-baséiert Tagging. D'Tags vun de resultéierende Docker Biller hänkt vum Inhalt vun dëse Biller of.
Wann Dir de Kommando leeft werf publish --tags-by-stages-signature oder werf ci-env --tagging-strategy=stages-signature publizéiert Biller vun der sougenannten Etapp Ënnerschrëft Bild. All Bild ass mat senger eegener Ënnerschrëft vun den Etappen vun dësem Bild markéiert, déi no de selwechte Reegele wéi déi regulär Ënnerschrëft vun all Etapp getrennt berechent gëtt, awer en allgemengen Identifizéierer vum Bild ass.
D'Ënnerschrëft vun de Bildstadien hänkt vun:
- den Inhalt vun dësem Bild;
- Geschichte vun de Git Ännerungen déi zu dësem Inhalt gefouert hunn.
E Git Repository huet ëmmer Dummy commits déi den Inhalt vun de Bilddateien net änneren. Zum Beispill, engagéiert nëmme mat Kommentaren oder fusionéiert Verpflichtungen, oder engagéiert déi dës Dateien am Git änneren, déi net an d'Bild importéiert ginn.
Wann Dir Inhaltsbaséiert Tagging benotzt, ginn d'Problemer vun onnéidege Restarts vun Applikatioun Pods an Kubernetes wéinst Ännerungen am Bildnumm geléist, och wann den Inhalt vum Bild net geännert huet. Iwwregens ass dëst ee vun de Grënn déi verhënnert datt vill Mikroservicer vun enger Applikatioun an engem eenzege Git Repository späicheren.
Och Inhalt-baséiert Tagging ass eng méi zouverlässeg Tagging Method wéi Tagging op Git Branchen, well den Inhalt vun de resultéierende Biller hänkt net vun der Uerdnung of an där Pipelines am CI System ausgefouert ginn fir verschidde Verpflichtungen vun der selwechter Branche ze sammelen.
wichteg: ab elo Etappen-Ënnerschrëft Ass déi eenzeg recommandéiert Tagging Strategie. Et gëtt als Standard am Kommando benotzt werf ci-env (ausser Dir spezifizéiert explizit en anert Tagging Schema).
. Eng separat Publikatioun wäert och zu dëser Fonktioun gewidmet ginn. UPDATED (3. Abrëll): Artikel mat Detailer .
Logniveauen
De Benotzer huet elo d'Méiglechkeet d'Ausgab ze kontrolléieren, de Logbicherniveau ze setzen a mat Debugginginformatioun ze schaffen. Optiounen dobäi --log-quiet, --log-verbose, --log-debug.
Par défaut enthält d'Ausgab déi minimal Informatioun:
Wann Dir verbose Output benotzt (--log-verbose) Dir kënnt gesinn wéi werf funktionnéiert:
Détailléiert Ausgang (--log-debug), Nieft werf Debugging Informatioun, enthält och Logbicher vu benotzte Bibliothéiken. Zum Beispill kënnt Dir gesinn wéi d'Interaktioun mam Docker Registry geschitt, an och d'Plazen notéieren wou eng bedeitend Quantitéit un Zäit verbruecht gëtt:
Weider Pläng
Opgepasst weg! D'Optiounen hei ënnen beschriwwe sinn markéiert v1.1 wäert an dëser Versioun verfügbar ginn, vill vun hinnen an der nächster Zukunft. Updates kommen iwwer Autoupdates . Dës Funktiounen beaflossen net de stabilen Deel vun de v1.1 Funktiounen; Hir Erscheinung erfuerdert keng manuell Benotzerinterventioun an existente Konfiguratiounen.
Voll Ënnerstëtzung fir verschidde Docker Registry Implementatiounen (NEW)
- Versioun: v1.1
- Datumer: Mäerz
D'Zil ass fir de Benotzer eng personaliséiert Implementatioun ouni Restriktiounen ze benotzen wann Dir werf benotzt.
De Moment hu mir déi folgend Set vu Léisungen identifizéiert fir déi mir voll Ënnerstëtzung garantéieren:
- Standard (Bibliothéik/Registry)*,
- AWS ECR
- Azur*,
- Docker Hub
- GCR*,
- GitHub Packagen
- GitLab Registry*,
- Hafen*,
- Quai.
Léisungen déi momentan voll ënnerstëtzt gi vu werf si mat engem Stern markéiert. Fir anerer gëtt et Ënnerstëtzung, awer mat Aschränkungen.
Zwee Haaptproblemer kënnen identifizéiert ginn:
- E puer Léisunge ënnerstëtzen net d'Entfernung vum Tag mat der Docker Registry API, verhënnert d'Benotzer vum werf seng automatesch Botzen ze benotzen. Dëst ass wouer fir AWS ECR, Docker Hub, a GitHub Packagen.
- E puer Léisungen ënnerstëtzen net sougenannte nested Repositories (Docker Hub, GitHub Packages a Quay) oder maachen, awer de Benotzer muss se manuell mat der UI oder API (AWS ECR) erstellen.
Mir léisen dës an aner Probleemer mat native APIs vun de Léisungen. Dës Aufgab ëmfaasst och de ganzen Zyklus vun der werf Operatioun mat Tester fir jidderee vun hinnen ofdecken.
Verdeelt Bildbau (↑)
- Versioun: v1.2 v1.1 (d'Prioritéit fir d'Ëmsetzung vun dëser Feature gouf erhéicht)
- Datumer: Mäerz-Abrëll Mäerz
Am Moment kënnen werf v1.0 a v1.1 nëmmen op engem dedizéierten Host benotzt ginn fir Operatiounen fir Biller ze bauen an ze publizéieren an d'Applikatioun op Kubernetes z'installéieren.
Fir d'Méiglechkeeten vun der verdeelerer Aarbecht vu werf opzemaachen, wann d'Build an d'Deployment vun Applikatiounen an Kubernetes op e puer arbiträr Hosten lancéiert ginn an dës Hosten hiren Zoustand net tëscht Builds retten (temporär Leefer), ass werf verlaangt d'Fäegkeet ze benotzen den Docker Registry als Bühngeschäft.
Virdrun, wéi de werfprojet nach dapp genannt gouf, hat et esou eng Chance. Mir hunn allerdéngs eng Rei Themen begéint, déi musse berécksiichtegt ginn, wann Dir dës Funktionalitéit an werf ëmsetzt.
Remarque. Dës Fonktioun erfuerdert net de Sammler fir bannent Kubernetes Pods ze schaffen, well Fir dëst ze maachen, musst Dir d'Ofhängegkeet vum lokalen Docker-Server lassginn (am Kubernetes Pod gëtt et keen Zougang zum lokalen Docker-Server, well de Prozess selwer an engem Container leeft, a werf net a wäert net ënnerstëtzen schafft mam Docker Server iwwer dem Netz). Ënnerstëtzung fir Kubernetes ze lafen gëtt separat implementéiert.
Offiziell Ënnerstëtzung fir GitHub Actions (NEW)
- Versioun: v1.1
- Datumer: Mäerz
Ëmfaasst werf Dokumentatioun (Sektiounen Referenz и guide), souwéi déi offiziell GitHub Action fir mat werf ze schaffen.
Zousätzlech, wäert et erlaben werf op ephemeral Leefer ze schaffen.
D'Mechanik vun der Benotzerinteraktioun mam CI System baséiert op d'Plaze vun Etiketten op Pull-Ufroen fir verschidden Aktiounen ze initiéieren fir d'Applikatioun ze bauen / auszerollen.
Lokal Entwécklung an Deployment vun Uwendungen mat werf (↓)
- Versioun: v1.1
- Datumer: Januar-Februar Abrëll
D'Haaptziel ass eng eenzeg vereenegt Configuratioun z'erreechen fir Uwendungen souwuel lokal wéi an der Produktioun z'installéieren, ouni komplex Aktiounen, aus der Këscht.
werf ass och erfuerderlech en Operatiounsmodus ze hunn an deem et bequem ass den Applikatiounscode z'änneren an direkt Feedback vun der lafender Applikatioun fir Debugging ze kréien.
Neie Botzalgorithmus (NEW)
- Versioun: v1.1
- Datumer: Abrëll
An der aktueller Versioun vu werf v1.1 an der Prozedur cleanup Et gëtt keng Viraussetzung fir Biller ze botzen fir den Inhaltsbaséierten Tagging Schema - dës Biller accumuléieren.
Och déi aktuell Versioun vu werf (v1.0 a v1.1) benotzt verschidde Botzenpolitike fir Biller déi ënner Tagging Schema publizéiert ginn: Git Branche, Git Tag oder Git commit.
En neien Algorithmus fir Biller ze botzen baséiert op der Geschicht vu Verpflichtungen am Git, vereenegt fir all Tagging Schemaen, gouf erfonnt:
- Halt net méi wéi N1 Biller verbonne mat den N2 rezentste Verpflichtungen fir all Git HEAD (Branchen an Tags).
- Späichert net méi wéi N1 Bühnbilder verbonne mat den N2 rezentste Verpflichtungen fir all Git HEAD (Branchen an Tags).
- Späichert all Biller déi an all Kubernetes Cluster Ressourcen benotzt ginn (all Kube Kontexter vun der Konfiguratiounsdatei an Nummraim gi gescannt; Dir kënnt dëst Verhalen mat speziellen Optiounen limitéieren).
- Store all Biller déi an Ressource Configuratioun Manifestatiounen benotzt ginn an Helm Fräisetzung gespäichert.
- E Bild kann geläscht ginn wann et net mat engem HEAD aus git assoziéiert ass (zum Beispill, well de entspriechende HEAD selwer geläscht gouf) a gëtt net an all Manifestatiounen am Kubernetes Cluster an an Helm Verëffentlechungen benotzt.
Parallel Bildopbau (↓)
- Versioun: v1.1
- Datumer: Januar-Februar Abrëll*
Déi aktuell Versioun vu werf sammelt d'Biller an Artefakte beschriwwen an werf.yaml, sequenziell. Et ass néideg de Prozess vun der Sammlung vun onofhängege Stadien vu Biller an Artefakte parallel ze maachen, souwéi praktesch an informativ Ausgab ze bidden.
* Notiz: d'Deadline gouf verréckelt wéinst enger verstäerkter Prioritéit fir d'Ëmsetzung vun verdeelt Versammlung, déi méi horizontale Skaléierungsfäegkeeten bäidréit, souwéi d'Benotzung vu Werf mat GitHub Actions. Parallel Assemblée ass den nächsten Optimisatiounsschrëtt, déi vertikal Skalierbarkeet ubitt wann Dir ee Projet montéiert.
Iwwergank op Helm 3 (↓)
- Versioun: v1.2
- Datumer: Februar-Mäerz Mee*
Ëmfaasst Migratioun op nei Codebase an e bewährte, praktesche Wee fir existent Installatiounen ze migréieren.
* Bemierkung: Wiessel op Helm 3 wäert keng bedeitend Features op d'werf bäidroen, well all d'Schlësselfeatures vum Helm 3 (3-Wee-Fusioun a kee Tiller) scho a werf implementéiert sinn. Ausserdeem huet werf zousätzlech zu deenen uginn. Dësen Iwwergang bleift awer an eise Pläng a wäert ëmgesat ginn.
Jsonnet fir Kubernetes Konfiguratioun ze beschreiwen (↓)
- Versioun: v1.2
- Datumer: Januar-Februar Abrëll-Mee
Werf wäert Konfiguratiounsbeschreiwunge fir Kubernetes am Jsonnet Format ënnerstëtzen. Zur selwechter Zäit bleift werf kompatibel mat Helm an et gëtt e Choix vum Beschreiwungsformat.
De Grond ass datt Go Templates, laut ville Leit, eng héich Entrée Barriär hunn, an d'Verständlechkeet vum Code vun dëse Templates och leiden.
D'Méiglechkeet fir aner Kubernetes Konfiguratiounsbeschreiwungssystemer aféieren (zum Beispill Kustomize) gëtt och berücksichtegt.
Schafft bannent Kubernetes (↓)
- Versioun: v1.2
- Datumer: Abrëll-Mee Mee-Juni
Zil: Gitt sécher datt d'Biller gebaut ginn an d'Applikatioun mat Leefer a Kubernetes geliwwert gëtt. Déi. Nei Biller kënne gebaut, publizéiert, gebotzt an direkt aus Kubernetes Pods ofgebaut ginn.
Fir dës Fäegkeet ëmzesetzen, braucht Dir als éischt d'Fäegkeet verdeelt Biller ze bauen (kuckt de Punkt uewen).
Et erfuerdert och Ënnerstëtzung fir de Betribsmodus vum Builder ouni Docker Server (dh Kaniko-ähnlechen Build oder am Userspace bauen).
Werf wäert d'Bau op Kubernetes ënnerstëtzen net nëmme mat Dockerfile, awer och mat sengem Stapel Builder mat inkrementellen Rebuilds an Ansible.
E Schrëtt a Richtung oppe Entwécklung
Mir hunn eis Gemeinschaft gär (, ) a mir wëllen datt ëmmer méi Leit hëllefe fir d'werf besser ze maachen, d'Richtung ze verstoen an déi mir eis beweegen an un der Entwécklung deelhuelen.
Ganz viru kuerzem gouf decidéiert op ze wiesselen fir den Aarbechtsprozess vun eisem Team z'entdecken. Elo kënnt Dir déi direkt Pläng gesinn, souwéi aktuell Aarbecht an de folgende Beräicher:
- ;
- ;
- ;
- .
Vill Aarbecht gouf mat Themen gemaach:
- Ewechzehuelen irrelevant.
- Déi existent ginn an een eenzegt Format bruecht, mat enger genuch Zuel vun Detailer an Detailer.
- Nei Themen mat Iddien a Virschléi goufen derbäigesat.
Wéi aktivéiert Versioun v1.1
D'Versioun ass de Moment verfügbar an (an de Kanäl stabil ass и steenfest Verëffentlechungen erschéngen awer wéi d'Stabiliséierung geschitt ea selwer ass scho stabil genuch fir ze benotzen, well duerch d'Kanäl gaangen Alpha и Beta). Aktivéiert op déi folgend Manéier:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Konklusioun
Déi nei Bühnespäicherarchitektur a Builderoptimiséierunge fir Stapel an Dockerfile Builder maachen d'Méiglechkeet op fir verdeelt a parallel Builds am werf ëmzesetzen. Dës Fonctiounen erschéngen geschwënn an der selwechter v1.1 Verëffentlechung a ginn automatesch duerch den automateschen Update Mechanismus verfügbar (fir Benotzer ).
An dëser Verëffentlechung ass eng Tagging Strategie baséiert op Bildinhalt bäigefüügt - Inhalt-baséiert Tagging, déi d'Standardstrategie ginn ass. Den Haaptkommandolog ass och ëmgeschafft ginn: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Deen nächste wichtege Schrëtt ass d'verdeelt Versammlungen ze addéieren. Verdeelt Builds sinn eng méi héich Prioritéit ginn wéi parallel Builds zënter v1.0 well se méi Wäert op Werf addéieren: vertikal Skala vu Builder an Ënnerstëtzung fir ephemeral Builder a verschiddene CI / CD Systemer, souwéi d'Fäegkeet fir offiziell Ënnerstëtzung fir GitHub Actions ze maachen . Dofir goufen d'Ëmsetzungsfriste fir parallel Versammlungen verréckelt. Mir schaffen awer fir béid Méiglechkeeten sou séier wéi méiglech ëmzesetzen.
Follegt d'Neiegkeeten! An vergiesst net eis ze besichen um fir en Thema ze kreéieren, eng existéierend ze fannen an e Plus ze addéieren, e PR erstellen oder einfach d'Entwécklung vum Projet kucken.
PS
Liest och op eisem Blog:
- «»
- «";
- Eng Serie vun Notizen iwwer Innovatiounen am werf:
- «";
- «";
- «";
- «".
Source: will.com