— unser Open-Source GitOps CLI-Tool zum Erstellen und Bereitstellen von Anwendungen in Kubernetes. Wie versprochen, den Beginn der Einführung neuer Funktionen in werf und einer Überarbeitung gewohnter Ansätze. Jetzt freuen wir uns, die Version v1.1 vorzustellen, die einen bedeutenden Schritt in der Entwicklung darstellt und die Grundlage für die Zukunft bildet. Compiler werf. Die Version ist derzeit im .
verfügbar. Die Grundlage dieser Veröffentlichung ist eine neue Architektur für die Stages-Speicherung und eine Optimierung der Funktionsweise beider Compiler (für Stapel und Dockerfile). Die neue Architektur der Speicherung eröffnet Möglichkeiten für verteilte Builds von mehreren Hosts und parallele Builds auf einem Host.
Die Optimierung umfasst die Eliminierung unnötiger Berechnungen während der Berechnung der Stages-Signaturen und die Umstellung auf effizientere Mechanismen zur Berechnung von Prüfziffern für Dateien. Diese Optimierung verringert die durchschnittliche Build-Zeit von Projekten mit werf. Und Leerlauf-Bauten, bei denen alle Stufen im Cache vorhanden sind, stages-storage, jetzt wirklich schnell. In den meisten Fällen wird der Wiederaufbau schneller als in 1 Sekunde abgeschlossen sein! Dies gilt auch für die Überprüfungsverfahren der Phasen während der Teamarbeit. werf deploy und werf run.
In diesem Release wurde zudem eine Strategie zur inhaltsbasierten Tagging von Images eingeführt — inhaltsbasiertes Tagging, die jetzt standardmäßig aktiviert ist und die einzige empfohlene Methode darstellt.
Lassen Sie uns die wichtigsten Neuerungen in werf v1.1 im Detail betrachten und zugleich über zukünftige Pläne sprechen.
Was hat sich in werf v1.1 geändert?
Ein neues Format zur Benennung von Phasen und ein Algorithmus zur Auswahl von Phasen aus dem Cache
Neue Regel zur Generierung des Phasennamens. Jetzt wird für jede Phasenbuild ein eindeutiger Phasename generiert, der aus zwei Teilen besteht: einer Signatur (wie in v1.0) plus einer einzigartigen Zeitidentifikation.
Zum Beispiel könnte der vollständige Name des Phasenimages so aussehen:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… oder allgemein wie folgt:
werf-stages-storage/PROJEKT:SIGNATUR-ZEITSTEMPEL_MILLISEC
Hier:
-
SIGNATUR— dies ist die Signatur der Phase, die den Inhaltsidentifikator der Phase darstellt und von der Geschichte der Bearbeitungen in Git abhängt, die zu diesem Inhalt führten; -
ZEITSTEMPEL_MILLISEC— ist eine garantiert eindeutige Identifikation eines Images, die beim Erstellen eines neuen Images generiert wird.
Der Algorithmus zur Auswahl der Stufen aus dem Cache basiert auf der Überprüfung der Zugehörigkeit von Git-Commits:
- Werf berechnet die Signatur einer bestimmten Stufe.
- In stages-storage Es können mehrere Stufen mit dieser Signatur existieren. Werf wählt alle passenden Stufen mit dieser Signatur aus.
- Wenn die aktuelle Stufe mit Git verbunden ist (git-archive, benutzerdefinierte Stufe mit Git-Patches:
install,beforeSetup,setup; oder git-latest-patch), wählt werf nur die Stufen aus, die mit dem Commit verbunden sind, der der Vorgänger des aktuellen Commits ist (für den der Build aufgerufen wird). - Aus den verbleibenden passenden Stufen wird eine ausgewählt – die älteste nach Erstellungsdatum.
Eine Stufe kann für verschiedene Git-Branches die gleiche Signatur haben. Aber werf verhindert die Verwendung von Cache, das mit verschiedenen Branches verbunden ist, zwischen diesen Branches, selbst wenn die Signaturen übereinstimmen.
.
Neuer Algorithmus zur Erstellung und Speicherung von Stufen im Stufenspeicher
Wenn während der Auswahl der Stufen aus dem Cache werf keine passende Stufe findet, wird der Prozess zum Erstellen einer neuen Stufe initiiert.
Beachten Sie, dass mehrere Prozesse (auf einem oder mehreren Hosts) zur gleichen Zeit mit dem Zusammenstellen der gleichen Phase beginnen können. Werf nutzt einen Algorithmus zur optimistischen Sperrung. stages-storage zum Zeitpunkt der Speicherung des neu erstellten Images in stages-storage. Somit sperrt Werf, wenn die neue Phase bereit ist, stages-storage und speichert das neu erstellte Image nur, wenn dort noch kein passendes Image vorhanden ist. (basierend auf Signature und anderen Parametern – siehe den neuen Algorithmus zur Auswahl von Phasen aus dem Cache).
Das neu erstellte Image wird garantiert eine eindeutige Kennung haben nach ZEITSTEMPEL_MILLISEC (siehe das neue Format zur Benennung der Phasen).Falls in stages-storage ein passendes Image gefunden wird, verwirft Werf das neu erstellte Image und verwendet das Image aus dem Cache.
Anders gesagt: Der erste Prozess, der das Image fertigstellt (der schnellste), erhält das Recht, es im stages-storage zu speichern (und genau dieses einzige Image wird für alle Builds verwendet). Ein langsamerer Build-Prozess wird niemals einen schnelleren Prozess daran hindern, die Ergebnisse des aktuellen Builds zu speichern und mit dem nächsten Build fortzufahren.
.
Die Leistung des Dockerfile-Builders wurde verbessert.
Derzeit besteht die Pipeline-Stufen für das aus Dockerfile erstellte Image aus einer einzigen Stufe — dockerfile. Bei der Berechnung der Signatur wird die Prüfziffer der Dateien berücksichtigt, context, die beim Bauen verwendet werden. Vor dieser Verbesserung hat werf rekursiv alle Dateien durchlaufen und die Prüfziffer ermittelt, indem er den Kontext und die Modi jeder Datei summierte. Ab Version v1.1 kann werf die berechneten Prüfziffern nutzen, die im Git-Repository gespeichert sind.
Der Algorithmus basiert auf . Der Algorithmus berücksichtigt die Einträge in .dockerignore und durchsucht das Dateibaum nur bei Bedarf rekursiv. Dadurch haben wir uns von der Dateisystemauslesung getrennt, und die Abhängigkeit des Algorithmus von der Größe context spielt keine wesentliche Rolle.
Der Algorithmus überprüft auch untracked Dateien und berücksichtigt sie bei Bedarf in der Prüfziffer.
Die Leistung beim Importieren von Dateien wurde verbessert.
In den Versionen von werf v1.1 kommt ein rsync-Server zum Einsatz beim Zuvor wurde der Import in zwei Schritten unter Verwendung der Montageverzeichnisse aus dem Hosts-System durchgeführt.
Die Importleistung in macOS ist nicht mehr auf Docker-Volumes beschränkt, und die Importe erfolgen jetzt in der gleichen Zeit wie unter Linux und Windows.
Inhaltsbasiertes Tagging
Werf v1.1 unterstützt das sogenannte Tagging nach Inhaltsbasis des Images — inhaltsbasiertes 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 die veröffentlichten Images werden mit dem sogenannten Stadien-Signatur des Images. Jedes Image wird mit seiner eigenen Stadien-Signatur dieses Images getaggt, die nach denselben Regeln berechnet wird wie die reguläre Signatur jeder einzelnen Phase, aber als aggregierender Identifier des Images dient.
Die Stadien-Signatur eines Images hängt ab von:
- dem Inhalt dieses Images;
- der Geschichte der Änderungen in Git, die zu diesem Inhalt geführt haben.
Im Git-Repository gibt es immer leere Commits, die den Inhalt der Image-Dateien nicht ändern. Zum Beispiel Commits nur mit Kommentaren oder Merge-Commits, oder Commits, die die Dateien in Git ändern, die nicht in das Image importiert werden.
Durch die Verwendung von content-basiertem Tagging können Probleme mit überflüssigen Neustarts der Anwendungspods in Kubernetes aufgrund von Namensänderungen des Images gelöst werden, selbst wenn sich der Inhalt des Images nicht geändert hat. Dies ist übrigens einer der Gründe, die es erschweren, mehrere Mikroschnittstellen einer Anwendung in einem einzigen Git-Repository zu speichern.
Außerdem ist content-basiertes Tagging eine zuverlässigere Methode zur Kennzeichnung als das Tagging über Git-Zweige, da der Inhalt der resultierenden Images nicht von der Ausführungsreihenfolge der Pipelines im CI-System zur Erstellung mehrerer Commits desselben Zweigs abhängt.
Wichtig: ab jetzt stages-signature — ist die einzig empfohlene Tagging-Strategie. Diese wird standardmäßig im Befehl werf ci-env verwendet (es sei denn, es wird ausdrücklich ein anderes Tagging-Schema angegeben).
. Eine separate Veröffentlichung wird dieser Funktion gewidmet sein. AKTUALISIERT (3. April): Artikel mit Details .
Loglevel
Benutzer haben die Möglichkeit, die Ausgabe zu steuern, den Loglevel zu setzen und mit Debug-Informationen zu arbeiten. Optionen wurden hinzugefügt: --log-quiet, --log-verbose, --log-debug.
Standardmäßig enthält die Ausgabe minimale Informationen:
Bei Verwendung der detaillierten Ausgabe (--log-verbose) kann nachvollzogen werden, wie werf funktioniert:
Die detaillierte Ausgabe (--log-debug), neben den Debug-Informationen von werf, enthält auch die Protokolle der verwendeten Bibliotheken. Zum Beispiel kann man sehen, wie die Interaktion mit dem Docker Registry erfolgt, sowie die Stellen festhalten, an denen erhebliche Zeit verbraucht wird:
Zukünftige Plä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. Updates werden durch Auto-Updates . Diese Funktionen betreffen nicht den stabilen Teil der Funktionen v1.1, ihr Auftreten erfordert keine manuelle Eingreifung des Benutzers in bestehende Konfigurationen.
Komplette Unterstützung verschiedener Implementierungen von Docker Registry (NEU)
- Version: v1.1
- Zeitplan: März
Ziel — der Benutzer soll eine beliebige Implementierung ohne Einschränkungen bei der Verwendung von werf nutzen können.
Derzeit haben wir den folgenden Satz von Lösungen ausgewählt, für die wir vollständige Unterstützung garantieren möchten:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Mit einem Sternchen gekennzeichnet sind Lösungen, die derzeit vollständig von werf unterstützt werden. Für die anderen besteht zwar Unterstützung, jedoch mit Einschränkungen.
Es gibt zwei Hauptprobleme:
- Einige Lösungen unterstützen das Entfernen von Tags über die Docker Registry API nicht, was es den Nutzern 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 so genannte Nested Repositories (Docker Hub, GitHub Packages und Quay) nicht oder unterstützen sie nur, wenn der Nutzer diese manuell über die Benutzeroberfläche oder API (AWS ECR) erstellt.
Diese und weitere Probleme beabsichtigen wir, mit den nativen APIs der Lösungen zu beheben. Diese Aufgabe umfasst auch das Testen des vollständigen Arbeitszyklus von werf für jede Lösung.
Verteilte Bildbau (↑)
- Version: v1.2 v1.1 (die Priorität für die Umsetzung dieser Funktionalität wurde erhöht)
- Zeitrahmen: März-April März
Derzeit kann werf v1.0 und v1.1 nur auf einem dedizierten Host für Build-, Veröffentlichungs- und Anwendungs-Deployment-Betrieb in Kubernetes verwendet werden.
Um die Möglichkeiten des verteilten Arbeitens mit werf zu eröffnen, wenn der Aufbau und das Deployment von Anwendungen in Kubernetes auf mehreren beliebigen Hosts startet und diese Hosts ihren Zustand zwischen den Builds nicht speichern (temporäre Runner), benötigt werf die Implementierung der Nutzung eines Docker Registrys als Speicher für Stufen.
Früher, als das Projekt werf noch dapp hieß, gab es diese Möglichkeit. Wir sind jedoch auf verschiedene Probleme gestoßen, die bei der Umsetzung dieser Funktion in werf berücksichtigt werden müssen.
Hinweis. Diese Möglichkeit sieht nicht vor, dass der Builder innerhalb von Kubernetes-Pods arbeitet, da dafür die Abhängigkeit vom lokalen Docker-Server beseitigt werden muss (innerhalb des Kubernetes-Pods gibt es keinen Zugriff auf den lokalen Docker-Server, da der Prozess selbst in einem Container läuft und werf keine Netzwerkverbindungen zum Docker-Server unterstützt und dies auch nicht tun wird). Die Unterstützung für die Arbeit in Kubernetes wird separat implementiert.
Offizielle Unterstützung für GitHub Actions (NEU)
- Version: v1.1
- Zeitplan: März
Umfasst die werf-Dokumentation (Abschnitte Referenz und guide), sowie die offizielle GitHub Action zur Zusammenarbeit mit werf.
Darüber hinaus ermöglicht es, dass werf auf flüchtigen Runnern arbeitet.
Die Interaktion des Benutzers mit dem CI-System basiert auf der Vergabe von Labels an Pull-Requests, um bestimmte Aktionen beim Builden/Deployment der Anwendung zu initiieren.
Lokale Entwicklung und Deployment von Anwendungen mit werf (↓)
- Version: v1.1
- Zeitraum: Januar-Februar April
Das Hauptziel ist es, eine einheitliche, standardisierte Konfiguration für das Deployment von Anwendungen sowohl lokal als auch in der Produktion zu erreichen, ohne komplizierte Aktionen, direkt 'out of the box'.
Von werf wird auch ein Arbeitsmodus gefordert, in dem es bequem ist, den Anwendungscode zu bearbeiten und sofortige Rückmeldungen von der laufenden Anwendung für das Debugging zu erhalten.
Neuer Bereinigungsalgorithmus (NEU)
- Version: v1.1
- Zeitraum: April
In der aktuellen Version von werf v1.1 gibt es im Verfahren cleanup keine Bereinigung von Images für das content-basierte Tagging — diese Images werden sich ansammeln.
In der aktuellen Version von werf (v1.0 und v1.1) werden zudem unterschiedliche Bereinigungspolitiken für Images verwendet, die nach Tagging-Schemata veröffentlicht wurden: Git-Branch, Git-Tag oder Git-Commit.
Ein neuer einheitlicher Bereinigungsalgorithmus für alle Tagging-Schemata wurde basierend auf der Historie der Git-Commits entwickelt:
- Speichern Sie maximal N1 Images, die mit den letzten N2 Commits für jedes git HEAD (Branches und Tags) verbunden sind.
- Speichern Sie maximal N1 Stufen-Images, die mit den letzten N2 Commits für jedes git HEAD (Branches und Tags) verbunden sind.
- Speichern Sie alle Images, die in irgendeiner Ressource des Kubernetes-Clusters verwendet werden (alle kube-Kontexte der Konfigurationsdatei und Namespaces werden durchsucht; dieses Verhalten kann mit speziellen Optionen eingeschränkt werden).
- Speichern Sie alle Images, die in den Konfigurationsmanifesten von Ressourcen gespeichert sind, die in Helm-Releases gespeichert wurden.
- Ein Image kann gelöscht werden, wenn es mit keinem HEAD aus git verbunden ist (z.B. weil das entsprechende HEAD selbst gelöscht wurde) und in keinem Manifest im Kubernetes-Cluster und in den Helm-Releases verwendet wird.
Paralleles Bauen von Images (↓)
- Version: v1.1
- Zeiträume: Januar-Februar April*
Die aktuelle Version von werf baut die in werf.yaml, beschriebenen Images und Artefakte sequentiell. Es ist notwendig, den Bauprozess der unabhängigen Stufen von Images und Artefakten zu parallelisieren und einen ansprechenden sowie informativen Output zu gewährleisten.
* Hinweis: Der Zeitraum wurde aufgrund der erhöhten Priorität der Implementierung von verteilten Builds verschoben, die mehr Möglichkeiten für horizontale Skalierung sowie die Verwendung von werf mit GitHub Actions bieten. Paralleles Bauen ist der nächste Schritt der Optimierung, der vertikale Skalierbarkeit beim Bauen eines einzelnen Projekts bietet.
Übergang zu Helm 3 (↓)
- Version: v1.2
- Zeitraum: Februar - März Mai*
Umfasst den Übergang zu einer neuen Codebasis und eine erprobte, benutzerfreundliche Möglichkeit zur Migration bestehender Installationen.
* Hinweis: Der Wechsel zu Helm 3 wird keine wesentlichen neuen Möglichkeiten in werf hinzufügen, da alle Schlüsselmerkmale von Helm 3 (3-Wege-Merge und kein Tiller) bereits in werf implementiert sind. Darüber hinaus hat werf neben den genannten. Dennoch bleibt dieser Übergang in unseren Plänen und wird durchgeführt.
Jsonnet zur Beschreibung der Kubernetes-Konfiguration (↓)
- Version: v1.2
- Zeitraum: Januar - Februar April - Mai
Werf wird die Beschreibung der Konfiguration für Kubernetes im Jsonnet-Format unterstützen. Gleichzeitig bleibt werf mit Helm kompatibel und es wird die Möglichkeit geben, das Format der Beschreibung auszuwählen.
Ein Grund dafür ist, dass viele Menschen der Meinung sind, dass die Templates der Programmiersprache Go eine hohe Einstiegshürde aufweisen und die Verständlichkeit des Codes dieser Templates ebenfalls leidet.
Es wird auch die Möglichkeit in Betracht gezogen, weitere Konfigurationsbeschreibungs-Systeme für Kubernetes zu implementieren (zum Beispiel Kustomize).
Arbeiten innerhalb von Kubernetes (↓)
- Version: v1.2
- Zeitrahmen: April-Mai, Mai-Juni
Ziel: Bereitstellung von Build-Images und 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, wird zunächst die Möglichkeit einer verteilten Image-Bereitstellung benötigt. (siehe Punkt oben).
Außerdem ist die Unterstützung eines Modus erforderlich, der den Builder ohne Docker-Server betreibt (d.h. ähnlich wie Kaniko oder Build im Userspace).
Werf wird die Build-Option in Kubernetes nicht nur mit Dockerfile, sondern auch mit seinem Builder Stapel unterstützen, der inkrementelle Neu-Distributionen und Ansible umfasst.
Ein Schritt in Richtung Open Source Entwicklung
Wir schätzen unsere Community (, ) und möchten, dass immer mehr Menschen daran mitwirken, werf besser zu machen, verstehen, in welche Richtung wir gehen, und an der Entwicklung teilnehmen.
Vor kurzem wurde beschlossen, auf um den Arbeitsablauf unseres Teams zu öffnen. Aktuell können Sie die nächsten Pläne sowie die laufenden Arbeiten in den folgenden Bereichen einsehen:
- ;
- ;
- ;
- .
Es wurde viel Arbeit mit Issues geleistet:
- Nicht mehr relevante wurden entfernt.
- Vorhandene wurden in ein einheitliches Format mit ausreichenden Details und Informationen gebracht.
- Neue Issues mit Ideen und Vorschlägen wurden hinzugefügt.
Wie Sie die Version v1.1 aktivieren
Die Version ist derzeit verfügbar in (in den Kanälen "stable" und rock-solid die Releases werden mit der Stabilisierung erscheinen, jedoch "ea" ist sie bereits stabil genug für den Einsatz, da sie durch die Kanäle gegangen ist Alpha-Zustand und Beta). Aktivierung auf folgende Weise:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Fazit
Die neue Architektur des Staging-Speichers und die Optimierung des Builders für Stapel und Dockerfile-Builder eröffnen Möglichkeiten für verteilte und parallele Builds in werf. Diese Möglichkeiten werden bald in demselben Release v1.1 verfügbar sein und automatisch über das Auto-Update-System zugänglich gemacht werden (für Benutzer von ).
In diesem Release wurde eine Tagging-Strategie basierend auf dem Inhalt der Images hinzugefügt — inhaltsbasiertes Tagging, — die zur Standardstrategie geworden ist. Auch das Log der Hauptbefehle wurde überarbeitet: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Der nächste wesentliche Schritt wird die Einführung verteilter Builds sein. Seit Version 1.0 haben sich verteilte Builds zu einer priorisierten Aufgabe entwickelt, die mehr Wert für werf bietet: vertikale Skalierung von Builds und Unterstützung für flüchtige Builds in verschiedenen CI/CD-Systemen, sowie die Möglichkeit, offizielle Unterstützung für GitHub Actions zu implementieren. Daher wurden die Zeitpläne für die Umsetzung paralleler Builds verschoben. Wir arbeiten jedoch daran, beide Funktionalitäten so schnell wie möglich bereitzustellen.
Bleiben Sie auf dem Laufenden! Vergessen Sie nicht, auch bei uns vorbeizuschauen , um ein Issue zu erstellen, ein bereits vorhandenes zu finden und einen Pluspunkt zu setzen, einen PR zu erstellen oder einfach den Fortschritt des Projekts zu beobachten.
P.S.
Lesen Sie auch in unserem Blog:
- «»
- «»;
- Notizen zu den Neuerungen in werf:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
