Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
•Als PPTX, PDF herunterladen•
0 gefällt mir•137 views
Was ist die beste Vorgehensweise um ein Produkt im Konzernumfeld für mehrere Mandanten auszurollen? Hoffentlich ein multimandantenfähiges Kaufprodukt einkaufen, das der Vorgabe der Prozesstrennung für Mandanten entspricht. Leider hatten wir in unserem Team kein solches Produkt zur Verfügung und standen vor der Herausforderung für jeden Mandanten einen eigenes System aufsetzen zu müssen. In diesem Vortrag beschreiben wir die drei Entwicklungsstufen unseres Deploymentprozesses hinsichtlich der Server-Infrastruktur in AWS inklusive Trennung der AWS-Accounts in Test- und Produktiv-Umgebungen. Die erste Phase beschreibt dabei den Aufbau einer managed Cloud mit festen Servern. Diese können zwar automatisiert eingerichtet werden, die automatische Skalierbarkeit ist aber unzureichend. Die nächste Iteration beleuchtet den Ansatz des "Infrastructure as Code" über Cloudformation, der für ein dediziertes System sehr gut funktionierte. Probleme bereiteten uns der richtige Git-Flow und die fehlende Unterstützung für eine echte Trennung der Systeme pro AWS-Account. In unserer aktuellen und hoffentlich finalen Iteration sind wir auf einen konsequenten GitOps-Ansatz gewechselt. Wir beschreiben, wie wir mit diesem Vorgehen seit Monaten stabile Infrastuktur-Deployments über Gitlab in Produktion bringen, welche Herausforderungen zu lösen waren im Hinblick auf Configuration as Code und dem richtigen Git-Flow. Auch die Erleichterung hinsichtlich der Einhaltung verschiedener Konzernvorgaben, beispielsweise der ISO 20000 an Release- und Changemanagement, darf hierbei nicht fehlen.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
Ähnlich wie Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments (12)
Mehr von Johannes Dienst
Mehr von Johannes Dienst (17)
Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
- 1. Von Managed Cloud zu GitOps Multi Client-Cluster Deployments DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas
- 2. Digitalpartner der Deutschen Bahn DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 2
- 3. DB Content Hub DB Systel GmbH | Johannes Dienst | @JohannesDienst | Jan Kohlhaas 3 ‒ Content as a Service (CaaS) ‒ Headless CMS ‒ Gehosted in der Cloud ‒ You build it, you run it!
- 4. DB Content Hub DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 4 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 5. Anforderung: Physisch separierte Kundencluster DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 5 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 6. Requirement: ISO 20000 DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 6
- 7. Anforderung: ISO 20000 DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 7 ‒Changemanagement ‒Releasemanagement ISO/IEC 2000-1 Service management system requirements
- 8. Changemanagement DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 8 Request for change Change planen Change freigeben Change implementieren Review Change Abschliessen
- 9. Releasemanagement DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 9 Releasenotes Freigabe Test Rollout Technischer Abnahmetest Fachliche Prüfung
- 10. Vision: Die Infrastruktur DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 10 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 11. Erste Iteration: Ansible -> Managed Cloud DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 11 Free Software Foundation - [1], FAL, https://commons.wikimedia.org/w/index.php?curid=53428398 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 12. Erste Iteration: Pain Points DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 12 Free Software Foundation - [1], FAL, https://commons.wikimedia.org/w/index.php?curid=53428398 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com ‒Schnell für einen Kunden ‒Compliance & Security ‒Wahrheit nicht im Repository
- 13. Zweite Iteration: Cloudformation Monorepository + Gitlab Pipeline DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 13 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 14. Zweite Iteration: Vorteile und Pain Points DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 14 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com ‒Schwierig zu warten ‒Kundenkonfigurationen nebeneinander ‒Aussteuerung über Pipelines ‒Compliance und Security
- 15. Dritte Iteration: Terraform und GitOps DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 15 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 16. Dritte Iteration: Terraform und GitOps DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 16 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 17. Dritte Iteration: Vorteile DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 17 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com ‒ Updates auf Einzelkomponenten einfach: MR in Kundenrepository ‒ Kundenkonfigurationen sauber getrennt ‒ Autarke Cluster (Stacks) ‒ Kundenrepository enthält nur Konfiguration (Automatisierung) ‒ Potenziell beliebig viele Stacks
- 18. Dritte Iteration: Unterschiedliche Umgebungen DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 18 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 19. Dritte Iteration: Terraform und Gitops DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 19
- 20. Dritte Iteration: Einbindung Monitoring GitOps DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 20 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 21. Wrap Up DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 21 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 22. Wrap Up - Advantages DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 22 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com ‒Einfaches anlegen neuer Kunden ‒Rolling Updates auf Knopfdruck ‒Anbindung an Monitoring ‒Compliance und Security Updates
- 23. Wrap Up - Herausforderungen DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 23 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com ‒Viele Git-Repositories ‒Komplexes Zusammenspiel Ausblick ‒Zentrales Management-Tool (Spot) ‒Aggregation der wichtigsten Informationen
- 24. DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 24 Welche zwei Fragen sind noch offen? Johannes.Dienst@deutschebahn.com @JohannesDienst Jan.J.Kohlhaas@deutschebahn.com
Hinweis der Redaktion
- Johannes + Jan
- Johannes
- Jan Base Setup: Headless CMS, generisches Datenmodell Global Content as a Service im Konzern bereitstellen Infrastruktur einer Clusters: Linux-Server, Zentrale Datenbank (RDS), Redis-Cache, Netzwerkspeicher (EFS) Zentrale API, einheitliche Abfragen, erleichterter Zugang zu Daten Kontrolle der Requests, des Traffics, zentrale WAF
- Jan Anforderungen an das Produkt: Automatisiertes Deployment beliebig vieler Kundencluster parallel Datenschutz -> Daten müssen physisch strikt voneinander getrennt sein, es darf kein Zugriff von einem auf der anderen Cluster möglich sein Zentrale API übernimmt das Routing per API-Key auf die Kundencluster im Hintergrund Hauptziel im Deployment: Neue Cluster und Updates für bestehende Kundencluster automatisch ausrollen können
- Johannes Nachvollziehbarkeit -> TODO Haben wir dazu eine interessante Story?
- Johannes Beispiele was da drunter fällt -> Request for Change (MR) Release Notes Testing Planning Changes -> Centralized Tool
- Johannes Beispiele was da drunter fällt -> Request for Change (MR) Release Notes Testing Planning Changes -> Centralized Tool Motivation: - Change Fail Rate > KPI > Wie gut ist die Qualität in den einzelnen Bereichen Firmen- / Konzernweit
- Johannes Beispiele was da drunter fällt -> Request for Change (MR) Release Notes Testing Planning Changes -> Centralized Tool
- Johannes Oben: LoadBalancer Mitte: EC2 / Server Unten: RDS, Redis-Cache, EFS Erzählen: Vorher: Routing Kundencluster Zum LB Zum Cluster / EC2 Hintergrundsysteme: Datenbank, EFS, Cache Automatische Einbindung des Servers / EC2 ins Kundennetzwerk, Einbindung der Services / Datenbank etc. automatisiert per Script / Terraform
- Johannes * First customer * Convenient and fast * Compliance is a problem -> What is deployed is not always declared in repository
- Johannes * First customer * Convenient and fast Compliance is a problem -> What is deployed is not always declared in repository Story: Plugin wurde selbst kompiliert auf Entwicklerrechner und dann deployed. Änderung aber nicht zurückgespielt.
- Johannes Advantages: Compliance easier to achieve because configuration and infrastructure is automatically verifiable over Code Pipeline deploys more reliable Disadvantages: Monorepository -> Chance of changing customer configuration of wrong customer Hard to maintain Deployment has to manual or pipeline very complex
- Johannes Advantages: Compliance easier to achieve because configuration and infrastructure is automatically verifiable over Code Pipeline deploys more reliable Disadvantages: Monorepository -> Chance of changing customer configuration of wrong customer Hard to maintain -> Änderungen wurden über Branches gemanaged, aber wie sieht das mit mehreren Umgebungen in unterschiedlichen Accounts aus? Deployment has to be manual or pipeline very complex
- Jan Finaler Ansatz: Repository pro asset (Docker, Plugin / Extensions, AMI, Infrastructure), Gitlab-Repository pro Kunden mit Konfigurationsmöglichkeiten Automatisches anlegen, einrichten und vorkonfigurieren von neuen Kundenrepositories Updates der assets (Docker, Plugin / Extensions, AMI, Infrastructure): Automatisch akzeptierte Merge Requests im Kundenrepo Stellt sicher, dass immer die neuesten (abgenommenen) Versionen der Assets im Kundencluster deplyoed werden
- Jan Am „Release-Day“: Auführen der Kundenpipeline deployed alle Assets mit einem Klick Branchbasiert: Unterschiedliche Branches bauen unterschiedliche Umgebungen in der AWS auf Infrastruktur-Pipeline wird per Gitlab-API ausgeführt Übergeben werden alle relevanten Konfigurationen per Gitlab-API-Variablen an Terraform wie z.B. die Versionen der Docker-Container, der zu ladenden Plugins etc. Alle benötigten Secrets werden von Terraform erstellt und im AWS Secretsmanager abgelegt und verwaltet Finale Infrastruktur: Cluster aus Linux-Servern, zentrale Datenbank RDS, zentraler Redis-Cache, zentrales Netzwerk-Filesystem EFS Automatisierte Einbindung ins Monitoring
- Jan
- Jan Assets durchlaufen verschiedene Stadien: Feature-Branch, Development, Main, Production Gitflow-Ansatz Neue Versionen in den Release-Branches triggern Merge Requests im Kundenrepo im entsprechenden Branch Release-Branches repräsentieren Umgebungen / Kunden-Cluster in der AWS Gitlab-Releases für jedes Asset erleichtert den Überblick TODO: Aktuell auf 3 Umgebungen / Branches begrenzt: > Ziel: n Umgebungen dynamisch aufbauen
- Jan Exzessive Nutzung von Child-Pipelines / Downstreams Trigger per API und per Child-Pipelines Notes: - Validierung erklären - Terraform-State im Plan-Schritt: Differenz auf neuem plan und state - Rolling-Update mit Autoscaling-Groups
- Jan Monitoring-Stack wird mit selben Ansatz aufgebaut / geupdated (Gitflow, Terraform etc.) Kundencluster werden automatisch ins Monitoring eingebunden Grafana-Dashboards werden automatisch ausgerollt, müssen aber Stand jetzt noch manuell angelegt werden
- Johannes Several Clusters -> Data Security Request for Change Add stages to fulfill process requirements -> Testing, Informing customers
- Johannes + Jan im Wechsel * Script for creating a new customer * Rolling updates where possible * Sidecars automatically installed. Tagging for monitoring over customer configuration repository * Compliance checks in pipeline possible * Security updates automatically merged into customer repository
- Johannes + Jan im Wechsel