Lorsque nous utilisons Docker, nous commençons par une image de base. Nous la démarrons, créons des changements et ces changements sont enregistrés dans des couches formant une autre image.
Au final, j'ai donc une image pour mon instance PostgreSQL et une image pour mon application web, dont les modifications continuent d'être conservées.
Qu'est-ce qu'un conteneur ?
Une instance d'une image est appelée un conteneur. Vous avez une image, qui est un ensemble de couches comme vous le décrivez. Si vous démarrez cette image, vous avez un conteneur en cours d'exécution de cette image. Vous pouvez avoir plusieurs conteneurs en cours d'exécution de la même image.
Vous pouvez voir toutes vos images avec docker images
tandis que vous pouvez voir vos conteneurs en cours d'exécution avec docker ps
(et vous pouvez voir tous les conteneurs avec docker ps -a
).
Ainsi, une instance d'une image en cours d'exécution est un conteneur.
Extrait de mon article sur [l'automatisation des déploiements Docker][1] :
À Dockerland, il existe des images et des conteneurs. Les deux sont étroitement liés, mais distincts. Pour moi, la compréhension de cette dichotomie a considérablement clarifié Docker.
Une image est un fichier inerte, immuable, qui est essentiellement un instantané d'un conteneur. Les images sont créées à l'aide de la commande [build][2], et elles produisent un conteneur lorsqu'elles sont lancées avec la commande [run][3]. Les images sont stockées dans un registre Docker tel que [registry.hub.docker.com][4]. Comme elles peuvent devenir assez grandes, les images sont conçues pour être composées de couches d'autres images, ce qui permet d'envoyer une quantité minimale de données lors du transfert d'images sur le réseau.
Les images locales peuvent être listées en exécutant docker images
:
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu 13.10 5e019ab7bf6d 2 months ago 180 MB
ubuntu 14.04 99ec81b80c55 2 months ago 266 MB
ubuntu latest 99ec81b80c55 2 months ago 266 MB
ubuntu trusty 99ec81b80c55 2 months ago 266 MB
<none> <none> 4ab0d9120985 3 months ago 486.5 MB
Quelques choses à noter:
-t
de la commande docker build
, ou de l'étiquetage docker tag
- d'une image existante. Vous êtes libre de taguer les images en utilisant une nomenclature qui a du sens pour vous, mais sachez que docker utilisera le tag comme emplacement du registre dans un docker push
ou un docker pull
.[REGISTRYHOST/][USERNAME/]NAME[:TAG]
. Pour ubuntu
ci-dessus, REGISTRYHOST est déduit comme étant registry.hub.docker.com
. Donc, si vous prévoyez de stocker votre image appelée mon-application
dans un registre à docker.example.com
, vous devriez marquer cette image docker.example.com/mon-application
.latest
n'est pas magique, c'est simplement la balise par défaut lorsque vous ne spécifiez pas de balise.<none>
et le REPOSITORY. Il est facile de les oublier.Plus d'informations sur les images sont disponibles dans la [documentation Docker][5] et le [glossaire][6].
Pour utiliser une métaphore de programmation, si une image est une classe, alors un conteneur est une instance d'une classe - un objet d'exécution. Les conteneurs sont, je l'espère, la raison pour laquelle vous utilisez Docker ; ce sont des encapsulations légères et portables d'un environnement dans lequel exécuter des applications.
Visualisez les conteneurs locaux en cours d'exécution avec docker ps
:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f2ff1af05450 samalba/docker-registry:latest /bin/sh -c 'exec doc 4 months ago Up 12 weeks 0.0.0.0:5000->5000/tcp docker-registry
Ici, je fais tourner une version dockerisée du registre docker, afin d'avoir un endroit privé pour stocker mes images. Encore une fois, quelques points à noter :
docker ps
ne donne que les conteneurs running. Vous pouvez voir tous les conteneurs (running ou stopped) avec docker ps -a
.--name
.Une de mes premières frustrations avec Docker était l'accumulation apparemment constante d'images non étiquetées et de conteneurs arrêtés. À quelques reprises, cette accumulation a entraîné la saturation des disques durs, ralentissant mon ordinateur portable ou arrêtant mon pipeline de construction automatisé. Vous parlez de "conteneurs partout" !
Nous pouvons supprimer toutes les images non marquées en combinant docker rmi
avec la récente requête dangling=true
:
docker images -q --filtre "dangling=true" | xargs docker rmi
Docker ne pourra pas supprimer les images qui se trouvent derrière les conteneurs existants, donc vous devrez peut-être d'abord supprimer les conteneurs arrêtés avec docker rm
:
docker rm `docker ps --no-trunc -aq`
Il s'agit de [points douloureux connus][7] avec Docker et ils seront peut-être traités dans les prochaines versions. Cependant, avec une compréhension claire des images et des conteneurs, ces situations peuvent être évitées avec quelques pratiques :
docker rm [CONTAINER_ID]
.docker rmi [IMAGE_ID]
.[1] : http://paislee.io/how-to-automate-docker-deployments/ [2] : https://docs.docker.com/engine/reference/commandline/build/ [3] : https://docs.docker.com/engine/reference/commandline/run/ [4] : https://registry.hub.docker.com/ [5] : https://docs.docker.com/engine/reference/commandline/images/ [6] : https://docs.docker.com/engine/reference/glossary/#image [7] : https://github.com/docker/docker/issues/928
S'il est plus simple de considérer un conteneur comme une image en cours d'exécution, ce n'est pas tout à fait exact.
Une image est en réalité un modèle qui peut être transformé en conteneur. Pour transformer une image en conteneur, le moteur Docker prend l'image, y ajoute un système de fichiers en lecture-écriture et initialise divers paramètres, notamment les ports réseau, le nom du conteneur, l'ID et les limites de ressources. Un conteneur en cours d'exécution possède un processus en cours d'exécution, mais un conteneur peut également être arrêté (ou exité dans la terminologie de Docker). Un conteneur quitté n'est pas la même chose qu'une image, car il peut être redémarré et conservera ses paramètres et les modifications apportées au système de fichiers.