Start/Projekte/Szenario Kubernetes

Szenario: Health-Tech von einem Server zu Kubernetes

Ein junges Health-Tech-Unternehmen betreibt sein Produkt auf einem einzelnen Server und spielt Releases von Hand ein. So würde ich es auf eine Plattform mit CI/CD, Releases ohne Ausfall und einem Monitoring über alles bringen. Das Vorgehen folgt den Mustern, mit denen ich die Plattform von Nun Pirat gebaut habe.

Ausgangslage

Das Produkt ist eine Web-Anwendung, mit der Praxen Termine und Befunde mit ihren Patientinnen und Patienten teilen. Sie besteht aus einer API, einem Web-Frontend und einem Dienst für Hintergrundaufgaben. Alles läuft auf einer virtuellen Maschine, deployed wird per SSH und Skript, meist abends. Bei jedem Release ist die Anwendung einige Minuten nicht erreichbar. Eine Testumgebung gibt es nicht, und die Logs liegen nur auf dem Server. Das Team hat sechs Entwicklerinnen und Entwickler und keine eigene Betriebsmannschaft. Mehrere größere Praxisverbünde wollen das Produkt einsetzen und fragen nach Verfügbarkeit und Nachweisen.

Was auf dem Spiel steht

Mit jedem neuen Kunden wird ein Ausfall teurer, und ein einzelner Server ist ein einzelner Ausfallpunkt. Releases am Abend binden genau die Leute, die tagsüber entwickeln sollen. Ohne Testumgebung landen Fehler direkt bei den Praxen. Und weil Gesundheitsdaten verarbeitet werden, wollen größere Kunden sehen, wer wann was geändert hat.

Vorgehen

1. Container

Jeder der drei Dienste bekommt ein Container-Image, das in der Pipeline gebaut wird. Konfiguration und Zugangsdaten kommen aus der Umgebung und stehen nicht mehr im Code. Lokal startet das Team alles mit einem Befehl.

2. Infrastructure as Code

Netze, Cluster, Datenbank, DNS und Zugriffsrechte beschreibe ich mit Terraform. Der anbieterspezifische Teil bleibt in einer eigenen, kleinen Schicht. Gehostet wird in einem Rechenzentrum in Deutschland.

3. Staging und Produktion

Aus demselben Code entstehen zwei Umgebungen, die sich nur in der Größe unterscheiden. Kubernetes lohnt sich hier, weil drei Dienste unabhängig voneinander skaliert und ausgerollt werden sollen und weitere absehbar sind. Für eine einzelne Anwendung würde ich bei Containern auf einem Server bleiben.

4. CI/CD mit Tests und Migrationen

Jede Änderung nimmt denselben Weg. Datenbankmigrationen laufen vor dem Rollout. Schlägt eine fehl, bleibt die laufende Version stehen.

5. Releases ohne Ausfall

Neue Versionen starten neben den alten. Erst wenn sie ihre Bereitschaft melden, bekommen sie Anfragen, und die alten werden nacheinander beendet. Releases können damit tagsüber laufen, und ein Rollback ist ein Schritt in der Pipeline.

6. Monitoring über alles

Alle Dienste senden Metriken, Logs und Traces über OpenTelemetry an einen Grafana-Stack. Jedes Signal trägt die Version, aus der es stammt. Wird die Anwendung langsamer, führt der Weg in wenigen Schritten zur Ursache.

7. Kosten und Kapazität

Nach einigen Wochen Betrieb sehe ich mir an, was die Plattform tatsächlich braucht. Ressourcen werden an die echte Last angepasst, und die Testumgebung läuft nur zu Arbeitszeiten. So bleiben die Kosten nachvollziehbar, auch wenn neue Kunden dazukommen.

Ergebnis, das ich anstreben würde

• Releases laufen tagsüber und ohne Ausfall, mehrmals pro Woche, wenn das Team es will.
• Fehler fallen auf Staging auf, bevor sie eine Praxis erreichen.
• Jede Änderung an Anwendung und Infrastruktur ist nachvollziehbar.
• Bei einer Störung zeigt das Monitoring Ursache und Version, ohne dass jemand auf dem Server nach Logs suchen muss.
• Das Team kann die Plattform nach der Übergabe selbst weiterführen.

Was es braucht

Vom Team braucht es eine Person, die die Plattform mit mir aufbaut und danach verantwortet, und Zeit, die bestehenden Tests in die Pipeline zu bringen. Zu entscheiden sind der Hosting-Anbieter und wie streng die Freigaben sein sollen. An Kosten fallen der Betrieb von zwei Umgebungen, der Monitoring-Stack und die Zeit für Aufbau und Übergabe an. Den genauen Rahmen klären wir im Erstgespräch.

Passende Leistung