Get best of the week

Werf 1.1 Release: Verbesserungen im Sammler heute und Pläne für die Zukunft



werf ist unser Open-Source-Dienstprogramm GitOps CLI zum Erstellen und Bereitstellen von Anwendungen für Kubernetes. Wie versprochen war die Veröffentlichung von v1.0 der Beginn des Hinzufügens neuer Funktionen zu werf und der Überarbeitung bekannter Ansätze. Jetzt freuen wir uns, v1.1 zu veröffentlichen, was ein großer Schritt in der Entwicklung und der Zukunft im Collector Werf ist. Die Version ist derzeit in Kanal 1.1 verfügbar .

Grundlage der Veröffentlichung ist die neue Architektur des Bühnenspeichers und die Optimierung der Arbeit beider Kollektoren (für Stapel und Dockerfile). Die neue Speicherarchitektur eröffnet die Möglichkeit, verteilte Assemblys von mehreren Hosts und parallele Assemblys auf einem einzelnen Host zu implementieren.

Die Optimierung der Arbeit umfasst die Beseitigung unnötiger Berechnungen bei der Berechnung von Stufensignaturen und die Änderung der Mechanismen zur Berechnung von Dateiprüfsummen in effizientere. Diese Optimierung reduziert die durchschnittliche Erstellungszeit eines Projekts mit werf. Und Leerlauf-Builds sind jetzt sehr schnell , wenn alle Stufen im Stufen-Speicher- Cache vorhanden sind. In den meisten Fällen ist der Neustart der Baugruppe schneller als in 1 Sekunde! Dies gilt auch für die Verfahren zur Überprüfung von Phasen während der Arbeit von Teams werf deployund werf run.

Auch in dieser Version gab es eine Strategie zum Markieren von Bildern nach Inhalten - inhaltsbasiertes Markieren , das jetzt standardmäßig aktiviert ist und das einzige empfohlene ist.

Schauen wir uns die wichtigsten Innovationen in werf v1.1 genauer an und sprechen wir gleichzeitig über Pläne für die Zukunft.

Was hat sich in werf v1.1 geändert?


Neues Stage-Benennungsformat und Cache-Stage-Auswahlalgorithmus


Neue Regel zur Generierung von Künstlernamen. Jetzt generiert jede Stufenbaugruppe einen eindeutigen Stufennamen, der aus zwei Teilen besteht: einer Signatur (wie in Version 1.0) und einer eindeutigen temporären Kennung.

Beispielsweise kann der vollständige Name des Bühnenbilds folgendermaßen aussehen:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... oder in allgemeiner Form:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Hier:

  • SIGNATURE - Dies ist die Bühnensignatur, die die Kennung des Bühneninhalts darstellt und von der Historie der Änderungen in Git abhängt, die zu diesem Inhalt geführt haben.
  • TIMESTAMP_MILLISEC - Dies garantiert eine eindeutige Kennung für das Bild, das zum Zeitpunkt der Zusammenstellung des neuen Bildes generiert wird.

Der Algorithmus zum Auswählen von Stufen aus dem Cache basiert auf der Überprüfung der Beziehung von Git-Commits:

  1. Werf berechnet die Signatur einer Stufe.
  2. Bei der Speicherung von Stufen kann es für eine bestimmte Signatur mehrere Stufen geben. Werf wählt alle Stufen aus, die für die Signatur geeignet sind.
  3. Wenn die aktuelle Phase mit Git zugeordnet ist (GIT-Archiv, user Schritt c Git-Patches: install, beforeSetup, setup, oder GIT-neuesten-Patch), dann Werf wählt nur jene Schritte, zu begehen beziehen, die die Vorfahren des aktuellen commit (für die verursachte Montag )
  4. Von den verbleibenden geeigneten Stufen wird eine ausgewählt - die älteste nach Erstellungsdatum.

Eine Bühne für verschiedene Git-Zweige kann dieselbe Signatur haben. Werf verhindert jedoch die Verwendung eines Caches, der verschiedenen Zweigen zwischen diesen Zweigen zugeordnet ist, selbst wenn die Signaturen übereinstimmen.

→ Dokumentation .

Neuer Algorithmus zum Erstellen und Speichern von Stufen im Bühnenspeicher


Wenn werf bei der Auswahl der Stufen aus dem Cache keine geeignete Stufe findet, wird der Prozess des Zusammenbaus einer neuen Stufe eingeleitet.

Beachten Sie, dass mehrere Prozesse (auf einem oder mehreren Hosts) ungefähr zur gleichen Zeit mit dem Zusammenstellen derselben Phase beginnen können. Werf verwendet den Stufen-Speicher optimistischen Verriegelungsalgorithmus , wenn ein frisch gesammeltes Bild gespeichert wird Stufen-Speicher . Wenn somit die Montage der neuen Stufe fertig ist, Werf blockiert die Stufen-Speicher und speichert die frisch dort gesammelt Bild nur , wenn kein geeignetes Bild gibt es (für die Unterschrift und andere Parameter - siehe den neuen Algorithmus für die Stufen aus dem Cache - Auswahl) .

Ein frisch ausgewähltes Bild hat garantiert eine eindeutige Kennung von TIMESTAMP_MILLISEC (siehe das neue Format für die Benennung der Bühne) . Wenn ein geeignetes Bild gefunden wird in Stufen-Lagerung wird werf das frisch gemolkene Bild verwirft und wird das Bild aus dem Cache.

Mit anderen Worten: Der erste Prozess, der das Sammeln des Bildes abschließt (der schnellste), erhält das Recht, es im Stufenspeicher zu speichern (und dann wird dieses bestimmte Bild für alle Baugruppen verwendet). Ein langsamer Montageprozess verhindert niemals, dass ein schnellerer Prozess die Montageergebnisse der aktuellen Phase speichert und mit der nächsten Montage fortfährt.

→ Dokumentation .

Verbesserte Dockerfile Collector-Leistung


Derzeit besteht die Stage-Pipeline für ein aus der Docker-Datei zusammengestelltes Image aus einer Stage - dockerfile. Bei der Berechnung der Signatur wird die Prüfsumme der Dateien berücksichtigt context, die beim Zusammenbau verwendet wird. Vor dieser Verbesserung durchlief werf rekursiv alle Dateien und erhielt eine Prüfsumme, in der der Kontext und der Modus jeder Datei zusammengefasst wurden. Ab Version 1.1 kann werf die berechneten Prüfsummen verwenden, die im Git-Repository gespeichert sind.

Der Algorithmus basiert auf git ls-tree . Der Algorithmus berücksichtigt Einträge in .dockerignoreund durchläuft den Dateibaum nur bei Bedarf rekursiv. Somit haben wir das Lesen des Dateisystems losgeworden, und die Abhängigkeit des Algorithmus von der Größe ist contextnicht signifikant.

Der Algorithmus prüft auch nicht verfolgte Dateien und berücksichtigt sie gegebenenfalls in der Prüfsumme.

Verbesserte Leistung beim Importieren von Dateien


Werf v1.1 verwendet den rsync-Server beim Importieren von Dateien aus Artefakten und Bildern . Bisher wurde der Import in zwei Schritten durchgeführt, indem das Verzeichnis vom Hostsystem bereitgestellt wurde.

Die Importleistung unter macOS ist nicht mehr auf Docker-Volumes beschränkt. Der Import erfolgt gleichzeitig mit Linux und Windows.

Inhaltsbasiertes Tagging


Werf v1.1 unterstützt das sogenannte Tagging nach Bildinhalten - inhaltsbasiertes Tagging . Tags für resultierende Docker-Bilder hängen vom Inhalt dieser Bilder ab.

Wenn Sie den Befehl werf publish --tags-by-stages-signatureoder ausführen werf ci-env --tagging-strategy=stages-signature, werden veröffentlichte Bilder der sogenannten Bildstufensignatur getestet . Jedes Bild ist mit einer eigenen Signatur der Stufen dieses Bildes versehen, die nach denselben Regeln wie die reguläre Signatur jeder Stufe separat berechnet wird, jedoch eine verallgemeinerte Kennung des Bildes darstellt.

Die Signatur der Bildstufen hängt ab von:

  1. den Inhalt dieses Bildes;
  2. Git-Revisionsverlauf, der zu diesem Inhalt geführt hat.

Git-Repositorys haben immer Leerlauf-Commits, die den Inhalt der Bilddateien nicht ändern. Beispielsweise werden Commits nur mit Kommentaren oder Commits zusammengeführt oder Commits, die die Dateien in Git ändern, die nicht in das Image importiert werden.

Die Verwendung von inhaltsbasiertem Tagging löst das Problem unnötiger Neustarts von Anwendungs-Pods in Kubernetes aufgrund von Änderungen des Bildnamens, auch wenn sich der Bildinhalt nicht geändert hat. Dies ist übrigens einer der Gründe, die es schwierig machen, viele Microservices einer Anwendung in einem einzigen Git-Repository zu speichern.

Das inhaltsbasierte Tagging ist außerdem eine zuverlässigere Tagging-Methode als das Tagging durch Git-Zweige, da der Inhalt der resultierenden Bilder nicht von der Reihenfolge der Ausführung von Pipelines im CI-System zum Zusammenstellen mehrerer Commits desselben Zweigs abhängt.

Wichtig: Auf, ab sofort Stufen-Signatur die ist nur zu empfehlen Tagging - Strategie . Es wird standardmäßig im Team verwendet werf ci-env(es sei denn, Sie geben explizit ein anderes Tagging-Schema an).

→ Dokumentation . Eine separate Veröffentlichung wird ebenfalls dieser Funktion gewidmet sein. AKTUALISIERT (3. April): Ein Artikel mit Details wurde veröffentlicht .

Protokollierungsstufen


Der Benutzer hat die Möglichkeit, die Ausgabe zu steuern, die Protokollierungsstufe festzulegen und mit Debugging-Informationen zu arbeiten. Hinzufügen von Optionen --log-quiet, --log-verbose, --log-debug.

Standardmäßig enthält die Ausgabe ein Minimum an Informationen:



Wenn Sie die detaillierte Ausgabe ( --log-verbose) verwenden, können Sie nachverfolgen, wie werf funktioniert: Die



detaillierte Ausgabe ( --log-debug) enthält neben den werf-Debugging-Informationen auch die Protokolle der verwendeten Bibliotheken. Sie können beispielsweise sehen, wie die Interaktion mit der Docker-Registrierung abläuft, und die Orte festlegen, an denen viel Zeit aufgewendet wird:



Zukunftspläne


Beachtung! Die unten mit v1.1 gekennzeichneten Funktionen werden in dieser Version verfügbar sein, viele davon in naher Zukunft. Updates werden durch automatische Updates bei Verwendung von Multiwerf durchgeführt . Diese Funktionen wirken sich nicht auf den stabilen Teil der Funktionen von Version 1.1 aus. Für ihr Erscheinungsbild ist kein manueller Eingriff des Benutzers in vorhandene Konfigurationen erforderlich.

Volle Unterstützung für verschiedene Docker Registry-Implementierungen (NEU)



Das Ziel ist, dass der Benutzer bei der Verwendung von werf eine beliebige Implementierung ohne Einschränkungen verwenden sollte.

Bisher haben wir die folgenden Lösungen identifiziert, für die wir volle Unterstützung garantieren werden:

  • Standard (Bibliothek / Registrierung) *,
  • AWS ECR,
  • Azure *,
  • Docker Hub
  • GCR *,
  • Github-Pakete
  • GitLab Registry *,
  • Hafen *,
  • Kai.

Ein Sternchen kennzeichnet Lösungen, die derzeit von werf vollständig unterstützt werden. Für den Rest gibt es Unterstützung, aber mit Einschränkungen.

Zwei Hauptprobleme können unterschieden werden:

  • Einige Lösungen unterstützen das Entfernen von Tags mithilfe der Docker-Registrierungs-API nicht, sodass Benutzer die in werf implementierte automatische Bereinigung nicht verwenden können. Dies gilt für AWS ECR-, Docker Hub- und GitHub-Pakete.
  • Einige Lösungen unterstützen die sogenannten verschachtelten Repositorys (Docker Hub, GitHub Packages und Quay) oder die Unterstützung nicht, aber der Benutzer muss sie manuell über die Benutzeroberfläche oder API (AWS ECR) erstellen.

Wir werden diese und andere Probleme mit nativen APIs von Lösungen lösen. Diese Aufgabe umfasst auch das Abdecken des gesamten Werf-Zyklus mit Tests für jeden von ihnen.

Verteilte Bildassemblierung (↑)



Derzeit können werf v1.0 und v1.1 nur auf einem dedizierten Host für die Zusammenstellung und Veröffentlichung von Images und die Bereitstellung von Anwendungen in Kubernetes verwendet werden.

Um die Möglichkeiten der verteilten Arbeit von werf zu eröffnen, muss werf die Möglichkeit implementieren, die Docker-Registrierung als Stage-Repository zu verwenden, wenn die Assembly und Bereitstellung von Anwendungen in Kubernetes auf mehreren beliebigen Hosts gestartet wird und diese Hosts ihren Status zwischen Assemblys (temporären Läufern) nicht beibehalten.

Früher, als das werf-Projekt noch dapp hieß, hatte es eine solche Gelegenheit. Wir sind jedoch auf eine Reihe von Problemen gestoßen, die bei der Implementierung dieser Funktion in werf berücksichtigt werden müssen.

Hinweis. Diese Funktion impliziert nicht die Arbeit des Sammlers in Kubernetes-Pods, wie Beseitigen Sie dazu die Abhängigkeit vom lokalen Docker-Server (im Kubernetes-Pod gibt es keinen Zugriff auf den lokalen Docker-Server, da der Prozess selbst im Container ausgeführt wird und werf die Arbeit mit dem Docker-Server im Netzwerk nicht unterstützt und nicht unterstützt). Die Unterstützung für die Arbeit in Kubernetes wird separat implementiert.

Offizieller GitHub Actions Support (NEU)



Enthält die werf-Dokumentation ( Referenz- und Leitfadenabschnitte ) sowie die offizielle GitHub-Aktion für die Arbeit mit werf.

Außerdem kann werf an kurzlebigen Läufern arbeiten.

Die Mechanismen der Benutzerinteraktion mit dem CI-System basieren darauf, dass Pull-Anforderungen beschriftet werden, um bestimmte Aktionen zum Erstellen / Ausrollen der Anwendung einzuleiten.

Lokale Anwendungsentwicklung und -bereitstellung mit werf (↓)


  • Version: v1.1
  • Termine: Januar-Februar April
  • Problem

Das Hauptziel besteht darin, eine einheitliche Konfiguration für die sofortige Bereitstellung von Anwendungen sowohl lokal als auch in der Produktion ohne komplexe Aktionen zu erreichen.

Werf benötigt auch eine Betriebsart, in der es bequem ist, den Anwendungscode zu bearbeiten und sofort Feedback von einer funktionierenden Anwendung zum Debuggen zu erhalten.

Neuer Reinigungsalgorithmus (NEU)



In der aktuellen Version von werf v1.1 cleanupsieht das Verfahren keine Bereinigung von Bildern für das inhaltsbasierte Tagging-Schema vor - diese Bilder werden akkumuliert.

In der aktuellen Version von werf (v1.0 und v1.1) werden für Bilder, die durch Tagging-Schemata veröffentlicht wurden, unterschiedliche Reinigungsrichtlinien verwendet: Git-Zweig, Git-Tag oder Git-Commit.

Basierend auf der Geschichte der Commits in Git wurde ein neuer einheitlicher Bildbereinigungsalgorithmus für alle Tagging-Schemata erfunden:

  • Speichern Sie nicht mehr als N1 Bilder, die mit den letzten N2-Commits für jeden Git-HEAD (Zweige und Tags) verknüpft sind.
  • Speichern Sie nicht mehr als N1 Bildstufen, die mit den letzten N2-Commits für jeden Git-HEAD (Zweige und Tags) verknüpft sind.
  • , - Kubernetes ( kube- namespace'; ).
  • , , Helm-.
  • , HEAD git (, HEAD ) Kubernetes Helm.

(↓)


  • : v1.1
  • : - *

Die aktuelle Version von werf sammelt die in beschriebenen Bilder und Artefakte werf.yamlnacheinander. Es ist notwendig, den Prozess der Zusammenstellung unabhängiger Stufen von Bildern und Artefakten zu parallelisieren und eine bequeme und informative Schlussfolgerung zu ziehen.

* Hinweis: Die Frist wird aufgrund der erhöhten Priorität für die Implementierung einer verteilten Assembly verschoben, wodurch weitere Funktionen für die horizontale Skalierung sowie die Verwendung von werf mit GitHub-Aktionen hinzugefügt werden. Die parallele Montage ist der nächste Optimierungsschritt und bietet vertikale Skalierbarkeit beim Zusammenstellen eines einzelnen Projekts.

Wechseln Sie zu Helm 3 (↓)


  • Version: v1.2
  • Daten: Februar-März Mai *

Es beinhaltet den Übergang zur neuen Helm 3- Codebasis und eine bewährte und bequeme Möglichkeit, vorhandene Installationen zu migrieren.

* Hinweis: Wenn Sie zu Helm 3 wechseln, werden werf keine wesentlichen Funktionen hinzugefügt, da alle wichtigen Funktionen von Helm 3 (3-Wege-Zusammenführung und fehlende Pinne) bereits in werf implementiert sind. Darüber hinaus verfügt werf neben den angegebenen über weitere Funktionen . Dieser Übergang bleibt jedoch in unseren Plänen und wird umgesetzt.

Konfigurationsbeschreibung für Jsonnet für Kubernetes (↓)


  • Version: v1.2
  • Daten: Januar-Februar April-Mai

Werf unterstützt die Konfigurationsbeschreibung für Kubernetes im Jsonnet-Format. Gleichzeitig bleibt werf mit Helm kompatibel und es kann ein Beschreibungsformat ausgewählt werden.

Der Grund ist die Tatsache, dass die Go-Sprachmuster nach Ansicht vieler Menschen eine große Eintrittsschwelle haben und die Code-Verständlichkeit dieser Muster ebenfalls leidet.

Andere Optionen zum Implementieren von Kubernetes-Konfigurationsbeschreibungssystemen (wie Kustomize) werden ebenfalls in Betracht gezogen.

Arbeit in Kubernetes (↓)


  • Version: v1.2
  • Termine: April-Mai Mai-Juni

Zweck: Sicherstellen der Zusammenstellung von Bildern und der Bereitstellung von Anwendungen mithilfe von Läufern in Kubernetes. Jene. Das Zusammenstellen neuer Bilder, deren Veröffentlichung, Bereinigung und Bereitstellung kann direkt über Kubernetes-Pods erfolgen.

Um diese Funktion zu realisieren, müssen Sie zunächst in der Lage sein, Bilder verteilt zu erstellen (siehe Abschnitt oben) .

Es erfordert auch Unterstützung für den Build-Betriebsmodus ohne den Docker-Server (d. H. Kaniko-ähnliche Erstellung oder Assembly im Benutzerbereich).

Werf wird Kubernetes-Builds nicht nur mit dem Dockerfile unterstützen, sondern auch mit seinem Stapel-Builder mit inkrementellen Neuerstellungen und Ansible.

Schritt in Richtung Open Source-Entwicklung


Wir lieben unsere Community ( GitHub , Telegram ) und wir möchten, dass immer mehr Menschen dazu beitragen, werf besser zu machen, zu verstehen, in welche Richtung wir uns bewegen, und an der Entwicklung teilnehmen.

Zuletzt wurde beschlossen, auf GitHub-Projektboards zu wechseln , um den Workflow unseres Teams zu öffnen. Jetzt können Sie die unmittelbaren Pläne sowie die laufenden Arbeiten in den folgenden Bereichen sehen:


Es wurde viel Arbeit mit folgenden Themen geleistet:

  • Irrelevant entfernt.
  • Bestehende werden auf ein einziges Format reduziert, eine ausreichende Anzahl von Details und Details.
  • Neue Themen mit Ideen und Vorschlägen hinzugefügt.

So aktivieren Sie Version v1.1


Die Version ist derzeit in Kanal 1.1 ea verfügbar ( Releases in stabilen und felsenfesten Kanälen werden angezeigt, wenn sie sich stabilisieren, aber ea selbst ist bereits stabil genug für die Verwendung, da es über Alpha- und Beta- Kanäle geleitet wird ). Es wird über Multiwerf folgendermaßen aktiviert :

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Fazit


Die neue Stage-Store-Architektur und die optimierte Kollektorleistung für die Stapel- und Dockerfile-Kollektoren eröffnen die Möglichkeit, verteilte und parallele Assemblys in werf zu implementieren. Diese Funktionen werden in Kürze in derselben Version 1.1 erscheinen und automatisch über den automatischen Aktualisierungsmechanismus (für Multiwerf- Benutzer ) verfügbar sein .

In dieser Version wurde eine inhaltsbasierte Tagging- Strategie hinzugefügt , die zur Standardstrategie wurde. Ein Protokoll wurde auch die grundlegenden Befehle neu gestaltet: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Der nächste wichtige Schritt besteht darin, verteilte Baugruppen hinzuzufügen. Verteilte Assemblys seit Version 1.0 haben eine höhere Priorität als parallele Assemblys, da sie einen höheren Werf-Wert bieten: vertikale Skalierung von Kollektoren und Unterstützung für kurzlebige Kollektoren in verschiedenen CI / CD-Systemen sowie die Möglichkeit, GitHub-Aktionen offiziell zu unterstützen. Daher wurde der Zeitpunkt für die Implementierung paralleler Baugruppen verschoben. Wir arbeiten jedoch daran, beide Möglichkeiten schnell zu realisieren.

Folgen Sie den Nachrichten! Und vergessen Sie nicht, bei unserem GitHub vorbeizuschauen , um ein Problem zu erstellen, ein vorhandenes zu finden und ein Plus zu setzen, eine PR zu erstellen oder einfach die Entwicklung des Projekts zu verfolgen.

PS


Lesen Sie auch in unserem Blog:

More articles:


All Articles