5.3Docker pour Node.js
L'essentiel en 30 secondes
- Fin du « ça marche sur ma machine » : le conteneur embarque l'app avec son environnement et tourne identiquement partout.
- Image → conteneur : le Dockerfile décrit la recette, docker build fige l'image, docker run lance le conteneur.
- Compose pour la pile : app + base + cache décrits dans un fichier et lancés ensemble — onboarding en une commande.
Mini-cas filé — Salim conteneurise à Alger
L'API de Salim tourne parfaitement sur son poste à Alger — mais plante chez sa collègue (version de Node différente, variable manquante). Il écrit un Dockerfile : image de base Node, dépendances installées dans l'image, commande de démarrage. Puis un fichier Compose avec la base de données : un seul lancement monte toute la pile. Suite des cas 5.1-5.2 — Salim rend son app reproductible partout.
Suite des cas 5.1-5.2 — Salim passe de « chez moi ça marche » à « partout pareil ».
1. Conteneuriser : image et conteneur
Docker résout le « ça marche sur ma machine » en empaquetant l'application avec tout son environnement (version de Node, dépendances, configuration) dans un conteneur isolé et portable, qui tourne identiquement partout : poste, collègue, serveur, cloud. Concepts : l'image (modèle figé de l'app + environnement, défini par un Dockerfile — la recette : image de base Node, copier le code, installer les dépendances, commande de démarrage) et le conteneur (instance en exécution d'une image). On construit (docker build), on lance (docker run). Le .dockerignore exclut l'inutile de l'image (node_modules — les dépendances s'installent DANS l'image). Salim ne débat plus des versions : l'environnement voyage avec le code.
Réflexe : tout ce qui est spécifique à votre poste et absent de l'image est un futur plantage ailleurs — l'image doit tout contenir.
2. Docker Compose et bénéfices
Pour une pile réaliste (app + base + cache), Docker Compose (docker-compose.yml) définit plusieurs conteneurs et leurs relations, lancés ensemble d'une commande (docker compose up). Un seul fichier décrit toute la pile, reproductible à l'identique — et l'onboarding devient trivial : un nouveau développeur lance une commande et obtient tout l'environnement. Bénéfices : reproductibilité (identique partout), isolation (pas de conflits entre apps et versions), portabilité (tout hôte Docker), facilité de déploiement (déployer = lancer le conteneur — voir 5.4). Salim ajoute la base au Compose : sa collègue démarre en minutes.
Docker est un standard du développement moderne et une compétence transversale (DevOps) : les bases suffisent pour commencer, l'orchestration avancée viendra selon les besoins.
3. Le bon dosage pour un développeur
Pas besoin de devenir expert infrastructure : visez les bases utiles — écrire un Dockerfile simple, construire et lancer, orchestrer app + base avec Compose, exclure l'inutile via .dockerignore. Maîtrisez Node d'abord (votre cœur de métier), ajoutez Docker quand vous travaillez en équipe, préparez un déploiement ou gérez plusieurs services. À éviter : inclure node_modules dans l'image, viser l'orchestration avancée avant les bases, ou conteneuriser un minuscule script d'apprentissage sans besoin réel. Salim garde son Dockerfile lisible : six instructions comprises valent mieux qu'une recette copiée.
Le bon profil : un développeur qui connaît les bases de l'exploitation — autonome, capable non seulement de coder mais de livrer.
Le saviez-vous ?
Même image, même comportement — partout.
🔎 Exemple concret — Le Dockerfile de Salim
La recette de l'image, lisible en six lignes.
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "app.js"]
# .dockerignore : node_modules
# docker compose up → app + base ensembleLecture : chaque instruction a un rôle — base, dépendances, code, démarrage.
Leçon : un Dockerfile compris vaut mieux qu'une recette copiée.
Vocabulaire de la section
- Docker
- Outil qui empaquette l'app avec son environnement dans un conteneur portable.
Exemple simple : L'API de Salim tourne pareil à Alger et chez sa collègue.
Ce que ce n'est pas : un simple installeur de Node sur chaque poste.
Réflexe : mon app dépend-elle encore de mon poste ?
- Image
- Modèle figé de l'app + environnement, construit depuis le Dockerfile.
Exemple simple : Salim construit une image versionnée de chaque livraison.
Ce que ce n'est pas : le conteneur en cours d'exécution.
Réflexe : puis-je reconstruire cette image à l'identique ?
- Dockerfile
- Recette de construction de l'image (base, code, dépendances, démarrage).
Exemple simple : Six instructions lisibles pour l'API de Salim.
Ce que ce n'est pas : un script qui installe Node à la main sur un serveur.
Réflexe : chaque instruction est-elle comprise, pas copiée ?
- Conteneur
- Instance en exécution d'une image, isolée et portable.
Exemple simple : Salim lance un conteneur identique en dev et en recette.
Ce que ce n'est pas : l'image figée elle-même.
Réflexe : dev et prod lancent-ils la même image ?
- Docker Compose
- Fichier décrivant plusieurs conteneurs lancés ensemble.
Exemple simple : App + base de Salim démarrées d'une seule commande.
Ce que ce n'est pas : l'orchestration avancée de type Kubernetes.
Réflexe : un nouveau dev démarre-t-il en une commande ?
En pratique — Conteneuriser une application Node
- Écrivez un Dockerfile : partir d'une image Node, copier le code, installer les dépendances (npm install), définir la commande de démarrage. Ajoutez un .dockerignore (node_modules…).
- Construisez l'image (`docker build`) et lancez un conteneur (`docker run`) ; vérifiez que l'application tourne dans le conteneur.
- Orchestrez avec Docker Compose : un docker-compose.yml définissant l'app Node ET sa base, lancés ensemble (`docker compose up`).
- Appréciez les bénéfices : reproductibilité (identique partout), isolation, et onboarding (un `docker compose up` suffit pour tout l'environnement).
Script prêt à dire — proposer Docker à l'équipe
« Notre API marche sur mon poste mais pas ailleurs : c'est un problème d'environnement, pas de code. Je propose un Dockerfile simple — six instructions — plus un Compose avec la base. Chacun lancera la même image, et un nouvel arrivant démarrera en une commande. On garde ça lisible et on évite l'orchestration avancée pour l'instant. »
À dire en réunion d'équipe pour faire adopter la conteneurisation sans viser l'expertise DevOps.
Modèle copier-coller — Dockerfile Node générique
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]
# .dockerignore :
# node_modules
# npm-debug.log
# .gitSolo / petit budget
Salim seul : un Dockerfile simple sans Compose suffit — l'image fige déjà l'environnement.
TPE / équipe réduite
Compose app + base : chaque collègue démarre la pile complète sans installation manuelle.
PME à Alger
Salim partage l'image avec l'équipe à Alger : tout le monde teste la même version, fin des écarts de poste.
Équipe qui démarre
Binôme : l'un écrit le Dockerfile, l'autre le relit ligne à ligne ; build testé sur deux postes avant adoption.
✓ Bonnes pratiques
- Maîtriser Node d'abord, puis apprendre les bases de Docker.
- Ajouter un .dockerignore (exclure node_modules).
- Utiliser Docker Compose pour orchestrer app + base (onboarding rapide).
✗ Pièges fréquents
- Inclure node_modules dans l'image (l'installer dans l'image via npm install).
- Vouloir maîtriser l'orchestration avancée avant les bases.
- Conteneuriser un tout petit script d'apprentissage sans besoin réel.
Points clés à retenir
- DOCKER empaquette l'application AVEC son environnement dans un CONTENEUR isolé et portable, qui tourne IDENTIQUEMENT partout — fin du « ça marche sur ma machine ».
- IMAGE (modèle figé, défini par un DOCKERFILE) → CONTENEUR (instance). `docker build` / `docker run`. .dockerignore exclut node_modules.
- DOCKER COMPOSE définit PLUSIEURS conteneurs (app + base + cache) lancés ensemble (`docker compose up`) — décrit toute la pile, reproductible.
- Bénéfices : REPRODUCTIBILITÉ, isolation, portabilité, facilité de déploiement, onboarding rapide. Standard moderne (transversal DevOps).
Défi 48h — appliquez demain
Écrivez le Dockerfile de votre app (modèle ci-dessus) et lancez-la en conteneur : répond-elle pareil que sur votre poste ?
- Je peux expliquer image vs conteneur en une phrase.
- Mon Dockerfile construit une image qui tourne.
- Je sais pourquoi node_modules n'y figure pas.
Questions fréquentes
Qu'apporte concrètement Docker, et est-ce nécessaire pour un développeur Node ?
Docker apporte surtout la reproductibilité : fin du « ça marche sur ma machine » (le conteneur embarque tout, donc tourne identiquement partout). Aussi : isolation (plusieurs apps/versions sans conflits), portabilité (tout hôte Docker), facilité de déploiement (déployer = lancer le conteneur), onboarding rapide (un docker compose up monte toute la pile). Pour apprendre Node ou de petits projets solo, non strictement. Pour du développement professionnel, en équipe ou avec déploiement, c'est devenu quasi incontournable — et transversal. Maîtrisez Node d'abord, puis les bases de Docker.
Docker, déploiement, CI/CD... dois-je devenir un expert DevOps en plus de développeur ?
Non, pas un expert — mais connaître les bases bénéficie énormément : autonomie (mettre son travail en production), employabilité (offres demandant Docker/déploiement/CI-CD), meilleure collaboration (apps faciles à déployer), vision complète du cycle. Visez les bases : conteneuriser et Compose (pas l'orchestration avancée), déployer sur une plateforme simple, un pipeline CI/CD simple, secrets et config en variables d'environnement, notions de logs/monitoring/HTTPS. Le bon profil : un développeur qui connaît les bases de l'exploitation — capable non seulement de coder mais de livrer.
Quel problème Docker résout-il principalement ?