Dockerisez la borne
d'accueil Next.js

Comprenez ce que fait l'application avant de l'emballer. Si vous avez Node.js >= 18 sur votre poste, lancez-la en local. Sinon, lisez le code, c'est court.

Indications

Si Node est installe :

$ cd application/
$ npm install
$ npm run dev

Ouvrez http://localhost:3000/. Vous voyez la carte SVG du parc avec quatre pavillons cliquables, et l'onglet "Horaires" qui montre les activites de la journee.

Si Node n'est pas installe, ouvrez application/app/page.js dans votre editeur. C'est un seul composant React de quelques centaines de lignes : tableaux de pavillons, fonctions de dessin SVG, gestion de l'etat avec useState. Vous n'avez pas besoin de modifier ce code.

A la semaine 1, votre Dockerfile faisait une seule chose : copier des fichiers HTML statiques dans Apache. Ici, l'application doit d'abord etre compilee avant d'etre servie. Deux mondes : le monde du build et le monde de l'execution.

Le probleme du single-stage

Si vous mettiez tout dans une seule etape, l'image finale contiendrait :

• Node.js (~150 Mo)
• node_modules/ (~300 Mo)
• Le source code (40 Mo)
• Le resultat du build (10 Mo)

Votre image pese alors 500 Mo pour servir 10 Mo de contenu. Et chaque borne du parc telecharge ces 500 Mo a chaque deploiement.

La solution multi-stage

Un Dockerfile peut avoir plusieurs sections FROM. Chaque FROM demarre une nouvelle etape. La derniere etape est celle qu'on garde dans l'image finale. Les etapes precedentes existent juste pour produire des artefacts qu'on copie selectivement.

Pour cette borne, deux scenarios sont valides :

Scenario A - Next start (mode serveur Node)

• Etape 1 (build) : node:20-slim, npm ci, npm run build.
• Etape 2 (run) : node:20-slim aussi (Next.js a besoin du runtime Node), mais sans le code source ni les devDependances. On copie .next/, public/, node_modules/ (production seulement) et package.json.
• Commande de demarrage : npm start qui execute next start.

Scenario B - Next export + nginx (rendu statique)

• Etape 1 (build) : node:20-slim, npm ci, npm run build. La page app/page.js est marquee "use client" et tout le rendu se fait dans le navigateur, donc l'export statique fonctionne.
• Etape 2 (run) : nginx:1.27-alpine. On copie uniquement le dossier out/ dans /usr/share/nginx/html/.
• Plus leger (~25 Mo final), pas de Node au runtime, mais perte des fonctionnalites Next dynamiques (que vous n'utilisez pas ici de toute facon).

Choisissez votre scenario maintenant et tenez-vous-y pour la suite. Le scenario B donne une image plus legere et illustre mieux le pattern multi-stage classique. Le scenario A est plus proche de ce qu'on ferait pour une vraie app Next avec API routes ou ISR.

Creer le fichier Dockerfile a la racine du dossier demande-1-borne-accueil/ (donc a cote de application/, pas dedans).

Squelette - scenario A (next start)

# --- Etape 1 : build ---
FROM node:20-slim AS builder
WORKDIR /app

# Cache npm install : copier package.json AVANT le reste
COPY application/package*.json ./
RUN npm ci

# Maintenant le code source
COPY application/ ./

RUN [commande de build Next]

# --- Etape 2 : run ---
FROM node:20-slim
WORKDIR /app

# Copier uniquement les artefacts utiles depuis builder
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/public ./public
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/node_modules ./node_modules

EXPOSE 3000
CMD ["npm", "start"]

Squelette - scenario B (export statique + nginx)

# --- Etape 1 : build ---
FROM node:20-slim AS builder
WORKDIR /app
COPY application/package*.json ./
RUN npm ci
COPY application/ ./

# Activer l'export statique dans next.config.mjs : output: 'export'
RUN [npm run build]

# --- Etape 2 : run ---
FROM nginx:1.27-alpine
COPY --from=builder /app/out /usr/share/nginx/html
EXPOSE 80

Faire apparaitre votre nom, votre matricule et la date de build dans la borne. Ce qui prouve que votre image et celle de votre voisin de classe ne sont pas identiques.

La chaine ARG -> ENV -> NEXT_PUBLIC -> UI

Next.js a une regle particuliere : seules les variables d'environnement qui commencent par NEXT_PUBLIC_ sont injectees dans le bundle JavaScript cote client. Donc votre chaine doit etre :

1. ARG NOM_ETUDIANT dans le Dockerfile (etape de build)
2. ENV NEXT_PUBLIC_NOM_ETUDIANT=$NOM_ETUDIANT dans le Dockerfile (avant le npm run build pour qu'elle soit lue par le bundler)
3. Dans le code React : process.env.NEXT_PUBLIC_NOM_ETUDIANT

Modification du Dockerfile (etape builder)

ARG NOM_ETUDIANT="Etudiant Inconnu"
ARG MATRICULE="0000000"
ARG BUILD_DATE="date-non-fournie"

ENV NEXT_PUBLIC_NOM_ETUDIANT=$NOM_ETUDIANT
ENV NEXT_PUBLIC_MATRICULE=$MATRICULE
ENV NEXT_PUBLIC_BUILD_DATE=$BUILD_DATE

# Le build doit avoir lieu APRES la definition des ENV
RUN npm run build

Modification du composant React

Dans application/app/page.js, ajoutez en haut du composant PageBorneAccueil une banniere :

// Au debut du JSX retourne
<div id="banniere-identification">
  Borne d'accueil - {process.env.NEXT_PUBLIC_NOM_ETUDIANT} ({process.env.NEXT_PUBLIC_MATRICULE}) - build {process.env.NEXT_PUBLIC_BUILD_DATE}
</div>

Stylez ensuite #banniere-identification dans globals.css pour qu'elle apparaisse en haut de l'ecran (vert zoo, texte blanc, hauteur 40px par exemple).

Lancer le build avec les --build-arg, demarrer un container, verifier dans le navigateur.

$ docker build \
    --build-arg NOM_ETUDIANT="Prenom Nom" \
    --build-arg MATRICULE="1234567" \
    --build-arg BUILD_DATE="$(date -I)" \
    -t zoo-borne-accueil:1.0 .

$ docker run -d \
    --name borne-accueil-en-marche \
    -p 8090:[port-container] \
    zoo-borne-accueil:1.0

Le port cote container depend du scenario : 3000 pour scenario A (next start), 80 pour scenario B (nginx).

Ouvrez http://localhost:8090/. Vous devez voir la carte du parc avec votre banniere en haut.

Trois scripts bash en kebab-case, executables. Comme en semaine 1, mais avec deux nouveautes : construire.sh accepte des arguments pour la banniere, et il calcule automatiquement la date de build.

Squelette de construire.sh

#!/bin/bash
set -e

# Arguments optionnels (ordre : nom, matricule)
nomEtudiant="${1:-Etudiant Inconnu}"
matricule="${2:-0000000}"
dateBuild="$(date -I)"

nomImage="zoo-borne-accueil:1.0"

echo "[info] Build de $nomImage avec banniere $nomEtudiant ($matricule)"

docker build \
    --build-arg NOM_ETUDIANT="$nomEtudiant" \
    --build-arg MATRICULE="$matricule" \
    --build-arg BUILD_DATE="$dateBuild" \
    -t "$nomImage" .

echo "[ok] Image $nomImage prete."

Squelette de demarrer.sh

Identique a la semaine 1, avec gestion du conflit de nom de container. Variables en mixedCase : nomImage, nomContainer, portHote, portContainer (3000 ou 80 selon scenario).

Squelette de arreter.sh

Identique a la semaine 1 : docker stop puis docker rm du container nomme. Pas de volume a nettoyer ici (la borne d'accueil ne stocke rien).

Une fois ecrits, rendez-les executables : chmod +x *.sh.

Documenter votre travail et exclure du contexte de build ce qui n'a rien a y faire.

.dockerignore - critique pour Next.js

Sans .dockerignore, votre docker build envoie au daemon Docker tout votre dossier, y compris application/node_modules/ qui peut peser plusieurs centaines de Mo. A exclure imperativement :

• application/node_modules/
• application/.next/
• application/out/
• Les scripts .sh
• Le README.md
• Les fichiers caches OS (.DS_Store, Thumbs.db)
• Le .dockerignore lui-meme

Test de validation : avant et apres ajout du .dockerignore, comparez la taille du contexte avec docker build --progress=plain .... Vous devriez voir le contexte passer de plusieurs centaines de Mo a quelques Mo.

README.md - sections obligatoires

• Ce que c'est : un paragraphe sur la borne d'accueil et sur votre choix de scenario (A ou B).
• Comment lancer : la sequence des trois scripts avec un exemple complet (vos vrais nom et matricule).
• Ce qu'on voit : URL d'acces, capture d'ecran de la carte et de la vue Horaires, votre banniere bien visible.
• Choix techniques : pourquoi multi-stage, pourquoi votre scenario, pourquoi votre port.

Bonus pedagogique : section Difficultes rencontrees qui raconte une difficulte concrete (banniere undefined, port deja pris, build qui echoue) et comment vous l'avez resolue.