$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
Et quand tu lis la documentation qui est juste avant:
Docker run reference
Docker runs processes in isolated containers. A container is a process which runs on a host.
Puis, tu lis la documentation juste après:
The docker run command must specify an IMAGE to derive the container from.
Je suis d'accord que la syntaxe donne l'impression de "run une image", mais en réalité tu run un container.
Ce n'est pas de la drosophilie avancée, c'est très important pour comprendre comment Docker fonctionne et comment il faut l'utiliser.
Le principe est qu'une image devrait toujours pouvoir être complètement détruite et, quand tu la rebuild avec un Dockerfile, tu retrouves le même résultat à peu près ("à peu près", car ça dépend des commandes exécutées pendant le build).
Le container par contre utilise l'image pour exécuter une commande et il n'y a plus de garantie sur l'état du système de fichier du container.
Ça permet aussi de garder un même volume entre plusieurs démarrages de container.
Je me suis même reposé la question et c'est pour ça que j'ai voulu précisé. Je me suis dis que si moi qui utilise docker régulièrement avait mal compris d'autres pourraient mal comprendre.
Ok, cette formulation n'était pas très précise.
Le but était surtout de préciser qu'un volume "nommé" a un nom fixe, qu'il peut être facilement identifiable sur la machine hôte.
En plus, comme son nom est fixe, il peut aussi facilement être réutilisé après avoir détruit son container. Il peut aussi être lié à d'autres containers (comme proposé par Psychofox pour les backups), mais dans ce cas, il faut faire très attention aux accès concurrents aux fichiers.
[^] # Re: Quelque chose qui m'échappe
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Sauvegarder le contenu d’un container Docker avec BackupPC. Évalué à 3.
Et quand tu lis la documentation qui est juste avant:
Puis, tu lis la documentation juste après:
Je suis d'accord que la syntaxe donne l'impression de "run une image", mais en réalité tu run un container.
Ce n'est pas de la drosophilie avancée, c'est très important pour comprendre comment Docker fonctionne et comment il faut l'utiliser.
Le principe est qu'une image devrait toujours pouvoir être complètement détruite et, quand tu la rebuild avec un Dockerfile, tu retrouves le même résultat à peu près ("à peu près", car ça dépend des commandes exécutées pendant le build).
Le container par contre utilise l'image pour exécuter une commande et il n'y a plus de garantie sur l'état du système de fichier du container.
Ok, cette formulation n'était pas très précise.
Le but était surtout de préciser qu'un volume "nommé" a un nom fixe, qu'il peut être facilement identifiable sur la machine hôte.
En plus, comme son nom est fixe, il peut aussi facilement être réutilisé après avoir détruit son container. Il peut aussi être lié à d'autres containers (comme proposé par Psychofox pour les backups), mais dans ce cas, il faut faire très attention aux accès concurrents aux fichiers.