ist unser Open-Source-GitOps-CLI-Dienstprogramm zum Erstellen und Bereitstellen von Anwendungen für Kubernetes. Wie versprochen, markierte den Beginn des Hinzufügens neuer Funktionen zu werf und der Überarbeitung traditioneller Ansätze. Jetzt freuen wir uns, die Version 1.1 präsentieren zu können, die einen großen Entwicklungsschritt und eine Grundlage für die Zukunft darstellt Kollektor werf. Die Version ist derzeit verfügbar in .
Grundlage des Releases ist die neue Architektur des Stage Storage und die Optimierung der Arbeit beider Collectors (für Stapel und Dockerfile). Die neue Speicherarchitektur eröffnet die Möglichkeit, verteilte Assemblys von mehreren Hosts und parallele Assemblys auf demselben Host zu implementieren.
Die Optimierung der Arbeit umfasst die Beseitigung unnötiger Berechnungen in der Phase der Berechnung der Phasensignaturen und die Umstellung der Mechanismen zur Berechnung der Dateiprüfsummen auf effizientere. Diese Optimierung reduziert die durchschnittliche Zeit für die Projekterstellung mit werf. Und Leerlauf-Builds, wenn alle Stufen im Cache vorhanden sind Bühnenspeicher, sind jetzt richtig schnell. In den meisten Fällen dauert der Neustart des Builds weniger als 1 Sekunde! Dies gilt auch für Verfahren zur Überprüfung der Arbeitsschritte von Teams. werf deploy и werf run.
Außerdem erschien in dieser Version eine Strategie zum Markieren von Bildern nach Inhalt – Inhaltsbasiertes Tagging, die jetzt standardmäßig aktiviert und die einzige empfohlene Option ist.
Werfen wir einen genaueren Blick auf die wichtigsten Neuerungen in werf v1.1 und erzählen Ihnen gleichzeitig etwas über die Pläne für die Zukunft.
Was hat sich in werf v1.1 geändert?
Neues Stufenbenennungsformat und Algorithmus zur Auswahl von Stufen aus dem Cache
Neue Regel zur Generierung von Künstlernamen. Jetzt generiert jeder Stage-Build einen eindeutigen Stage-Namen, der aus zwei Teilen besteht: einer Signatur (wie in Version 2) und einer eindeutigen temporären Kennung.
Der vollständige Bühnenbildname könnte beispielsweise so aussehen:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...oder allgemein:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Hier:
-
SIGNATUREist eine Bühnensignatur, die die Kennung des Bühneninhalts darstellt und vom Verlauf der Bearbeitungen in Git abhängt, die zu diesem Inhalt geführt haben; -
TIMESTAMP_MILLISECist eine garantiert eindeutige Bildkennung, die beim Erstellen eines neuen Bildes generiert wird.
Der Algorithmus zum Auswählen von Phasen aus dem Cache basiert auf der Überprüfung der Beziehung von Git-Commits:
- Werf berechnet die Signatur einer bestimmten Stufe.
- В Bühnenspeicher Für eine bestimmte Signatur kann es mehrere Phasen geben. Werf wählt alle Etappen aus, die der Signatur entsprechen.
- Wenn die aktuelle Stufe mit Git verknüpft ist (git-archive, benutzerdefinierte Stufe mit Git-Patches:
install,beforeSetup,setup; oder git-latest-patch), dann wählt werf nur die Phasen aus, die mit einem Commit verknüpft sind, der ein Vorfahre des aktuellen Commits ist (für den der Build aufgerufen wird). - Aus den verbleibenden geeigneten Stufen wird eine ausgewählt – die älteste nach Erstellungsdatum.
Eine Stufe für verschiedene Git-Zweige kann dieselbe Signatur haben. Aber werf verhindert, dass der Cache, der verschiedenen Zweigen zugeordnet ist, zwischen diesen Zweigen verwendet wird, selbst wenn die Signaturen übereinstimmen.
.
Neuer Algorithmus zum Erstellen und Speichern von Etappen im Bühnenspeicher
Wenn werf bei der Auswahl von Stufen aus dem Cache keine passende Stufe findet, wird der Prozess der Zusammenstellung einer neuen Stufe eingeleitet.
Beachten Sie, dass mehrere Prozesse (auf einem oder mehreren Hosts) ungefähr zur gleichen Zeit mit dem Aufbau derselben Phase beginnen können. Werf verwendet einen optimistischen Blockalgorithmus Bühnenspeicher im Moment des Speicherns des frisch gesammelten Bildes in Bühnenspeicher. Auf diese Weise wird werf blockiert, wenn der neue Bühnenaufbau fertig ist Bühnenspeicher und speichert dort nur dann ein frisch gesammeltes Bild, wenn dort kein passendes Bild mehr vorhanden ist (nach Signatur und anderen Parametern – siehe den neuen Algorithmus zur Auswahl von Stufen aus dem Cache).
Ein frisch zusammengestelltes Bild verfügt garantiert über eine eindeutige Kennung TIMESTAMP_MILLISEC (siehe neues Bühnenbenennungsformat). Für den Fall, dass Bühnenspeicher Wird ein passendes Bild gefunden, verwirft werf das frisch kompilierte Bild und verwendet das Bild aus dem Cache.
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 dann ist es dieses einzelne Image, das für alle Builds verwendet wird). Ein langsamer Build-Prozess wird niemals einen schnelleren Prozess daran hindern, die Build-Ergebnisse der aktuellen Phase zu speichern und mit dem nächsten Build fortzufahren.
.
Verbesserte Leistung des Dockerfile-Builders
Im Moment besteht die Stufenpipeline für ein aus einer Docker-Datei erstelltes Image aus einer Stufe: dockerfile. Bei der Berechnung der Signatur wird die Prüfsumme der Dateien berechnet context, die bei der Montage verwendet wird. Vor dieser Verbesserung durchlief werf alle Dateien rekursiv und erhielt eine Prüfsumme, indem der Kontext und der Modus jeder Datei summiert wurden. Ab v1.1 kann werf berechnete Prüfsummen verwenden, die in einem Git-Repository gespeichert sind.
Der Algorithmus basiert auf . Der Algorithmus berücksichtigt Datensätze in .dockerignore und durchläuft den Dateibaum nur bei Bedarf rekursiv. Somit haben wir uns vom Lesen des Dateisystems und der Abhängigkeit des Algorithmus von der Größe entkoppelt context ist nicht von Bedeutung.
Der Algorithmus überprüft auch nicht getrackte Dateien und berücksichtigt diese gegebenenfalls in der Prüfsumme.
Verbesserte Leistung beim Importieren von Dateien
Versionen von werf v1.1 verwenden einen Rsync-Server, wenn . Bisher erfolgte der Import in zwei Schritten mithilfe eines Verzeichnis-Mounts vom Hostsystem.
Die Importleistung unter macOS wird nicht mehr durch Docker-Volumes eingeschränkt und Importe werden in der gleichen Zeit wie unter Linux und Windows abgeschlossen.
Inhaltsbasiertes Tagging
Werf v1.1 unterstützt das sogenannte Tagging nach Bildinhalten - Inhaltsbasiertes Tagging. Die Tags der resultierenden Docker-Bilder hängen vom Inhalt dieser Bilder ab.
Beim Ausführen des Befehls werf publish --tags-by-stages-signature oder werf ci-env --tagging-strategy=stages-signature veröffentlichte Bilder der sogenannten Bühnensignatur Bild. Jedes Bild ist mit einer eigenen Signatur der Stufen dieses Bildes versehen, die nach den gleichen Regeln berechnet wird wie die reguläre Signatur jeder Stufe separat, aber eine allgemeine Kennung des Bildes darstellt.
Die Signatur der Bildstufen hängt ab von:
- der Inhalt dieses Bildes;
- Geschichten der Git-Änderungen, die zu diesem Inhalt geführt haben.
Ein Git-Repository verfügt immer über Dummy-Commits, die den Inhalt der Bilddateien nicht ändern. Zum Beispiel Commits mit nur Kommentaren oder Merge-Commits oder Commits, die die Dateien in Git ändern, die nicht in das Image importiert werden.
Durch die Verwendung von inhaltsbasiertem Tagging werden die Probleme unnötiger Neustarts von Anwendungs-Pods in Kubernetes aufgrund von Änderungen im Image-Namen gelöst, auch wenn sich der Inhalt des Images nicht geändert hat. Dies ist übrigens einer der Gründe, warum die Speicherung vieler Microservices einer Anwendung in einem einzigen Git-Repository verhindert wird.
Außerdem ist inhaltsbasiertes Tagging eine zuverlässigere Tagging-Methode als Tagging auf Git-Zweigen, da der Inhalt der resultierenden Bilder nicht von der Reihenfolge abhängt, in der Pipelines im CI-System zum Zusammenstellen mehrerer Commits desselben Zweigs ausgeführt werden.
Es ist wichtig,: von jetzt an Stufen-Signatur - Das die einzige empfohlene Tagging-Strategie. Es wird standardmäßig im Befehl verwendet werf ci-env (es sei denn, Sie geben explizit ein anderes Tagging-Schema an).
. Auch diesem Thema wird eine eigene Publikation gewidmet sein. AKTUALISIERT (3. April): Artikel mit Details .
Protokollierungsstufen
Der Benutzer hat nun die Möglichkeit, die Ausgabe zu steuern, die Protokollierungsstufe festzulegen und mit Debugging-Informationen zu arbeiten. Optionen hinzugefügt --log-quiet, --log-verbose, --log-debug.
Standardmäßig enthält die Ausgabe die Mindestinformationen:
Bei Verwendung einer ausführlichen Ausgabe (--log-verbose) können Sie sehen, wie werf funktioniert:
Detaillierte Ausgabe (--log-debug) enthält neben werf-Debugging-Informationen auch Protokolle der verwendeten Bibliotheken. Sie können beispielsweise sehen, wie die Interaktion mit der Docker-Registrierung erfolgt, und auch die Orte aufzeichnen, an denen viel Zeit verbracht wird:
Weitere Pläne
Achtung! Die nachfolgend beschriebenen Optionen sind markiert v1.1 werden in dieser Version verfügbar sein, viele davon in naher Zukunft. Updates erfolgen über automatische Updates . Diese Funktionen wirken sich nicht auf den stabilen Teil der v1.1-Funktionen aus; ihr Erscheinen erfordert keinen manuellen Benutzereingriff in bestehende Konfigurationen.
Volle Unterstützung für verschiedene Docker Registry-Implementierungen (NEU)
- Version: v1.1
- Termine: März
Das Ziel besteht darin, dass der Benutzer bei der Verwendung von werf eine benutzerdefinierte Implementierung ohne Einschränkungen verwenden kann.
Derzeit haben wir die folgenden Lösungen identifiziert, für die wir vollen Support garantieren werden:
- Standard (Bibliothek/Registrierung)*,
- AWS ECR
- Azurblau*,
- Docker-Hub
- GCR*,
- GitHub-Pakete
- GitLab-Registrierung*,
- Hafen*,
- Kai.
Lösungen, die derzeit vollständig von werf unterstützt werden, sind mit einem Sternchen gekennzeichnet. Für andere gibt es Unterstützung, allerdings mit Einschränkungen.
Es lassen sich zwei Hauptprobleme identifizieren:
- Einige Lösungen unterstützen das Entfernen von Tags mithilfe der Docker-Registrierungs-API nicht, sodass Benutzer die automatische Bereinigung von werf nicht verwenden können. Dies gilt für AWS ECR-, Docker Hub- und GitHub-Pakete.
- Einige Lösungen unterstützen sogenannte verschachtelte Repositories (Docker Hub, GitHub Packages und Quay) nicht oder tun dies nicht, sondern der Benutzer muss sie manuell über die Benutzeroberfläche oder API (AWS ECR) erstellen.
Wir werden diese und andere Probleme mithilfe der nativen APIs der Lösungen lösen. Zu dieser Aufgabe gehört auch die Abdeckung des gesamten Zyklus des Werfbetriebes mit Tests für jeden einzelnen davon.
Verteilter Image-Build ( ↑)
- Version: v1.2 v1.1 (die Priorität für die Implementierung dieser Funktion wurde erhöht)
- Termine: März-April März
Derzeit können werf v1.0 und v1.1 nur auf einem dedizierten Host für Vorgänge zum Erstellen und Veröffentlichen von Bildern und zum Bereitstellen der Anwendung auf Kubernetes verwendet werden.
Um die Möglichkeiten der verteilten Arbeit von werf zu eröffnen, muss werf die Fähigkeit zur Verwendung implementieren, wenn die Erstellung und Bereitstellung von Anwendungen in Kubernetes auf mehreren beliebigen Hosts gestartet wird und diese Hosts ihren Status zwischen den Builds nicht speichern (temporäre Läufer). die Docker Registry als Stage Store.
Zuvor, als das werf-Projekt noch dapp hieß, gab es eine solche Möglichkeit. Allerdings sind wir auf eine Reihe von Problemen gestoßen, die bei der Implementierung dieser Funktionalität in werf berücksichtigt werden müssen.
Beachten. Für diese Funktion ist es nicht erforderlich, dass der Collector in Kubernetes-Pods arbeitet, weil Dazu müssen Sie die Abhängigkeit vom lokalen Docker-Server beseitigen (im Kubernetes-Pod gibt es keinen Zugriff auf den lokalen Docker-Server, da der Prozess selbst in einem Container ausgeführt wird und werf dies nicht unterstützt und auch nicht unterstützen wird). Arbeiten mit dem Docker-Server über das Netzwerk). Die Unterstützung für die Ausführung von Kubernetes wird separat implementiert.
Offizielle Unterstützung für GitHub Actions (NEU)
- Version: v1.1
- Termine: März
Enthält werf-Dokumentation (Abschnitte Referenz и Guide) sowie die offizielle GitHub-Aktion für die Arbeit mit werf.
Darüber hinaus wird es werf ermöglichen, an kurzlebigen Läufern zu arbeiten.
Der Mechanismus der Benutzerinteraktion mit dem CI-System basiert auf der Platzierung von Labels auf Pull-Requests, um bestimmte Aktionen zum Erstellen/Rollout der Anwendung einzuleiten.
Lokale Entwicklung und Bereitstellung von Anwendungen mit werf (↓)
- Version: v1.1
- Termine: Januar-Februar April
Das Hauptziel besteht darin, eine einzige einheitliche Konfiguration für die Bereitstellung von Anwendungen sowohl lokal als auch in der Produktion zu erreichen, ohne komplexe Aktionen und sofort einsatzbereit.
werf muss außerdem über einen Betriebsmodus verfügen, in dem es bequem ist, den Anwendungscode zu bearbeiten und sofort Feedback von der laufenden Anwendung zum Debuggen zu erhalten.
Neuer Reinigungsalgorithmus (NEU)
- Version: v1.1
- Termine: April
In der aktuellen Version von werf v1.1 im Verfahren cleanup Es gibt keine Möglichkeit, Bilder für das inhaltsbasierte Tagging-Schema zu bereinigen – diese Bilder sammeln sich an.
Außerdem verwendet die aktuelle Version von werf (v1.0 und v1.1) unterschiedliche Bereinigungsrichtlinien für Bilder, die unter Tagging-Schemata veröffentlicht werden: Git Branch, Git Tag oder Git Commit.
Es wurde ein neuer Algorithmus zum Bereinigen von Bildern basierend auf der Historie der Commits in Git erfunden, der für alle Tagging-Schemata einheitlich ist:
- Behalten Sie nicht mehr als N1 Bilder, die mit den N2 neuesten Commits für jeden Git-HEAD (Zweige und Tags) verknüpft sind.
- Speichern Sie nicht mehr als N1-Stufenbilder, die mit den N2 neuesten Commits für jeden Git-HEAD (Zweige und Tags) verknüpft sind.
- Speichern Sie alle Bilder, die in beliebigen Kubernetes-Clusterressourcen verwendet werden (alle Kube-Kontexte der Konfigurationsdatei und Namespaces werden gescannt; Sie können dieses Verhalten mit speziellen Optionen einschränken).
- Speichern Sie alle Bilder, die in in Helm-Releases gespeicherten Ressourcenkonfigurationsmanifesten verwendet werden.
- Ein Image kann gelöscht werden, wenn es keinem HEAD von Git zugeordnet ist (z. B. weil der entsprechende HEAD selbst gelöscht wurde) und in keinem Manifest im Kubernetes-Cluster und in Helm-Releases verwendet wird.
Paralleler Imageaufbau (↓)
- Version: v1.1
- Termine: Januar-Februar April*
Die aktuelle Version von werf sammelt die in beschriebenen Bilder und Artefakte werf.yaml, der Reihe nach. Es ist notwendig, den Prozess der Zusammenstellung unabhängiger Phasen von Bildern und Artefakten zu parallelisieren und eine bequeme und informative Ausgabe bereitzustellen.
* Hinweis: Die Frist wurde aufgrund der erhöhten Priorität für die Implementierung verteilter Assembly verschoben, wodurch mehr horizontale Skalierungsfunktionen hinzugefügt werden, sowie die Verwendung von werf mit GitHub-Aktionen. Die parallele Montage ist der nächste Optimierungsschritt und bietet vertikale Skalierbarkeit bei der Montage eines Projekts.
Übergang zu Helm 3 (↓)
- Version: v1.2
- Termine: Februar-März Mai*
Beinhaltet die Migration auf eine neue Codebasis und eine bewährte, bequeme Möglichkeit, bestehende Installationen zu migrieren.
* Hinweis: Durch den Wechsel zu Helm 3 werden werf keine wesentlichen Funktionen hinzugefügt, da alle wichtigen Funktionen von Helm 3 (3-Wege-Merge und kein Tiller) bereits in werf implementiert sind. Darüber hinaus hat werf zusätzlich zu den angegebenen. Dieser Übergang bleibt jedoch in unseren Planungen und wird umgesetzt.
Jsonnet zur Beschreibung der Kubernetes-Konfiguration (↓)
- Version: v1.2
- Termine: Januar-Februar April-Mai
Werf unterstützt Konfigurationsbeschreibungen für Kubernetes im Jsonnet-Format. Gleichzeitig bleibt werf mit Helm kompatibel und es besteht die Möglichkeit, das Beschreibungsformat auszuwählen.
Der Grund dafür ist, dass Go-Vorlagen nach Ansicht vieler Menschen eine hohe Einstiegshürde aufweisen und auch die Verständlichkeit des Codes dieser Vorlagen leidet.
Auch die Möglichkeit der Einführung anderer Kubernetes-Konfigurationsbeschreibungssysteme (z. B. Kustomize) wird in Betracht gezogen.
Arbeiten in Kubernetes (↓)
- Version: v1.2
- Termine: April-Mai, Mai-Juni
Ziel: Stellen Sie sicher, dass Images erstellt und die Anwendung mithilfe von Runnern in Kubernetes bereitgestellt wird. Diese. Neue Images können direkt aus Kubernetes-Pods erstellt, veröffentlicht, bereinigt und bereitgestellt werden.
Um diese Funktion zu implementieren, müssen Sie zunächst in der Lage sein, verteilte Images zu erstellen (siehe Punkt oben).
Es erfordert außerdem Unterstützung für den Betriebsmodus des Builders ohne Docker-Server (d. h. Kaniko-ähnlicher Build oder Build im Userspace).
Werf wird das Erstellen auf Kubernetes nicht nur mit Dockerfile, sondern auch mit seinem Stapel-Builder mit inkrementellen Neuerstellungen und Ansible unterstützen.
Ein Schritt in Richtung offener Entwicklung
Wir lieben unsere Gemeinschaft (, ) und wir möchten, dass immer mehr Menschen dazu beitragen, werf besser zu machen, die Richtung, in die wir uns bewegen, verstehen und an der Entwicklung teilnehmen.
Vor kurzem wurde beschlossen, zu wechseln um den Arbeitsprozess unseres Teams offenzulegen. Jetzt können Sie die unmittelbaren Pläne sowie die aktuellen Arbeiten in den folgenden Bereichen einsehen:
- ;
- ;
- ;
- .
Es wurde viel Arbeit an folgenden Problemen geleistet:
- Unrelevante entfernt.
- Die vorhandenen werden auf ein einziges Format mit ausreichend Details und Details gebracht.
- Neue Ausgaben mit Ideen und Vorschlägen wurden hinzugefügt.
So aktivieren Sie Version v1.1
Die Version ist derzeit verfügbar in (in Kanälen stabil и grundsolide Veröffentlichungen werden jedoch erscheinen, wenn eine Stabilisierung eintritt ea selbst ist bereits stabil genug für den Einsatz, denn ging durch die Kanäle Alpha и Beta). Aktiviert auf die folgende Weise:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Abschluss
Die neue Stage-Storage-Architektur und Builder-Optimierungen für Stapel- und Dockerfile-Builder eröffnen die Möglichkeit, verteilte und parallele Builds in werf zu implementieren. Diese Funktionen werden bald in derselben Version 1.1 erscheinen und automatisch über den automatischen Update-Mechanismus verfügbar sein (für Benutzer). ).
In dieser Version wurde eine Tagging-Strategie basierend auf Bildinhalten hinzugefügt – Inhaltsbasiertes Tagging, was zur Standardstrategie geworden ist. Das Hauptbefehlsprotokoll wurde ebenfalls überarbeitet: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Der nächste wichtige Schritt besteht darin, verteilte Assemblys hinzuzufügen. Verteilte Builds haben seit Version 1.0 eine höhere Priorität als parallele Builds, da sie einen größeren Mehrwert für werf bieten: vertikale Skalierung von Buildern und Unterstützung für kurzlebige Builder in verschiedenen CI/CD-Systemen sowie die Möglichkeit, GitHub-Aktionen offiziell zu unterstützen . Daher wurden die Umsetzungsfristen für Parallelversammlungen verschoben. Wir arbeiten jedoch daran, beide Möglichkeiten schnellstmöglich umzusetzen.
Verfolgen Sie die Nachrichten! Und vergessen Sie nicht, uns zu besuchen um ein Problem zu erstellen, ein bestehendes zu finden und ein Plus hinzuzufügen, eine PR zu erstellen oder einfach die Entwicklung des Projekts zu beobachten.
PS
Lesen Sie auch auf unserem Blog:
- «»
- «";
- Eine Reihe von Anmerkungen zu Innovationen in werf:
- «";
- «";
- «";
- «".
Source: habr.com