Qual è la differenza tra immagini Docker e container?

Question

Accepted Answer

Un'**immagine** Docker è un **template** di sola lettura (un'applicazione confezionata con le sue dipendenze); un **container** è un'**istanza in esecuzione** di un'immagine. La relazione è come una classe e un oggetto: un'immagine può generare molti container. ## Immagine 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) ``` ## Lavorare con le immagini ```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 ``` Le immagini vengono costruite (da un Dockerfile), memorizzate localmente o nei registry, versionerizzate con tag (`myapp:1.0`), e condivise. ## Lavorare con i container ```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 ``` I container vengono creati da immagini, hanno un ciclo di vita (run, stop, start, remove), e puoi ispezionare i log o eseguire comandi al loro interno. ## La relazione a livelli ```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 ``` ## Perché è importante Comprendere la distinzione tra immagini e container è fondamentale per lavorare con Docker, quindi è una conoscenza essenziale e imprescindibile. La relazione — un'**immagine** è un **template** di sola lettura (l'applicazione confezionata con le dipendenze, come un blueprint o una classe) mentre un **container** è un'**istanza in esecuzione** di quella immagine (come un oggetto creato da una classe, con stato runtime) — è il modello concettuale core di Docker, e confondere i due porta a confusione su come Docker funziona. Comprendere che **un'immagine può generare molti container** (eseguire la stessa immagine più volte) è chiave per capire come Docker abilita scaling e coerenza. Conoscere le operazioni pratiche — costruire, listare, pullare, pushare, e versionare **immagini** (con tag come `myapp:1.0`), e eseguire, fermare, ispezionare (log), e eseguire comandi in **container** (gestire il loro ciclo di vita) — è conoscenza pratica quotidiana per usare Docker. Comprendere la **relazione a livelli** (immagini costruite in livelli cachati e condivisibili; un container essere i livelli di sola lettura dell'immagine più un sottile livello scrivibile dove vanno i cambiamenti runtime, persi al riavvio a meno che non siano persistiti via volumi) spiega sia l'efficienza di Docker (condivisione/caching dei livelli) che un importante gotcha (i cambiamenti del container sono effimeri senza volumi). Poiché la distinzione immagine/container è il modello mentale fondazionale di Docker, e poiché comprenderla (e le operazioni associate e la struttura a livelli) è necessario per costruire, eseguire e gestire correttamente i workload Docker, comprendere la differenza tra immagini e container è conoscenza Docker essenziale e fondamentale — il concetto core su cui tutto il resto di Docker si costruisce, e una distinzione che ogni utente Docker deve chiaramente comprendere.