Docker : isoler vos projets

Vous allez faire tourner plusieurs projets sur cette machine. L’un est resté sur Node 20, l’autre veut Node 24. Celui-ci a besoin d’une vieille version d’une librairie, celui-là de la dernière. Installés « en vrac » sur le système, ils finissent par se marcher dessus, et vous tombez sur le grand classique : « pourtant ça marchait avant ». Docker règle ce problème une bonne fois : chaque projet vit dans sa propre bulle étanche.

Pourquoi ça change la vie (surtout avec un agent)

Trois raisons, et la troisième est sous-estimée :

• Fini les conflits de versions. Chaque projet embarque son environnement exact. Node 20 ici, Node 24 là, sans interférence. Vous n’installez plus rien « globalement » qui risque de casser un autre projet.
• Des déploiements reproductibles. Le conteneur qui tourne chez vous est identique à celui qui tournera en ligne. Le « ça marche sur ma machine » disparaît : votre machine, c’est le conteneur. Ça simplifie énormément la mise en ligne (voir Cloudflare Tunnel).
• Les dégâts restent dans la boîte. C’est le point clé pour qui bosse avec un agent. Un agent qui expérimente, une dépendance louche, un script qui dérape : enfermés dans un conteneur, ils ne peuvent pas saccager toute la machine. C’est le niveau d’isolation au-dessus du « dossier de projet », un vrai bac à sable par projet (à relier à Sécuriser les accès).

Installer Docker

# La méthode officielle, en une commande
curl -fsSL https://get.docker.com | sudo sh
# Autorise ton utilisateur à piloter Docker sans sudo (déconnecte/reconnecte ensuite)
sudo usermod -aG docker $USER

Vérifiez : docker run hello-world doit télécharger une mini-image et afficher un message de bienvenue. Si vous le voyez, vous êtes prêt.

Niveau 1, lancer un truc existant (débutant)

Le plus beau de Docker au début, c’est que vous profitez du travail des autres. Des dizaines de milliers d’applications sont déjà « emboîtées », prêtes à lancer. Besoin d’une base de données PostgreSQL pour un projet ? Pas d’installation laborieuse :

# Lance une base PostgreSQL isolée, en une ligne
docker run -d --name ma-db -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres:16
docker ps              # voir ce qui tourne
docker logs ma-db      # voir les journaux
docker stop ma-db      # arrêter (docker start ma-db pour relancer)
docker rm ma-db        # supprimer le conteneur (la boîte disparaît proprement)

Niveau 2, un mini-projet à plusieurs services (Docker Compose)

La plupart des projets, c’est plusieurs morceaux : une app + une base de données, par exemple. Docker Compose décrit tout ça dans un seul fichier compose.yml, et lance l’ensemble d’une commande.

# compose.yml, une petite app web + sa base, isolées ensemble
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - db-data:/var/lib/postgresql/data   # les données survivent aux redémarrages
volumes:
  db-data:

docker compose up -d      # tout démarre, en arrière-plan
docker compose logs -f    # suivre ce qui se passe
docker compose down       # tout arrêter et nettoyer

Niveau 3, emballer VOTRE projet (le Dockerfile)

Pour mettre votre propre code en boîte, vous écrivez un Dockerfile : la recette qui dit comment construire l’image de votre projet.

# Dockerfile, la recette de ta boîte
# (un commentaire Docker tient sur sa propre ligne : un # en fin de ligne serait lu comme un argument)
# On part d'une image Node officielle, légère
FROM node:24-slim
WORKDIR /app
COPY package*.json ./
# Installe les dépendances DANS la boîte
RUN npm ci
COPY . .
EXPOSE 8080
# La commande qui démarre l'app
CMD ["node", "server.js"]

docker build -t mon-app .   # construit l'image à partir du Dockerfile
docker run -d -p 8080:8080 mon-app

Désormais, votre projet et son environnement ne font qu’un. Vous pouvez le lancer sur n’importe quelle machine qui a Docker, à l’identique.

Niveau expert, durcir l’isolation

Le conteneur isole déjà beaucoup, mais par défaut il ne s’arrête pas là où il pourrait. Quand vous hébergez un service exposé, ou que vous confinez un agent, resserrez les boulons :

• Ne tournez pas en root dans le conteneur : ajoutez un utilisateur non privilégié (USER node) dans votre Dockerfile. Si quelqu’un s’échappe de l’app, il n’est pas root.
• Système de fichiers en lecture seule : docker run --read-only empêche le conteneur d’écrire là où il ne devrait pas.
• Limitez les ressources : --memory=512m --cpus=1 empêche un conteneur emballé d’asphyxier toute la machine.
• Réduisez les privilèges : --cap-drop=ALL retire les capacités Linux inutiles ; vous n’en rajoutez que si nécessaire.
• Isolez le réseau : ne publiez (-p) que les ports réellement nécessaires ; le reste reste invisible. Et ce que vous publiez vers l’extérieur passe par Cloudflare Tunnel ou reste sur Tailscale, jamais en clair sur Internet.