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.

Das Hinzufügen eindeutiger Namenskonventionen war das nächste Problem, das wir in unserem Entwurf in Angriff genommen haben. Um mehrere Bereitstellungen des Anwendungsfalls in einer einzigen Volterra-Mandantenumgebung zu ermöglichen, mussten wir sicherstellen, dass unsere in jedem STACK erstellten Ressourcen eindeutige Namen hatten und nicht versuchten, Ressourcen mit Namen zu erstellen, die andere STACKs in derselben Volterra-Mandantenumgebung duplizierten. Um mögliche Konflikte bei Namenskonventionen zu lösen, begannen wir, die Idee eindeutiger, vom Benutzer bereitgestellter Umgebungsvariablen in Pipeline-Trigger zu integrieren, die für das Projekt von zentraler Bedeutung werden sollten. Die Umgebungsvariable STACK_NAME wurde eingeführt und von Terraform verwendet, um eine benutzerdefinierte Zeichenfolge in die Namen aller Ressourcen aufzunehmen, die einem bestimmten STACK zugeordnet sind. Anstatt beim Commit ausgelöst zu werden, wurden die Auslösebedingungen der AC-Pipeline-Jobs so eingestellt, dass sie nur ausgeführt werden, wenn sie durch einen API-Aufruf eines GitLab-Benutzers unter Verwendung eines GitLab-Projekt-CI-Trigger-Tokens ausgelöst werden, wodurch die Pipeline durch menschliche Eingabe oder externe API-Aufrufe gesteuert werden kann. Durch die Verwendung von API-Aufrufen ähnlich dem folgenden Beispiel konnten Benutzer unser Ziel erreichen, mehrere Bereitstellungen ohne Ressourcenkonflikte mit einem einzigen Befehl zu erstellen.

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 dieses Problem zu lösen, haben wir die Umgebungsvariable SLEEVE in die Pipeline-Struktur eingeführt, die nur/außer den Optionen GitLab CI/CD enthält. Dadurch konnten CI-Jobs, die auf einer beliebigen Pipeline ausgelöst wurden, basierend auf dem im Pipeline-Trigger bereitgestellten SLEEVE-Wert begrenzt werden. Schließlich hatten wir unsere anfänglichen 3 SLEEVE-Optionen: simple-aws, simple-azure und hello-cloud. Jeder SLEEVE würde definieren, welchen Anwendungsfall ein Benutzer bereitstellen möchte (und so die CI-Jobs in einer ausgelösten Pipeline steuern) und einen STACK_NAME, um die von einer ausgelösten Pipeline erstellten Ressourcen zu benennen. Die folgende Befehlsstruktur, die beide Umgebungsvariablen einbezieht, diente als grundlegendster AC-Befehl, der auch heute noch verwendet wird:

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 außerdem zusätzliche Jobs eingeführt, die ausgelöst werden, wenn die Umgebungsvariable DESTROY in einem beliebigen Pipeline-Trigger angegeben wird. Dies würde eine umgekehrte Option zum Entfernen der von AC erstellten Ressourcen bieten. Das Folgende ist ein Beispiel dafür, wie die Ressourcen eines vorhandenen STACKS entfernt werden:

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 der AC-Automatisierung können jedoch täglich geplante Jobs verwendet werden, um die Bereitstellung eines bestimmten Anwendungsfalls mit einem SLEEVE auszulösen und dann die erstellten Ressourcen zu entfernen, nachdem die Bereitstellung entweder abgeschlossen ist oder fehlgeschlagen ist. Dies wurde sowohl in Staging- als auch in Produktionsumgebungen verwendet, um zu testen, ob aktuelle Änderungen die Bereitstellung des Anwendungsfalls beeinträchtigt oder Fehler in der Volterra-Software verursacht haben. Wir könnten dann gefundene Fehler in unseren Anwendungsfallhandbüchern aktualisieren oder Softwarefehler von Volterra schnell erkennen und Lösungstickets einreichen.

Wir haben ein separates Repository und eine Pipeline mit geplanten Jobs erstellt, die die Triggerbefehle der GitLab-API verwenden, um gleichzeitig mehrere Stacks mit unterschiedlichen SLEEVEs zu generieren. Jeder Smoketest-Job würde mit der Auslösung der Erstellung eines Stapels mit einer unabhängigen AC-Pipeline beginnen. Der Smoke-Test-Job würde dann die Pipeline-ID vom Standardout des Pipeline-Triggeraufrufs und der GitLab-API abrufen, um den Status der von ihm ausgelösten Pipeline zu überwachen. Wenn die Pipeline abgeschlossen ist (entweder erfolgreich oder mit einem Fehler), wird die Destroy-Pipeline auf demselben STACK ausgeführt, den sie erstellt hat, 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 Bereitstellungen über GitOps-Workflows verwalten, scheinen am besten geeignet, wenn sie für einen statisch definierten Satz von Clustern verwendet werden. In diesem Fall würde sich jeder Lauf einer GitLab-Pipeline jedes Mal auf dieselben Cluster und Ressourcen auswirken. Der Bereitstellungsverlauf dieser Cluster ist in diesem Fall der Pipelineverlauf, der in der GitLab-Web-Benutzeroberfläche visualisiert wird. AC ist jedoch dynamisch und verarbeitet einen sich ständig ändernden Satz von Ressourcen, wobei jeder Pipeline-Lauf einen völlig anderen Satz von Jobs nutzen und unterschiedliche STACKS von Ressourcen bei verschiedenen Virtualisierungsanbietern verwalten kann. Diese durch die SLEEVE- und STACK-Konventionen geschaffene Unterscheidung führte dazu, dass es sehr schwierig ist, zu bestimmen, welche Pipeline welchem Stapel entspricht. Wir können uns beispielsweise die GitLab CI/CD-Pipeline-Web-Benutzeroberfläche für AC ansehen:

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 entweder gerade im Status „Apply“ ausgeführt wurde oder wenn seine Ressourcen mit dem Status „Destroy“ 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 Stapel nicht ändern. Wenn ein solcher Benutzer versucht, einen Stapel zu ändern, für den er keine Berechtigung hat, schlägt der Stapeldatensatzjob fehl, bevor irgendwelche 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.

Die automatisierten Bereitstellungen haben ihren größten Verbrauch in unseren nächtlichen Regressionstests gefunden. Jede Nacht testen wir jedes unserer SLEEVES in einer Produktions- und Staging-Umgebung, indem wir eine Bereitstellung auslösen und dann die erstellten Ressourcen abbauen. Wenn Änderungen auftreten, können wir diese schnell erkennen und Fehlerberichte übermitteln, um unsere Anleitungen zu aktualisieren. Unser aktueller Testumfang 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.