MonTour dans un conteneur : le projet et la méthode
Vous allez mettre MonTour dans des conteneurs, de votre poste jusqu’à un VPS en HTTPS. Ce chapitre fixe le projet, la méthode et le dépôt de départ.
Module 0 · Démarrer vite et sereinement
Objectif du chapitre
Vous savez ce que vous allez construire, pourquoi chaque brique existe et comment chaque chapitre se déroule. Vous récupérez le dépôt de départ au tag docker-start. Durée : 25 min · 60 % pratique.
Comment lire le schéma
- De gauche à droite et de haut en bas : vous poussez le code, GitLab CI construit l’image, la teste et la scanne (violet).
- L’image validée est rangée dans le registre (jaune) avec un tag unique, le hash du commit.
- Le VPS télécharge exactement cette image et la lance. Caddy reçoit le trafic HTTPS et le transmet au conteneur MonTour.
- La base reste chez Supabase (pointillés) : le VPS ne fait tourner que l’application.
Le projet : MonTour, mais cette fois en conteneurs
MonTour est une file d’attente virtuelle par QR code : le commerçant affiche une affiche, le client scanne, reçoit un numéro et suit sa place en direct. Dans la formation Coder avec l’IA, l’application était déployée sur Vercel. Ici, vous reprenez la main sur toute la chaîne :
- Une image Docker de MonTour, légère (moins de 200 Mo) et sans secret.
- Un environnement local lancé avec
docker compose up: application, base et outils, identiques pour toute l’équipe. - Un pipeline GitLab CI qui construit l’image, lance les tests dans des conteneurs, la scanne et la publie dans le registre.
- Un VPS où Caddy sert MonTour en HTTPS, mis à jour à chaque merge sur
main, avec un retour arrière en une commande.
Pourquoi Docker pour une application comme MonTour
- « Ça marche sur ma machine » disparaît : la même image tourne sur votre poste, dans la CI et en production.
- Vous ne dépendez plus d’un hébergeur : un VPS à quelques euros suffit, et vous pouvez changer de fournisseur en une journée.
- La sécurité devient vérifiable : ce qui est dans l’image est listé (SBOM), scanné et versionné.
- Le retour arrière est trivial : chaque version est une image taguée ; revenir en arrière, c’est relancer la précédente.
La boucle de chaque chapitre
- Objectif : une phrase, un résultat visible.
- Test : la commande qui prouve que c’est fait (
docker run,curl, un healthcheck vert). - Prompt : une demande précise à l’IA, avec le contexte du projet et un point de départ (tag Git).
- Relire : chaque ligne du Dockerfile ou du fichier Compose, avec la grille du chapitre.
- Commit : un petit pas historisé, puis un tag
dkNNen fin de chapitre. - Pipeline vert : à partir du module 3, GitLab CI valide chaque push.
Pratique : récupérez le dépôt de départ
Clonez le dépôt fourni (ou votre propre MonTour), placez-vous sur le tag docker-start et créez votre branche de travail. Vérifiez que l’application démarre encore sans Docker : c’est votre point de comparaison.
git clone https://gitlab.com/<votre-groupe>/montour.git
cd montour
git switch -c formation-docker docker-start
npm ci && npm run build # doit réussir avant de conteneuriser quoi que ce soit
Ce que l’IA fait, et ce que vous faites
- L’IA propose : un Dockerfile, un fichier Compose, un job de pipeline, une commande de diagnostic.
- Vous décidez : l’image de base, ce qui entre dans l’image, les ports exposés, les droits du conteneur.
- Les tests tranchent : une image qui ne démarre pas, qui tourne en root ou qui contient un secret ne passe pas.
Réflexe sécurité
Un Dockerfile généré par une IA contient souvent COPY . . sans .dockerignore : votre fichier .env.local finit alors dans l’image, lisible par toute personne qui la télécharge. Vous verrez dès le chapitre 03 comment l’empêcher, et le pipeline le bloquera au chapitre 14.
Les règles du jeu
- Un chapitre = une branche courte, un ou plusieurs commits, un tag
dkNNà la fin. - Aucune image n’est poussée à la main en production : seul le pipeline publie.
- Chaque Dockerfile est relu avec la grille avant le commit.
- Chaque chapitre contient une partie à faire sans IA, pour que vous sachiez lire et corriger ce qui est généré.
Le prompt reproductible
Même point de départ, même contexte, même résultat : partez du tag indiqué et collez ce prompt tel quel.
Point de départ : tag docker-start du dépôt MonTour (Next.js App Router + Supabase).
Rôle : tu es mon binôme DevOps pour la formation Docker.
Tâche : lis package.json, next.config.* et .env.example, puis liste en 10 lignes
maximum ce qu'il faudra pour conteneuriser l'application :
version de Node, commande de build, port, variables publiques (NEXT_PUBLIC_*)
et variables serveur.
Contraintes : ne crée ni ne modifie aucun fichier. Ne recopie aucune valeur
de secret, seulement les noms de variables.
Qualité et sécurité : ce que vous vérifiez
- Le build fonctionne sans Docker : on ne conteneurise jamais une application qui ne se construit pas.
- La liste des variables est complète et séparée en deux : publiques (gravées au build) et serveur (fournies au démarrage).
- Sans IA : retrouvez vous-même la version de Node exigée (champ
enginesou fichier.nvmrc) et comparez avec la réponse de l’assistant.
Outillage IA de ce chapitre
Connecteurs MCP : aucun. Le connecteur Docker arrive au chapitre 24, en lecture seule.
Agents : aucun. Un seul assistant, qui lit mais ne modifie rien.
Vérifier
- ☐ Le dépôt est cloné et la branche
formation-dockerpart du tagdocker-start. - ☐
npm run buildréussit sans Docker. - ☐ Vous avez la liste des variables publiques et serveur de MonTour.
- ☐ Vous savez expliquer en une phrase le rôle de l’image, du pipeline, du registre et du VPS.
Défi
Dessinez à la main le schéma de l’architecture cible sans regarder celui du chapitre, puis comparez. Ce qui manque est ce que vous comprendrez le mieux au fil des modules.
Pour aller plus loin
Suivez votre progression. Créez un compte gratuit pour cocher vos leçons et reprendre là où vous en étiez.
Créer un compte gratuit