feature Dokumentation Git GitHub
This commit is contained in:
parent
75d2537476
commit
79c9d4a71a
|
|
@ -0,0 +1,86 @@
|
|||
# **Infrastruktur-Strategie zur DSGVO-Konformität für das Projekt "Meldestelle"**
|
||||
|
||||
Version: 1.0
|
||||
Datum: 17\. Oktober 2025
|
||||
Status: In Planung
|
||||
Ziel: Definition eines phasen basierten Ansatzes zur Entwicklung und zum Betrieb der "Meldestelle"-Anwendung, der von einer pragmatischen Entwicklungsphase zu einem vollständig DSGVO-konformen Produktionsbetrieb übergeht.
|
||||
|
||||
## **1\. Zusammenfassung & Zielsetzung**
|
||||
|
||||
Dieses Dokument beschreibt die zweistufige Strategie für die Infrastruktur des "Meldestelle"-Projekts. Ziel ist es, in der initialen Entwicklungs- und Testphase maximale Geschwindigkeit und Kosteneffizienz zu ermöglichen, während gleichzeitig ein klar definierter Pfad zur Erreichung vollständiger DSGVO-Konformität für den späteren Live-Betrieb sichergestellt wird.
|
||||
|
||||
Wir verfolgen einen pragmatischen Ansatz, der den Aufwand und die Kosten in jeder Phase an die tatsächlichen Risiken und Anforderungen anpasst.
|
||||
|
||||
## **2\. Grundprinzipien**
|
||||
|
||||
* **Pragmatismus vor Dogmatismus:** In der Entwicklungsphase nutzen wir etablierte, effiziente Cloud-Dienste, auch wenn diese rechtliche Grauzonen aufweisen, solange das Risiko minimal ist (keine externen personenbezogenen Daten).
|
||||
* **Containerisierung als Schlüssel:** Die gesamte Anwendung und ihre Infrastruktur wird von Anfang an in Docker-Containern betrieben. Dies gewährleistet maximale Portabilität und macht den späteren Wechsel der Hosting-Umgebung trivial.
|
||||
* **Automatisierung als Ziel:** Eine CI/CD-Pipeline ist von Beginn an integraler Bestandteil, um manuelle Fehler zu reduzieren und den Deployment-Prozess zu standardisieren.
|
||||
* **Klare Trennlinie:** Es gibt einen klar definierten "Point of no Return": Bevor die erste Zeile personenbezogener Daten von Dritten verarbeitet wird, muss die Migration zu Phase 2 abgeschlossen sein.
|
||||
|
||||
## **3\. Phasenplan**
|
||||
|
||||
### **Phase 1: Entwicklungs- & Feldversuchs-Phase (MVP)**
|
||||
|
||||
**Ziel:** Schnelle Entwicklung, Implementierung von Kernfunktionen, Durchführung von Tests und ersten Feldversuchen in einer kontrollierten Umgebung.
|
||||
|
||||
**Dauer:** Von Projektbeginn bis zum Abschluss der Feldversuche und vor der Aufnahme von echten Nutzerdaten.
|
||||
|
||||
**Technologie-Stack:**
|
||||
|
||||
* **Code-Hosting:** **GitHub** (US-Anbieter)
|
||||
* *Begründung:* Exzellente Entwickler-Tools, Marktführer, nahtlose Integrationen.
|
||||
* **CI/CD-Pipeline:** **GitHub Actions**
|
||||
* *Begründung:* Perfekte Integration mit dem Code-Hosting. Der rechenintensive Build-Prozess wird auf leistungsstarke Server von GitHub ausgelagert, was den lokalen Heimserver schont.
|
||||
* **Hosting-Infrastruktur:** **Proxmox Heimserver** (Intel N100 Mini-PC)
|
||||
* *Begründung:* Kostengünstige, flexible und kontrollierte Umgebung für Entwicklung und Tests.
|
||||
* **Externer Zugriff:** **Cloudflare Tunnel**
|
||||
* *Begründung:* Bietet hochsicheren Zugriff auf den Heimserver ohne offene Ports, verbirgt die private IP-Adresse und ist einfach zu verwalten.
|
||||
|
||||
**DSGVO-Bewertung dieser Phase:**
|
||||
|
||||
* **Status:** **Nicht streng DSGVO-konform.**
|
||||
* **Risiko:** **Akzeptabel und kontrolliert.**
|
||||
* **Begründung:** Personenbezogene Daten (Name/E-Mail des Entwicklers in Git-Commits) werden an einen US-Anbieter (GitHub/Microsoft) übertragen. Da in dieser Phase keine externen oder sensiblen personenbezogenen Daten im Code oder den Systemen verarbeitet werden, wird dieses Restrisiko bewusst in Kauf genommen. Die rechtliche Grundlage bilden die Standardvertragsklauseln (SCCs) und das Trans-Atlantic Data Privacy Framework (TADPF).
|
||||
|
||||
### **Phase 2: Go-Live & Betrieb (Produktionsumgebung)**
|
||||
|
||||
**Ziel:** Bereitstellung der Anwendung für die Öffentlichkeit in einer hochverfügbaren, sicheren und vollständig DSGVO-konformen Umgebung.
|
||||
|
||||
**Trigger für die Migration:** Der Abschluss der Feldversuche und die geplante Verarbeitung von personenbezogenen Daten von echten Nutzern.
|
||||
|
||||
**Technologie-Stack (Phase 2 \- Go-Live & Betrieb):**
|
||||
|
||||
* **Hosting-Infrastruktur:** **Virtual Private Server (VPS) bei einem EU-Anbieter** (z.B. Hetzner, Standort Deutschland).
|
||||
* *Begründung:* Gewährleistet, dass alle Daten und Prozesse die EU physisch nicht verlassen (Datenhoheit). Bietet professionelle Performance und Zuverlässigkeit.
|
||||
* **Code-Hosting & CI/CD:** **Self-hosted Forgejo**, installiert auf dem VPS.
|
||||
* *Begründung:* Forgejo ist eine leichtgewichtige, von der Community betriebene Open-Source-Alternative. Es bietet Git-Hosting und ein integriertes CI/CD-System (Forgejo Actions), das mit GitHub Actions kompatibel ist. Der gesamte Lebenszyklus des Codes (Speicherung, Bau, Test) findet auf dem eigenen Server in Deutschland statt.
|
||||
* **Container Registry:** Die in Forgejo integrierte Container Registry.
|
||||
* *Begründung:* Hält auch die fertigen Docker-Images innerhalb der eigenen, konformen Infrastruktur.
|
||||
* **Externer Zugriff:** Standard-Reverse-Proxy (z.B. Traefik oder Nginx) direkt auf dem VPS.
|
||||
* *Begründung:* Der Server hat eine öffentliche IP, ein Tunnel ist nicht mehr nötig. Der Proxy steuert den Zugriff auf die Anwendungs-Container.
|
||||
|
||||
### **DSGVO-Bewertung (Phase 2\)**
|
||||
|
||||
* **Status:** **Vollständig DSGVO-konform.**
|
||||
* **Risiko:** **Minimal.**
|
||||
* **Begründung:** Der gesamte Datenverarbeitungsprozess – von der Codezeile in **Forgejo**, über den Build-Prozess durch **Forgejo Actions**, bis zur laufenden Anwendung und den Nutzerdaten in der Datenbank – findet ausschließlich auf Servern in Deutschland unter eigener Kontrolle statt.
|
||||
|
||||
### **4\. Migrationsschritte von Phase 1 zu Phase 2**
|
||||
|
||||
1. **Infrastruktur aufsetzen:** Einen geeigneten VPS bei Hetzner mieten und mit einem schlanken Debian-System grundlegend absichern.
|
||||
2. **Forgejo installieren:** Forgejo als Docker-Container auf dem neuen VPS installieren und konfigurieren.
|
||||
3. **Code migrieren:** Das "Meldestelle"-Repository von GitHub auf die eigene Forgejo-Instanz spiegeln/umziehen.
|
||||
4. **Pipeline adaptieren:** Die GitHub Actions-Workflows in die Forgejo Actions-Konfiguration überführen. **Da Forgejo Actions weitgehend mit GitHub Actions kompatibel ist, ist dieser Schritt deutlich einfacher als eine vollständige Portierung zu einem anderen System.**
|
||||
5. **Anwendung deployen:** Die CI/CD-Pipeline in Forgejo erstmals ausführen, um die "Meldestelle"-Anwendung (Docker-Container) auf dem VPS zu deployen.
|
||||
6. **DNS-Umschaltung:** Die DNS-Einträge für mo-code.at (und Subdomains) bei Cloudflare vom Tunnel auf die neue, feste IP-Adresse des Hetzner-Servers umstellen.
|
||||
7. **Decommissioning:** Nach erfolgreichem Testbetrieb den Cloudflare Tunnel und die alten GitHub-Workflows deaktivieren.
|
||||
|
||||
## **5\. Zeit- und Kostenschätzung**
|
||||
|
||||
* **Phase 1:**
|
||||
* **Kosten:** Minimal (Stromkosten für Heimserver). Die genutzten Dienste (GitHub, Cloudflare) sind im Rahmen des Projekts kostenlos.
|
||||
* **Zeitaufwand:** Fokus liegt zu 100% auf der Anwendungsentwicklung.
|
||||
* **Phase 2:**
|
||||
* **Kosten:** Monatliche Gebühren für den VPS (ca. 15-30 €/Monat, je nach Größe).
|
||||
* **Zeitaufwand:** Für die Migration von Phase 1 zu 2 sollte ein dediziertes Zeitfenster von **ca. 1-2 Wochen** eingeplant werden, um alle Schritte sorgfältig durchzuführen und zu testen.
|
||||
|
|
@ -19,22 +19,22 @@ Wir benötigten eine Lösung, die die Client-Service-Kommunikation vereinfachen
|
|||
|
||||
## Entscheidung
|
||||
|
||||
Wir haben uns entschieden, das API-Gateway-Muster mit Ktor als Framework zu implementieren. Das API-Gateway dient als einziger Eingangspunkt für alle Client-Anfragen und bietet die folgenden Funktionen:
|
||||
Wir haben uns entschieden, das API-Gateway-Muster mit Spring Cloud Gateway (Spring Boot) zu implementieren. Das API-Gateway dient als einziger Eingangspunkt für alle Client-Anfragen und bietet die folgenden Funktionen:
|
||||
|
||||
1. **Anfrage-Routing**: Leitet Anfragen an die entsprechenden Microservices weiter
|
||||
2. **Authentifizierung und Autorisierung**: Integriert sich mit Keycloak ([ADR-0006](0006-authentication-authorization-keycloak-de.md)), um Benutzer zu authentifizieren und Tokens zu validieren
|
||||
3. **Rate-Limiting**: Verhindert Missbrauch durch Begrenzung der Anzahl von Anfragen von einem einzelnen Client
|
||||
4. **Anfrage/Antwort-Transformation**: Transformiert Anfragen und Antworten nach Bedarf für verschiedene Clients
|
||||
5. **Logging und Monitoring**: Bietet zentralisiertes Logging und Monitoring aller API-Anfragen
|
||||
6. **Caching**: Speichert Antworten im Cache, um die Leistung zu verbessern
|
||||
7. **API-Dokumentation**: Hostet OpenAPI-Dokumentation für alle Dienste
|
||||
8. **Service-Discovery**: Entdeckt Dienstinstanzen dynamisch
|
||||
1. **Anfrage-Routing**: Deklaratives Routing auf Basis von Prädikaten und Filtern
|
||||
2. **Authentifizierung und Autorisierung**: Integration mit Keycloak ([ADR-0006](0006-authentication-authorization-keycloak-de.md)), Validierung über JWKs; Kontext-Propagation zu Backends
|
||||
3. **Rate-Limiting**: Token-Bucket/Burst-Limits via Gateway-Filter (optional Redis-gestützt)
|
||||
4. **Anfrage/Antwort-Transformation**: Manipulation von Headern/Body per Global/Gateway-Filtern
|
||||
5. **Logging und Monitoring**: Micrometer/Prometheus, strukturierte Logs, verteiltes Tracing
|
||||
6. **Caching**: Selektiv per Downstream oder Reverse-Proxy; Gateway-seitig per Filter möglich
|
||||
7. **API-Dokumentation**: Aggregation/Weiterleitung von OpenAPI-Dokumentation
|
||||
8. **Service-Discovery**: Integration mit Consul/Eureka
|
||||
|
||||
Unsere Implementierung umfasst:
|
||||
- Ein Ktor-basiertes API-Gateway, das als containerisierter Dienst bereitgestellt wird
|
||||
- Eine Spring-Cloud-Gateway-Applikation (Spring Boot), containerisiert
|
||||
- Integration mit Keycloak für Authentifizierung und Autorisierung
|
||||
- Benutzerdefinierte Plugins für Rate-Limiting, Logging und Monitoring
|
||||
- OpenAPI-Dokumentationsgenerierung
|
||||
- Benutzerdefinierte Global/Gateway-Filter für Rate-Limiting, Logging, Monitoring
|
||||
- Micrometer/Actuator für Metriken und Health
|
||||
- Service-Discovery-Integration
|
||||
|
||||
## Konsequenzen
|
||||
|
|
@ -74,8 +74,7 @@ Wir haben die Implementierung separater Backend for Frontend (BFF)-Dienste für
|
|||
Wir haben die Verwendung eines Service Mesh wie Istio oder Linkerd zur Handhabung der Service-zu-Service-Kommunikation in Betracht gezogen. Dies hätte viele der gleichen Vorteile für die Service-zu-Service-Kommunikation geboten, hätte aber die Herausforderungen der Client-zu-Service-Kommunikation nicht so effektiv adressiert.
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [API-Gateway-Muster](https://microservices.io/patterns/apigateway.html)
|
||||
- [Ktor-Dokumentation](https://ktor.io/docs/)
|
||||
- [Gateway-Routing-Muster](https://docs.microsoft.com/de-de/azure/architecture/patterns/gateway-routing)
|
||||
- [Backend for Frontend-Muster](https://samnewman.io/patterns/architectural/bff/)
|
||||
- https://spring.io/projects/spring-cloud-gateway
|
||||
- https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html
|
||||
- https://www.keycloak.org/documentation
|
||||
- https://microservices.io/patterns/apigateway.html
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ System_Boundary(meldestelle, "Meldestelle") {
|
|||
Container(desktopApp, "Desktop-Anwendung", "Kotlin, Compose Multiplatform", "Bietet eine umfangreiche Benutzeroberfläche für Administratoren und Veranstaltungsorganisatoren")
|
||||
Container(webApp, "Web-Anwendung", "Kotlin, Compose Multiplatform", "Bietet eine Weboberfläche für Mitglieder und Pferdebesitzer")
|
||||
|
||||
Container(apiGateway, "API-Gateway", "Kotlin, Ktor", "Leitet Anfragen an entsprechende Dienste weiter, verwaltet Authentifizierung und Autorisierung")
|
||||
Container(apiGateway, "API-Gateway", "Kotlin, Spring Cloud Gateway", "Leitet Anfragen an entsprechende Dienste weiter, verwaltet Authentifizierung und Autorisierung")
|
||||
|
||||
Container(masterdataService, "Stammdaten-Dienst", "Kotlin, Spring Boot", "Verwaltet Stammdaten wie Standorte, Disziplinen usw.")
|
||||
Container(membersService, "Mitglieder-Dienst", "Kotlin, Spring Boot", "Verwaltet Mitgliederregistrierung und -profile")
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user