Ein eigenes Containerimage löst manchmal ein konkretes Problem. Danach gehört allerdings auch dessen Pflege zum Betrieb: Basisimage beobachten, Pakete aktualisieren, Builds wiederholen und die Ergebnisse prüfen. Deshalb lohnt sich später die Frage, ob die ursprüngliche Ausnahme noch gebraucht wird.
Bei phpIPAM hatten wir vorübergehend eigene Web- und Cron-Images eingesetzt. Den Hintergrund beschreibt unser früherer Beitrag zum PHP-Sicherheitsupdate. Mit dem Wechsel auf phpIPAM 1.9.0 konnten wir diese Zwischenlösung durch die vom Projekt verlinkten Containerimages ersetzen. Die Docker-Images werden von der Community gepflegt; „offiziell“ bezeichnet hier den etablierten Projektlieferweg.
Interessant war dabei weniger das Ändern eines Imageverweises. Entscheidend waren die mitgebrachte Laufzeit, veränderte Dateipfade und die Abnahme nach dem Datenbankupgrade.
Vor dem Wechsel den tatsächlichen Stand erfassen
Eine Versionsnummer im Stack beschreibt den gewünschten Zustand. Ob der laufende Container diesem Zustand entspricht, ist eine weitere Prüfung.
Wir prüften die vorgesehenen Zielimages vor dem Einsatz und verglichen später den tatsächlich gestarteten Imageinhalt mit diesen Zielen. Zusätzlich kontrollierten wir die PHP-Laufzeit und das Webservermodul. Damit liess sich der Wechsel von zwei Seiten beurteilen: Welche Anwendung sollte starten, und welche Komponenten liefen tatsächlich?
Web und Cron betrachteten wir gemeinsam. Beide gehören zur Anwendung und benötigen einen zueinander passenden Stand. Den Datenbankserver aktualisierten wir bei diesem Schritt nicht zusätzlich. So blieb der Umfang der Änderung überschaubar.
Die vom phpIPAM-Projekt verlinkten Docker-Images bilden den Bezugspunkt für den Lieferweg. Die Verantwortung für die Prüfung der eigenen Installation bleibt trotzdem beim Betreiber.
Neue Software kann neue Containerpfade mitbringen
Die neue Version veränderte die Anwendungsstruktur. Für bestehende Installationen ist das relevant, weil zusätzliche Konfiguration oft unabhängig vom Image gespeichert wird.
Dabei gibt es zwei verschiedene Orte: die Quelldatei auf dem Host und den Zielpfad, unter dem sie im Container eingebunden wird. Eine Änderung am zweiten Ort verlangt nicht automatisch eine Verschiebung am ersten.
In unserem Fall blieben bestehende externe Konfigurationsdateien an ihrem Ablageort. Wir passten ihre Einbindung an die neue Struktur an. Auch die zusätzliche Webserverkonfiguration musste zum neuen Einstiegspunkt der Anwendung passen.
Ein frei gewähltes Schema zeigt den Zusammenhang:
Persistente Konfiguration
-> Einbindung am zur Version passenden Containerziel
-> Anwendung lädt die erwarteten EinstellungenWer nur das Image austauscht, kann solche Abhängigkeiten leicht übersehen. Ein Container startet möglicherweise trotzdem, während eine zusätzliche Konfiguration nicht mehr am erwarteten Ort liegt.
Anwendung und Datenbankschema gehören zusammen
Die Upgradeanleitung zu phpIPAM 1.9.0 behandelt neben den PHP-Anforderungen auch die Sicherung, die veränderte Anwendungsstruktur und das Datenbankupgrade. Das zeigt, weshalb ein Versionswechsel über den Containerstart hinausgeht.
Nach einer Schemaänderung ist das alte Image allein kein vollständiger Rückweg. Dazu gehört ein passender früherer Datenbank- und Konfigurationsstand. Eine alte Anwendung gegen eine bereits veränderte Datenbank zu starten, wäre eine zusätzliche, ungeprüfte Kombination.
Wir hielten deshalb den Vorzustand einschliesslich der ursprünglichen Images und Konfiguration fest. Das Datenbankupgrade gehörte zum dokumentierten Ablauf. Die Vorbereitung eines Rückwegs und dessen praktische Erprobung bleiben dabei unterschiedliche Aufgaben.
Die Anmeldung ist ein eigener Abnahmeschritt
Nach dem Wechsel liefen die Anwendungscontainer. Anschliessend folgten mehrere Kontrollen: Webserverkonfiguration prüfen, zusätzliche Einstellungen laden, vorhandene Anwendungsdaten aufrufen und die persönliche Anmeldung verwenden.
Gerade bei SAML lohnt sich diese Reihenfolge. Eine syntaktisch gültige Konfiguration sagt noch nicht, ob der vollständige Anmeldeablauf gelingt. Umgekehrt ersetzt ein sichtbarer Anmeldebildschirm keinen erfolgreichen Einstieg in die Anwendung.
Wir bestätigten sowohl den Zugriff auf vorhandene Subnetzdaten als auch die persönliche SAML-Anmeldung bis zur geladenen Oberfläche. Damit waren konkrete Benutzerwege geprüft. Für weitere Funktionen, etwa Hintergrundaufgaben oder Schreiboperationen, braucht es jeweils passende eigene Prüfungen.
Diese genaue Beschreibung hilft auch beim späteren Nachlesen: „Update erfolgreich“ wird durch nachvollziehbare Beobachtungen gestützt.
Erst nach der Abnahme gezielt aufräumen
Nach den Kontrollen entfernten wir ausgewählte alte Web- und Cron-Images sowie nicht mehr benötigte Basisimages. Der gesicherte Vorzustand blieb erhalten. Die Bereinigung betraf die zuvor bestimmten Images.
Docker unterscheidet zwischen Images, Containern, Volumes und weiteren Objekten. Die Docker-Dokumentation zur Bereinigung beschreibt diese getrennten Bereiche. Ein umfassender Bereinigungsbefehl kann daher einen deutlich grösseren Umfang haben als das Entfernen eines bekannten alten Images.
Auch die Speicheranzeige verlangt etwas Aufmerksamkeit: Images können Schichten gemeinsam nutzen. Die Summe ihrer angezeigten Grössen entspricht deshalb nicht automatisch dem Platz, der nach einer Löschung zusätzlich frei wird.
Eine Ausnahme braucht auch einen Abschluss
Das Sonderimage hatte seinen Zweck erfüllt. Der spätere Wechsel zurück zum etablierten Lieferweg reduzierte den eigenen Buildaufwand. Dafür mussten wir die neue Version als zusammenhängende Änderung behandeln: Imageinhalt, Dateieinbindungen, Datenbankschema und Benutzerzugriff.
Diese Erfahrung lässt sich auf andere Containeranwendungen übertragen. Eine vorübergehende Eigenlösung bekommt am besten schon bei ihrer Einführung ein Kriterium für den späteren Ausstieg. Sobald der reguläre Lieferweg die Anforderungen wieder erfüllt, lässt sich dieser Wechsel genauso sorgfältig planen wie die ursprüngliche Ausnahme.