Pipeline-Architektur
Die Deployment-Pipeline folgt einem mehrstufigen Orchestrierungsmuster, ausgelöst durch Bamboo CI/CD:
Deployment-Ablauf
- CI/CD-Trigger — Orchestrierungsscript empfängt Umgebungsparameter (QA, Dev, Staging, Test, Production)
- Repository-Synchronisation — Git Pull des Ansible-Repositorys für aktuelle Playbooks
- Monitoring-Pause — Uptime-Monitoring-API pausiert Prüfungen während des Deployment-Fensters
- VM-Bereitstellung — Python API-Client verwaltet den VM-Lebenszyklus: Starten, Stoppen, Klonen, Snapshot
- Health Checks — Warten auf SSH- (Linux) und RDP-Verfügbarkeit (Windows) vor dem Fortfahren
- Snapshot-Wiederherstellung — Hyper-V Snapshot-Wiederherstellung für einen sauberen Umgebungszustand
- Linux-Konfiguration — Ansible Playbooks konfigurieren Elasticsearch, Redis, RabbitMQ, HAProxy
- Windows-Konfiguration — Ansible Playbooks deployen Applikations-Dienste, Rendering-Engines, Monitoring-Agenten
- Kundenbereitstellung — Automatisierte Mandanten-Erstellung mit umgebungsspezifischen Anmeldedaten
- Testausführung — xUnit Test Runner mit automatisierter Testdatengenerierung
- Ergebnissammlung — Testergebnisse werden aggregiert und an die CI/CD-Plattform zurückgemeldet
- Metriken-Push — Deployment-Zeitdaten werden via Netcat an Graphite für Grafana-Dashboards gesendet
- Monitoring-Wiederaufnahme — Uptime-Monitoring wird wieder aktiviert
Umgebungstopologie
Jede Deployment-Umgebung betreibt eine mehrstufige Architektur:
| Schicht | Komponenten | Technologie |
|---|---|---|
| Load Balancer | HAProxy + Keepalived | VRRP-basierte HA, SSL-Terminierung |
| Anwendung | Plattform-Dienste (11+ Microservices) | Windows, IIS |
| Suche | Elasticsearch-Cluster (3+ Knoten) | Kibana zur Visualisierung |
| Cache | Redis-Instanzen | Mehrere Datenbanken pro Umgebung |
| Messaging | RabbitMQ | Multi-Node-Cluster |
| Workflow | Apache Camunda | BPMN-Prozess-Engine |
| Logging | ELK Stack | Filebeat, Metricbeat, Winlogbeat, Heartbeat |
| Monitoring | Nagios NRPE | Remote Health Checks |
| Speicher | Samba/CIFS | Dateifreigabe und Asset-Speicherung |
Umgebungen
| Umgebung | Zweck | Instanzen |
|---|---|---|
| QA (x5) | Paralleles QA-Testing | 5 isolierte Umgebungen |
| Development | Entwicklung | Einzelinstanz |
| Test | Load-Balanced Testing | Dual-Instanz mit Pool-Zuweisung |
| Staging | Staging | Multi-Mandant-Kundenkonfigurationen |
| Production | Produktion | Cloud-Produktion |
Ansible-Architektur
Die Infrastruktur ist als geschichtete Ansible-Codebasis organisiert:
- Inventories — Hostdefinitionen pro Umgebung
- Group Variables — Umgebungsspezifische Konfiguration (Ports, Anmeldedaten, Feature Flags)
- Roles (30+) — Wiederverwendbare Infrastrukturkomponenten (Elasticsearch, Redis, HAProxy, Applikations-Services, etc.)
- Playbooks — Orchestrierung durch Kombination von Roles für jede Umgebung
- Vault — Verschlüsselte Geheimnisse (SSL-Zertifikate, Anmeldedaten, Kerberos Keytabs)
Ausführungskonfiguration
- Forks: 50 (parallele Ansible-Ausführung über Hosts hinweg)
- Transport: SSH (Linux), WinRM über HTTPS (Windows)
- Secrets: Ansible Vault verschlüsselte Dateien
- Inventory: Statische Dateien mit umgebungsspezifischen Group Variables