Eine Anleitung fordert Sie auf, einen Dienst „einfach als Docker-Container zu starten“. Ihr NAS bietet eine Container-App an, oder ein heruntergeladenes Entwicklerprojekt enthält eine Datei namens docker-compose.yml. Was zunächst wie eine besondere Installationsform wirkt, ist ein eigenes Betriebsmodell: Die Anwendung wird nicht klassisch direkt auf dem vorhandenen System installiert, sondern zusammen mit ihren benötigten Bestandteilen in einer abgegrenzten Umgebung ausgeführt.
Docker ist eine Plattform, mit der Anwendungen in Containern bereitgestellt und ausgeführt werden können. Ein Container ist dabei keine vollständige virtuelle Maschine. Er enthält die Anwendung, ihre Bibliotheken, Abhängigkeiten und weitere Laufzeitbestandteile, nutzt aber grundsätzlich den Kernel seiner Laufzeitumgebung mit. Dadurch muss nicht für jeden Dienst ein komplettes Gastbetriebssystem gestartet werden.
Docker löst allerdings nicht automatisch Fragen zu dauerhaftem Speicher, Netzwerkzugriff, Updates oder Sicherheit. Damit ein Container zuverlässig funktioniert, müssen Sie vor allem Image und Container unterscheiden, die richtigen Datenpfade einbinden, Ports bewusst veröffentlichen und den Austausch des Containers einplanen.
Docker-Grundbegriffe: Image, Container und die Bausteine einer Anwendung
Das Image ist die Vorlage, der Container die Instanz
Ein Image ist ein schichtweise aufgebautes, unveränderliches Paket. Es enthält die Dateien, Programme, Bibliotheken und Startvorgaben, die Docker zum Erzeugen eines Containers benötigt. Das Image selbst ist noch kein laufender Dienst. Aus derselben Vorlage können mehrere voneinander unabhängige Container entstehen, etwa zwei Webserver mit unterschiedlichen Namen, Ports und Konfigurationen.
Der Container ist die aus dem Image erzeugte Instanz. Docker kann ihn starten, stoppen, erneut starten und entfernen. Zusätzlich zum unveränderten Image erhält jeder Container eine eigene beschreibbare Schicht. Dort landen Dateien und Änderungen, die nicht in einen separaten Speicher eingebunden wurden. Ein Stopp löscht diese Schicht nicht; erst beim Entfernen des Containers verschwindet sie.
Diese Trennung erklärt das typische Docker-Update: Statt eine Anwendung dauerhaft innerhalb des laufenden Containers umzubauen, laden oder bauen Sie ein neues Image und erzeugen daraus einen neuen Container. Dauerhafte Daten und bewusst ausgelagerte Konfigurationen werden anschließend wieder eingebunden.
Dockerfile, Registry und Docker Hub erfüllen verschiedene Aufgaben
Ein Dockerfile ist eine textbasierte Bauanweisung für ein Image. Darin stehen beispielsweise das Basis-Image, zu kopierende Dateien, zu installierende Abhängigkeiten, das Arbeitsverzeichnis und das Startkommando. Das Dockerfile beschreibt damit vor allem, wie ein Image entsteht. Es ist nicht mit einer Compose-Datei zu verwechseln, die festlegt, wie ein oder mehrere fertige Images ausgeführt werden.
Eine Registry speichert und verteilt Images. Docker Hub ist eine öffentliche Registry, die Docker standardmäßig verwendet; Unternehmen und Privatnutzer können jedoch andere öffentliche oder private Registries einsetzen. Docker ist außerdem nicht mit dem gesamten Containerkonzept gleichzusetzen: OCI-Spezifikationen standardisieren zentrale Image-, Verteilungs- und Laufzeitformate auch für andere Werkzeuge.
Volumes, Bind Mounts, Ports und Netzwerke bestimmen den Praxisbetrieb
Ein Volume ist von Docker verwalteter, persistenter Speicher. Seine Daten bestehen grundsätzlich unabhängig von einem einzelnen Container weiter. Entscheidend ist jedoch der Zielpfad: Das Volume muss genau an dem Verzeichnis eingebunden sein, in das die Anwendung Datenbanken, Uploads oder Einstellungen schreibt. Ein beliebiges vorhandenes Volume verhindert keinen Datenverlust.
Ein Bind Mount verbindet dagegen eine konkrete Datei oder ein Verzeichnis des Hosts direkt mit einem Pfad im Container. Das ist praktisch für Quellcode und bewusst verwaltete Konfigurationsdateien, bindet das Setup aber stärker an Pfade, Rechte und Betriebssystem des Hosts. Bind Mounts erlauben standardmäßig Schreibzugriff; unnötige Schreibrechte sollten Sie mit einer schreibgeschützten Einbindung vermeiden.
Ein Port-Mapping verbindet einen Port des Docker-Hosts mit einem Port im Container. Bei 8080:80 ist 8080 die Hostseite und 80 der interne Container-Port. Die Dockerfile-Anweisung EXPOSE dokumentiert lediglich einen vorgesehenen Port; sie veröffentlicht ihn nicht. Ohne angegebene Hostadresse können veröffentlichte Ports an allen Hostschnittstellen erreichbar sein. Für einen rein lokalen Testdienst ist eine Bindung wie 127.0.0.1:8080:80 meist enger begrenzt.
Docker-Netzwerke verbinden Container untereinander und trennen Dienstgruppen. In einem benutzerdefinierten oder von Compose erzeugten Netzwerk sprechen Container einander normalerweise über Dienst- oder Containernamen an. localhost bezeichnet innerhalb eines Containers den Container selbst – nicht automatisch den Docker-Host, eine Datenbank in einem Nachbarcontainer oder einen anderen Dienst.
Environment Variables, Compose, Stack und Logs ordnen die Laufzeit
Environment Variables übergeben Laufzeitwerte wie Betriebsmodus, Datenbankadresse oder Anwendungsoptionen. Schreibfehler, leere Werte und Überschreibungen können dazu führen, dass der Container läuft, die Anwendung aber falsch konfiguriert ist. Passwörter und API-Schlüssel sollten nicht ungeschützt in veröffentlichten Dateien, Images oder Protokollen landen; nutzen Sie unterstützte Secret-Mechanismen, wenn die Anwendung sie verarbeiten kann.
Docker Compose beschreibt Services, Netzwerke, Volumes, Ports und Konfigurationen deklarativ in einer YAML-Datei. Der bevorzugte Dateiname ist compose.yaml; ältere Namen wie docker-compose.yml werden weiterhin unterstützt. Compose erleichtert besonders Setups aus mehreren Diensten, beispielsweise WordPress, Datenbank und Reverse Proxy.
Der Begriff Stack hängt vom Werkzeug ab. Der offizielle Docker-Befehl docker stack gehört zu Swarm. NAS- und Verwaltungsoberflächen verwenden „Stack“ teilweise informell für eine zusammengehörige Compose-Anwendung. Prüfen Sie deshalb, welche Bedeutung und welche Compose-Funktionen die konkrete Oberfläche unterstützt.
Ein Container-Log besteht typischerweise aus den Standardausgaben des Hauptprozesses und wird von einem Logging-Treiber verarbeitet. docker logs zeigt daher nicht zwingend jede Logdatei der Anwendung. Bei dauerhaft laufenden Diensten gehört außerdem eine Logrotation zur Betriebsplanung, damit umfangreiche Ausgaben nicht unbemerkt den Datenträger füllen.
Container-Lebenszyklus: Vom Image bis zum kontrollierten Austausch
Ein zuverlässiges Docker-Setup entsteht nicht allein durch einen erfolgreichen Start. Sie müssen in jeder Phase wissen, welches Objekt Docker gerade verwendet, wo Daten liegen und welche Schnittstelle tatsächlich erreichbar sein soll. Die folgende Prüfung führt vom Image-Bezug bis zum späteren Austausch des Containers.
Docker-Lebenszyklus mit Daten-, Netzwerk- und Sicherheitsprüfung
| Phase | Docker-Objekt | Konkreter Prüfschritt | Typischer Fehler | Daten- oder Sicherheitsfolge |
|---|---|---|---|---|
| 1. Image laden oder bauen | Image, Dockerfile, Registry | Prüfen Sie Quelle, Tag oder Digest, Änderungsstand und Plattformvarianten wie linux/amd64 oder linux/arm64. | Ungeprüftes Image, veränderlicher latest-Tag oder falsche CPU-Architektur. | Der Start scheitert, Emulation bremst das System oder ein späterer Pull liefert unerwartet anderen Inhalt. |
| 2. Container erzeugen | Container und Laufzeitkonfiguration | Legen Sie Name, Benutzer, Environment Variables, Ressourcenlimits, Neustartverhalten und erforderliche Rechte nachvollziehbar fest. | Variable falsch geschrieben, Container unnötig als Root oder mit weitreichenden Rechten gestartet. | Die Anwendung arbeitet falsch oder erhält mehr Zugriff auf Host und Geräte als erforderlich. |
| 3. Speicher einbinden | Volume oder Bind Mount | Ermitteln Sie aus der Image-Dokumentation den echten Daten- und Konfigurationspfad. Prüfen Sie Eigentümer, Schreibrechte und gegebenenfalls Read-only-Mounts. | Volume am falschen Pfad, Hostverzeichnis fehlt oder Anwendung schreibt weiter in die Container-Schicht. | Daten verschwinden beim Entfernen des Containers oder Hostdateien können verändert werden. |
| 4. Netzwerk und Ports planen | Docker-Netzwerk und Port-Mapping | Trennen Sie Hostadresse, Host-Port, Container-Port und TCP oder UDP. Veröffentlichen Sie nur extern benötigte Ports. | Host-Port bereits belegt, Seiten des Mappings vertauscht oder Dienst unbeabsichtigt an alle Schnittstellen gebunden. | Der Dienst bleibt unerreichbar oder wird unnötig im LAN beziehungsweise Internet exponiert. |
| 5. Container starten | Hauptprozess, Logs und Healthcheck | Prüfen Sie Status, Prozessausgabe, Exit-Code, Portzuordnung und einen vorhandenen Healthcheck. Beachten Sie anwendungseigene Logdateien. | Der Status running wird mit vollständiger Betriebsbereitschaft gleichgesetzt. | Ein aktiver Prozess verdeckt Startfehler, fehlgeschlagene Migrationen oder eine noch nicht bereite Anwendung. |
| 6. Erreichbarkeit diagnostizieren | Anwendung, Mapping und Netzwerkweg | Klären Sie nacheinander: Läuft der Prozess, lauscht die Anwendung auf der richtigen Adresse, stimmt der interne Port, ist der Host-Port frei und erlaubt der Netzwerkweg den Zugriff? | Die Anwendung lauscht nur auf 127.0.0.1 im Container, ein falscher Dienstname wird verwendet oder eine Firewall blockiert. | Der Container wirkt gesund, obwohl Clients den Dienst nicht erreichen können. |
| 7. Update vorbereiten | Neues Image, Volume und Backup | Laden oder bauen Sie das gewünschte Image bewusst. Prüfen Sie Upgrade-Hinweise, unterstützte Versionssprünge, Datenmigration und eine getestete Wiederherstellung. | Datenbankcontainer ohne konsistentes Backup aktualisiert oder mehrere Hauptversionen übersprungen. | Das Volume bleibt zwar erhalten, seine Daten können nach einer Migration dennoch inkompatibel sein. |
| 8. Container ersetzen | Alter und neuer Container | Erzeugen Sie den Dienst mit identischen, überprüften Mounts und Einstellungen neu. Entfernen Sie Volumes nur nach eindeutiger Datenprüfung. | Nur innerhalb des alten Containers geänderte Konfiguration fehlt; down -v wird unbedacht ausgeführt. | Die beschreibbare Schicht oder bewusst gelöschte Volumes gehen dauerhaft verloren. |
Stoppen, Entfernen und Neuerzeugen haben unterschiedliche Folgen
Ein gestoppter Container bleibt mit seiner beschreibbaren Schicht vorhanden und kann erneut gestartet werden. Beim Entfernen des Containers löscht Docker diese Schicht. Ein korrekt eingebundenes benanntes Volume bleibt dagegen grundsätzlich erhalten, bis es separat gelöscht wird. Anonyme Volumes sind schwerer zuverlässig wiederzuordnen; für wichtige Daten sollten Sie benannte Volumes oder bewusst dokumentierte Bind Mounts verwenden.
Ändern Sie eine Compose-Datei, reicht docker compose restart nicht aus, um beispielsweise neue Environment Variables zu übernehmen. docker compose up kann einen betroffenen Container bei geänderter Konfiguration oder geändertem Image neu erzeugen und eingebundene Volumes weiterverwenden. Der genaue Ablauf bleibt imagespezifisch: Datenpfade, Startparameter und Migrationsschritte unterscheiden sich.
Der Tag latest ist kein Versprechen für eine feste oder kontrolliert getestete Version. Tags können später auf andere Images zeigen; ohne angegebenen Tag verwendet Docker üblicherweise latest. Für nachvollziehbare Setups wählen Sie einen dokumentierten Versionstag oder bei strenger Reproduzierbarkeit einen Digest und planen Updates ausdrücklich.
Ein Volume ist außerdem kein Backup. Es schützt Daten vor dem normalen Austausch eines Containers, nicht vor Fehlbedienung, beschädigten Dateien, Anwendungsfehlern oder einem Defekt des Hosts. Sichern Sie insbesondere Datenbanken konsistent und testen Sie die Wiederherstellung, bevor ein Update oder eine Migration sie erforderlich macht.
Docker und virtuelle Maschinen: Gemeinsamer Kernel oder eigenes Betriebssystem
Eine virtuelle Maschine stellt virtualisierte Hardware bereit und betreibt darauf ein Gastbetriebssystem mit eigenem Kernel. Sie kann deshalb eine umfassende Betriebssystemumgebung abbilden. Ein Container ist dagegen im Grundmodell ein isolierter Prozess mit eigenem Dateisystem, eigener Prozesssicht und eigener Netzwerkkonfiguration, der den Kernel seiner Laufzeitumgebung gemeinsam mit anderen Containern nutzt.
Da pro Container kein vollständiges Gastbetriebssystem mit eigenem Kernel hochgefahren werden muss, ist der strukturelle Overhead meist geringer. Daraus folgt jedoch keine universelle Garantie für bestimmte Startzeiten oder einen festen Speicherverbrauch. Anwendung, Image, Speichertechnik, Emulation und Hostplattform beeinflussen die tatsächliche Leistung.
Auf Docker Desktop laufen Linux-Container unter Windows und macOS typischerweise innerhalb einer von Docker verwalteten Linux-VM. Die Container teilen dort den Kernel dieser internen VM, nicht unmittelbar den Windows- oder macOS-Kernel. Das ist kein Widerspruch: Die VM schafft die benötigte Linux-Laufzeitumgebung, innerhalb derer weiterhin Container ausgeführt werden.
Auch Images sind nicht grenzenlos portabel. Betriebssystem und CPU-Architektur müssen passen. Ein Image für linux/amd64 läuft nicht automatisch nativ auf einem ARM-NAS, Raspberry Pi oder Apple-Silicon-Rechner. Multi-Plattform-Images können passende Varianten enthalten; andernfalls benötigen Sie ein anderes Image oder eine gegebenenfalls langsamere Emulation. Linux- und Windows-Container sind ebenfalls nicht beliebig austauschbar.
Container und virtuelle Maschinen konkurrieren daher nicht in jeder Situation. Häufig laufen mehrere Container gemeinsam in einer Server-VM. Benötigen Sie einen eigenen Kernel, ein anderes Gastbetriebssystem, vollständige Systemvirtualisierung oder eine stärkere Trennung unvertrauenswürdiger Workloads, spricht mehr für eine VM oder zusätzliche Isolation. Für reproduzierbare Anwendungsdienste mit passender Kernelbasis ist ein Container oft die direktere Einheit.
Einsatzbereiche, Einsteigerfehler und sichere Betriebsregeln
Docker trennt Anwendungen und macht Setups nachvollziehbar
Typische Einsatzbereiche sind lokale Entwicklungsumgebungen, Webanwendungen, temporäre Testdatenbanken, Reverse Proxys, Monitoring, CI/CD und Homelab-Dienste. Unterschiedliche Projekte können jeweils ihre benötigten Programm- und Bibliotheksversionen verwenden, ohne dieselben Abhängigkeiten direkt auf dem Host installieren zu müssen. Eine Compose-Datei dokumentiert außerdem, welche Services, Netzwerke, Mounts und Laufzeitwerte zusammengehören.
Docker beseitigt jedoch keine ungeeignete Hardware, zu wenig Arbeitsspeicher, falsche Anwendungsparameter oder eine mangelhafte Netzwerkplanung. Ebenso wenig ersetzt ein reproduzierbarer Container ein Backup-, Update- und Überwachungskonzept. Auf einem NAS hängt der tatsächlich verfügbare Funktionsumfang zudem vom Modell, Betriebssystemstand und der jeweiligen Container-Oberfläche ab.
Typische Docker-Fehler lassen sich über Ursache und Prüfschritt eingrenzen
- Daten sind nach dem Löschen weg: Prüfen Sie, ob die Anwendung in die beschreibbare Container-Schicht statt in den tatsächlich eingebundenen Datenpfad geschrieben hat.
- Das Volume bleibt leer: Vergleichen Sie den Mount-Zielpfad mit der Dokumentation des Images. Ein Volume am falschen Verzeichnis erfasst die Nutzdaten nicht.
- Der Port lässt sich nicht binden: Kontrollieren Sie, ob ein anderer Prozess oder Container den gewählten Host-Port bereits verwendet.
- Das Image startet auf dem NAS nicht: Prüfen Sie Betriebssystem und CPU-Plattform, insbesondere den Unterschied zwischen AMD64 und ARM64.
- Der Container läuft mit falscher Konfiguration: Kontrollieren Sie Namen, Wert, YAML-Einrückung und mögliche Überschreibungsquellen der Environment Variables.
- Der Container läuft, der Dienst ist aber nicht erreichbar: Prüfen Sie Anwendungsstatus, interne Listen-Adresse, Container-Port, Host-Mapping, Firewall und Routing getrennt.
- Ein Container erreicht den Nachbardienst nicht: Verwenden Sie im gemeinsamen Netzwerk den Dienstnamen und internen Port statt
localhostoder unnötig veröffentlichter Host-Ports. - Die Konfiguration verschwindet beim Update: Lagern Sie keine dauerhaften Anpassungen ausschließlich in die beschreibbare Schicht aus. Nutzen Sie ein neues Image, Volume oder einen dokumentierten Bind Mount.
- Ein Update verändert den Dienst unerwartet: Verlassen Sie sich nicht unkontrolliert auf
latest. Prüfen Sie Versionstag, Upgrade-Hinweise und Backup vor dem Austausch.
Container sind eine Isolationsschicht, aber keine magische Sicherheitsgrenze
Docker nutzt unter anderem Namespaces, Control Groups, reduzierte Linux-Capabilities und Sicherheitsprofile. Diese Mechanismen begrenzen Prozesse, beseitigen aber weder Schwachstellen in Images noch die gemeinsame Abhängigkeit vom Kernel. Mounts, Gerätezugriffe, offene Ports und der Docker-Daemon können die normale Isolation gezielt aufweichen.
- Prüfen Sie die Herkunft: Bevorzugen Sie nachvollziehbare Herausgeber, dokumentierte Tags, gepflegte Images und passende Plattformvarianten. Auch offizielle Kennzeichnungen garantieren keine Fehlerfreiheit.
- Lesen Sie fremde Definitionen: Kontrollieren Sie Dockerfiles und Compose-Dateien auf Hostpfade, Portbindungen, Gerätezugriffe, nachgeladene Skripte und sensible Variablen.
- Begrenzen Sie Rechte: Vermeiden Sie unnötigen Root-Betrieb, zusätzliche Capabilities, Host-Netzwerk und den Modus
privileged. Gewähren Sie nur konkret benötigte Rechte. - Schützen Sie den Docker-Socket: Ein Container mit Zugriff auf den Docker-Daemon kann weitreichende Aktionen auf dem Host auslösen. Erteilen Sie diesen Zugriff nur zwingend erforderlichen, vertrauenswürdigen Diensten.
- Begrenzen Sie Host-Mounts: Binden Sie nur notwendige Verzeichnisse ein und verwenden Sie Read-only-Zugriff, wenn der Container keine Dateien verändern muss.
- Veröffentlichen Sie nur benötigte Ports: Datenbanken und Verwaltungsoberflächen benötigen oft keinen direkten externen Port. Binden Sie lokale Testdienste nach Möglichkeit an Loopback.
- Schützen Sie Geheimnisse: Speichern Sie Passwörter und Schlüssel nicht im Dockerfile, Image oder öffentlichen Compose-Repository. Nutzen Sie geeignete Secret- oder Dateimechanismen.
- Planen Sie den Betrieb: Aktualisieren Sie Images kontrolliert, konfigurieren Sie Logrotation und sichern Sie persistente Daten mit getesteter Wiederherstellung.
Häufige Fragen zu Docker, Containern und persistenten Daten
Was ist Docker?
Docker ist eine Plattform, mit der Anwendungen in Containern bereitgestellt und ausgeführt werden können. Dazu verwaltet Docker unter anderem Images, Container, Netzwerke und Volumes.
Was ist ein Container?
Ein Container ist eine aus einem Image erzeugte, isolierte Prozessumgebung. Er besitzt eine eigene Laufzeitkonfiguration und beschreibbare Schicht, teilt aber grundsätzlich den Kernel seiner Laufzeitumgebung.
Was ist ein Image?
Ein Image ist die unveränderliche, schichtweise aufgebaute Vorlage für Container. Es enthält die benötigten Dateien und Startvorgaben, ist aber selbst keine laufende Anwendung.
Was ist Docker Compose?
Docker Compose beschreibt und verwaltet einen oder mehrere Services einschließlich Netzwerken, Volumes, Ports und Konfigurationen anhand einer YAML-Datei.
Was ist ein Volume?
Ein Volume ist von Docker verwalteter persistenter Speicher außerhalb des Lebenszyklus eines einzelnen Containers. Es ersetzt jedoch kein separates Backup.
Warum sind nach dem Löschen eines Containers Daten weg?
Nicht ausgelagerte Änderungen liegen in der beschreibbaren Container-Schicht. Docker entfernt diese Schicht zusammen mit dem Container. Dauerhafte Daten müssen am richtigen Anwendungspfad eingebunden sein.
Ist Docker eine virtuelle Maschine?
Nein. Ein Container ist keine vollständige VM mit eigenem Gastbetriebssystem und Kernel. Docker Desktop kann jedoch eine interne Linux-VM als Laufzeitumgebung für Linux-Container verwenden.
Ist Docker sicher?
Docker bietet wirksame Isolationsmechanismen, aber keine unüberwindbare Sicherheitsgrenze. Image-Vertrauen, Rechte, Host-Mounts, Docker-Socket, offene Ports, Updates und Kernel-Sicherheit bleiben entscheidend.
Klären Sie vor dem Start eines fremden Containers fünf Punkte: Stammt das Image aus einer nachvollziehbaren Quelle, unterstützt es Ihre Architektur, welche Datenpfade müssen dauerhaft gespeichert werden, welche Ports und Rechte sind wirklich erforderlich und wie lassen sich die Daten wiederherstellen?
Docker wird zuverlässig, wenn nicht der einzelne Container als dauerhafte Installation behandelt wird, sondern das gesamte Setup reproduzierbar beschrieben ist. Entscheidend sind eine kontrollierte Image-Version, ausgelagerte Daten, dokumentierte Konfiguration, begrenzte Zugriffe und ein geplanter Lebenszyklus vom ersten Start bis zum sicheren Austausch.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten