📘 Réseaux virtuels et déploiements multi-conteneurs

1. Problématique

Nous avons vu qu’un processus doit souvent communiquer avec d’autres processus (et donc d’autres logiciels) pour fonctionner. Par exemple, le processus d’un site web doit souvent communiquer avec le processus d’une base de données, par exemple pour demander à ce dernier de stocker des informations.

Idéalement, lors d’un déploiement qui implique plusieurs logiciels, nous souhaitons que chaque logiciel soit isolé dans son propre conteneur, pour faciliter son déploiement et pour lui offrir le meilleur environnement. Nous appelons ce type de déploiement un déploiement multi-conteneurs.

Cependant, une question technique doit être résolue pour permettre ce type de déploiement : comment permettre à des processus situés dans des conteneurs différents de communiquer entre eux ?

Nous avons vu dans un chapitre précédent qu’il était possible pour un conteneur de publier un port réseau. Malheureusement, ce méchanisme ne sera pas suffisant pour un déploiement multi-conteneurs: une publication de port permet uniquement à un processus extérieur à l’environnement d’accueil de communiquer avec un processus situé dans le conteneur.

Pour résoudre ce problème, dans ce (bref) chapitre nous allons apprendre le principe du réseau virtuel, qui permet de relier plusieurs conteneurs entre eux via un réseau purement logiciel.

2. Principe

La publication de port permet de répondre à une situation où un processus extérieur à l’environnement d’accueil souhaite communiquer avec un processus à l’intérieur d’un conteneur de l’environnement d’accueil.

Cependant, que faire lorsque deux processus souhaitent communiquer alors qu’ils sont dans le même environnement d’accueil, mais chacun dans un conteneur différent ?

Exemple 1. Problème de communication depuis l’extérieur vers Simplestblog conteneurisé

On considère à nouveau, Simplestblog, un logiciel qui s’exécute sous la forme d’un serveur web. Cette fois-ci, on se focalise sur le fait que Simplestblog stocke ses données dans un système de gestion de base de données (SGBD) via un logiciel à part appelé MariaDB. Dans ce contexte, c’est Simplestblog qui joue le rôle de processus client qui se contacte au processus serveur du SGBD.

Supposons que :

Simplestblog s’exécute au sein d’un conteneur dans un environnement d’accueil.
MariaDB s’exécute au sein d’un second conteneur dans le même environnement d’accueil.

Le processus MariaDB écoute sur le port 3306 et attend qu’un processus client se connecte pour lire ou écrire des entrées dans la base de données.

Même si MariaDB écoute sur un port réseau, ce n’est pas une publication de port puisqu’il n’y a aucun lien défini avec un port de l’interface réseau de l’environnement d’accueil.

Schématiquement, nous avons donc la situation suivante :

Ce schéma ne montre volontairement pas la publication de port définie dans la partie précédente, pour nous concentrer sur le problème de communication inter-conteneurs.

Problème : même si MariaDB écoute bien sur un port réseau, il est impossible pour Simplestblog de s’y connecter puisque les deux conteneux ne sont pas sur un même réseau informatique.

Pour remédier à ce type de situation, il est possible de relier différents conteneurs d’un même environnement à l’aide d’un réseau virtuel. Un réseau virtuel est un type de réseau purement logiciel (tout comme le réseau de rebouclage propre à chaque environnement) qui existe virtuellement au sein d’un environnement d’accueil donné. À sa création, un conteneur peut être connecté à un réseau virtuel à l’aide de son interface réseau virtuelle.

Par défaut, au sein d’un réseau virtuel, le nom d’hôte d’un conteneur est le nom donné au conteneur à sa création.

L’illustration ci-dessus présente trois conteneurs dans le même environnement d’accueil. On crée deux réseaux virtuels, à savoir R1 et R2. On ajoute les conteneurs A et B au réseau R1, et les conteneurs B et C au réseau R2.

Sur le réseau R2, les conteneurs B et C peuvent se contacter mutuellement. Par exemple, un processus exécuté dans C peut se connecter sur le port 465 du conteneur B (ou écrit autrement, peut se connecter à B:465).
Sur le réseau R1, les conteneurs A et B peuvent se contacter mutuellement. Par exemple, un processus exécuté dans B peut se connecter sur le port 5000 du conteneur A (ou écrit autrement, peut se connecter à A:5000).

Quelques points importants pour bien comprendre le cas général :

Un conteneur peut être sur plusieurs réseaux virtuels simultanément. C’est par exemple le cas ici du conteneur B.
Il est également possible qu’un réseau virtuel connecte plus de deux conteneurs simultanément.
Contrairement à la publication de port, la création et l’usage de réseaux virtuels est complétement séparée des interfaces réseaux matérielles de l’environnement d’accueil. Par exemple ici l’interface ethernet n’est absolument pas concernée par la mise en réseau purement logicielle des différents conteneurs entre eux.

Exemple 2. Relier Simplestblog à sa base de données avec un réseau virtuel

Pour permettre à Simplestblog, exécuté dans un conteneur appelé simplestblog_app, de communiquer avec le système de gestion de base de données MariaDB, exécuté dans un conteneur appelé simplestblog_db, on crée un réseau virtuel appelé simplestblog_network sur lequel on connecte les deux conteneurs :

Ainsi, le processus Simplestblog exécuté dans le conteneur simplestblog_app peut effectuer un accès réseau sur nom d’hôte simplestblog_db et le port 3306 (aussi écrit sous la forme simplestblog_db:3306), et ainsi se retrouver à échanger avec le processus MariaDB du conteneur simplestblog_db.

Exemple 3. Synthèse montages + publication de port + réseau virtuel pour déployer Simplestblog

Jusqu’ici dans le cours, sur le cas d’étude Simplestblog, nous avons regardé de manière séparée :

l’utilisation du montage de fichiers/répertoires, utilisé à la fois pour fournir un fichier de configuration à Simplestblog et pour persister les données de la base de donnée MariaDB,
l’utilisation d’une publication de port pour pouvoir se connecter au port réseau sur lequel écoute le processus Simplestblog,
l’utilisation d’un réseau virtuel pour permettre au processus Simplestblog de communiquer avec le processus MariaDB situé dans un conteneur séparé.

Voyons schématiquement à quoi ressemble ce déploiement une fois ces trois principes combinés :

3. Mise en œuvre avec Podman

La création d’un réseau virtuel doit se faire séparément et au préalable de la création d’un conteneur.

Pour créer un nouveau réseau virtuel :

$ podman network create <nom du réseau>

Pour lister tous les réseaux créés :

$ podman network ls

Ensuite, la connexion d’un conteneur à un réseau virtuel se fait lors de la création d’un conteneur (par exemple lors d’un appel à podman container run) à l’aide de l’option suivante :

--network <nom du réseau> : connecte le conteneur au réseau virtuel appelé <nom du réseau>.

Exemple 4. Déploiement de Simplestblog et sa base de données avec Podman

On souhaite déployer Simplestblog à l’aide de conteneurs. Il nous faut pour cela créer deux conteneurs : Simplestblog d’une part, et une base de données compatible MySQL d’autre part. Il nous faut également relier ces deux conteneurs à l’aide d’un réseau virtuel, afin de permettre à Simplestblog de se connecter à sa base de données.

On commence par préparer un réseau virtuel appelé simplestblog_network qui permettra aux deux conteneurs d’être connectés :

$ podman network create simplestblog_network

Pour la base de données, on souhaite utiliser l’image MariaDB disponible sur le registre Docker Hub à l’emplacement mariadb.

On souhaite que notre conteneur MariaDB :

soit nommé simplestblog_db,
soit en mode détaché,
soit automatiquement supprimé à la fin de son exécution,
possède un montage du répertoire de l’environnement d’accueil /data/simplestblog/database_data vers le répertoire /var/lib/mysql du conteneur, de manière à persister le contenu de la base de données sur l’environnement d’accueil,
soit sur la réseau virtuel simplestblog_network,
configure les variables d’environnement attendues par l’image MariaDB, c’est à dire :
- MARIADB_ROOT_PASSWORD, le mot de passe administrateur de l’instance MariaDB, avec la valeur "my_very_very_secret_root_password",
- MARIADB_DATABASE, le nom de la base de donnée pour Simplestblog, avec la valeur simplestblog
- MARIADB_USER, le nom d’utilisateur du compte base de données, avec la valeur "simplestblog",
- MARIADB_PASSWORD, le mot de passe pour le compte base de données, avec la valeur "my_very_secret_db_password",
utilise la version 11 de l’image de conteneur.

On exécute donc la commande suivante :

$ podman container run --name simplestblog_db \
             --detach \
             --rm \
             --mount type=bind,source=/data/simplestblog/database,target=/var/lib/mysql \
             --env MARIADB_ROOT_PASSWORD="my_very_very_secret_root_password" \
             --env MARIADB_DATABASE="simplestblog" \
             --env MARIADB_USER="simplestblog" \
             --env MARIADB_PASSWORD="my_very_secret_db_password" \
             --network simplestblog_network \
             docker.io/mariadb:11

Ensuite, pour Simplestblog, on fait usage de l’image disponible dans le registre de conteneurs du Gitlab Nantes Université, accessible à l’emplacement developpement_exploitation/resources/simplestblog. On suppose qu’une image de conteneur a déjà été préparée pour Simplestblog, et que cette image fait l’hypothèse qu’un fichier de configuration doit se trouver à l’emplacement /config.py au sein du conteneur. Ce fichier doit notamment contenir les informations indiquant à Simplestblog comment se connecter à sa base de données.

On prépare le fichier configuration Simplestblog suivant, à l’emplacement /data/simplestblog/test_config.py dans l’environnement d’accueil :

SECRET_KEY = "my_very_secret_key"

DB_TYPE = "mysql"

MYSQL_DATABASE_USER = "simplestblog"
MYSQL_DATABASE_DB = "simplestblog"
MYSQL_DATABASE_PASSWORD = "my_very_secret_db_password"
MYSQL_DATABASE_HOST = "simplestblog_db"
MYSQL_DATABASE_PORT = "3306"

Le contenu de ce fichier de configuration est préparé de manière à être compatible avec le conteneur MariaDB préparé plus haut. Plus précisément on peut constater que :

MYSQL_DATABASE_USER correspond à MARIADB_USER dans la configuration du conteneur MariaDB,
MYSQL_DATABASE_DB correspond à MARIADB_DATABASE dans la configuration du conteneur MariaDB,
MYSQL_DATABASE_PASSWORD correspond à MARIADB_PASSWORD dans la configuration du conteneur MariaDB,
MYSQL_DATABASE_HOST correspond au nom du conteneur MariaDB, car le nom du conteneur est également un nom d’hôte permettant d’atteindre le dit conteneur au sein du réseau virtuel où il se trouve (à savoir le réseau simplestblog_network dans notre exemple).
MYSQL_DATABASE_PORT correspond au port sur lequel écoute le processus MariaDB (à savoir, par défaut, 3306)

Enfin on souhaite que notre conteneur Simplestblog :

soit nommé simplestblog_app,
soit en mode détaché,
soit automatiquement supprimé à la fin de son exécution,
possède un montage du répertoire de l’environnement d’accueil /data/simplestblog/test_config.py vers le fichier /config.py du conteneur,
soit sur la réseau virtuel simplestblog_network,
publie son port 5000 sur le port 8100 de l’environnement d’accueil,
utilise la version 52 de l’image de conteneur.

On exécute donc la commande suivante :

$ podman container run --name simplestblog_app \
                       --detach \
                       --rm \
                       --mount type=bind,source=/data/simplestblog/test_config.py,target=/config.py \
                       --network simplestblog_network \
                       --publish 8100:5000 \
                       docker-registry.univ-nantes.fr/gl/developpement_exploitation/resources/simplestblog:60

On se retrouve ainsi avec un conteneur Simplestblog relié par un réseau virtuel à un conteneur MariaDB !

On notera également la commande suivante, pour supprimer tous les réseaux non utilisés par des conteneurs (pratique pour faire le ménage) :

$ podman network prune