Docker est jeté dans le panier de virtualisation, car les gens pensent qu'il est en quelque sorte en train de virtualiser le matériel. C’est un abus de langage qui imprègne la terminologie utilisée par Docker, principalement le terme conteneur.
Cependant, Docker ne fait rien de magique en ce qui concerne la virtualisation du matériel d'un système. Il utilise plutôt la capacité du noyau Linux à construire des "barrières" autour d'installations clés, ce qui permet à un processus d'interagir avec des ressources telles que le réseau, le système de fichiers et les autorisations (entre autres) pour donner l'illusion d'interaction. avec un système entièrement fonctionnel.
Voici un exemple illustrant ce qui se passe lorsque nous démarrons un conteneur Docker, puis que nous y entrons via l'invocation de /bin/bash
.
$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#
Maintenant de l'intérieur de ce conteneur, si nous courons ps -eaf
:
En passant à un autre onglet de terminal où nous sommes connectés au système hôte hébergeant le conteneur Docker, nous pouvons voir l'espace de processus que le conteneur occupe "en réalité":
Maintenant, si nous retournons à l'onglet Docker, y lançons plusieurs processus et les mettons tous en arrière-plan, nous pouvons constater que plusieurs processus enfants s'exécutent sous le processus Bash principal que nous avons initialement lancé dans le cadre du lancement du conteneur Docker.
Remarque: les processus sont 4 sleep 1000
commandes qui sont en arrière-plan.
Notez qu'à l'intérieur du conteneur Docker, les processus se voient attribuer des ID de processus (PID) de 48-51. Voyez-les dans la ps -eaf
sortie dans leur aussi:
Cependant, avec cette image suivante, une grande partie de la "magie" que Docker joue est révélée.
Voyez comment les 4 sleep 1000
processus ne sont en réalité que des processus enfants par rapport à notre processus Bash original? Notez également que notre conteneur Docker d'origine /bin/bash
est en fait un processus enfant du démon Docker.
Maintenant, si nous attendions plus de 1000 secondes pour l'original sleep 1000
commandes d' terminées, puis 4 autres nouvelles commandes et démarrions un autre conteneur Docker comme ceci:
$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#
La sortie de l'ordinateur hôte à partir de ps -eaf
ressemblerait à ceci:
Et d'autres conteneurs Docker apparaîtront simplement en tant que processus sous le démon Docker.
Vous voyez donc, Docker ne virtualise pas ( au sens traditionnel du terme ), il construit des "barrières" autour des différentes ressources du noyau et en limite la visibilité pour un processus donné + les enfants.