Conteneurs vs machines virtuelles (Qu'est-ce que Docker ?)

Aujourd'hui, nous avons un sujet brûlant à creuser : Les containers et les machines virtuelles. Êtes-vous sûr de comprendre la différence entre les deux ? En passant par un défi qui consistait à coder Docker en Go, j'ai percuté que je n'avais pas tout à fait saisi ce qu'est un container.

Pour illustrer, permettez-moi de vous poser la question suivante : Savez-vous dans quelles conditions le fait d’exécuter un container Docker est au moins aussi coûteux que d’exécuter d'une machine virtuelle ?

Si vous ne connaissez pas la réponse, ne quittez pas. Nous allons répondre à cette question et à d'autres, comme par exemple : Qu'est-ce qu'une VM ? Qu'est-ce qu'un container ? Quelles sont les différences entre un container et une VM ? Pourquoi un container est-il plus léger (en général) ? Quels sont les inconvénients de l'utilisation d'un container par rapport à une VM ?

La première étape consiste à comprendre ce qu'est une VM (ou machine virtuelle).

Qu'est-ce qu'une machine virtuelle ?

Le film "The Matrix" pose la question suivante : "Vivons-nous dans une simulation ?". Pour les machines virtuelles, la réponse est "oui". Une machine virtuelle (ou VM en abrégé) est un logiciel qui fait semblant d’être un ordinateur.

Quelle est la structure de nos ordinateurs ? Ils ont trois couches principales. Ils sont dotés de hardware : le CPU, la mémoire, le disque dur, l’interface réseau, etc. Au dessus du hardware, nous avons un système d'exploitation, et par dessus le système d'exploitation, nous avons la couche logicielle.

C'est dans la couche logicielle que vit la machine virtuelle. Une machine virtuelle est (pour schématiser) une simulation de hardware. Celle-ci dispose d'un processeur virtuel, d'un disque dur, d'une mémoire, et ainsi de suite. Le logiciel fait semblant d'être du hardware. À son tour, le disque dur simulé contient un tout nouveau système d'exploitation.

C'est ce qui nous permet (par exemple) de faire fonctionner Linux sur Mac ou Windows.

C'est également la technologie qui nous permet de faire fonctionner des téléphones portables et des tablettes simulés (qui ont généralement des processeurs avec un jeu d'instructions ARM) sur nos ordinateurs à l'aide de Xcode ou d'Android Studio.

Pour ceux qui se posent la question : Oui, vous pouvez faire fonctionner une VM dans une VM dans une VM... bien qu'il y ait une limite à cela. Pourquoi ?

Simuler un système entier peut être coûteux : l'ordinateur hôte doit non seulement exécuter son propre système d'exploitation, mais il doit aussi simuler le hardware de la VM, et puis son système d'exploitation, et puis tout le logiciel qui s'exécute sur la VM

C'est là que les conteneurs entrent en jeu.

Sur le plan conceptuel, les containers ont beaucoup en commun avec les machines virtuelles. D'une certaine façon, ils sont la prochaine étape de l'évolution, la suite logique des machines virtuelles.

Mais cela produit beaucoup de confusions quant à la différence exacte entre les deux. Pour ma part je n’ai vraiment compris la différence que quand j’ai mis le main dans le cambouis et que j’ai commencé à manipuler, à fabriquer ma propre version de Docker à l’aide de CodeCrafters. Si vous voulez faire de même, j’ai mis un lien dans la description.

Mais revenons en à nos moutons, pourquoi les conteneurs sont-ils la prochaine étape après les machines virtuelles ?

Penchons-nous sur ce que sont exactement les conteneurs et sur les améliorations qu'ils apportent aux machines virtuelles.

Qu'est-ce qu'un container ?

En un mot, les machines virtuelles ajoutent, mais les containers... retirent. Et c’est ça leur force. Laissez-moi vous expliquer.

Revenons à notre ordinateur, avec ses trois couches. Si nous plongeons dans la couche du système d'exploitation, nous constatons qu'elle aussi comporte des couches avec des rôles différents. La plus profonde, le noyau, s'interface directement avec le hardware.

Un container est une "tranche" cloisonnée de l'environnement, qui se trouve au-dessus du noyau. Il dispose d'une part personnelle mais limitée de la mémoire, du disque dur et des processus du processeur, etc., qu'il peut utiliser.

Il ne peut pas voir le reste de l'environnement. Il ne peut accéder à aucune partie du système de fichiers, de la mémoire ou des processus qui ne lui appartiennent pas.

Il s'adresse simplement au même noyau ou “kernel” que le reste des logiciels de l'ordinateur pour interagir avec le hardware, il partage donc le même hardware et une partie du système d'exploitation.

Pour communiquer, il utilise sa part du hardware du réseau pour envoyer et recevoir des messages réseau, y compris à d'autres containers sur le même ordinateur.

Parce que le container partage le hardware et le système d'exploitation au lieu de les simuler, un container est généralement plus léger à faire fonctionner qu'une machine virtuelle.

Cependant, il existe une situation où un container est plus coûteux qu'une machine virtuelle. Voyez-vous quand cela peut se produire ?

Cette question nous amène aux forces et faiblesses de la technologie des conteneurs, et à la question : pourquoi utiliser des conteneurs plutôt que des machines virtuelles ?

Pourquoi utiliser des conteneurs plutôt que des machines virtuelles ?

J'ai mentionné que les containers sont légers. C'est leur première force.

La deuxième force des containers est qu'ils sont jetables. À première vue, cela peut sembler être une faiblesse. Mais un environnement jetable est un environnement avec un comportement contrôlé et répétable. Cela présente deux avantages très importants.

Premièrement, cela signifie qu'un container sur ma machine fonctionne exactement de la même manière que sur la vôtre. Cela évite le syndrome du "ça marche sur ma machine" auquel j'ai vu tant de développeurs faire appel (et pour être honnête, j'ai aussi utilisé cette excuse).

Deuxièmement, un environnement léger et reproductible est facile à faire évoluer en fonction des besoins. La “jetabilité” permet la “scalabilité”.

Maintenant, les conteneurs sont également accompagnés de plusieurs coûts et inconvénients.

Tout d'abord, il y a un coût de mise en place. C’est plus difficile de configurer un environnement dans un container Docker, précisément parce que la configuration doit être répétable.

Deuxièmement, les conteneurs sont également moins sûrs que les machines virtuelles car ils sont plus proches du hardware final. Et de ce fait une faille dans l'isolation pourrait être source d'ennuis.

Il y a une autre faiblesse, et c'est la réponse à la question : "Quand un container est-il plus couteux qu'une machine virtuelle ?".

Voyez-vous, les conteneurs sont reproductibles, mais que se passe-t-il si j'ai un Mac et que vous utilisez Linux ? Une section cloisonnée d'un Mac et d'une machine Linux ne fonctionnera pas de la même manière.

Alors, comment les services de conteneurs fonctionnent-ils sur des machines qui ne sont pas sous Linux ? Et bien … Ils utilisent une machine virtuelle qui tourne sous Linux.

Alors, quand l'exécution d'un container Docker est-elle plus coûteuse en termes de calcul que l'exécution d'une VM ? Quand il y a besoin d'une machine virtuelle pour exécuter le container Docker.

Cela étant dit, si l'exécution d'un container sur une VM est plus coûteuse que la simple exécution d'une VM, l'exécution de tout un tas de containers est beaucoup moins coûteuse que de faire tourner le même nombre de machines virtuelles.

Ou, pour formuler les choses différemment, le jeu en vaut la chandelle.

Si vous souhaitez acquérir des connaissances plus pratiques, je vous suggère de suivre le défi de construction Docker que j’ai .. affronté (ce lien est affilié).