werf ist ein
Open-Source- GitOps-CLI-Dienstprogramm zum Erstellen und Bereitstellen von Anwendungen für Kubernetes. werf unterstützt das Zusammenstellen von Anwendungsimages mit Dockerfile oder einem eigenen integrierten Collector (basierend auf YAML-Syntax, mit Ansible-Unterstützung und inkrementellem Neuaufbau basierend auf Git). Helm-kompatibles Konfigurationsformat wird verwendet, um die Anwendung bereitzustellen. Der Anwendungscode, die Konfiguration der gesammelten Bilder und die Rollout-Konfiguration der Anwendung werden in einem Git-Repository gespeichert.
Die lang erwartete
stabile Version 1.0 ist die Basisversion des Dienstprogramms, das durch Funktionen vervollständigt wird
(die genaue Versionsnummer der ersten stabilen Version ist 1.0.6) . In der Basisversion unterstützt werf den gesamten Zyklus der Anwendungsbereitstellung und -wartung. Dies umfasst das Zusammenstellen von Anwendungsimages, das Bereitstellen auf Kubernetes und das Bereinigen nicht verwendeter Images.
Es ist wichtig, dass in Version 1.0 alle Vorgänge an einem Projekt (
build ,
deploy ,
cleanup ) von einem Host aus ausgeführt werden. Dies bedeutet, dass ein fester Mitarbeiter im CI-System verwendet werden muss. Gleichzeitig gibt es keine Einschränkungen hinsichtlich der Parallelität von Aufgaben: Werf löst dieses Problem vollständig. Sie können auch verschiedene Projekte auf verschiedene Mitarbeiter verteilen.
In diesem Artikel, der sich mit der Veröffentlichung befasst, werden wir uns näher mit dem befassen, was diese Version bietet und was nicht, sowie mit unseren Plänen für zukünftige Versionen. Beginnen wir jedoch mit dem Verständnis des Begriffs „GitOps“ und der Rolle von werf in den Prozessen der kontinuierlichen Integration und Anwendungsbereitstellung (CI / CD).
Warum werf ist GitOps
Was verstehen wir unter GitOps und welche Bereiche deckt werf ab?
Der Begriff „GitOps“ wurde vor etwa 2,5 Jahren von Weaveworks geprägt, und wir haben kürzlich einen Artikel seiner Autoren übersetzt, der die Essenz dieses neuen Phänomens für den Blog enthüllt. Nach unserem Verständnis ist die Hauptidee und Hauptbedeutung von GitOps, dass
Git eine „einzige Quelle der Wahrheit“ ist . Git speichert:
- Anwendungscode
- alle Abhängigkeiten;
- Informationen zum Sammeln von Containern;
- Informationen zur Bereitstellung auf Kubernetes;
- usw.
Und dann gibt es etwas, das die
Realität mit den Git-Änderungen in Einklang bringt. Dieser Ansatz kann nicht nur implementiert werden, indem ein Operator in Kubernetes installiert wird, der Git überwacht, sondern auch ein Konsolendienstprogramm verwendet, das von jedem CI-System aus aufgerufen werden kann. Aus unserer Sicht ist der Ansatz mit dem CLI-Dienstprogramm außerdem nicht mit unnötigen Einschränkungen verbunden: Wir können CI mit jedem Tool und mit einer beliebigen Anzahl von Nuancen ausführen, indem wir ein CLI-Dienstprogramm aufrufen, das die „Realität“ (dh Kubernetes) mit dem Status von Git synchronisiert .
werf bietet eine übergeordnete CLI-Oberfläche mit grundlegenden Befehlen zum
werf build-and-publish und Veröffentlichen von Abbildern, Bereitstellen von Anwendungen und Bereinigen von Abbildern:
werf build-and-publish ,
werf deploy ,
werf dismiss ,
werf cleanup . Es wird davon ausgegangen, dass diese grundlegenden Befehle in ein bestimmtes CI-System eingebettet sind und die erforderliche Synchronisation mit der Realität ermöglichen. Darüber hinaus bietet werf eine CLI-Oberfläche auf niedriger Ebene für die Verwaltung verschiedener Subsysteme - siehe die
Verwaltungsbefehle auf niedriger Ebene in der Dokumentation.
Es spielt keine Rolle, ob das eingebaute CI / die eingebaute CD nach dem Push- oder Pull-Modell funktioniert
(lesen Sie mehr darüber hier ) , da
werf in jedes Modell eingebaut werden kann . Gleichzeitig schließt werf Probleme wie die Arbeit mit separaten Low-Level-Dienstprogrammen wie
git , docker und kubernetes api-server, die der „fehlende Teil“ für die Konfiguration einer einheitlichen CI / CD-Anwendung sind.
Was ist werf 1.0 stabil
1. Montage, Veröffentlichung und Reinigung von Bildern
Wenn Ihre Anwendung das Erstellen von Docker-Images erfordert, können Sie mit werf 1.0:
- Beschreiben Sie die Regeln zum Zusammenstellen von Images (Sie können mehrere haben) in einer einzigen
werf.yaml Konfiguration. - Sammeln Sie Bilder und veröffentlichen Sie sie in der Docker-Registrierung
- Reinigen Sie die Docker-Registrierung regelmäßig für benutzerdefinierte Richtlinien.
werf unterstützt
zwei Möglichkeiten, die Assembly zu beschreiben : Verbinden von
werf.yaml vorhandenen Docker-Dateien und Anweisungen für
den Stapel-Collector . Das Bauen mit Stapel hat seine Vorteile: Eine schnellere inkrementelle Neuerstellung, wenn der Anwendungscode in Git geändert wird, Ansible-Syntax für Assemblierungen verwendet wird und andere. Weitere Informationen zu diesem Kollektor und zur Syntax finden Sie
in der Dokumentation . Ein Beispiel für seine Verwendung finden Sie im
Handbuch .
In Bezug auf Git-Commits, -Zweige und -Tags stehen verschiedene Schemata zum Taggen / Versionswechsel von gesammelten Bildern zur Verfügung.
Das Zusammenstellen von Images ist eine optionale Phase der Anwendungsbereitstellung und kann übersprungen werden, wenn keine eigenen zusammengestellten Images vorhanden sind.
2. Stage Storage auf nur einem Host
werf führt das konzept der stufenspeicherung ein. Die wichtigsten werf-Befehle verwenden den Stufenspeicher wie folgt:
- Montageergebnisse speichern - Docker-Bilder im Stage Store
- Verwenden Sie Bilder aus dem Stage Store als Cache zum Wiederherstellen und Zusammenstellen neuer Bilder.
- Verwenden Sie das Repository, um Informationen zu den gesammelten Bildern für deren weitere Verwendung abzurufen (z. B. bei der Übermittlung einer Anwendung an Kubernetes).
Bei der Bereitstellung einer einzelnen Anwendung sollte für alle Teams ein einstufiger Speicher verwendet werden (Zusammenstellung, Veröffentlichung, Image-Bereinigung, Anwendungsbereitstellung).
In Version 1.0 kann nur der lokale
--stages-storage=:local fungieren (der entsprechende Parameter für die Befehle lautet:
--stages-storage=:local ). Bei Verwendung von
:local Abschnitte auf der Festplatte gespeichert. Die Folge davon:
Werf 1.0 kann nur
auf einem Host verwendet werden, um die Bereitstellung einer
einzelnen Anwendung zu organisieren. Dieser Host muss zwischen den Befehlsstarts Daten speichern, damit werf ordnungsgemäß funktioniert.
In Version 1.0 gibt es keine Unterstützung für das Speichern von Phasen in einem externen Speicher, mit denen Sie eine verteilte Assembly organisieren könnten. Eine solche Funktion wird jedoch in zukünftigen Versionen von werf erscheinen
(siehe unten für weitere Details) .
3. Stellen Sie die Anwendung bereit und überprüfen Sie die Verfügbarkeit
Um die Anwendung einzuführen, beschreibt der Benutzer das Diagramm in einem mit Helm kompatiblen Format: eine Reihe von Kubernetes-Manifesten und Vorlagenparametern.
werf startet die Anwendung in Kubernetes und stellt sicher, dass sie gestartet wird und funktioniert, bevor der Rollout-Vorgang für die Anwendung abgeschlossen ist. Dies umfasst die Ausgabe von Komponentenprotokollen und die sofortige Reaktion auf Rollout-Fehler, wenn ein Fehler aufgetreten ist. Der Rollout-Befehl wird mit einem Code ungleich Null gelöscht. Wenn
wir also das werf-Rollout in CI / CD verwenden, erhalten
wir ein angemessenes Feedback von der Software : Die Anwendung wird heruntergeladen oder nicht, und es gibt genügend Informationen, um Probleme zu debuggen und zu beheben (ohne andere Dienstprogramme ausführen zu müssen, um Probleme wie
kubectl zu finden).
werf ist voll kompatibel mit bestehenden Helm 2 Installationen, aber werf hat mehrere Vorteile gegenüber. Als Mechanismus zum Aktualisieren von Ressourcen verwendet Kubernetes beispielsweise
Patches zum Zusammenführen in drei Richtungen. Außerdem besteht die Möglichkeit, Feedback zu erhalten, wenn die Anwendung an den Cluster übermittelt wird. Eine vollständige Liste der Unterschiede finden Sie auf
dieser Seite .
4. Die Beziehung der gesammelten Bilder zum Übermittlungsprozess der Anwendung
werf integriert die gesammelten Bilder in ein einziges System, markiert und versioniert sie und liefert die Anwendung an Kubernetes. Bilder, die werf sammelt, können in Ressourcenbeschreibungsvorlagen von Kubernetes verwendet werden.
Aufgrund dieser Funktionen können wir sagen, dass
werf eine übergeordnete Schnittstelle als Helm, Docker und andere Builder und Dienstprogramme für die separate Bereitstellung
bietet . Diese Schnittstelle ermöglicht es Ihnen, werf einfach in ein bestehendes CI / CD-System zu integrieren und nicht die Probleme zu lösen, alle verwendeten Komponenten zu kombinieren - er übernimmt diese Aufgabe.
5. Integration in vorhandene CI / CD-Systeme
In Version 1.0 ist die automatische Integration nur mit
dem GitLab CI-System verfügbar. Dazu wird der
werf ci-env bereitgestellt. Es empfängt die erforderlichen Informationen vom CI / CD-System und konfiguriert werf automatisch so, dass es in der CI-Umgebung ordnungsgemäß funktioniert.
Weitere Informationen zur Integration in ein CI / CD-System finden Sie in den Handbüchern (
Übersicht ,
GitLab CI-Besonderheiten ,
Integration in andere Systeme ).
6. Plattformübergreifende Entwicklung für Linux, Windows und macOS
werf 1.0 ist eine statisch verknüpfte Binärdatei, die unabhängig von Docker- und Helm-Versionen funktioniert. Externe Abhängigkeiten vom Hostsystem:
- Lokaler Docker-Daemon
- Git-Dienstprogramm.
werf kann auf allen Betriebssystemen und Umgebungen von GNU / Linux, Windows oder macOS ausgeführt werden. Darüber hinaus ist das Ergebnis der Assemblierung unabhängig vom verwendeten System dasselbe: Dieselbe Signatur der Cachestufen, dieselbe Füllung der Stufen, unabhängig davon, auf welchem System diese Stufe erfasst wurde. Änderungen in der Konfiguration für die Arbeit in verschiedenen Systemen sind ebenfalls nicht erforderlich.
Daher bietet werf 1.0 plattformübergreifende Tools zum Erstellen und Bereitstellen von Anwendungen für Kubernetes.
Hier ist auch zu beachten, dass werf Standard-Docker-Images für die Arbeit in einer Linux-Umgebung sammelt,
Windows-Container in Version 1.0
jedoch nicht unterstützt werden.
7. Funktionalität mit Tests abdecken
Derzeit werden 60% des werf-Codes durch Integrationstests und Unit-Tests abgedeckt.
werf wird auf allen unterstützten Betriebssystemen (Linux, Windows und macOS) mit GitHub Actions getestet, um den Start zu organisieren. Einige Details zu den Tests finden Sie auch unter
Code Climate .
8. Versionierung werf
Zum Zeitpunkt der Veröffentlichung von Version 1.0 wurden im Projekt
ungefähr 700 Veröffentlichungen vorgenommen.
werf nutzt ein erweitertes release-system mit stabilitätskanälen:
alpha ,
beta ,
ea (early access) ,
stable und
rock-solid . Dieser Beitrag fällt zeitlich mit der Veröffentlichung der ersten Version 1.0 im
Stable- Channel zusammen. Instabile Änderungen an der Version durchlaufen zunächst eine Kette von Kanälen und enden schließlich in einem sehr
soliden Zustand . Releases werden oft gemacht (manchmal mehrere pro Tag) und Änderungen werden kontinuierlich in "kleinen Portionen" geliefert.
Stabilitätskanäle und viele häufige Releases ermöglichen Ihnen ein kontinuierliches Feedback zu neuen Änderungen, die Möglichkeit, diese schnell zurückzusetzen und generell eine hohe Stabilität der Software bei gleichzeitig akzeptabler Entwicklungsgeschwindigkeit sicherzustellen.
Der wichtige Punkt ist, dass beim Wechsel zwischen den Versionen 1.0-> 1.1, 1.1-> 1.2 Änderungen an werf möglich sind, die einen manuellen Eingriff des Benutzers erfordern (dies kann ein Migrationsskript sein oder nur Anweisungen für die manuelle Ausführung, die in der Version beschrieben werden). Durch die Aktualisierung der Versionen in 1.0 (1.0.1, 1.0.2, ... 1.0.6-alpha.1, 1.0.6-beta.2 usw.) wird sichergestellt, dass solche manuellen Änderungen nicht erforderlich sind.
Weitere Informationen zum Versprechen der Abwärtskompatibilität finden Sie
hier .
Weitere Pläne
Hier sind die wichtigsten Arbeitsbereiche für zukünftige Versionen und ungefähre Bedingungen für deren Implementierung:
1. Lokale Entwicklung und Bereitstellung von Anwendungen mit werf
Das Hauptziel besteht darin, eine einzige einheitliche Konfiguration für die sofortige Bereitstellung von Anwendungen sowohl lokal als auch in der Produktion ohne komplexe Aktionen zu erstellen.
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.
Version 1.1, Januar-Februar 20202. Inhaltsbasiertes Tagging
Kennzeichnen von Bildern, wenn sie veröffentlicht werden, ausschließlich basierend auf dem Inhalt dieses Bildes. Im Gegensatz zu Modi mit Bindung an Git-Commits werden in diesem Modus unnötige Neuerstellungen vollständig beseitigt. Git-commit-id ist kein universeller Bezeichner für Arbeitsbauminhalte (obwohl es davon abhängt).
In dem Fall, dass der Anwendungscode nicht geändert wurde, aber ein neues Commit durchgeführt wurde, erstellt der aktuelle Tag-Modus für Git-Commits ein Bild mit einem neuen Namen, wenn es veröffentlicht wird. Dies führt auch zu einem Ressourcen-Rollback, wenn dieses Image in Kubernetes verwendet wird. Gleichzeitig hat sich der Inhalt des Bildes selbst nicht verändert.
Um diese Probleme zu lösen, wird werf eine neue Art der Kennzeichnung einführen, die auf Berechnungen der Prüfsummen des Anwendungsinhalts
basiert - die
inhaltsbasierte Kennzeichnung .
Version 1.1, Februar-März 20203. Der Übergang zu Helm 3
Es beinhaltet die Umstellung auf die neue
Helm 3- Codebasis und eine bewährte und bequeme Möglichkeit, vorhandene Installationen zu migrieren.
Version 1.1, Februar-März 20204. Paralleler Zusammenbau von Bildern
Derzeit sammelt werf 1.0 alle in
werf.yaml deklarierten Stufen von Bildern und Artefakten nacheinander. Erfordert die Fähigkeit, den Bühnenmontageprozess zu parallelisieren.
Version: 1.1, Januar-Februar 20205. Verteilte Assemblierung von Bildern
Im Moment kann werf 1.0 nur auf einem dedizierten Host verwendet werden
(siehe den obigen Punkt über den Stage-Speicher auf nur einem Host) .
Wenn die Assembly auf mehreren Hosts gestartet wird und diese Hosts ihren Status zwischen Assemblys (temporären Läufern) nicht beibehalten, muss werf die Möglichkeit implementieren, die Docker-Registrierung als Stage-Repository zu verwenden, um die Möglichkeiten der verteilten Assembly zu eröffnen.
Zuvor hatte das werf-Projekt, als es auch dapp hieß, 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.
Version 1.2: März-April 20206. Jsonnet zur Beschreibung der Kubernetes-Konfiguration
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-Sprachvorlagen nach Ansicht vieler Leute eine große Eingabeschwelle haben und die Codeverständlichkeit dieser Vorlagen ebenfalls darunter leidet.
Andere Optionen zur Implementierung von Kubernetes-Konfigurationsbeschreibungssystemen (wie z. B. Kustomize) werden ebenfalls in Betracht gezogen.
Version 1.1: Januar-Februar 20207. Arbeiten Sie in Kubernetes
Zweck: Sicherstellen der Zusammenstellung von Images und der Bereitstellung von Anwendungen mithilfe von Läufern in Kubernetes. Das heißt Die Montage neuer Images, deren Veröffentlichung, Reinigung und Bereitstellung kann direkt von Kubernetes-Pods erfolgen.
Um diese Funktion nutzen zu können, müssen Sie zunächst die Möglichkeit haben, Bilder verteilt zu verteilen
(siehe Abschnitt oben) .
Es erfordert auch Unterstützung für den Build-Betriebsmodus ohne den Docker-Dämon (d. H. Ein Kaniko-ähnliches Build oder ein
Build im Benutzerbereich ).
Werf wird Kubernetes Builds nicht nur mit dem Dockerfile unterstützen, sondern auch mit seinem Stapel Builder mit inkrementellen Neuerstellungen.
Version 1.2: April-Mai 20208. Andere
Es ist auch geplant:
- Ansible-Versions-Upgrade und die Möglichkeit, verschiedene Ansible-Versionen zu verwenden
- Unterstützung für angemessene Rollen;
- Unterstützung für beliebige Assemblerstufen in Stapel (derzeit unterstützt werf einen statischen Satz von Stufen:
beforeInstall , install , beforeSetup , setup ); - verbesserte
werf.yaml Syntax, Umstellung auf configVersion: 2 (unter anderem mit den beiden vorherigen Punkten verbunden), Unterstützung der OpenAPI-Spezifikation; - Git LFS-Unterstützung in Stapel zum Speichern großer Dateien in Git;
- Verbesserung der Bildbereinigungsmechanismen (unkritische Fehler in der aktuellen Version werden mit Bildern in Verbindung gebracht, die in der
werf.yaml Konfiguration im Hauptzweig des Masters nicht deklariert sind - diese Bilder werden durch regelmäßige Bereinigung gelöscht); - Richtigeres Arbeiten mit gemeinsam genutzten Kubernetes-Namespaces, wenn mehrere Anwendungen in einem Namespace bereitgestellt werden.
- Automatisches Rollback der Anwendung auf die neueste Arbeitsversion bei fehlgeschlagener Bereitstellung.
Total
Ich werde mich kurz fassen. Wir sind:
- lange ging bis zum Aufkommen der Version 1.0;
- berücksichtigte viel reale Erfahrung;
- Wir präsentieren Ihnen ein bewährtes Dienstprogramm mit stabiler Funktionalität, das durch Zehntausende von Rollouts verifiziert wurde.
Die Veröffentlichung von Version 1.0 markiert den Beginn einer neuen Entwicklungsphase von werf, in der grundlegend neue Funktionen hinzugefügt werden. Befolgen Sie die Nachrichten! Und schließen Sie sich
dem werf_ru tg-Kanal an , an dessen Leben sowohl direkte werf-Entwickler als auch unsere Ingenieure und Benutzer des Versorgungsunternehmens außerhalb der Firma Flant beteiligt sind.
PS
Lesen Sie auch in unserem Blog: