Je pense qu'il y a deux façons d'installer une dépendance dans Dockerfile:
1) dans Dockerfile:
RUN ./install.sh
2) mettre "yum install xxx" dans un script install.sh et dans Dockerfile
RUN yum install xxx
Les deux semblent fonctionner, juste errer est-il meilleur que l'autre?
3 Réponses :
Docker créera une image pour chaque Instruction sur votre Dockerfile mais si une image a été créée avec cette Instruction déjà, il utilisera cette image à la place.
Ainsi, lorsque vous avez plusieurs Instructions sur votre Dockerfile pour créer votre image, il est important d'organiser vos Instructions de manière à réduire le nombre d'images intermédiaires.
Je pense donc que si vous mettez toutes vos Instructions dans un seul fichier, vous aurez peut-être moins d'images intermédiaires. Mais notez également que toute modification future de ce fichier entraînera la création d'une nouvelle image intermédiaire car il n'y a rien de déjà créé pour être utilisé qui ralentira le temps de création de l'image.
Si vous créez des images Docker, utilisez ce qui suit dans le Dockerfile et non le script pour installer les packages et ses dépendances.
RUN yum -y update && \ miam -y installer .. && \ miam nettoie tout
Utilisez le script shell personnalisé pour exécuter le ou les services spécifiques à l'application dans ENTRYPOINT dans le Dockerfile.
Utilisez les instructions pour ajouter / installer des packages dans une commande RUN pour réduire les couches d'image intermédiaires.
Il est bon d'utiliser le script shell pour installer les packages et ses dépendances pour les images non conteneurs / images non docker pour automatiser le processus pour les applications basées sur VM.
Il n'y a pratiquement aucune différence entre les options offertes. Si vous insistez, je peux vous faire une petite différence:
1. La sortie de deux images a un nombre différent de calques et une petite différence de taille:
Un exemple simple comme suit:
Dockerfile:
$ docker history trial:1 IMAGE CREATED CREATED BY SIZE COMMENT f86f153f9d95 12 minutes ago |0 /bin/sh -c yum install -y net-tools 105MB 9f38484d220f 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B <missing> 3 months ago /bin/sh -c #(nop) LABEL org.label-schema.sc… 0B <missing> 3 months ago /bin/sh -c #(nop) ADD file:074f2c974463ab38c… 202MB $ docker history trial:2 IMAGE CREATED CREATED BY SIZE COMMENT 775be0061903 10 minutes ago |0 /bin/sh -c ./install.sh 105MB b7ca1d2a7e8b 10 minutes ago /bin/sh -c #(nop) ADD file:6f96562be8deac728… 25B 9f38484d220f 3 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B <missing> 3 months ago /bin/sh -c #(nop) LABEL org.label-schema.sc… 0B <missing> 3 months ago /bin/sh -c #(nop) ADD file:074f2c974463ab38c… 202MB
Commande de construction:
$ docker build -t trial:2 . --no-cache
Dockerfile:
yum install -y net-tools
install.sh:
FROM centos:7 ADD install.sh . RUN ./install.sh
Commande de construction:
$ docker build -t trial:1 . --no-cache
FROM centos:7 RUN yum install -y net-tools
D'en haut, vous pouvez voir si vous utilisez ./install.sh , vous devrez avoir une instruction ADD dans Dockerfile . Par rapport à l'option 1, cela augmentera un calque d'image d'environ 20B pour votre image finalement générée.
2. Limite maximale du calque d'image:
Voir cette discussion , le maximum de calques d'image du docker est de 127, donc si vous dans une situation particulière, quelle image de base ou votre image utilise déjà trop de calques, cela peut être utile.
3. Efficacité de la copie de fichiers d'un hôte à un autre:
ADD doit copier le fichier de l'hôte du docker vers le conteneur. En interne, docker build créera un fichier tar du répertoire context, l'envoyant au démon docker et le décompressera. La question sera donc de savoir pourquoi nous en avons besoin si nous pouvions le faire directement dans Dockerfile?
Mais vous souciez-vous vraiment du 20B , une couche de plus et un peu de vitesse de COPIE? Je suppose qu'à moins que dans certaines situations très simples, il n'y a pas de différence pour les 2 options.
Cependant, il semble que installer le package directement dans Dockerfile est le plus le choix des gens, car les gens peuvent se demander pourquoi je devrais faire des efforts pour maintenir un install.sh si cela ne m'a apporté aucun avantage.
Merci pour toutes les informations! Je dirais que le script install.sh est beaucoup plus portable et réutilisable, surtout si j'ai déjà un tel script fonctionnel à partir d'un environnement non-docker?
Oui, si vous avez une raison précise comme vous l'avez dit, vous pouvez l'utiliser car cela ne cause pas de grande différence par rapport à l'écrire dans dockerfile pour la plupart des situations.
Cela n’a vraiment pas d’importance. Le script shell peut être plus facile à tester en dehors de Docker; le formulaire en ligne peut être plus facile à lire.