TP02
Noms des auteurs : BONTEMS Antoine, SCHOONYANS Ann-Lore, LAMAND Cyril Date de réalisation : 14/02/2025
Documentez les commandes importantes de cette section.
docker run -p 80:80
--name web \
--mount type=bind,source="$(pwd)"/html,target=/usr/share/nginx/html/ \
custom-nginx
Cette commande crée le container en Bind Mount à partir de l'image custom-nginx. On sait donc accéder au serveur web sur le port 80.
docker run -p 80:80
--name web-volume
--mount source=mon-volume,target=/usr/share/nginx/html/
custom-nginx
Cette commande utilise le volume Docker pour créer le container à partir de l'image custom-nginx. Le container redirige toute les requêtes du port 80 vers son port 80.
Quelles sont les différences entre les deux types de volumes utilisés ici ? Dans quel cas utiliser l'un plutôt que l'autre?
Les Bind Mounts utilisent un chemin du système de fichiers hôte directement et on l'utilise pour le partage de données avec l’hôte, pour le développement et lorsqu’on est certain que le chemin du répertoire partagé de l’hôte existera toujours. Les Volumes Docker sont des espaces de stockage gérés par Docker et n'est pas destiné à être atteint par l'hôte. On l'utilise pour partager les données entre différents containers et lorsque les données doivent être stockée à distance.
-
Quelles sont les interfaces réseau et adresses IP de chaque container? Vous pouvez trouvez cette information soit depuis l'hôte avec un
docker inspect(cfr TP1), soit depuis le container lui-même. Note dans ce dernier cas : Si la commandeip addrn'est pas disponible, installez le packageiproute2.
L'adresse ip du premier container est 172.17.0.2 et le deuxième, c'est 172.17.0.3. -
Les containers peuvent-ils se joindre via
ping?
Oui, ils savent se joindre l'un l'autre.
-
Les containers ont-ils accès à Internet ?
Oui, ils y ont accès.
-
Est-ce une bonne idée d'utiliser ce réseau par défaut? Quels en sont les avantages et les inconvénients ?
Le réseau bridge est bien pour des réseaux simples mais si l'on de la sécurité il vaut mieux pas l'utiliser vu qu'il peut y avoir d'autres containers dessus. Il est facile à mettre en place, les containers peuvent communiquer entre eux grâce à leur adresse IP et les containers ne sont accessible de l'extérieur. Par contre, il a de moins bonne performances lorsque les réseaux deviennent plus complexes et il n'est pas sécurisé.
-
Le nouveau container ajouté sur le réseau
my-netpeut-il contacter les deux précédents (liés au réseau bridge par défaut)? A-t-il accès à Internet?
Non, il ne peut pas contacter les deux autres containers parce que les deux réseaux sont distincts. Le nouveau réseau a bien accès à internet.
-
Quels sont les différences entre ce nouveau réseau et le bridge par défaut? Quels en sont les avantages et inconvénients ?
Les différences sont que sur le réseau bridge, les containers partagent tous le même réseau et celui personnalisé est isolé de tous les autres réseaux. Grâce au réseau personnalisé, on peut faire des résolution DNS et il est plus adapté aux configurations complexes.
- Qu'avez-vous observé lors de cette première expérience avec Docker Compose ? Faites un court bilan sur base de screenshots.
- Documentez les commandes importantes.
On voit que les deux containers sont bien en cours d'exécution.
On voit que le volume a bien été créer ainsi que le réseau personnalisé.
Mes deux serveurs fonctionnent tous les deux correctement sur leur port (80 et 81).
Si l'on modifier la page HTML, les deux serveurs donnent correctement la nouvelle page
On arrive bien à les pinger avec leur nom.
Votre infrastructure est-elle conforme à ce qui était attendu? Comment avez-vous pu la valider? Donnez les commandes utilisées et illustrez le résultat par des screenshots.
C'est la config du docker-compose. Après on voit bien que chaque container à son bon volume et son bon réseau associé. On peut voir aussi que sur le web, il trois pages différentes en fonction du container lié au port choisit.
- Dans cette infrastructure, comment les données sont-elles partagées? Via des Bind Mounts ou des Volumes? Pourquoi ?
Le web utilise le Bind Mouts et la base de donnée les Volumes. Pour la DB, on a choisi les Volumes car les données doivent toujours exister même si le container est supprimer. Et le Bind Mount a été choisit pour le web car il permet de modifier directement les fichiers sur l’hôte et de voir les changements directement dans le container. - Quels sont les spécificités de chaque container?
Pour le web, c'est le port 3000 de l'hôte qui est redirigé vers le port 80 du container et il donne le contenu en local. La DB utilise le Volume pour garder les données.ec - Une fois démarrée, l'infrastructure est-elle conforme à ce qui était attendu? Comment avez-vous pu la valider? Donnez les commandes utilisées et illustrez le résultat par des screenshots.
Oui, cela fonctionne correctement. L'infrastructure utilise correctement les Bind Mounts et les Volumes Docker pour répondre aux besoins spécifiques des services. Le réseau personnalisé permet une communication entre les containers.
- Quelles sont vos observations suite à la réalisation de ce tutoriel ?
Le fichier compose crée deux containers le web et redis. Le web utilise une image à partir du Dockerfile présent et lie le port 5000 du conteneur et la machine hôte au port 8000. Le redis utilise une image prise du registre Docker Hub. - Sur quelle base les containers sont-ils lancés ?
Ils sont sur Compose et après sur Compose Watch. Le web crée son image à l'aide du Dockerfile défini et le redis à partir d'un image téléchargée du Docker Hub. - Qu'avez-vous appris de nouveau ?
Le Compose Watch qui permet à chaque fois qu'un fichier est modifié, Compose synchronise le fichier avec l'emplacement donné dans le conteneur. L'application en cours d'exécution se mettra à jour sans redémarrage.