Der Befehl war der einfache Teil
Ein neues Containerimage zu laden, ist meist schnell beschrieben. Schwieriger wird es, wenn Datenbanken, beschreibbare Verzeichnisse und voneinander abhängige Dienste beteiligt sind. Ein einheitlicher Knopf benötigt deshalb mehr Wissen als nur den Namen des Containers.
Mit KI-Unterstützung habe ich für meine Anlage einen geführten Updater entwickelt. Der Ausgangspunkt waren vorhandene Stacks und dokumentierte Wartungserfahrungen. Die KI half beim Entwurf, beim Programmieren und bei gezielten Prüfungen. Über die Freigabe entscheidet weiterhin der Benutzer.
Zuerst sichtbar machen, was sich ändern soll
Vor der Wartung zeigt eine Vorschau den betroffenen Stack und den vorgesehenen Stand. Vor dem Ausführen wird erneut geprüft, ob die zugrunde liegende Konfiguration noch passt. Damit führt eine alte Vorschau nicht unbemerkt eine inzwischen andere Änderung aus.
Nicht jede Anwendung darf denselben Ablauf verwenden. Verwaltungsdienste, Zugangswege und empfindliche Datenketten benötigen besondere Behandlung. Solche Ausnahmen müssen aus tatsächlichen Abhängigkeiten entstehen. Eine KI sollte fehlende Kenntnisse ausdrücklich benennen und nicht mit einer vermeintlich universellen Regel überdecken.
Die Sicherung gehört vor die Änderung
Zum Rückweg zählen die bisherige Konfiguration, passende Images und die benötigten Daten. Bei Datenbanken ist ein konsistenter Sicherungsweg erforderlich. Ein laufendes Dateiverzeichnis einfach zu kopieren, garantiert noch keinen verwendbaren Datenbankstand.
Mein Ablauf prüft Sicherungsartefakte vor dem Ausrollen, unter anderem auf Lesbarkeit und Prüfsummen. Solche Kontrollen erkennen bestimmte Fehler, ersetzen aber keine Wiederherstellungsprobe. Auch Platzbedarf und geschützte Ablage müssen vorher passen, damit das Update nicht erst nach dem Anhalten an einer fehlenden Sicherung scheitert.
Starten und funktionieren sind verschiedene Nachweise
Ein laufender Containerprozess belegt zunächst nur seinen Prozesszustand. Docker-Healthchecks können zusätzliche Bedingungen prüfen. Was sie tatsächlich belegen, hängt jedoch vom jeweiligen Prüfkommando ab. Eine erreichbare Startseite beweist beispielsweise nicht automatisch eine erfolgreiche Archivierung.
Die Startprüfung braucht außerdem realistische Zeiten. Manche Anwendungen benötigen nach einer Aktualisierung länger, etwa für interne Vorbereitungen. Die Reaktion sollte eine begründete Wartephase mit sichtbarem Fortschritt sein. Ein Fehler wird dadurch nicht stillschweigend zu Erfolg umbenannt.
Ein Autopilot braucht klare Grenzen
Nach ausdrücklicher Freigabe kann meine Wartungsreihe vorgesehene Stacks nacheinander bearbeiten. Fehler werden festgehalten; andere geeignete Einträge können weiterlaufen. Eine Abschlussmeldung nennt Erfolge und Punkte, die geprüft werden müssen.
Diese Fortsetzung ist nur sinnvoll, wenn die verbleibenden Aufgaben unabhängig ausführbar sind. Gemeinsame Zugangswege oder Abhängigkeiten verlangen eigene Sperren. Auch ein automatischer Rückweg ist nicht immer unbedenklich: Nach einer Datenmigration kann ein älteres Programm nicht ohne passende Datenrücksicherung eingesetzt werden.
Die Erkenntnis aus der Entwicklung
Die wertvollsten Prüfungen entstanden an konkreten Fehlerfällen: Eine Sicherung ist unvollständig, ein Dienst beendet sich nicht sauber oder eine Anmeldung läuft ab. Diese Fälle lassen sich zunächst isoliert nachstellen, bevor die eigene Anlage als Versuchsumgebung dienen muss.
KI beschleunigt das Schreiben und Überarbeiten solcher Abläufe. Verlässlichkeit entsteht durch nachvollziehbare Zustände, begrenzte Rechte und überprüfte Nachweise. Der praktische Gewinn ist ein verständlicher Wartungsprozess, bei dem vor und nach dem Update sichtbar bleibt, was tatsächlich geprüft wurde.