Examen niveau 2 — Docker

Examen — questions inédites

12 questions inédites : rappel + application + arbitrage sur Dockerfile, build, tags, configuration et sécurité.
Répondez à tout, puis cliquez sur Corriger : score et explications s'affichent.

2.1 · Rappel

1. Dans un Dockerfile, que fait RUN par rapport à CMD ?

Les deux lancent le serveur CMD installe, RUN lance RUN installe pendant le build (couche figée), CMD lance au démarrage C'est pareil

RUN = construction (installer), CMD = exécution (démarrer) à chaque run.

2.1 · Application

2. Idir écrit son premier Dockerfile Node. Quel ordre est correct ?

CMD d'abord, FROM à la fin, sans WORKDIR RUN node server.js puis COPY, sans FROM FROM sans CMD ni EXPOSE, lancement dans RUN FROM node:20-slim, WORKDIR /app, COPY, RUN npm ci, EXPOSE, CMD

Base, dossier, code, install au build, port déclaré, démarrage au run.

2.1 · Application

3. Le build d'Idir échoue. Où cherche-t-il en premier ?

Dans le fichier .env de Compose Dans les logs du conteneur de prod Sur le registre Docker Hub Dans la dernière étape affichée du build

La dernière étape accuse : dépendance manquante, faute de frappe, réseau.

2.2 · Rappel

4. Pourquoi placer les dépendances AVANT le code dans un Dockerfile ?

Pour que l'image soit publique Pour préserver le cache : un changement de code ne rejoue pas l'install Pour supprimer le CMD Pour éviter le docker login

Stable d'abord (caché), changeant ensuite (rejoué seul).

2.2 · Application

5. L'image d'Idir dépasse 1 Go avec le SDK livré en prod. Que fait-il ?

Il met le mot de passe en ENV Il pousse en latest sans tag Il supprime le CMD Il passe en multi-stage : build outillé, runtime slim via COPY --from=build

Construire gros, livrer maigre : seul le runnable atteint l'image finale.

2.2 · Arbitrage

6. Idir hésite entre optimiser à l'intuition ou mesurer. Que lui conseillez-vous ?

Supprimer le .dockerignore pour aller vite Livrer le SDK pour simplifier Optimiser à l'aveugle, c'est plus rapide Mesurer avec docker images + history avant/après, puis optimiser

On optimise ce qu'on mesure : taille totale + poids par couche.

2.3 · Application

7. Idir publie la version 1.2.0 testée. Quelle séquence est correcte ?

push avec secret en ENV, sans login docker build -t moncompte/mon-app:1.2.0, login, push 1.2.0, pull ailleurs push sans build ni tag, en root build sans tag puis run en prod

Taguer au build (compte inclus), authentifier, pousser, tirer ailleurs.

2.3 · Arbitrage

8. La prod d'Idir tire latest et dérive à chaque push. Quelle politique impose-t-il ?

Aucun tag, build à chaque run Réécrire la 1.2.0 à chaque correctif Un tag immuable par livraison (1.2.0) pour la prod, alias pour le dev Continuer en latest, c'est plus simple

Prod = tag figé et testé, jamais réécrit ; latest reste un confort de dev.

2.4 · Rappel

9. Quelle différence entre ARG et ENV ?

Aucune différence ENV sert au build puis disparaît, ARG persiste au run ARG et ENV lancent le serveur ARG sert pendant le build puis disparaît, ENV persiste au run et se surcharge

ARG construit (build), ENV exécute (run) : ne pas les confondre.

2.4 · Application

10. Idir sert le dev (3000) et la recette (8080) avec la même image 1.0. Comment ?

ENV PORT=3000 par défaut, surcharge -e PORT=8080 au lancement Deux images différentes par port Port en dur + rebuild par environnement Secret en ENV figé dans le Dockerfile

Défaut sain + surcharge -e : une image, N environnements.

2.5 · Application

11. L'image d'Idir tourne en root. Quel durcissement applique-t-il ?

Rester root pour simplifier Supprimer le CMD et le EXPOSE USER dédié avant CMD, propriété ajustée, whoami vérifié Mettre le secret en ENV dans le Dockerfile

Deux lignes (USER dédié) + vérification : fini le root par défaut.

2.5 · Arbitrage

12. Idir doit gérer une clé sensible avant un push public. Que choisit-il ?

La mettre en ENV figé dans le Dockerfile La copier via COPY dans l'image L'injecter au run (secrets managés), exclue du contexte et de l'historique La committer dans le .env poussé sur git

Zéro secret dans l'image : injecté au run, jamais committé, push public irréversible.

Et après ?

Score ≥ 80 % : passez au Niveau 3 — Compose et stacks multi-conteneurs, en gardant vos réflexes (Dockerfile maigre, tags figés, config hors image, non-root).
Score 60-79 % : reprenez les sections ratées (2.1 RUN/CMD, 2.2 cache et multi-stage, 2.3 tags immuables, 2.4 ARG/ENV, 2.5 non-root et secrets) et refaites les défis 48h.
Score < 60 % : reconstruisez l'app d'Idir pas à pas (Dockerfile 7 lignes, cache + multi-stage, push 1.0.0, ENV PORT, USER + scan), puis repassez le test.
Dans tous les cas : gardez les réflexes — RUN construit et CMD démarre, stable d'abord, tags figés, config hors image, zéro secret embarqué.