[Série Docker] Présentation de Dockerfile

Afin d'avoir rapidement une compréhension préliminaire de Dockerfile, regardons d'abord un exemple simple

Tout d'abord, nous tirons une image mysql: 5.7 de l'entrepôt miroir, nous démarrons le conteneur et entrons dans le conteneur, mais lorsque nous voulons envoyer un ping à une certaine adresse IP, nous constatons qu'il n'y a pas de commande ping
Insérez la description de l'image ici

Si nous avons ce besoin, ce serait très embarrassant, que peut-on faire pour le résoudre?
Nous pouvons reconstruire une nouvelle image basée sur mysql: 5.7 et ajouter ce que nous voulons; jetons un œil au contenu du Dockerfile suivant

FROM mysql:5.7

RUN apt-get update \
&& apt install iputils-ping -y

RUN apt-get install vim -y

Ici, nous avons installé les outils ping et vim (notez que vous devez afficher les informations de version via cat / etc / issue, et les commandes des outils d'installation sont différentes pour les différentes versions)

Commençons par construire avec ce Dockerfile :docker build -t mysql:mumu .
Insérez la description de l'image ici

Nous pouvons voir que le processus de construction est divisé en trois étapes, qui correspondent aux trois commandes de notre Dockerfile. Une
fois la construction terminée, nous pouvons voir qu'il est plus grand de 53 Mo que mysql: 5.7
Insérez la description de l'image ici

Une fois l'image jouée, nous pouvons démarrer le conteneur:
docker run -p 3306:3306 --name mysql -v /data/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql:mumu
Après le démarrage, nous pouvons envoyer un ping à www.baidu.com, et nous pouvons voir que nos outils sont normalement disponibles
Insérez la description de l'image ici

Dans le cas ci-dessus, avons-nous une compréhension préliminaire de
Dockerfile : Dockerfile est un Dockerfile utilisé pour créer un miroir.
Une instruction correspond à une étape.
Grâce au Dockerfile et au miroir de base, nous pouvons créer un miroir plus conforme à nos exigences.

Nous utilisons un autre Dockerfile pour comprendre le concept de superposition d'images:

FROM debian
RUN apt-get update && apt-get -y -f install emacs
RUN apt-get update && apt-get -y -f install apache2

Chaque instruction du Dockerfile est une nouvelle couche, couche par couche, et constitue enfin l'image que nous voulons
Insérez la description de l'image ici

Par exemple, la commande ci-dessus créera trois couches, chaque couche n'enregistrant que les modifications apportées à cette couche, et celles-ci sont en lecture seule. Lorsqu'un conteneur est démarré, Docker ajoute une couche de lecture-écriture en haut, généralement appelée couche de conteneur.
Insérez la description de l'image ici

Chaque conteneur a sa propre couche de conteneur indépendante, la modification n'aura donc que sa propre couche de conteneur, et il n'y a pas d'impact entre les conteneurs. De cette manière, différents conteneurs peuvent partager une couche de mise en miroir.
Insérez la description de l'image ici

Pourquoi utiliser une structure hiérarchique?
Le plus grand avantage est le partage des ressources. Par exemple, de nombreux miroirs sont construits à partir de miroirs de base. Une fois que nous avons enregistré une copie sur le disque, elle peut être partagée par tous les miroirs.

Mais par exemple, certaines personnes ont des questions. Si ce conteneur dérivé d'image modifie les fichiers qu'il contient, par exemple, si un fichier sous / opt est modifié, le / opt des autres conteneurs sera-t-il également modifié?
Nous avons mentionné plus haut que la couche conteneur est indépendante de chaque conteneur. Les données modifiées seront stockées directement dans la couche conteneur, et la couche image restera inchangée.

Introduction à l'instruction Dockerfile

FROM: Spécifiez l'image de base, doit être la première commande
FROM:
FROM @
Exemple:
FROM elasticsearch: 7.6.0
Remarque: la balise et le condensé sont facultatifs, s'ils sont vides, la dernière version de l'image de base sera utilisée automatiquement

MAINTAINER: informations mainteneur
MAINTAINER
exemple:
MAINTAINER mumu
MAINTAINER [email protected]
MAINTAINER [email protected]

RUN: La commande exécutée lors de la construction de l'image
RUN
RUN ["executable", "param1", "param2"]
Exemple:
RUN apk update
RUN ["./test", "dev", "offline"]
Remarque: Créé par le Instruction RUN L'image intermédiaire sera mise en cache et utilisée dans la prochaine construction. Si vous ne souhaitez pas utiliser ces images de cache, vous pouvez utiliser le paramètre –no-cache lors de la construction de la construction, tel que: docker build --no-cache

AJOUTER: Ajoutez des fichiers locaux au conteneur, les fichiers tar seront automatiquement décompressés (les ressources réseau compressées ne seront pas décompressées), vous pouvez accéder aux ressources réseau, similaire à l' exemple wget
ADD
:
ADD mumu.txt / mydir /
Remarque: COPY: similaire dans fonction ADD, mais il ne décompresse pas automatiquement le fichier et ne peut pas non plus accéder aux ressources réseau

CMD: appelé après la création du conteneur, c'est-à-dire qu'il est appelé au démarrage du conteneur.
CMD ["executable", "param1", "param2"]
CMD ["param1", "param2"]
Exemple de commande CMD param1 param2 (commande interne du shell)
:
CMD ["java", "-jar", "/ opt / server / product.jar "]
Remarque: CMD est différent de RUN. CMD est utilisé pour spécifier la commande à exécuter lorsque le conteneur est démarré et RUN est utilisé pour spécifier la commande à exécuter lors de la création de l'image; chaque Dockerfile ne peut avoir qu'une seule commande CMD Si plusieurs commandes sont spécifiées, seule la dernière sera exécutée. Si l'utilisateur spécifie une commande d'exécution lors du démarrage du conteneur, la commande spécifiée par CMD sera écrasée.

ENTRYPOINT: Configurez le conteneur pour le rendre exécutable. Avec CMD, l'application peut être omise et seuls les paramètres sont utilisés.
ENTRYPOINT ["executable", "param1", "param2"]
Commande ENTRYPOINT param1 param2 (commande interne du shell)
Exemple:
ENTRYPOINT ["/ bin / echo", "hello"]
Remarque: ENTRYPOINT est très similaire à CMD, mais docker exécute exécution La commande ne remplacera pas ENTRYPOINT, mais si docker run utilise l'option -entrypoint, le paramètre de cette option peut être utilisé comme programme à exécuter pour remplacer le programme spécifié par l'instruction ENTYPPOINT, et tous les paramètres spécifiés dans le docker run La commande sera traitée comme des paramètres. Passez-la à nouveau à ENTRYPOINT; une seule commande ENTRYPOINT est autorisée dans DockerFile, et si plus d'une est spécifiée, la précédente sera écrasée et seule la dernière sera exécutée.
Lorsque ENTRYPOINT est spécifié, la signification de CMD change. Ce n'est plus une commande directe, mais le contenu de CMD est passé en paramètre à l'instruction ENTRYPOINT, c'est-à-dire qu'il deviendra "" lorsqu'il sera effectivement exécuté.

N'est-ce pas un peu confus ici, quel est le lien entre CMD et ENTRYPOINT?
Dans Dockerfile, au moins un CMD et ENTRYPOINT doivent être spécifiés;
lorsque Docker est utilisé comme programme exécutable, ENTRYPOINT doit être utilisé pour la configuration;
CMD peut être utilisé comme paramètre par défaut de ENTRYPOINT, ou comme commande par défaut de Docker;
CMD peut être transmis par docker run Couverture des paramètres;
les paramètres transmis par docker run seront ajoutés à ENTRYPOINT, à condition que le format exec soit utilisé

Par exemple, le Dockerfile est le suivant
FROM nginx
ENTRYPOINT ["nginx", "-c"]
CMD ["/etc/nginx/nginx.conf"]
Lorsque nous activons nginx: docker run nginx: mumu
équivaut à exécuter ce qui suit commande: nginx -c /etc/nginx/nginx.conf
Lorsque nous changeons la commande de démarrage en: docker run nginx: mumu -c /etc/nginx/new.conf
équivaut à exécuter la commande suivante: nginx -c / etc / nginx / nouveau. conf

LABEL: Utilisé pour ajouter des métadonnées à l'image miroir
LABEL == =
Exemple:
LABEL version = "1.0" descriptioin = "Ceci est un service de Mumu"
Remarque: Lorsque vous utilisez LABEL pour spécifier des métadonnées, un LABEL peut spécifier un ou plusieurs éléments de métadonnées, séparées par des espaces. Il est recommandé de spécifier toutes les métadonnées via une commande LABEL pour éviter de générer trop d'images intermédiaires.

ENV: Définir la variable d'environnement
ENV ne peut définir qu'une seule variable à la fois, le contenu après la clé sera considéré comme valeur
ENV =… Plusieurs variables peuvent être définies, chaque variable est une paire clé-valeur "=", si elle contient espaces Caractères spéciaux, vous pouvez utiliser \ pour échapper
Exemple:
Nom d'utilisateur
ENV admin Mot de passe
ENV 123456 Port ENV = 3306

EXPOSE: Spécifiez le port pour l'interaction externe
EXPOSE […]
Exemple:
EXPOSE 80 443
EXPOSE 11221 / tcp 11221 / udp
Remarque: La commande EXPOSE déclare uniquement que le port que le conteneur doit ouvrir n'est pas réellement ouvert, si vous ne spécifiez pas le port à mapper sans -p, le conteneur ne mappera pas le port vers l'extérieur; pour le rendre accessible, vous devez spécifier ces ports via -p lors de l'exécution du docker

VOLUME: Utilisé pour spécifier le répertoire persistant
VOLUME ["/ chemin / vers / dir"]
Exemple:
VOLUME ["/ect/nginx/con.d"]
VOLUME ["/ etc / nginx / con.d", "/ etc / nginx / logs ”]
Remarque: Lorsque le conteneur est en cours d'exécution, essayez d'empêcher l'écriture de la couche de stockage du conteneur. Afin d'éviter que les utilisateurs oublient de monter le répertoire dans lequel le fichier dynamique est enregistré en tant que volume lors de l'exécution, nous pouvons spécifier certains répertoires dans le Dokcerfile à l'avance. Le montage est un volume anonyme, de sorte que même si l'utilisateur ne spécifie pas le montage, il n'écrira pas une grande quantité de données dans la couche de stockage du conteneur; il ne peut pas spécifier le répertoire sur l'hôte, et il est automatiquement généré.
Remarque: Le volume peut être partagé avec d'autres conteneurs et son cycle de vie est indépendant du conteneur. Docker ne supprimera pas automatiquement le volume de données une fois le conteneur supprimé, et il n'existe aucun mécanisme de récupération de place pour traiter les volumes de données référencés par le conteneur, si nécessaire Supprimez le volume de données lors de la suppression du conteneur. Vous pouvez utiliser la commande docker rm -v lors de la suppression du conteneur.
Voici le focus sur ce qui est en cours de montage:

WORKDIR: répertoire de travail, similaire à la commande cd
WORKDIR / chemin / vers / dir
Exemple:
WORKDIR / etc (le répertoire de travail est etc)
WORKDIR nginx (le répertoire de travail devient / etc / nginx)
Remarque: Après avoir défini le répertoire via WORKDIR, le retour dans le Dockerfile Les commandes sont exécutées dans le répertoire spécifié. Lors de l'exécution du conteneur, vous pouvez passer -w pour écraser le répertoire de travail du Dockerfile.

USER: spécifiez le nom d'utilisateur ou l'UID lors de l'exécution du conteneur, et la série de commandes suivante utilisera cet utilisateur.
USER user
USER uid
USER uid: gid
USER user: gid
USER uid: group
USEr user: group
Exemple:
USER mumu
Remarque: une fois que USER est utilisé pour spécifier un utilisateur, les commandes suivant le Dockerfile utiliseront cet utilisateur, mais lors de l'exécution du conteneur , vous pouvez passer le paramètre u pour écraser l'utilisateur spécifié.

ARG: Utilisé pour spécifier les variables passées à l'exécution de la construction, similaire à EVN
ARG [= <valeur par défaut]
Exemple:
site
ARG ARG user = mumu
Remarque: Si ARG spécifie une valeur par défaut et qu'aucune valeur n'est transmise pendant la construction, alors Just utilisez la valeur par défaut.

ONBUILD: Utilisé pour définir le déclencheur de mise en miroir
ONBUILD [INSTRUCTION]
Exemple:
ONBUILD ADD. / Etc / nginx
ONBUILD RUN
Remarque: Le paramètre peut être n'importe quelle instruction Dockerfile, qui n'aura pas un impact substantiel sur le miroir actuel (changer le miroir actuel Named A), mais si le miroir B est basé sur le miroir A, alors ses instructions seront exécutées lors de la construction du miroir B, mais lorsque C est basé sur B, l'instruction ne sera pas exécutée (on comprend qu'elle ne peut pas être héritée de génération en génération, haha).

Passons en revue avec un autre cas:
Jetons un coup d'œil au Dokcerfile de nginx: dernière version, la partie commentaire a été supprimée

FROM debian:buster-slim

LABEL maintainer="NGINX Docker Maintainers <[email protected]>"

ENV NGINX_VERSION   1.19.6

ENV NJS_VERSION     0.5.0

ENV PKG_RELEASE     1~buster

RUN set -x \

COPY docker-entrypoint.sh /

COPY 10-listen-on-ipv6-by-default.sh /docker-entrypoint.d

COPY 20-envsubst-on-templates.sh /docker-entrypoint.d

ENTRYPOINT ["/docker-entrypoint.sh"]

EXPOSE 80

STOPSIGNAL SIGQUIT

CMD ["nginx", "-g", "daemon off;"]

Reportez-vous à l'image de base: debian: buster-slim et
ajoutez les données source: mainteneur = "NGINX Docker Maintainers [email protected]"
introduit trois variables d'environnement: NGINX_VERSION 1.19.6 NJS_VERSION 0.5.0
PKG_RELEASE 1 ~ buster
exécute la commande set -x, C'est la commande dans le shell pour imprimer la commande à l'écran.
Copiez les trois fichiers à l'emplacement spécifié
. La combinaison de ENTRYPOINT et de CMD est: /docker-entrypoin.sh nginx -g daemon off
Spécifier le port 80
STOPSIGNAL: Ceci est introduit après docker1.9, et cette instruction est envoyée au système lancé par le conteneur Invoque des signaux, comme ce qu'il faut faire avant de quitter le système.

Je suppose que tu aimes

Origine blog.csdn.net/qq_41979344/article/details/113405668
conseillé
Classement