25. Okt 2022
Lesedauer 33 Min.
Erstellen, Bereitstellen und Freigeben
Cloud-DevOps mit Open-Source-Tools (Teil 9)
HashiCorp unterstützt mit Waypoint einen konsistenten DevOps-Workflow für Build, Deploy und Release von der Entwicklung bis in die Produktion.
Zu den traditionellen Aufgabenstellungen der Software-Entwicklung gehören: Codierung, Test, Build, Deploy, Release und Betrieb. Für die Entwicklung von Software existieren bereits breit akzeptierte und in der Praxis erprobte Werkzeuge und Verfahren.Im Unterschied dazu gibt es für DevOps, insbesondere im Cloud-Umfeld bestimmte Anforderungen, die es werkzeugseitig noch zu lösen gilt. HashiCorp hat diese Marktlücke erkannt und stellt mit Waypoint ein Werkzeug mit der Zielsetzung eines konsistenten Workflows für Build, Deploy und Release bereit – ohne zwangsweise die zugrundeliegende Infrastruktur im Detail kennen zu müssen. Dabei legt Waypoint besonderen Wert auf einen einheitlichen Workflow mittels einer durchgängigen Arbeitsweise. Für Build, Deploy und Release benötigt man keine unterschiedliche auf die jeweilige Plattform abgestimmten spezifische Kenntnisse. Vielmehr beschreibt der Entwickler mit einer deskriptiven Sprache die einzelnen Aufgaben des Workflows.Dabei greift HashiCorp auf die eigene Beschreibungssprache HCL (HashiCorp Configuration Language; siehe Teil 1) zurück. Seitens der Konzeption deckt Waypoint jeden Typ einer App und jede mögliche Plattform ab. Diese Flexibilität erreicht Waypoint durch Built-in-Plugins und ein erweiterbares Interface.
URL von Waypoint derzeit nur für HTTP-Services
Waypoint erzeugt URLs nach dem Deployment für jede unterstützte Plattform. Aktuell steht der URL-Service von Waypoint nur für Apps zur Verfügung, die über HTTP-Backends bereitgestellt werden. Zukünftig plant HashiCorp außer HTTP, auch andere Protokolle wie TCP zu unterstützen. Dieser URL-Service von Waypoint ermöglicht das Überprüfen der Software-Bereitstellung bevor diese endgültig für die Produktion freigegeben wird. Den Betrieb über diese URL übernimmt vollständig HashiCorp, daher gibt es einige Einschränkungen, was die Requests-per-Seconds und die Bandbreite betrifft. Ein On-Promise (eigenständiger Betrieb) lässt sich mittels des Open-Source-Code implementieren. Für Security-Gesichtspunkte greift Waypoint für HTTPS auf den jeweiligen Plattformen auf Ingress-Filter/Controller zurück.
Als Werkzeug zielt Waypoint darauf ab, die Entwickler in die Lage zu versetzen, ihre Apps von der Entwicklung in die Produktion zu überführen. Für diesen Zweck beschreiben die DevOps-Mitarbeiter in einer einzigen Datei, welche Apps auf welchen Plattformen in Produktion gehen sollen. Alle damit verbundenen Aufgaben für Build, Deploy und Release führt Waypoint auf Basis dieser Beschreibungsdatei durch. Anstatt für den Workflow verschiedene, spezielle Werkzeuge für den jeweiligen Anwendungstyp oder die gewünschte Laufzeitplattform einsetzen zu müssen – bietet Waypoint einen durchgängig konsistenten und keinen fragmentierten Workflow an.
Arbeits- und Funktionsweise im Überblick für Entwickler/DevOps
Diese Vorgehensweise von Waypoint erleichtert dem DevOps-Mitarbeiter wesentlich die Arbeitsweise, da dieser lediglich die Zielsetzung beschreiben muss. Die eigentlich komplexe Umsetzung, abgestimmt auf den konkreten Anwendungstyp und die jeweils einzusetzende Plattform, übernimmt vollständig Waypoint (Bild 1). Damit entfallen beim Entwickler und beim DevOps-Mitarbeiter alle im Umfeld des Anwendungstyps oder der Laufzeitplattform üblicherweise zu erledigenden Aufgaben. Waypoint übernimmt diese Aufgaben selbständig und entlastet damit wesentlich die Entwickler und DevOps-Mitarbeiter. So müssen beispielsweise keine Konfigurationsdateien wie Dockerfiles, YAML-Dateien oder ähnliches mehr programmiert werden.
Programmierer und DevOps-Mitarbeiterliefern mittels Quellcode und der Waypoint-Beschreibungsdatei Apps auf verschiedenen Plattformen aus(Bild 1)
Simon
Waypoint besitzt eine Befehlszeilenschnittstelle, ein sogenanntes Call Level Interface (CLI); der man Subkommandos zur Ausführung übergibt. Für die Überführung einer App von der Entwicklung in die Produktion reicht es, nur einen einzigen Befehl waypoint up auszuführen. Nach erfolgtem Deployment stehen dem DevOps-Mitarbeiter seitens Waypoint weitere Werkzeuge wie logs, exec oder der URL-Service bereit. Mit diesen Tools überprüft der DevOps-Mitarbeiter den Erfolg der Software-Bereitstellung und kann im Bedarfsfall eine Fehlersuche oder im erfolgreichen Fall eine Freigabe initiieren.
HashiCorp hat MemDB angepasst und erweitert
Die In-Memory-Datenbank MemDB bietet sehr hohe Zugriffsgeschwindigkeiten mit entsprechend hoher Verfügbarkeit. MemDB eignet sich besonders als In-Memory-Store für Go-Strukturen über die gleichnamige Go(lang)-Bibliothek memdb. HashiCorp hat MemDB um die Eigenschaften ACI (Atomicity, Consistency, Isolation) eines Datenbanksystems erweitert – Peristenz (Durability) erreicht der zusätzliche Einsatz von BoltDB. Bei BoltDB handelt es sich um eine in Go implementierte Key/Value-Datenbank, die als Datenspeicher B+-Bäume einsetzt und vollständig serialisierbare ACID-Transaktionen unterstützt. Diese Realisierung von HashiCorp findet man im Go-Package go-memdb; sie basiert auf kompakten Radix-Trees, auch Patricia-Trie (von reTrieval abgeleitet). Damit lassen sich Assoziativ-Arrays mit Strings über Schlüssel konstruieren, die Such-, Lösch- und Insert-Funktionen besitzen.
So aggregiert Waypoint Application-Logs und macht diese über das CLI oder die grafische Benutzeroberfläche einer Web-App zugänglich. Anhand dieser Logs lässt sich ein vorgenommenes Deployment der App schnell nachvollziehen. Im Umfeld der bereitgestellten App führt Waypoint über den exec-Service Kommandos aus, um beispielsweise ein Terminalfenster für eine weitere Befehlseingabe zu öffnen. Darüber lässt sich eine eventuelle Fehlersuche vornehmen. Anhand der von Waypoint generierten URL lässt sich die App schnell anschauen und auch mit anderen Entwicklern für Tests teilen. Ergänzend besitzt Waypoint eine Plugin-Architektur, um den Workflow und die eigene Funktionalität zu erweitern.
Kommando-Schnittstelle (CLI) von Waypoint bereitstellen und nutzen
Die Download-Seite von Waypoint bietet für die Betriebssysteme macOS, Windows und Linux verschiedene ZIP-Archive für die jeweils eingesetzte CPU an. Zusätzlich unterstützt HashiCorp für macOS und verschiedene Linux-Derivate die Installation über einen passenden Package-Manager. So stehen für macOS Homebrew und für Linux die Package-Manager APT (Advanced Package Tool), DNF (Dandified Yum) oder YUM (Yellowdog Updater Modified) zur Verfügung. Die letzte aktuelle Version von Waypoint besitzt die Versionsnummer 0.8.2. Eine andere Version stellt die Download-Seite über eine Auswahlliste zur Verfügung, die sich in der Vollansicht der Webseite oben mittig befindet (Bild 2).
HashiCorpmacht alle bisherigen Versionen von Nomad über die Download-Site zugänglich(Bild 2)
Simon
Die Waypoint-Software besteht im Wesentlichen aus einem Client- und einem Server-Teil, die sich beide in einer einzigen Binärdatei mit dem Namen waypoint befinden. Am einfachsten erledigt ein Package-Manager die Installation der Software und macht so direkt die Kommando-Schnittstelle (CLI) über den Befehl waypoint zugänglich. Beim Einrichten der Software von Hand kopiert man diese in ein Unterverzeichnis und legt zusätzlich einen passenden Eintrag im Pfad des Betriebssystems an. Erst danach erreicht man über den Terminalbefehl waypoint das Call-Level-Interface (CLI). Im Falle einer erfolgreichen Installation erscheint nach der Eingabe dieses Befehls in einem Terminalfenster eine Welcome to Waypoint-Nachricht.Deren Ausgabe auf dem Bildschirm enthält die Versionsnummer und zusätzliche Erläuterungen zum Befehlsaufbau mit den verfügbaren Subkommandos. Das integrierte Hilfesystem aktiviert man über die optionale Tag-Option -help. So erläutert beispielsweise der Terminalbefehl waypoint install -help die Arbeitsweise des install-Befehls mit allen verfügbaren Tag-Optionen. Der Hilfetext gibt auch ein vollständiges Waypoint-Kommando aus. Über ein GitHub-Repository stellt HashiCorp eine Reihe von Beispielen für den Einsatz von Waypoint zur Verfügung. Für jede dieser Anwendungsbeispiele findet man dort eine zentrale Projektdatei waypoint.hcl.Diese HCL-Konfigurationsdatei umfasst den notwendigen Quellcode, um ein Deployment der zugehörigen App durchzuführen. Leider sind nicht alle im examples-Repository enthaltenen Beispiele in jeder Betriebssystem-Umgebung/Plattform nutzbar. So kann man eventuelle Linux-Container für Docker nicht im Windows-Umfeld von Nomad einsetzen, da man hierzu Windows-Container (siehe Teil 8) benötigt. Der Befehl waypoint init im Projektordner prüft den Quellcode und initialisiert das Projekt.
Ausgewählte Kubernetes/K8s-Begriffe im Überblick
Beim Arbeiten mit K8s gibt es viele Begriffe, die man kennen sollte – nachfolgend eine Auswahl der für diesen Beitrag relevanten:
Einen Build der App nimmt der Befehl waypoint build vor. Alle notwendigen Subsysteme wie beispielsweise Docker müssen vorher laufen, da Waypoint diese nicht automatisch starten kann. Eventuelle Fehlermeldungen beim Arbeiten mit Waypoint liefern direkt einen Hinweis auf das benötigte Subsystem.
Waypoint im Werkzeugverbund mit Shell- und Workflow-Commands
Das Waypoint-CLI stellt eine Kommandozeilen-Schnittstelle dar, die man in eine Werkzeugkette integrieren kann. Für diesen Zweck liefert jede Ausführung eines CLI-Befehls einen Exit-Status zurück: Im erfolgreichen Fall die Zahl Null – im Fehlerfall irgendeine andere Zahl ungleich Null. Dieser einfache Sachverhalt ermöglicht die Integration des Waypoint-CLIs in Shell-Programme, die sich mehrerer Werkzeuge hintereinander bedienen können.Um einen aufgetretenen Fehler im Shell-Programm zu verarbeiten, kennen die jeweiligen Betriebssysteme verschiedene Systemvariable, die den letzten aufgetretenen Fehler für die Weiterverarbeiten zwischenspeichern. Im Falle von Linux oder macOS stellt dies die Variable $? (Bild 3) dar – die Windows-Kommandozeile kennt die Shell-Variable %ErrorLevel% und die PowerShell von Windows $LastExitCode.
Waypoint besitzteine Kommando-Shell (CLI), um direkt Befehle entgegenzunehmen und sofort auszuführen(Bild 3)
Simon
Die CLI umfasst einen umfangreichen Vorrat an Befehlen, die man schlecht in sequentieller Reihenfolge vorstellen kann. HashiCorp teilt diese gelegentlich in zwei Gruppen, Common Commands und Other Commands ein.Diese Gruppierung sagt nur wenig über die darin enthaltenen Befehle aus, sondern bezieht sich mehr auf deren Häufigkeit was den Einsatz in der Praxis betrifft.Zu den Common Command zählt HashiCorp die Befehle build, deploy, release und up. Während waypoint up alle notwendigen Schritte des Workflos beginnend mit build, deploy bis zu release in einem Aufruf durchführt, erledigen build, deploy und release nur diejenigen Tätigkeiten, die mit dem jeweils eigenen Arbeitsschritt verbunden sind. In die Gruppe Other Command nimmt HashiCorp alle anderen Kommandos auf, die nicht zu diesen häufig benutzten Befehlen gehören.Leider bietet die Aufteilung von HashiCorp keinen Überblick zum eigentlichen Funktionsumfang des Waypoint-CLIs. Um einen besseren Überblick aus dem Blickwinkel der im CLI enthaltenen Features zu erhalten, bietet sich eine Einteilung in Shell- und Workflow-Commands an. Unter den Shell-Commands versteht man alle Befehle, die keine Tätigkeit ausführt, die mit dem Workflow Build, Deploy, Release in engerem Zusammenhang steht. Dabei handelt es sich vielmehr um Befehle, die Waypoint als Werkzeug oder seine Umgebung betreffen.
Einsatz von Kubernetes am Entwicklerarbeitsplatz
Für den Einsatz von Kubernetes (K8s) in der lokalen Entwicklung stehen verschiedene Implementierungen zur Auswahl:
Ein Shell-Command von Waypoint nimmt eine Installation vor, richtet die Arbeitsumgebung von Waypoint ein, gibt Informationen dazu aus, aktualisiert oder passt eine vorhandene Arbeitsumgebung von Waypoint an aufgetretene Änderungen des Systemumfelds an. Im Unterschied dazu gehören zu den Workflow-Commands alle Befehle, die im direkten Zusammenhang mit einer Tätigkeit stehen die den Workflow, sprich Build, Deploy oder Release betreffen.
Die Features von Shell- und Workflow-Commands im Überblick
Ausgehend von der obigen Definition zählen zu den wichtigsten Shell-Commands von Waypoint die nachfolgenden Befehle. Einige Befehle besitzen weitere Subkommandos; die unteren Erläuterungen geben daher lediglich einen zusammenfassenden Überblick zum Funktionsumfang des jeweiligen Befehls:Die folgende Aufzählung verdeutlicht den Funktionsumfang der Workflow-Commands von Waypoint und bietet so einen Überblick zu ihren Features. Analog den Shell- besitzen die Workflow-Commands verschiedene Subkommandos; die nachfolgend nicht einzeln beschrieben, sondern zusammenfassend erläutert werden:HashiCorp hat sich zum Ziel gesetzt, das Examples-Repository kontinuierlich auszubauen und auf die jeweils aktuelle Waypoint-Version abzustimmen. Die URL github.com/hashicorp/waypoint-examples zeigt in erster Linie in alphabetischer Reihenfolge die Deployment-Plattformen AWS, Azure, Docker, GCP (Google Cloud Platform), Kubernetes und Nomad an. Verzweigt man in eines dieser Unterverzeichnisse solange bis in der Ansicht/Webseite eine waypoint.hcl-Datei erscheint, so befindet man sich in der zugehörigen Projektebene. Die Projektebene verdeutlicht für die zugehörige Deployment-Plattform die eingesetzte Programmiersprache und/oder die benötigte Web/System-Software.Examples-Repository erleichtert Einstieg in das Arbeiten mit Waypoint
So bedeutet eine Navigation zu waypoint-examples/docker/python/, dass man sich in einem Projekt befindet, welches auf Docker läuft und in der Programmiersprache Python realisiert ist. Die Erläuterungen der angezeigten README.md-Datei weisen auf jeweilige Besonderheiten der Realisierung des ausgewählten Projekts hin. Im angesprochenen Docker/Python-Projekt befindet sich eine URL, die auf Flask verweist – einem leichtgewichtigen Webframework für Web-Server-Gateway-Interface (WSGI)-Anwendungen, auf dem die Programmierung mit Python basiert. Wählt man als Deployment-Plattform Kubernetes aus, so umfasst das Examples-Repository viele Beispiele mit unterschiedlichen Szenarien für die Realisierung.Dabei kommen teilweise auch spezifische Techniken oder Technologien der jeweils eingesetzten Cloud-Plattform zum Einsatz. Die von HashiCorp zur Verfügung gestellte waypoint.hcl-Datei berücksichtigt eventuell derartige Besonderheiten. Zudem gibt die README.md-Datei im Bedarfsfall einen Hinweis auf den Befehl waypoint context verify, der eine korrekte Verfügbarkeit des Waypoint-CLIs und -Servers überprüft. Wichtig bei der Umsetzung eines Examples und insbesondere wertvoll für Einsteiger ist der bei jedem Repository-Beispiel enthaltene Verweis auf ein geeignetes Tutorial der Website HashiCorp Learn.In der Regel behandelt dieses Tutorial die erforderlichen Voraussetzungen für die konkrete Umsetzung eines Beispiels aus dem Examples-Repository. Es empfiehlt sich daher, das mit dem Verweis verbundene Tutorial durchzulesen und eventuell die dortigen Waypoint-spezifischen Schritte im eigenen Umfeld auszuführen. Dieser Ratschlag trägt dazu bei, dass die Voraussetzungen für den Einsatz von Waypoint im Projekt vorhanden sind. Eventuell muss man noch weitere beim jeweiligen Example angegebene Software installieren, sollte diese nicht bereits von Haus aus eingesetzt werden.Ein spezielles Beispiel, das nicht zum oben besprochenen Muster passt, enthält das Repository waypoint-examples/learn/. Dort findet man ein Beispiel für das Deployment eines Go-APIs auf Docker mit Einsatz von Waypoint Input-Variablen. Dieses andersartige Beispiel verdeutlicht ein spezielles Waypoint-Feature: Static Application Configuration. Dieses Feature unterstützt die dynamische Konfiguration von Apps verbunden mit einem automatischem Restart bei eventuellen Änderungen in deren Konfiguration.Client/Server-Architektur unterstützt hochgradig verteilte Verarbeitung
Waypoint implementiert eine Client/Server-Architektur (Bild 4) – wobei der Client-Teil dem CLI/UI entspricht und der Server-Teil als API fungiert. Soll Waypoint eine Aufgabe übernehmen, so übergibt der Entwickler oder DevOps-Mitarbeiter dem CLI einen passenden Befehl. Das CLI überführt diesen Befehl in API-Aufrufe, die es an den Waypoint-Server weiterreicht. Insofern fungiert das Waypoint-CLI als Client für das Server-API. Da das CLI nur Befehle an den Server transferiert oder von diesem das Ergebnis erhält, muss der Client auch keinerlei Zustandsinformation speichern. Die einzigen seitens des Clients benötigten Daten stellt die Verbindungsinformation zum Waypoint-Server dar.
Bei Waypointhandelt es sich um ein verteiltes System, in dessen Zentrum der Server steht; er koordiniert und überwacht alle Einzelaufgaben über Runner und Entrypoints(Bild 4)
Simon
Der Client löst Operationen wie Build, Deploy und ähnliche auf dem Server aus. Die Koordination dieser Operationen übernimmt in der Waypoint-Terminologie ein Waypoint-Runner. In den meisten Fällen fungiert das CLI, also der Client-Teil von Waypoint als Runner. Auf Bedarf startet das Kommando waypoint runner agent einen Runner manuell. Im Umfeld von Waypoint gibt es allerdings noch sogenannte Dedicated Runner für spezielle Aufgaben. Ein Dedicated Runner resultiert zwar aus einer Waypoint-Aufgabenstellung, basiert aber ursprünglich nicht direkt auf einem CLI-Kommando. Bei den Dedicated Runner unterscheidet man Remote und On-Demand Runner. Ein Remote Runner erledigt eigenständig Operationen, startet zur Skalierung über ein Plugin weitere, in der Regel kurzlebige, On-Demand Runner in einer Cloud-Umgebung.Neben dem Client- und Serverteil besitzt Waypoint noch eine Komponente, die sich Entrypoint nennt. Im Unterschied zum Client und Server, die sich zusammen im waypoint-Binary befinden – stellt der Entrypoint eine separate Binärdatei dar: waypoint-entrypoint. Anhand dieser eigenständigen Binärdatei führt Waypoint zur Erledigung der Aufgabe eine Konfiguration durch. Ergebnis der Konfiguration stellt ein ausführbarer Katalog von Unteraufgaben dar, um bestimmte Features für die App bereitzustellen. Zu diesen Unteraufgaben gehören zum Beispiel die Konfiguration/Einrichtung der App, der bereits erwähnte logs- und exec- oder der URL-Service von Waypoint oder das Monitoring/Tracking. Lediglich für Docker-Images generiert Waypoint diesen Aufgabenkatalog automatisch.
Server übernimmt Koordination mittels Warteschlange und Jobs
Für alle anderen Deployment-Umgebungen muss man eine spezielle waypoint-entrypoint-Datei vom HashiCrop-Release-Server herunterladen. Anschließend kopiert man diese Binärdatei in ein für das Betriebssystem übliches Installationsverzeichnis. Für unix-ähnliche Betriebssysteme lautet dies normalerweise /usr/local/bin. Abschließend muss die App so konfiguriert werden, dass beim Starten zuerst den Entrypoint ausgeführt und danach anwendungsspezifische Aktionen wie das Lesen der Einstellungen des Endbenutzers vorgenommen werden.Somit stellt Waypoint ein verteiltes System dar, dessen zentrale Komponente der Server immer von den anderen erreichbar ist. Alle anderen Komponenten Runner, Entrypoints und Clients benötigen keine eigenständige Erreichbarkeit über das Netz.Die Server-Komponente speichert Daten zwischen eventuell benötigten Restarts in zwei Datenbanken: MemDB und BoltDB. Die persistenten Daten liest Waypoint aus BoltDB und erzeugt eine MemDB-Datenbank für in-memory Indexing und Speicherzugriffe. Das Server-API basiert auf Protocol Buffers und gRPC: In einer großen server.proto-Datei befinden sich alle Protocol Buffer-Einträge – die Kommunikation erfolgt mittels dem hoch-performanten RPC-Framework (gRPC). Beide Technologien sowohl Protocol Buffers als gRPC sind unabhängig von einer Programmiersprache. Mittels Protocol Buffer serialisiert man strukturierte Daten in einer sprach-unabhängigen, plattform-neutralen Form. In C++, C#, Dart, Go, Java, Kotlin oder Python greift man über gRPC auf die Daten zu.Setzt man am Client (CLI, UI) einen Auftrag beispielsweise waypoint up für Waypoint ab, so erzeugt der Server ein Warteschlangen-System, das aus einzelnen Tasks besteht. Diese Tasks entstehen aus den spezifizierten Operationen wie Build, Deploy et cetera. Die Verwaltung der Warteschlange übernimmt der Waypoint-Server – er setzt einzelne Aufträge an Waypoint-Runner ab. Dabei führt der Waypoint-Server selbst nie einen Job aus. Aus dem beschriebenen Warteschlangen- und Job-System entsteht eine Zustandsmaschine. Dabei befindet sich ein Job der Warteschlange immer in genau einem der nachfolgenden Zustände: Queued, Waiting, Running, Success oder Error.Sobald ein Job einen der beiden Zustand Success oder Error erreicht – meldet der Runner diesen Zustand an den Server. Der Server entfernt einen derartigen Job aus dem Job-System und reagiert entsprechend, das heißt er leitet die benötigten Folgeschritte ab und führt sie aus. Das über Waypoint realisierte Job-System entsteht aus der Beziehung Client – Server – Runner (Bild 5). Der Client kommuniziert mit dem Server über dessen API, der Server erzeugt über das Netz einen Job durch die Aktivierung des passenden Runner in der jeweiligen Plattform. Der Runner greift auf verschiedene Plugins zurück, um die einzelnen Aufgaben zu erledigen.
Waypoint überträgt jede Aufgabe(Build, Deploy, et cetera) an einen Runner, dieser verantwortet eigenständig die Aufgabe und erledigt sie über einen oder mehrere Plugins(Bild 5)
Simon
Der Runner führt diese Aufgaben über die RunnerJobStream-API in eigener Verantwortung durch. Mittels RPC-Messages kommuniziert der Runner-Prozess mit dem Waypoint-Server-Prozess. Während dieser Kommunikation findet im Bedarfsfall das Logging statt. Dieses basiert auf einem Log-Speicher- und Streaming-System; es ist so allgemein gehalten, dass auch andere Subsysteme es zukünftig verwenden können. Derzeit nutzen sowohl Runner als auch die Anwendungen das Log/Streaming-System. Pro Job und pro Deployment gibt es spezielle, getrennte Dateien, in die Log-Buffer geschrieben werden. Anschließen werten geeignete Tools die Log-Dateien für Analysezwecke aus.
Voraussetzungen für die Installation von Waypoint-Server/Runner schaffen
Für das Einrichten eines Entwicklerarbeitsplatzes muss das Waypoint-CLI bereits installiert sein. Waypoint unterstützt als Plattformen im Cloud-Umfeld AWS, Azure, GCP, K8s und Nomad für den Betrieb von Server/Runner. Dabei verfolgt HashiCorp über Plattformen hinweg den Ansatz eines konsistenten Workflows. Am Arbeitsplatz eines Entwicklers arbeitet man vollkommen lokal, so dass Zugriffe über das Netz/Internet entfallen. Dieser lokale Workflow während Codierung und Test erleichtert dem DevOps-Mitarbeiter/Entwickler die Arbeitsweise erheblich. Im Falle von AWS, Azure und GCP benötigt man für logs und exec allerdings einen Remote-Server von Waypoint.Aktuell stehen für den Waypoint-Server die folgenden Plattformen zur Verfügung: Amazon ECS, Docker, K8s und Nomad. Wobei HashiCorp Docker nur für die lokale Entwicklung und nicht in einer Produktionsumgebung empfiehlt. Das Einrichten eines Servers/Runner auf einer lokalen Entwickler-Workstation setzt natürlich die Installation von Docker voraus. Dabei laufen Server und Runner von Waypoint in zwei separaten Docker-Containern.Kommunikation im Netz erfolgt in Nomad (siehe Teil 7) über IPv6-Adressen, daher erhält man unter macOS und Windows beim Einrichten von Waypoint in Nomad/Docker eine Fehlermeldung. Da Docker für Mac und Windows noch keine IPv6-Adressen unterstützt, muss im Falle von Nomad für die Netzkommunikation auf Consul (siehe Teil 5) zurückgegriffen werden. Für einen Betrieb von Waypoint mit K8s in der lokalen Entwicklung empfiehlt es sich, minikube zu installieren.Bei Einsatz von minikube entfällt die Aktivierung von Kubernetes über bei den Preferences der Docker-Settings! Mit minikube baut man schnell K8s-Cluster unter macOS, Linux und Windows auf. Als leichtgewichtige K8-Implementierung enthält es die kubectl-Kommandozeile, um direkt Befehle aufzuführen. Ein installiertes Helm-System führt ein Deployment von Waypoint durch, sobald das HashiCorp-Repository über helm repo add hashicorp https://helm.releases.hashicorp.com bereitsteht.Für den Betrieb in der Produktion mit K8s sollte man immer den Package-Manager Helm einsetzen. Der Befehl minikube start baut einen K8s-Cluster mit dem letzten stabilen K8s-Release auf und startet diesen in einem Docker-Container. Als Namespace wird standardmäßig default verwendet. Über die start-Befehlsoptionen --container-runtime=[containerd | cri-o] kann man ein anderes Container-Runtime festlegen.Anschließend öffnet das Kommando minikube dashboard die Web-App mit dem K8s-Dashboard im konfigurierten Browser des Betriebssystems. Dabei erscheint in der Ausgabe des vorher abgesetzten dashboard-Befehls die zugehörige URL des K8s-Dashboards. Der Befehl minikube status zeigt den Zustand/Status des lokalen K8-Clusters an; dazu gehören der Typ, Host, Kubelet, API-Server und kubeconfig. Im Unterschied dazu gibt kubectl cluster-info allgemeine Informationen zum Zustand/Status des K8s-Systems (K8s Control-Plane, CoreDNS) aus. Leider gibt nur das start-Kommando von minikube die Versionsnummer des K8s-Clusters aus.Einen Cluster für eine bestimmte K8s-Version erzeugt die Befehlsoption --kubernetes-version=x.y.z. Allerdings erlaubt K8s standardmäßig kein Downgrade – also das Einrichten eines Clusters mit niedrigerer Versionsnummer ausgehend von einem K8s-Cluster höherer Version. Daher muss vorher der aktuelle K8s-Cluster mit minikube stop beendet oder sollte ein Downgrade erforderlich sein, vorher der bisherige K8s-Cluster mittels minikube delete gelöscht werden.Server/Runner von Waypoint installieren, einrichten und starten
Der Waypoint-Server für K8s in Docker, AWS EKS (Elastic Kubernetes Service) oder GCP GKE (Google Kubernetes Engine) wird als Load-Balancer betrieben. Daher muss man für eine erfolgreiche Inbetriebnahme des Waypoint-Servers minikube tunnel ausführen. Dieser Befehl startet den Tunnel-Service, der eine Netzwerkroute für Load-Balancer-Services erzeugt und deren CIDR/Ingress auf die vorhandene ClusterIP setzt.Anschließend führt der Befehl waypoint [server] install eine Installation des Waypoint-Servers/Runner durch und startet ihn. Dem Befehl übergibt man verschiedene weitere Parameter; das nachfolgende Beispiel richtet einen lokalen Server auf K8s in Docker über minikube ein: waypoint install -platform=kubernetes -k8s-advertise-internal -k8s-context minikube -accept-tos. Es folgen eine ganze Reihe von Ausgaben während der Ausführung der einzelnen Installationsschritte.Wichtig ist, sich den ausgegebenen CLI-Context-Namen im Beispiel install-1656750697, die Advertise Address: waypoint:9701 und die Web UI Address: https://127.0.0.1:9702 zu notieren. Das Einrichten eines Waypoint-Servers erfolgt zusammen mit einem Deployment eines On-Demand-Runners für Docker. Der Befehl kubectl get svc zeigt den laufenden Waypoint-Server als Load-Balancer mit seiner Cluster-IP und der real existierende externen IP-Adresse an.Im K8s-Dashboard erscheinen unter Deployments der gestartete Waypoint-Runner; Services listet Waypoint als LoadBalancer und K8s als Cluster auf. Den als Web-App ausgelieferten Waypoint-Dashboard startet der Befehl waypoint ui im Standard-Browser. Alternativ öffnet man einen Webbrowser und gibt die zugehörige URL https://127.0.0.1:9702 der Web-App ein. Die Installation eines Waypoint-Servers/Runners nimmt neben einer Einrichtung des Servers also auch eine Konfiguration des bereits installierten CLI/UI vor. Danach greifen CLI und UI automatisch direkt auf diesen neu eingerichteten Server zu.Die Installation des Servers verbunden mit dieser Konfiguration des CLI/UI stellt eine der Hauptaufgaben des Waypoint-Administrators dar. Nach einer Installation des Servers steht dieser für alle Mitarbeiter eines Projekts zur Verfügung. Um sich gegenüber Waypoint zu authentifizieren, benötigt man ein Token, das der Befehl waypoint user token erzeugt. Für spätere Anmeldungen über die Web-App speichert man sich das generierte Token ab. Nach erfolgreicher Anmeldung in der Web-App erscheint die Projekt-Seite von Waypoint (Bild 6).
Die Web-Applegt neue Projekte an oder macht die Waypoint-Instanz anderen Benutzern über die durch Invite in der Toolbar erhaltene URL zugänglich(Bild 6)
Simon
In der Praxis existieren für Entwicklung, Test und Produktion unterschiedliche Server-Umgebungen mit jeweils einer eigenen Installation. Damit nicht jeder dieser Waypoint-Server für die Zugriffe über das CLI/UI eine separate Hardware erforderlich macht, hat HashiCorp das Konzept des Contexts eingeführt. Ein Context dient zur Ablage einer Server-Konfiguration; damit schaltet man ein CLI oder ein UI auf den gewünschten Waypoint-Server um.Durch diesen Context entfallen neben einer zusätzlichen Hardware auch Installation und Administration eigenständiger CLIs pro benötigtem Server-Zugriff. Jetzt lässt sich ein einziges Waypoint-CLI/UI für die verschiedene Installationen der Waypoint-Server/Runner (für Entwicklung, Test, Produktion) verwenden. Dazu greift der waypoint context use-Befehl mit diesem Context-Namen auf den Server zu.
Mit verschiedenen Waypoint-Konfigurationen arbeiten
Die Installation eines Servers über das CLI erzeugt automatisch den für Zugriffe benötigten Context. Dabei gibt die Installationsroutine den erzeugten Context-Namen aus und speichert ihn in einer gleichnamigen HCL-Datei. Zusätzlich kennt Waypoint die Umgebungsvariable WAYPOINT_CONTEXT für die Ablage eines Context-Namens. Alle vorhandenen Context-Namen gibt der Befehl waypoint context list in einer Liste aus. Bei dem in der ersten Spalte mit einem Stern * gekennzeichneten Context-Namen handelt es sich um den sogenannten Standard-Context (default context). Diesen Context-Namen verwendet das Waypoint-CLI/UI immer dann, wenn kein anderer angegeben wird. Der Ablageort der HCL-Context-Dateien entspricht dem Konfigurationspfad (config path) – diesen zeigt Befehl waypoint context inspect zusammen mit dem Standard-Context an.Das Kommando waypoint context verify prüft, ob der Standard-Context eine erfolgreiche Verbindung zum Waypoint-Server aufbaut. Übergibt man dem Kommando als zusätzlichen Parameter einen Context-Namen, so wird dieser auf einen erfolgreichen Aufbau der Verbindung geprüft. Um den Wert für eine bestimmte Konfigurationsvariable zu setzen, greift man auf den Befehl waypoint config set <name>=<value> zurück.Dieser Befehl erlaubt neben der Konfiguration von Waypoint auch die Vorgabe von Einstellungen für die Konfiguration einer App. Dabei gelten derartige Konfigurationen für alle Anwendungen innerhalb eines Waypoint-Projekts. So lässt sich beispielsweise eine Datenbank-URL für alle Apps projektübergreifend definieren. Soll eine bestimmte Vorgabe einer Konfiguration nur für eine bestimmte App gelten, so erreicht dies der -app-Flag, dem der Anwendungsname folgt.Die Einstellung in einer Konfiguration löscht der config set <name>-Befehl, dem keine Wertangabe folgt. Zusätzlich kennt der waypoint config set-Befehl den -runner-Flag, um für einen Waypoint Runner Einstellungen für dessen Konfiguration vorzugeben. Eine derartige Runner-Einstellung gilt für jeden aktivierten Runner. Damit reicht man bestimmte Vorgaben/Parameter an eine im Projekt eingesetzte Cloud-Umgebung weiter.Soll die Gültigkeit der Einstellung einer Konfiguration auf bestimmte Arbeitsbereiche eines Runner eingeschränkt werden, so verwendet man den -scope-Flag zusammen mit weiteren Flags. Diese zusätzlichen Flags wie -project, -loabel-scope oder -workspace-scope beschränken die Vorgaben auf bestimmte Situationen. Die Werte der aktuellen Konfiguration eines Runners gibt der Befehl waypoint config get -runner aus.Einen Context legt der Befehl waypoint context create mit weiteren spezifischen Parameteroptionen an. Die an den Befehl übergebenen Parameteroptionen, auch Flags genannt, konfigurieren den Zugriff auf einen bestimmten Waypoint-Server. So gibt man über diese Flags beispielsweise das Projekt (-project), den Workspace (-workspace), die Server-Adresse (-server-addr) oder die Plattform (-server-platform) vor. Den bei einem Zugriff standardmäßig zu verwendenden Server legt man über das -set-default-Flag fest.Um Einstellungen für die Konfiguration eines On-Demand-Runner vorzunehmen, greift man auf den Befehl waypoint runner profile set zurück. Der Befehl kennt Flags wie den Plugin-Typ (-plugin-type), Runner-Namen (-name), Umgebungsvariable (-env-vars) für die vom Runner verwendeten Tools oder auch den standardmäßig zu startenden On-Demand-Runner (-default). Die Einstellungen der Konfiguration des aktuellen On-Demand-Runner gibt der Befehl waypoint runner profile list aus.Waypoint-Projekte über CLI oder Web-App GUI anlegen und verwalten
Derzeit empfiehlt es sich, ein Projekt über das CLI zu erzeugen, da das von der Web-App bereitgestellte GUI sich noch in Entwicklung befindet. Zuerst legt man in einem Terminalfenster einen Ordner für das Projekt an und generiert mit dem CLI-Befehl waypoint init eine initiale waypoint.hcl-Datei. Existiert bereits ein Entwicklungsprojekt mit zugehörigem Quellcode, so referenziert man diesen im init-Befehl über die Kommando-Option -from-project durch einen lokalen Projektordner, eine lokale Datei oder ein Remote-Verzeichnis. Anschließend bearbeitet man die generierte waypoint.hcl-Datei mit einem HCL-Editor zum Beispiel VS Code und der installierten HCL Extension for Visual Studio Code.So ändert man den erzeugten Projektnamen my-project, erweitert um zusätzliche oder ändert die vorhandenen HCL-Spezifikationen ab. Der Name eines Waypoint-Projekts muss immer innerhalb einer Server-Installation eindeutig sein. Während der Entwicklung befindet sich die waypoint.hcl-Datei auf dem lokalen Entwicklungsarbeitsplatz.Zusätzlich besteht die Möglichkeit diese für Test, Deployment oder Betrieb auf dem Waypoint-Server abzulegen. Ein Waypoint-Projekt kann aus einer oder mehrerer Apps bestehen; üblicherweise gehören alle Bestandteile zum Projekt, die dem Change- und Configuration-Management unterliegen. Auch die waypoint.hcl-Datei sollte man in die Wurzel der Versionsverwaltung übernehmen. Standardmäßig hat HashiCorp das Git-System als Change- und Configuration-Management in Waypoint integriert.Um Git zu benutzen, definiert man in der waypoint.hcl-Datei einen runner-Block, der alle Git-Operationen remote ausführt. Das enabled-Attribut true aktiviert den Remote-Runner; mit dem data_source-Block greift die URL auf die Konfigurationsdatei und mittels dem path-Attribut auf den Ordner mit dem Anwendungsprojekt im Git-System zu. Alle in der Datei waypoint.hcl vorgenommenen Änderungen muss der Befehl waypoint init -update dem Projekt bekannt geben. Vergisst man das update-Subkommando auszuführen, so bleiben alle in der waypoint.hcl-Datei durchgeführten Änderungen dem Waypoint-Server unbekannt.Einstellungen für die Zugriffe auf das Git-System definiert man über das CLI oder über die Web-App von Waypoint (Bild 7). Bei Einsatz des CLI erledigt der Befehl waypoint project apply mit den entsprechenden Kommando-Optionen diese Aufgabe. Die Option -data-source gibt das Change- und Configuration-Management-System (git), über -git-auth-type und -git-private-key-path die Einstellungen für die Authentifizierung und über -git-url die Adresse der git-Datei vor. Die für das Projekt zu verwendende waypoint.hcl-Datei referenziert die Option -waypoint-hcl zusammen mit dem korrekten Projektnamen.
Waypoint unterstütztZugriffe auf ein Projekt in einem Git-Repository(Bild 7)
Simon
Diese Option unterstützt im Bedarfsfall auch die Ablage der waypoint.hcl-Datei auf dem Waypoint-Server. In der Web-App erreicht man diese Einstellungen über Manage Settings im Register Git Repository.
HCL-Syntax von Waypoint
HashiCorp hat für alle seine DevOp-Tools eine eigene Spezifikationssprache entwickelt: die HashiCorp Configuration Language (HCL) (siehe Teil 1). Bei der Konzeption der Sprache standen bestmögliche Kompatibilität zu JSON, als auch Lesbarkeit und maschinelle Verarbeitung im Vordergrund. Für HCL steht ein Go-API zur Verfügung. Seit Version 2 unterstützt HCL Variablen und Funktionen und ist damit kompatibel zu YAML. Aus dem Blickwinkel des Software-Engineering handelt es bei HCL um eine domänen-spezifische Sprache (DSL). Grundsätzlich befasst sich eine DSL immer mit einer konkreten Aufgabe. Im Falle der Waypoint-DSL mit der Konfiguration eines Projekts – daher bezeichnet man jede DSL auch als eine anwendungsspezifische Sprache.Für die Deklaration eines Projekts sollte primär HCL in der waypoint.hcl-Datei eingesetzt werden; zusätzlich verarbeitet Waypoint auch JSON – dann lautet die Projekt-Datei waypoint.hcl.json. Die Syntax der waypoint.hcl-Datei besteht im Wesentlichen aus zwei Konstrukten: Parameter und Blöcke (Stanzas). Durch einen Parameter erhält ein Name einen bestimmten Wert: parameter_name = "wert". Unter einem Block versteht man einen Behälter (Container), der eine Konfiguration beschreibt. Ein Parameter lässt sich innerhalb von Ausdrücken (Expressions) wiederverwenden. Ein Block beginnt mit einem Schlüsselwort (zum Beispiel app), es folgt der Name des Blocks in Hochkommas (zum Beispiel "kunde").Ein Block besitzt immer einen Datentyp, vorgegeben durch die Waypoint-HCL-Syntax – in der Regel handelt es sich dabei um eine Satz/Record-Struktur. Blöcke können geschachtelt werden, beispielsweise nimmt ein app-Block einen build-Block als weiteren Container auf. Die Waypoint-DSL kennt Kommentare: Ein Einzeilen-Kommentar beginnt mit dem #-Zeichen; als Alternative zu # kann man auch // verwenden. Ein Kommentar über mehrere Zeilen beginnt mit der /*-Zeichenfolge und endet mit */. Im Unterschied zum reinen JSON-Format unterstützt Waypoint in der waypoint.hcl.json-Datei innerhalb der HCL-Blöcke (Stanzas) auch einzeilige Kommentare, die wie bei HCL mit // beginnen. Vor der Bearbeitung mit einem JSON-Tool müssen diese Kommentare aus der waypont.hcl.json-Datei wieder entfernt werden.Innerhalb eines Ausdrucks (Expression) stehen in der Waypoint-HCL alle gängigen arithmetischen und logischen Operatoren zur Verfügung. Auch Vergleichsoperatoren wie Gleich (==), Ungleich (!=), Kleiner (<), Größer (>), Kleiner gleich (<=) und Größer gleich (>=) können verwendet werden. Als Ergebnis liefert ein Ausdruck immer einen Wert mit einem bestimmten Typ zurück. Als Datentypen stehen in Waypoint-HCL Zeichenketten (string), Zahlen (number), Boolesche Werte (bool), Listen (list) und Objekte (object) zur Verfügung. Für den Zugriff auf Listen kommen Indices zum Einsatz. Auf ein Objekt greift man über deren Attribute zu.Letztendlich gibt es noch einen Nullwert (null); liegt er vor, führt Waypoint das zugehörige Statement nicht aus. Um eine Bedingung für die Ausführung zu formulieren, dient ein Vergleich: bedingung ? true_Fall : false_Fall. Ist die bedingung erfüllt, kommt der true_Fall andernfalls der false_Fall zur Ausführung. In einem Ausdruck kann man auch eine der Built-in-Funktionen einsetzen. HCL kennt viele Build-in-Funktionen zum Arbeiten mit Zahlen, Zeichenketten, zur Konvertierung, zum Erzeugen oder zur Bearbeitung von Datentypen. Für die wiederholte Ausführung eines Ausdrucks greift man auf das for-Konstrukt zurück: [for x in var.list : anweisung].Waypoint kennt Input-, Standard-Variable und externe Daten
Innerhalb der Deklaration eines Projekts unterstützt Waypoint-HCL den Einsatz von Variablen. Dabei kennt Waypoint Input-Variable, die der Benutzer selbst definiert, und dynamische Variable, die Waypoint zur Laufzeit erzeugt. Der Gebrauch einer Variablen orientiert sich an den gängigen Programmiersprachen wie Go, JavaScript oder Python. Um den Inhalt/Wert einer Variablen mit Zeichenketten zu verbinden, greift Waypoint auf die Interpolation von Strings zurück. String-Interpolation, manchmal auch Variablen-Substitution, -Interpolation oder -Erweiterung genannt, stellt ein einfaches Templating dar. Innerhalb einer in doppelten Anführungszeichen "" eingeschlossenen Zeichenkette referenziert ein Platzhalter eine Variable, die in diesem Umfeld zur Verkettung einbezogen werden soll.Eine Input-Variable muss vor der Ausführung der waypoint.hcl-Datei ihren Wert durch Initialisierung erhalten. Der DevOps-Mitarbeiter deklariert eine Input-Variable innerhalb eines eigenständigen variable-Blocks. Auf das variable-Schlüsselwort folgt der Variablen-Name, im Block selbst erhält die Variable anhand optionaler Argumente einen Typ, Standardwert und eine Beschreibung. Im Anschluss an das Argument env kann auf eine Umgebungsvariable zugegriffen werden und deren Wert angezogen wird, falls die Umgebungsvariable existiert. Soll der Wert einer Input-Variable für Ausgaben aus Sicherheitsgründen verschlüsselt sein, so erreicht man das über Argument sensitive. Die Echtheit der Ausgabe überprüft das Server-Cookie mit der sha256sum. Innerhalb anderer HCL-Blöcke erhält man Zugriff auf eine Input-Variable durch den Ausdruck var.varName.Als Datentypen für eine Variable stehen string, number und bool zur Verfügung. Anhand von Typ-Konstruktoren wie list, set, map, object oder tuple können komplexe Typen gebildet werden. Bei der Vorgabe eines Standardwerts für eine Variable muss auf dessen Konvertierbarkeit in den jeweiligen Typ geachtet werden. Neben dem variable-Block bietet Waypoint auch die Einrichtung von Input-Variablen über die Einstellungen des Projekts, automatisch zu ladenden Variablen-Definitionsdateien (erkennbar am Dateinamen *.auto.wpvars[.json]), Umgebungsvariablen des Betriebssystems, über CLI zu ladende Variablen-Definitionsdateien mit der Dateiendung .wpvar oder über den -var-Parameter-Flag beim CLI-Aufruf (Bild 8). In der oben genannten Reihenfolge nimmt Waypoint auch das Laden von Variablen vor. Soll der CLI-Aufruf eine Variablen-Definitionsdatei anziehen, so muss diese mit dem Parameter-Flag -var-file= übergeben werden.
Waypoint greift auf Variablenüber verschiedene Wege zu: Dem CLI übergibt man direkt eine Variablen-Deklaration mit dem -var-Flag oder mit dem -var-file-Flag eine Datei, die Variablen-Deklarationen enthält(Bild 8)
Simon
Die Werte dynamischer Variable, die Waypoint zur Laufzeit erzeugt, stammen von externen Datenquellen. Zum einen handelt es sich um Einstellungen seitens K8s, Vault-Secrets, Ausgaben von Terraform oder ähnliches. Zum anderen stellen Remote-Runner externe Daten bei ihrer Ausführung zur Verfügung. Remote-Runner von Waypoint kennen im Zusammenhang mit bestimmen Ausführungen/Tasks diese Variable:Grundsätzlich nimmt ein app-Block die Beschreibung der App eines Projekts und dessen Aufgaben auf. Somit befinden sich die seitens Waypoint zu erledigenden Hauptaufgaben im app-Block; von dem es ab Version 0.10 genau einen in der waypoint.hcl-Datei gibt. Ab dieser Version beschränkt sich eine waypoint.hcl-Datei auf die Konfiguration genau einer App. Damit entfällt das Konzept eines Projekts, das mehrere Apps bündelt, so dass der app-Block auf der obersten Beschreibungsebene steht. Mehrere app-Blöcke innerhalb einer waypoint.hcl-Datei wird es in der Zukunft nicht mehr geben. Jedem app-Block kann man einen Namen, auch Label genannt, vergeben. Diesen Namen reicht der app-Block an alle nachgelagerten Aufgaben weiter.
Zentrale HCL-Blöcke für die Deklaration eines Waypoint-Projekts
Innerhalb eines app-Blocks muss es immer die beiden Blöcke build und deploy geben, optional kann ein release-Block aufgenommen werden. Der build-Block beschreibt den Aufbau einer App aus den vorhandenen Quelldateien. Man sagt dieser Vorgang, die Build-Phase, erzeugt als Arbeitsergebnis einen Artifact. Der Aufbau, auch Package genannt, des Artifact bestimmt die für das Deployment vorgesehene Zielplattform. Am Ende der Build-Phase speichert Waypoint das Artifact lokal ab oder überträgt es in ein zentrales Repository. Die Ausführung des build-Blocks stößt der DevOps-Mitarbeiter mit einem der beiden CLI-Befehle waypoint up oder waypoint build an.Ein weiterer obligatorischer Block innerhalb des app-Blocks stellt der deploy-Block dar. Ein deploy-Block beschreibt wie Waypoint das über den build-Block erzeugte Artifact in die Zielumgebung einer bestimmten Bereitstellungsumgebung übertragen soll. HashiCorp hat in der Waypoint-Architektur die Bereitstellungsumgebung als Plugin konzipiert. Derzeit stehen seitens HashiCorp mit Waypoint für das Deployment AWS EC2, AWS ECS, AWS Lambda, Azure Container Instances, Docker, Google Cloud Run, K8s und Nomad zur Verfügung.Die beiden CLI-Befehle waypoint up und waypoint deploy starten den Deployment-Prozess (Bild 9). Auswahl und Handling eines Deployments erfolgt im deploy-Block durch die im use-Block vorgegebene Spezifikation. Nach erfolgreichem Deployment einer App erzeugt Waypoint für Tests eine sogenannte Deployment-URL. Dabei greift Waypoint auf die Konfiguration des Servers und auf die Konfigurationsdatei der App zurück, diese befindet sich als Eintrag in der waypoint.hcl-Datei. Ein optionaler url-Block steuert, ob Waypoint den Hostnamen der App automatisch generiert.
Für einige Arbeitsergebnisseführt Waypoint nach dem Deployment automatisch eine Freigabe/ein Release durch(Bild 9)
Simon
Grundsätzlich überträgt ein Deployment das Artifact auf die spezifizierte Plattform, die zugehörige App ist aber den Endbenutzern im Normallfall noch nicht zugänglich. Eine Freigabe der App für die Endbenutzer führt im Anschluss an das Deployment der Release-Prozess durch. Innerhalb des app-Blocks ist der release-Block als optional anzusehen – sollte er fehlen, erfolgt eine automatische Breitstellung der App auch an die Endbenutzer. Beim deploy-Befehl schaltet der optionale Parameter -release=false dieses Verhalten ab.Für die automatische Freigabe nutzt Waypoint entweder den Default-Release der Zielplattform oder betrachtet einfach jede App als freigegeben. Die eigentliche Freigabe erledigt das im release-Block durch den use-Block übergebene Plugin. Um im Fehlerfall einen Rollback zu ermöglichen, behält Waypoint eine zuvor bereitgestellt App als Backup vor. Die Anzahl der als Backup vorzuhaltenden Apps bestimmt der optionale Parameter -prune-retain, dem man eine Zahl beim CLI-Befehl an Waypoint übergibt.
Build, Deploy, Release besitzen die im Cloud-Umfeld benötigte Flexibilität
Standardmäßig greift Waypoint für das Packaging des Artifact über den use-Block auf die Built-in-Plugins Docker Build (use "docker"), Docker Pull Build (use "docker-pull") und Cloud Native Buildpacks (use "pack") zurück. Als Default-Plugin für Cloud Native Buildpacks nutzt Waypoint die Heroku Buildpacks. Zusätzlich unterstützt Waypoint über die builder-Variable im build-Block als alternative Provider zu Heroku auch Paketo und Google Cloud Platform. Damit Waypoint Build und Deploy passend durchführt, müssen beide denselben Port nutzen. Letztendlich bedeutet dies, dass die service_port-Variable im deploy-Block dem Port des Build entsprechen muss.Für die Übertragung in eine Registry kennt der build-Block eventuell benötigte Parameter anhand des jeweils angezogenen Plugins. Für private Registries unterstützt Waypoint eine explizite Authentifizierung. Dazu greift der Build-Prozess auf eine externe Datei zurück. Diese referenziert der build-Block in der waypoint.hcl-Datei im use-Block anhand der encoded_auth-Variable. Da Waypoint für Build und Deploy das API der Zielplattform nutzt, findet eine implizite Authentifizierung automatisch durch ein zuvor erfolgtes Login statt. Eine besondere Flexibilität für die Verarbeitung erreicht HashiCorp durch die Einführung des hook-Blocks.Ein Hook erweitert jede von Waypoint auszuführende Aufgabe um weitere Kommandos, die vor oder nach deren Ausführung stattfinden. Ein hook-Block kann an jeden in der waypoint.hcl-Datei vorhandenen Blöcke als zusätzliche Arbeitseinheit hinzugefügt werden. Die Flexibilität des hook-Blocks erreicht dieser über seine Parameter. Als Parameter kennt ein hook-Block command, when und on_failure. Mit dem command-Parameter legt man alle durch den hook-Block auszuführenden Befehle fest. Der when-Parameter bestimmt anhand before oder after, ob das mit command spezifizierte Kommando vor oder nach der Ausführung des zugehörigen HCL-Blocks stattfindet.Normalerweise bricht im Fehlerfall eines hook-Blocks der mit ihm verknüpfte HCL-Blocks ab. Um dieses Verhalten auszuschalten, setzt man den on_failure-Parameter auf "continue". Dies bewirkt, dass aus einem Fehler des hook-Blocks nicht ein Abbruch des zugeordneten HCL-Block folgt. Vielmehr führt Waypoint den HCL-Block und alle nachfolgenden Blöcke der waypoint.hcl-Datei weiter aus. Darüber lässt sich ein eventuelles Fehler-Handling realisieren.Svelte-Web-App in Docker-Container mittels Waypoint bereitstellen
Bei einer mit Svelte programmierten Web-App handelt es sich um eine JavaScript-Anwendung, genau genommen um eine Node.js-App. Die Erstellung, das heißt der Build, der reinen Web-App erfolgt mittels eines Paket-Managers wie npm (Node Package Manager). Dabei bedient sich npm den im Svelte-Umfeld vorhandenen Tools, sprich Compiler, Module-Bundler und weiteren. Alle für die Web-App benötigten JavaScript-Pakete und ihre Abhängigkeiten beschreibt die im Projektordner aufzufindende Datei package.json. Die Entwicklung benötigt eine Installation der in package.json angegebenen npm-Pakete, die der im Projektordner abgesetzte Befehl npm install vornimmt.In der Datei package.json befindet sich ein Bereich scripts, dessen Einträge die Befehle für einen Build oder die Ausführung der Web-App beschreibt. So bedeutet der Eintrag "build": "vite build", dass der Befehl npm run build einen Build mit dem Frontend-Tooling vite für die Web-App durchführt. Der Eintrag "preview": "vite preview" beschreibt, dass der Befehl npm run preview mittels vite die Web-App erstellt, anschließend einen Webserver für die Ausführung startet und zum Schluss die URL für die Ausführung der Web-App ausgibt. Öffnet ein Webbrowser die angegebene URL, so startet die Web-App. Um die Svelte-Web-App über einen Docker-Container bereitzustellen, benötigt man ein Dockerfile:
# Das Ausgangs-Image fuer den Build des Images setzen
FROM node:14-alpine
# Arbeitsverzeichnis im Image fuer alle im
# Dockerfile nachfolgenden Befehle festlegen
WORKDIR /usr/src/app
# package*.json-Dateien kopieren
COPY package*.json ./
# Alle npm-Pakete in das Image installieren
RUN npm install
# Alle Dateien des lokalen Ordners im Image bereitstellen
COPY ./ ./
# Ein Build der Web-App im Image durchfuehren
RUN npm run build
# Container hoert auf nachfolgenden Port
EXPOSE 5000
# Umgebungsvariable HOST setzen
ENV HOST=0.0.0.0
# Beim Start des Containers die nachfolgenden Befehle ausfuehren
CMD [ "npm", "run", "preview" ]
Das Image sollte minimal sein, was die Aufnahme der Verzeichnisse .git und node_modules in die Datei .dockerignore sicherstellt. Damit der Docker-Port im Container extern verfügbar ist, benötigt die vite.config.js-Datei beim svelte-Plugin einen server-Eintrag:
import { defineConfig } from 'vite'
import { svelte } from '@sveltejs/vite-plugin-svelte'
// https://vitejs.dev/config/
export default defineConfig({
plugins: [svelte()],
server: {
host: true,
port: 5000
}
})
Für die Durchführung eines Build der Svelte-Web-App muss Docker Desktop gestartet sein. Eine Installation der Docker-Extension über den Marketplace in VS Code richtet eine Verbindung der IDE zu Docker ein. Das Docker-Icon in der linken Toolbar zeigt alle über Docker verfügbaren Ressourcen wie Containers, Images, Registries, Networks, Volumes und weitere an. Wählt man das Dockerfile in VS Code an, so startet ein Build durch Auswahl von Build Image… in dessen Kontextmenü.Build und Bereitstellung der Svelte-App mittels Waypoint erfolgt über die Deklarationen der waypoint.hcl-Datei:
project = "svelte-projekt"
runner {
enabled = true
data_source "git" {
url = "https://github.com/.../app-svelte.git"
path = ""
}
}
app "app-svelte" {
labels = {
"service" = "app-svelte",
"env" = "dev"
}
build {
use "docker" {}
}
deploy {
use "docker" {
service_port = 5000
}
}
}
Zu Beginn macht man die darin enthaltene Definition des Projekts mittels des Befehls waypoint init dem Waypoint-Server bekannt. Nachträglich eingerichtete Remote-Runner muss man über waypoint init -update dem Server mitteilen. Zusätzlich sollte man bei den Project Settings in der Waypoint UI-Web-App prüfen, ob das korrekte GitHub-Repository bei den Git settings eingetragen ist.Für Build und Deploy kommt das Docker-Plugin zum Einsatz, das Waypoint standardmäßig remote oder auch lokal über die Option waypoint build -local ausführt. Während waypoint build das Docker-Image erzeugt, startet waypoint deploy das Image in einem Docker-Container und macht es gleichzeitig extern zugänglich. Das von Waypoint erzeugte Image findet man in der VS Code-IDE über das Docker-Icon im Bereich Images > waypoint. Nach Auswahl dieses Images startet der Befehl Run Interactive im Kontextmenü den Docker-Container. Die im Terminalfenster ausgegebene Network-URL führt die Svelte-App im Webbrowser aus (Bild 10).
Waypoint erzeugt mittels build-Kommandoein Docker-Image, das über einen Container zur Ausführung kommt(Bild 10)
Simon
Eine in Go programmierte statische HTML-Seite soll als Google Cloud Run (GCR)-Service über die Google Cloud bereitgestellt werden. Dazu benötigt man auf der Google Cloud Platform (GCP) einen Account. Nach der Anmeldung in der GCP lädt man das Google Cloud-CLI, kurz gcloud genannt, herunter und installiert dies. Der Befehl gcloud init autorisiert die gcloud-Befehlszeile für den in der GCP eingerichteten Account.
Go-App in VS Code-IDE für Google Cloud Run (GCR)-Service einrichten
Über das Google Cloud Dashboard legt man ein neues Projekt an und merkt sich dessen Project ID. Der CLI-Befehl gcloud config set project <Project ID> erklärt dieses Projekt zum Standardprojekt. Da der GCR-Service verschiedene andere GCP-Dienste benutzt, muss man diese mit einigen CLI-Befehlen aktivieren:
gcloud services enable apigateway.googleapis.com
gcloud services enable servicemanagement.googleapis.com
gcloud services enable servicecontrol.googleapis.com
gcloud services enable containerregistry.googleapis.com
Alle aktivierten Dienste zeigt der Befehl gcloud services list in einem Terminalfenster an. Anschließend installiert die Extension Cloud Code des VS Code-Marketplace die von Google implementierten IDE-Dienste für die Google Cloud-Services. Danach erscheint in der linken Toolleiste von VS Code das zugehörige Cloud Code-Icon; darüber meldet man sich im Bereich HELP AND FEEDBACK am Google Cloud Account an. Über View > Command Palette… und Auswahl von Cloud Code: New Application stehen einige App-Beispiele für die GCP bereit. Dazu wählt man in der Drop-Down-Liste Cloud Run application… und danach Go: Cloud Run aus. Als Name für das neue Projekt übernimmt man den Vorschlag hello-world und klickt auf die Schaltfläche Create New Application.Jetzt lädt VS Code die Beispiel-App für Go: Cloud Run herunter und öffnet das Projekt. Diese Go-App erzeugt mittels Templating eine statische HTML-Seite und zeigt diese über den von ihr überwachten Port mittels GCR-Service an. Die von VS Code vom neuen Projekt angezeigte Preview README.md-Datei erläutert die Arbeitsweise mit der Cloud Run-Extension in VS Code. Cloud Run enthält einen Cloud Run Emulator, um die App lokal auf dem Arbeitsplatzrechner auszuführen. Dazu genügt ein Klick in der Statusbar von VS Code auf den Eintrag Cloud Code. Anschließend wählt man in der sich öffnenden Command Palette den Eintrag Run on Cloud Emulator aus. Die angezeigte Bereiche Build environment und Build Settings lässt man unverändert und klickt auf die Run-Schaltfläche.Nach Dependency-Check startet Cloud Code über minikube ein K8s-Cluster, erzeugt den Docker-Container und führt dessen Deployment auf dem K8s-Cluster durch. Danach gibt VS Code im OUTPUT-Bereich die zugehörige URL der Go-App aus: http://localhost:8080. Ein Klick auf diese URL bringt die Go-App im Webbrowser zur Ausführung und zeigt die von ihr erzeugte statische HTML-Seite an. Um die Ausführung der Go-App zu beenden, genügt ein Klick auf das Stop-Icon in der Debug-Toolbar. Ein File-Watcher überwacht Änderungen im Projekt und initiiert eventuelle neue Builds des Artifacts und dessen erneutes Deployment. Dabei bleibt in Docker Desktop das Container-Image cloud-run-dev-internal von minikube für nachfolgende lokale Tests sinnvollerweise erhalten.Die im hello-world-Projekt von VS Code vorhandene HTML-Seite wird durch eine neue index.html-Datei ersetzt:
<!DOCTYPE html>
<html>
<head>
<title>GCR-Dienst (Go-App)</title>
</head>
<body>
<div class="container">
<section class="content">
<h1>Statische HTML-Seite mit Go-App erzeugt
<br> und mit Waypoint bereitgestellt.</h1>
<p>
Änderungen dieser HTML-Seite aktualisiert
<br> Waypoint-CLI-Befehl: waypoint up!
</p>
</section>
</div>
</body>
</html>
Der GCR-Service soll jetzt in der Google Cloud über Waypoint eingerichtet werden. Dazu definiert die waypoint.hcl-Date ein Projekt go-hello-world mit einer App app-hello:
# Projektname
project = "go-hello-world"
# Anwendung definieren
app "app-hello" {
labels = {
"service" = "app-hello",
"env" = "dev"
}
# Cloud Native Docker-Build mit Heroku Buildpacks
build {
use "pack" {
builder = "heroku/buildpacks:20"
disable_entrypoint = false
}
# Container-Registry der Google Cloud Platform verwenden
registry {
use "docker" {
image = "gcr.io/meinprojekt-356912/app-hello"
# "<my-project-id>" = meinprojekt-356912
tag = "latest"
}
}
}
# Bereitstellen der Go-App als Google Cloud Run/GCR-Dienst
deploy {
use "google-cloud-run" {
project = "meinprojekt-356912"
# Project ID: meinprojekt-356912
location = "europe-southwest1"
port = 8080
capacity {
memory = 128
cpu_count = 1
max_requests_per_container = 10
request_timeout = 300
}
auto_scaling {
max = 2
}
}
}
# Freigabe des GCR-Service erfolgt bereits mit Deploy
release {
use "google-cloud-run" {}
}
}
Dabei handelt es sich um die Go-App im Projekt hello-world, welche die neue index.html-Datei über die Go-App rendert und im Webbrowser anzeigt. Waypoint stellt diese Go-App in einem Docker-Container über eine Container-Registry in der GCP als GCR-Service bereit. Den Build erledigt Waypoint mit den Cloud Native Docker-Build von Heroku.Um auf die Container-Registry in der GCP zugreifen zu können, definiert der registry-Block diese in der waypoint.hcl-Datei. Anschließend gibt der CLI-Befehl waypoint init im Projektordner dem Waypoint-Server das neue go-hello-world-Projekt bekannt. Die Web-App UI von Waypoint zeigt danach das neue Projekt mit der zugehörigen App app-hello an. Der CLI-Befehl waypoint build startet den ersten Build des Projekts und gibt in der Web-App UI nähere Informationen über den Build Logs-Bereich aus. Nachdem Waypoint das erzeugte Docker-Image in die Container-Registry der Google Cloud gepushed hat, erscheint dieses im Bereich CI/CD.Hat Waypoint mehrere Builds für das Image der Go-App durchgeführt, so zeigt Google Cloud diese in einer Liste an. Hierzu klickt man in der Container-Registry in der Google Cloud Dashboard auf den App-Namen app-hello und die Image-Liste erscheint. Die Bereitstellung der Go-App als GCR-Service führt der CLI-Befehl waypoint deploy durch. Die Web-App UI von Waypoint gibt im Bereich Deployments zugehörige Fortschrittsmeldungen aus. Nach erfolgtem Deployment nimmt Waypoint ein automatisches Release der App vor. Die erfolgreiche Bereitstellung zeigt die Web-App UI über das Register Releases an. Klickt man in der Liste der freigegebenen Software-Versionen auf eines der angezeigten Release-Nummern, so erhält man nähere Informationen über deren Entstehen.Der ganz rechts erscheinende Bereich Timeline erläutert, aus welchem Build und welchem Deployment das ausgewählte Release von Waypoint bereitgestellt wurde. Rechts oben unterhalb der Toolleiste der Web-App UI erscheint eine URL. Ein Klick auf diese URL startet den zugehörigen GCR-Service und führt ihn aus. Im Falle der Go-App öffnet sich ein Webbrowser, der die statische HTML-Seite anzeigt (Bild 11).
Waypoint führt über die Google Cloudeine statische HTML-Seite mittels Google Cloud Run/GCR-Service aus(Bild 11)
Simon
Nimmt man Änderungen in der statischen HTML-Seite vor, stößt einen erneuten Build und Deploy an, so erzeugt Waypoint für beide eine neue Versionsnummer. Aufgrund der automatischen Freigabe der Go-App vergibt Waypoint auch eine neue Release-Nummer. Startet man jetzt die Go-App als GCR-Service, so zeigt der Webbrowser die geänderte HTML-Seite an.
Links zum Thema
<b>◼ <a href="https://www.waypointproject.io/" rel="noopener" target="_blank">Homepage von HashiCorp Waypoint</a> <br/></b>
