Wat is het verschil tussen Docker images en containers?

Question

Accepted Answer

Een Docker **image** is een alleen-lezen **template** (een verpakte applicatie met zijn afhankelijkheden); een **container** is een **draaiende instantie** van een image. De relatie is zoals een class en een object: één image kan veel containers opspawnen. ## Image versus 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) ``` ## Werken met 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 worden gebouwd (uit een Dockerfile), lokaal of in registries opgeslagen, geversioned met tags (`myapp:1.0`), en gedeeld. ## Werken met containers ```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 ``` Containers worden uit images gemaakt, hebben een levenscyclus (run, stop, start, remove), en je kunt logs inspecteren of erin exec uitvoeren. ## De gelaagde relatie ```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 ``` ## Waarom het belangrijk is Het begrijpen van het verschil tussen images en containers is fundamenteel voor het werken met Docker, dus het is essentieel, must-know kennis. De relatie — een **image** is een alleen-lezen **template** (de verpakte applicatie met afhankelijkheden, zoals een blauwdruk of class) terwijl een **container** een **draaiende instantie** van die image is (zoals een object gemaakt uit een class, met runtime state) — is het kernconceptuele model van Docker, en het verwarren van de twee leidt tot verwarring over hoe Docker werkt. Begrijpen dat **één image veel containers kan opspawnen** (dezelfde image meerdere keren uitvoeren) is essentieel voor hoe Docker schaling en consistentie mogelijk maakt. De praktische operaties kennen — images bouwen, opsommen, pullen, pushen en versioning (met tags zoals `myapp:1.0`), en containers uitvoeren, stoppen, inspecteren (logs), en exec-en (lifecycle beheren) — is dagelijkse praktische kennis voor het gebruik van Docker. De **gelaagde relatie** begrijpen (images gebouwd in gecachde, deelbare lagen; een container is de alleen-lezen lagen van de image plus een dunne schrijfbare laag waar runtime wijzigingen naartoe gaan, verloren bij verwijdering tenzij persistent gemaakt via volumes) legt zowel Docker's efficiëntie uit (laag delen/cachen) als een belangrijk gotcha (container wijzigingen zijn efemeer zonder volumes). Omdat het image/container onderscheid het fundamentele mentale model voor Docker is, en omdat het begrijpen ervan (en de bijbehorende operaties en gelaagde structuur) nodig is voor het correct bouwen, uitvoeren en beheren van Docker workloads, is het begrijpen van het verschil tussen images en containers essentieel, fundamenteel Docker kennis — het kernencept waarop alles anders in Docker voortbouwt, en een onderscheid dat elke Docker gebruiker duidelijk moet begrijpen.