Hvad er forskellen mellem Docker-images og containere?

Question

Accepted Answer

Et Docker **image** er en skrivebeskyttet **skabelon** (en pakket applikation med dens afhængigheder); en **container** er en **kørende instans** af et image. Forholdet er som en klasse og et objekt: ét image kan generere mange containere. ## 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) ``` ## Arbejde 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 bygges (fra en Dockerfile), gemmes lokalt eller i registreringer, versioneres med tags (`myapp:1.0`), og deles. ## Arbejde med containere ```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 ``` Containere oprettes ud fra images, har en livscyklus (kør, stop, start, fjern), og du kan inspicere logs eller exec ind i dem. ## Det lagdelte forhold ```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 ``` ## Hvorfor det betyder noget At forstå skellet mellem images og containere er grundlæggende for at arbejde med Docker, så det er vigtig, må-vide viden. Forholdet — et **image** er en skrivebeskyttet **skabelon** (den pakkede applikation med afhængigheder, som en blueprint eller klasse), mens en **container** er en **kørende instans** af det image (som et objekt skabt fra en klasse, med runtime-tilstand) — er Dockers kernekoncept, og forvirring af de to fører til uklarhed omkring hvordan Docker fungerer. At forstå, at **ét image kan generere mange containere** (køre det samme image flere gange) er nøglen til hvordan Docker muliggør skalering og konsistens. At kende de praktiske operationer — bygning, oplistning, pulling, pushing og versionering af **images** (med tags som `myapp:1.0`), og kørsel, stop, inspektion (logs) og exec ind i **containere** (håndtering af deres livscyklus) — er daglig praktisk viden for at bruge Docker. At forstå det **lagdelte forhold** (images bygget i cachede, delbare lag; en container være image-ets skrivebeskyttede lag plus et tyndt skrivbart lag, hvor runtime-ændringer går, tabt ved fjernelse medmindre persisteret via volumes) forklarer både Dockers effektivitet (lag-deling/caching) og en vigtig gotcha (containerændringer er kortvarige uden volumes). Da image/container-skellet er den grundlæggende mentale model for Docker, og da det at forstå det (og de tilhørende operationer og lagdelte struktur) er nødvendigt for korrekt at bygge, køre og administrere Docker-workloads, er forståelsen af forskellen mellem images og containere vigtig, grundlæggende Docker-viden — kernekoncept, som alt andet i Docker bygger på, og et skelne som hver Docker-bruger må forstå klart.