Thema: deployment
-
Welche Regeln zur Image-Aufbewahrung halten eine Container-Registry klein, ohne noch eingesetzte Images zu löschen?
Offene Frage: Registrys sammeln per Garbage Collection nur Blobs ein, auf die kein Manifest mehr verweist, und Lifecycle-Regeln lassen Images nach Alter, Anzahl oder Tag-Muster ablaufen; welche Kombination von Regeln haben Teams über Jahre gefahren, ohne dass entweder unbegrenztes Wachstum entstand oder ein Rollback scheiterte, weil sein Image weg war?
-
Welche Rollout-Strategie funktioniert auf einem einzelnen Host mit Docker Compose und Reverse Proxy?
Offene Frage: Rollierend, Blue-Green und Canary sind für Orchestratoren beschrieben; viele kleine Dienste laufen aber auf einem Host mit Docker Compose hinter Traefik, nginx oder Caddy. Welche Nachbildung – zweiter Container mit umgeschalteter Proxy-Regel, gewichtete Verteilung, start-first – haben Teams über Monate betrieben, was hat sie gebrochen, und ab welcher Grösse lohnt sich der Orchestrator?
-
Tags und Releases: Lightweight- versus annotierte Tags und wie sie sich verbreiten
Ein Lightweight-Tag ist nur ein Name für einen Commit; ein annotierter Tag ist ein eigenes Objekt mit Tagger, Datum, Nachricht und optionaler Signatur – deshalb ignoriert git describe Lightweight-Tags standardmässig, und deshalb sollten Releases annotierte oder signierte Tags verwenden; Tags werden nicht zusammen mit Branches gepusht, ausser mit --follow-tags oder --tags, und ein veröffentlichter Tag sollte nie verschoben werden.
-
Geordnetes Herunterfahren: Umgang mit SIGTERM in Diensten
Container-Laufzeitumgebungen senden SIGTERM und warten eine Karenzzeit ab, bevor sie SIGKILL schicken; ein Dienst sollte keine neue Arbeit mehr annehmen, laufende Arbeit abschliessen oder zurückgeben, Verbindungen schliessen und innerhalb der Frist beenden. Wird das Signal ignoriert, wird aus jedem Deployment ein Ausfall.
-
Rollback vor dem Rollout entwerfen
Vor dem Deployment einen Wiederherstellungs-Entscheidungsbaum schreiben, der reversible Konfigurationsänderungen von Datenmigrationen unterscheidet, die einen Ausgleich brauchen.
-
Datenbankänderungen ohne Ausfall: Expand und Contract
Ein Schema in drei einzeln auslieferbaren Schritten ändern: erweitern (neue Spalte oder Tabelle anlegen, alte behalten), migrieren (doppelt schreiben und in Häppchen nachfüllen), zusammenziehen (Altes entfernen, sobald aller Code das Neue nutzt); lange Sperren vermeiden, indem keine Tabelle in einem Statement umgeschrieben wird und lock_timeout jede Wartezeit begrenzt.
-
Verhaltensänderungen als Canary vor dem Rollout testen
Eine begrenzte Kohorte einem neuen Verhalten aussetzen, mit einer Baseline vergleichen und anhand vorab festgelegter Abbruchbedingungen stoppen.
-
Nur-Lese-Wartungsmodus: Lesezugriffe bedienen, während Schreibzugriffe pausiert sind
Bei Speicherumzügen, Failovers und langen Migrationen kann ein Dienst weiterhin Lesezugriffe bedienen und Schreibzugriffe mit einer klaren Meldung verweigern, statt ganz auszufallen; PostgreSQLs default_transaction_read_only macht neue Transaktionen auf Datenbankebene als Rückfallebene schreibgeschützt, und HTTP 503 mit Retry-After sagt Clients, wann sie es erneut versuchen sollen. Der Modus braucht einen Schalter, eine für Nutzer sichtbare Meldung und eine Generalprobe.
-
Rolling-, Blue-Green- und Canary-Deployments im Vergleich
Rolling Updates ersetzen Instanzen schrittweise innerhalb von Grenzen für Surge und Nichtverfügbarkeit; Blue-Green betreibt den vollständigen neuen Stack neben dem alten und schaltet den Verkehr auf einmal um; Canary schickt einen kleinen Anteil des echten Verkehrs an die neue Version und befördert sie anhand von Evidenz. Die Wahl hängt von Kapazität, Geschwindigkeit des Rollbacks und davon ab, ob zwei Versionen gleichzeitig bedienen dürfen.
-
Die Twelve-Factor-App als Checkliste für Dienste
Die zwölf Faktoren beschreiben Konventionen für einsetzbare Dienste: eine Codebasis, deklarierte Abhängigkeiten, Konfiguration in der Umgebung, Backing Services als angehängte Ressourcen, strikte Trennung von Build, Release und Run, zustandslose Prozesse und Logs als Event-Streams.
-
Geheimnisse ausserhalb des Repositorys verwalten
Zugangsdaten gehören in geschützte, zur Laufzeit eingespielte Konfiguration, nie in die Versionsverwaltung, in Images oder in Logs; sie nach Zeitplan und bei Verdacht rotieren und jedem Dienst eigene geben.
-
Einen Build durch die Umgebungen befördern: Konfigurationsübernahme und Dev-Prod-Parität
Ein Artefakt einmal bauen, ihm eine unveränderliche Identität geben und genau dieses Artefakt von Test über Staging bis Produktion befördern, wobei sich nur die umgebungsspezifische Konfiguration ändert; Umgebungen bei Backing Services und Topologie angleichen, damit eine bestandene Stufe die nächste zuverlässig vorhersagt.
-
Schemamigrationen mit kurzem lock_timeout und automatischem Retry verursachen weniger Vorfälle beim Deployment als Migrationen ohne
Hypothese: Weil die meisten Formen von ALTER TABLE eine ACCESS-EXCLUSIVE-Sperre benötigen, die sich hinter jeder langen Transaktion einreiht und dabei jede spätere Abfrage blockiert, verursachen Migrationen, die mit einem lock_timeout von wenigen Sekunden und einer begrenzten Retry-Schleife ausgeführt werden, weniger und kürzere Ausfälle zur Deployment-Zeit als dieselben Migrationen mit der standardmässig unbegrenzten Wartezeit – auf Kosten einiger weniger Migrationen, die manuell erneut ausgeführt werden müssen.
-
Einen Service Worker sicher ausrollen: Scope, versionierte Caches, der wartende Worker und ein Notausschalter
Ein Service Worker, der HTML cacht, kann Nutzerinnen und Nutzer nach einem Deployment an alten Code binden. Ihn mit explizitem Scope registrieren, das Skript bei jeder Update-Prüfung frisch abrufen, Caches pro Build versionieren und alte beim Aktivieren löschen, Strategien pro Ressourcentyp wählen, entscheiden, wie der wartende Worker übernimmt, und vor dem ersten Release einen getesteten Notausschalter ausliefern.
-
Welche Vor-Deployment-Prüfungen haben im letzten Jahr tatsächlich ein schlechtes Release gestoppt, und welche haben nie ausgelöst?
Offene Frage: Pipelines sammeln im Lauf der Zeit Schranken an (Tests, Scans, Smoke-Checks, Canary-Analyse, manuelle Freigaben, Rollout-Fristen), und die Kubernetes-Dokumentation weist darauf hin, dass ein ins Stocken geratenes Deployment nur gemeldet, nicht zurückgerollt wird; welche Schranken haben nachweislich ein schlechtes Release gestoppt, welche haben nie ausgelöst, und welche nur falsch ausgelöst?
-
Feature-Toggles: Arten, Lebensdauer und Aufräumen
Toggles entkoppeln Deployment von Release, aber jedes Toggle ist ein Zweig im Code; sie nach Zweck klassifizieren (Release, Experiment, Betrieb, Berechtigung) und jedem einen Owner und ein Entfernungsdatum geben.
-
Schemaänderungen ohne Ausfallzeit mit Expand and Contract
Ein Schema in drei deploybaren Schritten ändern: Expand (die neue Spalte oder Tabelle hinzufügen, die alte behalten), Migrate (Dual-Write und Backfill in Stapeln), Contract (das Alte entfernen, sobald der gesamte Code das Neue verwendet); lange Sperren vermeiden, indem Tabellen nicht in einer einzigen Anweisung umgeschrieben werden.
-
Kleine, reproduzierbare Container-Images bauen
Basis-Images per Digest anheften, aus Lockfiles mit Hash-Prüfung installieren, nur das kopieren, was die Laufzeitumgebung braucht, als Nicht-Root-Nutzer laufen lassen, einen Health-Check ergänzen und Secrets aus Layern und Build-Argumenten heraushalten.
-
Container-Image-Tags versus Digests: veränderliche Namen und Inhaltsadressen
Ein Tag ist ein menschenlesbarer Zeiger, der jederzeit auf ein anderes Manifest umgehängt werden kann; ein Digest ist der Hash der Manifest-Bytes und identifiziert für immer genau ein Image. Nach Tag bauen und testen, nach Digest deployen und pinnen, und den Digest in jeder Release-Notiz festhalten.
-
Einen Dienst unter systemd betreiben
Eine Unit-Datei legt fest, wie ein Dienst startet, neu startet und eingegrenzt wird; Type, Restart=on-failure, Ressourcenlimits und Sandboxing-Direktiven verwenden und Logs mit journalctl lesen, statt eine eigene Daemonisierung zu schreiben.
Maschinenlesbar: JSON