GUIDINEE.COM › Docker › Niveau 6 › 6.1

6.1 · Cas concrets

Niveau 6 · Dans la pratique

6.1Cas concrets

Objectif : voir comment les compétences des niveaux 0 à 5 s'enchaînent sur des cas réels.
Temps estimé : 14 min · Si vous n'avez que 5 min : lisez « L'essentiel en 30s » + le schéma.

L'essentiel en 30 secondes

  • Assembler : Dockerfile propre (slim, dépendances d'abord, non-root), image taguée 1.0, stack Compose déclaratif, persistance prouvée, CI seule usine.
  • Prouver : tester en local, faire tirer et lancer par un tiers, prouver down/up sans perte — ce qui n'est pas prouvé n'existe pas.
  • Partager : une image versionnée et un repo cloné + up = appli complète, sans « installe Node 20 ».

Fil Idir — deux livraisons à Alger

Idir, devops junior à Alger, relit ses deux chantiers marquants du trimestre : conteneuriser l'API Node qui ne tournait que sur le portable de son auteur (Dockerfile, build 1.0, durcissement, poussée vers le registre, reprise par un collègue), puis outiller sa petite équipe avec un stack Compose api + base + console (paramètres, restart et healthcheck, validation, preuve sans perte). Les deux cas ci-dessous reprennent son enchaînement : écrire propre, builder, durcir, partager, déclarer, prouver.

Chaque cas suit le déroulé Contexte → Étapes → Résultat : rejouez-le sur votre appli.

Mettre les briques bout à bout

Les niveaux précédents ont posé les briques (images, conteneurs, volumes, réseaux, Dockerfile, Compose, registres, CI) ; ici on les assemble en conditions réelles : c'est l'enchaînement des bons réflexes — image durcie, stack déclaratif, persistance prouvée, CI unique — qui distingue un déploiement fiable d'un empilement fragile. Deux cas déroulés de A à Z.

Cas 1 — Conteneuriser une API de A à Z

Contexte : On reçoit une API Node qui ne tourne que sur le portable de son auteur et on doit la livrer en image partagée. Risque : un environnement non reproductible et des « ça marche chez moi ».

Déroulé :

  1. Écrire le Dockerfile (node:20-slim, WORKDIR, dépendances d'abord, USER node, CMD) avec .dockerignore (N2.1, N2.5).
  2. Builder en mon-app:1.0 et tester en local avec -p 3000:3000 (N1.2, N2.1).
  3. Durcir : .dockerignore, non-root, scan, tag immuable 1.0 (N2.5, N4.1).
  4. Pousser vers le registre et faire tirer + lancer par un collègue (N2.3, N4.1).
  5. Valider : un tiers lance l'image d'une commande, sans installer Node 20.

Résultat : Une image 1.0 partagée, lançable partout d'une commande, sans « installe Node 20 ».

Cas 2 — Stack Compose pour une petite équipe

Contexte : Une équipe veut lancer api + base + console en une commande, avec données persistées et mises à jour simples. Défi : une stack qui casse au premier redémarrage.

Déroulé :

  1. Écrire compose.yml : api (build), bdd (volume pgdata), adminer en profil dev (N3.1, N3.4).
  2. Paramétrer via ${PORT:-3000} et .env.example versionné, .env non commité (N3.4, N2.4).
  3. Ajouter restart + healthcheck bdd + depends_on healthy (N4.2, N3.2).
  4. Valider par config, up -d --build, puis prouver down/up sans perte (N3.2, N4.4).
  5. Documenter : la doc « comment lancer » tient en une ligne (clone + up).

Résultat : Un repo cloné + up = appli complète ; la doc « comment lancer » tient en une ligne.

Erreur d'interprétation fréquente : « recopier les cas à l'identique ». Non. Les cas montrent un ordre de production (écrire propre, builder, durcir, partager, déclarer, prouver), pas une recette à copier : reprenez l'ordre, adaptez image, services et paramètres à votre appli.
Version texte du schéma (SEO / lecteurs d'écran / traduction) : Chaîne complète : 1) Écrire (Dockerfile slim, dépendances d'abord, USER node, .dockerignore, N2.1/N2.5). 2) Builder et tester (tag immuable 1.0, run -p en local, N1.2). 3) Durcir (non-root, scan, tag 1.0 jamais latest en prod, N2.5/N4.1). 4) Partager (push vers le registre, pull + run par un tiers, N2.3/N4.1). 5) Déclarer (compose.yml api + bdd + profil dev, ${PORT:-3000}, .env.example, N3.1/N3.4). 6) Fiabiliser et prouver (restart, healthcheck, depends_on healthy, config, up -d --build, down/up sans perte, N4.2/N4.4). Leçon : un déploiement fiable vient de l'enchaînement, pas d'une seule commande.

Script prêt à dire — cadrer une livraison Docker (30 s)

« Notre besoin : [API à partager / stack api + base]. Notre image : [slim, non-root, tag 1.0, scannée]. Notre stack : [compose versionné, ${PORT:-3000}, volume pgdata]. Notre preuve : [tirage par un tiers / down-up sans perte]. »

Modèle copier-coller — enchaînement cas concret

docker build -t mon-app:1.0 .
docker run -d --name api -p 3000:3000 mon-app:1.0
docker compose config
docker compose up -d --build
docker compose ps
docker compose down
docker compose up -d

TPE / petit budget

Un seul cas rejoué petit : une image 1.0, un compose à deux services, preuve down/up notée.

PME Alger

Adapter aux réalités locales : tester sur la machine réelle de l'équipe, prévoir le volume pgdata sauvegardé.

Remote / hybride

Doubler la traçabilité à distance : tag, registre et preuve down/up notés et partagés.

Interculturel

Expliciter la doc avant de transposer un cas : une ligne « cloner + up » doit parler à tout nouvel arrivant.

Prudence : Rappel générique : une image partagée engage votre équipe — tags immuables, non-root, scan, zéro secret dans l'image et le git, .env non commité, preuve down/up avant de considérer la livraison comme faite.

Défi 48h — appliquez demain

Prenez 1 appli réelle et rejouez l'enchaînement : Dockerfile propre, build 1.0, run local, compose validé par config, preuve down/up sans perte.

Checklist sortie de section
  • Je sais enchaîner Dockerfile, build, partage et stack Compose sur un cas réel.
  • J'ai un enchaînement rejouable (image 1.0, compose versionné, preuve sans perte).
  • J'ai fait le défi 48h ou planifié sa date.
Auto-évaluation 1-5 : mon image est-elle reprise par un tiers d'une commande ?ma persistance est-elle prouvée down/up ?
Suite : Problèmes récurrents (playbook) (V3) →
Vérifiez votre compréhension

Idir livre son API. Quel enchaînement respecte le guide ?