Ein führender Anbieter von Zahlungssoftwarelösungen trat an uns heran, um eine automatisierte Integrationstestumgebung zu erstellen.
Unser Kunde, ein führender Anbieter von Zahlungssoftwarelösungen für ein großes Automobilunternehmen in Deutschland, trat an uns heran, um eine automatisierte Integrationstestumgebung zu erstellen. Die Umgebung muss automatisch sowohl in einer der öffentlichen Clouds als auch in der privaten Cloud des Kunden bereitgestellt werden. Das Ziel ist es, genau die gleiche Funktionalität zu erreichen, die bereits in der weniger sicherheitsrelevanten öffentlichen Cloud vorhanden ist, und zwar auf vollständig automatisierte Weise; z. B. die Bereitstellung mehrerer Microservices, die automatisch zusammenarbeiten, die Durchführung von Validierungstests und die Erfassung von Protokollen und Metriken. Die Validierung gilt als erfolgreich, wenn jeder Python- und Selenium-QA-Test ohne Fehlschlag abgeschlossen wurde. Dann wird die temporäre Umgebung/der Namespace abgebaut. Der Code, der die Testpipeline durchläuft, wird als Release-Kandidat gekennzeichnet und in Form von Docker-Images an die vom Kunden gehostete Docker-Registry übertragen. Natürlich muss das Projekt trotz der knappen Fristen nach allen DevOps Best Practices durchgeführt werden. Dies erforderte einen rigorosen Implementierungsprozess, der sich an den DevOps-Best-Practices orientierte und die strengen regulatorischen Anforderungen in der Branche des Kunden einhielt.
DIE HERAUSFORDERUNG
Das Projekt war mit einigen bemerkenswerten Herausforderungen verbunden, die das Know-how und die Kreativität unseres Teams erforderten. Erstens war der Zugriff auf den Hybrid-Cloud-Kubernetes-Cluster aufgrund der strengen Sicherheitsanforderungen in der Finanz- und Fintech-Branche eine große Herausforderung. Unser Team arbeitete eng mit dem Softwareanbieter zusammen, um Vertrauen zu schaffen und die notwendigen Sicherheitsgenehmigungen zu erhalten, um Zugang zum Cluster zu bekommen.
Zweitens standen wir vor der Aufgabe, schnell einen Kubernetes-Cluster zu erstellen, der die automatische Bereitstellung neuer Integrationstestumgebungen erleichtern sollte. Unsere Lösung bestand darin, die umfangreiche Wissensbasis und die auf der AWS-Plattform verfügbaren Ressourcen zu nutzen, um einen Kubernetes-Cluster zu erstellen, der mehrere Microservices ausführen, Metriken erfassen und Validierungstests durchführen kann. Mit diesem Ansatz konnten wir knappe Fristen einhalten und den Kunden die benötigte Hochleistungsumgebung bereitstellen.
Insgesamt haben die einzigartigen Herausforderungen dieses Projekts die Fähigkeit unseres Teams unterstrichen, Hindernisse zu überwinden und innovative Lösungen zu entwickeln, die die komplexen Anforderungen und Vorschriften der Finanz- und Fintech-Branche erfüllen.
DIE LÖSUNG
→ Kubernetes-Initialisierung
Das Ziel war natürlich eine ausfallsichere Umgebung, die nicht ständig gewartet werden muss und ohne Schluckauf funktioniert.
Um dies zu erreichen, nutzen wir die Stärken von Kubernetes, Jenkins und AWS-Diensten. Ausgehend von der Linux-Distribution bauen wir unser eigenes AMI auf, das auf den Sicherheits- und Versionsanforderungen des Kunden basiert. Dies gibt uns die Möglichkeit, eine produktionsreife Kubernetes-Cluster-Umgebung zu erstellen, die in einer eigenen VPC mit privaten Subnetzen, Domänen und ELBs läuft.
→Jenkins-Server
Jenkins ist das Produkt unserer Wahl, wenn es darum geht, Bereitstellungsprozesse zu automatisieren und sie in Pipelines zu bündeln. Es übernimmt alle Schritte, die notwendig sind, um eine Umgebung zu erstellen, zu testen und wieder abzubauen, ohne dass ein menschliches Eingreifen erforderlich ist.
→HELM-Auslastung
Wenn wir helm.sh zur Verfügung haben, wird alles viel einfacher. Zunächst nutzen wir seine Leistungsfähigkeit, indem wir die Komponenten der Kubernetes-Infrastruktur
aufrufen, wie z. B.:
- Prometheus;
- Grafana;
- Alert Manager;
- Elasticsearch;
- FluentD;
- Kibana;
- Ingress-Controller;
- Quay-enterprise (Docker-Registry).
Dann verwenden wir Helm, um die Integrationstestumgebung zu erstellen und sie später mithilfe von Pipelines nach unseren Wünschen anzupassen. Da jedes Diagramm im Git-Repository gespeichert ist, bietet es noch mehr Flexibilität und Kontrolle über das erwartete Ergebnis.
→Pipeline-Konzept
Wir haben uns für eine Kette von Jenkins-Aufträgen als Automatisierungsansatz entschieden. Anstatt separate Aufträge für die Bereitstellung jeder Anwendung zu haben, hatten wir einen einzigen "Deploy"-Auftrag, der Variablen als Eingabe vom primären Wrapper-Auftrag erhielt und für jede Anwendung arbeitete. Eine der vielen Herausforderungen bestand darin, alle Aufträge und Umgebungen parallel laufen zu lassen, so dass die einzige Einschränkung für parallele Tests die tatsächlich verfügbaren Kubernetes-Ressourcen sind. Alle Aufträge mussten unter Berücksichtigung der Skalierbarkeit konzipiert werden. Letztendlich standen uns zwei Ansätze zur Verfügung, mit denen wir mehrere Integrationstests parallel ausführen konnten - über einen Jenkins-URL-Aufruf oder über einen ECR-Scanner-Job, der nur die gleichzeitige Ausführung eines Integrationstests erlaubt. Wir verwendeten Helm als unser Kubernetes-Bereitstellungstool. Es bietet eine gute Versionierung und ist in einem Repository leicht zu verwalten.
DIE SCHLUSSFOLGERUNG
Zusammenfassend lässt sich sagen, dass wir erfolgreich eine automatisierte Build- und Bereitstellungsumgebung mit AWS und Kubernetes implementiert haben, die alle Anforderungen des Kunden erfüllte und die bewährten DevOps-Verfahren einhielt. Wir haben mehrere Herausforderungen gemeistert, darunter die Einholung der erforderlichen Sicherheitsgenehmigungen und die Erstellung des Kubernetes-Clusters innerhalb enger Fristen. Durch unser Fachwissen bei der Nutzung von Kubernetes, Jenkins und AWS-Diensten konnten wir eine ausfallsichere Umgebung schaffen, die vollständig automatisiert ist und keine menschlichen Eingriffe erfordert. Unser Einsatz von Helm ermöglichte eine größere Flexibilität und Kontrolle über das erwartete Ergebnis, und unser Pipeline-Konzept ermöglichte parallele Tests und Skalierbarkeit. Insgesamt lieferten wir eine Kubernetes-Umgebung mit einer Jenkins-Konfiguration, die problemlos in jeder privaten oder öffentlichen Cloud eingesetzt werden kann und sofort einsatzbereit ist, während sie gleichzeitig die Einhaltung von Branchenvorschriften im der Finanz- und Fintech-Branche.