Willkommen zum zweiten Blogbeitrag über unseren neuen 4DIdentity-Service. Im ersten Blogbeitrag haben wir unsere Motivation zur Erstellung dieses internen Dienstes und dessen Architektur besprochen. Kurze Zusammenfassung: Wir nutzen ihn, um Single Sign-On für interne Anwendungen und zukünftige Managed Services zu ermöglichen. 4DIdentity basiert auf dem Amazon Cognito Service von AWS. Wir haben bewusst entschieden, ihn komplett serverlos, hoch resilient, vollständig verwaltbar und mit Infrastructure as Code (IaC) zu bauen.

In diesem Beitrag erläutern wir zunächst, wie wir den 4DIdentity-Service in vollständig automatisierter Weise mit GitOps bereitstellen und konfigurieren. Anschliessend besprechen wir das Infrastructure as Code-Setup, das die konsistente und automatisierte Konfiguration der verschiedenen AWS-Dienste ermöglicht. Danach zeigen wir, wie wir mit GitLab die Entwicklungskosten niedrig halten, indem wir die während der Entwicklung genutzte Infrastruktur automatisch bereinigen. Schliesslich beschreiben wir, wie wir eine grundlegende Berechtigungsverwaltungslösung unter Verwendung von GitOps-Prinzipien implementiert haben.

Deployment

Wir haben uns hauptsächlich auf Automatisierung und IaC konzentriert, als wir diesen Service entwickelt haben. Wir haben Terraform als unser IaC-Tool und GitLab CI-Pipelines verwendet, um den Code anzuwenden. Dadurch können wir die Infrastruktur automatisch in verschiedene Umgebungen bereitstellen. Wie im ersten Blogbeitrag erwähnt, umfassen die in 4DIdentity verwendeten Dienste EventBridge für das Monitoring, Simple Email Service (SES) und die Amazon Cognito-Benutzerpools. Wir haben auch erläutert, dass wir die Pilot Light Disaster-Recovery-Strategie anwenden, die erfordert, ein ruhendes Setup in einer Ausweichregion bereitzustellen. Der Screenshot unten zeigt das needs Diagramm der Haupt-GitLab CI-Pipeline zur Bereitstellung / Konfiguration der verschiedenen Dienste für die Entwicklungsumgebung. Besonders schön an diesem Setup ist, dass das Bereitstellen der Ausweichinfrastruktur einfach ein zusätzlicher CI-Job ist, nachdem die primäre Infrastruktur bereitgestellt wurde.

Die Hauptpipeline besteht nur aus Trigger-Jobs, die sicherstellen, dass die verschiedenen Dienste in der richtigen Reihenfolge bereitgestellt werden, um die Abhängigkeiten zwischen ihnen zu berücksichtigen. Jeder Trigger-Job löst eine nachgelagerte Pipeline aus, die dann den Code anwendet, indem sie immer die gleichen vier Stufen durchläuft: validate, test, plan und apply, mit einer zusätzlichen cleanup-Stufe, die manuell ausgeführt werden kann, um die bereitgestellte Infrastruktur zu entfernen.

Wir nutzen dann die verschiedenen Pipeline-Typen in GitLab, wie Branch-Pipelines, Merge-Request-Pipelines und Tag-Pipelines, um die Infrastruktur für die verschiedenen Umgebungen bereitzustellen:

• Branch-Pipelines werden verwendet, um die Entwicklungsumgebung bereitzustellen. Wenn also ein Entwicklungs-Branch erstellt wird, wird automatisch eine neue Entwicklungsumgebung bereitgestellt. Das Zusammenführen des Entwicklungs-Branches in den "main"-Branch löst dann eine Bereitstellung in die Vorproduktionsumgebung aus.
• Merge-Request-Pipelines werden verwendet, um die Änderungen vorzuschauen, die in die Vorproduktions- und Produktionsumgebungen übernommen werden, bevor der Code in den "main"-Branch zusammengeführt wird.
• Tag-Pipelines werden ausgelöst, wenn der Code in GitLab getaggt wird und werden verwendet, um die Produktionsumgebung bereitzustellen.

Zusätzlich nutzen wir GitLab, um die Terraform-State-Datei zu speichern und deren Konsistenz sicherzustellen. Schliesslich verwenden wir die GitLab-Umgebungsfunktion, die es uns ermöglicht, verschiedene Umgebungen in GitLab zu trennen, die mit spezifischen Pipelines verknüpft sind und die Zielumgebungen automatisch auf dem neuesten Stand halten.

IaC-Struktur

Für unseren Anwendungsfall erwarten wir, dass mehrere verschiedene Benutzerpools als Teil unserer 4DIdentity-Lösung bereitgestellt werden. Daher machte es Sinn, die verschiedenen Benutzerpools mit einem Terraform-Modul zu erstellen. Das Erstellen und Warten eines Moduls erfordert jedoch zusätzlichen Aufwand. Um diesen Aufwand zu reduzieren, haben wir den Prozess ebenfalls mit GitLab automatisiert.

In unserer Hauptpipeline, die die Trigger-Jobs für die Bereitstellung unserer Infrastruktur enthält, haben wir auch einen Job integriert, um unser Terraform-Modul für die Einrichtung der Benutzerpools automatisch zu validieren und zu erstellen. Dieser Job wird nur ausgeführt, wenn der Modulcode aktualisiert wurde. Beim Erstellen des Moduls lädt der Job es auch in das Terraform-Modul-Registry von GitLab hoch und kümmert sich um die korrekte semantische Versionierung. Für die semantische Versionierung nutzen wir erneut die verschiedenen Pipeline-Typen, die GitLab bietet. Die verschiedenen Versionen werden wie folgt aktualisiert:

• Die Patch-Version wird aktualisiert, wann immer das Modul aus einer Standard-Branch-Pipeline erstellt wird.
• Die Minor-Version wird aktualisiert, wann immer das Modul aus einer Tag-Pipeline erstellt wird.
• Für das Major-Version-Upgrade haben wir ein spezielles Flag erstellt, da nicht viele Major-Upgrades erwartet werden.

Ephemere vs. persistente Umgebungen

Wir möchten verschiedene Umgebungen haben, um die Wartbarkeit und Verfügbarkeit des Dienstes sicherzustellen. Gleichzeitig wollen wir jedoch unsere Cloud-Kosten im Auge behalten und vermeiden, veraltete Infrastrukturkomponenten laufen zu lassen. Auch wenn es kein grosses Problem darstellt, bevorzugen wir es dennoch, unsere Entwicklungsumgebung sauber zu halten und nur dann Dienste bereitzustellen, wenn sie benötigt werden. Daher haben wir eine ephemere Entwicklungsumgebung.

Mit GitLab gibt es eine elegante Möglichkeit, dies zu erreichen, indem man die eingebaute Funktion nutzt, die eine Umgebung beendet, wenn sie von einer Pipeline erstellt wurde, die durch die Erstellung eines Entwicklungs-Branches ausgelöst wurde. Wenn der cleanup-Job mit der on_stop-Aktion einer solchen Umgebung verknüpft ist, wird der Cleanup-Job automatisch ausgelöst, wenn der Entwicklungs-Branch in den Main-Branch zusammengeführt wird. Dadurch wird die während der Entwicklung genutzte Infrastruktur automatisch entfernt, was die Cloud-Umgebung sauber hält und die Kosten unter Kontrolle hält.

Gruppenmitgliedschaftsverwaltung

4DIdentity fungiert als Identitäts- und Zugriffsmanagementdienst (IAM). Dementsprechend bietet es auch die Möglichkeit, Berechtigungen in Anwendungen und Tools zu verwalten, die damit verbunden sind. Die den Benutzern gewährten Berechtigungen werden je nach Gruppenzugehörigkeit einer Person und nicht nach der einzelnen Person verwaltet. Auch in Amazon Cognito wurde das Konzept der Gruppen übernommen. Die Gruppenzugehörigkeit der Benutzer kann ebenfalls mit AWS Lambda-Funktionen oder wieder mit IaC automatisiert werden.

Um die Berechtigungen unserer intern genutzten Tools zu verwalten, verwenden wir ein einfaches IaC-Setup, um Gruppen und Mitgliedschaften zu verwalten. Ein GitLab-Repository enthält den Terraform-Code, der zur Verwaltung der Gruppenmitgliedschaft verwendet wird und den Code automatisch auf die verschiedenen Umgebungen anwendet, genauso wie wir den 4DIdentity-Dienst bereitstellen.

Dies ermöglicht es uns, die Berechtigungen für unsere internen Anwendungen zu verwalten, indem wir eine Merge-Request (MR) für den Code erstellen. Die Nutzung der CodeOwner-Funktion von GitLab stellt sicher, dass die verantwortliche Person die MR überprüft und dem regulären Überprüfungs- und Genehmigungsprozess folgt. Schliesslich bieten diese Methoden dank des eingebauten Versionierungssystems von GitLab Audit-Fähigkeiten out-of-the-box.

Fazit

Damit endet dieser Blogbeitrag sowie unsere Serie über unseren 4DIdentity-Dienst. In diesem Beitrag haben wir uns darauf konzentriert, wie wir unseren Infrastrukturcode strukturieren und wie wir den Code in GitLab-Pipelines anwenden, um ihn in verschiedenen Umgebungen bereitzustellen.

Wie immer, zögere nicht, uns für Feedback oder Fragen zu kontaktieren.