Der Artikel widmet sich der Entwicklung von Helm-Diagrammen für Kubernetes unter Verwendung vorgefertigter Lösungen aus Diagramm-Repositorys. Bei diesem Ansatz wendet der Benutzer Community-Rezepte oder seine eigenen an, um eine zeitnahe Aktualisierung der Standardkomponenten aller seiner Projekte und die Bequemlichkeit der Wartung von Lösungen im Allgemeinen sicherzustellen.
Eine solche praktische Funktion ist jetzt in unser werf GitOps-Dienstprogramm integriert, das den gesamten Prozess des Betriebs der Infrastruktur für Anwendungen vereinfachen soll, die zusammengestellt und in Kubernetes eingeführt wurden.
Eingebauter Helm
Vielleicht hängt der Haupterfolg von Helm - dem "Paketmanager für Kubernetes" - weniger mit seiner Funktionalität als vielmehr mit dem offiziellen
Chart-Repository und der Unterstützung für Repositorys im Allgemeinen zusammen. Rezepte und Diagrammeinstellungen werden von einer riesigen Community begleitet. Spezialisten unterstützen aktuelle Lösungen, die von Endbenutzern benötigt werden. Jedes Diagramm des offiziellen Repositorys ist standardisiert und gut dokumentiert.
In trivialen Fällen muss der Benutzer nicht einmal ein Diagramm erstellen, um die Anwendung auszurollen: Er findet nur eine vorgefertigte Lösung, liest die Dokumentation, bereitet die Einstellungen vor und verwendet das offizielle Diagramm.
Seit langem nutzen wir Helm inside werf aktiv, um die Anwendungsinfrastruktur auszurollen, und jetzt gehen wir weiter. Ab Version
v1.0.4-alpha.10 wurden
werf Befehle zum Arbeiten mit Abhängigkeiten und Diagramm-Repositorys hinzugefügt, um den Helm-Client vollständig zu verlassen.
Die Hauptbefehle dafür:
werf helm repo
add Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in local directory init Init default chart repositories configuration list List chart repositories remove Remove a chart repository search Search for a keyword in charts update Update information of available charts locally from chart repositories
werf helm dependency
build Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
Außerdem wurde dem
werf helm deploy-chart Unterstützung für
Diagrammreferenzen hinzugefügt.
Und so sieht all diese Magie in Aktion aus - genauer gesagt, hier zeigen wir einen Vergleich des Rollouts desselben Diagramms in werf (links) und in Helm (rechts):
Mehr Übung
Zurück zum Komfort der Verwendung vorgefertigter Lösungen für die Einführung ganzer Anwendungen - ein
gängiges Beispiel für WordPress . Das Rollout seines Helm-Diagramms mit werf im Kubernetes-Cluster könnte folgendermaßen aussehen:
$ cat << EOF > values.yaml wordpressBlogName: flant wordpressUsername: admin wordpressPassword: password mariadb: mariadbRootPassword: password EOF $ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
→
Demonstration im Asciicinema .
Da Repositorys
viele Lösungen enthalten, können Sie daraus eigene Anwendungen als Cubes erstellen, wobei die Cubes die verschiedenen Helm-Diagramme sind, von denen das gesamte System abhängt. Höchstwahrscheinlich müssen Sie die Komponenten nur entsprechend Ihren Anforderungen konfigurieren.
Beispielsweise erfordert eine Webanwendung eine Warteschlange, einen Cache und einen Datenspeicher. Wie stellen wir diese Komponenten über werf bereit?
Um zu beginnen, beschleunigen wir die Suche nach allem, was Sie über die CLI benötigen:
$ werf helm repo search queue NAME CHART VERSION APP VERSION DESCRIPTION stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A... stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
In Analogie finden wir die verbleibenden Komponenten für alle registrierten Diagramm-Repositorys (die Liste der verwendeten Repositorys kann durch Ausführen des
werf helm repo list ).
Nachdem alles gefunden wurde, müssen sie nur noch zum Diagramm hinzugefügt werden. Es gibt verschiedene Möglichkeiten, dies zu tun:
werf helm dependency build|list|update dem Diagrammverzeichnis Komponentendiagramme hinzu oder erstellen Sie eine Datei "
werf helm dependency build|list|update beschreiben Sie die Abhängigkeiten und interagieren Sie dann mit ihnen, indem Sie spezielle
werf helm dependency build|list|update .
Abbildung des zweiten Weges:
$ cat << EOF > .helm/requirements.yaml dependencies: - name: mysql version: 0.3.4 repository: "@stable" - name: redis version: 1.1.11 repository: "@stable" - name: rabbitmq version: 0.6.16 repository: "@stable" EOF $ werf helm dependency build $ werf deploy --env test
→
Demonstration im Asciicinema .
Während des Rollout-Prozesses erstellt werf
alle Abhängigkeiten und verfolgt sie zusammen mit den restlichen Ressourcen. Es sind keine zusätzlichen Aktionen erforderlich.
Auf diese Weise sparen Sie unter Berücksichtigung des Fachwissens der erfahrenen Community erheblich Zeit bei der Entwicklung und Pflege von Diagrammen. Niemand beschränkt Sie jedoch auf die Verwendung öffentlicher Diagramme: Sie können Ihre Diagramme mit gleichem Erfolg ausrollen, deren Konfiguration unter Berücksichtigung der erforderlichen Besonderheiten vorbereitet wird.
Die Dokumentation zu Repository- und Abhängigkeitsbefehlen in werf finden Sie
hier . Möglicherweise
möchten Sie auch die Dokumentation lesen, um weitere Informationen
zur Einführung in werf und zu den
Hauptunterschieden von Helm zu erhalten .
Fazit
Das Fehlen von Funktionen, die für uns in den vorhandenen Open Source-Lösungen von entscheidender Bedeutung sind, zwingt uns, die entsprechenden Funktionen, Bindungen und Integrationen zu erstellen. Das werf-Projekt wurde erstellt und vor allem unterstützt, um die alltäglichen Aufgaben unserer DevOps-Ingenieure zu lösen.
Zum Beispiel haben wir lange gearbeitet (zweites Jahr!), Damit
unser Vorschlag zur Nachverfolgung von Ressourcen in Helm als alternativer Modus in der Hauptcodebasis des Projekts (Upstream) akzeptiert wird. Die Community akzeptierte und unterstützte die Idee als Viele brauchen diese Gelegenheit. Fortschritte in diese Richtung begannen jedoch in
Helm 3 und erst jetzt ...
Bisher wurde die Umsetzung dieser Idee in Helm von Entwicklern praktisch blockiert. In dieser Zeit haben wir jedoch die entsprechenden Funktionen zum Verfolgen von Ressourcen in einer separaten Open Source-Bibliothek -
kubedog - entwickelt und verwenden diese bereits in werf. Und nach der Aktivität auf GitHub zu urteilen, fand die Bibliothek Interesse bei anderen Kubernetes / Helm-Benutzern, was sehr erfreulich ist.
Sie können unsere Idee (und Implementierung) unterstützen, indem Sie einen Stern auf das Kubedog-Projekt auf GitHub setzen und / oder in der
Originalausgabe in Helm Daumen hoch. Vielen Dank!
PS
Lesen Sie auch in unserem Blog: