Downloaden Sie, um offline zu lesen
![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](https://image.slidesharecdn.com/approvedvonmanagedcloudzugitops-johannesdienstjankohlhaasaks-220202072106/85/Von-Managed-Cloud-zu-GitOps-Multi-Client-Cluster-Deployments-11-320.jpg)
![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](https://image.slidesharecdn.com/approvedvonmanagedcloudzugitops-johannesdienstjankohlhaasaks-220202072106/85/Von-Managed-Cloud-zu-GitOps-Multi-Client-Cluster-Deployments-12-320.jpg)
Hochgeladen vonJohannes Dienst
Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
Das Dokument behandelt die Entwicklung von Multi-Client-Cluster-Deployments unter Verwendung von GitOps und Terraform bei der DB Systel GmbH, wobei die erste Iteration durch Ansible und Managed Cloud ersetzt wurde. Es werden Anforderungen, Vorteile und Herausforderungen in den verschiedenen Iterationen beschrieben, einschließlich der Trennung von Kundenkonfigurationen und der Unterstützung von Compliance und Sicherheit. Die abschließenden Punkte umfassen die Vorteile der ausgezeichneten Kundenanbindung, einfache Updates und die Notwendigkeit eines zentralen Management-Tools.
Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments
- 1. Von Managed Cloudzu GitOps Multi Client-Cluster Deployments DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas
- 2. Digitalpartner der Deutschen Bahn DBSystel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 2
- 3. DB Content Hub DBSystel 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 DBSystel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 4 Icons made by Freepik, Good Ware, Sprang and Smashicons from www.flaticon.com
- 5. Anforderung: Physisch separierteKundencluster 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 DBSystel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 6
- 7. Anforderung: ISO 20000 DBSystel 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 DBSystel 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: PainPoints 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: CloudformationMonorepository + 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: Vorteileund 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: Terraformund 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: Terraformund 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 DBSystel 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: UnterschiedlicheUmgebungen 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: Terraformund Gitops DB Systel GmbH | Johannes Dienst @JohannesDienst | Jan Kohlhaas 19
- 20. Dritte Iteration: EinbindungMonitoring 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 SystelGmbH | 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
- #2 Johannes + Jan
- #3 Johannes
- #5 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
- #6 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
- #7 Johannes Nachvollziehbarkeit -> TODO Haben wir dazu eine interessante Story?
- #8 Johannes Beispiele was da drunter fällt -> Request for Change (MR) Release Notes Testing Planning Changes -> Centralized Tool
- #9 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
- #10 Johannes Beispiele was da drunter fällt -> Request for Change (MR) Release Notes Testing Planning Changes -> Centralized Tool
- #11 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
- #12 Johannes * First customer * Convenient and fast * Compliance is a problem -> What is deployed is not always declared in repository
- #13 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.
- #14 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
- #15 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
- #16 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
- #17 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
- #18 Jan
- #19 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
- #20 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
- #21 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
- #22 Johannes Several Clusters -> Data Security Request for Change Add stages to fulfill process requirements -> Testing, Informing customers
- #23 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
- #24 Johannes + Jan im Wechsel