Container, Cloud und Deployment

Ein Systementwurf ist erst dann etwas wert, wenn er zuverlässig in Betrieb geht – und immer wieder aktualisiert werden kann, ohne dass Nutzer darunter leiden. Früher waren Deployments seltene, nervenaufreibende Ereignisse am Wochenende. Heute rollen viele Teams mehrmals täglich neue Versionen aus, ohne dass es jemand bemerkt. Möglich machen das Container, automatisierte Pipelines und durchdachte Ausrollstrategien. Diese Lektion zeigt die Bausteine und hilft bei der Wahl des passenden Betriebsmodells.

1. Container

Das klassische Problem „bei mir funktioniert es“ entsteht, weil Entwicklungsrechner und Server sich unterscheiden: andere Versionen, andere Bibliotheken, andere Einstellungen. Container lösen das, indem alles, was die Anwendung braucht, in ein Image gepackt wird. Im Vergleich zu virtuellen Maschinen sind Container leicht: Sie starten in Sekunden und teilen sich den Kern des Betriebssystems. Erkunden Sie den Unterschied:

Konfiguration gehört dabei nicht ins Image. Datenbankadressen, Schlüssel und Einstellungen werden beim Start über Umgebungsvariablen oder einen Geheimnisspeicher übergeben. So läuft dasselbe Image im Test und in der Produktion, nur mit anderer Konfiguration – ein Grundsatz der Twelve-Factor-App.

2. Betriebsmodelle

Wo laufen die Container? Die Spanne reicht von Plattformdiensten, bei denen man nur den Code hochlädt, bis zu selbst betriebenen Kubernetes-Clustern. Plattformen wie Vercel, Render oder Fly.io übernehmen Server, Zertifikate, Skalierung und Rollouts. Ein eigener Server mit Docker und einem Verwaltungswerkzeug wie Coolify ist günstig und kontrollierbar, verlangt aber etwas mehr Betriebswissen. Kubernetes schließlich ist eine mächtige Plattform zur Orchestrierung vieler Container, die sich erst ab einer gewissen Größe lohnt. Ordnen Sie zu:

3. Die CI/CD-Pipeline

Continuous Integration und Continuous Delivery, kurz CI/CD, bezeichnen die Automatisierung des Weges vom Code bis zur Produktion. Jede Änderung durchläuft dieselben Stationen. Klicken Sie sich hindurch:

Der wichtigste Grundsatz: Das Image, das getestet wurde, ist genau das, das in Produktion geht. Es wird nicht neu gebaut, sondern nur mit anderer Konfiguration gestartet. Und jeder Schritt ist automatisiert und wiederholbar, sodass ein Deployment kein Ereignis mehr ist, sondern Routine.

4. Ausrollstrategien

Selbst mit guten Tests schlüpfen Fehler durch. Die Ausrollstrategie bestimmt, wie viele Nutzer ein Fehler trifft und wie schnell man zurückkommt. Probieren Sie die drei gängigen Strategien aus und schalten Sie einen Fehler hinzu:

Ergänzend nutzen viele Teams Feature Flags: Neue Funktionen werden ausgeliefert, aber erst per Schalter aktiviert – zunächst für das eigene Team, dann für einen Teil der Nutzer, dann für alle. So werden Auslieferung und Freischaltung getrennt, und eine fehlerhafte Funktion lässt sich abschalten, ohne ein neues Deployment.

5. Datenbankänderungen

Der heikelste Teil eines Deployments ist oft nicht der Code, sondern die Datenbank. Weil bei Rolling Updates und Canary-Releases alte und neue Version gleichzeitig laufen, müssen Änderungen am Schema mit beiden funktionieren. Bewährt hat sich das Vorgehen „erweitern, dann verkleinern“: Zuerst wird eine neue Spalte hinzugefügt, die alte bleibt. Dann schreibt der Code in beide, später liest er nur noch die neue. Erst in einem späteren Deployment wird die alte Spalte entfernt. So gibt es zu keinem Zeitpunkt eine Version, die mit dem Schema nicht zurechtkommt, und ein Zurückrollen bleibt jederzeit möglich.

6. Infrastruktur als Code

Server, Netzwerke, Datenbanken und Load Balancer werden heute ebenfalls als Code beschrieben, etwa mit Terraform, OpenTofu oder Pulumi. Das hat dieselben Vorteile wie beim Anwendungscode: Änderungen sind nachvollziehbar, werden geprüft und lassen sich wiederholen. Fällt eine Umgebung aus, kann sie aus dem Code neu aufgebaut werden. Für kleinere Projekte genügt oft eine gut dokumentierte Docker-Compose-Datei; wichtig ist nur, dass die Umgebung nicht aus vergessenen Handgriffen auf einem einzelnen Server besteht. Ein Fahrradverleih, dessen Buchungssystem nach einem Serverausfall in einer Stunde aus Code und Backup wiederhergestellt ist, erlebt einen ärgerlichen Vormittag – einer ohne diese Vorbereitung womöglich eine verlorene Woche.

7. Geheimnisse und Sicherheit im Deployment

Mit automatisierten Pipelines wächst auch die Verantwortung für Zugangsdaten. Die Pipeline braucht Zugriff auf die Registry, auf Server und manchmal auf Datenbanken – und ist damit ein lohnendes Ziel für Angreifer. Bewährt haben sich einige Regeln. Zugangsdaten liegen nie im Code oder im Image, sondern in einem Geheimnisspeicher der Plattform oder einem Dienst wie Vault. Jede Pipeline erhält nur die Rechte, die sie für ihren Schritt braucht. Kurzlebige Zugangstoken sind langlebigen Passwörtern vorzuziehen. Und Images werden auf bekannte Sicherheitslücken geprüft, bevor sie in Produktion gehen, denn ein Image enthält neben dem eigenen Code viele fremde Bibliotheken.

Zu einem sicheren Deployment gehört außerdem, dass man jederzeit weiß, welche Version gerade läuft. Jedes Image trägt eine eindeutige Kennung, die auf den Commit verweist, aus dem es gebaut wurde. Tritt ein Fehler auf, lässt sich so sofort nachvollziehen, welche Änderungen enthalten sind, und das vorherige Image kann ohne neuen Build wieder gestartet werden. Genau diese Möglichkeit, in Sekunden zur letzten funktionierenden Version zurückzukehren, macht häufige Deployments erst sicher. Wer weiß, dass ein Fehler schnell rückgängig zu machen ist, kann kleinere Änderungen öfter ausliefern – und kleinere Änderungen sind wiederum leichter zu prüfen und seltener fehlerhaft.

Studien zur Softwareauslieferung zeigen seit Jahren denselben Zusammenhang: Teams, die häufig und in kleinen Schritten ausliefern, haben nicht mehr, sondern weniger Ausfälle und beheben sie schneller. Tempo und Stabilität sind also kein Widerspruch, wenn die Pipeline gut gebaut ist. Für den Systementwurf heißt das: Die Frage, wie ein System ausgerollt und zurückgerollt wird, gehört von Anfang an dazu und nicht erst in die letzte Woche vor dem Start.

Für den Einstieg genügt oft eine einfache Pipeline: Tests bei jedem Pull Request, automatischer Build eines Images beim Zusammenführen und ein Deployment auf einen Server oder eine Plattform mit Health Checks. Staging, Canary-Releases und Feature Flags kommen dazu, wenn das System und das Team wachsen und die Folgen eines Fehlers größer werden.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.