Documentation : https://docs.docker.com/engine/reference/builder/
introduction du fichier docker
qu'est-ce que le fichier docker
Dockerfile est un fichier texte qui contient toutes les commandes pour créer une image. Il contient des instructions et des instructions. Chaque instruction crée une couche. Grâce à la commande docker build, l'image est construite en fonction du contenu du Dockerfile. Par conséquent, le contenu de chaque instruction décrit comment la couche est construite. Avec Dockerfile, vous pouvez formuler vos propres règles d'image Docker. Il vous suffit d'ajouter ou de modifier des instructions sur le Dockerfile pour générer une image Docker.
Quel problème Dockerfile résout-il ?
Dockerfile contient le processus opérationnel complet de production d'images. D'autres développeurs peuvent comprendre et reproduire le processus de production via Dockerfile. Chaque instruction dans Dockerfile créera une nouvelle couche d'image et ces images peuvent être mises en cache par Docker Daemon. Lors de la création d'une image à nouveau, Docker essaiera de réutiliser la couche d'image mise en cache (en utilisant le cache) au lieu de la construire couche par couche, ce qui peut économiser du temps et de l'espace disque. Le processus de fonctionnement du Dockerfile peut être interrogé via l'historique de l'image Docker [image nom] pour faciliter le développement. Afficher l'historique des modifications
processus de construction de Docker build
La commande docker build lira le contenu du Dockerfile et enverra le contenu du Dockerfile au moteur Docker. Enfin, le moteur Docker analysera chaque instruction du Dockerfile et construira l'image requise.
Dans la première étape, docker build empaquetera les fichiers dans le contexte et les transmettra au démon Docker. S'il y a des fichiers .dockerignore dans le contexte, les fichiers qui satisfont aux règles .dockerignore seront supprimés de la liste de téléchargement. Remarque : S'il y a un certain nombre de fichiers dans le contexte, l'ensemble du processus d'envoi de fichiers peut être clairement ressenti.
Il y a une exception ici. S'il y a .dockerignore ou Dockerfile dans le fichier .dockerignore, la commande docker build ignorera ces deux fichiers lors de l'exclusion de fichiers. Si la balise d'image est spécifiée, le référentiel et la balise seront également vérifiés.
La deuxième étape, la commande docker build envoie une requête HTTP au serveur Docker, demandant au serveur Docker de créer l'image. La requête contient le contexte requis information.
La troisième étape, une fois que le serveur Docker aura reçu la demande de build, il exécutera le processus suivant pour créer l'image :
1. Créez un répertoire temporaire et extrayez les fichiers en contexte dans ce répertoire.
2. Lisez et analysez le Dockerfile, parcourez les instructions qu'il contient et distribuez-les à différents modules pour exécution en fonction du type de commande.
3. Le moteur de construction Docker crée un conteneur temporaire pour chaque instruction, exécute l'instruction dans le conteneur temporaire, puis valide le conteneur pour générer une nouvelle couche d'image.
4. Enfin, fusionnez les calques d'image construits par toutes les instructions pour former le résultat final de la construction. L'ID d'image généré par le dernier commit est l'ID d'image final.
Afin d'améliorer l'efficacité de la construction, Docker build mettra en cache les couches d'images existantes par défaut. S'il s'avère qu'une certaine couche d'image a été mise en cache lors de la création de l'image, l'image mise en cache sera utilisée directement sans reconstruction. Si vous ne souhaitez pas utiliser l'image mise en cache, vous pouvez spécifier le paramètre --no-cache=true lors de l'exécution de la commande docker build.
Les règles de Docker pour faire correspondre les images mises en cache sont les suivantes : parcourir l'image de base et ses sous-images dans le cache, et vérifier si les instructions de construction de ces images sont exactement les mêmes que les instructions actuelles. Si elles ne sont pas les mêmes, le cache ne correspondre. Pour les instructions ADD et COPY, la somme de contrôle du fichier sera également utilisée pour déterminer si les fichiers ajoutés à l'image sont identiques. S'ils ne sont pas identiques, cela signifie que le cache ne correspond pas. Notez ici que la vérification de correspondance du cache ne vérifie pas les fichiers dans le conteneur. Par exemple, lors de l'utilisation de la commande RUN apt-get -y update pour mettre à jour les fichiers dans le conteneur, la stratégie de cache ne vérifiera pas ces fichiers pour déterminer si le cache correspond. Enfin, vous pouvez afficher l'historique de construction de l'image via la commande docker history.
Mots clés
FROM 设置镜像使用的基础镜像
MAINTAINER 设置镜像的作者
RUN 编译镜像时运行的脚步
CMD 设置容器的启动命令
LABEL 设置镜像标签
EXPOSE 设置镜像暴露的端口
ENV 设置容器的环境变量
ADD 编译镜像时复制上下文中文件到镜像中
COPY 编译镜像时复制上下文中文件到镜像中
ENTRYPOINT 设置容器的入口程序
VOLUME 设置容器的挂载卷
USER 设置运行 RUN CMD ENTRYPOINT的用户名
WORKDIR 设置 RUN CMD ENTRYPOINT COPY ADD 指令的工作目录
ARG 设置编译镜像时加入的参数
ONBUILD 设置镜像的ONBUILD 指令
STOPSIGNAL 设置容器的退出信号量pratique du fichier docker
Pratique de grammaire de base
mkdir example
cd examplefichier Docker vim
FROM golang
ENV env1=env1value
ENV env2=env2value
MAINTAINER zloser
# 仅指定镜像元数据内容
LABEL hello 1.0.0
RUN git clone https://gitee.com/nickdemo/helloworld.git
WORKDIR helloworld
RUN go env -w GOPROXY=https://proxy.golang.com.cn,https://goproxy.cn,direct
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .
EXPOSE 80
CMD ["./app","--param1=p1","--param2=p2"]
docker build -t hello:1.0.0 -f Dockerfile .
docker run -p 80:80 -d --name hello hello:1.0.0Construire avec succès :
contexte de construction Docker
1. Préparation du matériel
# 创建一个目录，案例需要
mkdir example2
cd example2
# 下载nginx源码包，作为案例素材
curl https://nginx.org/download/nginx-1.21.6.tar.gz > ./nginx-1.21.6.tar.gz
# 下载app代码
git clone https://gitee.com/nickdemo/helloworld# ./nginx*
# helloworld
2. Contexte inutile
FROM golang
ENV env1=env1value
ENV env2=env2value
MAINTAINER zloser
# 仅指定镜像元数据内容
LABEL hello 1.0.0
RUN git clone https://gitee.com/nickdemo/helloworld.git
WORKDIR helloworld
RUN go env -w GOPROXY=https://proxy.golang.com.cn,https://goproxy.cn,direct
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .
EXPOSE 80
CMD ["./app","--param1=p1","--param2=p2"]# 调整为不同的上下文，查看不同的效果
docker build -t hello:1.0.0 -f Dockerfile .
3. Le véritable rôle du contexte
FROM golang:1.18
ENV env1=env1value
ENV env2=env2value
MAINTAINER zloser
LABEL hello 1.0.0
COPY ./helloworld /go/src/helloworld
WORKDIR /go/src/helloworld
RUN go env -w GOPROXY=https://proxy.golang.com.cn,https://goproxy.cn,direct
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .
EXPOSE 80
CMD ["./app","--param1=p1","--param2=p2"]docker build -t hello:1.0.0 -f Dockerfile .Action :
1. Essayez d'ignorer les différents contenus du fichier .dockerignore et observez les données envoyées au démon
2. Essayez d'utiliser chemin de contexte différent pour créer l'image
3. Essayez de copier le contenu en dehors du contexte pour créer l'image
Construction en plusieurs étapes
Après Docker version 17.05, la construction en plusieurs étapes Dockerfile est ajoutée. La construction dite en plusieurs étapes permet en fait à plusieurs instructions FROM d'apparaître dans un Dockerfile. Quel est l'intérêt de faire ça ? L'importance de plusieurs instructions FROM Les instructions FROM multiples ne sont pas destinées à générer des relations de couches multi-racines. L'image finale générée est toujours basée sur le dernier FROM. Le FROM précédent sera ignoré, alors quelle est la signification du FROM précédent ? Chaque instruction FROM est une étape de construction, et plusieurs instructions FROM sont des constructions en plusieurs étapes. Bien que l'image finale générée ne puisse être que le résultat de la dernière étape, les fichiers de l'étape précédente peuvent être copiés vers les étapes ultérieures. Il s'agit de la meilleure solution. importance de la construction en plusieurs étapes. Le scénario d'utilisation le plus important consiste à séparer l'environnement de compilation et l'environnement d'exécution. Par exemple, si nous avions besoin de créer un programme en langage Go auparavant, nous aurions besoin d'utiliser la commande go et d'autres environnements de compilation.
AJOUTER et COPIER
1. ADD et COPY ne peuvent pas copier de fichiers en dehors du contexte
2. Format de syntaxe de la commande COPY
COPY <src> <dest> //将上下文中源文件，拷贝到目标文件
COPY prefix* /destDir/ //将所有prefix 开头的文件拷贝到 destDir 目录下
COPY prefix?.log /destDir/ //支持单个占位符，例如 ： prefix1.log、prefix2.log 等3. Pour les répertoires, les commandes COPY et ADD ont les mêmes caractéristiques : copier uniquement le contenu du répertoire sans inclure le répertoire lui-même.
COPY srcDir /destDir/ //只会将源文件夹srcDir下的文件拷贝到 destDir 目录下4. La différence entre COPY et ADD réside dans l'utilisation de plusieurs étapes dans Dockerfile
5. Syntaxe de la commande ADD
ADD <src> <dest>Sauf que la commande ADD ne peut pas être utilisée dans des scénarios à plusieurs étapes, la commande ADD peut compléter toutes les fonctions de la commande COPY, et peut également remplir deux types de fonctions :
a. Décompressez le fichier compressé et ajoutez-le à l'image. Pour les fichiers compressés locaux sur l'hôte, la commande ADD les décompressera automatiquement et les ajoutera à l'image
b. Copiez le fichier de l'URL vers le image. Remarque : Si le fichier où se trouve l'URL est un package compressé, la commande ADD ne sera pas automatiquement décompressée
CMD et POINT D'ENTRÉE
CMD
La commande CMD a trois formats
# shell 格式
CMD <command>
# exec格式，推荐格式
CMD ["executable","param1","param2"]
# 为ENTRYPOINT 指令提供参数
CMD ["param1","param2"]
1. L'instruction CMD fournit des valeurs par défaut lorsque le conteneur est en cours d'exécution. Ces valeurs par défaut peuvent être une instruction ou certains paramètres.
2. Il peut y avoir plusieurs instructions CMD dans un fichier docker, mais seule la dernière instruction CMD est valide.
3. Le format des paramètres CMD est utilisé lorsque l'instruction CMD est combinée avec l'instruction ENTRYPOINT. Les paramètres de l'instruction CMD seront ajoutés à l'instruction ENTRYPOINT.
4. Lors de l'utilisation des formats shell et exec, la commande est exécutée dans le conteneur de la même manière que l'instruction RUN. La différence est que l'instruction RUN exécute la commande lors de la construction de l'image et génère une nouvelle image.
5. La commande CMD n'exécute aucune commande lors de la construction de l'image. Au lieu de cela, la commande CMD est utilisée comme première commande à exécuter par défaut au démarrage du conteneur. Si vous spécifiez des paramètres de commande lors de l'exécution de la commande docker run sur l'interface de ligne de commande, la commande dans l'instruction CMD sera écrasée.
ENTRYPOINT
La commande ENTRYPOINT a deux formats
# shell 格式
ENTRYPOINT <command>
# exec 格式，推荐格式
ENTRYPOINT ["executable","param1","param2"]1. L'instruction ENTRYPOINT est similaire à l'instruction CMD. Elles permettent toutes deux au conteneur d'exécuter la même commande à chaque démarrage, mais il existe des différences entre elles. Il peut y avoir plusieurs instructions ENTRYPOINT dans un Dockerfile, mais seule la dernière instruction ENTRYPOINT est valide.
2. Lors de l'utilisation du format shell, la commande ENTRYPOINT ignorera les paramètres de commande CMD et de commande docker run, et s'exécutera dans bin/sh -c.
3. Il est recommandé d'utiliser le format exec. En utilisant ce format, les paramètres de commande passés dans docker run écraseront le contenu de la commande CMD et seront ajoutés aux paramètres de la commande ENTRYPOINT.
4. CMD peut être un paramètre ou une instruction, et ENTRYPOINT ne peut être qu'une commande ; les paramètres de commande en cours fournis par la commande docker run peuvent remplacer CMD, mais pas ENTRYPOINT.
5. Vous pouvez remplacer le programme d'entrée du conteneur via docker run --entrypoint
construire un argument
1. paramètres prédéfinis du dockerfile : HTTP_PROXY, http_proxy, HTTPS_PROXY, https_proxy, FTP_PROXY, ftp_proxy, NO_PROXY, no_proxy, ALL_PROXY, all_proxy. Les paramètres prédéfinis peuvent être utilisés directement dans le fichier docker sans utiliser arg pour déclarer
2. Personnaliser les paramètres via ARG
FROM alpine:latest as s1
ARG wd label tag
RUN echo $wd,$label,$tag
ENV env1=env1value
ENV env2=env2value
MAINTAINER zloser
LABEL $label $tag
WORKDIR $wd
COPY --from=stage0 /go/src/helloworld/app ./
EXPOSE 80
ENTRYPOINT ["./app","--param1=p1","--param2=p2"]cible et cache depuis
Pour les builds en plusieurs étapes, vous pouvez spécifier les étapes qui doivent être reconstruites via --target. --cache-from peut spécifier une image comme source de cache. Lorsque l'instruction dockerfile correspond à l'instruction source de l'image de cache pendant le processus de construction, la couche d'image dans l'image de cache sera utilisée directement pour accélérer le processus de construction. L'image mise en cache peut être poussée vers le centre d'enregistrement distant pour être utilisée dans différents processus de construction. Elle doit être extraite localement avant utilisation.
surconstruction
La directive onbuild ajoute des instructions à l'image qui déclencheront l'exécution lorsque l'image sera utilisée comme image de base pour une autre build. Les instructions de déclenchement seront exécutées dans le contexte du build en aval. Remarque : la directive onbuild n'affectera pas la version actuelle, mais affectera les versions en aval.