Erstellen einer dynamischen und skalierbaren Multi-Cloud-Bereitstellungspipeline mit GitLab

Das Lösungsteam bei Volterra entwirft und pflegt viele potenzielle Anwendungsfälle der Volterra-Plattform, um ihren potenziellen Wert zu demonstrieren. Aus diesen Anwendungsfällen werden häufig Anleitungen erstellt, mit denen Kunden erste praktische Erfahrungen mit Volterra sammeln können.

Das Lösungsteam wollte eine schnellere, automatisierte Methode, um unsere Anwendungsfälle bei Bedarf intern bereitzustellen, wobei möglichst wenig menschliches Eingreifen erforderlich ist. Unsere Bereitstellungen umfassten eine hybride Multi-Cloud-Umgebung, die sowohl IaaS-Plattformen (AWS, Azure und GCP) als auch privates Rechenzentrum (VMware vSphere und Vagrant KVM) nutzte. Wir wollten die Verwaltung dieser Umgebungen vereinfachen, indem wir ein einziges Tool bereitstellen, mit dem Bereitstellungen in jeder Umgebung erstellt werden können, ohne dass einzelne Benutzer zusätzliche Zugriffskonten erstellen oder zusätzliche Benutzeranmeldeinformationen für jede Virtualisierungsplattform oder jeden IaaS-Anbieter verwalten müssen. Dieses Tool musste außerdem skalierbar sein, um mehrere gleichzeitige Benutzer und Bereitstellungen zu unterstützen.

Zusammenfassend bestand das zentrale Problem, das wir lösen wollten, darin, ein automatisiertes Bereitstellungstool für Anwendungsfälle von Lösungen zu erstellen, das in der Lage ist, gleichzeitige Bereitstellungen in hybriden Multi-Cloud-Umgebungen mit möglichst wenig Benutzereingabe zu skalieren und zu handhaben.

Das Altered-Carbon-Projekt (AC)

Zu diesem Zweck haben wir ein Projekt namens Altered-Carbon erstellt, das oft als AC abgekürzt wird. Das AC-Projekt ist eine dynamische GitLab-Pipeline, mit der über 20 verschiedene Anwendungsfälle für Volterra-Lösungen erstellt werden können. Durch Pipeline-Automatisierung haben wir „Push-Button-Bereitstellungen“ mit einem einzigen Befehl erstellt, mit denen Benutzer mehrere Anwendungsfallcluster problemlos nach Bedarf oder über geplante tägliche Cron-Jobs bereitstellen können.

Als Referenz bezeichnen wir in AC jede Bereitstellung als STACK und jeden einzelnen Anwendungsfall als SLEEVE .

Projektentwicklung

Wir begannen mit der Entwicklung des AC-Projekts mit der Automatisierung des Anwendungsfalls „Hello-Cloud“ im ersten SLEEVE. Der Anwendungsfall „Hello Cloud“ erstellt eine Volterra-Site in AWS und Azure, kombiniert diese Sites dann zu einem Volterra VK8s-Cluster (virtuelles Kubernetes) und stellt mithilfe der VK8s eine 10-Pod Application auf beiden Sites bereit. Wir begannen den Prozess mit der Erstellung zusätzlicher Terraform-Vorlagen und Shell-Skripte unter Verwendung der Volterra-API, um einen vollständig automatisierten GitLab-Workflow zu erstellen, der von CI/CD-Pipelines verwaltet werden kann. Dann machten wir uns an die Arbeit, diese Bereitstellungsmethode wiederverwendbar und skalierbar zu machen.

Als nächstes haben wir uns an die Integration eindeutiger Namenskonventionen in unserem Design gemacht. Um mehrere Bereitstellungen des Anwendungsfalls in einer einzelnen Volterra-Mandantenumgebung zu ermöglichen, haben wir dafür gesorgt, dass alle Ressourcen, die wir in jedem STACK erstellen, einzigartige Namen erhalten und nicht versehentlich Namen verwenden, die in anderen STACKs derselben Umgebung vergeben sind. Zur Vermeidung von Namenskonflikten haben wir begonnen, eindeutige, vom Benutzer angegebene Umgebungsvariablen in die Pipeline-Trigger einzubauen, die zum zentralen Element des Projekts wurden. Die Variable STACK_NAME haben wir eingeführt und nutzen Terraform, um eine vom Nutzer definierte Zeichenfolge in allen Ressourcennamen eines bestimmten STACK einzubinden. Anstatt bei jedem Commit auszulösen, laufen die AC-Pipeline-Jobs nur dann, wenn ein GitLab-Benutzer via API-Aufruf mit einem GitLab-Projekt-CI-Trigger-Token den Start auslöst – so steuern Sie die Pipeline durch manuelle Eingaben oder externe API-Aufrufe. Mit API-Aufrufen ähnlich dem folgenden Beispiel ermöglichen wir Ihnen, mehrere Bereitstellungen ohne Ressourcenkonflikte mit nur einem einzigen Befehl durchzuführen.

Anschließend haben wir versucht, aus diesem Modell weitere Einsatzmöglichkeiten zu schaffen. Die AWS- und Azure-Site-Bereitstellungen von Hello-Cloud waren ebenfalls einzelne Anwendungsfälle, die wir unabhängig mit AC bereitstellen wollten. Dies führte dazu, dass wir auf unser erstes großes Problem mit GitLab stießen. In GitLab CI/CD-Pipelines sind alle Jobs in einer Projektpipeline verbunden. Dies war kontraintuitiv, da viele Jobs, die in unserer Hello-Cloud-Bereitstellung benötigt werden, in unseren AWS- oder Azure-Site-Bereitstellungen nicht benötigt werden. Wir wollten im Wesentlichen, dass eine GitLab-Projekt-CI-Pipeline mehrere unabhängige Pipelines enthält, die bei Bedarf mit separaten CI-Job-Sätzen ausgelöst werden können.

Um das Problem zu lösen, haben wir die Umgebungsvariable SLEEVE in die Pipeline-Struktur eingeführt, die die GitLab CI/CD only/except-Optionen integriert. So konnten wir die CI-Jobs, die in einer beliebigen Pipeline ausgelöst werden, anhand des im Pipeline-Trigger angegebenen SLEEVE-Werts begrenzen. Anfangs standen uns drei SLEEVE-Optionen zur Verfügung: simple-aws, simple-azure und hello-cloud. Jeder SLEEVE definierte, welchen Anwendungsfall Sie bereitstellen möchten (und steuerte damit die CI-Jobs in der ausgelösten Pipeline) sowie einen STACK_NAME zur Benennung der Ressourcen, die durch die Pipeline erstellt wurden. Die folgende Befehlsstruktur, welche beide Umgebungsvariablen enthält, ist der einfachste AC-Befehl und wird noch heute verwendet:

Das folgende Bild zeigt eine Visualisierung, wie sich durch die Änderung der Umgebungsvariable SLEEVE die bei jedem Durchlauf der AC-Pipeline ausgelösten Jobs ändern.

SLEEVE-Pipeline „simple-aws“:

SLEEVE-Pipeline „Hallo-Cloud“:

Wir haben zusätzliche Jobs eingerichtet, die ausführbar werden, sobald die Umgebungsvariable DESTROY bei einem Pipeline-Trigger angegeben ist. So können Sie Ressourcen, die durch AC erstellt wurden, gezielt entfernen. Das folgende Beispiel zeigt, wie Sie die Ressourcen eines bestehenden STACK löschen:

Andere Umgebungsvariablen wurden in GitLab mit Standardwerten gespeichert, die durch Hinzufügen von Werten zum Triggerbefehl überschrieben werden konnten. Beispielsweise wurde die API-URL unserer Volterra-Tenant-Umgebungen in der Umgebungsvariable VOLTERRA TENANT gespeichert. Wenn ein Benutzer seinem API-Befehl die Umgebungsvariable VOLTERRA TENANT hinzufügt , würde dies den Standardwert überschreiben und die Bereitstellung an den gewünschten Speicherort umleiten. Dies erwies sich als sehr wichtig für unsere internen Testmöglichkeiten, da das Lösungsteam Dutzende von Volterra-Mieterumgebungen verwaltet und je nach anstehender Aufgabe die Möglichkeit haben muss, zwischen ihnen zu wechseln:

Diese optionalen Umgebungsvariablen konnten verwendet werden, um bei Bedarf eine größere Kontrolle über Bereitstellungen zu erlangen, ermöglichten aber eine einfachere Standardbereitstellungsoption für Benutzer, die diesen zusätzlichen Mehraufwand nicht verwalten wollten. Darüber hinaus konnten wir problemlos zwischen Bereitstellungen in Staging- und Produktionsumgebungen wechseln, was sich für unseren größten AC-Verbraucher als unverzichtbar erweisen sollte.

Anwendungsfall der Lösung: Nächtliche Regressionstests

Wie bereits erwähnt, stellte jeder SLEEVE in AC einen Volterra-Anwendungsfall dar, der häufig die erste Interaktion der Kunden mit dem Produkt darstellte. Um einen überzeugenden ersten Eindruck des Produkts zu vermitteln, war es entscheidend, sicherzustellen, dass diese Anwendungsfälle funktionsfähig und fehlerfrei waren. Vor der Erstellung von AC war das Testen der Anwendungsfälle, um sicherzustellen, dass sie funktionsfähig und mit der neuesten Volterra-Software und den neuesten API-Versionen auf dem neuesten Stand waren, eine zeitaufwändige Aufgabe. Die für jeden Anwendungsfall erforderlichen manuellen Teile stellten eine Einschränkung bei den Regressionstests dar, die nicht oft genug durchgeführt wurden und anfällig für menschliches Versagen waren.

Mit AC-Automatisierung nutzen Sie täglich geplante Tasks, um die Bereitstellung eines bestimmten Anwendungsfalls mit einem SLEEVE zu starten und die dafür angelegten Ressourcen nach Abschluss oder Fehlschlag der Bereitstellung wieder zu entfernen. Sie können dies sowohl in Staging- als auch in Produktionsumgebungen einsetzen, um sicherzugehen, dass aktuelle Änderungen weder die Bereitstellung des Anwendungsfalls beeinträchtigen noch Fehler in der Volterra-Software verursachen. So lassen sich Fehler in Ihren Anwendungsfallleitfäden schnell aktualisieren oder Probleme in der Volterra-Software rasch erkennen und Behebungstickets erzeugen.

Wir haben ein separates Repository und eine Pipeline mit geplanten Jobs erstellt, die mithilfe der GitLab-API Triggerbefehle einsetzen, um parallel mehrere Stacks mit unterschiedlichen SLEEVEs zu erstellen. Jeder Smoke-Test-Job startet, indem er die Erstellung eines Stacks über eine unabhängige AC-Pipeline auslöst. Der Smoke-Test-Job ermittelt anschließend die Pipeline-ID aus der Standardausgabe des Trigger-Aufrufs und verwendet die GitLab-API, um den Status der gestarteten Pipeline zu überwachen. Sobald die Pipeline abgeschlossen ist – egal ob erfolgreich oder nicht – startet sie die Destroy-Pipeline für denselben STACK, um die Ressourcen nach dem Test zu entfernen.

Das folgende Bild zeigt diesen Vorgang im Detail und die Jobs, die er in AC für seine Erstellungs- und Vernichtungsbefehle auslöst:

Als eine Smoke-Test-Pipeline fehlschlug, konnten wir die Umgebungsvariablen bereitstellen, die in einem AC-Trigger verwendet werden konnten, um das Problem zu reproduzieren. Dies könnte in unseren technischen Problemtickets bereitgestellt werden, sodass unsere Entwickler die fehlgeschlagenen Bereitstellungen problemlos neu erstellen können. Als dann mehr SLEEVES fertiggestellt wurden, fügten wir den CI-Pipelines immer mehr Jobs hinzu, um eine größere Testabdeckung zu ermöglichen. Um die Sichtbarkeit dieser Tests weiter zu verbessern, haben wir eine Slack-Integration hinzugefügt und die Smoke-Test-Jobs die Erfolgs- oder Fehlermeldung jedes Pipeline-Laufs mit Links und Details an die entsprechenden CI-Webseiten sowohl im Altered-Carbon- als auch im Smoke-Test-Projekt senden lassen.

Stapelaufzeichnungsführung und Pipeline-Web-URL-Navigation

Die Komplexität des Projekts nahm zu, als AC sich weiterentwickelte, zusätzliche Benutzer aus dem Lösungsteam hinzukamen und immer mehr Stapel erstellt wurden. Dies führte zu grundlegenden Problemen bei der Navigation in der GitLab Pipeline-Web-Benutzeroberfläche. Wir verwendeten GitLab-Pipelines auf eine sehr unkonventionelle Weise, was die Verwendung der GitLab Pipeline-Web-Benutzeroberfläche zum Nachverfolgen einzelner Pipeline-Läufe, die sich auf die von uns erstellten STACKs bezogen, erschwerte.

GitLab-Pipelines, die Deployments über GitOps-Workflows steuern, eignen sich am besten für statisch definierte Cluster-Sets. Dabei wirkt sich jeder Pipeline-Durchlauf stets auf dieselben Cluster und Ressourcen aus. Die Deployment-Historie dieser Cluster spiegelt sich dann als Pipeline-Historie in der GitLab-Weboberfläche wider. AC ist jedoch dynamisch und verwaltet laufend wechselnde Ressourcensets, wobei jeder Pipeline-Durchlauf komplett unterschiedliche Jobs einsetzen kann, um verschiedene RESOURCE-STACKS bei unterschiedlichen Virtualisierungsanbietern zu steuern. Durch die Unterscheidung nach SLEEVE- und STACK-Konventionen fällt es schwer zuzuordnen, welche Pipeline zu welchem Stack gehört. Schauen wir uns zum Beispiel die GitLab CI/CD-Pipeline-Weboberfläche für AC an:

Aus dieser Ansicht können wir nicht bestimmen, welchen STACK oder SLEEVE eine einzelne Pipeline ändert, ohne jede einzelne Pipeline einzeln anzuzeigen. Wenn Hunderte von Pipelines pro Tag ausgeführt werden, kann es mühsam sein, den spezifischen Pipeline-Lauf zu finden, der einen bestimmten STACK erstellt oder zerstört hat, oder spezifische Details zu diesem STACK zu ermitteln. Um dieses Problem frühzeitig in der AC-Entwicklung zu lösen, haben wir ein einfaches System zur Aufzeichnung hinzugefügt. Ein Job würde vor jeder Pipeline namens „Stack-Records“ ausgeführt. Dieser Job würde bei der Erstellung Details zum Stapel sammeln und eine JSON-Datei generieren, die in unseren S3-Speicher-Bucket hochgeladen würde, der zum Speichern unserer TFState-Backups verwendet wird. Unten sehen wir ein Beispiel für einen Stapeldatensatz:

Die Dateien stack-record.json enthalten Details zu jedem Stapel, beispielsweise:

• Welche Volterra-Mandantenumgebung wurde verwendet.
• Welche HÜLSE wurde verwendet.
• Wenn der STACK gerade im Zustand „Anwenden“ lief oder seine Ressourcen im Zustand „Zerstören“ entfernt wurden.
• Welcher GitLab-Benutzer hat den Stack erstellt?
• Eine Arbeitsgruppe, die andere Benutzer mit Zugriff zum Ändern eines STACKS auflistet.
• Und am wichtigsten: ein Pipeline-Array, das die Web-URL jedes Pipeline-Laufs enthält, der für den Stapel ausgeführt wurde, wer die Pipeline ausgelöst hat, ob die Pipeline einen Stapel angewendet oder zerstört hat und wann die Pipeline ausgelöst wurde.

Dadurch wurde ein aufgezeichneter Verlauf aller mit einem bestimmten Stapel verknüpften Pipeline-URLs bereitgestellt. Um den Vorgang weiter zu vereinfachen, wurde ein einfaches CLI-Skript erstellt, das über S3-API-Aufrufe auf diese Dateien zugreifen kann. Unsere Benutzer, die AC verwenden, können diese Dokumente nutzen, um den Verlauf der Stapel zu verfolgen und durch Anzeigen der Stapelaufzeichnungen anzuzeigen, wann diese Stapel geändert wurden.

Stapeldatensätze ermöglichten uns außerdem die Implementierung bestimmter Ebenen der Benutzerkontrolle und Fehlererkennung über die von uns eingesetzten Pipelines. Beispielsweise zwang uns eine Änderung an der Volterra-Software nach der Erstellung von AC dazu , die bei der Volterra-Site-Erstellung verwendeten Site-Clusternamen (ein Wert, der vom STACK NAME-Wert abgeleitet wird) auf maximal 17 Zeichen zu beschränken. Daher haben wir dem Stapeldatensatzjob eine Prüfung hinzugefügt, die dazu führt, dass Pipelines fehlschlagen, bevor irgendwelche Bereitstellungsschritte ausgeführt werden, wenn der STAPELNAME die Zeichenbegrenzung überschreitet. Es wurden weitere benutzerdefinierte Steuerelemente hinzugefügt, z. B. das Hinzufügen von Benutzerberechtigungsstufen in AC, die einschränken, welche Benutzer Zugriff auf die Änderung bestimmter, von AC gesteuerter Stapel haben.

• Berechtigungen auf Administratorebene, mit denen die beiden obersten Entwickler von AC jeden beliebigen Stack zu Debugzwecken erstellen oder zerstören können. – Die Ebene „Eigentümer“ oder „Ersteller“ ist für einen GitLab-Benutzer, der ursprünglich einen STACK erstellt. Ihr GitLab-E-Mail-Wert wird in den Stapeldatensätzen als Ersteller aufgezeichnet und hat die Möglichkeit, einen Stapel zu erstellen oder zu zerstören.
• Dann haben wir Berechtigungen auf Arbeitsgruppenebene. Die E-Mail-Adresse des GitLab-Benutzers kann zum Arbeitsgruppen-Array des Stapeldatensatzes hinzugefügt werden, wodurch anderen Benutzern außer dem Ersteller die Möglichkeit gegeben wird, einen STACK anzuwenden oder zu löschen.
• Ein Benutzer ohne eine dieser Berechtigungsstufen kann einen Stack nicht ändern. Versuchen Sie als solcher Benutzer, einen Stack zu ändern, für den Sie keine Rechte besitzen, schlägt der Stack-Records-Auftrag fehl, noch bevor Ressourcen bereitgestellt werden.

Interne Verwendung und aktuelle Testabdeckung

Heute ist AC ein zentraler Bestandteil des Lösungsteams und übernimmt den Großteil unserer Regressionstests und Automatisierung. Wir haben festgestellt, dass es hauptsächlich für Regressions-Smoke-Tests, Skalentests, Produktabrechnungstests und vereinfachte Bereitstellungen in Produktdemos verwendet wird.

Automatisierte Bereitstellungen nutzen wir vor allem in unseren nächtlichen Regressionstests. Jede Nacht prüfen wir jedes unserer SLEEVES in einer Produktions- und Staging-Umgebung, indem wir die Bereitstellung auslösen und die angelegten Ressourcen anschließend wieder abbauen. Bei Änderungen erkennen Sie diese schnell und können Fehlerberichte erstellen, um unsere Anleitungen zu aktualisieren. Unsere aktuelle Testabdeckung umfasst:

• Sicheres Kubernetes-Gateway.
• Sicherheit von Application .
• Netzwerk-Edge Applications , die unsere standardmäßige 10-Pod Application „Hipster-Co“ und eine leichtere Single-Pod Application bereitstellen.
• Hallo-Cloud.
• CE-Einzelknoten-Einzelnetzwerkschnittstellen-Volterra-Sites über AWS, GCP, Azure, VSphere und KVM/Vagrant.
• CE-Einzelknoten-Volterra-Sites mit doppelter Netzwerkschnittstelle über AWS, GCP, Azure, VSphere und KVM/Vagrant.
• Skalierte Bereitstellungen von CE-Einzelknoten-Einzelnetzwerkschnittstellen-Volterra-Sites (mit GCP, VSphere und KVM), wobei eine Reihe von CE-Einzelknoten-Einzelnetzwerkschnittstellen-Sites erstellt wurden, um die Skalierungsfähigkeiten von Volterra zu testen.
• CE-Einzelknoten-Volterra-Sites mit mehreren Netzwerkschnittstellen über AWS, GCP, Azure, VSphere und KVM/Vagrant.
• CE-Multiknoten-Einzelnetzwerkschnittstellen-Volterra-Sites über AWS, GCP, Azure, VSphere und KVM/Vagrant.
• CE-Multiknoten-Multinetzwerkschnittstellen-Volterra-Sites über AWS, GCP, Azure, VSphere und KVM/Vagrant.

Wir verfügen außerdem über spezielle Skalierungstesthülsen, die den Prozess der Bereitstellung von bis zu 400 Sites gleichzeitig automatisieren, um die Skalierungsfunktionen der Volterra-Software zu testen und die mit GCP, vSphere und KVM getestet wurden.

Durch die schnelle automatisierte Bereitstellung von Anwendungsfällen können sich die Mitglieder des Lösungsteams auf andere Aufgaben konzentrieren, was die interne Effizienz verbessert. Das Lösungsteam verwendet AC häufig, um Dutzende von KVM-, GCP- und vSphere-Sites zum Aufzeichnen von Videodemos bereitzustellen. Dadurch sparen wir Zeit bei der Erstellung von Volterra-Sites, die wir zum Erstellen komplexerer Infrastrukturen verwenden können und die auf der vorhandenen Automatisierung aufbauen. Dies wird auch für tägliche Cron-Jobs verwendet, die die Abrechnungsfunktionen der Volterra-Plattform testen, indem die Bereitstellung von AWS, Web-App-Sicherheit, sicherem Kubernetes-Gateway und Application für Netzwerk-Edge-Anwendungen auf einem spezialisierten Volterra-Mieter, der Abrechnungsinformationen aufzeichnet, automatisiert wird.

Zukunftspläne und Roadmap

Unser Einsatz von AC führt bereits zu sehr erfolgreichen Ergebnissen und es werden in naher Zukunft noch viele weitere Funktionen und Verbesserungen zum Projekt hinzugefügt.

Die größte Neuerung im Projekt ist die ständige Hinzufügung neuer SLEEVE-Optionen zur Abdeckung zusätzlicher Anwendungsfallbereitstellungen. Für jedes neue hinzugefügte SLEEVE fügen wir unseren nächtlichen Regressions-Smoke-Tests einen neuen Job hinzu und bieten so eine größere Abdeckung für Projekte zur Lösungsbereitstellung. Die meisten früheren Sleeves konzentrierten sich auf Anwendungsfälle mit einzelnen Knoten und einzelnen Netzwerkschnittstellen, aber wir haben unsere SLEEVE-Abdeckung kürzlich auf Multi-Node-Volterra-Site-Cluster und Anwendungsfälle mit mehreren Netzwerkschnittstellen auf den Plattformen AWS, Azure, GCP, VMWare und KVM/Vagrant ausgeweitet.

Wir möchten auch unser Stapelaufzeichnungssystem verbessern. Wir werden den Detaillierungsgrad unserer AC-Datensätze erhöhen und durch die Einbindung von RDS-Datenbankspeichern für unsere Datensätze verbesserte Suchfunktionen hinzufügen. Das Ziel besteht darin, dass wir schnellere Suchvorgänge in unserer AC-Umgebung und selektivere Suchfunktionen bereitstellen können, wie etwa Stapelsuchen basierend auf Stapelstatus, Stapelerstellern usw. Auf unserem Plan steht auch die Verwendung dieser Datensätze zum Erstellen einer benutzerdefinierten Benutzeroberfläche zur effizienteren Visualisierung von mit AC erstellten Bereitstellungen.