Conteneurs vs Machines Virtuelles
Mise en situation
En situation de virtualisation, lorsqu’un administrateur systèmes vient à décider du type d’infrastructure informatique à utiliser pour y loger une application, il a, entre autre choix, la possibilité de la déployer dans une machine virtuelle et/ou dans un conteneur ou ‘service conteneurisé’.
Pour bien comprendre qu’un, ne remplace pas l’autre, que le choix revient au type de charge appliquée au système, voici un essais comparatif.
Présentation des concepts de base de conteneurs et de VM
1 – Qu’est-ce qu’une Machine Virtuelle (VM)
Une machine virtuelle est l’émulation – grace à un hyperviseur – d’un ordinateur complet.
Avec cette technologie, il est possible de ‘simuler’ la présence de plusieurs ordinateurs à partir d’une seule machine physique.
Chaque machine virtuelle:
- se partagent les ressources matérielles de l’ordinateur hôte.
- propose son propre système d’exploitation
- contient l’ensemble de ses services et applications
Cette approche est une solution efficace pour consolider un parc de serveurs.
Les machines virtuelles peuvent consommer une grande quantité de ressources;
- une instance complète de son système d’exploitation
- une copie virtuelle du matériel requis pour son bon fonctionnement.
Cette approche peut parfois être trop gourmande en ressources pour une situation donnée.
Par exemple, l’environnement et les dépendances requises pour l’exécution d’une petite application ‘maison’ en Node.js.
Par contre, cela demeure un choix intéressant pour remplacer un grand nombre de serveurs couteux ou pour mettre en place l’infrastructure requise pour y déployer des applications conteneurisées.
Pour plus de détails, voir ici
2 – Qu’est qu’un conteneur (container)
Avec les conteneurs, au lieu de virtualiser l’ensemble du matériel, seulement le système d’exploitation est virtualisé – Linux ou Windows*.
* Quoi qu’il soit possible de créer des conteneurs pour Windows, la tendance forte est d’exécuter des conteneurs Linux sous Windows en utilisant la couche ‘Windows Subsystems for Linux – wsl‘
Les conteneurs sont situés au dessus du système d’exploitation et du matériels. Ils utilisent le même noyau du système d’exploitation (habituellement Linux), pour des raisons de sécurité, en mode lecture seule. Les conteneurs ont aussi accès aux binaires et aux librairies du système hôte.
Cela réduit considérablement la taille des images de déploiement.
Un autre point fort de cette approche, les applications sont assemblées avec toutes leurs dépendances; librairies, ressources, etc …
Il est aussi possible de conteneuriser chacun des services d’une application; serveur web dans un conteneur + base de données dans un conteneur + app Web dans un autre conteneur, …
On parle alors ici de micro-services.
Donc, lors du déploiement du conteneur, l’administrateur systèmes n’aura pas à se sourcier, par exemple, des conflits possibles de la version ‘php’ installée sur le serveur ou bien de l’impact que pourrait avoir l’absence d’une librairie.
Avant l’avènement des conteneurs, chaque déploiement d’application comportait un grand niveau de complexité pour l’administrateur des systèmes informatiques.
Cette harmonisation des tâches entre le développeur/intégrateur et l’administrateur systèmes est connu sous l’appellation ‘DevOps‘.
L’automatisation des tâches de déploiements des conteneurs peut être effectuée grace à des outils d’orchestration – tel que ‘Kubernetes‘.
Finalement, les cycles complets d’intégration et de déploiement de conteneurs peuvent être réitérés – répétés à l’infini – grace à des outils implémentant l’approche d’Intégration Continue/Distribution Continue ‘CI/DI‘.
3 – Outils pour conteneurs
Docker est, au moment d’écrire ceci, une technologie très populaire pour tout le cycle de développement et de déploiement de conteneurs. Une alternative populaire est Podman.
Il en existe d’autres:
LXD (lexdi)
rkt (rocket)
Serveurs de conteneurs Windows
4 – VM vs Conteneurs
Machines Virtuelles | Conteneurs |
| Des images lourdes – plusieurs dizaines de GO, voir des TO | De très petites images, 50k … 500 MG |
| Performance relative – coût de la virtualisation matériel | Performance native – accès direct au noyau de l’OS |
| Une installation OS complète par VM | Partage du noyau OS entre les conteneurs |
| Virtualisation matériel | Virtualisation du système d’exploitation |
| Longs délais de démarrage – plusieurs minutes | Très courts délais de démarrage – millisecondes |
| Grand besoin en mémoire vive | Consomme peu de ressources mémoires |
| Le système est entièrement isolé, ce qui assure une meilleur sécurité | Isolation au niveau des applications – potentiellement moins sécuritaire |
| Déploiement à grande échelle long et lourd | Déploiement rapide à grande échelle |
| Libraires de base du système | Application livrée avec toutes ses dépendances |
| Offre des outils pour la gestion des infrastructures réseaux et informatiques | Application en vase clos |
| Offre le support pour les outils de déploiement des technologies de conteneurs. | N/A |