Chapitre 4. Création d’images

Les directives suivantes s’appliquent lors de la création d’une image de conteneur en général et sont indépendantes de l’utilisation ou non des images sur Red Hat OpenShift Service sur AWS.

La réutilisation des images

Dans la mesure du possible, basez votre image sur une image en amont appropriée à l’aide de l’instruction FROM. Cela garantit que votre image peut facilement récupérer des correctifs de sécurité à partir d’une image en amont lorsqu’elle est mise à jour, plutôt que de devoir mettre à jour vos dépendances directement.

De plus, 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. En utilisant une balise autre que la dernière, vous assurez que votre image n’est pas soumise à des changements qui pourraient entrer dans la dernière version d’une image en amont.

Conserver la compatibilité dans les balises

Lors du marquage de vos propres images, essayez de maintenir la compatibilité rétrograde dans une balise. Ainsi, si vous fournissez une image nommée image et qu’elle inclut actuellement la version 1.0, vous pouvez fournir une balise d’image:v1. Lorsque vous mettez à jour l’image, tant qu’elle continue d’être compatible avec l’image originale, vous pouvez continuer à marquer la nouvelle image:v1, et les consommateurs en aval de cette balise sont en mesure d’obtenir des mises à jour sans être cassés.

Lorsque vous publiez ultérieurement une mise à jour incompatible, puis passez à une nouvelle balise, par exemple image:v2. Cela permet aux consommateurs en aval de passer à la nouvelle version à volonté, mais ne sont pas brisés par inadvertance par la nouvelle image incompatible. Le consommateur en aval utilisant image:la plus longue prend le risque d’introduire des modifications incompatibles.

Évitez les processus multiples

Il ne faut pas démarrer plusieurs services, tels qu’une base de données et un SSHD, à l’intérieur d’un seul conteneur. Ce n’est pas nécessaire car les conteneurs sont légers et peuvent être facilement liés entre eux pour l’orchestration de multiples processus. Le service OpenShift Red Hat sur AWS vous permet de colocaliser et de co-gérer facilement les images associées en les regroupant en un seul pod.

Cette colocation assure que les conteneurs partagent un espace de noms réseau et un stockage pour la communication. Les mises à jour sont également moins perturbatrices car chaque image peut être mise à jour moins fréquemment et indépendamment. Les flux de gestion du signal sont également plus clairs avec un seul processus car vous n’avez pas à gérer les signaux de routage vers les processus engendrés.

Exec dans les scripts d’emballage

De nombreuses images utilisent des scripts d’emballage pour faire une certaine configuration avant de commencer un processus pour le logiciel en cours d’exécution. Lorsque votre image utilise un tel script, ce script utilise exec afin que le processus du script soit remplacé par votre logiciel. Lorsque vous n’utilisez pas exec, les signaux envoyés par votre conteneur vont dans votre script d’emballage au lieu du processus de votre logiciel. Ce n’est pas ce que vous voulez.

Lorsque vous avez un script d’emballage qui démarre un processus pour un serveur. Démarrez votre conteneur, par exemple, en utilisant podman run -i, qui exécute le script d’emballage, qui démarre à son tour votre processus. Lorsque vous souhaitez fermer votre conteneur avec CTRL+C. Lorsque votre script d’emballage utilisé exec pour démarrer le processus serveur, podman envoie SIGINT au processus serveur, et tout fonctionne comme vous l’attendez. Lorsque vous n’avez pas utilisé Exec dans votre script d’emballage, podman envoie SIGINT au processus pour le script d’emballage et votre processus continue de fonctionner comme si rien ne s’était passé.

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

Nettoyer les fichiers temporaires

Enlevez tous les fichiers temporaires que vous créez pendant le processus de construction. Cela inclut également tous les fichiers ajoutés avec la commande ADD. À titre d’exemple, exécutez la commande yum clean après avoir effectué des opérations d’installation yum.

Il est possible d’empêcher le cache yum de se retrouver dans une couche d’image en créant votre instruction RUN comme suit:

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

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

A noter que si vous écrivez plutôt:

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

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

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

Le processus de construction du conteneur actuel ne permet pas qu’une commande s’exécute dans une couche ultérieure pour réduire l’espace utilisé par l’image lorsque quelque chose a été supprimé dans une couche antérieure. Cependant, 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. Donc, comme avec l’exemple yum clean, il est préférable de supprimer des fichiers dans la même commande qui les a créés, lorsque cela est possible, afin qu’ils ne finissent pas par écrire sur un calque.

De plus, l’exécution de commandes multiples dans une seule instruction RUN réduit le nombre de couches de votre image, ce qui améliore le temps de téléchargement et d’extraction.

Placer les instructions dans l’ordre approprié

Le constructeur de conteneurs lit le Dockerfile et exécute les instructions de haut en bas. Chaque instruction exécutée avec succès crée un calque qui peut être réutilisé la prochaine fois que cette ou une autre image est construite. Il est très important de placer des instructions qui changent rarement en haut de votre Dockerfile. Cela garantit que les prochaines versions de la même image sont très rapides car le cache n’est pas invalidé par des changements de couche supérieure.

À titre d’exemple, si vous travaillez sur un Dockerfile contenant une commande ADD pour installer un fichier sur lequel vous itérez, et une commande RUN pour yum installer un paquet, il est préférable de mettre la commande ADD en dernier:

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

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

De cette façon, chaque fois que vous modifiez myfile et redémarrez podman build ou docker build, le système réutilise le calque mis en cache pour la commande yum et génère uniquement le nouveau calque pour l’opération ADD.

Au lieu de cela, vous avez écrit le Dockerfile comme suit:

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

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

Ensuite, chaque fois que vous avez changé myfile et reran podman build ou docker build, l’opération ADD invaliderait le cache de couche RUN, de sorte que l’opération yum doit également être redémarrée.

Marquer les ports importants

L’instruction EXPOSE met un port dans le conteneur à la disposition du système hôte et d’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 pour les humains et les logiciels en déclarant explicitement les ports que votre logiciel doit exécuter:

Définir les variables d’environnement

C’est une bonne pratique de définir des variables d’environnement avec l’instruction ENV. Il s’agit par exemple de définir la version de votre projet. Cela permet aux gens de trouver facilement la version sans regarder le Dockerfile. Autre exemple, la publicité d’un chemin sur le système qui pourrait être utilisé par un autre processus, tel que JAVA_HOME.

Évitez les mots de passe par défaut

Évitez de définir les mots de passe par défaut. Beaucoup de gens é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 sont paramétrables à l’aide d’une variable d’environnement à la place.

Lorsque vous choisissez de définir un mot de passe par défaut, assurez-vous qu’un message d’avertissement approprié est affiché lors du démarrage du conteneur. Le message doit informer l’utilisateur de la valeur du mot de passe par défaut et expliquer comment le modifier, comme quelle variable d’environnement à définir.

Évitez le sshd

Il est préférable d’éviter de courir sshd dans votre image. La commande podman exec ou docker exec permet d’accéder aux conteneurs qui s’exécutent sur l’hôte local. Alternativement, vous pouvez utiliser la commande oc exec ou la commande oc rsh pour accéder aux conteneurs qui s’exécutent sur le service OpenShift Red Hat sur le cluster AWS. L’installation et l’exécution de sshd dans votre image ouvrent des vecteurs supplémentaires pour les attaques et les exigences pour le correctif de sécurité.

Les volumes utilisés pour les données persistantes

Les images utilisent un volume pour les données persistantes. De cette façon, Red Hat OpenShift Service sur AWS monte le stockage réseau sur le nœud exécutant le conteneur, et si le conteneur se déplace vers un nouveau nœud, le stockage est réattaché à ce nœud. En utilisant le volume pour tous les besoins de stockage persistants, le contenu est conservé même si le conteneur est redémarré ou déplacé. Lorsque votre image écrit des données à des endroits arbitraires dans le conteneur, ce contenu n’a pas pu être préservé.

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 drapeau en lecture seule pour les conteneurs, qui peut être utilisé pour appliquer strictement les bonnes pratiques en matière de ne pas écrire de données pour le stockage éphémère dans un conteneur. Concevoir votre image autour de cette capacité rend maintenant plus facile d’en profiter plus tard.

Définir explicitement les volumes dans votre Dockerfile permet aux consommateurs de l’image de comprendre facilement quels volumes ils doivent définir lors de l’exécution de votre image.

Consultez la documentation Kubernetes pour plus d’informations sur la façon dont les volumes sont utilisés dans Red Hat OpenShift Service sur AWS.

Les lignes directrices suivantes s’appliquent lors de la création d’images de conteneurs spécifiquement destinées à être utilisées sur Red Hat OpenShift Service sur AWS.

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

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