Containers dans des VM ou bare-metal : les avantages et les inconvénients

Bare-metal vs VM

Ce sujet n'est pas nouveau. Cette rivalité entre serveur nu et la VM est à l’esprit  des CTO depuis que la virtualisation s'est généralisée dans les datacenters - soit dans les années 2000 - , avant l’avènement des containers Docker, qui ont fait leur apparition en 2013.

Les principaux avantages des serveurs bare-metal sont les suivants :

• des performances supérieures, car aucune ressource système n'est gaspillée par l'émulation matérielle ;
• la pleine utilisation de toutes les ressources de la machine, car aucune d'entre elles ne reste inactive pendant les pics de demande ; et
• une administration plus facile, car il y a moins d'hôtes, de connexions réseau et de disques à gérer dans l'infrastructure.

Les machines virtuelles, en revanche, offrent les avantages suivants :

• les applications peuvent être déplacées facilement d'un hôte à l'autre en transférant les images d'un serveur à l'autre ;
• les applications qui s'exécutent dans différentes VM sont isolées les unes des autres. Cette structure offre certains avantages sur le plan de la sécurité et peut réduire la complexité en matière de gestion.
• Un environnement cohérent peut être créé à l’ensemble de l’infrastructure lorsque toutes les applications sont sur le même type de VM, même si les serveurs hôtes ne sont pas homogènes.

Mais les machines virtuelles ont aussi des inconvénients :

• Les ressources du serveur peuvent être sous-utilisées. Par exemple, si vous allouez de l'espace de stockage sur un hôte serveur pour créer une image de disque, cette partie devient indisponible, même si la machine virtuelle à laquelle le disque est attaché ne l'utilise pas entièrement.
• Dans la plupart des cas, les VM ne peuvent pas accéder directement au matériel physique. La VM ne peut par exemple pas décharger les opérations de calcul vers un GPU sur son hôte - du moins pas facilement - parce que la VM est abstraite d'un environnement hôte.
• les machines virtuelles ne fonctionnent généralement pas aussi bien que les serveurs physiques, en raison de la couche d'abstraction entre l'application et le matériel.

Avec les plateformes de virtualisation modernes, les administrateurs peuvent contourner ces limitations. Par exemple, on peut créer une image disque dynamique qui s’ajuste à mesure que l'utilisation des VM augmente. Cela permet d’éviter de verrouiller l'espace de stockage sur un hôte avant qu'un invité l'utilise réellement.

Les « pass-through » permettent également aux machines virtuelles d'accéder directement au matériel physique d'un hôte. Cependant, ces hacks ne fonctionnent pas toujours bien. Ils ne sont pas supportés par tous les types d'hôtes et d'OS invités, et ils alourdissent la gestion. Si les applications nécessitent un accès au serveur, il est préférable, donc, d'exécuter ces applications sur un serveur bare-metal.

Mais vous pouvez également exécuter vos applications à l'intérieur de containers sur du bare-metal et obtenir ainsi le meilleur des deux mondes.

Exécuter des containers sur du bare-metal : la boucle est bouclée

Les containers sur des hôtes bare-metal bénéficient des nombreux avantages de VM, mais sans les inconvénients de la virtualisation :

• Accéder au matériel nu sans avoir recours à des techniques de pass-through, car les processus applicatifs s'exécutent sur le même OS que le serveur hôte ;
• Avoir une utilisation optimale des ressources du système. On peut certes mettre des limites quant à la quantité de calcul, de stockage et de mise en réseau dans les containers. Mais ces derniers n'ont généralement pas besoin que ces ressources leur soient dédiées. Un hôte peut, par conséquent, distribuer et partager l'utilisation des ressources système selon les besoins.
• Bénéficier de performances élevées pour les applications, car il n'y a pas de couche d'émulation matérielle les séparant d'un serveur hôte.

De plus, en hébergeant des containers sur des serveurs nus, on bénéficie des avantages qui n'étaient traditionnellement possibles qu'avec les VMs :

• Avoir la capacité de déployer des applications dans des environnements qui peuvent facilement passer d'un serveur hôte à l'autre.
• Isoler l'application. Si les containers n'offrent sans doute pas le même niveau d'isolation que les VM, ils permettent d'empêcher les applications d'interagir entre elles et de fixer des limites strictes aux privilèges et à l'accessibilité des ressources associés à chaque container.

Les inconvénients des containers sur du bare-metal

Pourtant, il ne convient pas d’exécuter tous les containers sur des serveurs nus. Ils existent des freins majeurs où il vaut mieux considérer les machines virtuelles :

• Les mises à jour des serveurs physiques sont difficiles. Pour remplacer un serveur bare-metal, vous devez recréer l'environnement de containers à partir de zéro sur le nouveau serveur. Si celui-ci faisait partie d'une VM, vous pourriez simplement déplacer l'image vers le nouvel hôte.
• La plupart des plateformes cloud nécessite des VM. Il y a quelques hébergeurs qui proposent des offres bare-metal. Mais les serveurs nus dans les environnements de cloud coûtent généralement beaucoup plus cher. Dans l'ensemble, la plupart des fournisseurs de cloud public n'offrent que des machines virtuelles. Si vous voulez utiliser leurs plateformes pour faire fonctionner des containers, vous devrez les déployer dans des machines virtuelles.
• Les plateformes de containers ne prennent pas en charge toutes les configurations matérielles et logicielles. De nos jours, vous pouvez héberger presque tous les types d'OS sur une plateforme de virtualisation. Et vous pouvez l’exécuter sur presque tous les types d'OS ou de serveurs. Docker est plus limité et ne peut fonctionner que sur Linux, certains serveurs Windows et les mainframes IBM s'il est hébergé sur du bare-metal.
• Les containers dépendent de l’OS. Les containers Linux tournent sur des hôtes Linux ; les containers Windows tournent sur des hôtes Windows. Un serveur Windows bare-metal nécessite un environnement VM Linux afin d'héberger des containers Docker en vue d'une application compilée pour Linux.
• Les serveurs bare-metal n'offrent pas de fonctions de rollback. La plupart des plateformes de virtualisation permettent de faire des snapshots de VM. Les containers sont éphémères par nature, il n'y a donc rien à faire pour revenir en arrière. Vous pouvez peut-être utiliser les fonctions de rollback intégrées au système d'exploitation ou au système de fichiers hôte, mais elles sont souvent moins transparentes.

Orchestrateurs de containers sur du bare- metal

La plupart des orchestrateurs de containers, y compris Kubernetes et Docker Swarm, prennent en charge les déploiements bare-metal aussi bien que les containers dans des VM ou dans le cloud.

La seule mise en garde est que certaines distributions de Kubernetes, comme Kubicorn, ne fonctionnent pas sur le bare-metal. Si votre équipe DevOps dépend d'un orchestrateur ou d'une distribution Kubernetes en particulier, il est nécessaire de s’assurer que le bare-metal soit supporté.