
L'équipe technique a validé votre proposition : pour éviter les erreurs manuelles et les conflits de dépendances, la nouvelle application interne sera conteneurisée. Mais une application moderne repose rarement sur un seul composant. Dans notre cas, elle nécessite à la fois un serveur web et une base de données pour fonctionner. Il faut donc pouvoir démarrer plusieurs conteneurs ensemble, les faire communiquer et vérifier qu’ils fonctionnent correctement.
C’est précisément le rôle de Docker Compose : décrire une application composée de plusieurs conteneurs, puis la lancer de manière cohérente à partir d’un seul fichier de configuration.
Avec Docker Compose, vous allez décrire l’ensemble de l’application dans un fichier texte, généralement nommé compose.yml .
Ce fichier indique notamment :
les services à lancer, par exemple un service web et une base de données,
les ports à exposer pour rendre l’application accessible,
les liens nécessaires entre les différents composants.
Alex insiste souvent sur l’avantage de cette méthode :
Un bon déploiement commence par une description claire. Si ton fichier
compose.ymlest fiable, tu peux relancer ton application de manière beaucoup plus cohérente, sur le même serveur ou ailleurs.
Une fois ce fichier prêt, vous pouvez lancer les conteneurs décrits avec une seule commande, depuis le dossier qui contient ce fichier : docker compose up -d .
L'option -d (pour detached) permet de lancer les conteneurs en arrière-plan. Vous retrouvez ici une logique familière : des composants s’exécutent en tâche de fond, et vous devez ensuite vérifier leur état. Pour cela, vous utiliserez notamment : docker ps . Cette commande affiche les conteneurs en cours d’exécution et vous permet de vérifier rapidement que votre application est bien lancée.
Découvrez maintenant comment lire un fichier docker-compose.yml , lancer l’application et vérifier que les conteneurs sont bien actifs.
Dans cette vidéo on a :
exploré la structure d'un fichier de déploiementcompose.yml,
déployé l'intégralité d'une application en une seule ligne de commande avecdocker compose up -d,
vérifié l'état d'exécution de nos conteneurs avec la commande de supervision docker ps.
Votre application tourne en arrière-plan, c'est une excellente nouvelle ! Mais testons un scénario : que se passe-t-il si vous devez supprimer ou recréer le conteneur de la base de données lors d’une mise à jour ?
Pour éviter cette situation, il faut utiliser un volume Docker.

Un conteneur peut être remplacé ; les données métier, elles, doivent rester disponibles. Pour notre outil de partage de fichiers, la persistance est donc indispensable.
Dans Docker Compose, cette persistance se configure en ajoutant une instruction volumes dans le fichier compose.yml .
Voici pourquoi cette configuration est essentielle avant toute mise en production.
Dans cette vidéo on a :
identifié le risque de perte de données lié au caractère éphémère des conteneurs,
configuré la persistance des données en déclarant des volumes dans notre fichiercompose.yml,
associé/var/transferts_fichiers/INau répertoire web Nginx/usr/share/nginx/html,
créé un fichierindex.htmldans le répertoire hôte,
vérifié son affichage aveccurl http://localhost:8080,
supprimé les conteneurs avecdocker compose down,
constaté que le service n’était plus accessible,
relancé les conteneurs avecdocker compose up -d,
vérifié que le fichier était toujours disponible, prouvant la persistance des données grâce au montage.
Vous avez rédigé votre fichier compose.yml et lancé la commande docker compose up -d . Mais lors des tests, l'application reste inaccessible. Que faire ?
La logique de diagnostic reste la même que pour un service natif : observer, lire les logs, identifier la cause, puis corriger. Seuls les outils changent.
Commencez par vérifier l’état de vos conteneurs :docker ps
Cette commande vous permet de voir si les conteneurs attendus sont bien démarrés, arrêtés ou en erreur.
Ensuite, consultez les logs de l’application :docker compose logs
Ces journaux sont votre principale source d’information pour comprendre ce qui bloque le démarrage ou l’accès à l’application.
Les erreurs les plus courantes concernent généralement trois éléments :
Les ports : un port exposé par le conteneur est déjà utilisé par un autre composant sur la machine.
Les permissions : l’application n’a pas les droits nécessaires pour lire ou écrire dans un répertoire monté en volume.
L’environnement hôte : le serveur manque d’espace disque, de mémoire ou rencontre un problème réseau.
Comme le rappelle Alex :
Ne relance jamais un service au hasard en espérant que le problème disparaisse. Un bon admin sait expliquer pourquoi ça ne marche pas. Prends donc le temps de lire l’erreur, de comprendre ce qui bloque, puis d’agir en conséquence.

L'équipe technique a finalisé la préparation de la nouvelle application de partage de fichiers. Un collègue vous transmet le fichier compose.yml pour que vous puissiez l'exécuter sur notre serveur. Confiant, vous lancez le déploiement, mais le terminal vous renvoie immédiatement une erreur : les conteneurs démarrent mal et l'application est totalement inaccessible !
C’est un grand classique : le fichier Compose tente d’exposer l’application sur un port déjà utilisé par un autre service de la machine. À vous d’identifier le conflit et de corriger la configuration.
Pour reproduire cet incident de manière sécurisée sur votre machine virtuelle, vous allez d'abord lancer un petit service en tâche de fond pour "bloquer" volontairement un port, puis tenter de déployer une infrastructure par-dessus.
1. Créez un dossier pour votre projet et placez-vous à l'intérieur : mkdir mon_projet && cd mon_projet
2. Lancez un service natif temporaire en arrière-plan pour bloquer le port 8080 de votre serveur :
python3 -m http.server 8080 &
3. Créez maintenant le fichier de configuration de l'application (qui tente d'utiliser ce même port) en copiant-collant la commande suivante dans votre terminal :
cat <<EOF > compose.yml
services:
web:
image: nginx:latest
ports:
- "8080:80"
EOFVotre environnement est prêt et le piège est en place. C'est le moment d'appliquer votre méthode de diagnostic :
Lancez le déploiement de l'application avec la commande dockercompose up -d. Constatez immédiatement l'échec et lisez attentivement le message d'erreur retourné par le système dans votre terminal (il vous parlera probablement de bind: address already in use).
Vérifiez l'état de l'infrastructure avecdocker ps. Vous remarquerez que votre conteneur n'est pas actif.
Consultez les logs avecdocker compose logspour confirmer l'origine du blocage. Le diagnostic est clair : le port 8080 demandé par votre conteneur est déjà utilisé par une autre application de la machine !
Corrigez le problème en éditant votre fichiercompose.yml(par exemple avec vim). Modifiez la section ports pour exposer votre service web sur un autre port libre du serveur, comme le8081(modifiez8080:80 en8081:80).
Relancez votre infrastructure.
Validez la résolution de l'incident en utilisant à nouveaudocker ps. Votre conteneur doit cette fois-ci apparaître comme fonctionnel en arrière-plan !
Docker Compose permet d’orchestrer une application composée de plusieurs conteneurs en décrivant l’ensemble des services, des ports et des dépendances dans un fichiercompose.ymlunique et structuré.
La commandedocker compose up -dlance tous les conteneurs définis en arrière-plan, tandis quedocker pspermet de vérifier rapidement leur état d’exécution.
Les volumes Docker assurent la persistance des données en les stockant en dehors du cycle de vie des conteneurs, ce qui protège les informations lors d’une suppression ou d’une mise à jour.
Le diagnostic d’un déploiement repose sur une méthode rigoureuse consistant à vérifier l’état des conteneurs puis à analyser les journaux avecdocker compose logsafin d’identifier précisément la cause de l’échec.
Les erreurs fréquentes concernent les conflits de ports, les permissions des volumes ou les ressources insuffisantes du serveur, ce qui impose une lecture attentive des messages d’erreur avant toute correction.
En partant de votre machine sécurisée, vous avez appris à héberger, maintenir et déployer des services robustes avec méthode. Du pilotage des processus natifs à la configuration d'un accès SFTP confiné, vous avez finalement franchi un cap en orchestrant une application conteneurisée avec Docker Compose.
Avant de déployer vos propres projets, gardez en tête les règles d’or d’Alex :
Interrogez toujours les logs : Ne relancez jamais un service au hasard. Lisez les journaux ( journalctl , docker compose logs ) pour comprendre pourquoi ça bloque.
Isolez pour mieux régner : Que ce soit via un chroot ou un conteneur, l'isolation protège votre système hôte et évite les conflits.
Privilégiez la reproductibilité : Un déploiement fiable commence toujours par une description claire ( compose.yml ).
Anticipez la perte de données : Un conteneur étant éphémère, utilisez systématiquement des volumes pour persister vos données en production !
Votre infrastructure est prête à relever de nouveaux défis. À vous de la faire évoluer en gardant ces excellents réflexes d’administration !