Aller au contenu
English

Images et conteneurs en cours d'exécution

  • Leçon 2
  • 45 min
  • Module 1 : Comprendre les conteneurs
Leçon 2 sur 15 · L'essentiel de Docker et du nuage pour les développeurs en IAImages et conteneurs en cours d'exécution

Ce que vous saurez faire

Comprenez ce qu’une image contient, ce qu’un conteneur en cours d’exécution y ajoute et ce que sa suppression fait perdre. C’est la base de tous les modules suivants. Le code de l’API va dans l’image. Les données à conserver vont ailleurs.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 45 minutes

Ce que vous devez savoir

Ce qu’il vous faut sur votre ordinateur

  • Docker, pour exécuter les commandes vous-même. Si vous ne l’avez pas encore, faites d’abord Installer et vérifier : installer Docker et Vérifier l’installation, puis revenez. Vous pouvez aussi lire cette leçon d’abord : chaque commande présente sa sortie réelle. L’exercice du module, à la fin de la prochaine leçon, vous demande d’exécuter les mêmes étapes.
  • Une connexion Internet. La première commande télécharge l’image Python (46 Mo).
  • Aucun fichier de projet. Cette leçon ne modifie pas ticket-api.

Testé avec Docker Desktop 4.81.0 (Docker Engine 29.6.1) sur macOS, avec un processeur Apple silicon. Les étapes pour Windows et Linux n’ont pas été testées. Les commandes docker sont les mêmes sur tous les systèmes.

Amira télécharge l’image officielle Python depuis Docker Hub. Télécharger une image, c’est faire un ** pull ** (récupération) :

Terminal
docker pull python:3.14.8-slim-trixie

La sortie (sur un ordinateur qui n’a pas encore l’image) :

3.14.8-slim-trixie: Pulling from library/python
2037d17aae31: Pulling fs layer
11de3117eae8: Pulling fs layer
bbeda6b4abb7: Pulling fs layer
9822e19f729e: Pulling fs layer
...
9822e19f729e: Pull complete
Digest: sha256:f85c5697265c178cc6887276c55fe16cf3d14ca35c3df6a5eab3b360534a55d2
Status: Downloaded newer image for python:3.14.8-slim-trixie
docker.io/library/python:3.14.8-slim-trixie

Chaque ligne avec un identifiant court représente une couche : un ensemble de fichiers ajouté par-dessus les couches inférieures. Docker télécharge les couches séparément, en même temps. Le condensat est l’empreinte exacte de l’image. Le module 2 l’utilise pour fixer une version. library/python désigne une Docker Official Image (image officielle Docker). Ces images de Docker Hub sont vérifiées par Docker et reçoivent rapidement des mises à jour de sécurité. Le module 2 explique davantage comment choisir une image.

L’image se trouve maintenant sur l’ordinateur :

Terminal
docker image ls python
Sortie
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
python:3.14.8-slim-trixie f85c5697265c 206MB 46MB

L’image a deux tailles. CONTENT SIZE (taille du contenu), soit 46 Mo, représente les couches compressées. C’est ce qu’une récupération ou un envoi transfère sur le réseau. DISK USAGE (espace disque utilisé), soit 206 Mo, représente l’espace occupé sur cet ordinateur, avec les couches décompressées. Vos chiffres peuvent varier un peu si votre ordinateur possède déjà d’autres images qui partagent des couches.

Amira démarre un conteneur qui exécute une seule commande Python :

Terminal
docker run --name c18m01-first python:3.14.8-slim-trixie python -c "print('Hello from a container')"
Partie Signification
docker run Créer un nouveau conteneur à partir d’une image et le démarrer.
--name c18m01-first Un nom pour le conteneur. Sans cet argument, Docker choisit un nom au hasard. Dans ce cours, les noms commencent par le module (c18m01-), pour retrouver et supprimer vos conteneurs plus tard.
python:3.14.8-slim-trixie L’image.
python -c "..." La commande à exécuter dans le conteneur, à la place de la commande de démarrage de l’image.

La sortie :

Hello from a container

La commande s’est terminée, donc le conteneur s’est arrêté. Il existe encore. docker ps montre seulement les conteneurs en cours d’exécution. docker ps -a (« tous ») montre aussi les conteneurs arrêtés. --filter name=c18m01- montre seulement les conteneurs dont le nom contient ce texte :

Terminal
docker ps --filter name=c18m01-
docker ps -a --filter name=c18m01-
Sortie
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
87a66f714f56 python:3.14.8-slim-trixie "python -c 'print('H…" Less than a second ago Exited (0) Less than a second ago c18m01-first

La première liste est vide. La deuxième contient le conteneur, avec Exited (0) (terminé avec le code 0). Le programme s’est terminé avec le code de sortie 0, qui indique une réussite. Docker conserve ce que le programme a affiché. docker logs l’affiche à nouveau, et docker rm supprime le conteneur arrêté :

Terminal
docker logs c18m01-first
docker rm c18m01-first
Sortie
Hello from a container
c18m01-first

Un conteneur reste en cours d’exécution exactement aussi longtemps que son programme principal. C’est le fait le plus important à retenir : un conteneur est un processus, encadré par Docker.

La même image peut répondre à d’autres questions. Par exemple, quelle version de Python et quel processeur sont utilisés :

Terminal
docker run --rm python:3.14.8-slim-trixie python -c "import sys, platform; print(sys.version, platform.machine())"
Sortie
3.14.8 (main, Oct 6 2026, 02:02:59) [GCC 14.2.0] aarch64

--rm supprime le conteneur quand son programme se termine. Vous n’avez donc pas besoin de docker rm. Sur un ordinateur Intel ou AMD, le dernier mot est x86_64.

docker history liste les couches d’une image, de la plus récente à la plus ancienne, avec l’instruction ayant créé chacune :

Terminal
docker history python:3.14.8-slim-trixie
Sortie
IMAGE CREATED CREATED BY SIZE COMMENT
f85c5697265c 39 hours ago CMD ["python3"] 0B buildkit.dockerfile.v0
<missing> 39 hours ago RUN /bin/sh -c set -eux; for src in idle3 p… 16.4kB buildkit.dockerfile.v0
<missing> 39 hours ago RUN /bin/sh -c set -eux; savedAptMark="$(a… 45.3MB buildkit.dockerfile.v0
<missing> 39 hours ago ENV PYTHON_SHA256=c2215904f02b175596dc493515… 0B buildkit.dockerfile.v0
<missing> 39 hours ago ENV PYTHON_VERSION=3.14.8 0B buildkit.dockerfile.v0
<missing> 39 hours ago RUN /bin/sh -c set -eux; apt-get update; a… 4.99MB buildkit.dockerfile.v0
<missing> 39 hours ago ENV PATH=/usr/local/bin:/usr/local/sbin:/usr… 0B buildkit.dockerfile.v0
<missing> 2 days ago # debian.sh --arch 'arm64' out/ 'trixie' '@1… 110MB debuerreotype 0.17

Lisez la liste à partir du bas :

  1. Les fichiers de Debian 13, un petit système Linux : 110 Mo.
  2. Quelques paquets système, installés avec apt-get : 4,99 Mo.
  3. Python 3.14.8, construit à partir de son code source : 45,3 Mo.
  4. Des noms courts pour les commandes Python, comme python pour python3 : 16,4 ko.
  5. Les lignes ENV et CMD : 0 octet. Elles n’ajoutent aucun fichier. Ce sont des métadonnées : des renseignements sur la façon d’exécuter l’image. ENV définit les variables d’environnement, et CMD est la commande de démarrage.

<missing> (manquant) est normal. Les couches ont été construites sur un autre ordinateur. Seule celle du haut a donc un identifiant ici.

docker image inspect montre les métadonnées. --format choisit les valeurs à afficher :

Terminal
docker image inspect python:3.14.8-slim-trixie --format 'Cmd={{.Config.Cmd}} User={{.Config.User}} Arch={{.Architecture}}'
Sortie
Cmd=[python3] User= Arch=arm64

La commande de démarrage est python3. User= (utilisateur) est vide. Cela signifie que le programme s’exécute en tant que root, l’administrateur du système du conteneur. Le module 2 change cela pour l’API de billets. arm64 est le processeur auquel cette copie de l’image est destinée.

Amira démarre un conteneur qui reste en cours d’exécution. sleep infinity attend indéfiniment. -d (« détaché ») démarre le conteneur en arrière-plan, ce qui libère le terminal :

Terminal
docker run -d --name c18m01-box python:3.14.8-slim-trixie sleep infinity
docker ps --filter name=c18m01-
Sortie
aa62c8ec9cb50a09e1259d59b20422651168cecb7363ef53177e4a0b46e2a58f
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
aa62c8ec9cb5 python:3.14.8-slim-trixie "sleep infinity" Less than a second ago Up Less than a second c18m01-box

La longue ligne est l’identifiant complet du conteneur. docker exec exécute une deuxième commande dans un conteneur en cours d’exécution. Elle y écrit un fichier, puis le lit :

Terminal
docker exec c18m01-box sh -c 'echo "written inside" > /tmp/note.txt'
docker exec c18m01-box cat /tmp/note.txt
Sortie
written inside

docker diff liste les changements dans le conteneur par rapport à son image. A signifie ajouté, C modifié et D supprimé :

Terminal
docker diff c18m01-box
Sortie
C /tmp
A /tmp/note.txt

docker top montre les processus dans le conteneur. Il y en a un : sleep infinity :

Terminal
docker top c18m01-box
Sortie
UID PID PPID C STIME TTY TIME CMD
root 8886 8863 0 16:54 ? 00:00:00 sleep infinity

Prédisez le résultat : Amira arrête le conteneur et le redémarre. Le fichier est-il encore là? Ensuite, elle supprime le conteneur et en démarre un nouveau à partir de la même image. Le fichier est-il là?

Terminal
docker stop c18m01-box
docker ps -a --filter name=c18m01-
docker start c18m01-box
docker exec c18m01-box cat /tmp/note.txt
Sortie
c18m01-box
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
aa62c8ec9cb5 python:3.14.8-slim-trixie "sleep infinity" 10 seconds ago Exited (137) Less than a second ago c18m01-box
c18m01-box
written inside

Après stop (arrêter) et start (démarrer), le fichier est encore là. (docker stop a pris 10 secondes ici. La commande demande au programme de s’arrêter et attend jusqu’à 10 secondes. sleep ne réagit pas à cette demande dans un conteneur. Docker l’a donc forcé à s’arrêter : code de sortie 137. Le module 2 montre comment l’API s’arrête immédiatement.)

Elle supprime maintenant le conteneur avec -f (« forcer »), car il est en cours d’exécution, puis en démarre un nouveau :

Terminal
docker rm -f c18m01-box
docker run -d --name c18m01-box python:3.14.8-slim-trixie sleep infinity
docker exec c18m01-box cat /tmp/note.txt
Sortie
c18m01-box
908dbd393fa639f56aa3f90f0a482fefb9b4c2cf40b7dec4ed5f8818fe7ff437
cat: /tmp/note.txt: No such file or directory

Le fichier a disparu. Le nouveau conteneur a le même nom et la même image, mais c’est un conteneur différent.

Voici la règle qui explique le résultat. Les couches d’une image sont en lecture seule : aucun conteneur ne peut les modifier. Quand Docker démarre un conteneur, il ajoute une couche accessible en écriture, mince et vide, par-dessus les couches de l’image. Chaque fichier que le conteneur écrit, modifie ou supprime va dans sa couche accessible en écriture. Le conteneur voit les couches ensemble, comme un seul système de fichiers.

  • docker stop arrête le processus. La couche accessible en écriture reste.
  • docker rm supprime le conteneur, ainsi que sa couche accessible en écriture.
  • Un nouveau conteneur reçoit une nouvelle couche accessible en écriture, vide.

docker ps --size montre à quel point la couche accessible en écriture est petite. Avec la note qu’elle contient :

Terminal
docker ps --size --filter name=c18m01-box
Sortie
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE
21f0351f8228 python:3.14.8-slim-trixie "sleep infinity" 1 second ago Up Less than a second c18m01-box 12.3kB (virtual 160MB)

La couche accessible en écriture fait 12,3 ko. « virtual 160MB » représente cette couche plus les couches décompressées de l’image, que le conteneur utilise sans les copier.

En haut, deux couches accessibles en écriture, une par conteneur : c18m01-a contient /tmp/note.txt, c18m01-b ne contient aucun fichier écrit. docker rm les supprime avec le conteneur. En dessous, les couches de l'image python:3.14.8-slim-trixie, en lecture seule et partagées : métadonnées (CMD python3, ENV) 0 octet, liens Python 16,4 ko, Python 3.14.8 45,3 Mo, paquets apt 4,99 Mo, fichiers Debian 13 110 Mo.
Tous les conteneurs issus d'une image partagent les mêmes couches en lecture seule. Chacun possède sa propre couche accessible en écriture par-dessus. docker rm supprime la couche accessible en écriture.
Description textuelle du diagramme

Le schéma comporte deux parties. En bas se trouvent les couches de l’image python:3.14.8-slim-trixie, tirées de docker history. Elles sont en lecture seule et partagées par tous les conteneurs. Du bas vers le haut : Debian 13 (110 Mo), paquets apt (4,99 Mo), Python 3.14.8 (45,3 Mo), liens Python (16,4 ko). Au sommet se trouvent les métadonnées, CMD python3 et les lignes ENV, qui ajoutent 0 octet. (Dans docker history, les lignes ENV se trouvent entre les autres couches.) Au-dessus de l’image se trouvent deux couches accessibles en écriture, une par conteneur. Le conteneur c18m01-a a écrit /tmp/note.txt. Le conteneur c18m01-b n’a rien écrit. docker rm supprime la couche accessible en écriture d’un conteneur.

Amira démarre deux conteneurs à partir de la même image :

Terminal
docker run -d --name c18m01-a python:3.14.8-slim-trixie sleep infinity
docker run -d --name c18m01-b python:3.14.8-slim-trixie sleep infinity
docker ps --filter name=c18m01-
Sortie
f507c4b684d5984760d67bdd2c9d4856c15ca19481d9d84af8b9a326959182da
bc257ecef1f618a63a53fb3bdc855cae09f8ea92c8d60334bb7204f3af017cd4
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bc257ecef1f6 python:3.14.8-slim-trixie "sleep infinity" 1 second ago Up Less than a second c18m01-b
f507c4b684d5 python:3.14.8-slim-trixie "sleep infinity" 1 second ago Up Less than a second c18m01-a

Elle écrit une note dans c18m01-a seulement, puis la cherche dans c18m01-b :

Terminal
docker exec c18m01-a sh -c 'echo only-in-a > /tmp/note.txt'
docker exec c18m01-b cat /tmp/note.txt
Sortie
cat: /tmp/note.txt: No such file or directory

Chaque conteneur possède sa propre couche accessible en écriture. Il voit donc les fichiers de son propre point de vue. Chacun possède aussi son propre nom sur le réseau et sa propre liste de processus :

Terminal
docker exec c18m01-a hostname
docker exec c18m01-b hostname
docker exec c18m01-a python -c "import os; print(sorted(int(p) for p in os.listdir('/proc') if p.isdigit()))"
Sortie
f507c4b684d5
bc257ecef1f6
[1, 25]

Le nom d’hôte d’un conteneur est son identifiant court. Dans c18m01-a, seuls deux processus existent. Le numéro 1 est sleep infinity, et le numéro 25 est la commande Python qui pose la question. Le conteneur ne peut pas voir les processus de l’autre conteneur ni ceux de l’ordinateur.

Les conteneurs partagent une chose : le noyau, le cœur du système d’exploitation qui exécute chaque processus et communique avec le matériel.

Terminal
docker exec c18m01-a uname -r
docker exec c18m01-b uname -r
uname -r
Sortie
6.12.76-linuxkit
6.12.76-linuxkit
25.6.0

Les deux conteneurs indiquent le même noyau Linux, 6.12.76-linuxkit. La dernière ligne est le noyau du Mac, version 25.6.0, qui n’est pas Linux. Les conteneurs ont besoin d’un noyau Linux. Sur macOS et Windows, Docker Desktop exécute une petite machine virtuelle Linux. Tous les conteneurs utilisent son noyau. Sur un ordinateur Linux, les conteneurs utilisent le noyau de l’ordinateur.

Amira supprime les deux conteneurs :

Terminal
docker rm -f c18m01-a c18m01-b

Une machine virtuelle (VM) est un ordinateur complet créé par logiciel. Elle possède son propre système d’exploitation, avec son propre noyau. Un programme appelé hyperviseur partage le matériel réel entre les VM. Un conteneur n’a pas son propre noyau. C’est un processus qui utilise le noyau de l’hôte, et que Docker sépare des autres processus.

Deux piles. Conteneurs : trois conteneurs, chacun avec une application, Python et des bibliothèques, sur Docker Engine, sur un noyau Linux partagé par tous les conteneurs, sur le matériel. Machines virtuelles : deux VM, chacune avec une application, Python, des bibliothèques et son propre noyau, sur un hyperviseur, sur le système d'exploitation et le noyau de l'hôte, sur le matériel.
Les conteneurs partagent un noyau. Chaque machine virtuelle possède son propre noyau.
Description textuelle du diagramme

La pile de gauche montre les conteneurs. Trois conteneurs, chacun avec une application, Python et des bibliothèques, s’exécutent sur Docker Engine. En dessous se trouve un noyau Linux partagé par tous les conteneurs. Tout en bas se trouve le matériel : processeur, mémoire et disque. La pile de droite montre les machines virtuelles. Deux VM possèdent chacune une application, Python, des bibliothèques et leur propre noyau. Elles s’exécutent sur un hyperviseur, sur le système d’exploitation et le noyau de l’hôte, sur le même type de matériel.

Conteneur Machine virtuelle
Possède son propre noyau Non : il partage le noyau Linux de l’hôte Oui
Démarre En environ une seconde : il démarre un processus (docker run --rm python:3.14.8-slim-trixie true a pris de 0,4 à 1,0 seconde ici) Quand tout son système d’exploitation a démarré
Taille Seulement les fichiers du programme : 206 Mo pour cette image Python Un système d’exploitation complet
Séparation Bonne pour vos propres programmes. Tous les conteneurs dépendent d’un seul noyau. Plus forte : un problème dans un noyau reste dans une seule VM

Les plateformes infonuagiques utilisent souvent les deux. Dans le module 5, Azure exécute votre conteneur et décide où se trouvent le noyau et les VM. Cela fait partie de ce que vous payez.

Exercice guidé : vérifier la couche accessible en écriture

Section intitulée « Exercice guidé : vérifier la couche accessible en écriture »
  1. Démarrez un conteneur qui reste en cours d’exécution.

    Fenêtre de terminal
    docker run -d --name c18m01-practice python:3.14.8-slim-trixie sleep infinity

    Résultat attendu : un long identifiant de conteneur.

  2. Écrivez un fichier dans le conteneur.

    Fenêtre de terminal
    docker exec c18m01-practice sh -c 'echo "my note" > /tmp/note.txt'
  3. Vérifiez le changement avec docker diff c18m01-practice. Résultat attendu : C /tmp et A /tmp/note.txt.

  4. Vérifiez la taille de la couche accessible en écriture avec docker ps --size --filter name=c18m01-practice. Résultat attendu : quelques ko et « virtual 160MB ».

  5. Supprimez le conteneur avec docker rm -f c18m01-practice.

  6. Démarrez un nouveau conteneur avec la commande de l’étape 1.

  7. Cherchez le fichier avec docker exec c18m01-practice cat /tmp/note.txt. Résultat attendu : cat: /tmp/note.txt: No such file or directory (aucun fichier ou dossier de ce nom).

  8. Supprimez le conteneur avec docker rm -f c18m01-practice, puis vérifiez avec docker ps -a --filter name=c18m01- que la liste est vide.

Montrer pourquoi l’étape 7 échoue

La note se trouvait dans la couche accessible en écriture du premier conteneur. À l’étape 5, docker rm -f a supprimé ce conteneur et sa couche accessible en écriture. Le conteneur de l’étape 6 porte le même nom, mais il est nouveau. Il possède une nouvelle couche accessible en écriture, vide, sur la même image en lecture seule. L’image n’a jamais contenu la note.

Démarrez deux conteneurs, c18m01-a et c18m01-b, comme dans Plusieurs conteneurs à partir d’une image. Dans c18m01-a, supprimez la commande pip3 : docker exec c18m01-a rm /usr/local/bin/pip3. Faites une prédiction : est-ce que pip3 --version fonctionne encore dans c18m01-a? Et dans c18m01-b? Que montre docker diff c18m01-a? Exécutez ensuite les commandes et vérifiez. Supprimez les deux conteneurs à la fin.

Afficher la réponse
docker exec c18m01-a pip3 --version
OCI runtime exec failed: exec failed: unable to start container process: exec: "pip3": executable file not found in $PATH
docker exec c18m01-b pip3 --version
pip 26.2.1 from /usr/local/lib/python3.14/site-packages/pip (python 3.14)
docker diff c18m01-a
C /usr
C /usr/local
C /usr/local/bin
D /usr/local/bin/pip3

pip3 a disparu seulement dans c18m01-a. Le fichier se trouve encore dans la couche en lecture seule de l’image. La couche accessible en écriture de c18m01-a enregistre seulement « supprimé » (D) et masque le fichier dans ce conteneur. c18m01-b et chaque nouveau conteneur ont encore pip3. Supprimez les deux avec docker rm -f c18m01-a c18m01-b.

Erreur courante

Le conteneur s'arrête immédiatement

Symptôme : Amira démarre l’image Python en arrière-plan, sans commande. docker run affiche un identifiant, mais docker ps ne montre rien :

Terminal
docker run -d --name c18m01-py python:3.14.8-slim-trixie
docker ps --filter name=c18m01-py
docker ps -a --filter name=c18m01-py
Sortie
1e8a3e2b493bb6a733ce77279cfa60aba1caaa3726f5c74a8df530ac91619bfa
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1e8a3e2b493b python:3.14.8-slim-trixie "python3" 3 seconds ago Exited (0) 2 seconds ago c18m01-py

docker logs c18m01-py n’affiche rien.

Cause : la commande de démarrage de l’image est python3, l’invite interactive de Python. En arrière-plan, aucun terminal n’est connecté. Python atteint donc immédiatement la fin de son entrée et se termine avec le code de sortie 0. Un conteneur reste actif seulement tant que son processus principal fonctionne.

Solution :

  1. Regardez l’état dans docker ps -a et la commande dans la colonne COMMAND (commande). Exited (0) (terminé avec le code 0) signifie que le programme s’est terminé normalement. Il n’a pas planté.
  2. Donnez au conteneur une commande qui continue de fonctionner, comme sleep infinity pour un test, ou un serveur.
  3. Pour une invite interactive de Python, connectez plutôt votre terminal : docker run -it --rm python:3.14.8-slim-trixie (-i garde l’entrée ouverte, -t lui fournit un terminal). Tapez exit() pour quitter.
  4. Supprimez le conteneur arrêté : docker rm c18m01-py.

Pour un vrai service d’IA : la commande de démarrage du service doit lancer un serveur qui continue de fonctionner, comme fastapi run. Si le serveur s’arrête à cause d’une erreur, le conteneur s’arrête aussi. docker ps -a et docker logs sont les deux premiers endroits à consulter.

Vérifiez votre compréhension

Amira écrit un fichier dans un conteneur en cours d'exécution, puis exécute docker stop et docker start. Ensuite, elle exécute docker rm et docker run à nouveau. Quand le fichier est-il encore là, et pourquoi?

Afficher la réponse

Après docker stop et docker start, le fichier est encore là. L’arrêt termine le processus, mais conserve le conteneur et sa couche accessible en écriture. Après docker rm et un nouveau docker run, le fichier a disparu. docker rm supprime le conteneur et sa couche accessible en écriture. Le nouveau conteneur démarre avec une nouvelle couche vide, accessible en écriture, sur l’image en lecture seule.

Vérifiez votre compréhension

Pourquoi docker history affiche-t-il 0B pour les lignes ENV et CMD de l'image Python?

Afficher la réponse

ENV et CMD n’ajoutent aucun fichier. Ce sont des métadonnées : ENV définit les variables d’environnement des processus du conteneur, et CMD est la commande de démarrage. Docker les conserve dans la configuration de l’image, que montre docker image inspect, plutôt que dans une couche de fichiers.

Vérifiez votre compréhension

Deux conteneurs fonctionnent sur le Mac d'Amira. Que partagent-ils parmi ces éléments : les fichiers qu'ils écrivent, leur liste de processus, le noyau?

Afficher la réponse

Seulement le noyau. Chaque conteneur a sa propre couche accessible en écriture. Un fichier écrit par l’un ne se trouve donc pas dans l’autre. Chacun a sa propre liste de processus. Dans c18m01-a, le processus principal porte le numéro 1, et les processus de l’autre conteneur ne sont pas visibles. Les deux utilisent le même noyau Linux, 6.12.76-linuxkit. Sur un Mac, c’est le noyau de la petite machine virtuelle Linux de Docker Desktop. Une machine virtuelle, par contre, a son propre noyau.

Récapitulatif

  • Une image est une pile de couches en lecture seule, accompagnée de métadonnées : commande de démarrage (CMD), variables d’environnement (ENV), utilisateur. docker history et docker image inspect les montrent.
  • Un conteneur est un processus démarré à partir d’une image. Il a sa propre couche accessible en écriture, vue des fichiers, nom réseau et liste de processus. Il partage le noyau Linux de l’hôte. Une machine virtuelle a son propre noyau.
  • docker stop conserve la couche accessible en écriture. docker rm la supprime. Un nouveau conteneur démarre avec une couche vide.
  • Les commandes : docker pull, run (-d, --name, --rm), ps et ps -a, logs, exec, diff, top, stop, start, rm, image ls, history.

Ensuite, vous installerez Docker, si ce n’est pas déjà fait, et vous le vérifierez avec un premier conteneur. Vous exécuterez aussi un serveur web dans un conteneur.

Leçon suivante : Installer et vérifier