💻 TP : Faire un déploiement multi-conteneurs

Dans un TP précédent, vous avez vu comment rendre un conteneur joignable depuis l’extérieur de son environnement d’accueil, à l’aide d’un mécanisme appelé la publication de port. Cependant, la publication de port n’est pas adaptée lorsque des logiciels exécutés dans des conteneurs différents ont besoin de communiquer entre eux.

Dans ce TP, vous allez voir comment rendre possible la communication inter-conteneurs à l’aide de réseaux virtuels.

1. Tutoriel : premiers réseaux virtuels

Jusqu’ici, le déploiement de chaque service a nécessité la création d’un seul conteneur à la fois, souvent à l’aide d’une publication de port pour rendre ce conteneur accessible depuis un réseau local. Or, il est courant qu’un même service nécessite le fonctionnement de plusieurs conteneurs reliés entre eux − typiquement, un logiciel applicatif associé à un système de gestion de base de données. Voyons comment déployer plusieurs conteneurs mis en réseau.

1.1. Deux conteneurs sur un même réseau virtuel

1.1.1. Mise en place

Pour commencer, créons un réseau virtuel r1 qui permette de relier plusieurs conteneurs entre eux :

[sur l’environnement de déploiement distant]

$ podman network create r1

On peut vérifier que ce réseau a bien été créé avec la commande suivante, qui liste les réseaux virtuels existants :

[sur l’environnement de déploiement distant]

$ podman network ls

Un conteneur peut être relié à un réseau virtuel uniquement lors de sa création. Dans un premier terminal, créons un premier conteneur interactif Alpine appelé conteneurA relié à ce réseau (à l’aide de l’option --network) :

[sur l’environnement de déploiement distant]

$ podman container run --name conteneurA \
                       --rm -ti \
                       --network r1 \
                       docker.io/alpine:3.22

Gardez au chaud ce premier terminal dans lequel s’exécute conteneurA, et ouvrez un second terminal dans lequel nous allons créer un second conteneur interactif conteneurB également connecté au réseau appelé r1 :

[sur l’environnement de déploiement distant]

$ podman container run --name conteneurB \
                       --rm -ti \
                       --network r1 \
                       docker.io/alpine:3.22

Ensuite, pour tester leur mise en réseau, nous allons installer dans les deux conteneurs l’utilitaire netcat, qui a l’avantage de permettre de facilement créer un petit processus serveur et un petit processus client.

Au sein d’un conteneur Alpine, netcat est disponible via le paquet netcat-openbsd installable à l’aide du gestionnaire de paquets apk. On commence donc par installer netcat dans chacun des deux conteneurs :

[dans conteneurA]

# apk update && apk add netcat-openbsd

[dans conteneurB]

# apk update && apk add netcat-openbsd

Utiliser netcat pour du test réseau simple

Une fois netcat installé dans un environnement Linux donné, il peut être utilisé à l’aide de la commande nc. On peut distinguer deux usages simples de la commande netcat nc :

on peut demander à nc de se comporter comme un processus serveur qui écoute sur un port réseau, de manière à pouvoir recevoir une connexion requise par un processus client, à l’aide de la commande suivante :
```
nc -l <port d'écoute>
```
L’option -l signifie listen, ce qui se traduit en "écouter".

on peut demander à nc de se comporter comme un processus client qui se connecte à un port réseau d’un environnement donné (désigné par son nom d’hôte), de manière pouvoir se connecter à un processus serveur exécuté dans cet autre environnement, à l’aide de la commande suivante :

nc <nom d'hôte> <port auquel se connecter>

Un processus serveur nc ne peut pas recevoir plus d’une seule connexion à la fois, ainsi un seul processus client peut se connecter à un processus serveur. Cela n’est pas représentatif du cas général dans le monde du logiciel : il est habituel qu’un processus serveur puisse recevoir plusieurs connexions en parallèle (par exemple un serveur web peut recevoir des connexions de plusieurs navigateurs web).

Si une de ces commandes se termine instantanément, et vous rend la main, c’est que la connexion a échoué − cela peut arriver si le nom d’hôte et/ou le port renseigné est incorrect ou incohérent.

Mais à l’inverse, si les deux commandes ne se terminent pas et ne vous rendent pas la main, c’est généralement qu'une connexion a été établie entre processus serveur et processus client.

Il est alors possible d’effectuer une saisie au clavier, puis d’appuyer sur Entrée, pour envoyer un texte au processus serveur, qui l’affiche dès réception. À l’inverse, si on écrit un texte côté serveur et qu’on appuie sur entrée, le message s’affiche côté client.

Pour arrêter une commande nc en cours d’exécution, on peut faire la combinaison de touches Ctrl+C dans le terminal concerné.

Faisons l’inventaire de ce que nous avons en place :

Un réseau virtuel appelé r1,
Un conteneur appelé conteneurA, relié à ce réseau virtuel. Au sein de ce réseau virtuel, conteneurA est joignable au travers du nom d’hôte conteneurA (identique à son nom de conteneur).
Un conteneur appelé conteneurB, relié au même réseau virtuel. Là aussi, au sein de ce réseau virtuel, conteneurB est joignable au travers du nom d’hôte conteneurB (identique à son nom de conteneur).

Maintenant, utilisons netcat pour tester cette mise en réseau !

1.1.2. Test 1 : serveur dans `conteneurA`, client dans `conteneurB`

Utilisons netcat pour démarrer un processus serveur qui écoute sur le port 5000 du conteneurA :

[dans conteneurA]

# nc -l 5000

Une fois cette cette commande exécutée, il semble ne rien se passer. C’est normal : netcat a démarré son processus serveur et est en attente d’une connexion, donc il reste (très) silencieux pour le moment.

Puis utilisons netcat pour démarrer un processus client qui se connecte sur le port 5000 de conteneurA :

[dans conteneurB]

# nc conteneurA 5000

Si la connexion est bien établie (lire l’encart sur netcat plus haut), vous pouvez alors :

envoyer "bonjour depuis conteneurB !" depuis le processus client exécuté sur le conteneurB, et vérifier que le message s’affiche dans le terminal avec le conteneurA,
envoyer "bonjour depuis conteneurA !" depuis le processus serveur exécuté sur le conteneurA, et vérifier que le message s’affiche dans le terminal avec le conteneurB.

Figure 1. Échange de messages entre les deux conteneurs Alpines

Si tout fonctionne, vous avez fait votre première mise en réseau de plusieurs conteneurs !

1.1.3. Test 2 : client dans `conteneurB`, client dans `conteneurA`

Juste pour démontrer que la connexion entre les deux conteneurs est bien symétrique, reproduisez le même test mais en inversant les deux rôles :

démarrez un processus nc serveur depuis conteneurB, sur un port d’écoute différent de 5000,
démarrer un processus nc client depuis conteneurA pour se connecteur au conteneurB sur le port choisi à l’étape précédente,
échangez des messages dans les deux sens pour vérifier que tout fonctionne.

1.2. Trois conteneurs sur deux réseaux virtuels

1.2.1. Mise en place

Dans la dernière partie de ce tutoriel, voyons comment deux réseaux virtuels peuvent coexister.

Notre objectif va être de garder le premier réseau, puis de créer un second réseau r2, et d’y connecter une partie de nos conteneurs. Nous souhaitons faire en sorte d’avoir :

un conteneur conteneurA connecté au réseau r1,
un conteneur conteneurB connecté aux réseaux r1 et r2,
un conteneur conteneurC connecté au réseau r2.

Commençons par créer le nouveau réseau :

[sur l’environnement de déploiement distant]

$ podman network create r2

Vérifions que les deux réseaux co-existent bien :

[sur l’environnement de déploiement distant]

$ podman network ls

On peut garder le conteneurA à l’identique, car est déjà relié au réseau r1 comme souhaité.

Nous devons par contre recréer le conteneurB car nous souhaitons qu’il soit relié aux deux réseaux virtuels. On peut faire les commandes suivantes dans le terminal dédié au conteneurB :

[sur l’environnement de déploiement distant]

$ podman container rm --force conteneurB
$ podman container run --name conteneurB \
                       --rm -ti \
                       --network r1 \
                       --network r2 \
                       docker.io/alpine:3.22

Enfin, dans un troisième terminal, on crée le conteneurC de la sorte :

[sur l’environnement de déploiement distant]

$ podman container run --name conteneurC \
                       --rm -ti \
                       --network r2 \
                       docker.io/alpine:3.22

Sur les deux conteneurs Alpine ainsi (re)créés, installez la commande nc comme fait précédemment.

Voyons maintenant ce que ce déploiement jouet permet de faire.

1.2.2. Test 1 : communications depuis le `conteneurB`

Sur le conteneurA, démarrez un processus serveur nc qui écoute sur le port 8888.
Sur le conteneurC, démarrez un processus serveur nc qui écoute également sur le port 8888.

On peut sans problème ici utiliser le même numéro de port, car chacun de ces ports est ouvert dans un environnement différent (et donc sur une interface réseau différente).
Sur le conteneurB, démarrez un processus client nc qui se connecte au port 8888 du conteneurA, puis échangez des messages dans les deux sens pour vérifier que tout fonctionne.
Sur le conteneurB, démarrez un processus client nc qui se connecte au port 8888 du conteneurC, puis échangez des messages dans les deux sens pour vérifier que tout fonctionne.

Si tout se passe bien, vous pouvez constater que les messages arrivent à s’échanger dans les deux cas :

Dans le premier cas, les messages entre conteneurB et conteneurA transitent via le réseau virtuel r1.
Dans le second cas, les messages entre conteneurB et conteneurC transitent via le réseau virtuel r2.

1.2.3. Test 2 : communication entre `conteneurA` et `conteneurC` ?

Sur le conteneurA, démarrez un processus serveur nc qui écoute sur le port 9999.
Sur le conteneurC, démarrez un processus client nc qui tente de se connecter au port 9999 du conteneurA, puis tentez d’échanger des messages entre les deux processus.

Si votre mise en place est correcte, les échanges de messages ne devraient ici… pas fonctionner !

En effet, même s’il existe un réseau r1 entre conteneurA et conteneurB, et un réseau r2 entre conteneurB et conteneurC, il n’existe aucun réseau entre conteneurA et conteneurC. Ainsi il est impossible de créer une commumnication directe entre les deux.

À retenir

En réfléchissant bien à quelles connexions sont nécessaires entre nos conteneurs, on peut s’assurer avec nos réseaux virtuels quelles communications inter-conteneurs sont possible/autorisées, et lesquelles ne sont impossibles/interdites.

Ce dernier cas est utile pour éviter que deux processus communiquent entre eux "par erreur" (ou par malice) alors qu’ils ne devraient pas.

2. Tutoriel : déployer un service Mealie à l’aide d’un réseau virtuel

On se propose de déployer un service Mealie, un logiciel libre permettant de stocker et partager des recettes de cuisine. Mealie est capable de fonctionner avec un système de gestion de base de données de type PostgreSQL, on souhaite donc déployer Mealie avec sa propre base de données PostgreSQL.

Avant tout, commencez par créer sur l’environnement d’accueil un répertoire mealie_deployment qu’on utilisera pour nos prochains montages de répertoire.

2.1. Réseau virtuel

Commençons par préparer un réseau virtuel qui permettra à nos deux futurs conteneurs de communiquer entre eux.

Exécutez la commande suivante pour créer un réseau virtuel appelé mealie_network :

[sur l’environnement de déploiement distant]

$ podman network create mealie_network

On peut vérifier que ce réseau a bien été créé avec la commande :

[sur l’environnement de déploiement distant]

$ podman network ls

Le réseau virtuel devrait apparaître dans la liste, avec son propre identifiant unique et le driver bridge.

Nous n’utiliserons pas d’autres drivers réseau que bridge.

2.2. Conteneur PostgreSQL

On peut maintenant préparer le système de gestion de base de données PostgreSQL.

On choisit d’utiliser l’image de conteneur officielle PostgreSQL située sur le Docker Hub. En lisant la documentation de l’image, on observe que :

Le point d’entrée de l’image est l’exécution du logiciel PostgreSQL,
Les données de la base de données sont stockées dans le répertoire /var/lib/postgresql/data du conteneur,
Par défaut, le logiciel PostgreSQL écoute sur le port 5432 du conteneur,
Par défaut, lors du premier lancement d’un conteneur, un compte PostgreSQL est créé, ainsi qu’une base de données vide à laquelle ce compte peut accéder. Des variables d’environnement sont disponibles pour configurer cela :
- POSTGRES_USER permet de spécifier le nom du compte PostgreSQL,
- POSTGRES_PASSWORD, permet de spécifier le mot de passe du compte POSTGRES_USER,
- POSTGRES_DB permet de spécifier le nom de la base de données créée pour le compte POSTGRES_USER.

Dans le répertoire mealie_deployment que vous avez préparé, créez un sous-répertoire appelé db-data dans lequel nous stockerons les données de la base de données. Utilisez la commande pwd pour obtenir le chemin absolu du répertoire db-data, et notez ce chemin absolu quelque part.

Exécutez ensuite la commande suivante pour créer votre conteneur PostgreSQL, en version 16, avec pour nom mealie_db, en l’ajoutant sur le réseau mealie_network, et en préparant un compte PostgreSQL appelé mealie avec pour mot de passe mealie_password et pour base de données mealie_db.

[sur l’environnement de déploiement distant]

$ podman container run --rm \
                       --detach \
                       --name mealie_db \
                       --network mealie_network \
                       --mount type=bind,source="<chemin absolu db-data>",target="/var/lib/postgresql/data" \
                       --env POSTGRES_USER=mealie \
                       --env POSTGRES_PASSWORD=mealie_password \
                       --env POSTGRES_DB=mealie_data \
                       docker.io/postgres:16

Mais puisque PostgreSQL écoute sur le port 5432, pourquoi n’avons-nous pas effectué une publication de ce port ? La raison est la suivante : nous ne souhaitons pas que ce conteneur PostgreSQL soit accessible par n’importe quel logiciel sur le réseau du serveur de déploiement. À la place, nous souhaitons qu’il soit uniquement accessible par notre application, à savoir Mealie, au travers du réseau virtuel mealie_network que nous avons préparé.

Vérifiez que le conteneur est bien en exécution avec :

[sur l’environnement de déploiement distant]

$ podman container ps

Puis vérifiez les logs du conteneur pour s’assurer que tout va bien :

[sur l’environnement de déploiement distant]

$ podman container logs mealie_db

Vers la fin, vous devriez notamment voir la ligne :

PostgreSQL init process complete; ready for start up.

Et quelques lignes plus loin :

database system is ready to accept connections

Vérifiez enfin que le conteneur est bien sur le réseau mealie_network à l’aide de la commande :

[sur l’environnement de déploiement distant]

$ podman container ps --filter network=mealie_network

Si le conteneur est bien dans la liste, c’est que tout est OK !

2.3. Conteneur Mealie

Il ne nous reste plus qu’à lancer un conteneur Mealie, et de lui permettre d’utiliser notre base de données PostgreSQL située dans le premier conteneur.

Mealie est développé à l’aide d’un projet sur la forge logicielle Github, et utilise le registre de conteneurs Github pour stocker les images de conteneur de l’application. Les images seront donc accessibles à l’aide du registre ghcr.io, sous le nom mealie-recipes/mealie.

En lisant la documentation de Mealie, on trouve les informations utiles suivantes :

Le point d’entrée de l’image est l’exécution du logiciel Mealie,
Le logiciel écoute par défaut sur le port 9000 du conteneur,
Le logiciel a besoin de stocker des fichiers (notamment des photos téléversées pour illustrer les recettes de cuisine) dans le répertoire /app/data/ du conteneur,
On peut configurer l’accès à la base de données à l’aide des variables d’environnement suivantes :
- DB_ENGINE permet d’indiquer le type de la base de données, avec soit la valeur sqlite, soit la valeur postgres,
- POSTGRES_SERVER permet d’indiquer le nom d’hôte réseau du serveur PostgreSQL à utiliser pour stocker les données,
- POSTGRES_DB permet d’indiquer le nom de la base de données à utiliser au sein du serveur PostgreSQL,
- POSTGRES_USER permet d’indiquer le compte à utiliser pour se connecter au serveur PostgreSQL,
- POSTGRES_PASSWORD permet d’indiquer le mot de passe à utiliser pour se connecter au serveur PostgreSQL,
- POSTGRES_PORT permet d’indiquer le port à utiliser pour se connecter au serveur PostgreSQL.

Avec tout cela en tête, préparez et exécutez la commande suivante, afin de créer un conteneur Mealie, en version v1.0.0-RC1.1, appelé mealie, sur le réseau virtuel mealie_network, avec une publication de port et avec la bonne configuration pour se connecter à la base de données PostgreSQL préparée à l’étape précédente :

[sur l’environnement de déploiement distant]

$ podman container run --rm \
                       --detach \
                       --name mealie \
                       --network mealie_network \
                       --publish <mon port réseau>:9000 \
                       --env DB_ENGINE=postgres \
                       --env POSTGRES_SERVER=mealie_db \
                       --env POSTGRES_DB=mealie_data \
                       --env POSTGRES_USER=mealie \
                       --env POSTGRES_PASSWORD=mealie_password \
                       --env POSTGRES_PORT=5432 \
                       ghcr.io/mealie-recipes/mealie:v1.0.0-RC1.1

en remplaçant <mon port réseau> par un port réseau de votre choix de votre plage de port attribuée.

Toutes les informations écrites dans les variables POSTGRES_ du conteneur Mealie doivent absolument correspondre exactement à la configuration effectuée du conteneur PostgreSQL au préalable. On notera par exemple que POSTGRES_SERVER correspond au nom donné au conteneur PostgreSQL, car ce nom est également un nom d’hôte réseau au sein d’un réseau virtuel mealie_network.

Vérifiez que le conteneur est bien en exécution avec :

[sur l’environnement de déploiement distant]

$ podman container ps

Puis vérifiez les logs du conteneur pour s’assurer que tout va bien :

[sur l’environnement de déploiement distant]

$ podman container logs mealie

Vers la fin, vous devriez notamment voir la ligne :

Uvicorn running on http://0.0.0.0:9000

Cette ligne indique que Mealie écoute sur le port 9000, mais n’oubliez pas que nous avons publié ce port sur un port différent de l’environnement d’accueil !

Vérifiez enfin que le conteneur est bien sur le réseau mealie_network à l’aide de la commande :

[sur l’environnement de déploiement distant]

$ podman container ps --filter network=mealie_network

Si les deux conteneurs sont bien dans cette liste, c’est que tout est OK !

2.4. Tests puis nettoyage

On peut désormais tester notre logiciel déployé. Sur votre poste Linux, ouvrez Firefox, et accédez à l’adresse http://podman:<mon port réseau>.

Pour rappel, ici <mon port réseau> correspond au port de publication choisi pour le conteneur Mealie dans l’étape précédente.

Vous devriez faire face à un écran de connexion du logiciel Mealie. Vous pouvez vous connecter avec le compte créé par défaut qui a pour utilisateur changeme@example.com et pour mot de passe MyPassword.

Ensuite, vous pouvez utiliser le bouton Créer puis Importer une recette par son URL afin d’importer une recette de cuisine à partir d’une page web. Saisissez par exemple cette URL https://deliacious.com/2020/03/babka-cannelle-vegan.html puis validez. L’import devrait fonctionner, et si vous accédez au menu Rechercher à fauche, votre recette devrait être listée.

Félicitations, vous avez effectué votre premier déploiement multi-conteneurs !

On peut maintenant faire un peu de nettoyage avant de passer à la suite :

[sur l’environnement de déploiement distant]

$ podman container rm -f mealie
$ podman container rm -f mealie_db
$ podman network rm mealie_network

3. Exercice : déployer un service Kanboard+MariaDB avec un réseau virtuel

3.1. Énoncé

On souhaite à nouveau déployer un service Kanboard, tout comme dans le TP précédent. Cette fois-ci, on souhaite utiliser le fait que Kanboard est capable de stocker des données dans un système de gestion de base de données compatible MySQL. On souhaite donc que notre nouveau déploiement soit composé d’un conteneur Kanboard d’une part, et d’un conteneur compatible MySQL d’autre part.

Concernant la base de données, on choisit d’utiliser l’image de conteneur officielle pour le logiciel MariaDB, un système de gestion de base de données compatible MySQL. En lisant la documentation de l’image, on trouve les informations utiles suivantes :

Le point d’entrée de l’image est l’exécution du logiciel MariaDB,
Le logiciel écoute par défaut sur le port 3306 du conteneur,
Le logiciel stocke ses données dans le répertoire /var/lib/mysql du conteneur,
Par défaut, lors du premier lancement d’un conteneur, un compte MariaDB est créé, ainsi qu’une base de données vide à laquelle ce compte peut accéder. Des variables d’environnement sont disponibles pour configurer cela (de manière assez similaire à l’image de conteneur PostgreSQL vue précédemment) :
- MARIADB_USER permet de spécifier le nom du compte MariaDB,
- MARIADB_PASSWORD permet de spécifier le mot de passe du compte MARIADB_USER,
- MARIADB_DATABASE permet de spécifier le nom de la base de données créée pour le compte MARIADB_USER,
- MARIADB_ROOT_PASSWORD est une variable obligatoire qui permet de spécifier un mot de passe administrateur pour tout le logiciel MariaDB.

Concernant le logiciel Kanboard, même si le contexte est le même que dans le TP précédent, il nous faut également savoir comment configurer un conteneur pour qu’une base de données externe soit utilisée. En parcourant la documentation, on peut lire qu’il est possible de configurer un conteneur Kanboard à l’aide d’une unique variable d’environnement :

DATABASE_URL permet de spécifier une URL de base de données qui prend la forme suivante :
```
mysql://<nom utilisateur>:<mot de passe>@<nom d'hôte>:<port>/<nom base de données>
```
avec :
- <nom utilisateur> le nom d’utilisateur MariaDB à utiliser,
- <mot de passe> le mot de passe pour l’utilisateur MariaDB
- <nom d’hôte> le nom d’hôte à utiliser pour se connecter au serveur MariaDB,
- <port’hôte> le port réseau à utiliser pour se connecter au serveur MariaDB,
- <nom base de données> le nom de la base de données à utiliser.

3.2. Questions

Préparez et exécutez une commande pour déployer un service Kanboard, sous la forme d’un conteneur Kanboard relié à un conteneur MariaDB en suivant avec les contraintes suivantes:
- Le nom du conteneur Kanboard doit être kanboard_instance.
- Le nom du conteneur MariaDB doit être kanboard_db.
- L’image de conteneur Kanboard utilisée doit être celle correspondant à l’étiquette v1.2.32.
- L’image de conteneur MariaDB utilisée doit être celle correspondant à l’étiquette 11.1.
- L’application Kanboard doit être accessible par une publication de port,
- Les données du conteneur Kanboard doivent être stockées dans l’environnement d’accueil.
- Les données du conteneur MariaDB doivent être stockées dans l’environnement d’accueil.
Une fois les conteneurs en exécution, utilisez Firefox depuis votre poste de travail Linux pour accéder à la page d’accueil de Kanboard, en utilisant la publication de port que vous avez réalisée.
Testez l’application de manière similaire à ce qui était demandé dans le TP précédent.
Une fois authentifié dans l’application avec le compte par défaut, cliquez tout en haut à droite sur l’icone utilisateur, puis accédez aux Préférences. Dans les informations affichées, vérifiez que le type de base de données est bien mysql.

Vous allez constater que les données créées par le conteneur MariaDB ne peuvent pas directement être supprimées de l’environnement d’accueil, car votre compte utilisateur ne possède pas les permissions suffisantes. Rendez-vous vers la fin du sujet de TP pour plus d’informations à ce sujet.

4. Exercice : déployer lldap, Kanboard et Mealie à l’aide de réseaux virtuels

Cet exercice a été terminé tardivement et ajouté après le début des premières séances pour ce sujet de TP. À ce titre il n’est donc pas obligatoire, mais il reste très intéressant à faire pour approfondir les notions de ce chapitre.

Pour finir ce TP, on souhaite effectuer un déploiement un peu plus complexe qui fait principalement collaborer trois logiciels différents :

Une instance du logiciel Kanboard (adossé à une instance MariaDB comme base de données)
Une instance du logiciel Mealie (adossé à une instance PostgreSQL comme base de données)
Et enfin une instance du logiciel _lldap, un logiciel qui fournit un service d’authentification de type LDAP.

Dans cet exercice, l’idée est de configurer Kanboard et de configurer Mealie de manière à ce que chacun des deux logiciels délègue sur l’instance lldap pour l’authentification d’un utilisateur. Ainsi, un compte utilisateur créé au sein de l’instance lldap pourra à la fois être utilisé pour se connecter à Mealie, et pour se connecter à Kanboard.

On souhaite déployer chaque logiciel sous la forme d’un conteneur, soit un total de 5 conteneurs à déployer !

4.1. Présentation de LDAP et lldap

Lightweight Directory Access Protocol (LDAP) est une norme qui permet à un logiciel serveur d’agir comme un annuaire d’utilisateurs (le serveur LDAP), et qui permet à d’autres logiciels (les clients LDAP) de déléguer la gestion et l’authentification de leurs utilisateurs à un serveur LDAP existant. C’est une manière répandue de centraliser un ensemble unique de comptes utilisateurs, qui permettront de se connecter de manière unifier à tout un ensemble de services informatiques.

lldap (qui signifie Light LDAP implementation for authentication) est un logiciel libre qui permet de déployer un serveur LDAP simplifié et suffisant pour gérer un annuaire léger d’utilisateurs, et pour gérer l’authentification d’utilisateurs sur différents services.

En lisant la documentation lldap, on découvre les informations utiles suivantes :

une image de conteneur lldap est disponible sur le registre de conteneur Docker Hub (donc docker.io) sous le nom lldap/lldap.
Une étiquette valide pour cette image est 2025-10-14
Le point d’entrée de cette image est le démarrage d’un processus lldap
Au sein du conteneur, le processus lldap stocke ses données au sein du répertoire /data.
Par défaut, un processus lldap écoute simultanément sur deux ports réseaux :
- le port 17170, via lequel on peut se connecter à lldap à l’aide d’un navigateur web, pour pouvoir utiliser l’interface d’administration de lldap ; cette interface permet de créer un compte, lister les comptes disponibles, etc.
- le port 3890, via lequel un autre logiciel peut se connecter à lldap à l’aide du protocole LDAP, et qui permet à cet autre logiciel de déléguer à lldap l’authentification utilisateur.
lldap doit être configuré à l’aide des variables d’environnement suivantes :
- LLDAP_JWT_SECRET : doit contenir une chaîne de caractères générée aléatoirement, utilisée à des fins cryptographiques par lldap
- LLDAP_KEY_SEED : tout comme LLDAP_JWT_SECRET, doit contenir une chaîne de caractères générée aléatoirement, utilisée à des fins cryptographiques par lldap
- LLDAP_LDAP_USER_PASS : mot de passe du compte administrateur (dont l’identifiant est admin)
- LLDAP_LDAP_BASE_DN : définit le distinguished name de base de l’annuiaire LDAP, et s’écrit sous la forme dc=example,dc=com ou bien juste dc=example

4.2. Étape 1 : préparer le plan de déploiement

Avant de vous lancer, répondez soigneusement aux questions suivantes :

Quels sont les conteneurs qu’il va falloir créer ?
Quels sont les réseaux virtuels qu’il va falloir créer ?

Pour simplifier légèrement, on peut considérer que tous conteneurs ayant besoin de contacter lldap peuvent être mis sur un même réseau virtuel.

Quels sont les publications de port qui vont être nécessaires ?

Il ne faut pas exposer tous les ports réseau sur le réseau local ! Réfléchissez bien à ceux qu’il est nécessaire de publier, et si vous avez un doute là dessus, demandez à votre intervenant de TP.

Quels sont les montages de fichiers/répertoires qui vont être nécessaires ?

4.3. Étape 2 : créer tous les réseaux virtuels nécessaires

Pour chaque réseau virtuel anticipé à l’étape précédente, le créer avec podman.

4.4. Étape 3 : déployer lldap

Déployez une instance lldap qui suit votre plan de déploiement, et avec également les contraintes suivantes :

le conteneur doit s’appeler lldap_instance
les données de lldap doivent être persistées dans l’environnement de déploiement
vous utiliserez les valeurs suivantes pour les différentes variables d’environnement :
- LLDAP_JWT_SECRET : la valeur de votre choix,
- LLDAP_KEY_SEED : la valeur de votre choix,
- LLDAP_LDAP_BASE_DN : la valeur 'dc=monannuaire'
- LLDAP_LDAP_USER_PASS : la valeur motdepasse

Connectez vous ensuite à l’interface web d’administration de lldap, connectez vous avec le compte admin, puis utilisez le bouton Create a user pour créer un compte utilisateur de votre choix

Ne perdez pas le mot de passe que vous aurez choisi, il sera nécessaire aux étapes suivantes !

4.5. Partie 4 : déployer Kanboard

En suivant votre plan de déploiement, déployez une base de données PostgresQL, ainsi qu’une instance Kanboard.

Pour le déploiement de Kanboard, ajoutez les variables d’environnement suivantes pour configurer l’authentification au travers du serveur lldap :

LDAP_AUTH : mettre la valeur true
LDAP_BIND_TYPE : mettre la valeur user
LDAP_SERVER : mettre une valeur de la forme ldap://<nom d’hôte>:<numéro port>, où <nom d’hôte> est le nom d’hôte permettant d’atteindre le serveur LDAP, et <numero port> le numéro de port auquel se connecter sur ce serveur pour contacter le serveur LDAP
LDAP_USERNAME : mettre la valeur uid=%s,ou=people,dc=monannuaire
LDAP_USER_BASE_DN : mettre la valeur ou=people,dc=monannuaire
LDAP_USER_FILTER : mettre la valeur uid=%s

Ici nous vous fournissons la solution pour la plupart des valeurs, car configurer une connexion LDAP est une entreprise assez tortueuse.

Une fois votre instance Kanboard démarrée, testez de vous connecter à l’aide du compte utilisateur que vous avez créé dans la partie 3. Si cela fonctionne, c’est bon !

4.6. Partie 5 : déployer Mealie

En suivant votre plan de déploiement, déployez une base de données MariaDB, ainsi qu’une instance Mealie.

Pour le déploiement de Mealie, ajoutez les variables d’environnement suivantes pour configurer l’authentification au travers du serveur lldap :

LDAP_AUTH_ENABLED : mettre la valeur true
LDAP_SERVER_URL : mettre une valeur de la forme ldap://<nom d’hôte>:<numéro port>, où <nom d’hôte> est le nom d’hôte permettant d’atteindre le serveur LDAP, et <numero port> le numéro de port auquel se connecter sur ce serveur pour contacter le serveur LDAP
LDAP_BASE_DN : mettre la valeur ou=people,dc=monannuaire
LDAP_QUERY_BIND : mettre la valeur cn=admin,ou=people,dc=monannuaire
LDAP_QUERY_PASSWORD : mettre la valeur motdepasse (à savoir le mot de passe du compte admin créé au lancement de lldap)
LDAP_ID_ATTRIBUTE : mettre la valeur uid
LDAP_NAME_ATTRIBUTE : mettre la valeur uid
LDAP_MAIL_ATTRIBUTE : mettre la valeur mail

À nouveau ici nous vous fournissons la solution pour la plupart des valeurs, car configurer une connexion LDAP est une entreprise assez pénible.

Une fois votre conteneur démarré, accédez à Mealie à l’aide d’un navigateur, et tentez de vous connecter à l’aide du compte utilisateur préparé en partie 3. Si vous arrivez à vous connecter, c’est tout bon !

5. Prise de recul sur le travail réalisé dans les séances de TP jusqu’ici

Prenons un peu de recul.

La première chose à remarquer est que, malgré les déboires que vous avez pu rencontrer, les différents déploiements que vous avez réalisé en TP n’ont normalement pas représenté une quantité de travail très importante. Certes il peut être laborieux de préparer les bonnes commandes et de créer les bons conteneurs dans le bon ordre avec les bonnes configurations − et c’est pour cela que nous avons tout un cours ! − mais le nombre d’actions à effectuer pour faire le déploiement à proprement parler est généralement très bas (seulement quelques commandes par situation).

En outre, vous avez pu déployer ces logiciels sans avoir la moindre connaissance technique de leur fonctionnement interne, ou des technologies qu’ils utilisent, ou des dépendances qu’ils nécessitent. Sans le savoir, vous avez déployé un logiciel développé en C (nginx), un autre développé en Python + JavaScript (mealie), et un autre développé en PHP (Kanboard), le tout alors que chacune de ces technologies gère totalement différemment ses dépendances logicielles. Vous n’avez jamais eu besoin d’installer un moteur d’exécution PHP, ou un interpréteur Python, ou des bibliothèques natives pour C. Sacrée prouesse !

Tout cela illustre la grande efficacité de la conteneurisation pour le déploiement des logiciels. C’est simple : faire tous ces déploiements n’aurait simplement pas été possible dans un TP de M1 Informatique sans utiliser cette méthode, car cela aurait nécessité de votre part une bien plus grande maîtrise du travail d’administrateur⋅ice système.

Bien entendu, ce qui a mis ces déploiements à votre portée est le travail important réalisé en amont pour préparer toutes les images de conteneurs que vous avez utilisées. La suite des travaux pratique consistera donc à découvrir comment préparer de telles images pour les logiciels que vous souhaitez déployer.

6. Exercices additionnels

Pour ceux qui auraient terminé ce TP avant le temps alloué en séance, voici quelques exercices supplémentaires moins guidés et plus "libres" que ceux demandés précédemment.

6.1. Déploiement d’un serveur ForgeJo

ForgeJo est une forge logicielle permettant de gérer des développements logiciels. On peut y créer des projets avec référentiel Git et avec des outils d’organisation classiques (tickets, navigation dans le code, revues de code, etc.). C’est donc une alternative au logiciel Gitlab, plus légère mais avec également moins de fonctionnalités.

On notera que ForgeJo a besoin d’écouter sur deux ports réseau différents :

le port 3000, qui permet de se connecter à ForgeJo à l’aide d’un navigateur web
le port 22, qui permet de se connecter à ForgeJo à l’aide d’une connexion SSH, afin de pouvoir utiliser Git à l’aide du protocole SSH

Pour ce dernier exercice, vous effectuerez un déploiement d’une instance ForgeJo, avec les contraintes suivantes :

on utilisera une base de données MariaDB (compatible MySQL)
on configurera ForgeJo pour qu’il utilise correctement le port de publication SSH que vous aurez choisi, à l’aide de l’option SSH_PORT
on utilisera une image avec une étiquette possédant le suffixe -rootless, pour s’assurer d’avoir une image compatible Podman
plutôt que de configurer le logiciel à l’aide de variables d’environnement, on utilisera un fichier de configuration app.ini, en se basant sur ce fichier exemple fourni par les développeurs de ForgeJo.

Cette page de la documentation vous explique comment ForgeJo peut être configuré, et résume toutes les options permettant de configurer le logiciel.

Cette autre page de la documentation vous donne des informations sur les images de conteneur ForgeJo disponibles, en particulier un exemple de référence d’image. Elle comporte également des exemples de fichiers écrits avec le langage Compose, non étudié dans ce cours pour le moment.

Pour valider votre déploiement, vous pouvez :

créer un compte sur votre instance ForgeJo,
ajouter votre clé publique SSH à votre compte,
créer un projet à l’aide de ce compte,
effectuer un clone Git par SSH de ce nouveau projet,
ajoutez un fichier, puis effectuez une validation (commit) et envoi (push)

6.2. Déploiement de Simplestblog

Faites un déploiement par vous même d’une instance de Simplestblog

Vous pouvez bien entendu vous baser sur les commandes déjà vues pendant le cours.

Sur la page du projet, vous pouvez accéder à l’ensemble des images de conteneurs disponibles en vous rendant dans Déploiement → Registre de conteneur.

💻 TP : Faire un déploiement multi-conteneurs

1. Tutoriel : premiers réseaux virtuels

1.1. Deux conteneurs sur un même réseau virtuel

1.1.1. Mise en place

1.1.2. Test 1 : serveur dans conteneurA, client dans conteneurB

1.1.3. Test 2 : client dans conteneurB, client dans conteneurA

1.2. Trois conteneurs sur deux réseaux virtuels

1.2.1. Mise en place

1.2.2. Test 1 : communications depuis le conteneurB

1.2.3. Test 2 : communication entre conteneurA et conteneurC ?

2. Tutoriel : déployer un service Mealie à l’aide d’un réseau virtuel

2.1. Réseau virtuel

2.2. Conteneur PostgreSQL

2.3. Conteneur Mealie

2.4. Tests puis nettoyage

3. Exercice : déployer un service Kanboard+MariaDB avec un réseau virtuel

3.1. Énoncé

3.2. Questions

4. Exercice : déployer lldap, Kanboard et Mealie à l’aide de réseaux virtuels

4.1. Présentation de LDAP et lldap

4.2. Étape 1 : préparer le plan de déploiement

4.3. Étape 2 : créer tous les réseaux virtuels nécessaires

4.4. Étape 3 : déployer lldap

4.5. Partie 4 : déployer Kanboard

4.6. Partie 5 : déployer Mealie

5. Prise de recul sur le travail réalisé dans les séances de TP jusqu’ici

6. Exercices additionnels

6.1. Déploiement d’un serveur ForgeJo

6.2. Déploiement de Simplestblog

1.1.2. Test 1 : serveur dans `conteneurA`, client dans `conteneurB`

1.1.3. Test 2 : client dans `conteneurB`, client dans `conteneurA`

1.2.2. Test 1 : communications depuis le `conteneurB`

1.2.3. Test 2 : communication entre `conteneurA` et `conteneurC` ?