0.1À quoi sert Docker : conteneurs vs machines virtuelles
L'essentiel en 30 secondes
- Docker emballe l'application ET son environnement dans un paquet standard, le conteneur : fini le « ça marche sur ma machine ».
- Le conteneur partage le noyau de l'hôte et n'isole que le nécessaire : démarrage en secondes, poids en mégaoctets — ce n'est pas une VM.
- On exécute des images versionnées, identiques partout ; à grande échelle on ajoute un orchestrateur (Swarm, Kubernetes).
Mini-cas filé — Idir en a assez du « ça marche sur ma machine » à Alger
Idir, devops junior à Alger, livre un site qui tourne sur son portable mais casse sur le serveur de test : version de Node différente, Redis manquant, variable oubliée. Il applique la grille de la section : le problème vient de l'environnement, pas du code → il emballe l'application ET son environnement dans des images versionnées (site + cache Redis), lancées en conteneurs. Même image sur son portable, le serveur de test et la production : même comportement partout. Il note aussi la limite : pour deux conteneurs, Docker suffit ; pour des dizaines de services critiques, il faudra un orchestrateur.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 0.1.
1. Le problème : « ça marche sur ma machine »
Une application dépend de sa version de langage, de ses bibliothèques, de son système et de sa configuration. Sur le poste du développeur tout fonctionne, en production tout casse. Docker répond à ce fléau en embarquant l'application ET son environnement dans un paquet standard : le conteneur. Idir retient l'image : le code voyage avec sa valise, pas seul.
2. Conteneur vs machine virtuelle : la vraie différence
Une machine virtuelle virtualise un ordinateur entier (système invité + noyau + ressources réservées) : c'est lourd et lent à démarrer. Un conteneur partage le noyau de l'hôte et n'isole que le nécessaire (processus, fichiers, réseau) : il démarre en secondes, pèse des mégaoctets et se multiplie facilement. C'est l'outil du microservice, pas le remplaçant universel du serveur. Idir tranche : même noyau et besoin léger → conteneur ; noyau différent ou isolement fort → VM.
3. Où Docker s'arrête
Docker emballe et exécute, il n'orchestre pas à grande échelle (c'est le rôle de Swarm ou Kubernetes), ne supervise pas et ne remplace ni la sauvegarde ni la sécurité système. Pour un poste, un petit serveur ou un pipeline CI, Docker suffit ; pour des dizaines de services critiques, on passe à un orchestrateur. Idir cadre son périmètre : Docker pour emballer et exécuter, l'orchestrateur plus tard.
Le saviez-vous ? La cantine qui voyage
Même cantine partout, même goût partout.
🔎 Exemple concret — 🔎 Exemple concret — Un site qui tourne pareil partout
Idir livre un site Node 20 avec Redis : deux conteneurs depuis deux images versionnées, sans installer Node ni Redis sur la machine.
docker run -d -p 3000:3000 --name site mon-app:1.0
docker run -d --name cache redis:7Lecture : deux conteneurs démarrés depuis deux images versionnées, sans installer Node ni Redis sur la machine.
Leçon : le portable, le serveur de test et la production exécutent exactement les mêmes images.
Vocabulaire de la section
- Conteneur
- Un processus isolé + son système de fichiers, démarré depuis une image.
Exemple simple : Idir lance le conteneur site depuis l'image mon-app:1.0.
Ce que ce n'est pas : une machine virtuelle complète avec son noyau.
Réflexe : léger, rapide, un rôle par conteneur.
- Image
- Le modèle immuable et versionné d'où naissent les conteneurs.
Exemple simple : Idir fige mon-app:1.0 : mêmes dépendances sur toutes les machines.
Ce que ce n'est pas : un conteneur vivant que l'on modifie.
Réflexe : toujours un tag de version explicite, jamais latest en production.
- Docker Engine
- Le moteur qui construit, stocke et exécute images et conteneurs.
Exemple simple : Idir vérifie que le moteur tourne avant de lancer son site.
Ce que ce n'est pas : la seule commande docker tapée au clavier.
Réflexe : moteur arrêté = aucun conteneur ne démarre.
- Registre
- Le dépôt d'images versionnées (Docker Hub, GHCR).
Exemple simple : Idir récupère redis:7 depuis le registre au lieu de l'installer.
Ce que ce n'est pas : le disque local de la machine.
Réflexe : nommer l'image avec son tag avant de la partager.
- Port mapping
- La redirection -p 3000:3000 entre la machine et le conteneur.
Exemple simple : Idir joint son site sur le port 3000 grâce au mapping 3000:3000.
Ce que ce n'est pas : le port interne seul, sans exposition.
Réflexe : injoignable ? vérifier le -p d'abord.
En pratique — En pratique — Situer Docker dans votre contexte
- Listez trois logiciels que vous installez péniblement (versions, conflits, docs), comme Idir avec Node et Redis.
- Pour chacun, dites si un conteneur versionné réglerait le problème.
- Repérez un cas où une VM resterait préférable (noyau différent, isolement fort).
- Formulez en une phrase ce que Docker va vous apporter.
Script pas-à-pas — cadrer le cas d'Idir avant d'installer (3 min)
1) Écrivez le duo d'Idir : application + environnement (ex. site Node 20 + Redis) qui diverge entre portable et serveur. 2) Découpez en rôles : un conteneur site, un conteneur cache — jamais tout dans un seul. 3) Notez l'image versionnée visée par rôle (ex. mon-app:1.0, redis:7) : même image sur toutes les machines. 4) Cochez la limite : 2 conteneurs → Docker suffit ; noyau différent ou isolement fort → VM ; dizaines de services → orchestrateur plus tard.
Gardez cette fiche : les sections 0.2 à 0.4 la transforment en commandes réelles.
Modèle copier-coller — ma fiche Docker ou VM ?
Cas : ___ (ex. site Node 20 + Redis d'Idir).
Rôles : [ ] site / [ ] base / [ ] cache → 1 conteneur par rôle.
Images versionnées : ___:___ + ___:___ (jamais latest en production).
Tranchant : [ ] même noyau + léger → conteneur / [ ] noyau différent ou isolement fort → VM.
Échelle : [ ] poste / petit serveur / CI → Docker suffit / [ ] dizaines de services → orchestrateur.Site + cache
Idir livre son site Node 20 avec Redis : deux conteneurs versionnés, zéro installation locale de Node ou Redis.
Noyau différent
Idir doit tester un système au noyau différent : il garde une VM, le conteneur partageant le noyau de l'hôte.
Petit serveur
Deux ou trois services sur un petit serveur : Idir reste sur Docker, sans orchestrateur.
Pipeline CI
Chaque build rejoue les mêmes images versionnées : Idir élimine le « ça marche sur ma machine » de la CI.
✓ Bonnes pratiques
- Pensez image versionnée : jamais de « latest » en production.
- Visez un conteneur = un rôle (web, base, cache).
- Connaissez la limite : l'orchestration, c'est l'étape d'après.
✗ Pièges fréquents
- Croire que Docker = une VM légère (le noyau est partagé).
- Mettre base + app + cache dans le même conteneur.
- Attendre de Docker la supervision et la sauvegarde.
Points clés à retenir
- Docker emballe l'app ET son environnement.
- Le conteneur partage le noyau : léger et rapide.
- On exécute des images versionnées, identiques partout.
- À grande échelle, on ajoute un orchestrateur.
Défi 48h — appliquez demain
Remplissez la fiche Docker ou VM du modèle sur UN cas réel (celui d'Idir ou le vôtre) : rôles, images versionnées, tranchant conteneur/VM — en une phrase, dites ce que Docker va vous apporter.
- Je peux expliquer en une phrase ce que Docker apporte (app + environnement, même image partout).
- Je sais trancher conteneur (léger, même noyau) vs VM (noyau différent, isolement fort).
- Je connais la limite : orchestration, supervision et sauvegarde sont hors Docker.
Questions fréquentes
Docker remplace-t-il une machine virtuelle ?
Non : la VM isole un système complet avec son noyau, le conteneur partage celui de l'hôte. Pour des noyaux différents (Windows vs Linux) ou un isolement fort, la VM reste pertinente. Idir garde le réflexe : même noyau et besoin léger → conteneur ; sinon → VM.
Faut-il être administrateur système pour Docker ?
Non : les bases (run, ps, logs, volumes, Compose) s'apprennent en quelques heures. L'administration fine (réseaux, registres, sécurité) vient ensuite, niveau par niveau — exactement la progression de ce guide.
Qu'est-ce qui fait la vraie force de Docker par rapport à une installation classique ?