Quelle est la différence entre les images Docker et les conteneurs ?

Question

Accepted Answer

Une **image** Docker est un **modèle** en lecture seule (une application empaquetée avec ses dépendances) ; un **conteneur** est une **instance en cours d'exécution** d'une image. La relation est comme une classe et un objet : une image peut créer de nombreux conteneurs. ## Image vs conteneur ```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) ``` ## Utiliser les 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 ``` Les images sont construites (à partir d'un Dockerfile), stockées localement ou dans des registres, versionnées avec des tags (`myapp:1.0`), et partagées. ## Utiliser les conteneurs ```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 ``` Les conteneurs sont créés à partir d'images, ont un cycle de vie (run, stop, start, remove), et vous pouvez inspecter les logs ou vous connecter dedans. ## La relation en couches ```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 ``` ## Pourquoi c'est important Comprendre la distinction entre les images et les conteneurs est fondamental pour travailler avec Docker, c'est donc une connaissance essentielle et incontournable. La relation — une **image** est un **modèle** en lecture seule (l'application empaquetée avec ses dépendances, comme un schéma ou une classe) tandis qu'un **conteneur** est une **instance en cours d'exécution** de cette image (comme un objet créé à partir d'une classe, avec un état d'exécution) — est le modèle conceptuel fondamental de Docker, et confondre les deux entraîne une confusion sur le fonctionnement de Docker. Comprendre qu'**une image peut créer de nombreux conteneurs** (exécuter la même image plusieurs fois) est essentiel pour comprendre comment Docker permet la mise à l'échelle et la cohérence. Connaître les opérations pratiques — construire, lister, télécharger, envoyer et versionner des **images** (avec des tags comme `myapp:1.0`), et exécuter, arrêter, inspecter (logs) et se connecter dans des **conteneurs** (gérer leur cycle de vie) — est une connaissance pratique quotidienne pour utiliser Docker. Comprendre la **relation en couches** (les images construites en couches mises en cache et partageables ; un conteneur étant les couches en lecture seule de l'image plus une fine couche inscriptible où les changements d'exécution vont, perdus à la suppression sauf s'ils sont persistés via des volumes) explique à la fois l'efficacité de Docker (partage/mise en cache des couches) et un problème important (les changements de conteneur sont éphémères sans volumes). Comme la distinction image/conteneur est le modèle mental fondateur de Docker, et comme la comprendre (ainsi que les opérations associées et la structure en couches) est nécessaire pour construire, exécuter et gérer correctement les charges de travail Docker, comprendre la différence entre les images et les conteneurs est une connaissance Docker essentielle et fondamentale — le concept fondamental sur lequel tout le reste de Docker s'appuie, et une distinction que chaque utilisateur de Docker doit clairement maîtriser.