Legacy-Code containerisieren – sicher weiterbetreiben

Was Containerisierung für Legacy bedeutet

Stellen Sie sich Ihre alte Software wie eine Maschine in einer Werkstatt vor. Die Maschine funktioniert. Aber die Werkstatt drum herum — das Betriebssystem, die Bibliotheken, die Laufzeitumgebung — verfällt. Irgendwann ist die Werkstatt so marode, dass es gefährlich wird, die Maschine weiter darin zu betreiben.

Containerisierung bedeutet: Sie packen die Maschine mitsamt ihrer eigenen kleinen Werkstatt in eine transportable Einheit. Diese Einheit läuft dann in einer neuen, modernen Halle — aber die Maschine selbst merkt davon nichts. Sie hat ihre gewohnte Umgebung um sich herum.

Technisch gesprochen: Ein Container enthält die Anwendung zusammen mit allem, was sie zum Laufen braucht. Die richtige PHP-Version, die passende Datenbank-Bibliothek, die Konfigurationsdateien. Das Ganze wird vom restlichen System isoliert. Es spielt keine Rolle mehr, welches Betriebssystem auf dem Server läuft — der Container bringt seine eigene Umgebung mit.

Für Sie als Unternehmer heißt das vor allem eines: Ihre bewährte Software muss nicht umgeschrieben werden, um sicher weiterbetrieben zu werden. Das ist ein entscheidender Unterschied zur Neuentwicklung. Die Geschäftslogik, die über Jahre im Code gewachsen ist, bleibt erhalten. Jede Sonderregel, jede Berechnung, jeder Ablauf — alles bleibt, wie es ist.

Gleichzeitig sinkt das Risiko. Der Container ist isoliert. Wenn der Server aktualisiert wird, bleibt die Software davon unberührt. Wenn eine andere Anwendung auf demselben Server Probleme macht, ist Ihre Software davon abgeschirmt. Das ist ein Gewinn an Stabilität, ohne dass Sie eine einzige Zeile Code ändern müssen.

Docker und Co.: Alten Code in moderne Umgebungen packen

Wenn von Containerisierung die Rede ist, fällt fast immer der Name Docker. Docker ist das verbreitetste Werkzeug, um Container zu erstellen und zu betreiben. Aber es geht nicht um das Werkzeug — es geht darum, was damit möglich wird.

Der Ablauf sieht im Kern so aus: Zunächst wird analysiert, was Ihre Software alles braucht. Welche Laufzeitumgebung, welche Bibliotheken, welche Dienste. Dann wird eine sogenannte Container-Definition geschrieben — eine Art Bauplan, der festlegt, wie die Umgebung aussehen muss. Daraus entsteht ein Container-Image: ein Paket, das alles enthält und sich auf jedem modernen Server starten lässt.

Lassen Sie uns das an einem konkreten Beispiel durchgehen.

Schritt für Schritt: Eine PHP-5-Anwendung in Docker kapseln

Eine häufige Situation in der Praxis: Eine Webanwendung wurde vor zehn oder fünfzehn Jahren in PHP 5 geschrieben. Sie läuft auf einem alten Debian-Server mit Apache und MySQL. Der Server bekommt keine Updates mehr. PHP 5 wird seit Jahren nicht mehr unterstützt. Aber die Anwendung funktioniert — und in ihr steckt die gesamte Auftragsabwicklung des Unternehmens.

So gehen wir vor:

1. Bestandsaufnahme: Wir erfassen, welche PHP-Version exakt im Einsatz ist, welche Erweiterungen geladen sind, welche Apache-Konfiguration vorliegt und welche MySQL-Version die Datenbank nutzt. Dazu prüfen wir, ob die Anwendung auf Dateisystemebene Besonderheiten hat — etwa Uploads, temporäre Dateien oder Log-Verzeichnisse.
2. Container-Definition erstellen: Wir schreiben eine Konfiguration, die genau diese Umgebung nachbaut. Ein Container für PHP und Apache, ein Container für MySQL. Beide kommunizieren über ein internes Netzwerk miteinander.
3. Daten separieren: Datenbank-Inhalte und hochgeladene Dateien werden außerhalb des Containers gespeichert. So bleibt der Container selbst austauschbar, während die Daten sicher liegen.
4. Test und Vergleich: Die Anwendung wird im Container gestartet und gegen den alten Server verglichen. Funktioniert die Anmeldung? Stimmen die Berechnungen? Werden Aufträge korrekt angelegt? Erst wenn alles passt, geht der Container in den Produktivbetrieb.
5. Umstellung: Der alte Server wird abgelöst. Die Anwendung läuft nun im Container auf einem aktuellen System — mit aktuellem Betriebssystem, aktuellen Sicherheitsupdates und professioneller Überwachung.

Das klingt nach einem Projekt, und das ist es auch. Aber es ist ein überschaubares Projekt. Kein Neubau, keine monatelange Entwicklung. In vielen Fällen ist die Umstellung in wenigen Wochen erledigt.

Betriebssystem-Abhängigkeiten kapseln

Einer der häufigsten Gründe, warum alte Software nicht einfach auf einen neuen Server umziehen kann, sind Abhängigkeiten zum Betriebssystem. Die Anwendung braucht eine bestimmte Version einer Bibliothek, die auf modernen Systemen nicht mehr verfügbar ist. Oder der Compiler, mit dem der Code übersetzt wurde, existiert für aktuelle Systeme nicht mehr.

In der Praxis sehen wir das regelmäßig:

• Software, die auf einer bestimmten Java-Version basiert, die seit Jahren abgekündigt ist
• Anwendungen, die 32-Bit-Bibliotheken brauchen, obwohl das Betriebssystem nur noch 64-Bit unterstützt
• Programme, die auf spezifische Windows-Dienste zugreifen, die in neueren Versionen entfernt wurden
• Datenbanktreiber, die nur mit einer alten OpenSSL-Version funktionieren

All das sind keine exotischen Sonderfälle. Es ist der normale Zustand von Software, die fünf, zehn oder fünfzehn Jahre im Einsatz ist. Und genau hier zeigt die Containerisierung ihre Stärke: Der Container bringt seine eigene Betriebssystemschicht mit. Er enthält genau die Bibliotheken, die die Anwendung braucht — in genau der richtigen Version.

Das Betriebssystem des Servers wird damit irrelevant für die Anwendung. Der Server kann auf dem neuesten Stand sein, mit allen Sicherheitsupdates. Die Anwendung im Container läuft trotzdem in ihrer gewohnten Umgebung. Beide Welten sind sauber voneinander getrennt.

Wichtig dabei: Die Isolation funktioniert nicht nur technisch, sondern auch organisatorisch. Wenn Ihre IT-Abteilung oder Ihr Hosting-Anbieter den Server aktualisiert, müssen Sie sich keine Sorgen machen, dass die alte Software plötzlich nicht mehr funktioniert. Der Container schützt sie davor.

Monitoring und Updates trotz alter Codebasis

Ein Container löst das Betriebssystem-Problem. Aber er löst nicht automatisch das Problem, dass niemand auf die Software aufpasst. Deshalb gehört zur Containerisierung immer auch ein Konzept für Überwachung und Pflege.

Überwachung bedeutet: Sie wissen jederzeit, ob die Software läuft. Sie werden informiert, wenn etwas ausfällt. Sie sehen, wenn der Speicher knapp wird oder die Datenbank langsam antwortet. Das klingt selbstverständlich, ist es bei vielen Altsystemen aber nicht. Oft läuft die Software einfach — bis sie es nicht mehr tut. Und dann beginnt die hektische Suche nach der Ursache.

Mit einem containerisierten System lässt sich das ändern:

• Verfügbarkeitsüberwachung: Automatische Prüfung, ob die Anwendung erreichbar ist und korrekt antwortet
• Ressourcen-Monitoring: Überwachung von Speicherverbrauch, CPU-Auslastung und Festplattenplatz
• Log-Auswertung: Fehler und Warnungen werden erfasst und können ausgewertet werden
• Automatischer Neustart: Wenn die Anwendung abstürzt, wird der Container automatisch neu gestartet

Und dann ist da die Frage der Updates. Der Code selbst wird in vielen Fällen nicht verändert — das ist ja gerade der Vorteil. Aber die Umgebung drum herum braucht Pflege. Sicherheitslücken in der Container-Plattform müssen geschlossen werden. SSL-Zertifikate müssen erneuert werden. Backup-Strategien müssen funktionieren.

All das ist bei einem containerisierten System deutlich einfacher als bei einer gewachsenen Installation auf einem alten Server. Der Container ist definiert und reproduzierbar. Wenn etwas schiefgeht, kann er in Minuten auf einem anderen System neu gestartet werden. Probieren Sie das mal mit einem Server, auf dem seit 2009 Software installiert und konfiguriert wurde.

Das ist ein Aspekt, den viele unterschätzen: Containerisierung macht Ihre alte Software nicht nur lauffähig auf neuen Systemen. Sie macht den gesamten Betrieb professioneller. Und damit auch sicherer.

Grenzen der Containerisierung

Jetzt wird es konkret. Containerisierung ist kein Allheilmittel. Es gibt Situationen, in denen sie nicht funktioniert oder nicht ausreicht. Das sagen wir lieber vorher als nachher.

Windows-Desktop-Anwendungen: Wenn Ihre Software eine klassische Windows-Oberfläche hat — also ein Programm, das auf dem PC installiert ist und mit Fenstern, Menüs und Dialogen arbeitet — ist Docker nicht das richtige Werkzeug. Container sind für Serveranwendungen und Hintergrunddienste gedacht, nicht für Desktop-Programme mit grafischer Oberfläche. Es gibt Ansätze, aber sie sind komplex und oft nicht praxistauglich.

Hardwaregebundene Software: Wenn die Anwendung direkt auf spezielle Hardware zugreift — etwa auf einen Dongle, einen Kartenleser oder eine Maschinensteuerung — wird es schwierig. Container abstrahieren die Hardware. Was direkt angeschlossen sein muss, lässt sich nicht ohne Weiteres virtualisieren.

Tiefgreifende Sicherheitsprobleme im Code: Ein Container isoliert die Software vom Rest des Systems. Aber wenn die Software selbst Sicherheitslücken hat — etwa eine SQL-Injection oder eine offene Schnittstelle ohne Authentifizierung — dann bleiben diese Lücken bestehen. Der Container schützt den Server, nicht die Anwendung selbst.

Wenn sich die Anforderungen grundlegend ändern: Containerisierung bewahrt den Status quo. Wenn Sie aber nicht nur den Betrieb sichern, sondern grundlegend neue Funktionen brauchen — ein neues Datenmodell, eine komplett andere Benutzeroberfläche, eine Umstellung der Geschäftslogik — dann reicht Containerisierung allein nicht. Dann brauchen Sie jemanden, der den Code versteht und gezielt portieren kann. Oder es ist tatsächlich Zeit für einen Neuanfang.

Lizenzprobleme: Manche Softwarekomponenten sind an bestimmte Server oder Installationen lizenziert. Wenn Sie die Software in einen Container verlagern, kann das lizenzrechtliche Fragen aufwerfen. Das muss vorab geklärt werden.

Die gute Nachricht: In vielen Fällen sind diese Grenzen kein Showstopper. Oft lässt sich Containerisierung mit gezielten Anpassungen kombinieren. Zum Beispiel: Die Kernanwendung wird containerisiert, und gleichzeitig wird eine neue Schnittstelle angebaut, die eine aktuelle Anforderung abdeckt. Das ist pragmatisch und wirtschaftlich sinnvoll.

Entscheidend ist die gründliche Analyse am Anfang. Nicht jedes Problem lässt sich mit einem Container lösen. Aber erstaunlich viele schon.