Hva er forskjellen mellom Docker-bilder og containere?

Question

Accepted Answer

Et Docker-**bilde** er en skrivebeskyttet **mal** (en pakket applikasjon med sine avhengigheter); en **container** er en **kjørende instans** av et bilde. Forholdet er som en klasse og et objekt: ett bilde kan generere mange containere. ## Bilde 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) ``` ## Arbeid med bilder ```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 ``` Bilder bygges (fra en Dockerfile), lagres lokalt eller i registreringer, versjoneres med tagger (`myapp:1.0`), og deles. ## Arbeid 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 opprettes fra bilder, har en livssyklus (kjør, stopp, start, fjern), og du kan inspisere logger eller kjøre kommandoer i dem. ## Det lagdelte forholdet ```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 er viktig Å forstå skillet mellom bilder og containere er grunnleggende for arbeid med Docker, så det er essensielt, må-vite-kunnskap. Forholdet — et **bilde** er en skrivebeskyttet **mal** (den pakkede applikasjonen med avhengigheter, som en ritning eller klasse) mens en **container** er en **kjørende instans** av det bildet (som et objekt opprettet fra en klasse, med kjøringsstilstand) — er kjernekonseptmodellen for Docker, og å blande sammen de to fører til forvirring om hvordan Docker fungerer. Å forstå at **ett bilde kan generere mange containere** (kjøre samme bilde flere ganger) er nøkkelen til hvordan Docker muliggjør skalering og konsistens. Å kjenne de praktiske operasjonene — bygge, liste, trekke, skyve og versjonere **bilder** (med tagger som `myapp:1.0`), og kjøre, stoppe, inspisere (logger) og kjøre kommandoer i **containere** (administrere deres livssyklus) — er daglig praktisk kunnskap for å bruke Docker. Å forstå det **lagdelte forholdet** (bilder bygget i cachede, delbare lag; en container være bildet sine skrivebeskyttede lag pluss et tynt skrivbart lag hvor kjøringsendringar går, tapt ved fjerning med mindre de oppbevares via volumer) forklarer både Dockers effektivitet (lagdeling/caching) og en viktig fallgruve (containerendringar er kortvarige uten volumer). Siden bilde/container-skillet er den grunnleggende mentalmodellen for Docker, og siden forståelse av det (og de tilhørende operasjonene og lagdelt struktur) er nødvendig for å bygge, kjøre og administrere Docker-arbeidsbelastninger riktig, er forståelse av forskjellen mellom bilder og containere essensielle, grunnleggende Docker-kunnskap — kjernekonseptet som alt annet i Docker bygger på, og et skille som hver Docker-bruker må forstå klart.