🥇Release werf 1.1: Verbesserungen im Builder heute und Pläne für die Zukunft

werf — unser Open-Source GitOps CLI-Tool zum Erstellen und Bereitstellen von Anwendungen in Kubernetes. Wie versprochen, wurde die Version v1.0 zum Beginn der Einführung neuer Funktionen in werf und der Überarbeitung gewohnter Ansätze. Nun freuen wir uns, das Release v1.1 vorzustellen, das einen großen Schritt in der Entwicklung darstellt und die Grundlage für die Zukunft legt. Builder werf. Die Version ist derzeit verfügbar auf dem Kanal 1.1 ea.

Die Grundlage des Releases ist die neue Architektur des Stages-Speichers und die Optimierung der Arbeit beider Builder (für Stapel und Dockerfile). Die neue Architektur des Speichers eröffnet die Möglichkeit, verteilte Builds von mehreren Hosts und parallele Builds auf einem Host zu realisieren.

Die Optimierung umfasst die Beseitigung überflüssiger Berechnungen während der Berechnung der Stages-Signaturen sowie Änderungen in den Mechanismen zur Berechnung von Prüfziffern für Dateien auf effizientere Weise. Diese Optimierung verringert die durchschnittliche Bauzeit eines Projekts mit werf. Und leere Builds, bei denen alle Stufen im Cache vorhanden sind stages-storage, sind jetzt wirklich schnell. In den meisten Fällen wird der erneute Start eines Builds schneller als in 1 Sekunde erfolgen! Dies gilt auch für die Validierungsverfahren der Stufen während der Arbeit mit den Teams. werf deploy und werf run.

In dieser Version wurde auch eine Strategie zur Tagging von Images nach Inhalt eingeführt — content-based tagging, die nun standardmäßig aktiviert ist und die einzige empfohlene Methode ist.

Lassen Sie uns die wichtigsten Neuerungen in werf v1.1 im Detail betrachten und gleichzeitig über die Pläne für die Zukunft sprechen.

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

Neues Namensformat für Stufen und Algorithmus zur Auswahl von Stufen aus dem Cache

Neue Regel zur Generierung des Stufen-Namens. Nun generiert jede Build-Stufe einen einzigartigen Stufen-Namen, der aus 2 Teilen besteht: einer Signatur (wie in v1.0) plus einer einzigartigen zeitlichen Kennung.

Zum Beispiel könnte der vollständige Name des Stufen-Images so aussehen:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

… oder im allgemeinen Format:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Hier:

SIGNATURE — ist die Signatur der Stufe, die den Inhalt der Stufe identifiziert und von der Geschichte der Änderungen in Git abhängt, die zu diesem Inhalt geführt haben;
TIMESTAMP_MILLISEC — ist ein garantiert einzigartiger Kennzeichner des Images, der zum Zeitpunkt des Builds eines neuen Images generiert wird.

Der Algorithmus zur Auswahl von Stufen aus dem Cache basiert auf der Überprüfung der Verwandtschaft von Git-Commits:

Werf berechnet die Signatur einer bestimmten Phase.
Im stages-storage Es kann mehrere Phasen mit dieser Signatur geben. Werf wählt alle passenden Phasen basierend auf der Signatur aus.
Wenn die aktuelle Phase mit Git verbunden ist (git-archive, benutzerdefinierte Phase mit Git-Patches: install, beforeSetup, setup; oder git-latest-patch), wählt werf nur die Phasen aus, die mit dem Commit verbunden sind, der dem aktuellen Commit (für den der Build aufgerufen wurde) vorangeht.
Von den verbleibenden passenden Phasen wird eine ausgewählt – die älteste basierend auf dem Erstellungsdatum.

Eine Phase kann für verschiedene Git-Zweige dieselbe Signatur besitzen. Aber werf wird die Verwendung des Caches, der mit verschiedenen Zweigen verbunden ist, zwischen diesen Zweigen verhindern, selbst wenn die Signaturen übereinstimmen.

→ Dokumentation.

Neuer Algorithmus zur Erstellung und Speicherung von Phasen im Phasen-Repository

Wenn beim Abrufen von Phasen aus dem Cache werf keine passende Phase findet, wird der Prozess zum Erstellen einer neuen Phase eingeleitet.

Es ist zu beachten, dass mehrere Prozesse (auf einem oder mehreren Hosts) mit dem Erstellen derselben Phase nahezu gleichzeitig beginnen können. Werf verwendet einen Algorithmus für optimistische Sperrung stages-storage zum Zeitpunkt der Speicherung des frisch erstellten Images in stages-storage. Dadurch wird sichergestellt, dass, wenn die Erstellung einer neuen Phase abgeschlossen ist, werf stages-storage sperrt und das frisch erstellte Image dort nur speichert, wenn dort bereits kein passendes Image existiert (basierend auf Signatur und anderen Parametern – siehe neuer Algorithmus zum Abrufen von Phasen aus dem Cache).

Das frisch erstellte Image wird garantiert eine eindeutige ID basierend auf TIMESTAMP_MILLISEC (siehe neues Namensschema für Phasen). Falls in stages-storage ein passendes Image gefunden wird, wird werf das frisch erstellte Image verwerfen und das Image aus dem Cache verwenden.

Mit anderen Worten: Der erste Prozess, der die Erstellung des Images abschließt (der schnellste), erhält das Recht, es im stages-storage zu speichern (und nur dieses eine Image wird dann für alle Builds verwendet). Ein langsamerer Erstellungsprozess wird niemals den schnelleren Prozess daran hindern, die Ergebnisse der Erstellung der aktuellen Phase zu speichern und mit der Erstellung der nächsten Phase fortzufahren.

→ Dokumentation.

Verbesserte Leistung des Dockerfile-Builders

Derzeit besteht die Pipeline der Phasen für das aus Dockerfile erstellte Image aus einer Phase – dockerfile. Bei der Berechnung der Signatur wird die Prüfziffer der Dateien berücksichtigt. context, die bei der Erstellung verwendet werden. Vor dieser Verbesserung durchlief werf rekursiv alle Dateien und erhielt eine Prüfziffer, indem der Kontext und der Mod von jeder Datei summiert wurden. Ab Version v1.1 kann werf die berechneten Prüfziffern verwenden, die im Git-Repository gespeichert sind.

Die Grundlage des Algorithmus bildet git ls-tree. Der Algorithmus berücksichtigt Einträge in .dockerignore und durchläuft rekursiv den Dateibaum nur bei Bedarf. Somit sind wir von der Dateisystemabfrage entkoppelt, und die Abhängigkeit des Algorithmus von der Größe context ist nicht erheblich.

Der Algorithmus überprüft auch untracked Dateien und berücksichtigt sie bei Bedarf in der Prüfziffer.

Die Leistungsfähigkeit beim Import von Dateien wurde verbessert

In den Versionen von werf v1.1 wird beim Import von Dateien aus Artefakten und Images ein rsync-Server verwendet.Früher wurde der Import in zwei Schritten unter Verwendung der Verzeichnismontage aus dem Host-System durchgeführt.

Die Importgeschwindigkeit in macOS ist nicht mehr durch Docker-Volumes begrenzt, und die Importe werden in der gleichen Zeit wie in Linux und Windows durchgeführt.

Inhaltsbasiertes Tagging

Werf v1.1 unterstützt das sogenannte Tagging nach dem Inhalt des Images — content-based tagging. Die Tags der resultierenden Docker-Images hängen vom Inhalt dieser Images ab.

Beim Ausführen des Befehls werf publish --tags-by-stages-signature oder werf ci-env --tagging-strategy=stages-signature werden die veröffentlichten Images mit der sogenannten Stufen-Signatur des Images getaggt. Jedes Image wird mit seiner eigenen Stufen-Signatur dieses Images getaggt, die nach den gleichen Regeln berechnet wird wie die reguläre Signatur jeder Stufe einzeln, jedoch ein zusammenfassender Identifikator des Images ist.

Die Stufen-Signatur des Images hängt ab von:

dem Inhalt dieses Images;
der Historie der Änderungen in Git, die zu diesem Inhalt geführt haben.

Im Git-Repository gibt es immer leere Commits, die den Inhalt der Dateien im Image nicht verändern. Zum Beispiel Commits, die nur Kommentare enthalten oder Merge-Commits, oder Commits, die Dateien in Git ändern, die nicht in das Image importiert werden.

Bei Verwendung des inhaltsbasierten Taggings werden Probleme mit unnötigen Neustarts von Pods der Anwendung in Kubernetes aufgrund von Änderungen am Namen des Images gelöst, selbst wenn sich der Inhalt des Images nicht geändert hat. Übrigens ist das einer der Gründe, die es erschweren, viele Mikrodienste einer Anwendung in einem einzigen Git-Repository zu speichern.

Auch das content-based Tagging ist eine zuverlässigere Methode zum Tagging als das Tagging nach Git-Branches, da der Inhalt der resultierenden Images nicht von der Ausführungsreihenfolge der Pipelines im CI-System zur Erstellung mehrerer Commits desselben Branches abhängt.

Wichtig: ab diesem Zeitpunkt stages-signature sind die einzige empfohlene Tagging-Strategie. Genau diese wird standardmäßig im Team verwendet werf ci-env (sofern nicht ausdrücklich ein anderes Tagging-Schema angegeben wird).

→ Dokumentation. Dieser Funktion wird auch ein separater Beitrag gewidmet sein. AKTUALISIERT (3. April): Artikel mit Details wurde veröffentlicht.

Logging-Ebenen

Der Benutzer hat die Möglichkeit, die Ausgabe zu kontrollieren, das Log-Level festzulegen und mit Debug-Informationen zu arbeiten. Es wurden Optionen hinzugefügt --log-quiet, --log-verbose, --log-debug.

Standardmäßig enthält die Ausgabe minimale Informationen:

Durch die Verwendung der detaillierten Ausgabe (--log-verbose) kann nachvollzogen werden, wie werf funktioniert:

Detaillierte Ausgabe (--log-debug) enthält neben Debug-Informationen von werf auch die Logs der verwendeten Bibliotheken. Zum Beispiel kann man sehen, wie die Interaktion mit dem Docker Registry abläuft, sowie Stellen protokollieren, an denen erheblich Zeit aufgebracht wird:

Zukunftspläne

Achtung! Die nachfolgend beschriebenen Funktionen mit dem Hinweis v1.1 werden bereits in dieser Version verfügbar sein, viele von ihnen – in naher Zukunft. Aktualisierungen erfolgen über Auto-Updates bei Verwendung von multiwerf. Diese Funktionen betreffen nicht den stabilen Teil der Funktionen von v1.1, deren Einführung erfordert kein manuelles Eingreifen des Benutzers in bestehende Konfigurationen.

Vollständige Unterstützung verschiedener Implementierungen von Docker Registry (NEU)

Version: v1.1
Zeitrahmen: März
Issue

Ziel – der Benutzer soll beliebige Implementierungen ohne Einschränkungen bei der Verwendung von werf nutzen können.

Derzeit haben wir die folgende Lösungssatz ausgewählt, für den wir vollständige Unterstützung garantieren:

Default (library/registry)*,
AWS ECR,
Azure*,
Docker Hub,
GCR*,
GitHub Packages,
GitLab Registry*,
Harbor*,
Quay.

Mit einem Sternchen gekennzeichnete Lösungen werden derzeit bereits vollständig von werf unterstützt. Für die übrigen gibt es Unterstützung, jedoch mit Einschränkungen.

Es gibt zwei Hauptprobleme zu beachten:

Einige Lösungen unterstützen nicht das Löschen von Tags über die Docker Registry API, was es den Benutzern nicht ermöglicht, die in werf implementierte automatische Bereinigung zu nutzen. Dies trifft auf AWS ECR, Docker Hub und GitHub Packages zu.
Einige Lösungen unterstützen die sogenannten verschachtelten Repositories (Docker Hub, GitHub Packages und Quay) nicht oder unterstützen sie nur, wenn der Benutzer sie manuell über die UI oder API (AWS ECR) erstellt.

Diese und weitere Probleme möchten wir mithilfe der nativen APIs der Lösungen angehen. Zu dieser Aufgabe gehört auch die Testabdeckung des vollständigen Arbeitszyklus von werf für jede von ihnen.

Verteilte Bildbau (↑)

Version: v1.2 v1.1 (die Priorität für die Umsetzung dieser Funktion wurde erhöht)
Zeitraum: März-April März
Issue

Derzeit können werf v1.0 und v1.1 nur auf einem dedizierten Host für das Bauen und Veröffentlichen von Bildern sowie das Bereitstellen von Anwendungen in Kubernetes verwendet werden.

Um die Möglichkeiten für die verteilte Arbeit von werf zu eröffnen, wenn das Bauen und Bereitstellen von Anwendungen in Kubernetes auf mehreren beliebigen Hosts gestartet wird und diese Hosts ihren Zustand zwischen den Builds nicht speichern (temporäre Runner), ist von werf die Umsetzung der Möglichkeit erforderlich, Docker Registry als Speicher für die Stufen zu verwenden.

Früher, als das Projekt werf noch dapp hieß, gab es diese Möglichkeit. Allerdings sind wir auf eine Reihe von Problemen gestoßen, die bei der Umsetzung dieser Funktion in werf berücksichtigt werden müssen.

Hinweis. Diese Möglichkeit sieht nicht vor, den Builder innerhalb von Kubernetes-Pods zu betreiben, da es dafür notwendig ist, die Abhängigkeit vom lokalen Docker-Server loszuwerden (im Kubernetes-Pod gibt es keinen Zugang zum lokalen Docker-Server, da der Prozess selbst in einem Container ausgeführt wird, und die Kommunikation mit dem Docker-Server über das Netzwerk wird von werf nicht unterstützt und wird nicht unterstützt werden). Die Unterstützung der Arbeit in Kubernetes wird separat umgesetzt.

Offizielle Unterstützung für GitHub Actions (NEU)

Version: v1.1
Zeitrahmen: März
Issue

Beinhaltet die Dokumentation von werf (Abschnitte Referenz und Leitfaden), sowie die offizielle GitHub-Aktion zur Arbeit mit werf.

Außerdem ermöglicht es, dass werf auf ephemeren Runnern arbeitet.

Die Interaktion des Benutzers mit dem CI-System wird auf der Basis der Vergabe von Labels an Pull-Requests beruhen, um bestimmte Aktionen beim Bauen/Deployen der Anwendung auszulösen.

Lokale Entwicklung und Bereitstellung von Anwendungen mit werf (↓)

Version: v1.1
Zeitraum: Januar-Februar April
Issue

Das Hauptziel besteht darin, eine einheitliche, standardisierte Konfiguration für die Bereitstellung von Anwendungen sowohl lokal als auch in der Produktion zu erreichen, ohne komplizierte Schritte, „out of the box“.

Auch werf benötigt einen Betriebsmodus, in dem der Code der Anwendung bequem bearbeitet werden kann und sofortiges Feedback von der laufenden Anwendung für das Debugging bereitgestellt wird.

Neuer Reinigungsalgorithmus (NEU)

Version: v1.1
Fristen: April
Issue

In der aktuellen Version von werf v1.1 ist im Verfahren Bereinigung keine Reinigung von Images für das content-based tagging vorgesehen — diese Images werden sich ansammeln.

In der aktuellen Version von werf (v1.0 und v1.1) werden zudem unterschiedliche Reinigungsrichtlinien für Images verwendet, die nach den Tagging-Schemata veröffentlicht werden: Git-Branch, Git-Tag oder Git-Commit.

Ein neuer einheitlicher Reinigungsalgorithmus für alle Tagging-Schemata wurde auf der Grundlage der Commit-Historie in Git entwickelt:

Es sollen nicht mehr als N1 Images gespeichert werden, die mit den letzten N2 Commits für jedes git HEAD (Branches und Tags) verknüpft sind.
Es sollen nicht mehr als N1 Stage-Images gespeichert werden, die mit den letzten N2 Commits für jedes git HEAD (Branches und Tags) verknüpft sind.
Alle Images, die in irgendeiner Ressourcenkonfiguration des Kubernetes-Clusters verwendet werden, sollen gespeichert werden (alle kube-Kontexte der Konfigurationsdatei und Namespaces werden gescannt; dieses Verhalten kann durch spezielle Optionen eingeschränkt werden).
Alle Images, die in den Konfigurationsmanifesten von Ressourcen, die in Helm-Releases gespeichert sind, verwendet werden, sollen gespeichert werden.
Ein Image kann gelöscht werden, wenn es mit keinem HEAD aus git verknüpft ist (zum Beispiel weil der entsprechende HEAD selbst gelöscht wurde) und in keinem der Manifesten im Kubernetes-Cluster und in den Helm-Releases verwendet wird.

Paralleler Aufbau von Images (↓)

Version: v1.1
Fristen: Januar-Februar April*

Die aktuelle Version von werf baut die in werf.yamlbeschriebenen Images und Artefakte nacheinander auf. Es ist notwendig, den Aufbau der unabhängigen Stufen von Images und Artefakten zu parallelisieren und einen benutzerfreundlichen sowie informativen Output zu gewährleisten.

* Hinweis: Der Termin wurde aufgrund der Erhöhung der Priorität für die Implementierung des verteilten Builds verschoben, der mehr Möglichkeiten für horizontale Skalierung hinzufügen wird, sowie für die Verwendung von werf mit GitHub Actions. Parallelbau ist der nächste Schritt in der Optimierung, der vertikale Skalierbarkeit beim Bau eines einzelnen Projekts bietet.

Umstellung auf Helm 3 (↓)

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

Beinhaltet die Umstellung auf die neue Codebasis Helm 3 und eine erprobte, benutzerfreundliche Methode zur Migration bestehender Installationen.

* Hinweis: Der Umstieg auf Helm 3 bringt keine wesentlichen Vorteile für werf, da alle Schlüsselmerkmale von Helm 3 (3-way-merge und die Abwesenheit von Tiller) bereits in werf umgesetzt sind. Darüber hinaus verfügt werf über zusätzliche Möglichkeiten neben den genannten. Dieser Umstieg bleibt jedoch in unseren Plänen und wird umgesetzt werden.

Jsonnet zur Beschreibung von Kubernetes-Konfigurationen (↓)

Version: v1.2
Fristen: Januar-Februar April-Mai

Werf wird die Beschreibung von Konfigurationen für Kubernetes im Jsonnet-Format unterstützen. Dabei bleibt werf mit Helm kompatibel und es wird die Möglichkeit bestehen, das Beschreibungsformat zu wählen.

Der Grund dafür ist, dass viele Menschen der Meinung sind, dass die Vorlagen der Go-Sprache eine hohe Einstiegshürde haben und die Verständlichkeit des Codes dieser Vorlagen ebenfalls leidet.

Es wird auch die Möglichkeit in Betracht gezogen, andere Systeme zur Beschreibung von Kubernetes-Konfigurationen (z.B. Kustomize) einzuführen.

Arbeiten innerhalb von Kubernetes (↓)

Version: v1.2
Fristen: April-Mai Mai-Juni

Ziel: Gewährleistung des Bauens von Images und der Bereitstellung von Anwendungen unter Verwendung von Runnern in Kubernetes. Das heißt, der Bau neuer Images, deren Veröffentlichung, Reinigung und Deployment kann direkt aus den Pods von Kubernetes erfolgen.

Um diese Möglichkeit zu realisieren, ist zuerst die Möglichkeit des verteilten Bauens von Images erforderlich (vgl. Punkt oben).

Es wird auch Unterstützung für den Betrieb des Builders ohne Docker-Server benötigt (d.h. Kaniko-ähnlicher Build oder Build im Userspace).

Werf wird den Build in Kubernetes nicht nur mit Dockerfile, sondern auch mit seinem Builder Stapel mit inkrementellen Neu-Bauten und Ansible unterstützen.

Ein Schritt in Richtung offene Entwicklung

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

Vor kurzem wurde beschlossen, auf GitHub-Projektboards um den Arbeitsprozess unseres Teams ein wenig transparenter zu gestalten. Momentan können die nächsten Pläne sowie die laufenden Arbeiten in folgenden Bereichen eingesehen werden:

Es wurde viel Arbeit an Issues geleistet:

Veraltete wurden entfernt.
Bestehende wurden in ein einheitliches Format mit ausreichenden Details und Angaben gebracht.
Neue Issues mit Ideen und Vorschlägen wurden hinzugefügt.

Wie man Version v1.1 aktiviert

Die Version ist derzeit verfügbar in dem Kanal 1.1 ea (in den Kanälen stable und rock-solid Releases werden erscheinen, sobald sie stabil sind, jedoch ea ist bereits von sich aus ausreichend stabil für den Einsatz, da sie durch die Kanäle getestet wurde. Alpha und beta). Wird aktiviert über multiwerf auf folgende Weise:

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

Fazit

Die neue Architektur der Stufenablage und die Optimierung des Build-Systems für Stapel- und Dockerfile-Builder ermöglichen verteilte und parallele Builds in werf. Diese Funktionen werden bald im selben Release v1.1 verfügbar sein und automatisch über den Auto-Update-Mechanismus bereitgestellt (für Benutzer multiwerf).

In diesem Release wurde eine Inhalts-basierte Tagging-Strategie hinzugefügt — content-based tagging, — die zur Standardstrategie wurde. Auch das Logging der Hauptbefehle wurde überarbeitet: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Der nächste wichtige Schritt wird die Einführung von verteilten Builds sein. Verteilte Builds sind seit v1.0 eine priorisierte Aufgabe geworden, da sie mehr Wert für werf bieten: vertikale Skalierung der Builder und Unterstützung für ephemeral Builders in verschiedenen CI/CD-Systemen sowie die Möglichkeit, offizielle Unterstützung für GitHub Actions bereitzustellen. Daher wurden die Fristen für die Implementierung paralleler Builds verschoben. Wir arbeiten jedoch daran, beide Möglichkeiten so schnell wie möglich zu realisieren.

Bleiben Sie dran! Und vergessen Sie nicht, uns in GitHub, zu besuchen, um ein Issue zu erstellen, ein bereits vorhandenes zu finden und zu liken, einen PR zu erstellen oder einfach der Entwicklung des Projekts zuzusehen.