📘 Scripter la conteneurisation d’un logiciel

Le langage de loin le plus utilisé pour écrire un script de construction d’image de conteneur est le langage informatique Containerfile.

C’est un langage informatique initialement développé pour le moteur de conteneurisation Docker (sous le nom Dockerfile), mais qui désormais est utilisé par une grande partie des outils de conteneurisation − y compris Podman.

On nomme communément Containerfile un fichier contenant un script de construction écrit avec le langage Containerfile. Un tel fichier est situé la plupart du temps à la racine du répertoire contenant le code source du logiciel qu’on souhaite conteneuriser.

Un Containerfile est une séquence d'instructions. Chaque instruction commence par un mot-clé (FROM, RUN, COPY, etc.) et est suivie par une liste d’arguments. Par convention, de manière analogue au langage SQL, on écrit toujours les instructions en majuscule.

On trouve principalement trois sortes d’instructions :

Lorsqu’on écrit un Containerfile pour créer une image de conteneur pour un logiciel, il existe au moins deux stratégies possibles.

Passons maintenant en revue les instructions les plus importantes qu’on puisse trouver dans un Containerfile.

La première instruction d’un Containerfile est obligatoirement une instruction FROM, qui permet de définir l'image de base utilisée comme pour de départ pour créer notre propre image.

La syntaxe est la suivante :

avec reference_image une référence d’image valide.

Lorsqu’une instruction FROM est exécutée, l’image référencée est récupérée depuis un registre distant si nécessaire, puis un conteneur temporaire est créé à partir de cette image. Toutes les instructions qui suivent FROM agissent sur ce conteneur temporaire afin de l’enrichir pour construire l’environnement souhaité.

L’instruction WORKDIR a deux effets :

où répertoire_conteneur est un chemin vers le répertoire ciblé dans le conteneur.

Changer le répertoire courant influence toutes les instructions suivantes, qui prendront ce répertoire comme contexte d’exécution, jusqu’à la prochaine instruction WORKDIR.

L’instruction COPY copie un répertoire ou un fichier depuis l’environnement d’accueil, vers le conteneur.

où chemin_environnement_hote est un chemin vers un fichier/répertoire de l’environnement d’accueil, et chemin_conteneur un chemin vers un emplacement dans le conteneur.

Au delà de son apparente simplicité, il faut faire attention à quelques particularités peu intuitives concernant COPY :

L’instruction RUN exécute une commande à l’intérieur du conteneur.

Pour que cette commande puisse être exécutée, il faut que l’outil exécuté soit au préalable installé à l’intérieur du conteneur. Cette instruction permet par exemple d’installer de nouveaux logiciels à l’aide d’un installeur de paquets (comme apt ou apk), ou bien de manipuler des fichiers à l’aide de commandes comme cp, mv, rm (si ces dernières sont disponibles dans le conteneur), ou même de compiler le logiciel qu’on souhaite avoir dans le conteneur, si cela est nécessaire.

Un dernier ensemble d’instructions utiles permet de définir les métadonnées de l’image produite pour qu’elle fonctionne de la manière souhaitée.

L’instruction WORKDIR, présentée précédemment, permet de définir le répertoire de départ (c’est à dire le répertoire à partir duquel sera exécuté le point d’entrée) de l’image de contneur.

L’instruction ENV permet de donner une valeur à une variable d’environnement au sein du conteneur créé à partir de l’image  :

Cette variable d’environnement est ensuite accessible par tous les logiciels exécutés au sein du conteneur, par exemple pour les configurer.

L’instruction CMD permet de spécifier le point d’entrée de l’image, autrement dit la commande qui sera exécutée par défaut lors du démarrage du conteneur. Elle s’écrit de manière identique à RUN :

On a vu qu’il existe au moins deux stratégies distinctes pour écrire un Containerfile : soit on construit le logiciel avant de construire l’image, soit on construit le logiciel pendant que l’on construit l’image.

Un grand avantage de la première stratégie est ne pas nécessiter d’avoir dans l’image tout le nécessaire pour construire le logiciel (compilateur, gestionnaire de dépendances, etc). Cela permet donc d’obtenir des images plus légères, qui se concentrent sur le nécessaire pour exécuter le logiciel.

Cependant, il est tout de même souvent désirable de suivre la deuxième stratégie, de manière à simplifier grandement le processus de création de l’image. Malheureusement, cela signifie généralement une image résultante plus lourde.

Pour résoudre cela, il existe une possibilité offerte par le langage Containerfile: la construction d’image multi-stage. Cette fonctionnalité permet d’utiliser des conteneurs temporaires intermédiaires durant le processus de construction de l’image, par exemple pour exécuter des commandes pour compiler un logiciel. On peut ensuite copier des fichiers d’un de ces conteneurs temporaires vers un autre conteneur, par exemple le conteneur final qui sera lui transformé en image.

Cette fonctionnalité s’utilise en combinant deux instructions que l’on a déjà présentées :

Ainsi, on peut par exemple compiler un logiciel dans un premier conteneur − qui peut contenir autant d’outils que nécessaires pour cela − avant de copier le produit de cette compilation dans un second conteneur − qui peut se contenter de posséder le nécessaire juste pour exécuter le logiciel.

Même si nous n’allons pas les utiliser dans ce cours, il est préférable de mentionner brièvement quelques autres instructions que vous risquez de croiser au sein de scripts écrits en Containerfile dans le futur.

L’un des objectifs de la conteneurisation est de rendre aussi facile que possible le fait de déployer un logiciel dans un environnement donné. Au delà du simple déploiement, on souhaite aussi rendre aussi indolore que possible le fait de mettre à jour un logiciel déployé avec un conteneur, ou de migrer un logiciel déployé d’un environnement vers un autre.

Pour que tout cela soit favorisé, une caractéristique recherchée chez un conteneur est sa capacité à être éphémère. Par éphémère on signifie ici qu’un conteneur ne possède pas d’état interne (en anglais, stateless), et qu’il soit anodin de détruire un conteneur pour le reconstruire à l’identique.

Il est par conséquent important de garder deux choses à l’esprit :

Un principe souvent répété en conception logicielle est celui de la séparation des responsabilités (ou séparation des préoccupations). Ce principe établit qu’il est bénéfique de segmenter un programme informatique en plusieurs parties, afin que chacune des partie traite séparément d’un problème particulier. Ce découpage peut s’opérer en divisant du code en plusieurs fichiers, fonctions, classes, composants, ou même différents logiciels.

Ce principe vaut également pour la conception d’images de conteneurs, avec l’idée qu'il est préférable qu’une image se concentre sur une seule responsabilité.

En effet, on peut être tenté de mettre dans un unique conteneur tout le nécessaire pour répondre au problème que l’on souhaite résoudre, y compris par exemple plusieurs logiciels devant être exécutés en parallèle. Cependant, faire cela va rendre plus complexe différentes tâches :

Une image de conteneur contient un mini-environnement qui peut aller jusqu’à inclure les bases d’un véritable système d’exploitation. En outre, l’image contient toutes les dépendances du logiciel qu’on souhaite conteneuriser, à savoir d’autre logiciels ou bibliothèques.

Tout cela mis bout à bout, on peut facilement se retrouver à construire des images d’une taille assez importante.