English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Dockerfile est un fichier texte utilisé pour construire des images, qui contient une série d'instructions et de descriptions nécessaires pour construire des images.
Personnalisation d'image avec Dockerfile
1、Ici, nous expliquons comment exécuter le fichier Dockerfile pour personnaliser une image (les instructions détaillées du fichier Dockerfile seront présentées dans le prochain chapitre, ici vous devez seulement savoir le processus de construction). /usr/share/nginx/html/index.html Fichier)
Dans un répertoire vide, créez un fichier Dockerfile nommé et ajoutez le contenu suivant :
FROM nginx RUN echo 'Ceci est une image nginx construite localement' > /usr/share/nginx/html/index.html
2、Les fonctions des instructions FROM et RUN
FROM：Toutes les images personnalisées sont basées sur l'image FROM, ici nginx est l'image de base nécessaire pour la personnalisation. Les opérations suivantes sont basées sur nginx.
RUN：Utilisé pour exécuter les commandes en ligne suivantes. Il existe deux formats :
Format shell :
RUN <commande en ligne> # <commande en ligne> équivaut à la commande shell opérée dans le terminal.
Format exec :
RUN ["fichier exécutable", "paramètres1", "paramètres2"] # Par exemple : # RUN ["./test.php", "dev", "offline"] équivaut à RUN ./test.php dev offline
Attention：Chaque instruction du Dockerfile exécutée crée une nouvelle couche sur docker. Par conséquent, trop de couches sans signification peuvent entraîner une image trop volumineuse. Par exemple :
FROM centos RUN yum install wget RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" RUN tar -xvf redis.tar.gz L'exécution ci-dessus créera 3 Couche d'image. Elle peut être simplifiée au format suivant : FROM centos RUN yum install wget \ && wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \ && tar -xvf redis.tar.gz
Comme indiqué ci-dessus, reliez les commandes avec le symbole &&, de sorte que, après l'exécution, seules 1 Couche d'image.
Exécuter l'action de construction dans le répertoire contenant le fichier Dockerfile.
Dans cet exemple, construire un nginx:v3(Nom du miroir : étiquette du miroir).
Remarque: Le dernier point . représente le chemin de contexte de cette exécution, qui sera présenté dans la section suivante.
$ docker build -t nginx:v3 .
Comme indiqué ci-dessus, cela signifie que la construction a réussi.
Dans la section précédente, il a été mentionné que le dernier point . de l'instruction est le chemin de contexte, alors qu'est-ce que le chemin de contexte ?
$ docker build -t nginx:v3 .
: Le chemin de contexte, c'est-à-dire que Docker construit l'image, parfois il est nécessaire d'utiliser les fichiers de notre machine (par exemple, copier), après que la commande docker build ait connaissance de ce chemin, elle enveloppera tout le contenu de ce chemin.
Analyse: En raison du mode de fonctionnement de Docker C/S. Notre machine est C, l'engine Docker est S. Le processus de construction réel est effectué sous l'engine Docker, donc à ce moment-là, nous ne pouvons pas utiliser les fichiers de notre machine. Cela nécessite de fournir ensemble les fichiers du répertoire spécifique de notre machine au moteur Docker.
Si le dernier paramètre n'est pas spécifié, le chemin de contexte par défaut est l'emplacement du Dockerfile.
Attention: Ne placez pas de fichiers inutiles dans le chemin de contexte, car ils seront envoyés ensemble à l'engine Docker, et un grand nombre de fichiers peut ralentir le processus.
Commande de copie, copie des fichiers ou des répertoires du répertoire de contexte vers le chemin spécifié dans le conteneur.
Format :
COPY [--chown=<user>:<group>] <chemin_source1>... <chemin_cible> COPY [--chown=<user>:<group>] ["<chemin_source1>",... "<chemin_cible>"]
[--chown=<user>:<group>]: paramètre optionnel, l'utilisateur peut changer l'utilisateur et le groupe propriétaire du fichier copié dans le conteneur.
<chemin_source>: fichier source ou répertoire source, ici cela peut être une expression de correspondance de wildcard, les règles de wildcard doivent respecter les règles de filepath.Match de Go. Par exemple :
COPY hom* /mydir/ COPY hom?.txt /mydir/
<chemin_cible>: le chemin spécifié dans le conteneur, ce chemin n'a pas besoin d'être créé à l'avance, s'il n'existe pas, il sera créé automatiquement.
La syntaxe d'utilisation de l'instruction ADD est identique à celle de COPY (l'officialisation recommande l'utilisation de COPY). Les fonctionnalités sont similaires, mais les différences sont les suivantes :
Les avantages de ADD : si <fichier_source> est un fichier compressé tar, le format de compression est gzip, bzip.2 Et dans le cas de xz, il copiera automatiquement et décompressera dans <chemin_cible>.
Les inconvénients de ADD : sans décompression, il est impossible de copier les fichiers compressés au format tar. Cela peut rendre le cache de construction d'image obsolète, ce qui pourrait ralentir la construction de l'image. La décision de son utilisation peut être prise en fonction de la nécessité d'une décompression automatique.
Similaire à l'instruction RUN, utilisé pour exécuter un programme, mais les deux s'exécutent à des moments différents:
CMD est exécuté lors de docker run.
RUN est utilisé pendant docker build.
Fonction：Spécifie le programme par défaut à exécuter dans le conteneur. Lorsque le programme spécifié par l'instruction CMD s'arrête, le conteneur se termine également. Le programme spécifié par l'instruction CMD peut être couvert par le programme spécifié en tant que paramètre de ligne de commande de docker run.
Attention：Si plusieurs instructions CMD existent dans le Dockerfile, seule la dernière est effective.
Format :
CMD <commande shell> CMD ["<executable> ou commande","<param1>","<param2>",...] CMD ["<param1>","<param2>",...] # Cette écriture fournit des paramètres par défaut pour le programme spécifié par l'instruction ENTRYPOINT
Il est recommandé d'utiliser le deuxième format, qui est plus clair dans le processus d'exécution. Le premier format se convertira automatiquement en deuxième format pendant le processus d'exécution et le fichier exécutable par défaut est sh.
similaire à la commande CMD, mais qui ne sera pas couverte par les arguments en ligne spécifiés par docker run, et ces arguments en ligne seront passés en tant que paramètres à la commande spécifiée par l'ENTRYPOINT.
Mais, si vous utilisez docker run avec --L'option entrypoint couvre l'instruction CMD spécifiée.
Avantages：Lors de l'exécution de docker run, vous pouvez spécifier les arguments nécessaires à l'ENTRYPOINT.
Attention：Si plusieurs instructions ENTRYPOINT existent dans le Dockerfile, seule la dernière est effective.
Format :
ENTRYPOINT ["<executable>","<param1>","<param2>",...]
Il peut être utilisé avec la commande CMD : généralement, la commande CMD est utilisée pour les arguments variables, ici CMD est utilisé pour transmettre des arguments à l'ENTRYPOINT, les exemples suivants seront mentionnés.
Exemple :
Supposons que l'image nginx:test ait été construite via un Dockerfile :
FROM nginx ENTRYPOINT ["nginx", "-c"] # arguments fixes CMD ["/etc/nginx/nginx.conf"] # arguments variables
1et sans arguments
$ docker run nginx:test
Le conteneur exécutera par défaut les commandes suivantes pour démarrer le processus principal.
nginx -c /etc/nginx/nginx.conf
2et avec des arguments
$ docker run nginx:test -c /etc/nginx/new.conf
Le conteneur exécutera par défaut les commandes suivantes pour démarrer le processus principal (/etc/nginx/new.conf: supposons que le fichier existe déjà dans le conteneur)
nginx -c /etc/nginx/new.conf
Définir les variables d'environnement, après la définition des variables d'environnement, elles peuvent être utilisées dans les instructions suivantes.
Format :
ENV <key> <value> ENV <key1>=<value1> <key2>=<value2>...
Exemple de configuration de NODE_VERSION = 7.2.0 ， il peut être mentionné par $NODE_VERSION dans les instructions suivantes :
ENV NODE_VERSION 7.2.0 RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \ && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc"
Paramètres de construction, agissent de la même manière que ENV. Cependant, leur portée est différente. Les variables d'environnement définies par ARG ne sont valides que dans Dockerfile, c'est-à-dire qu'elles ne sont valides que pendant le processus de construction de l'image, et ne sont pas présentes dans l'image construite.
La commande de construction docker build peut utiliser --build-arg <nom du paramètre>=<valeur> pour le remplacer.
Format :
ARG <nom du paramètre>[=<valeur par défaut>]
Définir un volume de données anonyme. Si vous oubliez de monter le volume de données au lancement du conteneur, il sera automatiquement monté sur le volume anonyme.
Fonction :
Éviter que des données importantes ne soient perdues lors du redémarrage du conteneur, ce qui est extrêmement fatal.
Éviter que le conteneur ne devienne trop grand.
Format :
VOLUME ["<chemin1>", "<chemin2>"...] VOLUME <chemin>
Lors du lancement du conteneur docker run, nous pouvons utiliser -v Paramètre pour modifier le point de montage.
Déclarer simplement le port.
Fonction :
Aider les utilisateurs de l'image à comprendre le port de surveillance du service de l'image, pour faciliter la configuration de la redirection.
Lors de l'utilisation de la redirection de port aléatoire en temps de runtime, c'est-à-dire docker run -Lorsque P est utilisé, le port EXPOSE sera automatiquement mappé de manière aléatoire.
Format :
EXPOSE <port1> [<port2>...]
Spécifier le répertoire de travail. Le répertoire de travail spécifié par WORKDIR existera dans chaque couche de construction de l'image. (Le répertoire de travail spécifié par WORKDIR doit déjà être créé).
Dans le processus de construction de l'image Docker, chaque commande RUN est une nouvelle couche. Seul le répertoire créé par WORKDIR reste en existence.
Format :
WORKDIR <chemin du répertoire de travail>
Utilisé pour spécifier l'utilisateur et le groupe d'utilisateurs qui exécuteront les commandes suivantes, ici il s'agit simplement de basculer l'utilisateur pour l'exécution des commandes suivantes (l'utilisateur et le groupe d'utilisateurs doivent déjà exister).
Format :
USER <nom_d'utilisateur>[:<groupe_utilisateur>]
Utilisé pour spécifier un programme ou une instruction pour surveiller l'état de fonctionnement du service de conteneur Docker.
Format :
HEALTHCHECK [options] CMD <commande> : Définir la commande pour vérifier l'état de santé du conteneur HEALTHCHECK NONE : Si l'image de base a des instructions de vérification de santé, vous pouvez utiliser cette ligne pour masquer les instructions de vérification de santé HEALTHCHECK [options] CMD <commande> : Les commandes suivantes CMD peuvent être utilisées après CMD, vous pouvez vous référer à l'utilisation de CMD.
Utilisé pour retarder l'exécution des commandes de construction. En d'autres termes, les commandes spécifiées par ONBUILD dans le Dockerfile ne seront pas exécutées lors de la construction de l'image (hypothèse : l'image est test)-build). Lorsqu'un nouveau Dockerfile utilise l'image précédemment construite FROM test-build, c'est-à-dire que lors de la construction du Dockerfile pour créer une nouvelle image, le test sera exécuté-Les commandes spécifiées par ONBUILD dans le Dockerfile de build. C'est-à-dire que lors de la construction du Dockerfile, les commandes spécifiées par ONBUILD ne seront pas exécutées (hypothèse : l'image est test)
Format :
ONBUILD <autres instructions>