Conteneur ou machine virtuelle : la différence en une phrase et ses quatre conséquences

Vous allez faire tourner quelque chose de nouveau sur Proxmox et il y a deux options. Toutes deux font tourner un Linux, toutes deux figurent côte à côte dans le panneau, toutes deux semblent faire le même travail.

Le choix se fait d’ordinaire par habitude de ressources : « un conteneur est plus léger ». C’est vrai, mais ce n’est pas ce qui doit décider.

La différence tient en une phrase : une machine virtuelle apporte son propre noyau, un conteneur utilise celui du serveur. Tout ce qu’il faut savoir découle de cette phrase.

Première conséquence : où passe la frontière

La frontière de la machine virtuelle est tracée par le matériel. Celle du conteneur est tracée par le noyau du serveur.

Cela ne veut pas dire qu’un conteneur est « faible » ; cela dit où passe la frontière. Si un défaut logiciel à l’intérieur d’un conteneur veut atteindre le serveur, ce qu’il doit franchir est le noyau propre du serveur. Dans une machine virtuelle, ce qu’il doit franchir est un mur au niveau matériel.

La question pratique est celle-ci : quelle confiance accordez-vous à ce que vous allez faire tourner ? Pour un service que vous avez écrit ou que vous utilisez depuis des années, un conteneur convient parfaitement. Pour quelque chose de téléchargé que vous ne maîtrisez pas entièrement, une machine virtuelle est un meilleur endroit.

Deuxième conséquence : tout ne tourne pas dans un conteneur

Rien de ce qui exige son propre noyau ne tourne dans un conteneur. Un logiciel qui veut une autre version de noyau, un outil qui charge des modules noyau, un système d’exploitation qui n’est pas Linux : tous réclament une machine virtuelle.

Ce n’est pas une affaire de préférence, c’est une conséquence directe de la phrase ci-dessus. Si un conteneur utilise le noyau du serveur, vous ne pouvez pas lui demander de changer ce noyau.

Troisième conséquence : la maintenance les touche différemment

C’est la moins connue et celle qui risque le plus de faire mal.

Quand vous mettez à jour le moteur de machines virtuelles, les machines en marche ne sont pas affectées. Le nouveau moteur s’applique aux machines démarrées après cette mise à jour. Une nuit de maintenance peut donc passer sans bruit au-dessus de vos machines en marche.

Quand vous mettez à jour la couche d’exécution des conteneurs, les conteneurs en marche peuvent être affectés, car ils partagent tous cette couche. Pendant la mise à jour, la couche de fichiers partagée peut être remontée et de brèves erreurs d’accès peuvent apparaître à l’intérieur des conteneurs.

Ce n’est pas un avis produit, c’est la conséquence directe de la même phrase : si vous mettez à jour quelque chose de partagé, tous ceux qui le partagent le sentent.

Quatrième conséquence : la liberté de mouvement

Une machine virtuelle peut être déplacée vers un autre nœud en marche. Un conteneur non : on l’arrête, on le déplace, on le redémarre.

Si donc un travail qui ne tolère aucune interruption se trouve dans un conteneur, ce travail s’arrêtera les nuits de maintenance. C’est à mettre dans la balance au moment de décider de l’emplacement.

La règle pratique

Choisissez un conteneur quand ce que vous faites tourner est un service Linux ordinaire que vous pourriez sinon lancer sur le serveur, quand vous lui faites confiance et quand il supporte une brève interruption.

Choisissez une machine virtuelle quand un noyau propre est nécessaire, quand elle ne doit pas être interrompue pendant la maintenance, ou quand vous ne faites pas entièrement confiance à ce que vous exécutez.

La différence de ressources vient après ces trois tests. Qu’un conteneur consomme moins de mémoire est vrai, mais le coût d’un conteneur mal placé dépasse de loin cette économie.

Ce que fait Atlas

Atlas porte cette distinction non comme un slogan mais comme un comportement.

Dans l’évaluation des mises à jour, le moteur de machines virtuelles et la couche d’exécution des conteneurs sont traités séparément. Quand le moteur de machines est mis à jour, la réponse pour les machines en marche est au niveau informatif : elles ne sont pas affectées, le nouveau moteur vaut pour celles démarrées ensuite. Quand la couche conteneur est mise à jour, le niveau monte à l’avertissement et la raison est écrite : la couche partagée peut être remontée, envisagez d’arrêter brièvement les conteneurs critiques.

La même distinction apparaît dans la planification des déplacements : pour les conteneurs, le déplacement en marche n’est pas proposé comme une option, c’est la chaîne arrêter, déplacer, démarrer qui est indiquée.

Le produit ne présente donc pas les deux comme « deux variantes de la même chose ». Ils se comportent différemment, donc on les décrit différemment.