Chapitre 12.5 — Docker ou bare-metal

⏱️ TL;DR — Docker n’est pas obligatoire. Tout ce que tu as fait dans les Parties 9 à 11 — installer Node, faire tourner l’app en service systemd derrière Nginx, brancher Postgres — c’est du bare-metal (installation directe sur la machine), et ça marche très bien. La vraie question n’est pas « Docker c’est mieux ? » mais « Docker pour quoi faire ? ». Docker brille sur la reproductibilité, l’isolation, le multi-services et la parité dev/prod ; il coûte une courbe d’apprentissage, une couche d’abstraction de plus (réseaux, volumes) et un peu de ressources. Bare-metal gagne sur une app unique simple : moins de couches, débogage direct, rien à apprendre de neuf. Ce chapitre te donne l’arbre de décision honnête — et rappelle qu’on peut mélanger.

🎯 Objectifs

Nommer les vrais gains de Docker et son coût réel.
Décrire ce que « bare-metal » veut dire (systemd + Nginx, installation directe).
Savoir quand chacun gagne, selon le projet et l’équipe.
Comprendre qu’on peut panacher les deux approches.
Décider avec un arbre de décision, sans hype ni dogme.

Deux façons de faire tourner la même app

Reprenons FormaCampus. Le front Next peut tourner de deux manières sur le VPS :

Bare-metal (Parties 9-11) : Node installé sur la machine, le code buildé sur place, un service systemd formacampus-web.service qui lance next start, Nginx de l’hôte devant, Postgres installé via apt. Tout est posé directement sur le système.
Docker (ce chapitre) : le même front dans une image, lancé par docker compose, avec Postgres en conteneur et un volume pour ses données.

Les deux servent la même page au visiteur. La différence est dans comment l’environnement est géré : bricolé à la main sur la machine (bare-metal) ou décrit et figé dans une image (Docker).

Ce que Docker t’apporte vraiment

Reproductibilité. L’environnement est décrit (Dockerfile) et identique partout. Fin du « ça marche chez moi » : dev, CI et prod partagent la même image.
Isolation. Chaque app a ses dépendances, sa version de runtime. Deux projets qui exigent deux versions de Node cohabitent sans conflit — impossible proprement en bare-metal sans jongler avec nvm et compagnie.
Multi-services. Front + API + base + proxy + cache, orchestrés d’une commande (compose up), avec le réseau et l’ordre de démarrage gérés pour toi.
Portabilité. L’image tourne sur n’importe quel hôte qui a Docker : tu changes de VPS, tu pull et tu up, sans réinstaller quoi que ce soit.
CI/CD facilité. Construire une image en CI et la déployer est plus simple et plus fiable que de synchroniser des fichiers et redémarrer des services à la main (Partie 13).

Ce que Docker te coûte (l’honnêteté)

Aucune magie sans contrepartie :

Courbe d’apprentissage. Images, layers, volumes, réseaux, compose, registres : c’est une couche de concepts à digérer en plus de Linux. Pour un dev qui débute l’admin serveur, c’est beaucoup d’un coup.
Abstraction en plus. Un problème réseau ou de permissions passe désormais par la médiation de Docker : le débogage a un niveau d’indirection supplémentaire (« l’app ou le conteneur ou le réseau Docker ou le volume ? »).
Ressources. Le démon, les images, les couches consomment un peu de RAM et surtout de disque (le piège du disque plein, chapitre 12.4). Négligeable sur un VPS correct, réel sur une toute petite machine.
Complexité opérationnelle. Volumes à sauvegarder correctement, logs à borner, images à nettoyer : de nouveaux gestes d’hygiène à ne pas oublier.

⚠️ Piège — Dockeriser par mode, sans besoin réel. Mettre une app unique et simple dans Docker « parce que c’est moderne » t’ajoute une couche à apprendre et à maintenir sans rien résoudre que tu avais comme problème. Docker répond à des besoins précis (repro, isolation, multi-services, parité) — si tu n’en as aucun, un bon vieux service systemd + Nginx est plus simple à opérer et à déboguer. L’outil doit servir un besoin, pas une tendance.

Ce que bare-metal t’apporte

L’installation directe n’est ni dépassée ni honteuse — c’est souvent le bon choix :

Simplicité. Une app, un service systemd, un server block Nginx. Aucune couche entre ton code et le système. Ce que tu vois est ce qui tourne.
Débogage direct. journalctl -u formacampus-web, htop, les fichiers sont là, à leur place FHS habituelle. Pas d’indirection conteneur.
Rien de neuf à apprendre. Tu maîtrises déjà systemd, Nginx, apt (Parties 2 à 11). Zéro concept supplémentaire.
Moins de ressources. Pas de démon Docker, pas de couches d’images : tout va à l’app.

💡 Réflexe — Pour une seule app que tu es seul à opérer, sur un VPS que tu ne changeras pas tous les six mois, bare-metal est souvent le choix le plus sobre. Tu ne « perds » rien : la reproductibilité, tu l’obtiens autrement (un script d’install versionné, une doc à jour). Docker devient rentable quand la complexité (services multiples, équipe, environnements) dépasse ce que la main gère confortablement.

Quand chacun gagne

Situation	Plutôt bare-metal	Plutôt Docker
Nombre d’apps/services	Une app simple	Plusieurs services (front + API + base + cache…)
Équipe	Solo, une personne opère	Plusieurs devs, besoin de parité dev/prod
Environnements	Un seul (la prod)	Dev + CI + prod à garder identiques
Conflits de versions	Aucun	Plusieurs projets, runtimes différents
Portabilité	VPS stable, pas de migration	Changements d’hôte fréquents, scaling
Courbe d’apprentissage acceptable	On veut le minimum de concepts	On investit, l’équipe connaît Docker
Débogage	On veut du direct, sans couche	On accepte l’indirection pour le reste
CI/CD	Déploiement `rsync`/SSH simple	Pipeline d’images, registres

Aucune ligne n’est un absolu : c’est la somme qui penche d’un côté. Une app unique, solo, sur un VPS stable → bare-metal. Une plateforme multi-services, en équipe, avec CI et parité dev/prod → Docker.

L’arbre de décision

Lis-le à l’envers pour t’en convaincre : c’est l’accumulation de besoins (multi-services ou équipe/parité ou conflits/portabilité) qui justifie Docker. En l’absence de tous, bare-metal reste le plus simple.

On peut mélanger

Le débat « l’un ou l’autre » est en partie faux. Les deux approches cohabitent très bien sur le même VPS :

Nginx sur l’hôte (bare-metal), apps en conteneurs derrière — l’option A du chapitre 12.4. Le meilleur des deux : proxy maîtrisé + apps reproductibles.
Postgres en bare-metal (installé via apt, sauvegardé classiquement) et le reste en conteneurs — certaines équipes préfèrent garder leur base hors Docker pour un contrôle total du stockage et des sauvegardes.
App conteneurisée, mais jobs cron et scripts d’admin directement sur l’hôte.

🧭 Sur FormaCampus — Le choix final de FormaCampus est hybride et assumé. Le front Next et l’API Symfony partent en conteneurs (compose) : ce sont deux services à maintenir en parité entre trois postes de dev, la CI et la prod — Docker y règle un vrai problème quotidien. Nginx reste sur l’hôte (bare-metal), avec Certbot, parce que l’équipe le maîtrise depuis les Parties 7-8 et n’a aucune raison de le conteneuriser. Pour Postgres, l’équipe hésite : conteneur + volume (parité dev/prod) ou installation bare-metal (contrôle du stockage et des sauvegardes) ; elle tranche pour le conteneur avec volume sauvegardé, quitte à réévaluer si la base grossit beaucoup. Le fil conducteur : Docker là où il résout un problème réel (parité multi-services), bare-metal là où il est plus simple (le proxy). Pas de dogme, des décisions.

🔒 Sécurité — Ni Docker ni bare-metal n’est « plus sûr » dans l’absolu ; ils déplacent la surface. Bare-metal : un système à durcir (Parties 4-5), des services non-root, un pare-feu. Docker : des images à maintenir à jour, le socket à protéger, le groupe docker = root, les ports à ne pas exposer. Dans les deux cas, la sécurité vient de tes gestes, pas de l’outil. Choisir Docker ne te dispense d’aucun des fondamentaux de sécurité du cours.

📚 La doc — Ce chapitre est un cadre de décision, pas une vérité figée. Les besoins d’un projet évoluent : une app solo bare-metal aujourd’hui peut mériter Docker quand une deuxième brique arrive. Réévalue le choix quand le contexte change (nouveau service, nouvelle recrue, migration d’hôte), plutôt que de t’enfermer dans une décision prise une fois.

Conclusion — un outil, pas une religion

Docker est un excellent outil pour des problèmes précis : reproductibilité, isolation, orchestration multi-services, parité dev/prod, industrialisation CI/CD. Ce sont de vrais gains, pas du marketing. Mais ce ne sont pas tes problèmes par défaut. Si tu opères une app simple, seul, sur un VPS stable, le trio systemd + Nginx + apt que tu maîtrises déjà est plus sobre et parfaitement professionnel. Le bon réflexe n’est ni « toujours Docker » ni « jamais Docker », mais : quel problème est-ce que je résous, et Docker le résout-il mieux que la simplicité que je perds ? Réponds à ça, et tu choisiras juste.

✏️ Exercices

Exercice 1 — Trois projets, trois choix. Docker ou bare-metal (et pourquoi) ? (a) Un blog personnel Next.js, un seul dev, sur un petit VPS gardé des années. (b) Une plateforme SaaS avec front, API, base et cache Redis, une équipe de quatre devs, dev + staging + prod. (c) Un script Python qui tourne une fois par nuit en cron.

✅ Solution

(a) Bare-metal. Une app, un dev, un VPS stable : aucun des déclencheurs Docker n’est présent. systemd + Nginx suffit, plus simple à opérer. (b) Docker. Multi-services et équipe et parité dev/staging/prod : les trois raisons de dockeriser sont réunies, compose orchestre tout et garantit l’identité des environnements. (c) Bare-metal (cron sur l’hôte). Un script solitaire nocturne n’a besoin ni d’isolation ni d’orchestration ; un cron + un venv Python est bien plus simple qu’une image. On pourrait le conteneuriser si son environnement était pénible à reproduire, mais par défaut : non.

Exercice 2 — Démonte le dogme. Un collègue affirme : « En 2026, tout doit être dockerisé, le bare-metal c’est du legacy. » Donne deux arguments concrets qui nuancent.

✅ Solution

Par exemple : (1) pour une app unique opérée par une personne, Docker ajoute une couche de concepts (images, volumes, réseaux) et un niveau d’indirection au débogage sans résoudre de problème existant — un service systemd est plus direct. (2) Docker n’est pas « plus sûr » ni « plus moderne » en soi : mal opéré (socket exposé, ports ouverts, images jamais mises à jour, disque saturé), il ajoute des surfaces de risque. Le bare-metal reste parfaitement professionnel et est toujours ce qui tourne sous beaucoup de Docker (le démon, Nginx…). L’outil se choisit sur le besoin, pas sur la mode.

Exercice 3 — Conçois l’hybride. Sur un VPS, tu veux : Nginx que tu maîtrises déjà, une app Next et une API à garder en parité dev/prod, une base dont tu veux contrôler finement les sauvegardes. Propose une répartition Docker / bare-metal et justifie.

✅ Solution

Nginx en bare-metal (hôte, avec Certbot) : acquis maîtrisé, aucun besoin de le conteneuriser, il proxifie les apps publiées en local. Next + API en conteneurs (compose) : deux services à garder identiques entre dev et prod → Docker y règle un vrai problème de parité. Base : au choix argumenté — conteneur + volume sauvegardé (parité maximale) ou Postgres bare-metal (contrôle total du stockage/pg_dump) si tu privilégies la maîtrise des sauvegardes. Les deux se défendent ; l’essentiel est de justifier selon ta priorité (parité vs contrôle du stockage). C’est exactement l’approche hybride de FormaCampus.

🧠 Quiz de révision

1. Que signifie « bare-metal » ici, concrètement ?

L’installation directe de l’app sur la machine : Node/PHP posés via apt, l’app en service systemd, Nginx de l’hôte devant, Postgres installé sur le système — sans couche de conteneurisation. C’est ce qu’on a fait aux Parties 9 à 11.

2. Cite trois gains réels de Docker.

Parmi : reproductibilité (environnement figé, identique partout), isolation (dépendances/versions par app, pas de conflit), multi-services (orchestration d’une commande), portabilité (tourne sur tout hôte avec Docker), CI/CD facilité.

3. Cite deux coûts réels de Docker.

Parmi : courbe d’apprentissage (couche de concepts en plus), abstraction au débogage (indirection réseau/volume), ressources (RAM/disque, images à nettoyer), complexité opérationnelle (volumes, logs, hygiène du disque).

4. Dans quel cas typique bare-metal est-il le meilleur choix ?

Une app unique et simple, opérée par une seule personne, sur un VPS stable, sans conflit de versions ni besoin de parité multi-environnements. Le trio systemd + Nginx + apt est alors plus sobre et plus direct à déboguer.

5. Peut-on mélanger les deux ? Donne un exemple.

Oui, et c’est fréquent. Exemple : Nginx sur l’hôte (bare-metal) qui proxifie des apps en conteneurs derrière ; ou une base bare-metal avec le reste conteneurisé. On met Docker là où il résout un problème, bare-metal là où il est plus simple.

Fin de la Partie 12. Ton app est conteneurisée et tourne proprement en prod. On automatise maintenant sa livraison : Partie 13 — CI/CD & automatiser — construire l’image et déployer à chaque merge, sans intervention manuelle.