„Auf meinem Rechner funktioniert es“ beschreibt ein verbreitetes Problem der Softwareentwicklung. Lokal sind bestimmte Bibliotheken, Einstellungen und Werkzeuge vorhanden, auf dem Server dagegen andere. Container können helfen, diese Unterschiede zu verringern. Sie ersetzen jedoch weder ein Betriebskonzept noch die fachliche Prüfung einer Anwendung.

Docker ist eine verbreitete Plattform zum Erstellen und Ausführen von Containern. Für Unternehmen ist vor allem interessant, wie Anwendungen damit reproduzierbar bereitgestellt werden können. Die Entscheidung sollte sich an Wartbarkeit, Infrastruktur und Teamkenntnissen orientieren. Nicht jede kleine Website benötigt Container, und nicht jede containerisierte Anwendung ist automatisch skalierbar oder sicher.

Image und Container unterscheiden

Ein Image ist eine Vorlage mit den für eine Anwendung vorgesehenen Bestandteilen. Ein Container ist eine daraus gestartete laufende Instanz. Die offizielle Docker-Dokumentation beschreibt diesen Zusammenhang als Grundlage des Betriebsmodells. Mehrere Container können auf derselben Vorlage beruhen, ohne denselben Laufzeitzustand zu teilen.

Bei Linux-Containern werden Funktionen des Host-Kernels zur Abgrenzung von Prozessen verwendet. Das unterscheidet sie von einer vollständigen virtuellen Maschine mit eigenem Gastbetriebssystem. Auf anderen Entwicklungsplattformen kann dafür zusätzlich eine virtuelle Linux-Umgebung eingesetzt werden. Container bieten also eine Form der Isolation, aber nicht automatisch dieselbe Sicherheitsgrenze wie jede beliebige Virtualisierungslösung.

Die Anwendung nachvollziehbar bauen

Eine deklarierte Bauanleitung hält fest, welche Basis und Abhängigkeiten verwendet werden. Dadurch wird aus einer Folge manueller Installationsschritte ein wiederholbarer Prozess. Voraussetzung ist, dass die Eingaben ausreichend kontrolliert werden. Veränderliche Tags oder nicht festgelegte Abhängigkeiten können dazu führen, dass derselbe Bau später ein anderes Ergebnis erzeugt.

Für die Praxis sind nachvollziehbare Versionsstände und ein kontrollierter Build hilfreich. Ein erfolgreich gebautes Image sollte geprüft und anschließend möglichst unverändert in weitere Umgebungen übernommen werden. Wird für Produktion erneut unter anderen Bedingungen gebaut, kann die zuvor getestete Variante von der tatsächlich ausgelieferten abweichen. Reproduzierbarkeit muss deshalb im gesamten Ablauf betrachtet werden.

Konfiguration von der Vorlage trennen

Datenbankadresse, Mailserver und Umgebungseinstellungen unterscheiden sich zwischen Entwicklung und Produktion. Sie sollten nicht unbedacht in ein allgemein verwendetes Image eingebaut werden. Besonders Geheimnisse wie Kennwörter oder Zugriffstoken gehören in dafür vorgesehene, geschützte Bereitstellungsverfahren. Auch ein später gelöschtes Geheimnis kann in einer früheren Image-Schicht erhalten bleiben.

Die Anwendung muss außerdem mit fehlender oder falscher Konfiguration verständlich umgehen. Ein automatischer Start ist wenig hilfreich, wenn anschließend unbemerkt eine falsche Datenbank angesprochen wird. Für wichtige Einstellungen sind klare Prüfungen und getrennte Umgebungen sinnvoll. Produktionsdaten sollten nicht als bequeme Standardgrundlage einer lokalen Entwicklungsumgebung dienen.

Persistente Daten brauchen einen eigenen Plan

Der beschreibbare Zustand eines Containers ist nicht mit einem dauerhaften Datenspeicher gleichzusetzen. Docker stellt dafür unter anderem Volumes bereit. Ihre Daten können den Austausch eines Containers überdauern. Die offizielle Dokumentation beschreibt Volumes als unabhängig vom Lebenszyklus einzelner Container. Diese Eigenschaft bedeutet allerdings noch kein Backup.

Datenbank und hochgeladene Dateien benötigen weiterhin konsistente Sicherungen. Ein einfaches Kopieren während laufender Schreibvorgänge ist nicht für jede Datenbank geeignet. Je nach System werden spezielle Sicherungsverfahren oder koordinierte Zeitpunkte benötigt. Ebenso muss geprüft werden, ob wiederhergestellte Daten mit der verwendeten Anwendungsversion zusammenpassen.

Ein typischer Denkfehler

Ein fiktives Portal speichert Dokumente direkt im Container. Nach einem Update wird eine neue Instanz gestartet und die alte entfernt. Ohne vorgesehenen dauerhaften Speicher können die Dokumente fehlen. Der Fehler liegt nicht im Update selbst, sondern in einem unklaren Datenlebenszyklus. Vor der Einführung sollte deshalb jede Datenart einem Speicher- und Sicherungsverfahren zugeordnet werden.

Dienste gemeinsam betreiben

Eine Anwendung kann aus Webdienst, Datenbank und Hintergrundverarbeitung bestehen. Werkzeuge wie Docker Compose beschreiben, wie mehrere Dienste zusammen gestartet und verbunden werden. Das kann für überschaubare Umgebungen hilfreich sein. Eine solche Beschreibung muss dennoch Netzwerke, Speicher und Konfiguration bewusst festlegen.

Die Startreihenfolge allein garantiert nicht, dass ein Dienst bereits fachlich betriebsbereit ist. Eine Datenbank kann beispielsweise noch initialisieren. Anwendungen sollten vorübergehende Verbindungsprobleme berücksichtigen und einen kontrollierten Wiederanlauf ermöglichen. Ebenso ist zu unterscheiden, ob ein Prozess technisch läuft oder tatsächlich Anfragen korrekt beantwortet. Dafür werden geeignete Gesundheitsprüfungen benötigt.

Sicherheitsgrenzen bewusst setzen

Container sollten nur die Rechte erhalten, die sie benötigen. Unnötige privilegierte Ausführung, zusätzliche Hostzugriffe und frei zugängliche Verwaltungsendpunkte vergrößern Risiken. Die Docker-Verwaltungsschnittstelle ist besonders sensibel. Wer sie kontrolliert, kann je nach Konfiguration weitreichende Auswirkungen auf den Host haben.

Images und ihre Basis benötigen regelmäßige Aktualisierung. Auch Container enthalten Bibliotheken mit möglichen Sicherheitslücken. Die Verpackung beseitigt diese nicht. Herkunft, Abhängigkeiten und Prüfungen gehören deshalb in den Build- und Freigabeprozess. Ein kleinerer Umfang kann die Wartung erleichtern, ersetzt aber keine Bewertung der tatsächlich eingesetzten Komponenten.

Updates und Rückkehr organisieren

Ein Vorteil containerbasierter Bereitstellung kann der Austausch einer klar bezeichneten Anwendungsversion sein. Für einen Rückweg müssen die vorherige Vorlage und ihre Konfiguration verfügbar bleiben. Schwieriger wird es, wenn die neue Version zugleich Datenbankstrukturen verändert. Eine ältere Anwendung kann mit dem neuen Datenstand möglicherweise nicht mehr arbeiten.

Deshalb sollten Datenmigration und Anwendungswechsel gemeinsam geplant werden. Gegebenenfalls sind schrittweise kompatible Änderungen nötig. Ein Rückkehrverfahren muss fachlich getestet werden und berücksichtigen, welche neuen Daten seit dem Wechsel entstanden sind. Einfach das alte Image zu starten ist kein vollständiger Wiederherstellungsplan.

Betrieb bleibt sichtbar erforderlich

Protokolle, Ressourcenverbrauch und Speicherfüllstände müssen überwacht werden. Ein Neustartmechanismus kann eine ausgefallene Instanz erneut starten, aber keine fehlerhafte Bestellung korrigieren. Fehlermeldungen sollten mit Anwendungszustand und fachlichen Vorgängen in Verbindung gebracht werden können. Gleichzeitig sind vertrauliche Daten in Protokollen zu begrenzen.

Für einen Einstieg empfiehlt sich eine begrenzte Anwendung mit klar dokumentierten Abhängigkeiten. Das Team sollte Aufbau, Sicherung und Wiederherstellung eigenständig nachvollziehen können. Eine komplexe Orchestrierungsplattform ist nicht automatisch der nächste sinnvolle Schritt. Die Betriebsform muss zum tatsächlichen Bedarf und den verfügbaren Fähigkeiten passen.

Den ersten Containerwechsel bewusst üben

Vor dem produktiven Einsatz sollte eine Anwendung auf einer frischen Umgebung aus ihren dokumentierten Bestandteilen gestartet werden können. Damit wird geprüft, ob Abhängigkeiten wirklich beschrieben sind oder nur zufällig auf dem Entwicklungsrechner existieren. Der Test umfasst Konfiguration, Speicheranbindung und einen vollständigen fachlichen Vorgang.

Anschließend wird der Container ersetzt, während die vorgesehenen dauerhaften Daten erhalten bleiben. Dabei zeigt sich, ob Dateien am richtigen Ort liegen und ob Berechtigungen nach dem Wechsel weiterhin passen. Temporäre Daten dürfen verschwinden, verbindliche Geschäftsdaten dagegen nicht. Diese Trennung sollte auch für neue Teammitglieder verständlich dokumentiert sein.

Ein zweiter Test verwendet eine zuvor erstellte Sicherung auf einem getrennten Ziel. Die Anwendung muss mit dieser Kopie starten und die erwarteten Dokumente sowie Datenbeziehungen zeigen. Erst dann ist die Aussage belastbar, dass das Sicherungsverfahren zur containerisierten Anwendung passt. Ein erfolgreiches Archivieren eines Verzeichnisses allein genügt nicht.

Für die Übergabe werden Imagekennung, benötigte Konfiguration, Speicherorte und Prüfablauf festgehalten. Damit bleibt der Betrieb nachvollziehbar, wenn die ursprüngliche Entwicklungsumgebung nicht mehr existiert. Container entfalten ihren Nutzen besonders dann, wenn diese Wiederholbarkeit praktisch demonstriert und nicht nur als Eigenschaft des Werkzeugs angenommen wird.

Wann Container einen guten Beitrag leisten

Container sind besonders nützlich, wenn reproduzierbare Umgebungen und ein kontrollierter Bereitstellungsprozess benötigt werden. Ihre Vorteile entstehen zusammen mit festgelegten Abhängigkeiten, getrennten Daten und verantwortlichem Betrieb. Ohne diese Grundlagen verschiebt sich die Komplexität lediglich in andere Dateien und Werkzeuge.

GRITTMANN kann für individuelle Anwendungen prüfen, ob ein containerbasierter Betrieb sinnvoll ist. Dabei werden Hosting, Datenhaltung und Wartung gemeinsam betrachtet. Der Beitrag zur IT-Sicherheit im Mittelstand ergänzt die organisatorischen Grundlagen, die auch bei einer modernen Containerarchitektur erforderlich bleiben.

Quellen und weiterführende Dokumentation

Fachliche Grundlagen und ergänzende Hinweise der jeweiligen Herausgeber. Links zuletzt geprüft am 28.08.2026.