VMs vs conteneurs Docker
En PME, vous entendrez de plus en plus parler de Docker. Comprendre la différence avec une VM vous évitera de choisir le mauvais outil lors d'un déploiement — et de répondre correctement quand un utilisateur demande "on ne peut pas juste utiliser Docker ?".
La VM : un OS complet isolé
Une VM embarque son propre noyau (kernel) et tout un OS guest. Elle est totalement isolée du système hôte. C'est lourd (plusieurs Go sur disque, plusieurs minutes à démarrer) mais parfaitement isolé et compatible avec n'importe quel OS.
Le conteneur : un processus isolé
Un conteneur partage le kernel de l'OS hôte. Il isole uniquement l'espace utilisateur (bibliothèques, dépendances, application). Résultat : démarrage en secondes, quelques Mo sur disque, mais limité au kernel Linux de l'hôte.
graph LR
subgraph VM["Machine Virtuelle"]
HV[Hyperviseur] --> GOS[OS Guest complet]
GOS --> APP1[Application]
end
subgraph CT["Conteneur Docker"]
DE[Docker Engine] --> LIB[Libs + dépendances]
LIB --> APP2[Application]
DE -->|partage| KRN[Kernel Linux hôte]
end
Cas concret : GLPI en VM vs GLPI en Docker
GLPI en VM : vous créez une VM Ubuntu Server, installez Apache, MariaDB, PHP, GLPI. Si la VM crashe, elle n'impacte pas le reste. Idéal si vous voulez un snapshot avant mise à jour.
GLPI en Docker : vous lancez docker compose up avec le fichier officiel. Déploiement en 5 minutes, mise à jour facile. Mais si le serveur Linux hôte plante, tous vos conteneurs tombent ensemble.
Règle en PME : VM pour les services critiques (AD, fichiers) qui nécessitent isolation forte et snapshots. Docker pour les outils internes (GLPI, Nextcloud, monitoring) où la rapidité de déploiement prime.