333 lines
9.1 KiB
Markdown
333 lines
9.1 KiB
Markdown
### Schlachtplan für das 'infrastructure'-Modul
|
|
|
|
Basierend auf der Analyse des aktuellen Zustands (Stand: 11. Oktober 2025) habe ich einen strukturierten Aktionsplan erstellt. Die letzte größere Aktualisierung war im Juli 2025, seitdem gab es signifikante Änderungen am Gateway-Modul.
|
|
|
|
---
|
|
|
|
### 🔴 Phase 1: SOFORT (Diese Woche)
|
|
|
|
#### 1.1 Gateway-Tests reparieren (Höchste Priorität)
|
|
**Problem:** Tests sind komplett defekt - nur ~47% funktionieren noch (25/53 Tests).
|
|
|
|
**Aktionen:**
|
|
- ❌ **Löschen:** `JwtAuthenticationTests.kt` - testet nicht-existierende Custom-Filter
|
|
- ✅ **Behalten:** `FallbackControllerTests.kt`, `GatewayApplicationTests.kt`
|
|
- ✏️ **Überarbeiten:** `GatewayRoutingTests.kt`, `GatewaySecurityTests.kt`, `GatewayFiltersTests.kt`
|
|
- Option A: Tests mit MockJWT-Tokens ausstatten (siehe `TestSecurityConfig.kt`)
|
|
- Option B: Tests auf Public Paths verlegen (`/actuator/**`, `/fallback/**`)
|
|
- Option C: Security in Tests deaktivieren
|
|
|
|
**Warum jetzt:** Tests geben keine Sicherheit mehr - blockiert Entwicklung.
|
|
|
|
**Zeitaufwand:** 4-6 Stunden
|
|
|
|
---
|
|
|
|
#### 1.2 Gateway Build-Datei bereinigen
|
|
**Problem:** Duplizierte Dependency in `gateway/build.gradle.kts` (Zeile 33-34).
|
|
|
|
**Aktion:**
|
|
```kotlin
|
|
// ENTFERNEN: Zeile 34
|
|
implementation(project(":infrastructure:event-store:redis-event-store")) // ← Duplikat!
|
|
```
|
|
|
|
**Zeitaufwand:** 5 Minuten
|
|
|
|
---
|
|
|
|
### 🟡 Phase 2: KURZFRISTIG (Nächste 2 Wochen)
|
|
|
|
#### 2.1 Dependency-Versionen aktualisieren
|
|
**Problem:** Versionen von Juli 2025 - teilweise veraltet.
|
|
|
|
**Zu prüfen und aktualisieren:**
|
|
|
|
| Dependency | Aktuell | Latest (Okt 2025) | Priorität |
|
|
|------------|---------|-------------------|-----------|
|
|
| Spring Boot | 3.5.5 | 3.5.x | Mittel |
|
|
| Spring Cloud | 2025.0.0 | 2025.0.x | Mittel |
|
|
| Kotlin | 2.2.20 | 2.2.x | Niedrig |
|
|
| Keycloak | 26.0.7 | 26.x.x | Hoch |
|
|
| Testcontainers | 1.21.3 | 1.21.x | Niedrig |
|
|
| PostgreSQL Driver | 42.7.7 | 42.7.x | Niedrig |
|
|
|
|
**Aktion:**
|
|
1. `gradle/libs.versions.toml` aktualisieren
|
|
2. Tests nach jedem Update ausführen
|
|
3. Breaking Changes dokumentieren
|
|
|
|
**Zeitaufwand:** 1-2 Tage (mit Testing)
|
|
|
|
---
|
|
|
|
#### 2.2 Docker-Images aktualisieren
|
|
**Problem:** Einige Docker-Images sind möglicherweise veraltet.
|
|
|
|
**Zu prüfen:**
|
|
|
|
```yaml
|
|
# docker-compose.yml
|
|
postgres: 16-alpine # ✅ Aktuell (neueste: 16.x)
|
|
redis: 7-alpine # ✅ Aktuell
|
|
keycloak: 26.4.0 # ⚠️ Prüfen auf 26.x updates
|
|
consul: 1.15 # ⚠️ Prüfen (neueste: 1.20+)
|
|
kafka: 7.4.0 # ⚠️ Prüfen (neueste: 7.8+)
|
|
prometheus: v2.54.1 # ⚠️ Prüfen
|
|
grafana: 11.3.0 # ✅ Wahrscheinlich aktuell
|
|
```
|
|
|
|
**Aktion:**
|
|
1. Versions-Check durchführen
|
|
2. Schrittweise aktualisieren (einzeln testen!)
|
|
3. `.env`-Datei mit Versions-Variablen anlegen
|
|
|
|
**Zeitaufwand:** 3-4 Stunden
|
|
|
|
---
|
|
|
|
#### 2.3 Monitoring-Modul vervollständigen
|
|
**Problem:** Nur 3 Kotlin-Files - deutlich unterimplementiert im Vergleich zur Dokumentation.
|
|
|
|
**Dokumentiert aber fehlt:**
|
|
- Distributed Tracing (Zipkin) - Docker-Container fehlt!
|
|
- Custom Metrics Implementation
|
|
- Health Check Aggregation
|
|
- Alerting Rules Implementation
|
|
|
|
**Aktion:**
|
|
1. Zipkin zu `docker-compose.yml` hinzufügen
|
|
2. Tracing-Integration in Gateway testen
|
|
3. Custom Metrics-Library erstellen
|
|
4. Prometheus Alerting Rules konfigurieren
|
|
|
|
**Zeitaufwand:** 2-3 Tage
|
|
|
|
---
|
|
|
|
### 🟢 Phase 3: MITTELFRISTIG (Nächste 4-6 Wochen)
|
|
|
|
#### 3.1 Dokumentation aktualisieren
|
|
**Problem:** README von Juli 2025 - nicht mehr aktuell.
|
|
|
|
**Zu aktualisieren:**
|
|
|
|
**`README-INFRASTRUCTURE.md`:**
|
|
- Zeile 552: "Letzte Aktualisierung: 25. Juli 2025" → Oktober 2025
|
|
- Security-Sektion: OAuth2 Resource Server statt Custom JWT Filter
|
|
- Keycloak Version: 23.0 → 26.4.0
|
|
- Kafka Version: 7.5.0 → 7.4.0 (Downgrade dokumentieren!)
|
|
- Monitoring: Zipkin-Konfiguration ergänzen
|
|
|
|
**Neue Sections hinzufügen:**
|
|
- #### Bekannte Limitierungen
|
|
- #### Migration Notes (Juli → Oktober 2025)
|
|
- #### Troubleshooting erweitern
|
|
|
|
**Zeitaufwand:** 1 Tag
|
|
|
|
---
|
|
|
|
#### 3.2 Auth-Module überarbeiten
|
|
**Problem:** Vermutlich veraltet - Custom JWT vs. OAuth2 Resource Server Diskrepanz.
|
|
|
|
**Zu klären:**
|
|
- Werden `auth-client` und `auth-server` noch verwendet?
|
|
- Redundanz mit Gateway's OAuth2 Resource Server?
|
|
- Keycloak-Integration vereinheitlichen
|
|
|
|
**Aktion:**
|
|
1. Abhängigkeiten zu auth-Modulen analysieren
|
|
2. Entscheiden: Refactoring oder Deprecation
|
|
3. Wenn deprecated: Migration Path dokumentieren
|
|
|
|
**Zeitaufwand:** 3-5 Tage
|
|
|
|
---
|
|
|
|
#### 3.3 Cache-Module modernisieren
|
|
**Problem:** Redis 7 ist aktuell, aber Implementation-Patterns könnten veraltet sein.
|
|
|
|
**Zu prüfen:**
|
|
- Multi-Level Caching tatsächlich implementiert?
|
|
- Cache Statistics vorhanden?
|
|
- TTL Management korrekt?
|
|
- Integration mit Spring Cache Abstraction?
|
|
|
|
**Aktion:**
|
|
1. Cache-Tests erweitern
|
|
2. Performance-Metriken hinzufügen
|
|
3. Cache-Warming Strategy implementieren
|
|
|
|
**Zeitaufwand:** 2-3 Tage
|
|
|
|
---
|
|
|
|
#### 3.4 Event-Store Performance-Optimierung
|
|
**Problem:** Redis-basiert - für Production ggf. nicht optimal.
|
|
|
|
**Zu evaluieren:**
|
|
- Ist Redis der richtige Event Store für Production?
|
|
- Alternative: PostgreSQL mit Event Store Pattern?
|
|
- Snapshot-Strategie tatsächlich implementiert?
|
|
|
|
**Aktion:**
|
|
1. Performance-Tests durchführen
|
|
2. Event Store Benchmark (Redis vs. PostgreSQL)
|
|
3. Dokumentation aktualisieren mit Pros/Cons
|
|
|
|
**Zeitaufwand:** 1 Woche
|
|
|
|
---
|
|
|
|
### 🔵 Phase 4: LANGFRISTIG (Nächste 2-3 Monate)
|
|
|
|
#### 4.1 Service Mesh evaluieren
|
|
**Dokumentiert in "Zukünftige Erweiterungen"** - noch nicht implementiert.
|
|
|
|
**Optionen:**
|
|
- Istio (komplex, feature-reich)
|
|
- Linkerd (leichtgewichtig)
|
|
- Consul Connect (bereits Consul vorhanden!)
|
|
|
|
**Empfehlung:** Start mit Consul Connect - minimaler Overhead.
|
|
|
|
**Zeitaufwand:** 2-3 Wochen
|
|
|
|
---
|
|
|
|
#### 4.2 OpenTelemetry statt Zipkin
|
|
**Problem:** Zipkin ist veraltet - OpenTelemetry ist der moderne Standard.
|
|
|
|
**Migration Path:**
|
|
1. OpenTelemetry Collector aufsetzen
|
|
2. Spring Boot Auto-Instrumentation aktivieren
|
|
3. Zipkin als Backend behalten (kompatibel!)
|
|
4. Schrittweise migrieren
|
|
|
|
**Zeitaufwand:** 1-2 Wochen
|
|
|
|
---
|
|
|
|
#### 4.3 Security Hardening
|
|
**Aktuelle Gaps:**
|
|
- JWT Token Rotation nicht implementiert
|
|
- Rate Limiting nur dokumentiert, nicht konfiguriert
|
|
- Audit Logging fehlt
|
|
- HTTPS/TLS noch nicht erzwungen
|
|
|
|
**Aktion:**
|
|
1. Rate Limiting im Gateway aktivieren
|
|
2. Audit Log Framework implementieren
|
|
3. TLS für Service-zu-Service Kommunikation
|
|
4. Security Scan mit OWASP Dependency Check
|
|
|
|
**Zeitaufwand:** 2-3 Wochen
|
|
|
|
---
|
|
|
|
#### 4.4 Infrastructure as Code (IaC)
|
|
**Problem:** Nur Docker Compose - für Production nicht ausreichend.
|
|
|
|
**Zu erstellen:**
|
|
- Kubernetes Manifests (aktualisieren - Zeile 393+)
|
|
- Helm Charts (aktualisieren - Zeile 420+)
|
|
- Terraform für Cloud-Ressourcen
|
|
- CI/CD Pipelines
|
|
|
|
**Zeitaufwand:** 4-6 Wochen
|
|
|
|
---
|
|
|
|
### 📊 Priorisierungs-Matrix
|
|
|
|
| Phase | Aufgabe | Dringlichkeit | Aufwand | Impact |
|
|
|-------|---------|---------------|---------|--------|
|
|
| 1 | Gateway-Tests | 🔴 Sehr hoch | 4-6h | Hoch |
|
|
| 1 | Build-Datei | 🔴 Sehr hoch | 5min | Niedrig |
|
|
| 2 | Dependencies | 🟡 Hoch | 1-2d | Mittel |
|
|
| 2 | Docker-Images | 🟡 Hoch | 3-4h | Mittel |
|
|
| 2 | Monitoring | 🟡 Mittel | 2-3d | Hoch |
|
|
| 3 | Dokumentation | 🟢 Mittel | 1d | Mittel |
|
|
| 3 | Auth-Module | 🟢 Mittel | 3-5d | Hoch |
|
|
| 3 | Cache | 🟢 Niedrig | 2-3d | Mittel |
|
|
| 3 | Event-Store | 🟢 Niedrig | 1w | Mittel |
|
|
| 4 | Service Mesh | 🔵 Niedrig | 2-3w | Hoch |
|
|
| 4 | OpenTelemetry | 🔵 Niedrig | 1-2w | Mittel |
|
|
| 4 | Security | 🔵 Mittel | 2-3w | Hoch |
|
|
| 4 | IaC | 🔵 Niedrig | 4-6w | Hoch |
|
|
|
|
---
|
|
|
|
### 🎯 Empfohlene Reihenfolge
|
|
|
|
#### Woche 1-2:
|
|
1. Gateway-Tests reparieren
|
|
2. Build-Datei bereinigen
|
|
3. Dependencies aktualisieren
|
|
|
|
#### Woche 3-4:
|
|
4. Docker-Images aktualisieren
|
|
5. Monitoring vervollständigen
|
|
6. Dokumentation aktualisieren
|
|
|
|
#### Woche 5-8:
|
|
7. Auth-Module evaluieren/refactoren
|
|
8. Cache-Module modernisieren
|
|
9. Event-Store Performance-Tests
|
|
|
|
#### Monat 3-4:
|
|
10. Security Hardening
|
|
11. OpenTelemetry Migration
|
|
12. Service Mesh Evaluation
|
|
|
|
#### Monat 5-6:
|
|
13. Infrastructure as Code
|
|
14. Production Readiness Assessment
|
|
|
|
---
|
|
|
|
### 🛠️ Tooling-Empfehlungen
|
|
|
|
**Für Dependency-Management:**
|
|
- Renovate Bot oder Dependabot für automatische Updates
|
|
- `./gradlew dependencyUpdates` Plugin verwenden
|
|
|
|
**Für Security:**
|
|
- OWASP Dependency Check
|
|
- Trivy für Container-Scanning
|
|
- SonarQube für Code-Qualität
|
|
|
|
**Für Monitoring:**
|
|
- Grafana Dashboards aus Community importieren
|
|
- Prometheus Alertmanager konfigurieren
|
|
|
|
---
|
|
|
|
### 📝 Nächste Schritte
|
|
|
|
1. **Jetzt sofort:** Gateway-Tests fixen (blockiert alles andere)
|
|
2. **Diese Woche:** Dependencies updaten und testen
|
|
3. **Nächste Woche:** Sprint Planning für Phase 2
|
|
4. **Monatlich:** Review des Fortschritts und Reprioritisierung
|
|
|
|
---
|
|
|
|
### ⚠️ Risiken & Abhängigkeiten
|
|
|
|
**Kritische Pfade:**
|
|
- Gateway-Tests müssen ZUERST behoben werden
|
|
- Dependency-Updates können Breaking Changes haben
|
|
- Auth-Refactoring könnte alle Services betreffen
|
|
|
|
**Externe Abhängigkeiten:**
|
|
- Keycloak Breaking Changes bei Major Updates
|
|
- Spring Boot/Cloud Release Schedule beachten
|
|
- Kubernetes Cluster für IaC-Phase benötigt
|
|
|
|
---
|
|
|
|
**Geschätzter Gesamtaufwand:** 6-8 Wochen (bei 1 Vollzeit-Entwickler)
|
|
|
|
**Empfohlener Start:** Sofort mit Phase 1, dann iterativ durch die Phasen
|