Was ist der Unterschied zwischen Docker-Images und Containern?

Question

Accepted Answer

Ein Docker-**Image** ist eine schreibgeschützte **Vorlage** (eine gepackte Anwendung mit ihren Abhängigkeiten); ein **Container** ist eine **laufende Instanz** eines Images. Die Beziehung ist wie eine Klasse und ein Objekt: Ein Image kann viele Container erzeugen. ## Image vs. Container ```text IMAGE → a read-only TEMPLATE: the app + dependencies + config, built in layers (like a blueprint/class; stored, shared, versioned) CONTAINER → a RUNNING INSTANCE of an image (with a writable layer on top) (like an object created from a class; has runtime state) One IMAGE → many CONTAINERS (run the same image multiple times) ``` ## Arbeiten mit Images ```bash docker build -t myapp:1.0 . # BUILD an image from a Dockerfile docker images # list local images docker pull nginx # download an image from a registry docker push myapp:1.0 # upload an image to a registry docker rmi myapp:1.0 # remove an image ``` Images werden erstellt (aus einem Dockerfile), lokal oder in Registries gespeichert, mit Tags versioniert (`myapp:1.0`) und freigegeben. ## Arbeiten mit Containern ```bash docker run -d -p 80:80 nginx # RUN a container from an image (-d = background) docker ps # list RUNNING containers docker ps -a # list all (including stopped) docker stop # stop a container docker start # start a stopped container docker rm # remove a container docker logs # view a container's logs docker exec -it bash # run a command inside a running container ``` Container werden aus Images erstellt, haben einen Lebenszyklus (run, stop, start, remove), und Sie können Logs inspizieren oder in sie hineinfahren. ## Die geschichtete Beziehung ```text → Images are built in LAYERS (each Dockerfile instruction adds a layer, cached/shared) → A container = the image's read-only layers + a thin WRITABLE layer on top → Changes in a running container go to its writable layer (lost when removed, unless persisted via volumes) — the underlying image is unchanged ``` ## Warum es wichtig ist Das Verständnis des Unterschieds zwischen Images und Containern ist grundlegend für die Arbeit mit Docker und daher unverzichtbares, essentielles Wissen. Die Beziehung — ein **Image** ist eine schreibgeschützte **Vorlage** (die gepackte Anwendung mit Abhängigkeiten, wie ein Blueprint oder eine Klasse), während ein **Container** eine **laufende Instanz** dieses Images ist (wie ein Objekt, das aus einer Klasse mit Laufzeitzustand erstellt wird) — ist das Kern-Konzeptmodell von Docker, und die Verwechslung der beiden führt zu Verwirrung über die Funktionsweise von Docker. Zu verstehen, dass **ein Image viele Container erzeugen kann** (das gleiche Image mehrmals ausführen), ist der Schlüssel dazu, wie Docker Skalierung und Konsistenz ermöglicht. Die praktischen Operationen zu kennen — Images erstellen, auflisten, pullen, pushen und versionieren (mit Tags wie `myapp:1.0`), und Container ausführen, stoppen, inspizieren (Logs) und in sie hineinfahren (ihren Lebenszyklus verwalten) — ist alltägliches praktisches Wissen für die Verwendung von Docker. Das Verständnis der **geschichteten Beziehung** (Images werden in gecachten, gemeinsam nutzbaren Schichten erstellt; ein Container ist die schreibgeschützte Schicht des Images plus eine dünne beschreibbare Schicht, in die Laufzeitänderungen gehen, die beim Entfernen verloren gehen, es sei denn, sie werden über Volumes beibehalten) erklärt sowohl Dockers Effizienz (Schicht-Sharing/Caching) als auch eine wichtige Falle (Container-Änderungen sind ohne Volumes ephemer). Da die Image-/Container-Unterscheidung das grundlegende mentale Modell für Docker ist und da das Verständnis dafür (und der damit verbundenen Operationen und geschichteten Struktur) notwendig ist, um Docker-Workloads korrekt zu erstellen, auszuführen und zu verwalten, ist das Verständnis des Unterschieds zwischen Images und Containern essentielles, grundlegendes Docker-Wissen — das Kernkonzept, auf dem alles andere in Docker aufbaut, und eine Unterscheidung, die jeder Docker-Benutzer klar verstehen muss.