Docker (9/9) — Observabilité & santé

L’idée reçue

« Si docker ps affiche “Up”, tout va bien. »

« Up » veut seulement dire que le processus tourne — pas que l’application répond correctement. Un serveur peut être « Up » et pourtant renvoyer des erreurs à chaque requête. On va apprendre à savoir si un service est vraiment sain, et à le faire dire au conteneur lui-même.

À la fin de ce module, tu sauras…

Lire et filtrer les logs d’un conteneur efficacement
Comprendre pourquoi les logs vont sur la sortie standard
Déclarer un healthcheck dans une image
Distinguer « en marche » et « en bonne santé »

01Lire les logs correctement

Expérience 1

Suivre, dater, limiter

Manipule

docker run -d --name web -p 8080:80 nginx:1.27-alpine
docker logs --tail 5 --timestamps web
docker logs -f web

–tail limite aux dernières lignes, –timestamps date chaque entrée, -f suit en direct. Fais quelques requêtes et regarde-les défiler.

Comprends pourquoi la sortie standard ?

Un conteneur bien conçu n’écrit pas ses logs dans un fichier interne (qui disparaîtrait avec lui). Il écrit sur la sortie standard, et la plateforme (Docker, plus tard Kubernetes) les collecte. Principe : le conteneur parle, la plateforme écoute et centralise.

02« Up » ne veut pas dire « sain »

Expérience 2

Le piège du statut

Manipule

docker ps

Observe

STATUS
Up 2 minutes

« Up » signifie seulement : le processus principal tourne. Rien ne garantit que Nginx sert vraiment des pages. Il faut un test actif de santé.

Comprends liveness, le vrai signal

Un processus vivant n’est pas une application fonctionnelle : elle peut être bloquée, saturée, ou renvoyer des 500. On veut un test de santé qui vérifie réellement qu’elle répond. C’est le rôle du healthcheck — et Kubernetes s’appuiera exactement là-dessus pour redémarrer ce qui va mal.

03Déclarer un healthcheck

Expérience 3

Faire dire au conteneur s’il va bien

Manipule

cd ~/soria-web
cat > Dockerfile &lt;&lt;'EOF'
FROM nginx:1.27-alpine
COPY index.html /usr/share/nginx/html/index.html
HEALTHCHECK --interval=10s --timeout=3s --retries=3 \
CMD wget -q -O /dev/null http://localhost/ || exit 1
EOF
docker build -t soria-web:health .
docker run -d --name web-h -p 8081:80 soria-web:health

Attends ~15 s, puis regarde le statut :

Manipule

docker ps

Observe

STATUS
Up 20 seconds (healthy)

Le conteneur affiche maintenant (healthy) : Docker teste régulièrement l’application, et publie son état de santé.

Comprends les paramètres du healthcheck

–interval = fréquence du test, –timeout = délai max, –retries = nombre d’échecs avant de marquer « unhealthy ». La commande de test doit renvoyer 0 (sain) ou non-0 (malade). Ici, on interroge la page d’accueil : si elle ne répond plus, le conteneur devient unhealthy.

04Voir la santé de près

Expérience 4

Inspecter l’historique de santé

Manipule

docker inspect --format '{{json .State.Health}}' web-h

Tu obtiens le statut de santé et l’historique des derniers tests (succès/échecs). C’est cette information que les orchestrateurs utilisent pour décider de redémarrer ou retirer du trafic un conteneur malade.

Comprends le lien avec la suite du projet

Ce que tu déclares ici en petit (un healthcheck sur un conteneur) devient, en Kubernetes, les liveness/readiness probes : la plateforme redémarre automatiquement un Pod malade, ou cesse de lui envoyer du trafic. Tu poses aujourd’hui la brique qu’exploitera la Phase 5.

✓Ce que tu retiens

Observer un service, c’est plus que « Up » : lire ses logs (sortie standard, collectée par la plateforme) et déclarer un healthcheck qui teste réellement sa santé. « En marche » ≠ « en bonne santé ». Ces signaux sont la base de l’auto-réparation en production.

Mini-projet — clôture de la phase Docker

SORIA Web, observable

À faire

Ajoute un healthcheck pertinent à l’image SORIA Web.
Lance-la, attends, et prouve le statut (healthy).
Simule une panne (arrête Nginx dans le conteneur, ou pointe le test sur une URL inexistante) et observe le passage à unhealthy.
Consulte l’historique de santé avec docker inspect.
Prends un snapshot final de la VM nommé phase3-docker-ok.

Fil rouge — Tu as une image de production, observable et saine, de SORIA Web. Une question évidente se pose : où la stocker pour la déployer ailleurs ? Et où vit son code ? C’est tout l’objet de la Phase 4 : registre (Harbor) & code (Git).

?Auto-évaluation

1. Pourquoi un conteneur écrit-il ses logs sur la sortie standard ?

Pour que la plateforme les collecte et les centralise, au lieu de les enfermer dans un fichier qui disparaîtrait avec le conteneur.

2. « Up » garantit-il que l’application fonctionne ?

Non : « Up » dit seulement que le processus tourne. Le healthcheck teste si l’application répond réellement.

3. Que deviennent les healthchecks en Kubernetes ?

Ils deviennent les liveness/readiness probes, qui redémarrent un Pod malade ou cessent de lui envoyer du trafic.