Chapitre 4. Création d'images

Les directives suivantes s'appliquent à la création d'une image de conteneur en général, et sont indépendantes de l'utilisation des images sur OpenShift Container Platform.

Réutiliser les images

Dans la mesure du possible, basez votre image sur une image en amont appropriée en utilisant la déclaration FROM. Cela permet à votre image de récupérer facilement les correctifs de sécurité d'une image en amont lorsqu'elle est mise à jour, plutôt que d'avoir à mettre à jour vos dépendances directement.

En outre, utilisez des balises dans l'instruction FROM, par exemple rhel:rhel7, pour indiquer clairement aux utilisateurs la version d'une image sur laquelle votre image est basée. L'utilisation d'une balise autre que latest permet de s'assurer que votre image n'est pas soumise à des modifications qui pourraient être apportées à la version latest d'une image en amont.

Maintenir la compatibilité entre les balises

Lorsque vous marquez vos propres images, essayez de maintenir la compatibilité ascendante au sein d'une balise. Par exemple, si vous fournissez une image nommée foo et qu'elle inclut actuellement la version 1.0, vous pouvez fournir une balise foo:v1. Lorsque vous mettez à jour l'image, tant qu'elle reste compatible avec l'image originale, vous pouvez continuer à baliser la nouvelle image foo:v1, et les consommateurs en aval de cette balise sont en mesure d'obtenir des mises à jour sans être interrompus.

Si vous publiez ultérieurement une mise à jour incompatible, passez à une nouvelle balise, par exemple foo:v2. Cela permet aux consommateurs en aval de passer à la nouvelle version à leur guise, sans être interrompus par inadvertance par la nouvelle image incompatible. Tout consommateur en aval qui utilise foo:latest prend le risque que des changements incompatibles soient introduits.

Éviter les processus multiples

Ne démarrez pas plusieurs services, tels qu'une base de données et SSHD, à l'intérieur d'un même conteneur. Cela n'est pas nécessaire car les conteneurs sont légers et peuvent être facilement reliés entre eux pour orchestrer plusieurs processus. OpenShift Container Platform vous permet de colocaliser et de cogérer facilement des images connexes en les regroupant dans un seul pod.

Cette colocation garantit que les conteneurs partagent un espace de noms réseau et un espace de stockage pour la communication. Les mises à jour sont également moins perturbantes, car chaque image peut être mise à jour moins fréquemment et indépendamment. Les flux de traitement des signaux sont également plus clairs avec un processus unique, car il n'est pas nécessaire de gérer l'acheminement des signaux vers les processus créés.

Utiliser exec dans les scripts d'accompagnement

De nombreuses images utilisent des scripts enveloppants pour effectuer certaines configurations avant de lancer un processus pour le logiciel en cours d'exécution. Si votre image utilise un tel script, celui-ci utilise exec afin que le processus du script soit remplacé par votre logiciel. Si vous n'utilisez pas exec, les signaux envoyés par le moteur d'exécution de votre conteneur sont transmis à votre script d'encapsulation au lieu du processus de votre logiciel. Ce n'est pas ce que vous souhaitez.

Si vous avez un script wrapper qui démarre un processus pour un serveur. Vous démarrez votre conteneur, par exemple, à l'aide de podman run -i, qui exécute le script wrapper, lequel démarre à son tour votre processus. Si vous souhaitez fermer votre conteneur à l'aide de CTRL C, si votre script wrapper a utilisé exec pour démarrer le processus du serveur, podman envoie SIGINT au processus du serveur et tout se passe comme prévu. Si vous n'avez pas utilisé exec dans votre script wrapper, podman envoie SIGINT au processus du script wrapper et votre processus continue à fonctionner comme si de rien n'était.

Notez également que votre processus s'exécute en tant que PID 1 lorsqu'il est exécuté dans un conteneur. Cela signifie que si votre processus principal se termine, l'ensemble du conteneur est arrêté, ce qui annule tous les processus enfants que vous avez lancés à partir de votre processus PID 1.

Nettoyer les fichiers temporaires

Supprimez tous les fichiers temporaires créés au cours du processus de construction. Cela inclut également tous les fichiers ajoutés avec la commande ADD. Par exemple, exécutez la commande yum clean après avoir effectué les opérations yum install.

Vous pouvez éviter que le cache yum ne se retrouve dans une couche d'image en créant votre déclaration RUN de la manière suivante :

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

Notez que si vous écrivez à la place :

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

La première invocation de yum laisse alors des fichiers supplémentaires dans cette couche, et ces fichiers ne peuvent pas être supprimés lorsque l'opération yum clean est exécutée ultérieurement. Les fichiers supplémentaires ne sont pas visibles dans l'image finale, mais ils sont présents dans les couches sous-jacentes.

Le processus actuel de construction des conteneurs ne permet pas à une commande exécutée dans une couche ultérieure de réduire l'espace utilisé par l'image lorsque quelque chose a été supprimé dans une couche antérieure. Toutefois, cela pourrait changer à l'avenir. Cela signifie que si vous exécutez une commande rm dans une couche ultérieure, bien que les fichiers soient cachés, cela ne réduit pas la taille globale de l'image à télécharger. Par conséquent, comme dans l'exemple yum clean, il est préférable de supprimer les fichiers dans la même commande que celle qui les a créés, dans la mesure du possible, afin qu'ils ne finissent pas par être écrits dans un calque.

En outre, l'exécution de plusieurs commandes dans une seule déclaration RUN réduit le nombre de couches de votre image, ce qui améliore le temps de téléchargement et d'extraction.

Placez les instructions dans l'ordre approprié

Le constructeur de conteneurs lit le site Dockerfile et exécute les instructions de haut en bas. Chaque instruction exécutée avec succès crée une couche qui peut être réutilisée lors de la prochaine construction de cette image ou d'une autre. Il est très important de placer les instructions qui changent rarement au sommet de votre Dockerfile. Cela garantit que les prochaines constructions de la même image seront très rapides, car le cache n'est pas invalidé par les modifications des couches supérieures.

Par exemple, si vous travaillez sur un site Dockerfile qui contient une commande ADD pour installer un fichier sur lequel vous êtes en train d'itérer, et une commande RUN pour yum install un paquet, il est préférable de placer la commande ADD en dernier :

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

Ainsi, chaque fois que vous modifiez myfile et que vous exécutez à nouveau podman build ou docker build, le système réutilise la couche mise en cache pour la commande yum et ne génère la nouvelle couche que pour l'opération ADD.

Si, au lieu de cela, vous écriviez Dockerfile comme suit :

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

Ensuite, chaque fois que vous modifiez myfile et que vous exécutez à nouveau podman build ou docker build, l'opération ADD invalide le cache de la couche RUN, de sorte que l'opération yum doit également être exécutée à nouveau.

Marquer les ports importants

L'instruction EXPOSE rend un port du conteneur accessible au système hôte et aux autres conteneurs. Bien qu'il soit possible de spécifier qu'un port doit être exposé avec une invocation podman run, l'utilisation de l'instruction EXPOSE dans un Dockerfile facilite l'utilisation de votre image par les humains et les logiciels en déclarant explicitement les ports dont votre logiciel a besoin pour fonctionner :

Définir les variables d'environnement

Il est conseillé de définir des variables d'environnement à l'aide de l'instruction ENV. Un exemple est la définition de la version de votre projet. Cela permet aux gens de trouver facilement la version sans avoir à consulter l'instruction Dockerfile. Un autre exemple consiste à annoncer un chemin sur le système qui pourrait être utilisé par un autre processus, tel que JAVA_HOME.

Éviter les mots de passe par défaut

Évitez de définir des mots de passe par défaut. De nombreuses personnes étendent l'image et oublient de supprimer ou de modifier le mot de passe par défaut. Cela peut entraîner des problèmes de sécurité si un utilisateur en production se voit attribuer un mot de passe bien connu. Les mots de passe peuvent être configurés à l'aide d'une variable d'environnement.

Si vous choisissez de définir un mot de passe par défaut, veillez à ce qu'un message d'avertissement approprié s'affiche au démarrage du conteneur. Ce message doit informer l'utilisateur de la valeur du mot de passe par défaut et lui expliquer comment le modifier, par exemple en lui indiquant la variable d'environnement à définir.

Éviter sshd

Il est préférable d'éviter d'exécuter sshd dans votre image. Vous pouvez utiliser la commande podman exec ou docker exec pour accéder aux conteneurs qui s'exécutent sur l'hôte local. Vous pouvez également utiliser la commande oc exec ou la commande oc rsh pour accéder aux conteneurs qui s'exécutent sur le cluster OpenShift Container Platform. L'installation et l'exécution de sshd dans votre image ouvre des vecteurs d'attaque supplémentaires et des exigences en matière de correctifs de sécurité.

Utiliser des volumes pour les données persistantes

Les images utilisent un volume pour les données persistantes. De cette façon, OpenShift Container Platform monte le stockage réseau sur le nœud qui exécute le conteneur, et si le conteneur est déplacé vers un nouveau nœud, le stockage est rattaché à ce nœud. En utilisant le volume pour tous les besoins de stockage persistant, le contenu est préservé même si le conteneur est redémarré ou déplacé. Si votre image écrit des données à des emplacements arbitraires dans le conteneur, ce contenu ne pourra pas être préservé.

Toutes les données qui doivent être conservées même après la destruction du conteneur doivent être écrites sur un volume. Les moteurs de conteneurs prennent en charge un indicateur readonly pour les conteneurs, qui peut être utilisé pour appliquer strictement les bonnes pratiques concernant l'absence d'écriture de données sur un stockage éphémère dans un conteneur. En concevant votre image autour de cette capacité dès maintenant, il sera plus facile d'en tirer parti ultérieurement.

La définition explicite des volumes dans votre site Dockerfile permet aux utilisateurs de l'image de comprendre facilement quels volumes ils doivent définir lors de l'exécution de votre image.

Voir la documentation Kubernetes pour plus d'informations sur l'utilisation des volumes dans OpenShift Container Platform.

Les directives suivantes s'appliquent lors de la création d'images de conteneurs spécifiquement destinées à être utilisées sur OpenShift Container Platform.

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory