À quoi ressemblent les processus à l'intérieur d'un conteneur Docker?

J'ai entendu dire récemment que la confusion entourait ce qu'est un conteneur Docker, et plus particulièrement ce qui se passe à l'intérieur, en ce qui concerne les commandes et processus que j'appelle lorsque je suis dans un conteneur Docker.

Quelqu'un peut-il s'il vous plaît donner un aperçu de haut niveau de ce qui se passe?

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 1000commandes 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 -eafsortie 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 1000processus ne sont en réalité que des processus enfants par rapport à notre processus Bash original? Notez également que notre conteneur Docker d'origine /bin/bashest 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 -eafressemblerait à 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.

Dans le conteneur, vos processus doivent être isolés (mis en quarantaine). En fait, vous ne devriez voir aucun processus, sauf ceux que vous spécifiez (un shell au moins). Ce n'est pas pour les tests de "sociabilité". La seule similitude avec chroot est que le noyau hôte est utilisé. Docker est idéal si vous devez isoler quelque chose ou utiliser des versions différentes du logiciel d'architecture de plate-forme que celles exécutées sur l'hôte. (très anciennes versions de Java ou un autre fork de Python, par exemple). Sachez que les dossiers et les fichiers binaires avec lesquels vous traitez peuvent différer de ceux de l'hôte. Ce n'est pas le même dossier / bin, etc.

EDIT: similitude avec chroot plutôt qu'avec les VM.