Vad är skillnaden mellan Docker-images och containers?

Question

Accepted Answer

En Docker **image** är en skrivskyddad **mall** (ett paketerat program med dess beroenden); en **container** är en **körande instans** av en image. Relationen är som en klass och ett objekt: en image kan skapa många containers. ## Image kontra 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) ``` ## Arbeta med 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 byggs (från en Dockerfile), lagras lokalt eller i register, versioneras med taggar (`myapp:1.0`), och delas. ## Arbeta med 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 skapas från images, har en livscykel (kör, stoppa, starta, ta bort), och du kan inspektera loggar eller köra kommandon inuti dem. ## Den skiktade relationen ```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 ``` ## Varför det är viktigt Att förstå skillnaden mellan images och containers är fundamental för arbete med Docker, så det är väsentlig, måste-kunna kunskap. Relationen — en **image** är en skrivskyddad **mall** (det paketerade programmet med beroenden, som en ritning eller klass) medan en **container** är en **körande instans** av den imagen (som ett objekt skapat från en klass, med körtidstillstånd) — är Docker-konceptets kärnmodell, och att förväxla de två leder till förvirring om hur Docker fungerar. Att förstå att **en image kan skapa många containers** (köra samma image flera gånger) är nyckeln till hur Docker möjliggör skalning och konsistens. Att kunna de praktiska operationerna — bygga, lista, hämta, pusha och versionera **images** (med taggar som `myapp:1.0`), och köra, stoppa, inspektera (loggar) och köra kommandon in i **containers** (hantera deras livscykel) — är vardaglig praktisk kunskap för att använda Docker. Att förstå den **skiktade relationen** (images byggt i cachade, delbara skikt; en container är imagen:s skrivskyddade skikt plus ett tunt skrivbart skikt där körändringarna går, förlorad vid borttagning om inte persisterad via volymer) förklarar både Docker:s effektivitet (skiktdelning/caching) och ett viktigt problem (containerändringarna är efemära utan volymer). Eftersom image/container-distinktionen är den grundläggande mentalmodellen för Docker, och eftersom det är nödvändigt att förstå den (och de associerade operationerna och den skiktade strukturen) för att bygga, köra och hantera Docker-arbetsbelastningar korrekt, är förståelsen av skillnaden mellan images och containers väsentlig, fundamental Docker-kunskap — kärnkonceptet som allt annat i Docker bygger på, och en distinktion som varje Docker-användare måste helt klart förstå.