Projet final : un mini-site reproductible · Docker sur Windows ou Ubuntu

Dernier épisode, et il ne présente aucune notion nouvelle. Votre mission : monter OwlNet MiniSite, un site local construit à partir de votre propre image, décrit par Compose, surveillé par Docker, et que n’importe qui pourrait recréer à l’identique avec vos trois fichiers.

Trois fichiers, une image, un conteneur surveillé : tout le projet se recrée à partir du dossier.

Étape 1 : créer les trois fichiers

mkdir ~\docker-lab\minisite\site
cd ~\docker-lab\minisite
New-Item site\index.html, Dockerfile, compose.yaml

Remplissez chaque fichier avec le Bloc-notes, par exemple notepad site\index.html, puis enregistrez avec Ctrl + S.

mkdir -p ~/docker-lab/minisite/site
cd ~/docker-lab/minisite

Remplissez chaque fichier avec nano, par exemple nano site/index.html.

La page, site/index.html :

<!doctype html>
<html lang="fr">
<meta charset="utf-8">
<title>OwlNet MiniSite</title>
<style>
  body { font-family: system-ui, sans-serif; margin: 0; padding: 4rem 2rem;
         background: #0b1b2e; color: #fff; }
  h1 { color: #5cc8ff; }
</style>
<h1>Mon projet Docker fonctionne !</h1>
<p>Construit avec un Dockerfile, lancé avec Compose, surveillé par Docker.</p>

La recette, Dockerfile. Cette fois, on copie tout le dossier site :

FROM nginx:alpine
COPY site/ /usr/share/nginx/html/

Et la notice, compose.yaml :

services:
  site:
    build: .
    ports:
      - "127.0.0.1:8085:80"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://127.0.0.1/"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 5s

Deux nouveautés par rapport à l’épisode 7 :

Rubrique	Ce qu’elle fait
`build: .`	Au lieu de télécharger une image, Compose construit la vôtre avec le Dockerfile du dossier
`healthcheck`	Toutes les 10 secondes, Docker demande la page d’accueil depuis l’intérieur du conteneur. Trois échecs d’affilée, et le service est déclaré malade

Étape 2 : vérifier, construire, lancer

docker compose config
docker compose up -d --build
docker compose ps

Dans la colonne STATUS, le service affiche d’abord health: starting. Relancez docker compose ps après une quinzaine de secondes : il doit indiquer healthy. Ouvrez ensuite http://127.0.0.1:8085.

Étape 3 : prouver la reproductibilité

Détruisez tout, puis recréez :

docker compose down
docker compose up -d

Le site revient, identique : il n’existait que dans vos trois fichiers.

Modifiez maintenant le titre dans site/index.html et actualisez la page. Rien ne change — et c’est normal : ici, la page est dans l’image, copiée au moment de la construction. Il faut reconstruire :

docker compose up -d --build

Retenez la différence avec l’épisode 7, parce qu’elle guide tous vos choix futurs : un dossier monté pour ce que vous modifiez souvent, une image pour ce qui doit être livré tel quel.

Étape 4 : la panne volontaire

Un vrai projet finit toujours par tomber en panne. Autant s’y entraîner quand on sait ce qui ne va pas.

Dans compose.yaml, remplacez l’adresse du contrôle de santé par une page qui n’existe pas :

      test: ["CMD", "wget", "-q", "--spider", "http://127.0.0.1/absente.html"]

Relancez docker compose up -d, attendez une quarantaine de secondes, puis menez l’enquête comme un professionnel.

L’état d’abord. docker compose ps affiche unhealthy. Pourtant, ouvrez le site : il fonctionne. Première leçon, le contrôle de santé ne teste que ce qu’on lui demande de tester — et Docker, à lui seul, ne redémarre pas un conteneur malade.

Les journaux ensuite. Ceux de Nginx montrent les demandes du contrôle, toutes en erreur 404 :

docker compose logs --tail 10

Le détail du contrôle enfin, qui garde la trace de ses derniers essais :

docker inspect --format "{{json .State.Health}}" minisite-site-1

Le message 404 Not Found y apparaît : le test demande une page qui n’existe pas. Remettez http://127.0.0.1/, relancez docker compose up -d, et vérifiez que l’état redevient healthy.

Étape 5 : ranger

docker compose down

Gardez le dossier minisite : c’est votre premier projet Docker complet, et un modèle pour les suivants.

Et après ?

Vous savez maintenant lire la documentation d’une application distribuée en image Docker, écrire son compose.yaml, protéger ses données et la dépanner. C’est exactement ce que font les serveurs maison et les NAS : les applications de TrueNAS SCALE, par exemple, tournent sous Docker. La formation TrueNAS vous montrera le même raisonnement, appliqué à un serveur qui tourne jour et nuit. Et pour choisir la machine qui l’accueillera, lisez notre guide du serveur maison.

Testez-vous

3 questions pour vérifier que l’essentiel est acquis. Rien n’est noté ni enregistré.

Que garantit l’état healthy ?

Vous modifiez index.html. Quelle commande applique le changement dans ce projet ?

Face à une panne, dans quel ordre chercher ?

Vérifier que tout fonctionne

Cochez au fur et à mesure : quand tout est coché, vous pouvez passer à la suite.

docker compose ps affiche le service avec l’état healthy

http://127.0.0.1:8085 affiche votre page

Après docker compose down puis up -d, tout revient à l’identique

La panne volontaire a été trouvée grâce à l’état et au journal du contrôle de santé

Problèmes courants

L’état reste « health: starting »

Le premier contrôle n’a pas encore eu lieu : patientez une quinzaine de secondes et relancez docker compose ps. S’il passe ensuite à unhealthy, le test lui-même échoue — c’est exactement la situation de la panne volontaire.

Ma modification de index.html n’apparaît pas

Dans ce projet, la page est copiée dans l’image par le Dockerfile. Il faut reconstruire : docker compose up -d --build. C’est la grande différence avec l’épisode 7, où le dossier était monté.

« port is already allocated »

Un projet précédent occupe peut-être encore le port. docker ps montre tout ce qui tourne ; arrêtez l’ancien projet depuis son dossier avec docker compose down, ou changez le port de celui-ci.