OS de votre poste :
Module 06 · Docker Vidéo DevOps · TP 00

TP-00 — Déployer et diagnostiquer le projet Taskboard

Une application web complète repose sur plusieurs services qui doivent communiquer et conserver leurs données. Vous déploierez Taskboard avec Compose, suivrez les échanges entre le navigateur, l’API et PostgreSQL, puis utiliserez les états, les journaux et les contrôles de santé pour diagnostiquer un problème.

Objectifs et cours associés

  • déployer une application multi-conteneurs avec Docker Compose
  • comprendre le rôle des services web, api et db
  • suivre le trajet d’une requête du navigateur jusqu’à PostgreSQL
  • observer la résolution DNS entre services sans publier inutilement l’API ou la base
  • vérifier la persistance des données dans un volume Docker
  • utiliser ps, logs, curl et les healthchecks pour diagnostiquer la stack.

Pour réviser les notions utilisées dans ce TP :

Préparation

Prérequis

Configuration pour Linux

Compte student, membre de devops, avec accès sudo ; terminal Linux et systemd.

Guide : Préparer Linux pour les TP

Moteur Docker et Compose disponibles.

Guide : Préparer Docker pour les TP

Dans le terminal Linux, entrer dans student si nécessaire :

Terminal Linux — Bash — entrer dans le compte student

su - student

Si vous êtes déjà connecté avec student, conserver cette session.

Dépendances

Configuration pour Linux

Si ce dossier existe, inspecter les anciens fichiers avant de reprendre.

Utiliser le moteur préparé par le guide commun :

Terminal Linux — Bash

docker version
docker compose version

Client et Server doivent être disponibles. Les services applicatifs seront lancés par les commandes du TP ; ne pas installer les serveurs web ou bases de données sur le poste.

Les services web, api et db seront construits et démarrés par Compose pendant les étapes. Télécharger le projet indiqué à l’étape 1 et conserver son arborescence.

Créer le dossier du TP puis s’y placer pour préparer les fichiers de travail :

Terminal Linux — Bash

# Créer le dossier indiqué pour les fichiers de travail du TP.
mkdir -p ~/devops-formation/tp-06-00

# Se placer dans ce dossier pour préparer les dépendances.
cd ~/devops-formation/tp-06-00

Étape 1 : Récupérer et repérer le projet

Avec le compte de travail, créer le dossier du TP puis s’y placer :

Terminal Linux — Bash

# Créer le dossier indiqué pour les fichiers de travail du TP.
mkdir -p ~/devops-formation/tp-06-00

# Se placer dans le dossier requis pour les commandes suivantes.
cd ~/devops-formation/tp-06-00

Le projet de départ est fourni pour que ce premier fil rouge se concentre sur Docker. Tu vas d’abord le lire, puis le construire et l’observer. Les prochains TP pourront faire évoluer cette même application.

⬇ Télécharger le projet TP-00 (.zip)

Décompresse l’archive dans un dossier de travail, puis place-toi à sa racine. Tu dois notamment retrouver :

Arborescence du projet — à reproduire

taskboard/
├── compose.yaml
├── .env.example
├── api/
│   ├── Dockerfile
│   ├── Program.cs
│   ├── Data/TasksDb.cs
│   ├── Endpoints/TaskEndpoints.cs
│   ├── Health/Probe.cs
│   ├── Models/TaskItem.cs
│   └── Repositories/TasksRepository.cs
└── web/
    ├── Dockerfile
    ├── nginx.conf
    └── src/
Avant de lancer quoi que ce soit

Repère compose.yaml. Il est le point d’entrée de la stack : il décrit les services à créer et la façon dont ils sont reliés. Les dossiers web et api contiennent chacun leur propre Dockerfile : Compose demandera donc à Docker de construire deux images locales.

  1. Conclusion

    • Identifier les services et les fichiers du projet permet de comprendre ce que Compose va construire et démarrer.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 2 : Préparer la configuration

L’application utilise des variables d’environnement. Le fichier .env.example sert de modèle ; on le copie en .env afin de conserver un exemple versionnable sans imposer les valeurs locales du poste.

Terminal Linux — Bash

# Copier le fichier vers l’emplacement où il sera utilisé.
cp .env.example .env
Terminal commun : cp copie un fichier dans le terminal Linux utilisé pour ce TP. Continuer les commandes dans ce même terminal.

Ouvre ensuite compose.yaml et retrouve les trois services web, api et db, ainsi que le volume nommé db-data.

À comprendre avant de continuer
  • web est le seul service destiné au navigateur : son port est publié sur l’hôte
  • api est appelée par NGINX sur le réseau Compose ; elle n’a pas besoin d’être exposée directement au poste
  • db est appelée par l’API avec le nom DNS db
  • db-data conserve les données PostgreSQL indépendamment du cycle de vie du conteneur.

  1. Conclusion

    • Les paramètres configurés doivent correspondre aux services et à l’environnement de travail réellement utilisés.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 3 : La commande Docker Compose

Terminal Linux — Bash

# Piloter le projet Compose avec la sous-commande <action>.
docker compose <action> [options] [service] [commande à exécuter dans le conteneur]
  • docker compose
    utilise Docker Compose et le fichier compose.yaml du projet
  • <action>
    action demandée à Compose, par exemple config, up, ps, exec, logs, stop ou start
  • [options]
    options éventuelles de l’action, par exemple -d, --build ou --tail 100
  • [service]
    service défini dans compose.yaml, par exemple web, api ou db
  • [commande à exécuter dans le conteneur]
    commande à exécuter sur le conteneur du service sélectionné
    avec une action comme exec, commande disponible dans l’environnement Linux du conteneur du service ciblé.

Exemple utilisé plus loin dans ce TP :

Terminal Linux — Bash
Cible : conteneur du service Compose web — commande lancée depuis ce terminal.

# Exécuter la vérification dans le service Compose ciblé.
docker compose exec web nginx -v

Ici, exec demande d’exécuter une commande dans un conteneur déjà démarré, web désigne le service Compose, et nginx -v est la commande exécutée dans le conteneur Linux associé à ce service.

Une action peut aussi accepter plusieurs services lorsqu’elle est conçue pour agir sur plusieurs cibles. Par exemple :

Terminal Linux — Bash

# Consulter les sorties des services pour repérer la cause d’un problème.
docker compose logs web api db

Ici, l’action logs peut afficher les journaux de plusieurs services en une seule commande. C’est également le cas d’actions comme start ou stop, auxquelles on peut fournir plusieurs services. En revanche, exec cible un seul service : la commande qui suit doit être exécutée dans le conteneur de ce service précis.

  1. Conclusion

    • La commande Compose pilote le projet décrit par ses fichiers ; il faut identifier le projet et la configuration visés.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 4 : Valider la configuration Compose

Avant de créer des conteneurs, demande à Compose de résoudre et valider la configuration :

Terminal Linux — Bash

# Valider et afficher la configuration Compose résolue avant le démarrage.
docker compose config --quiet
Syntaxe de la commande
KeywordValeurExplication
actionconfigValide et résout la configuration Compose du projet.
option--quietN’affiche rien si la configuration est valide ; une erreur reste affichée.

En cas de succès, la commande ne produit normalement aucune sortie. Une erreur YAML, une variable obligatoire absente ou une configuration invalide doit être corrigée avant le démarrage.

Pour voir la configuration réellement comprise par Compose, exécute ensuite :

Terminal Linux — Bash

# Valider et afficher la configuration Compose résolue avant le démarrage.
docker compose config
Syntaxe

La commande est la même que précédemment sans --quiet : Compose affiche cette fois la configuration finale qu’il a comprise, après résolution des variables.

Pourquoi commencer par config ?

C’est un contrôle peu coûteux : il permet de distinguer un problème de description Compose d’un problème qui apparaîtrait plus tard pendant le build ou l’exécution.

  1. Conclusion

    • La configuration résolue permet de repérer des erreurs avant le démarrage ; elle ne remplace pas les tests des services.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 5 : Construire et démarrer la stack

Lance maintenant la construction des images locales puis le démarrage en arrière-plan :

Terminal Linux — Bash

# Créer ou mettre à jour les services et les démarrer avec la configuration du projet.
docker compose up -d --build
Syntaxe de la commande
KeywordValeurExplication
actionupCrée si nécessaire puis démarre les services du projet.
option-dDémarre les conteneurs en arrière-plan.
option--buildReconstruit les images avant le démarrage.

Le premier build peut être plus long : Docker doit télécharger les images de base et les dépendances. Observe les étapes de build. Tu dois voir une construction pour le frontend et une pour l’API.

Contrôle ensuite l’état des services :

Terminal Linux — Bash

# Contrôler l’état des services du projet Compose.
docker compose ps -a
Syntaxe de la commande
KeywordValeurExplication
actionpsAffiche l’état des conteneurs du projet Compose.
option-aall : inclut les conteneurs arrêtés, utile pour repérer un service qui a démarré puis quitté.

Les services web, api et db doivent être démarrés. Selon le moment où tu exécutes la commande, un healthcheck peut brièvement être indiqué comme starting avant de devenir healthy.

Si les conteneurs existent mais sont arrêtés

Si docker compose ps -a montre que les conteneurs sont présents mais simplement arrêtés, tu peux redémarrer les mêmes conteneurs avec :

Terminal Linux — Bash

# Redémarrer les conteneurs déjà créés pour le projet.
docker compose start
Syntaxe de la commande
start — démarre les conteneurs existants d’un projet Compose qui sont à l’arrêt.

docker compose stop effectue l’opération inverse : il arrête les conteneurs sans les supprimer. Ne l’exécute pas maintenant ; nous vérifierons réellement la différence entre stop/start et down/up à la section 9.

Si un service redémarre puis repasse immédiatement à l’état arrêté ou en erreur, ne relance pas la stack en boucle : relève son état et consulte ses logs pour diagnostiquer la cause.

  1. Conclusion

    • Le build produit les images nécessaires puis Compose démarre les services ; leur état doit encore être vérifié.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 6 : Vérifier l’application de bout en bout

Ouvre http://localhost:8080 dans le navigateur. L’interface Taskboard doit s’afficher. Ajoute une tâche depuis le formulaire, puis recharge la page : la tâche doit toujours apparaître.

Comprendre le trajet d’une requête

  • Le navigateur contacte le port 8080 publié par le service web
  • Dans le conteneur web, NGINX écoute sur le port 80 et sert les fichiers React compilés
  • Pour une URL /api/..., NGINX agit comme reverse proxy et transmet la requête au service api
  • Docker fournit la résolution DNS du nom api sur le réseau Compose
  • L’API utilise à son tour le nom db pour joindre PostgreSQL
  • PostgreSQL écrit les données dans le volume db-data
À comprendre avant de continuer

NGINX n’est pas installé sur ton poste Windows. Il tourne dans le conteneur web. C’est précisément Docker qui permet au projet d’utiliser NGINX sans l’installer sur l’hôte.

Prouver le trajet de la requête

On ne va pas se contenter du schéma précédent : on va vérifier chaque maillon observable.

  1. Vérifie le point d’entrée depuis le poste apprenant :

    Terminal Linux — Bash

    curl -i http://localhost:8080/api/health
    Syntaxe de la commande
    KeywordValeurExplication
    commandecurlEnvoie une requête HTTP.
    option-iAffiche les en-têtes de la réponse HTTP avec son contenu.
    ciblehttp://localhost:8080/api/healthEndpoint de santé interrogé.

  2. Prouve que NGINX tourne dans le conteneur web :

    Terminal Linux — Bash
    Cible : conteneur du service Compose web — commande lancée depuis ce terminal.

    docker compose exec web nginx -v
    Syntaxe de la commande
    KeywordValeurExplication
    actionexecExécute une commande dans le conteneur déjà démarré d’un service.
    servicewebCible le conteneur du service web.
    commandenginx -vCommande exécutée dans le conteneur.
    Le résultat prouve que NGINX existe dans le conteneur web, pas sur Windows.

  3. Vérifie la règle de reverse proxy réellement chargée :

    Terminal Linux — Bash
    Cible : conteneur du service Compose web — commande lancée depuis ce terminal.

    docker compose exec web cat /etc/nginx/conf.d/default.conf
    Syntaxe de la commande
    KeywordValeurExplication
    actionexecExécute une commande dans le conteneur déjà démarré d’un service.
    servicewebCible le conteneur du service web.
    commandecat /etc/nginx/conf.d/default.confCommande exécutée dans le conteneur.

  4. Vérifie que le service API est résolu depuis le réseau du conteneur web :

    Terminal Linux — Bash
    Cible : conteneur du service Compose web — commande lancée depuis ce terminal.

    docker compose exec web getent hosts api
    Syntaxe de la commande
    KeywordValeurExplication
    actionexecExécute une commande dans le conteneur déjà démarré d’un service.
    servicewebCible le conteneur du service web.
    commandegetent hosts apigetent interroge les bases système disponibles ; hosts demande une résolution de nom d’hôte et api est le nom du service Compose à résoudre.
    Une adresse retournée prouve que api est résolu sur le réseau Docker.
    Ce que tu viens de prouver

    La requête part de Windows vers localhost:8080, arrive dans le conteneur web où NGINX est réellement installé, puis la configuration NGINX relaie /api/... vers le nom de service api, résolu par Docker. On ne déduit donc pas le trajet uniquement du code source : on l’observe dans la stack en cours d’exécution.

  1. Conclusion

    • Une requête réussie de bout en bout confirme les échanges entre l’interface, l’API et PostgreSQL pour la fonction testée.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 7 : Observer les conteneurs et les logs

Affiche les dernières lignes de logs des trois services :

Terminal Linux — Bash

# Consulter les sorties des services pour repérer la cause d’un problème.
docker compose logs --tail 100 web api db
Syntaxe de la commande
KeywordValeurExplication
actionlogsAffiche les journaux des services ciblés.
option--tail 100Limite l’affichage aux 100 dernières lignes.
serviceweb api dbCible les trois services indiqués.

Ajoute ensuite une nouvelle tâche dans l’interface et relance la commande. Cherche à relier ce que tu viens de faire aux traces produites par les différents composants.

Pour suivre les logs en direct :

Terminal Linux — Bash

# Consulter les sorties des services pour repérer la cause d’un problème.
docker compose logs -f web api db
Syntaxe de la commande
KeywordValeurExplication
actionlogsAffiche les journaux des services ciblés.
option-fSuit les journaux et affiche les nouvelles lignes en temps réel.
serviceweb api dbCible les trois services indiqués.

Ajoute une tâche, observe les nouvelles lignes, puis quitte le suivi avec Ctrl+C. Cela arrête seulement l’affichage des logs, pas les conteneurs.

Réflexe de diagnostic

Commence par docker compose ps -a pour savoir quel service pose problème, puis consulte les logs de ce service avec docker compose logs NOM_DU_SERVICE. Évite de modifier plusieurs composants au hasard en même temps.

  1. Conclusion

    • Les états et les journaux apportent des indices complémentaires pour repérer le service ou la requête en difficulté.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 8 : Vérifier la persistance PostgreSQL

La tâche créée précédemment est stockée dans PostgreSQL. Nous allons supprimer les conteneurs sans supprimer le volume, puis vérifier que la donnée survit.

Terminal Linux — Bash

# Supprimer les conteneurs et le réseau du projet ; les volumes sont conservés sans option de suppression.
docker compose down
Syntaxe de la commande
KeywordValeurExplication
actiondownArrête puis supprime les conteneurs et le réseau du projet Compose.
option-vSans cette option, les volumes nommés ne sont pas supprimés.

Relance la stack :

Terminal Linux — Bash

# Créer ou mettre à jour les services et les démarrer avec la configuration du projet.
docker compose up -d
Syntaxe

up et -d ont déjà été expliqués. Ici, l’absence de --build signifie que Compose peut réutiliser les images déjà construites.

Retourne sur http://localhost:8080. La tâche créée avant le down doit toujours être présente.

Attention à -v

N’utilise pas docker compose down -v pendant cette vérification. L’option -v demande explicitement la suppression des volumes du projet : elle supprimerait donc les données utilisées pour démontrer la persistance.

  1. Conclusion

    • Retrouver les données PostgreSQL après la manipulation prévue confirme que le volume conserve les données au-delà du conteneur.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 9 : Distinguer arrêt et suppression

Un état affiché par Docker ne suffit pas : nous allons aussi vérifier le comportement depuis le poste apprenant.

Avant l’arrêt, vérifie que l’application répond :

Terminal Linux — Bash

# Interroger le point de santé et observer le code HTTP retourné.
curl -i http://localhost:8080/api/health

Cette commande a déjà été expliquée à l’étape 6. La réponse doit être un succès HTTP.

Arrête les conteneurs sans les supprimer :

Terminal Linux — Bash

# Arrêter les services sans supprimer leurs conteneurs ni leurs volumes.
docker compose stop
Syntaxe de la commande
KeywordValeurExplication
actionstopArrête les conteneurs du projet sans les supprimer.
Les conteneurs conservent leur configuration et leur identité pour un futur start.

Contrôle leur état :

Terminal Linux — Bash

# Contrôler l’état des services du projet Compose.
docker compose ps -a

Prouve maintenant que le service n’est réellement plus joignable :

Terminal Linux — Bash

# Interroger le point de santé et observer le code HTTP retourné.
curl -i http://localhost:8080/api/health

Cette fois, la requête doit échouer : aucun conteneur web n’écoute plus derrière le port publié. Cela confirme le constat de docker compose ps -a par une observation depuis l’extérieur.

Redémarre les mêmes conteneurs :

Terminal Linux — Bash

# Redémarrer les conteneurs déjà créés pour le projet.
docker compose start

Vérifie l’état puis le service :

Terminal Linux — Bash

# Contrôler l’état des services du projet Compose.
docker compose ps

Terminal Linux — Bash

# Interroger le point de santé et observer le code HTTP retourné.
curl -i http://localhost:8080/api/health

Compare avec l’étape 8 : stop/start conserve les conteneurs, tandis que down/up les supprime puis les recrée à partir de la définition Compose.

  1. Conclusion

    • Arrêter les services et supprimer leurs conteneurs sont distincts de supprimer les volumes ; le choix de la commande détermine ce qui est conservé.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Étape 10 : Mini-diagnostic guidé

Réponds d’abord sans afficher la correction. Utilise ensuite le bouton pour vérifier ton raisonnement.

1. Quel service publie un port vers la machine hôte ? Pourquoi les deux autres n’en ont-ils pas besoin ?

2. Où NGINX apprend-il qu’il doit transmettre /api/ vers l’API ?

3. Par quel nom l’API contacte-t-elle PostgreSQL ?

4. Quel élément permet de conserver les tâches après recréation du conteneur PostgreSQL ?

5. Si web fonctionne mais qu’un appel /api/tasks échoue, quelles commandes utiliserais-tu en premier ?

But de cette étape

Tu dois pouvoir expliquer la stack sans réciter le fichier Compose : partir d’un symptôme, identifier le composant concerné, puis choisir l’observation utile.

Validation du TP

Le TP est validé si tu peux vérifier et expliquer chacun des points suivants :

  • les trois services sont démarrés et leur rôle est identifié
  • le frontend est accessible sur http://localhost:8080
  • /api/health répond à travers NGINX
  • une tâche créée depuis React est enregistrée puis relue depuis PostgreSQL
  • la donnée persiste après docker compose down puis docker compose up -d
  • tu sais expliquer le trajet navigateur → NGINX → API → PostgreSQL
  • tu sais expliquer la différence entre port publié, communication interne par DNS Compose et volume persistant
  • tu sais commencer un diagnostic avec ps et logs plutôt que relancer au hasard.
À retenir

Compose ne sert pas seulement à « lancer plusieurs conteneurs ». Il décrit une petite architecture : quels services existent, comment ils sont construits, comment ils communiquent, quelle configuration ils reçoivent et quelles données doivent survivre. Dans ce fil rouge, le frontend est le point d’entrée, NGINX relaie les appels API, Docker fournit le réseau et le DNS entre services, et le volume découple les données PostgreSQL du conteneur.

  1. Conclusion

    • Un diagnostic confirmé relie le symptôme à une cause vérifiable puis contrôle que la correction rétablit le résultat attendu.

    Si vos observations ne permettent pas de confirmer cette conclusion, comparez le résultat aux indications d’Observer et reprenez les commandes de cette manipulation.
    Relisez au besoin : 3. Réseau Docker et volumes - strict ; 4. Dockerfile, Registry et Docker Compose - strict.

Nettoyage

Dépendances

Configuration pour Linux

Linux : exécuter le nettoyage ciblé dans le terminal relié au Docker Engine natif du TP. Ne pas toucher aux ressources d’un autre contexte.

Dans le dossier du projet, sauvegarder les données utiles puis arrêter et retirer uniquement cette stack avec docker compose down. Vérifier docker compose ps -a. Le volume PostgreSQL reste conservé par défaut. Si ses données sont exclusivement celles du TP et que leur effacement est souhaité, utiliser explicitement docker compose down --volumes après sauvegarde. Ne pas lancer de prune global.

Conserver le projet pour la suite du fil rouge. Retirer le dossier seulement après validation et sauvegarde de vos modifications ; ne supprimer aucune autre stack.

Guide : Préparer Docker pour les TP. Retirer un moteur supprime ou rend indisponibles ses ressources : sauvegarder et vérifier les usages avant de décider.

Dépendance réutilisée : conserver le moteur Docker pour les autres TP. Son retrait complet est facultatif après nettoyage des seuls conteneurs, réseaux, volumes et certificats de ce TP. Préserver un moteur préexistant.

Prérequis

Configuration pour Linux

Conserver student, devops et l’environnement pour les TP suivants. Le retrait complet reste facultatif, après nettoyage des dépendances et sauvegarde des travaux.

Guide : Préparer Linux pour les TP

Conserver le moteur Docker pour la suite.

Guide : Préparer Docker pour les TP

exit quitte la session student et revient au compte initial si vous avez utilisé su - student. Le système Linux du poste reste installé.