💻 TP : Scripter la conteneurisation d’un logiciel

1. Présentation et objectifs

L’objectif de ce TP est d’apprendre à utiliser le language Containerfile ainsi que l’outil Podman pour créer de nouvelles images de conteneurs.

Tout pour tous les TPs, lorsque le sujet de TP vous propose d’exécuter une commande, il est demandé que vous arriviez à comprendre tout ce que comporte cette commande. Prenez le temps de bien lire et décortiquer chaque commande qui vous est proposée, et n’hésitez pas à poser des questions.

2. Préparatifs

Ce TP est similaire au TP précédent sur le principe, à savoir la création et la publication d’images. La seule différence est que la création d’images va cette fois se faire avec Containerfile.

Pour la publication d’images, vous allez pouvoir réutiliser le projet Gitlab developpement_exploitation-tp-images créé lors du TP précédent.

Il vous faut également ne pas oublier de vous ré-authentifier auprès du registre de conteneurs pour les exercices qui vous demandent de publier l’image produite :

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

3. Tutoriel : image `cowsay` via un `Containerfile`

3.1. Rappel

Dans le TP précédent, nous avions vu comme premier exemple comment créer une image de conteneur qui met à disposition la commande cowsay.

Dans ce tutoriel, nous allons refaire exactement la même chose, mais en l’automatisant à l’aide d’un script Containerfile.

3.2. Premier `Containerfile` avec `FROM` et `RUN`

Sur l’environnement de déploiement, créez un nouveau répertoire tutoriel-cowsay-containerfile, et préparez le Containerfile suivant :

FROM docker.io/ubuntu:24.04

RUN apt update
RUN apt install -y cowsay

On peut observer l’ajout de l’option -y lors de l’appel à apt install. La raison est que durant l’exécution d’un Containerfile, il n’est pas possible d’interagir avec le constructeur d’image. Or, par défaut, la commande apt peut demander à l’utilisateur de confirmer l’installation d’un paquet à l’aide de la touche clavier y (pour yes) ou n (pour no). Pour éviter cela, l’option -y indique qu’il faut automatiquement répondre par y à toutes les questions posées par apt.

Faites ensuite appel à Podman pour créer une nouvelle image avec pour nom tutoriel-cowsay et pour étiquette v3 :

$ podman image build --tag tutoriel-cowsay:v3 .

La dernière partie d’une commande podman image build doit être le chemin vers un répertoire dit de contexte. Dans notre cas, il suffit donc de pointer vers le répertoire tutoriel-cowsay-containerfile, qui est normalement ici votre répertoire courant, donc ".". Si le répertoire de contexte possède un Containerfile, il sera utilisé par défaut, sauf si l’option --file est spécifiée.

Vous verrez alors apparaître une sortie textuelle complète de ce qui est réalisé pour créer l’image. Chaque instruction du Containerfile apparaît sous la forme d’une étape (STEP).

Une fois l’image construite, vérifiez qu’elle est bien présente dans votre stockage d’image local :

$ podman image list

On notera que la colonne REPOSITORY indique la référence d’image, qui dans notre cas commence par localhost puisque l’image est sur le stockage local.

Il est possible que vous ayez également dans cette liste un reliquat d’images téléchargées dans les précédents exercices, ce qui est normal.

Il ne nous reste plus qu’à tester notre nouvelle image, on peut donc faire :

$ podman container run --rm -ti localhost/tutoriel-cowsay:v3

Comme lors du TP précédent, on se retrouve dans un interpréteur de commandes au sein du conteneur. On peut alors directement exécuter la commande souhaitée, sans avoir à l’installer au préalable :

$ /usr/games/cowsay "Bonjour depuis notre image construite avec un Containerfile !"

3.3. Ajout d’un point d’entrée avec `CMD`

Comme la dernière fois, on souhaite maintenant améliorer notre image en modifiant quel logiciel est exécuté lors du démarrage d’un conteneur créé avec l’image. Cela nécessite de spécifier un point d’entrée pour l’image à l’aide de l’instruction CMD dans le Containerfile.

Il est possible dans une instruction CMD de faire référence à une variable d’environnement avec la syntaxe $VARIABLE. On prépare donc la deuxième version suivante pour notre Containerfile, qui spécifie un point d’entrée avec la commande cowsay prenant comme argument le contenu d’une nouvelle variable d’environnement MESSAGE :

FROM docker.io/ubuntu:24.04

RUN apt update
RUN apt install -y cowsay

CMD /usr/games/cowsay $MESSAGE

À l’aide de ce Containerfile modifié, construisez une nouvelle image de conteneur, cette fois-ci avec l’étiquette v4 :

$ podman image build --tag tutoriel-cowsay:v4 .

On peut vérifier que l’image est bien créée à nouveau à l’aide de la commande :

$ podman image list

On peut ainsi désormais exécuter un conteneur de la sorte :

$ podman container run --rm \
                       --env MESSAGE="Re-bonjour depuis notre nouvelle image !" \
                       localhost/tutoriel-cowsay:v4

Et voilà en fonctionnement une construction automatisée de notre image paramétrable !

4. Exercice : image Asciidoctor via `Containerfile`

Refaites l’exercice Asciidoctor du TP précédent, mais cette fois-ci construisez votre image de conteneur à l’aide d’un Containerfile.

5. Tutoriel : image site web nginx via `Containerfile`

5.1. Rappel

Pour rappel, dans le TP précédent nous avions préparé une image de conteneur contenant un petit site web près à être déployé. Nous allons dans ce tutoriel accomplir la même chose, mais à l’aide d’un Containerfile.

5.2. `Containerfile` avec `FROM`, `RUN` et `COPY`

L’objectif ici est de créer une image de conteneur dans laquelle se trouve directement à la fois le logiciel nginx et le site web qu’on souhaite déployer.

Pour accomplir cela, il nous faut, lors de la création de l’image, s’assurer que notre site web (qui contient à minima un fichier index.html) soit copié dans le répertoire /usr/share/nginx/html/ de l’image, car c’est à cet emplacement que nginx va charger le site qu’il rendra accessible.

Au sein de l’image nginx, le contenu par défaut de /usr/share/nginx/html/ n’est pas vide, car il contient une page d’accueil d’exemple, qui ne nous intéresse pas ! Il va donc nous falloir remplacer ce répertoire par le contenu de notre choix.

Sur l’environnement de déploiement, créez un nouveau répertoire tutoriel-nginx. Dans ce répertoire, mettez le HTML que vous aviez généré à l’aide d’Asciidoctor dans l’exercice précédent, et renommez ce fichier en index.html. Ensuite, rendez-vous dans le répertoire tutoriel-nginx et préparez le Containerfile suivant :

FROM docker.io/nginx:1.25

RUN rm /usr/share/nginx/html/*

COPY ./*.html /usr/share/nginx/html/index.html

On observe que :

À l’aide de RUN, une commande rm est utilisée pour supprimer le contenu du répertoire /usr/share/nginx/html/, afin de supprimer la page d’accueil d’exemple qui est fournie d’office dans l’image nginx.
À l’aide de COPY, On ajoute à l’image tous les fichiers HTML du répertoire tutoriel-nginx, au cas où notre site comporte plusieurs pages.

Il est possible d’écrire un Containerfile équivalent à celui ci-dessus en utilisant la commande WORKDIR pour changer le répertoire courant, qui permet de simplifier les commandes RUN et ADD qui suivent. N’hésitez pas à essayer !

Construisez une image de conteneur avec la commande suivante :

$ podman image build --tag tutoriel-nginx:2 .

Enfin, testez votre image en créant un conteneur :

$ podman container run --rm \
                       --detach \
                       --name nouveau_serveur_web \
                       --publish <mon port réseau>:80 \
                       localhost/tutoriel-nginx:2

Vérifiez que votre déploiement fonctionne en accédant depuis un navigateur à l’adresse http://podman:<mon port réseau> : normalement votre HTML s’affiche comme prévu !

Une fois ce tutoriel terminé, n’oubliez pas d’arrêter et de supprimer le conteneur créé.

6. Exercice : créer une image pour Web Calculator (Python)

6.1. Énoncé

On souhaite créer une image de conteneur pour un logiciel fraîchement développé appelé Web Calculator. C’est une application web développée en Python, dont le code source est disponible sur le projet Gitlab suivant.

Une fois exécutée, l’application peut être accédée via un navigateur web, et fournit une interface pour faire des calculs arithmétiques entre deux nombres (addition, soustraction, etc.).

Lisez la documentation de l’application, et en particulier les sections 3 et 4. On y trouve des informations importantes, notamment :

Le logiciel nécessite un certain nombre de dépendances Python.
Ces dépendances peuvent être installées à l’aide de l’utilitaire pip.
Une commande uvicorn permet de démarrer le logiciel.
Le logiciel nécessite le port réseau 8000 pour recevoir des connexions.

La documentation fait référence à un concept Python appelé venv. C’est une manière pratique pour créer des environnements Python dans lesquelles on installe des dépendances spécifiques à un développement ou un déploiement particulier. Dans notre cas, nous pouvons ignorer l’utilisation de venv car cela n’est pas nécessaire dans un conteneur, qui fourni déjà un environnement isolé adapté.

6.2. Préparatifs

Vous allez avoir besoin de récupérer le code source du logiciel afin de l’ajouter dans votre image de conteneur. Pour cela, le plus simple est d’utiliser l’utilitaire git de la manière suivante :

$ git clone <URL git>

avec <URL git> l’URL git du projet que l’on souhaite récupérer.

Pour obtenir l’URL dit d’un projet Gitlab, on clique sur le bouton "Code" et on copie le contenu "Cloner avec HTTPS". On peut ensuite coller l’URL dans un terminal pour faire notre git clone.

Par exemple pour le projet web calculator on peut faire :

[sur l’environnement de déploiement distant]

$ git clone https://gitlab.univ-nantes.fr/gl/developpement_exploitation/resources/web-calculator.git

ce qui va créer un répertoire web-calculator où sera téléchargé tout le code source du projet.

6.3. Questions

Pour récupérer le code source du projet Gitlab, vous pouvez suivre les instructions dédiées de la notice Gitlab.

Préparez un Containerfile permettant de créer une image Web Calculator. Pour cela, posez-vous les questions suivantes :
1. Quels outils doivent être présents dans notre image de base ? Par conséquent, quelle image de base choisir ?
  
  Pour choisir une image de base, n’hésitez pas à relire la section correspondante dans le chapitre sur les images de conteneurs.
2. Quels fichiers faut-il mettre dans l’image afin d’exécuter le logiciel ?
3. Quelles commandes faut-il exécuter lors de la construction de l’image ?
4. Quelle métadonnée est nécessaire pour le point d’entrée ?
Créez une image en exécutant votre Containerfile à l’aide de Podman. On souhaite que notre image se nomme webcalculator et ait pour étiquette dev.
Préparez une commande pour créer un conteneur à l’aide de votre image créée localement, puis déployez votre application sur le serveur de déploiement.
Testez votre application à l’aide d’un navigateur.
Publiez votre image au sein de votre projet Gitlab.

7. Exercice : créer une image webdav-embedded-server (Java)

7.1. Énoncé

On souhaite créer une image de conteneur pour le logiciel webdav-embedded-server, développé en Java, dont le code source est disponible au sein d’un projet sur le Gitlab Université.

Ce logiciel permet d’exécuter un serveur de stockage de fichiers, sur lequel il est possible de se connecter à l’aide du protocole Webdav. Ce protocole est aujourd’hui très répandu et de nombreux explorateurs de fichiers sont capables d’accéder à distance au contenu d’un serveur Webdav, afin de lire, modifier, créer ou supprimer des fichiers.

Si on analyse le contenu du projet on découvre plusieurs éléments importants :

On peut voir la présence d’un fichier build.gradle, qui signifie que la compilation du code doit se faire avec l’outil Gradle. Si on fouille dans le fichier build.gradle, on découvre qu’une commande Gradle intitulée fatJar est disponible, et permet de compiler le code du logiciel au sein d’un fichier .jar qui embarque automatiquement toutes les dépendances du logiciel − très pratique pour un déploiement !
On peut voir dans le README une description sommaire du mode Standalone du logiciel, qui permet de démarrer un serveur. On peut voir que différentes options sont disponibles pour lancer l’application, notamment --credentials qui permet de spécifier un compte utilisateur pour se connecter au serveur, et --port qui permet de spécifier le port à utiliser pour se connecter à l’application (par défaut, 8080). Après les options, il faut spécifier le chemin du répertoire dans lequel le serveur Webdav stockera ses fichiers.

Si on met tout cela bout à bout, cela signifie qu’on peut compiler notre application à l’aide de la commande :

$ gradle fatJar

Cela produira normalement un fichier build/libs/webdav-embedded-server-0.2.1-SNAPSHOT-fatjar.jar.

Malheureusement, le serveur de déploiement de l’Université possède une contrainte qui va entraver l’usage de Gradle : l’usage obligatoire d’un proxy HTTP pour toute connexion HTTP réalisée (donc pour tout téléchargement de fichier). Or, Gradle a besoin de télécharger des fichiers pour récupérer toutes les dépendances Java du projet… !

Jusqu’ici le problème ne s’est pas présenté durants les TPs car le serveur de déploiement est bien configuré, et possède une variable d’environnement standard appelée https_proxy qui est utilisée automatiquement par tous les logiciels pour utiliser le proxy de manière transparente. Ainsi, on peut généralement ignorer la présence du proxy, et laisser les logiciels l’utiliser par eux-même sans que nous ayons à faire quoi que ce soit.

Mais Gradle n’est pas capable d’utiliser la variable https_proxy ! Il est nécessaire de lui donner cette information via deux options :

-Dhttps.proxyHost=<nom d’hôte proxy HTTP>
-Dhttps.proxyPort=<port réseau proxy HTTP>

À l’Université, le serveur de proxy HTTP est accessible avec le nom d’hôte proxy.ensinfo.sciences.univ-nantes.prive et avec le port 3128.

Si on met tout cela bout à bout, il est donc dans notre cas nécessaire d’appeler Gradle de la sorte :

$ gradle -Dhttps.proxyHost=proxy.ensinfo.sciences.univ-nantes.prive \
         -Dhttps.proxyPort=3128 fatJar

Ensuite, depuis le répertoire build/libs, on peut lancer le serveur avec la commande :

$ java -jar webdav-embedded-server-0.2.1-SNAPSHOT-fatjar.jar
            --credentials "<utilisateur>:<mot de passe>"

Et le serveur Webdav démarrera en écoutant sur le port 8080, et n’autorisera que les informations de connections spécifiées par --credentials.

Contraintes à respecter : Lors de la création d’un conteneur à partir votre l’image, on souhaite pouvoir spécifier :

un nom d’utilisateur et un mot de passe qui seront les informations de connexion acceptées par le serveur Webdav.
un emplacement de l’environnement d’accueil dans lequel le serveur stockera ses fichiers.

7.2. Préparatifs

Récupérez le code source du logiciel à l’aide de git clone.

7.3. Questions (création de l’image)

Pour récupérer le code source du projet Gitlab, vous pouvez suivre les instructions dédiées de la notice Gitlab.

Préparez un Containerfile permettant de créer une image webdav-embedded-server. Pour cela, posez-vous les questions suivantes :
1. Quels outils doivent être présents dans notre image de base ? Par conséquent, quelle image de base choisir ?
2. Quels fichiers faut-il mettre dans l’image afin de compiler le logiciel ?
3. Quels fichiers faut-il mettre dans l’image afin d’exécuter le logiciel ? D’où provient ce fichier ?
4. Quelles commandes faut-il exécuter lors de la construction de l’image ?
5. Par quels mécanismes gérer les deux contraintes posées plus haut ?
6. Quelle métadonnée est nécessaire pour le point d’entrée ?
Créez une image en exécutant votre Containerfile à l’aide de Podman. On souhaite que notre image se nomme webdavserver et ait pour étiquette latest.
Préparez une commande pour créer un conteneur à l’aide de votre image créée localement, puis déployez votre application sur le serveur de déploiement.
Testez votre application de la sorte :
1. Sur votre poste de travail linux, ouvrez l’application Fichiers (que vous utilisez quotidiennement pour accéder à vos fichiers).
2. Utilisez le raccourci clavier CTRL+L afin d’accéder à la barre d’adresse en haut de l’a fenêtre.
3. Dans cette barre d’adresse, saisissez dav://podman:<port réseau>, afin de vous connecter à votre serveur Webdav déployé sur le serveur de déploiement. Saisissez les informations de connexion demandées, et validez. Si vous n’avez pas de message d’erreur, vous êtes bien connecté !
4. Tentez de copier un fichier de votre choix au sein de votre serveur Webdav.
5. Vérifiez que le fichier copié apparaît bien dans l’emplacement du serveur de déploiement où le serveur stocke ses fichiers.
Enfin, publiez votre image au sein de votre projet Gitlab.

7.4. Questions (amélioration de l’image)

Il est conseillé (mais pas indispensable) de revenir sur ces questions "avancées" uniquement après voir fini l’exercice WordcloudGenerator qui suit, ou bien pendant les longs temps d’attente dûs à l’installation de paquets durant l’exercice WordcloudGenerator.

Quelle est la taille de l’image webdav-embedded-server que vous avez produite ?
Qu’est-ce que qui peut expliquer la taille occupée par l’image ?
Quelle stratégie étudiée en cours permettrait de réduire la taille de l’image ?
Proposez un nouveau Containerfile qui mette en œuvre cette stratégie, et comparez la taille de l’image obtenue avec la première version.

Si vous avez déjà mis en place cette stratégie − déjà, bravo ! − vous pouvez bien sûr sauter cette partie.

8. Exercice : créer une image WordcloudGenerator (langage R)

8.1. Énoncé

On souhaite créer une image de conteneur pour le logiciel WordcloudGenerator développé en R, dont le code source est là aussi disponible au sein d’un projet sur le Gitlab Université.

Ce logiciel permet de construire un nuage de mots à partir d’un fichier texte simple. Il s’exécute sous la forme d’une application web qui peut être accédée depuis un navigateur. L’interface permet d’envoyer un fichier .txt et de sélectionner le nombre de mots devant apparaître dans le nuage.

Lisez la documentation technique du projet. On peut y trouver les informations utiles suivantes :

Le logiciel nécessite un ensemble de paquets R.
Le logiciel nécessite également une bibliothèque logicielle C appelée libxml2.
Une commande simple est fournie pour exécuter le logiciel.

Installer un paquet R

Pour installer un paquet R dans un environnement donné où R est déjà installé, on peut utiliser la commande suivante :

$ Rscript -e 'install.packages("<nom du package>")'

Installer un paquet R peut prendre beaucoup de temps ! N’hésitez pas à faire la fin de l’exercice précédent pendant la longue construction de votre image.

8.2. Préparatifs

Récupérez le code source du logiciel à l’aide de git clone.

8.3. Questions

Pour récupérer le code source du projet Gitlab, vous pouvez suivre les instructions dédiées de la notice Gitlab.

Préparez un Containerfile permettant de créer une image WordcloudGenerator. Pour cela, posez-vous les questions suivantes :

Quels outils doivent être présents dans notre image de base ? Par conséquent, quelle image de base choisir ?

Comment faire pour installer la bibliothèque logicielle C nécessaire au sein de l’image de base choisie ?

Indice : vous pouvez allez voir quelle image de base a été utilisée pour construire l’image de base que vous souhaitez utiliser, cela peut vous aider à savoir quel utilitaire de gestion de dépendance (apt, ou apk, ou dnf, ou autre) utiliser !

Quels fichiers faut-il mettre dans l’image afin d’exécuter le logiciel ?
Quelles commandes faut-il exécuter lors de la construction de l’image ?
Quelle métadonnée est nécessaire pour le point d’entrée ?

Créez une image en exécutant votre Containerfile à l’aide de Podman. On souhaite que notre image se nomme wordcloudgenerator et ait pour étiquette v1.
Préparez une commande pour créer un conteneur à l’aide de votre image créée localement, puis déployez votre application sur le serveur de déploiement.
Testez votre déploiement à l’aide d’un navigateur. Vous aurez pour cela besoin d’un fichier texte avec du contenu à analyser. Vous pouvez par exemple utiliser le contenu du livre The Adventures of Sherlock Holmes, ou encore le contenu du livre Moby Dick.
Enfin, publiez votre image au sein de votre projet Gitlab.

💻 TP : Scripter la conteneurisation d’un logiciel

1. Présentation et objectifs

2. Préparatifs

3. Tutoriel : image cowsay via un Containerfile

3.1. Rappel

3.2. Premier Containerfile avec FROM et RUN

3.3. Ajout d’un point d’entrée avec CMD

4. Exercice : image Asciidoctor via Containerfile

5. Tutoriel : image site web nginx via Containerfile

5.1. Rappel

5.2. Containerfile avec FROM, RUN et COPY

6. Exercice : créer une image pour Web Calculator (Python)

6.1. Énoncé

6.2. Préparatifs

6.3. Questions

7. Exercice : créer une image webdav-embedded-server (Java)

7.1. Énoncé

7.2. Préparatifs

7.3. Questions (création de l’image)

7.4. Questions (amélioration de l’image)

8. Exercice : créer une image WordcloudGenerator (langage R)

8.1. Énoncé

8.2. Préparatifs

8.3. Questions

3. Tutoriel : image `cowsay` via un `Containerfile`

3.2. Premier `Containerfile` avec `FROM` et `RUN`

3.3. Ajout d’un point d’entrée avec `CMD`

4. Exercice : image Asciidoctor via `Containerfile`

5. Tutoriel : image site web nginx via `Containerfile`

5.2. `Containerfile` avec `FROM`, `RUN` et `COPY`