TP3 - réseaux et volumes

Portainer

• Pour visualiser aisément notre environnement docker au fur et à mesure de nos TPs nous allons charger une interface web d’administration docker appelée portainer et qui s’installe elle-même avec docker.

docker run --detach --name portainer \
    -p 9000:9000 \
    -v portainer_data:/data \
    -v /var/run/docker.sock:/var/run/docker.sock \
    portainer/portainer-ce

• Remarque sur la commande précédente : pour que Portainer puisse fonctionner et contrôler Docker lui-même depuis l’intérieur du conteneur il est nécessaire de lui donner accès au socket de l’API Docker de l’hôte grâce au paramètre --mount ci-dessus.

• Visitez ensuite la page http://localhost:9000 pour accéder à l’interface.

• Créez votre user admin avec le formulaire.

• Explorons l’interface de portainer.

• Créer un conteneur

Docker networking

Pour expérimenter avec le réseau, nous allons lancer une petite application nodejs d’exemple (moby-counter) qui fonctionne avec une queue redis (comme une base de données mais pour stocker des paires clé/valeur simple).

Récupérons les images depuis Docker Hub:

• docker image pull redis
• docker image pull russmckendrick/moby-counter

Pour connecter les deux applications créons un réseau manuellement:

• docker network create moby-counter

Puis lancons les deux applications en utilisant notre réseau

• docker container run -d --name redis --network moby-counter redis

• docker container run -d --name moby-counter --network moby-counter -p 8000:80 russmckendrick/moby-counter

• Visitez la page de notre application. Qu’en pensez vous ? Moby est le nom de la mascotte Docker :).

Comment notre application se connecte-t-elle au conteneur redis ? Elle utilise ces instructions JS dans son fichier server.js:

var port = opts.redis_port || process.env.USE_REDIS_PORT || 6379;
var host = opts.redis_host || process.env.USE_REDIS_HOST || "redis";

En résumé par défaut, notre application se connecte sur l’hôte redis avec le port 6379

Explorons un peu notre réseau Docker.

• Exécutez à l’intérieur du conteneur moby-counter avec (docker exec) la commande ping -c 3 redis sur notre conteneur applicatif. Quelle est l’adresse ip affichée ?

• De même, affichez le contenu des fichiers /etc/hosts et /etc/resolv.conf. Nous constatons que docker a automatiquement configuré le nom d’hôte de la machine avec l’identifiant du conteneur.

• Pour le vérifier interrogeons le serveur DNS de notre réseau moby-counter en lançant la commande nslookup redis 127.0.0.11 toujours grâce à docker exec.

• Créez un deuxième réseau moby-counter2 et une deuxième instance de l’application dans ce réseau : docker run --name moby-counter2 --network moby-counter2 -p 9090:80 russmckendrick/moby-counter

• Lors que vous pingez redis depuis cette nouvelle instance de l’application, quelle ip obtenez vous ?

• Récupérez comme auparavant l’adresse ip du nameserver local pour moby-counter2.

• Puis lancez nslookup redis <nameserver_ip> pour tester la résolution de DNS. Comparer l’adresse ip avec les adresses habituelles Docker.

Bien que vous ne puissiez pas avoir deux conteneurs avec les mêmes noms, comme nous l’avons déjà découvert, notre deuxième réseau fonctionne complètement isolé de notre premier réseau, ce qui signifie que nous pouvons toujours utiliser le domaine redis ; pour ce faire, nous devons ajouter le drapeau --network-alias :

• Créons un deuxième redis avec le même domaine: docker container run -d --name redis2 --network moby-counter2 --network-alias redis redis

• Relancez la résolution précédente avec nslookup.

• Vous pouvez retrouver la configuration du réseau et les conteneurs qui lui sont relié avec docker network inspect moby-counter.
  Notez la section IPAM (IP Address Management).

• Arrêtons nos conteneurs docker container stop moby-counter2 redis2.

• Pour faire rapidement le ménage des conteneurs arrêtés lancez docker container prune.

• De même docker network prune permet de faire le ménage des réseaux qui ne sont plus utilisés par aucun conteneur.

Docker Volumes

Pour ne pas interférer avec la deuxième partie du TP :

• Stoppez tous les conteneurs redis et moby-counter avec docker stop ou portainer.
• Supprimez les conteneurs arrêtés avec docker container prune
• Lancez docker volume prune pour faire le ménage de volume éventuellement créés dans les TPs précédent
• Lancez docker volume ls pour vérifier qu’aucun volume n’est créé sinon supprimez les avec docker volume rm --force <id_volume>
• Lancez aussi docker network prune pour nettoyer les réseaux inutilisés

Passons à l’exploration des volumes:

• Recréez le réseau moby-counter et les conteneurs redis et moby-counter à l’intérieur:

docker network create moby-counter
docker container run -d --name redis --network moby-counter redis
docker container run -d --name moby-counter --network moby-counter -p 8000:80 russmckendrick/moby-counter

• Visitez votre application dans le navigateur. faites un motif reconnaissable en cliquant.
• supprimez le conteneur redis : docker rm --force redis
• Rechargez la page web: l’app est deconnectée de son backend.
• Recréez le redis à nouveau dans le réseau moby-counter: docker container run -d --name redis --network moby-counter redis
• Redémarrez le conteneur moby-counter : docker restart moby-counter
• Rechargez la page. Que s’est-il passé ?

• Supprimez à nouveau le conteneur redis.

Avons nous vraiment perdu les données de notre conteneur ? (spoiler non)

le Dockerfile pour l’image officielle Redis ressemble à ça:

FROM alpine:3.5

RUN addgroup -S redis && adduser -S -G redis redis
RUN apk add --no-cache 'su-exec>=0.2'`docker container prune`
`docker network prune`
`docker volume prune`
ENV REDIS_VERSION 3.0.7
ENV REDIS_DOWNLOAD_URL http://download.redis.io/releases/redis-3.0.7.tar.gz
ENV REDIS_DOWNLOAD_SHA e56b4b7e033ae8dbf311f9191cf6fdf3ae974d1c
RUN set -x \
    && apk add --no-cache --virtual .build-deps \
        gcc \
        linux-headers \
        make \
        musl-dev \
        tar \
    && wget -O redis.tar.gz "$REDIS_DOWNLOAD_URL" \
    && echo "$REDIS_DOWNLOAD_SHA *redis.tar.gz" | sha1sum -c - \
    && mkdir -p /usr/src/redis \
    && tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
    && rm redis.tar.gz \
    && make -C /usr/src/redis \
    && make -C /usr/src/redis install \
    && rm -r /usr/src/redis \
    && apk del .build-deps

RUN mkdir /data && chown redis:redis /data
VOLUME /data
WORKDIR /data
COPY docker-entrypoint.sh /usr/local/bin/
RUN ln -s usr/local/bin/docker-entrypoint.sh /entrypoint.sh # backwards compat
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379
CMD [ "redis-server" ]

Notez, vers la fin du fichier, il y a une instruction VOLUME /data; Cela signifie que lorque notre conteneur a été lancé, un volume “caché” a effectivement été créé par Docker.

La beaucoup de conteneurs docker sont des applications stateful c’est à dire qui stockent des données. Automatiquement ces conteneurs créent des volument anonymes en arrière plan qu’il faut ensuite supprimer manuellement (avec rm ou prune).

• Pour le confimer allez voir la liste des volumes dans portainer. Normalement il devrait y avoir un volume portainer_data et un volume anonyme avec un hash.

• Copiez l’id du volume anonyme du type: 4d8e8cfec5461406de805fc37913177cab1325893ad7972c16275bcf851d27ed

• Créez un nouveau conteneur redis en rattachant le volume du précédent redis.
  docker container run -d --name redis --volume <volume_id>:/data --network moby-counter redis:alpine

• Redémarrez moby-counter et visitez la page de l’application. Normalement un motif de moby d’une précédente session devrait s’afficher (après un délai)

• Affichez le contenu du volume avec la commande : docker container exec redis ls -lhat /data

Finalement nous allons écraser ce volume anonyme par le notre : la bonne façon de créer des volumes consiste à les créer manuellement (volume nommés). docker volume create redis_data.

• Créez un nouveau conteneur attaché à ce volume nommé : docker container run -d --name redis -v redis_data:/data --network moby-counter redis:alpine

Bind Mounting
Lorsqu’un répertoire hôte spécifique est utilisé dans un volume (la syntaxe -v HOST_DIR:CONTAINER_DIR), elle est souvent appelée bind mounting.
C’est quelque peu trompeur, car tous les volumes sont techniquement “bind mounted”. La différence, c’est que le point de montage est explicite plutôt que caché dans un répertoire appartenant à Docker.

• Lancez docker volume inspect redis_data.

• Créez un réseau moby-counter2 et ajoutez un deuxième conteneur redis2 qui va partager les même données que le premier :

  • situé à l’intérieur du nouveau réseau (moby-counter2) comme à la partie précédent.
  • partageant le volume de données du premier (Cf cours)
  • monté en read-only (:ro après le paramètre de la question précédente)

Le read only est nécessaire pour que les deux redis n’écrivent pas de façon contradictoire dans la base de valeurs.

• Ajoutez une deuxième instance de l’application dans le deuxième réseau connectée à ce nouveau redis.

• Visitez la deuxième application: vous devriez voir également le même motif de moby apparaître.

• Pour nettoyer tout ce travail, arrêtez les les deux redis et les deux moby-counter.

• Lancez trois prune pour les conteneurs d’abord puis les réseaux et les volumes.

Comme les réseau et volumes n’étaient plus attachés à des conteneurs en fonctionnement ils ont étés supprimés. Généralement, il faut faire beaucoup plus attention au prune de volumes (données à perdre) que de conteneur(rien à perdre car immutable et dans le registry).