Container-Migration für Legacy-Anwendungen: Docker und Kubernetes als Modernisierungsbrücke
Ihr Server heißt "web02" und steht seit 2016 im Rechenzentrum. Auf ihm läuft eine PHP-Anwendung, die niemand mehr neu aufsetzen könnte. Welche Pakete installiert sind, weiß nur der Server selbst. Der Kollege, der ihn eingerichtet hat, arbeitet inzwischen woanders. Wenn web02 stirbt, stirbt die Anwendung mit.
Eine Container-Migration für Legacy-Anwendungen ist für genau solche Fälle gedacht. Die Software bleibt, wie sie ist. Sie zieht nur um: aus dem historisch gewachsenen Server in einen Container, der sich jederzeit neu bauen lässt. Ein Container ist dabei ein abgeschlossenes Paket aus Anwendung, Laufzeitumgebung und allen Abhängigkeiten. Docker ist das bekannteste Werkzeug dafür.
Dieser Artikel erklärt, was eine Container Migration bei Legacy-Software leistet und was nicht. Und wie der Einstieg in der Praxis aussieht.
Was ein Container bei alter Software wirklich ändert
Heute lebt Ihre Anwendung auf einem Server, dessen Zustand sich über Jahre ergeben hat. Updates hier, ein manuell installiertes Modul da, eine Konfigurationsdatei, die jemand 2019 per Hand angepasst hat. Nichts davon steht in einem Dokument.
Bei einer Containerisierung schreiben Sie diesen Zustand auf. Das Dockerfile ist eine Textdatei mit allen Schritten: Welches Betriebssystem, welche PHP-Version, welche Erweiterungen, welche Konfiguration. Aus dieser Datei baut Docker den Container. Immer gleich, auf jedem Rechner.
Das hat drei praktische Folgen.
Erstens wird der Server austauschbar. Fällt web02 aus, starten Sie den Container auf einer anderen Maschine. Die Anwendung merkt keinen Unterschied.
Zweitens bekommen Entwickler eine echte Testumgebung. Bisher hieß es oft: "Auf meinem Rechner läuft es nicht, nur auf dem Server." Mit einem Container läuft auf dem Laptop dieselbe Umgebung wie in der Produktion. Fehler lassen sich reproduzieren, statt sie im laufenden Betrieb zu suchen.
Drittens wird das Deployment, also das Ausrollen einer neuen Version, zu einem wiederholbaren Schritt. Kein FTP-Upload mehr um 22 Uhr, bei dem man hofft, keine Datei vergessen zu haben.
Wichtig dabei: Der Code ändert sich nicht. Eine Legacy Software aus dem Jahr 2012 bleibt eine Legacy Software aus dem Jahr 2012. Sie läuft nur in einer Verpackung, die man versteht.
Was Containerisierung nicht löst
Hier wird oft zu viel versprochen. Ein Container macht Ihre Software nicht sicherer, nicht schneller und nicht moderner. Er macht sie reproduzierbar. Das ist viel wert, aber es ist nicht dasselbe.
Läuft die Anwendung auf PHP 5.6, läuft sie im Container weiterhin auf PHP 5.6. Die Sicherheitslücken dieser Version reisen mit. Ein Container schützt nicht vor einem Angriff über eine bekannte Schwachstelle im Code. Er begrenzt höchstens den Schaden, weil der Angreifer im Container landet und nicht direkt auf dem Server.
Auch die technischen Schulden im Code bleiben. Unlesbare Funktionen, fehlende Tests, hart verdrahtete Datenbank-Zugangsdaten: Das alles zieht mit um. Manchmal wird es sogar sichtbarer, weil das Dockerfile jeden Sonderfall ehrlich aufzählen muss.
Und dann ist da Kubernetes. Kubernetes verwaltet viele Container auf vielen Servern, verteilt Last und startet abgestürzte Container neu. Für eine einzelne Legacy-Anwendung mit ein paar hundert Nutzern ist das meistens zu viel Werkzeug. Der Betrieb eines Kubernetes-Clusters braucht eigenes Wissen und eigene Wartung. Wer diesen Aufwand nicht stemmen kann, tauscht ein undokumentiertes Problem gegen ein komplexes.
Unsere Empfehlung in den meisten Fällen: Erst Docker. Kubernetes nur dann, wenn es einen konkreten Grund gibt, etwa mehrere Anwendungen, die gemeinsam skalieren müssen.
Was passiert, wenn Sie nichts tun
Der Server web02 wird älter. Irgendwann läuft der Support für sein Betriebssystem aus. Der Hoster kündigt die Hardware-Generation ab. Dann müssen Sie umziehen, und zwar unter Zeitdruck.
Ein Umzug ohne Dokumentation ist ein Ratespiel. Man kopiert Dateien, installiert Pakete nach Gefühl und testet, bis es irgendwie läuft. Was dabei vergessen wird, fällt Wochen später auf. Der Export-Job, der nur nachts läuft. Das Modul für die PDF-Erzeugung, das eine bestimmte Schriftart braucht.
Wir haben solche Notfall-Umzüge begleitet. Sie kosten ein Vielfaches von dem, was eine geplante Containerisierung gekostet hätte. Und sie kosten Nerven, weil das Geschäft in dieser Zeit stillsteht.
So läuft eine Container-Migration in der Praxis
Der Ablauf ist bei fast allen Legacy-Anwendungen ähnlich. Er dauert je nach Größe zwischen zwei Tagen und drei Wochen.
Schritt 1: Den Server ausgraben
Zuerst schauen wir, was auf dem Server tatsächlich läuft. Welche Prozesse, welche Cron-Jobs, welche installierten Pakete, welche Umgebungsvariablen. Das ist Detektivarbeit. Oft finden sich Dinge, von denen niemand mehr wusste. Am Ende steht eine Liste, die zur Grundlage des Dockerfiles wird.
Schritt 2: Zustand von Code trennen
Ein Container soll jederzeit weggeworfen und neu gestartet werden können. Deshalb darf er keine Daten in sich speichern. Uploads, Logs, Session-Dateien und die Datenbank müssen nach außen. Das ist bei alter Software der aufwendigste Schritt. Viele Anwendungen schreiben munter in ihr eigenes Verzeichnis. Hier muss man Pfade anpassen oder Verzeichnisse per Volume nach außen leiten, also als dauerhaften Speicher außerhalb des Containers einbinden.
Schritt 3: Konfiguration herauslösen
Datenbank-Passwort, SMTP-Server, API-Schlüssel: In Legacy-Code stehen diese Werte oft direkt in einer PHP-Datei. Für den Container gehören sie in Umgebungsvariablen. Das ist eine kleine Codeänderung mit großer Wirkung. Dieselbe Container-Version läuft dann in Test und Produktion, nur mit anderen Werten.
Schritt 4: Bauen, testen, vergleichen
Jetzt wird der Container gebaut und neben dem alten Server gestartet. Wir vergleichen das Verhalten: Gleiche Seiten, gleiche Ausgaben, gleiche Cron-Ergebnisse. Erst wenn beide Systeme identisch reagieren, schalten wir um.
Schritt 5: Umschalten und alten Server behalten
Der Wechsel selbst dauert Minuten. Der alte Server bleibt danach noch einige Wochen erreichbar, als Rückfallebene. Danach wird er abgeschaltet. Dann hat web02 seinen Dienst getan.
Der Container als Brücke, nicht als Ziel
Der eigentliche Nutzen der Containerisierung zeigt sich danach. Sobald die Anwendung reproduzierbar läuft, werden weitere Schritte einfacher.
Ein PHP-Upgrade lässt sich im Container gefahrlos testen: Man ändert eine Zeile im Dockerfile, baut neu und sieht, was bricht. Neue Dienste lassen sich als eigene Container daneben stellen. Wer die Anwendung schrittweise ablösen will, findet im Strangler-Fig-Pattern einen passenden Weg. Dabei wachsen neue Komponenten neben der alten Anwendung, bis diese überflüssig wird. Container sind dafür die technische Grundlage.
Auch die Frage nach dem Hosting wird leichter. Ein Container läuft beim eigenen Hoster, in der Cloud oder bei einem Dienstleister, der Managed Hosting für Legacy-Projekte anbietet. Der Umzug zwischen diesen Optionen ist kein Projekt mehr, sondern ein Nachmittag.
Wer sich fragt, wo Containerisierung im Vergleich zu Neuentwicklung oder Refactoring steht, findet im Überblick der Modernisierungsstrategien eine Einordnung. Kurz gesagt: Sie ist der günstigste erste Schritt, weil sie das größte Risiko zuerst beseitigt, nämlich den Server, den keiner versteht.
Wann eine Container-Migration nicht passt
Es gibt Fälle, in denen wir abraten. Wenn die Anwendung in wenigen Monaten sowieso abgeschaltet wird, lohnt der Aufwand nicht. Manche Anwendungen sind tief mit dem Betriebssystem verwoben, etwa über Windows-Dienste oder Hardware-Zugriff. Dort wird die Containerisierung teuer und bringt wenig. Und wenn niemand die Container später betreiben kann, entsteht nur ein neues Wissensproblem.
In allen anderen Fällen ist die Container Migration für Legacy-Systeme eine solide Investition mit überschaubarem Risiko. Der Code bleibt unangetastet, die Anwendung läuft weiter, und Sie gewinnen die Kontrolle über Ihre Infrastruktur zurück.
Fazit: Erst verpacken, dann sanieren
Eine Container-Migration räumt nicht im Code auf. Sie sorgt dafür, dass Sie überhaupt gefahrlos aufräumen können. Wer seine Legacy-Anwendung in Docker verpackt, tauscht einen undokumentierten Server gegen eine Textdatei, die alles beschreibt. Das ist die Voraussetzung für jeden weiteren Modernisierungsschritt.
Wenn Ihre Anwendung noch auf einem Server läuft, den niemand neu aufsetzen könnte, sprechen Sie uns an. Wir schauen gemeinsam, ob Containerisierung der richtige erste Schritt ist und was er kostet. Das Erstgespräch ist kostenlos. Mehr zu unserem Vorgehen finden Sie auf der Seite Software-Modernisierung.
