Les 5 régles de base

1) Ne stockez pas de données dans des conteneurs - Un conteneur peut être arrêté, détruit ou remplacé. Une application version 1.0 fonctionnant en conteneur devrait être facilement remplacée par la version 1.1 sans aucun impact ni perte de données. Pour cette raison, si vous avez besoin de stocker des données, faites-le dans un volume. Vous devez également faire attention si deux conteneurs écrivent des données sur le même volume cela pourrait entraîner une corruption. Assurez-vous que vos applications sont conçues pour écrire dans un magasin de données partagé.

2) Ne distribuer pas votre application en deux parties - Comme certaines personnes voient les conteneurs comme une machine virtuelle, la plupart d'entre eux ont tendance à penser qu'ils devraient déployer leur application dans des conteneurs en cours d'exécution existants. Cela peut être vrai pendant la phase de développement où vous devez déployer et déboguer en continu; mais pour un pipeline de livraison continue (CD) vers l'assurance qualité et la production, votre application doit faire partie de l'image. N'oubliez pas: les conteneurs sont immuables.

3) Ne créez pas de grosses images – Une image lourde sera plus difficile à diffuser. Assurez-vous que vous ne disposez que des fichiers et bibliothèques requis pour exécuter votre application / processus. N’installez pas de packages inutiles et n’exécutez pas de «mises à jour» (yum update) qui téléchargent de nombreux fichiers sur un nouveau calque d’image. ( C’est détaillé plus bas avec deux exemples.)

4) N’utilisez pas une seule layer d’image – Pour utiliser efficacement le système de fichiers en layer, créez toujours votre propre couche d’image de base pour votre système d’exploitation, puis une couche pour la définition du nom d’utilisateur, une layer pour l’installation d’exécution, une autre pour la configuration , et enfin la layer application pour votre application. Ainsi il sera plus facile de recréer, gérer et diffuser votre image.

5) Ne créez pas d’images à partir de conteneurs en cours d’exécution (Idée de debutant?)- En d’autres termes, n’utilisez pas «docker commit» pour créer une image. Cette méthode pour créer une image n’est pas reproductible et doit être complètement prohibée. Utilisez toujours un Dockerfile ou toute autre approche S2I (source-image) totalement reproductible, et vous pouvez suivre les modifications apportées au Dockerfile si vous le stockez dans un référentiel de contrôle de source (git).

6) N’utilisez pas uniquement la balise « latest »sur une version stable- La balise « Latest » est equivalente à « SNAPSHOT » pour les utilisateurs de Maven. Les balises sont une bonne pratique du fait de la nature du système de fichiers en couches des conteneurs. Pour limiter les surprises lorsque vous construisez votre image quelques mois plus tard et qvous rendre compte que votre application ne peut pas s’exécuter car une couche parente (FROM dans Dockerfile) a été remplacée par une nouvelle version qui n’est pas rétrocompatible ou parce qu’une mauvaise La «dernière» version a été extraite du cache de compilation. La balise « latest » doit également être évitée lors du déploiement de conteneurs en production, car vous ne pouvez pas savoir quelle version de l’image est en cours d’exécution. Cependant si votre cycle le permet il est important de raffraichir vos CI/CD afin d’^étre au bon niveau de patch et de ne pas laisser trainer de CVE.

7) N’exécutez pas plus d’un processus dans un seul conteneur – Les conteneurs sont parfaits pour exécuter un seul processus (démon http, serveur d’applications, base de données), mais si vous avez plus d’un processus, vous risquez d’avoir plus de difficultés à gérer, récupérer les journaux et mettre à jour les processus individuellement.

8) Ne stockez pas les identifiants dans l’image. Utilisez des variables d’environnement – Vous ne souhaitez pas coder en dur un nom d’utilisateur / mot de passe dans votre image. Utilisez les variables d’environnement pour récupérer ces informations à l’extérieur du conteneur. Un bon exemple de ce principe est l’image Postgres.

9) N’exécutez pas de processus en tant qu’utilisateur root – « Par défaut, les conteneurs Docker s’exécutent en tant que root. À mesure que le docker mûrit, des options par défaut plus sécurisées sont disponibles. Utiliser root est dangereux pour les autres et souvent inutile, faite l’effort de contruire des containers rootleess. Votre image doit utiliser l’instruction USER pour spécifier un utilisateur non root pour les conteneurs à exécuter en tant que ”. ( Guidance for Docker Image Authors)

10) Ne vous fiez pas aux adresses IP – Chaque conteneur a sa propre adresse IP interne et cela pourrait changer si vous démarrez et arrêtez le conteneur. Si votre application ou microservice doit communiquer avec un autre conteneur, utilisez des variables d’environnement pour transmettre le nom d’hôte et le port appropriés d’un conteneur à un autre.

En savoir plus sur – https://developers.redhat.com/topics/kubernetes

Exemples : Comment garder sa légéreté ?

Commencons par illustrer le problème, par une image toute fraiche de Fedora: latest (ou RHEL). (Utilisez le fedora docker pull: latest à l’heure de cet article version 32).

Une fois terminé, l’exécution de la commande docker images, montre une taille d’image de 204,7 Mo. Nous allons maintenant créer une image personnalisée qui contient JDK 1.8 et WildFly 20.0.0.Final, à l’aide du Dockerfile suivant (créer votre dockerfile). https://github.com/FROMENT/tinydocker/blob/main/fedora31

La construction de cette image donne une taille finale de 671.16 MB, et en faisant un historique du docker pour voir la taille de chaque layer. JDK 1.8 représente 239.54 MB, et WildFly a ajouté 230.7 MB à la taille totale de l’image – c’est beaucoup d’espace!

De plus, s’il vous prent l’envie de créer une image WildFly 21.0.0.Final.

Si vous ne souhaitez pas réinstaller JDK 1.8, vous pourriez être tenté de réutiliser l’image existante en remplaçant WildFly 20.0.0.Final par 21.0.0.FINAL. Ce faisant, vous vous attendez probablement à ce que cette nouvelle image ait presque la même taille de 671.1MB, mais en fai la taille d’image résultante augmentera à 728,1 Mo. L’image aura augmenté de 239.63 MB même si vous supprimez WildFly 20.0.0.Final avant d’ajouter WildFly 21.0.0.FINAL dans l’image docker. La différence de taille n’est pas due aux différences entre les versions de WildFly mais aux traces laissées en fonction des modalité de construction.


Copier lors de l’écriture

Afin de comprendre ce comportement, nous devons comprendre que le système de fichiers du conteneur Docker utilise une technique de copie sur écriture qui améliore le temps de démarrage du conteneur (incroyablement rapide!).

En comparant les conteneurs aux machines virtuelles ordinaires. Bien que cette technique contribue de plusieurs manières à rendre les conteneurs docker efficaces, elle peut entraîner une utilisation supplémentaire du disque; ainsi, les auteurs d’images docker doivent prendre en compte plusieurs choses pour éviter de créer de grosses images.

Pour expliquer: chaque instruction RUN dans le Dockerfile écrit une nouvelle layer dans l’image. Chaque couche nécessite de l’espace supplémentaire sur le disque; par conséquent, lorsque nous «déplaçons» WildFly, nous créons en fait une nouvelle couche. Afin de garder le nombre de couches au minimum, toute manipulation de fichier comme le déplacement, l’extraction, la suppression, etc., doit idéalement être effectuée sous une seule instruction RUN.

La ligne suivante, par exemple, installe WildFly dans le conteneur, et les commandes de téléchargement, d’extraction, de déplacement et de nettoyage sont effectuées sur une seule ligne. Cela donne une taille finale de 569,1 Mo:

   "cd /tmp && \
        curl -O https://download.jboss.org/wildfly/$WILDFLY_VERSION/wildfly-$WILDFLY_VERSION.tar.gz && \
        tar xf wildfly-$WILDFLY_VERSION.tar.gz && \
        mv /tmp/wildfly-$WILDFLY_VERSION /opt/jboss/wildfly && \
        rm /tmp/wildfly-$WILDFLY_VERSION.tar.gz"
Maldives

Yum Update

Qu’en est-il de l’utilisation de la mise à jour par yum?
Pour mieux illustrer la réponse à cette question, deux images: fedora: 31 et fedora: 32. Ces deux images personnalisées ont la même instruction de mise à jour RUN dnf -y dans leurs fichiers Docker respectifs, mais le résultat est que ce fedora: 31 a une taille de 562MB, tandis que le plus récent fedora: 32 a une taille de 436MB.

Le container Fedora: 31 est plus volumineux car il a fallu télécharger beaucoup plus de fichiers pour la mettre «à jour» avec Fedora: 32. Ainsi, cet exemple démontre que l’exécution des dernières versions des plates-formes existantes (par exemple Fedora 32 au lieu de 31) peut non seulement accélérer la création d’images, mais aussi économiser de l’espace en empêchant l’écriture de fichiers supplémentaires sur une couche intermédiaire.

N’oubliez pas que les «mises à jour» déclenchent de nombreuses modifications de fichiers lors du téléchargement de nouveaux packages rpm et de leur installation. Comme expliqué précédemment, nous ne pouvons pas modifier les couches d’image précédentes, mais nous pouvons au moins nous débarrasser du cache rpm en une seule commande RUN. Avec une petite modification à RUN dnf -y update && dnf clean all dnf clean all </strong> , l’image est réduite de 358,2 Mo à 216,2 Mo (seulement 11,5 Mo de plus que le fedora original: 23 image). Donc, si vous avez besoin de faire une mise à jour, gardez à l’esprit que vous devez également nettoyer par la suite pour libérer autant d’espace que possible.

Article inspiré de Redhat.com
https://developers.redhat.com/blog/2016/03/09/more-about-docker-images-size/

Votre commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Commencez votre blog avec WordPress.com.

Retour en haut ↑

%d blogueurs aiment cette page :