TP2
Noms des auteurs : WILLEMS Julien
Date de réalisation : 23 février 2025
Documentez les commandes importantes de cette section.
Création d'un volume Docker (à adapter) :
$ docker run -p 80:80 --name web-volume –mount source=mon-volume,target=/usr/share/nginx/html/ custom-nginx
Inspection d'un volume Docker :
$ docker volume inspect <nom du volume>
Effectuer un Bind Mount (à adapter) :
$ docker run -p80:80 --name=Web --mount type=bind,source="$(pwd)"/html,target=/usr/share/nginx/html/ custom-nginx
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?
Bind Mount → Le bind mount n'est finalement qu'une simple "liaison" d'un fichier présent sur la machine hôte. Cela signifie concrètement que l'on se contente de "greffer" un lien vers ledit fichier sur le conteneur. Docker Volume → Ici, un volume est créé (un peu comme une clé USB virtuelle) que l'on peut monter sur plusieurs conteneurs. L'édition d'un fichier présent dans ce volume impactera tous les conteneurs sur lequel ce dernier est monté.
En ce qu'il s'agit du cas d'usage de l'un et de l'autre, on a tendance à recommander les volumes dans le cas où les fichiers qui y sont insérés ne seront utilisés et gérés que par Docker et les Bind Mount seront quant à eux nécéssaires si l'on souhaite que d'autres processus/applications que Docker puissent aller éditer ces fichiers.
Source : https://blog.logrocket.com/docker-volumes-vs-bind-mounts/
Documentez les commandes importantes de cette section.
Création d'un nouveau réseau Docker :
$ docker network create <nom pour le réseau>
Liste de tous les réseaux Docker existant :
$ docker network ls
Inspection d'un réseau Docker :
$ docker network inspect <nom du réseau>
Création d'un nouveau conteneur faisant partie d'un réseau existant au préalable :
$ docker run --net <nom réseau existant> --name <nom pour le conteneur> <nom de l'image>
1. 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 commande ip addrn'est pas disponible, installez le package iproute2.
Rappel de la commande permettant de trouver rapidement une adresse IP de conteneur :
$ docker inspect <nom du conteneur> | grep "Address"
Dans mon cas, l'adresse IP du premier conteneur, lié au port n°80 de la machine hôte, a l'adresse IP 172.17.0.2. L'adresse IP du second conteneur, quant à lui lié au port n°81 de la machine hôte, a l'adresse IP 172.17.0.3.
2. Les containers peuvent-ils se joindre via ping ?
Oui étant donné qu'ils ont été lié au même réseau lors de leur création.
3. Les containers ont-ils accès à Internet ?
Oui.
4. Est-ce une bonne idée d'utiliser ce réseau par défaut? Quels en sont les avantages et les inconvénients ?
Le premier avantage d'utiliser ce réseau par défaut est sa facilité de configuration et d'utilisation. En effet, tout ce qui est résolution DNS est fait automatiquement et on peut aussi employer le port mapping pour lier un port du conteneur à un port de la machine hôte. En contrepartie, l'utilisation de ce réseau n'offre pas la possibilité d'utiliser des configurations plus avancées et peut donc s'avérer être un défi lorsqu'il s'agit de la gestion des adresses IP etc.
1. Le nouveau container ajouté sur le réseau my-net peut-il contacter les deux précédents (liés au réseau bridge par défaut)? A-t-il accès à Internet?
Ce nouveau conteneur a effectivement accès à internet puisque la commande $ apt update fonctionne. En ce qu’il s’agit de savoir s’il peut joindre les deux autres conteneurs, il faut d’abord se souvenir de leur adresse IP. Celle de “web-volume” est la 172.17.0.2/16.
Si l’on fait, depuis “web-my-net”, un ping vers l’adresse IP de “web-volume”, ce dernier n’aboutit pas. En revanche, si l’on retourne sur un conteneur connecté au réseau “bridge” et non “my-net”, tout fonctionne.
En lançant un nouveau conteneur que l’on connecte à ce réseau “my-net”, puis que l’on effectue un ping de celui-ci vers le tout premier conteneur connecté sur le réseau “my-net”, cela fonctionne.
2. Quels sont les différences entre ce nouveau réseau et le bridge par défaut? Quels en sont les avantages et inconvénients ?
Une première différence entre ce réseau personnalisé et celui par défaut, est que la résolution DNS est assurée par Docker. Donc, on peut ping d’autre conteneurs sur base de leurs noms de conteneur, chose que l’on n’a pas dans le réseau bridge par défaut.
1. Qu'avez-vous observé lors de cette première expérience avec Docker Compose ? Faites un court bilan sur base de screenshots.
Rien de particulier n’a été observé, c’est “juste” une façon d’automatiser la création d’une infrastructure. Cependant, une petite différence réside dans le fait que tous les conteneurs créés par ce docker-compose communiquent dans la même fenêtre de terminal.
2. Documentez les commandes importantes.
Lancement/création d'une infrastructure Docker sur base d'un fichier "docker-compose.yaml" :
$ docker-compose up
Arrêt des conteneurs liés à une infrastructure Docker :
$ docker-compose down
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.
- Dans cette infrastructure, comment les données sont-elles partagées? Via des Bind Mounts ou des Volumes? Pourquoi ?
- Quels sont les spécificités de chaque container?
- 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.