Kubernetes und Betrieb
Die Next-Anwendung wird im Kubernetes-Cluster betrieben. Frontend, Backend und Datenbank werden als getrennte Workloads und Services modelliert.
Frontend-Workload
Das kompilierte Vue-Frontend besteht aus statischen HTML-, JavaScript-, CSS- und Bildressourcen. Ein kleiner Webserver liefert diese Dateien aus. Ein Kubernetes Service macht den Workload intern erreichbar; der Ingress stellt den externen HTTPS-Endpunkt bereit.
Umgebungsspezifische Werte wie Backend-URL und Keycloak-Konfiguration sollen kontrolliert zur Laufzeit oder beim Deployment bereitgestellt werden, ohne für jede Umgebung unterschiedliche Quellstände zu erzeugen.
Backend-Workload
Das Spring-Boot-Backend wird als unveränderliches OCI-Image ausgeliefert. Ein Kubernetes Deployment verwaltet die Backend-Pods. Der interne Service wird vom Frontend beziehungsweise vom Ingress erreicht.
Der Workload erhält:
- nicht vertrauliche Einstellungen aus ConfigMaps,
- Zugangsdaten und Client Secrets über den vorgesehenen Secret-Mechanismus,
- Datenbank- und Keycloak-Endpunkte über umgebungsspezifische Konfiguration,
- CPU- und Memory-Requests sowie Limits,
- Startup-, Readiness- und Liveness-Probes,
- eine Graceful-Shutdown-Konfiguration.
Der Container soll ohne privilegierte Rechte und möglichst mit schreibgeschütztem Root-Dateisystem laufen. Temporär benötigte Schreibbereiche werden explizit bereitgestellt.
Datenbank-Workload
Die Datenbank benötigt im Gegensatz zu Frontend und Backend dauerhaften Speicher. Im Zielbild wird sie als zustandsbehaftete Cluster-Komponente mit Persistent Volume betrieben. Die konkrete Bereitstellung kann je nach Plattformstandard durch einen Operator, ein StatefulSet oder eine vorhandene Datenbanklösung erfolgen.
Für den Betrieb müssen mindestens geregelt sein:
- persistenter Speicher und Kapazitätsplanung,
- Backup, Restore und Wiederanlauf,
- Updates der Datenbankversion,
- Netzwerkzugriff ausschließlich für berechtigte Workloads,
- sichere Bereitstellung von Zugangsdaten,
- Monitoring von Verbindungen, Speicher und Fehlern.
Flyway-Migrationen
Flyway wird kontrolliert im Deploymentablauf ausgeführt. Es muss verhindert werden, dass mehrere Backend-Pods konkurrierende oder unkontrollierte Migrationen beginnen.
Das konkrete Muster wird vor der Umsetzung festgelegt. Mögliche Varianten sind ein eigener Kubernetes Job vor dem Backend-Rollout oder eine eindeutig koordinierte Migration beim Anwendungsstart. Ein Fehler der Migration muss das Deployment stoppen und sichtbar machen.
Netzwerk und Ingress
Die externe Kommunikation erfolgt über einen Ingress mit TLS. Intern werden Kubernetes Services und DNS verwendet. Network Policies sollen die erlaubten Kommunikationswege begrenzen:
- Browser zu Frontend und Backend nur über den Ingress,
- Frontend-Auslieferung ohne direkten Datenbankzugriff,
- Backend zur Datenbank,
- Frontend und Backend zu Keycloak,
- Backend zu benötigten externen Diensten wie SMTP.
Delivery mit GitLab
GitLab CI erstellt und prüft die Artefakte von Frontend und Backend. Freigegebene Builds werden als eindeutig versionierte Container-Images in der internen Registry veröffentlicht.
Der Deploymentprozess soll:
- ein unveränderliches Release-Image auswählen,
- bei Bedarf die Flyway-Migration ausführen,
- Frontend und Backend kontrolliert ausrollen,
- den Kubernetes-Rolloutstatus sichtbar machen,
- eine geschützte Produktionsfreigabe verwenden,
- einen dokumentierten Rollback auf das vorherige Release ermöglichen.
Observability
Backend-Logs werden strukturiert nach Standardausgabe geschrieben und von der Clusterplattform eingesammelt. Spring Boot stellt Health- und Metrikendpunkte bereit. Für Frontend und Backend sollen mindestens technische Fehler, Startprobleme, Datenbankverbindungen und Authentifizierungsfehler diagnostizierbar sein.