📘 Conteneuriser (manuellement) un logiciel en image de conteneur

1. Motivation

Nous avons vu tout au long du cours qu’il était possible d’utiliser une image de conteneur déjà disponible "sur étagère" afin de facilement créer un nouveau conteneur. Une première catégorie d’images de conteneur sont celles qui fournissent chacune un environnement minimal sur la base d’un système d’exploitation (Ubuntu, Alpine, etc.) ou dédiée à une technologie (Python, Julia, Java, etc.). Une seconde catégorie d’images sont celles qui permettent chacune de déployer facilement un logiciel spécifique (et l’environnement minimal associé), qui aura été pré-installé et pré-configuré au sein de la dite image.

Dans ce cours, il nous reste à comprendre comment faire pour créer une nouvelle image de conteneur, et particulièrement une image de conteneur de la seconde catégorie (à savoir une image qui fournit un logiciel spécifique). En effet, préparer une image de conteneur immutable et complète est une manière très robuste et efficace de permettre le déploiement d’un logiciel fraichement développé.

On utilise parfois l’expression "conteneuriser un logiciel" pour parler de la création d’une image de conteneur pour un logiciel.

2. Principe

Pour rappel, une image de conteneur est quasiment de même nature qu’un conteneur : elle définit un mini-environnement et tout ce dont il est composé (fichiers, répertoires, etc.). La principale différence est qu’une image de conteneur est immutable − c’est à dire qu’elle est figée dans un état non modifiable − tandis qu’un conteneur est mutable − c’est à dire que son état peut être modifié. Une conséquence de cette définition est qu’il n’est pas possible d’exécuter un processus au sein d’une image de conteneur, puisqu’un processus nécessite un environnement mutable − c’est pour cette raison qu’il faut toujours créer un nouveau conteneur à partir d’une image pour démarrer un processus.

Ainsi, puisqu’une image de conteneur n’est rien d’autre qu’un conteneur immutable, la création d’une nouvelle image de conteneur peut s’accomplir en créant un nouveau conteneur temporaire à partir d’une image de conteneur existante dite "de base", puis en modifiant ce conteneur temporaire, et enfin en rendant ce conteneur temporaire immutable.

La création d’une nouvelle image de conteneur à partir d’une image de base peut se résumer ainsi :

Figure 1. Étapes principales lors de la création d’une nouvelle l’image de conteneur

(si nécessaire) L’image de base pressentie est téléchargée auprès d’un registre distant, et est stockée dans le stockage local d’images de l’environnement utilisé pour construire notre image.
Un conteneur temporaire est instancié à partir de l’image de base.
Ce conteneur temporaire est modifié afin d’y ajouter notamment :
- le logiciel que l’on souhaitera déployer,
- toutes les dépendances du logiciel à déployer (bibliothèques, exécuteurs, utilitaires, etc.).
- si pertinent, les fichiers/répertoires nécessaires à l’exécution de base du logiciel − par exemple des fichiers de configuration,
Le conteneur temporaire (désormais modifié) est enregistré en nouvelle image de conteneur au sein du stockage local d’images. Lors de cet enregistrement, on vient greffer à cette image un ensemble de métadonnées nécessaires au fonctionnement de l’image, en particulier :
- Le point d’entrée, qui prend la forme d’une commande qui sera exécutée lors du démarrage d’un conteneur créé à partir de l’image,
- Si besoin, le répertoire de départ à partir duquel sera exécuté la commande du point d’entrée de l’image,
- Si besoin, des valeurs constantes affectées à certaines variables d’environnement utilisées par le logiciel.
Enfin, si souhaité, l’image de conteneur créée est téléversée vers un registre de conteneurs distant, afin de rendre l’image disponible aux utilisateur⋅ices souhaités.

Mais comment créer une image sans partir d’un conteneur ?

Jusqu’ici nous avons vu que :

un conteneur est toujours créé à partir d’une image de conteneur,
une image de conteneur peut être créée à partir d’un conteneur (lui-même créé à partir d’une image de base).

Nous sommes ici face à un problème de type "l’œuf ou la poule" : comment a pu être créé le premier conteneur ou la première image de conteneur, si chacun⋅e dépend de l’autre pour exister ?

Il est en fait possible de créer une image de conteneur à partir de zéro (en anglais, "from scratch"), sans partir d’un conteneur existant, et donc sans partir d’une image de base existante. On procède alors en construisant "à la main" une arborescence de fichiers contenant exactement le contenu souhaité dans l’image. C’est comme cela qu’est construite une image de conteneur qui fournit juste un système d’exploitation minimal.

On ne s’intéressera pas dans ce cours à ce mode de fonctionnement, car c’est un cas plus rare et plus difficile. Il par ailleurs aujourd’hui plus habituel de toujours reposer sur une image de base pour construire une nouvelle image.

3. Bien concevoir une image de conteneur

3.1. Problématique

Une fois une image de conteneur préparée pour un logiciel donné, elle sera mise entre les mains des administrateur⋅ices système qui seront chargé⋅es de déployer le dit logiciel. Lors de cette "phase d’usage" de l’image, ces personnes devront correctement la configurer et l’exécuter… sans se tromper !

Figure 2. Distinction entre phase de création et phase d’usage d’image de conteneur

Lors des TPs vous avez souvent été dans cette situation, à savoir devoir utiliser une image de conteneur "sur étagère" en devant lire soigneusement sa documentation.

Pour que cette phase d’usage se déroule sans accroc, il est préférable avant de créer une image de bien concevoir et documenter l’image de conteneur en prévision de son usage final. En effet, lorsqu’un conteneur sera créé à partir de l’image, il faudra s’assurer que le processus logiciel exécuté reçoive toutes les données, valeurs de configuration, et accès au réseau dont il pourrait avoir besoin. L’image de conteneur doit anticiper cela au travers de son état initial et de sa documentation.

Dans toutes les étapes qui suivent, un point récurrent sera de bien distinguer ce qui doit pré-exister (autrement dit des "constantes") dans l’image de conteneur − valeurs de configuration par défaut, fichiers, etc. − et ce qui sera apporté (autrement dit des "variables") uniquement lors de la création d’un conteneur à partir de l’image − valeurs de configurations, fichiers, montages, accès réseau, etc.

Si on fait un parallèle avec la programmation, on peut voir une image de conteneur comme une sorte de fonction prête à l’emploi, que l’on peut ensuite appeler lorsque c’est nécessaire. Or une fonction doit être clairement conçue en terme de données entrées (paramètres) et données de sorties (valeurs de retour), et doit être bien documentée pour expliquer comment chaque entrée peut affecter les sorties possibles.

3.2. Étape 1 : définir le mode de configuration de l’image

Tout au long du cours, nous avons vu qu’une préoccupation est de bien configurer un logiciel que l’on déploie. Ainsi, si on souhaite rendre un logiciel déployable via une image de conteneur, il est utile de se poser les questions suivantes :

avant tout, est-ce que le logiciel que l’on souhaite conteneuriser est configurable ?
- via des arguments en ligne de commande ?
- via un fichier de configuration ?
- via des variables d’environnement ?
souhaite-t-on pré-configurer le logiciel au sein de l’image, avec certaines constantes ?
souhaite-t-on que l’utilisateur de l’image puisse configurer le logiciel (partiellement ou entièrement) ?
de quelle manière est-il pertinent de permettre la configuration du logiciel lors de l’utilisation de l’image ?

Concernant le dernier point, comme il n’est pas pratique de passer des arguments en ligne de commande à un logiciel conteneurisé, on privilégie surtout les deux autres méthodes :

soit en passant un fichier de configuration par montage de fichier,
soit en passant des variables d’environnement au conteneur directement,
soit via un mélange de ces deux méthodes.

3.2.1. Méthode A : passer un fichier de configuration par montage de fichier

Si le logiciel conteneurisé a été à l’origine conçu pour se configurer en lisant un fichier de configuration, alors il est possible de directement reposer sur ce mode de configuration. Il sera alors nécessaire pour l’utilisateur⋅irce future de l’image de devoir écrire un fichier de configuration, et de le fournir au logiciel conteneurisé à l’aide d’un montage de fichier.

Il sera pertinent de documenter l’image de conteneur pour expliquer qu’un fichier de configuration est attendu à un emplacement précis (c’est à dire, l’emplacement où il sera cherché par le processus en exécution) dans le futur conteneur.

3.2.2. Méthode B : définir et/ou utiliser des variables d’environnement

Une stratégie très populaire pour configurer un logiciel conteneurisé est de reposer sur des variables d’environnement. Le grand avantage de cette approche est qu’elle est repose sur un mécanisme assez universel, et que les moteurs de conteneurisation permettent très facilement de définir des variables d’environnement lors de l’exécution d’un conteneur.

Lorsqu’on prépare une image de conteneur, deux cas de figure sont possibles :

Dans le cas le plus simple, le logiciel conteneurisé a été dès le départ construit pour se configurer au travers de variables d’environnement. Il faut alors bien analyser les variables d’environnement comprises par le logiciel et en déduire :
- celles pour lesquelles il faut fixer des valeurs constantes,
- celles qu’il faudra laisser à configurer pour l’utilisateur final de l’image de conteneur.
Dans un cas plus complexe, il est possible que le logiciel que l’on conteneurise n’ait pas été au départ conçu pour se configurer via des variables d’environnement. Si on souhaite tout de même pouvoir permettre une configuration via des variables d’environnement, on peut définir de nouvelles variables d’environnement juste pour l’image de conteneur. Cependant, comme elles ne seront pas lues par le logiciel, il est nécessaire que l’image de conteneur possède un point d’entrée qui fera usage de ces nouvelles variables d’environnement − par exemple en les transformant en arguments en ligne de commande.

Dans tous les cas, il sera pertinent de documenter l’image de conteneur pour expliquer les choix réalisés.

3.3. Étape 2 : définir le point d’entrée

Comme déjà vu dans le cours, le point d’entrée d’une image de conteneur définit quel processus logiciel est exécuté lors du démarrage d’un conteneur qui instancie cette image. C’est tout simplement une commande exécutée dans le conteneur lors du démarrage de ce dernier.

En principe, le point d’entrée est donc simplement la commande qui permet de démarrer le logiciel conteneurisé. Cependant, si le logiciel à exécuter nécessite des arguments en ligne de commande, il est nécessaire de les lui fournir dans le point d’entrée :

soit sous la forme de constantes,
soit sous la forme de variables d’environnement dont les valeurs seront fixées lors de la future création du conteneur.

Et à nouveau, il sera pertinent de documenter l’image de conteneur pour expliquer les choix réalisés.

Définir un point d’entrée à l’aide d’un script dédié

Si le point d’entrée souhaité devient trop complexe − par exemple si on fait l’usage d’un grand nombre de nouvelles variables d’environnement − il peut être nécessaire d’écrire un script qui sera ajouté à l’image de conteneur et qui sera utilisé comme point d’entrée. Pour les curieux, voir par exemple le le script utilisé comme point d’entrée dans l’image de conteneur MariaDB.

3.4. Étape 3 : anticiper les points de montage nécessaires

Si le logiciel conteneurisé devra lire ou écrire des fichiers durant son exécution, alors il est utile de se poser les questions suivantes :

Est-ce que le logiciel utilisera des fichiers constants, qui seront toujours les mêmes, d’une exécution à une autre ?
- Si oui, ces fichiers peuvent être ajoutés à lors de la création de l’image.
Est-ce que le logiciel devra lire des fichiers fournis par l’utilisateur⋅ice du logiciel ?
- Si oui, ces fichiers devront être fournis à l’aide de montages de répertoires/fichiers.
Est-ce que le logiciel devra produire des fichiers qui devront être récupérés par l’utilisateur⋅ice du logiciel ?
- Si oui, un point de montage devra être créé par l’utilisateur⋅ice pour pouvoir récupérer les dits fichiers.
Est-ce que le logiciel stocke son état sous la forme de fichiers, et est-ce qu’on souhaite faire persister cet état d’une exécution du logiciel à une autre ?
- Si oui, un point de montage devra être créé par l’utilisateur⋅ice pour garantir la persistence des dits fichiers en cas de supression du conteneur.

Encore une fois, il sera pertinent de documenter l’image de conteneur pour expliquer les choix réalisés.

3.5. Étape 4 : anticiper les accès réseau nécessaires

Si le logiciel conteneurisé aura besoin de communiquer avec d’autres processus logiciels, il est important de documenter à la fois :

les ports réseaux sur lesquels le logiciel conteneurisé est susceptible d’écouter,
les logiciels extérieurs auxquels le logiciel conteneurisé souhaitera se connecter (par exemple un accès à une base de données), et comment configurer accès réseaux à ces logiciels (par exemple l’adresse réseau et le port auxquels se connecter).

À nouveau, il sera pertinent de documenter l’image de conteneur pour expliquer les choix réalisés.

3.6. Exemples

Exemple 1. Conception de l’image de conteneur Automatic-Image-Converter

On souhaite préparer une image de conteneur pour Automatic-Image-Converter, notre logiciel capable de convertir en continu des photos d’un type de fichier à un autre.

Étape 1 : définir le mode de configuration de l’image

Automatic-Image-Converter est un logiciel qui s’attend à trouver quatre arguments en ligne de commande pour s’exécuter, dans un ordre strict : le répertoire d’entrée, puis le répertoire de sortie, puis le format vers lequel convertir, et enfin la durée entre chaque passe de conversion.

On fait le choix que les deux répertoires (entrée et sortie) seront des constantes au sein du conteneur, à savoir /inputs et /outputs, et on décide que la configuration du format et de la durée pourra se faire lors de la phase d’usage à l’aide de deux variables d’environnement FORMAT DURATION.

Étape 2 : définir le point d’entrée

En supposant que le logiciel soit copié dans l’image de conteneur à l’emplacement /app.jar, la commande pour exécuter Automatic-Image-Converter prend la forme :

java -jar /app.jar <répertoire entrée> <répertoire sortie> <format cible> <durée>

Sur la base des choix faits en étape 1, on fixe les deux constantes choisies pour les deux premiers arguments, et les deux variables choisies pour les deux derniers arguments, ce qui donne le point d’entrée suivant :

java -jar /app.jar /inputs /outputs $FORMAT $DURATION

Étape 3 : anticiper les points de montage nécessaires

Le logiciel aura besoin de lire des fichiers fournis par l’utilisateur, et de produire des fichiers en conséquence, dans deux répertoires distincts (à savoir les constantes /inputs et /outputs fixées dans les étapes précédentes). On documente donc pour notre image que :

un montage de répertoire est nécessaire à l’emplacement /inputs pour pouvoir fournir des images à notre logiciel,
un montage de répertoire est nécessaire à l’emplacement /outputs pour pouvoir récupérer les images produites par notre logiciel.

Étape 4 : anticiper les accès réseau nécessaires

Automatic-Image-Converter n’a pas besoin de communiquer avec d’autres processus via le réseau.

Exemple 2. Conception de l’image de conteneur Simplestblog

On souhaite préparer une image de conteneur pour Simplestblog, notre logiciel de blog accessible par le web.

Étape 1 : définir le mode de configuration de l’image

Simplestblog est un logiciel qui requiert un fichier de configuration pour fonctionner. Petite subtilité, le logiciel ira chercher ce fichier de configuration à l’emplacement spécifié par la variable d’environnement SIMPLESTBLOG_SETTINGS_FILE.

On fait le choix que le fichier de configuration devra être fourni lors de la phase d’usage, et on fait le choix qu’il sera toujours fourni à un emplacement constant au sein du conteneur, à savoir l’emplacement /config.py. Par conséquent, on fixe une valeur constante /config.py dans la variable SIMPLESTBLOG_SETTINGS_FILE (ce qui signifie que l’on considère que l’utilisateur n’aura pas à utiliser définir variable).

Étape 2 : définir le point d’entrée

En supposant que l’image de conteneur ait pour répertoire initial le répertoire avec le code source de Simplestblog, la commande pour exécuter le logiciel prend la forme :

waitress-serve --call simplestblog:create_app

Il n’y a pas d’arguments particuliers à fournir, donc on peut garder la commande telle quelle.

Étape 3 : anticiper les points de montage nécessaires

Simplestblog n’a pas d’état à stocker sous forme de fichier (car il stocke son état dans une base de données), et ne produit aucun fichier. En revanche, comme évoqué plus haut, Simplestblog requiert un fichier de configuration à l’emplacement constant /config.py fixé précédemment.

On documente donc pour notre image qu’un montage de fichier à l’emplacement /config.py est attendu lors de la phase d’usage.

Étape 4 : anticiper les accès réseau nécessaires

Simplestblog souhaite communiquer avec des processus extérieurs de deux manières :

d’une part, Simplestblog écoute sur le port réseau 5000 et s’attend à être sollicité par des navigateurs webs (ex. Firefox) sur ce port.
d’autre part, Simplestblog cherche à contacter une base de données compatible MySQL située sur un réseau accessible ; plus précisément, Simplestblog se basera sur la valeur MYSQL_DATABASE_HOST du fichier de configuration attendu pour savoir à quelle adresse réseau se connecter pour trouver une base de données, et sur la valeur MYSQL_DATABASE_PORT pour savoir sur quel port réseau se connecter.

On écrit bien ces informations dans la documentation de l’image.

4. Utiliser Podman pour créer et gérer des images de conteneur

4.1. Création d’une image à partir d’un conteneur

Supposons qu’un conteneur temporaire ait été créé à partir d’une image dite "de base", puis que ce conteneur ait été modifié pour contenir un logiciel à déployer ainsi que ses dépendances. La commande à utiliser pour créer une image de conteneur à partir de ce conteneur temporaire est la suivante :

$ podman container commit  <nom du conteneur> \
                           <options> \
                           <nom donné>:<étiquette donnée>

avec :

<nom du conteneur> : le nom du conteneur à partir duquel on crée une nouvelle image,
<nom donné> : le nom que l’on souhaite donner à cette nouvelle image,
<étiquette donnée> l’étiquette que l’on souhaite donner à cette nouvelle image.

S’il y avait déjà une image stockée localement avec le même nom et la même étiquette, elle est alors remplacée par la nouvelle image.

Dans <options> nous allons en utiliser une seule appelée --change, qui permet de définir des métadonnées pour notre nouvelle image. Plus précisément, nous allons utiliser trois variantes de cette option :

--change 'WORKDIR <répertoire>' : spécifie le répertoire de départ à partir duquel le point d’entrée est exécuté,
--change 'CMD <point d’entrée>' : spécifie le point d’entrée, c’est à dire la commande qui sera exécutée lorsqu’un conteneur sera créé à partir de cette nouvelle image,
--change 'ENV <clé>=<valeur>' : affecte <valeur> à une variable d’environnement <clé> lors de l’exécution du point d’entrée.

Exemple 3. Création d’une image figlet à partir d’un conteneur

On souhaite préparer une image jouet qui conteneurise l’utilitaire Unix figlet qui permet d’écrire en art ASCII un message sur la ligne de commande.

On conçoit notre image de la manière suivante :

l’image de base sera l’image officielle Ubuntu Linux en version 25.10, disponible sur le Docker Hub,
on installera la commande figlet avec le gestionnaire de paquet apt,
on souhaite que l’utilisateur futur de l’image puisse spécifier un message à afficher à l’aide d’une variable d’environnement MESSAGE.

On commence par préparer un conteneur temporaire :

$ podman container run -ti --name figlet_template docker.io/ubuntu:25.10

Dans ce conteneur temporaire, on installe figlet :

[sur le conteneur]

$ apt update
$ apt install figlet

C’était l’unique élément à ajouter pour notre image, on peut donc quitter l’interpréteur de commande de notre conteneur temporaire :

[sur le conteneur]

# exit

Puis on peut utiliser commit pour créer une nouvelle image à partir de notre conteneur temporaire. Lors de cette création d’image, on fixe un point d’entrée via la métadonnée CMD qui exécute la commande figlet en lui demandant de lire la variable d’environnement MESSAGE :

$ podman container commit  figlet_template \
                           --change 'CMD figlet $MESSAGE' \
                           figlet:v1

Suite à cette commande, nous avons créé une nouvelle image de conteneur stockée localement (dénoté localhost). On peut alors utiliser notre image de la manière suivante, en n’oubliant pas de fixer une valeur à la variable d’environnement MESSAGE :

podman container run --rm --env MESSAGE="hello world" localhost/figlet:v1
 _          _ _                            _     _
| |__   ___| | | ___   __      _____  _ __| | __| |
| '_ \ / _ \ | |/ _ \  \ \ /\ / / _ \| '__| |/ _` |
| | | |  __/ | | (_) |  \ V  V / (_) | |  | | (_| |
|_| |_|\___|_|_|\___/    \_/\_/ \___/|_|  |_|\__,_|

Exemple 4. Création d’une image Automatic-Image-Converter à partir d’un conteneur

Automatic-Image-Converter est un logiciel développé en Java, il nous faut donc à minima un environnement fournissant la commande java. Si on fait l’hypothèse que le logiciel n’a pas été pré-compilé, alors nous avons égalementbesoin d’un environnement avec les commandes nécessaires pour cette compilation.

Le code de Automatic-Image-Converter repose sur l’outil Maven pour la compilation, il nous faut donc une image nous fournissant la commande maven. On se rend sur la page de l’image officielle Maven, et on regarde les versions. On souhaite Java en version 17, et on souhaite utiliser Eclipse Temurin comme distribution Java à la fois pour la compilation et l’exécution. On choisit donc l’étiquette 3-eclipse-temurin-17 comme image de base pour notre conteneur temporaire :

$ podman container run -ti --name aic_template \
                       docker.io/maven:3-eclipse-temurin-17 \
                       bash

On choisit de démarrer explicitement notre conteneur temporaire avec le point d’entrée bash, et non avec la commande mvn qui est le point d’entrée par défaut de l’image maven.

En parallèle, dans un second terminal, on récupère le projet de développement de Automatic-Image-Converter dans un répertoire aic, puis on copie tout le code source au sein du conteneur à l’emplacement prévu :

$ podman container cp ./aic simplestblog_template:/install

De retour dans le conteneur, on peut vérifier que tout est bien arrivé à l’emplacement prévu :

[sur le conteneur]

# cd /install
# ls
acceptance_testing  Containerfile.nobuild      Containerfile.twostages  README.adoc
ansible             Containerfile.singlestage  pom.xml                  src

Puis on peut utiliser mvn pour à la fois installer les bibliothèques requises par Automatic-Image-Converter , et compiler Automatic-Image-Converter au passage :

[sur le conteneur]

# mvn package

Cette commande produit dans le conteneur le fichier /install/target/automatic-image-converter-1.0-SNAPSHOT.jar qui contient tout notre logiciel compilé avec ses dépendances.

À partir d’ici, notre conteneur contient exactement ce que l’on souhaite comme fichiers au sein de notre future image, à savoir :

un environnement Java,
le logiciel que l’on souhaitera déployer (à savoir Automatic-Image-Converter),
les dépendances du dit logiciel (à savoir les bibliothèques Java requises par Automatic-Image-Converter)

On peut donc quitter l’interpréteur de commande de notre conteneur temporaire :

[sur le conteneur]

# exit

Précédemment, nous avons anticipé la conception de notre image Automatic-Image-Converter avec un point d’entrée qui anticipe la définition de certaines variables d’environnement en phase d’usage. On en déduit donc les métadonnées suivantes :

WORKDIR /install
CMD java -jar target/automatic-image-converter-1.0-SNAPSHOT.jar /inputs /outputs $FORMAT $DURATION

Ainsi, à partir du conteneur temporaire simplestblog_template, on peut créer une image appelée simplestblog et étiquettée v1 à l’aide de la commande suivante :

$ podman container commit  aic_template \
                           --change 'WORKDIR /install' \
                           --change 'CMD java -jar target/automatic-image-converter-1.0-SNAPSHOT.jar /inputs /outputs $FORMAT $DURATION' \
                           aic:v1

En supposant avoir préparé localements les répertoires /data/input_images et /data/input_images, on peut ensuite par exemple utiliser notre image de conteneur de la manière suivante :

podman container run   --name aic \
                       --detach \
                       --rm \
                       --mount type=bind,source="/data/input_images",target="/inputs" \
                       --mount type=bind,source="/data/output_images",target="/outputs" \
                       --env FORMAT="png" \
                       --env DURATION="5000" \
                       localhost/aic:v1

Exemple 5. Création d’une image Simplestblog à partir d’un conteneur

Simplestblog étant une application web développée en Python, il nous faut donc à minima un environnement fournissant la commande python. On choisit d’utiliser l’image officielle Python comme image de base. L’image en question est disponible sur le Docker Hub et on se rend sur sa page de description. On souhaite une version de l’image qui contienne Python version 3, et qui soit aussi légère (slim) que possible. On se décide à utiliser l’étiquette 3-slim.

$ podman container run -ti --name simplestblog_template \
                       docker.io/python:3-slim \
                       bash

On choisit de démarrer explicitement notre conteneur Python avec le point d’entrée bash, et non avec l’interpréteur Python qui est le point d’entrée par défaut de l’image docker.io/python.

En parallèle, dans un second terminal, on récupère le projet de développement de Simplestblog dans un répertoire simplestblog, puis on copie tout le code source situé dans le sous-répertoire src au sein du conteneur à l’emplacement prévu :

$ podman container cp simplestblog/src simplestblog_template:/install

De retour dans le conteneur, on peut vérifier que tout est bien arrivé à l’emplacement prévu :

[sur le conteneur]

# cd /install
# ls
Containerfile  Simplestblog.egg-info  example  instance        reports		 simplestblog
LICENSE.rst    dist		      htmlcov  pyproject.toml  requirements.txt  tests

Puis on peut utiliser pip pour installer les bibliothèques Python requises par Simplestblog :

[sur le conteneur]

# pip install -r requirements.txt

À partir d’ici, notre conteneur contient exactement ce que l’on souhaite comme fichiers au sein de notre future image, à savoir :

un environnement Python,
le logiciel que l’on souhaitera déployer (à savoir Simplestblog),
les dépendances du dit logiciel (à savoir les bibliothèques Python requises par Simplestblog)

On peut donc quitter l’interpréteur de commande de notre conteneur temporaire :

[sur le conteneur]

# exit

Précédemment, nous avons anticipé la conception de notre image Simplestblog avec un point d’entrée et une constante fixée dans la variable d’environnement SIMPLESTBLOG_SETTINGS_FILE. On en déduit donc les métadonnées suivantes :

WORKDIR /install
CMD waitress-serve --call simplestblog:create_app
ENV SIMPLESTBLOG_SETTINGS_FILE=/config.py

Ainsi, à partir du conteneur temporaire simplestblog_template, on peut créer une image appelée simplestblog et étiquettée v1 à l’aide de la commande suivante :

$ podman container commit  simplestblog_template \
                           --change 'WORKDIR /install' \
                           --change 'CMD waitress-serve --call simplestblog:create_app' \
                           --change 'ENV SIMPLESTBLOG_SETTINGS_FILE=/config.py' \
                           simplestblog:v1

En supposant que l’on ait préparé localement un fichier de configuration /data/simplestblog/test_config.py, on peut par exemple utiliser notre image de conteneur de la manière 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 \
                       localhost/simplestblog:v1

4.2. Lister, inspecter des images

Pour lister toutes les images présentes dans le stockage local :

$ podman image list

Exemple 6. Lister l’image Simplestblog

Suite à la construction de l’image de Simplestblog précédemment, on liste les images présentes sur le stockage local :

$ podman image list

REPOSITORY                TAG         IMAGE ID      CREATED        SIZE
localhost/simplestblog    v1          1bd95c71ec04  7 seconds ago  278 MB
docker.io/library/python  3-slim      c1c23a6632a4  13 days ago    136 MB

On observe que deux images sont présentes :

La première est l’image Simplestblog que nous avons créé, avec pour nom simplestblog et comme étiquette v1
La seconde est l’image Python qui a été téléchargée lors de l’instruction FROM, et qui a été utilisée comme base pour construire l’image Simplestblog.

Pour inspecter tous les détails d’une image du stockage local, on peut faire :

$ podman image inspect <référence d'image>

Bien que très utile dans certains contextes, cette commande produit un résultat en JSON très verbeux et assez peu lisible. À n’utiliser que lorsqu’on souhaite vérifier certaines propriétés d’une image (format de stockage, variables d’environnement, etc.).

4.3. Interagir avec un registre distant

Si on souhaite interagir avec un registre de conteneurs distant avec accès restreint, il est d’abord nécessaire de s’authentifier avec un compte utilisateur auprès de ce registre.

Pour s’authentifier auprès d’un registre distant :

$ podman login <nom d'hôte registre distant>

On doit ensuite saisir son nom d’utilisateur et son mot de passe. Si le login est validé, alors toutes les futures commandes Podman pourront utiliser le registre privé.

Cette authentification n’est pas permanente et ne dure que le temps d’une session utilisateur Linux. Il sera par exemple nécessaire de refaire cette authentification à chaque séance de TP.

Exemple 7. Connexion au registre d’images du Gitlab Nantes Université

Le registre d’images du Gitlab Nantes Université a le fonctionnement suivant :

Chaque projet de développement peut héberger ses propres images de conteneurs, visibles dans l’interface à l’aide du menu Déploiement → Registre de conteneur.
Pour pouvoir envoyer une image de conteneur au sein d’un projet, il est nécessaire d’utiliser un compte Gitlab qui possède le statut Developer, Maintainer ou Owner au sein du projet.
Pour pouvoir télécharger une image de conteneur d’un projet, il y a deux cas de figure :
- Si le projet est public, alors les images sont téléchargeables par n’importe qui sans besoin de compte Gitlab au préalable.
- Si le projet est privé, alors seul un membre du projet peut télécharger une image du projet.

Ainsi, pour que vous puissiez correctement envoyer et récupérer des images, en particulier celles de vos projets de développement privés, il vous faut d’abord faire :

$ podman login docker-registry.univ-nantes.fr

puis saisir votre identifiant et mot de passe université.

Pour télécharger manuellement une image distante vers le stockage local :

$ podman image pull <reference d'image>

Pour publier son image sur un registre distant :

$ podman image push <reference d'image locale> \
                    <chemin d'image distante>

Un push nécessite toujours un login préalable, et nécessite d’avoir les droits nécessaires pour déposer l’image à l’emplacement indiqué dans le chemin d’image distante.

Exemple 8. Publication de l’image Simplestblog

On souhaite publier l’image simplestblog:v1 construite précédemment. On suppose avoir déjà fait l’authentification nécessaire auprès du registre de conteneur de Nantes Université.

Le projet de développement de Simplestblog est hébergé sur le Gitlab Nantes Université et est visible sur cette page. Le chemin complet au sein du Gitlab (et, par extension, au sein du registre de conteneurs) est developpement_exploitation/resources/simplestblog.

À l’aide d’un compte utilisateur qui a suffisamment de droits dans ce projet, on exécute la commande suivante :

$ podman image push simplestblog:v1 \
                    docker-registry.univ-nantes.fr/gl/developpement_exploitation/resources/simplestblog:v1

Suite à cela, sur la page du projet sur le Gitlab Nantes Université, on se rend sur la page Déploiement → Registre de conteneur, et on constate la présence de l’étiquette v1 au côté des autres versions disponibles de l’image :

simplestblog gitlab registry annotated.drawio

4.4. Supprimer des images

Pour supprimer une image du stockage local :

$ podman image rm <référence image>

Cette commande échouera s’il existe localement au moins un conteneur instance de l’image référencée. Il faudra donc d’abord supprimer les conteneurs concernés.

Pour supprimer toutes les images actuellement non utilisées par des conteneurs :

$ podman image prune --all

5. Références

Documentation officielle Docker (consultée le 08/09/2023)
Documentation officielle Podman (consultée le 08/09/2023)