Dockerfile Reference traduction japonaise

Traduction japonaise de Référence Dockerfile.

Docker peut créer automatiquement l'image en lisant les instructions du Dockerfile. Dockerfile est un document texte qui décrit les commandes de création d'une image. Appelé et utilisé par l'utilisateur à partir de la ligne de commande. La build docker (https://qiita.com/JhonnyBravo/items/87976fe9de47ed58b8b1) permet aux utilisateurs de créer des builds automatiques qui exécutent successivement plusieurs instructions de ligne de commande.

Cette page décrit les commandes que vous pouvez utiliser dans votre Dockerfile. Après avoir lu cette page, veuillez vous référer aux Meilleures pratiques Dockerfile pour un guide orienté astuces.

comment utiliser

La commande docker build crée une image à partir d'un Dockerfile et d'un contexte. Le contexte de construction est un ensemble de fichiers dans le PATH ou l'URL à l'emplacement spécifié. PATH est un répertoire sur votre système de fichiers local. L'URL est l'emplacement du référentiel Git.

Les contextes sont traités de manière récursive. Par conséquent, le PATH contient des sous-répertoires et l'URL contient le référentiel et ses sous-modules. L'exemple suivant montre une commande de construction qui utilise le répertoire actuel comme contexte.

$ docker build .

Sending build context to Docker daemon  6.51 MB
...

La construction est effectuée par le démon Docker, pas par la CLI. La première chose que fait le processus de construction est d'envoyer tout le contexte (récursivement) au démon. Dans la plupart des cas, c'est une bonne idée de commencer avec un répertoire vide comme contexte et de conserver le Dockerfile dans ce répertoire. Ajoutez uniquement les fichiers nécessaires à la création du Dockerfile.

** Avertissement ** N'utilisez pas le répertoire racine `` / '' comme PATH. Tout le contenu du disque dur est transféré vers le démon Docker lors de l'exécution de la compilation.

Lors de l'utilisation d'un fichier dans un contexte de construction, Dockerfile référence le fichier spécifié par une instruction telle que l'instruction COPY ''. Pour améliorer les performances de compilation, ajoutez le fichier .dockerignoreau répertoire contextuel pour exclure les fichiers et répertoires. Consultez la documentation sur cette page pour savoir comment créer un fichier .dockerignore``.

Par convention, le Dockerfile est placé à la racine du contexte, Vous pouvez utiliser l'indicateur -f dans docker build pour spécifier un Dockerfile n'importe où dans le système de fichiers. ..

$ docker build -f /path/to/a/Dockerfile .

Vous pouvez spécifier un référentiel et des balises pour enregistrer la nouvelle image si la construction réussit.

$ docker build -t shykes/myapp .

Pour marquer une image dans plusieurs référentiels après la construction, ajoutez plusieurs paramètres `` -t '' lors de l'exécution de la commande de construction.

$ docker build -t shykes/myapp:1.0.2 -t shykes/myapp:latest .

Le démon Docker effectue une pré-validation du Dockerfile avant d'exécuter les instructions du Dockerfile et renvoie une erreur si la syntaxe est incorrecte.

$ docker build -t test/myapp .

Sending build context to Docker daemon 2.048 kB
Error response from daemon: Unknown instruction: RUNCMD

Le démon Docker exécute les instructions du Dockerfile une par une, valide les résultats de chaque instruction dans une nouvelle image si nécessaire et imprime enfin l'ID de la nouvelle image. Le démon Docker nettoie automatiquement le contexte que vous soumettez.

Notez que chaque instruction est exécutée indépendamment et qu'une nouvelle image est créée. Par conséquent, `` RUN cd / tmp '' n'affecte pas les instructions suivantes.

Dans la mesure du possible, Docker réutilise les images intermédiaires (caches) pour accélérer considérablement le processus de création de Docker. La réutilisation des images intermédiaires est indiquée par le message `ʻUsing cache`` dans la sortie de la console. (Consultez le Guide des meilleures pratiques Dockerfile (https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/) pour plus d'informations)

$ docker build -t svendowideit/ambassador .

Sending build context to Docker daemon 15.36 kB
Step 1/4 : FROM alpine:3.2
 ---> 31f630c65071
Step 2/4 : MAINTAINER [email protected]
 ---> Using cache
 ---> 2a1c91448f5f
Step 3/4 : RUN apk update &&      apk add socat &&        rm -r /var/cache/
 ---> Using cache
 ---> 21ed6e7fbb73
Step 4/4 : CMD env | grep _TCP= | (sed 's/.*_PORT_\([0-9]*\)_TCP=tcp:\/\/\(.*\):\(.*\)/socat -t 100000000 TCP4-LISTEN:\1,fork,reuseaddr TCP4:\2:\3 \&/' && echo wait) | sh
 ---> Using cache
 ---> 7ea8aef582cc
Successfully built 7ea8aef582cc

Le cache de construction n'est utilisé qu'à partir de l'image locale qui a la chaîne parente. Cela signifie que l'image a été créée par une version précédente ou que toute la chaîne d'images a été chargée avec docker load ''. Si vous souhaitez utiliser le cache de construction pour une image particulière, vous pouvez le spécifier avec l'option --cache-from ''. L'image spécifiée par --cache-from n'a pas besoin d'avoir une chaîne parent et peut être récupérée à partir d'autres registres.

Une fois la construction terminée, vous êtes prêt à réfléchir à la manière de pousser le référentiel vers le registre.

BuildKit

Docker version 18.09 et ultérieure prend en charge un nouveau backend pour exécuter les builds fournis par le projet moby / buildkit. Le backend BuildKit présente de nombreux avantages par rapport aux implémentations plus anciennes. Par exemple, BuildKit peut:

Pour utiliser le backend BuildKit, vous devez définir la variable d'environnement `` DOCKER_BUILDKIT = 1 '' dans la CLI avant d'appeler docker build.

Consultez la documentation du référentiel BuildKit (https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md) pour la syntaxe expérimentale de Dockerfile qui peut être utilisée avec les builds basés sur BuildKit. S'il vous plaît.

Format

Le format du Dockerfile est:

# Comment
INSTRUCTION arguments

Les instructions sont insensibles à la casse. Cependant, il est d'usage de le capitaliser pour le distinguer de ses arguments.

Docker exécute les instructions du Dockerfile dans l'ordre. Le Dockerfile doit commencer par l'instruction FROM ''. Cela peut être après les directives de l'analyseur, les commentaires et la portée globale «ARG». L'instruction FROM '' spécifie l'image parente à partir de laquelle elle a été construite. Le FROM ne peut être précédé que d'une ou plusieurs instructions ```ARGqui déclarent les arguments utilisés dans la ligne FROM`` du Dockerfile.

Docker traite les lignes commençant par # '' comme des commentaires, sauf si la ligne est une directive d'analyseur valide. Les marqueurs # '' ailleurs dans la ligne sont traités comme des arguments. Cela permet des déclarations telles que:

# Comment
RUN echo 'we are running some # of cool things'

La ligne de commentaire est supprimée avant l'exécution de l'instruction Dockerfile. Autrement dit, les commentaires de l'exemple suivant ne sont pas traités par le shell qui exécute la commande `ʻecho``. Les deux exemples ci-dessous sont équivalents.

RUN echo hello \
# comment
world

RUN echo hello \
world

Les caractères de continuation de ligne ne sont pas pris en charge dans les commentaires.

** Notes sur les blancs **

Pour une compatibilité descendante, les espaces de début avant les commentaires (# '') et les instructions (telles que RUN '') sont ignorés, mais pas recommandés. Dans ces cas, les blancs de début ne sont pas conservés, donc l'exemple suivant est équivalent.

         # this is a comment-line
   RUN echo hello
RUN echo world

# this is a comment-line
RUN echo hello
RUN echo world

Cependant, les blancs dans les arguments d'instructions tels que les commandes suivant RUN '' sont conservés, donc dans l'exemple suivant, hello world '' est affiché avec un vide au début.

RUN echo "\
    hello\
    world"

Directive analyseur

Les directives d'analyseur sont facultatives et affectent la façon dont les lignes suivantes du Dockerfile sont traitées. Les directives d'analyseur n'ajoutent pas de couches à la construction et n'apparaissent pas comme des étapes de construction. Les directives de l'analyseur sont écrites comme un type spécial de commentaire sous la forme `` # directive = valeur ''. Une directive ne peut être utilisée qu'une seule fois.

Lorsqu'un commentaire, une ligne vide ou une instruction de générateur est traitée, Docker ne recherche plus les directives de l'analyseur. Il traite ce qui est écrit comme une directive d'analyseur comme un commentaire et n'essaye pas de vérifier s'il peut s'agir d'une directive d'analyseur. Par conséquent, toutes les directives de l'analyseur doivent être en haut du Dockerfile.

Les directives d'analyseur ne sont pas sensibles à la casse. Cependant, par convention, il devrait être inférieur. Par convention, vous pouvez également inclure une ligne vide après la directive parser. Les caractères de continuation de ligne ne sont pas pris en charge dans les directives d'analyseur.

En raison de ces règles, tous les exemples suivants ne sont pas valides:

Invalide en raison de la continuation de la ligne

# direc \
tive=value

Non valide car il est affiché deux fois

# directive=value1
# directive=value2

FROM ImageName

Il est traité comme un commentaire car il apparaît après les instructions du constructeur.

FROM ImageName
# directive=value

Il est traité comme un commentaire car il apparaît après un commentaire qui n'est pas une directive d'analyseur.

# About my dockerfile
# directive=value
FROM ImageName

`ʻUnknowndirectiveest traité comme un commentaire car il n'est pas reconnu. De plus, knowndirective '' est traité comme un commentaire car il apparaît après un commentaire qui n'est pas une directive parser.

# unknowndirective=value
# knowndirective=value

La directive parser autorise les espaces sans interruption. Par conséquent, les lignes suivantes sont toutes traitées de la même manière.

#directive=value
# directive =value
#	directive= value
# directive = value
#	  dIrEcTiVe=value

Les directives d'analyseur suivantes sont prises en charge.

syntax

# syntax=[remote image reference]

Exemple

# syntax=docker/dockerfile
# syntax=docker/dockerfile:1.0
# syntax=docker.io/docker/dockerfile:1
# syntax=docker/dockerfile:1.0.0-experimental
# syntax=example.com/user/repo:tag@sha256:abcdef...

Cette fonctionnalité n'est activée que lorsque le backend BuildKit est utilisé.

La directive `` syntax '' définit l'emplacement du générateur Dockerfile utilisé pour construire le Dockerfile actuel. Le backend BuildKit vous permet d'utiliser de manière transparente une implémentation externe du générateur qui est distribuée sous forme d'image Docker et s'exécute dans un environnement de bac à sable de conteneur.

L'implémentation personnalisée de Dockerfile vous permet de:

Sortie officielle

Docker distribue la version officielle de l'image qui peut être utilisée pour créer un Dockerfile dans le référentiel docker / dockerfile sur DockerHub. Il existe deux canaux où de nouvelles images sont publiées: stable et expérimental.

Les canaux stables suivent le versionnage sémantique.

Exemple:

Le canal expérimental utilise une gestion de version incrémentielle avec des composants majeurs et mineurs du canal stable à la sortie.

Exemple:

Vous devez choisir la chaîne qui correspond à vos besoins. Si vous avez seulement besoin de corriger des bogues, vous devez utiliser docker / dockerfile: 1.0. Si vous souhaitez profiter des fonctionnalités expérimentales, vous devez utiliser le canal expérimental. Si vous utilisez le canal expérimental, nous vous recommandons d'utiliser la variante de version complète immuable, car les nouvelles versions peuvent ne pas être rétrocompatibles.

Voir Description du référentiel source (https://github.com/moby/buildkit/blob/master/README.md) pour les versions principales et les versions de fonctionnalités nocturnes.

escape

# escape=\ (backslash)

Ou

# escape=` (backtick)

Les directives d'échappement définissent les caractères utilisés pour échapper aux caractères dans le Dockerfile. S'il n'est pas spécifié, le caractère d'échappement par défaut est `` \ ''.

Les caractères d'échappement sont utilisés à la fois pour échapper des caractères dans une ligne et pour échapper des sauts de ligne. Cela permet à l'instruction Dockerfile de s'étendre sur plusieurs lignes. Notez que l'échappement n'est pas effectué avec la commande RUN, sauf à la fin de la ligne, indépendamment du fait que la directive parseur ```escape`` soit incluse dans le Dockerfile.

Définir le caractère d'échappement sur "` "est particulièrement utile sous Windows. Ici, `` \ '' est le délimiteur du chemin du répertoire. "` "Est compatible avec Windows PowerShell.

Prenons l'exemple suivant, qui échoue de manière non triviale sous Windows. Le deuxième \ '' à la fin de la deuxième ligne est interprété comme un échappement de rupture, pas la cible de l'échappement du premier \ ''. De même, le `` \ '' à la fin de la troisième ligne est traité comme une continuation de la ligne s'il a été réellement traité comme une instruction. Le résultat de ce dockerfile est que les deuxième et troisième lignes sont considérées comme une seule instruction.

FROM microsoft/nanoserver
COPY testfile.txt c:\\
RUN dir c:\

Résultat de l'exécution:

PS C:\John> docker build -t cmd .
Sending build context to Docker daemon 3.072 kB
Step 1/2 : FROM microsoft/nanoserver
 ---> 22738ff49c6d
Step 2/2 : COPY testfile.txt c:\RUN dir c:
GetFileAttributesEx c:RUN: The system cannot find the file specified.
PS C:\John>

L'une des solutions ci-dessus consiste à utiliser / '' comme cible à la fois pour l'instruction COPY '' et le dir ''. Cependant, cette syntaxe est déroutante car elle n'est pas naturelle dans les chemins Windows. Dans le pire des cas, toutes les commandes Windows ne prennent pas en charge / '' comme séparateur de chemin, ce qui le rend sujet aux erreurs.

En ajoutant la directive de l'analyseur `ʻescape``, le Dockerfile suivant réussira comme prévu en utilisant la sémantique naturelle de la plateforme dans le chemin du fichier Windows.

# escape=`

FROM microsoft/nanoserver
COPY testfile.txt c:\
RUN dir c:\

Résultat de l'exécution:

PS C:\John> docker build -t succeeds --no-cache=true .
Sending build context to Docker daemon 3.072 kB
Step 1/3 : FROM microsoft/nanoserver
 ---> 22738ff49c6d
Step 2/3 : COPY testfile.txt c:\
 ---> 96655de338de
Removing intermediate container 4db9acbb1682
Step 3/3 : RUN dir c:\
 ---> Running in a2c157f842f5
 Volume in drive C has no label.
 Volume Serial Number is 7E6D-E0F7

 Directory of c:\

10/05/2016  05:04 PM             1,894 License.txt
10/05/2016  02:22 PM    <DIR>          Program Files
10/05/2016  02:14 PM    <DIR>          Program Files (x86)
10/28/2016  11:18 AM                62 testfile.txt
10/28/2016  11:20 AM    <DIR>          Users
10/28/2016  11:20 AM    <DIR>          Windows
           2 File(s)          1,956 bytes
           4 Dir(s)  21,259,096,064 bytes free
 ---> 01c7f3bef04f
Removing intermediate container a2c157f842f5
Successfully built 01c7f3bef04f
PS C:\John>

Remplacement des variables d'environnement

Les variables d'environnement (déclarées dans l'instruction «ENV») peuvent également être utilisées dans certaines instructions comme des variables interprétées par le Dockerfile. Les échappements sont également traités pour inclure une syntaxe de type variable dans l'instruction telle quelle.

Les variables d'environnement sont représentées dans le Dockerfile sous la forme $ variable_name ou $ {variable_name} ''. Ils sont traités de la même manière et la syntaxe des accolades est généralement utilisée pour résoudre le problème des noms de variables non vides, tels que $ {foo} _bar``.

La syntaxe `` $ {variable_name} '' prend également en charge certains des modificateurs bash standard spécifiés ci-dessous.

Dans tous les cas, `` mot '' peut être n'importe quelle chaîne contenant des variables d'environnement supplémentaires.

L'échappement est possible en ajoutant \ '' à la variable. Par exemple, \ $ fooou \ $ {foo} '' est converti en $ foo et `` $ {foo} ''.

Exemple (la représentation analysée apparaît après `` # ''):

FROM busybox
ENV FOO=/bar
WORKDIR ${FOO}   # WORKDIR /bar
ADD . $FOO       # ADD . /bar
COPY \$FOO /quux # COPY $FOO /quux

Les variables d'environnement sont prises en charge par les instructions ci-dessous dans le Dockerfile.

Lors du remplacement des variables d'environnement, la même valeur est utilisée pour chaque variable tout au long de l'instruction. En d'autres termes, dans cet exemple:

ENV abc=hello
ENV abc=bye def=$abc
ENV ghi=$abc

Le résultat est un def '' avec une valeur de bonjour '' au lieu d'un bye ''. Cependant, ghi ne fait pas partie de la même instruction qui définit ```abc sur bye, donc il a une valeur de bye.

fichier .dockerignore

La CLI du docker recherche un fichier nommé .dockerignore dans le répertoire racine du contexte avant d'envoyer le contexte au démon docker. Si ce fichier existe, la CLI modifie le contexte pour exclure les fichiers et les répertoires qui correspondent au modèle qu'il contient. Cela évite d'envoyer inutilement des fichiers ou des répertoires volumineux ou sensibles au démon ou de les ajouter à l'image en utilisant «ADD» ou «COPY».

La CLI interprète le fichier .dockerignore comme une liste de motifs séparés par des sauts de ligne similaires aux gants de fichiers shell Unix. À des fins de classement, la racine du contexte est considérée à la fois comme le répertoire de travail et le répertoire racine. Par exemple, les modèles / foo / bar et foo / bar sont tous deux bar '' à la racine du dépôt git dans le sous-répertoire foo '' de `` PATH '' ou à l'URL. Excluez les fichiers ou répertoires nommés `. Ni l'un ni l'autre n'exclut l'autre.

Si une ligne du fichier .dockerignore commence par `` # '' dans la première colonne, cette ligne est considérée comme un commentaire et est ignorée avant d'être interprétée par la CLI.

Voici un exemple d'écriture d'un fichier .dockerignore:

# comment
*/temp*
*/*/temp*
temp?

Ce fichier provoque le comportement de génération suivant:

règle mouvement
# comment Ignorez-le.
*/temp* Un sous-répertoire direct de la racine, nommétempExcluez les fichiers et répertoires commençant par. Par exemple, un fichier brut/somedir/temporary.txtEst exclu et le répertoire/somedir/tempEst également exclu.
*/*/temp* Depuis un sous-répertoire deux niveaux sous la racinetempExcluez les fichiers et répertoires commençant par. Par exemple/somedir/subdir/temporary.txtEst exclu.
temp? Le nom est temp+Exclut les fichiers et répertoires du répertoire racine contenant un seul caractère. Par exemple/tempaQuand/tempbEst exclu.

La correspondance est effectuée à l'aide de la règle filepath.Match '' de Go. L'étape de pré-traitement utilise filepath.Clean '' de Go pour supprimer les espaces blancs de début et de fin, et supprime les éléments . '' Et .. ''. Les lignes vides sont ignorées après le prétraitement.

En plus de la règle filepath.Match '' de Go, Docker prend également en charge la chaîne générique spéciale ** '' qui correspond à n'importe quel nombre de répertoires (y compris les zéros). Par exemple, ** / *. Go exclut tous les fichiers se terminant par .go dans tous les répertoires contenant la racine du contexte de construction.

Vous pouvez créer des exceptions d'exclusion en utilisant des lignes commençant par ! '' (Exclamation). Voici un exemple de fichier .dockerignore`` utilisant ce mécanisme.

*.md
!README.md

Tous les fichiers markdown sauf README.md sont exclus du contexte.

Le placement de la règle d'exception ! '' Affecte son comportement. La dernière ligne de .dockerignore`` qui correspond à un fichier particulier détermine si ce fichier est inclus ou exclu. Prenons l'exemple suivant.

*.md
!README*.md
README-secret.md

Les fichiers Markdown ne sont pas inclus dans le contexte, à l'exception des fichiers README '' autres que README-secret.md``.

Considérons maintenant cet exemple.

*.md
README-secret.md
!README*.md

Contient tous les fichiers README ''. La ligne médiane n'a aucun effet car! README * .mdcorrespond à README-secret.md`` et vient à la fin.

Vous pouvez également utiliser le fichier .dockerignore '' pour exclure les fichiers Dockerfile et .dockerignore``. Ces fichiers continueront d'être envoyés au démon car ils doivent exécuter le travail. Cependant, les instructions «ADD» et «COPY» ne les copient pas sur l'image.

Enfin, il est judicieux de spécifier les fichiers que vous souhaitez inclure dans le contexte, et non les fichiers que vous souhaitez exclure. Pour ce faire, spécifiez * '' comme premier motif, suivi d'un ou plusieurs motifs d'exception! ''.

** Attention **

Pour des raisons historiques, le motif ``. '' Est ignoré.

FROM

FROM [--platform=<platform>] <image> [AS <name>]

Ou

FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]

Ou

FROM [--platform=<platform>] <image>[@<digest>] [AS <name>]

L'instruction FROM '' initialise une nouvelle étape de construction et définit l'image de base pour les instructions suivantes. Par conséquent, un Dockerfile valide doit commencer par l'instruction FROM ''. L'image peut être n'importe quelle image valide. Il est particulièrement facile de commencer par obtenir l'image à partir d'un référentiel public.

Vous pouvez utiliser l'indicateur optionnel --platform pour spécifier la plate-forme de l'image lorsque FROM '' fait référence à une image multi-plate-forme. Par exemple, linux / amd64 '', linux / arm64 '' ou windows / amd64 ''. Par défaut, la plate-forme cible de la demande de génération est utilisée. Vous pouvez utiliser des arguments de construction globaux pour la valeur de cet indicateur. Par exemple, vous pouvez utiliser l'argument de plate-forme automatique pour forcer une étape vers une plate-forme de construction native et l'utiliser pour effectuer une compilation croisée vers une plate-forme cible dans l'étape. ( --platform=$BUILDPLATFORM )

Comprendre l'interaction entre ```ARGet FROM``

L'instruction FROM prend en charge les variables déclarées par l'instruction ```ARGqui se produit avant le premier FROM``.

ARG  CODE_VERSION=latest
FROM base:${CODE_VERSION}
CMD  /code/run-app

FROM extras:${CODE_VERSION}
CMD  /code/run-extras

```ARGdéclaré avant FROMest en dehors de la phase de construction et ne peut pas être utilisé dans les instructions après FROM``. Pour utiliser la valeur par défaut de «ARG» déclarée avant le premier «FROM», utilisez l'instruction «ARG» sans valeur à l'étape de construction.

ARG VERSION=latest
FROM busybox:$VERSION
ARG VERSION
RUN echo $VERSION > image_version

RUN

RUN a deux formes:

L'instruction `` RUN '' exécute la commande sur un nouveau calque sur l'image courante et valide le résultat. L'image avec le résultat validé sera utilisée à l'étape suivante dans le Dockerfile.

Hiérarchiser l'instruction `` RUN '' et générer des commits est conforme au concept de base de Docker de commits bon marché et à la possibilité de créer des conteneurs à partir de n'importe quel point de l'historique de l'image, comme le contrôle de code source.

Vous pouvez utiliser le format ```execpour éviter de changer la chaîne du shell ou pour exécuter la commande RUN`` avec une image de base qui ne contient pas l'exécutable shell spécifié.

Le shell au format shell par défaut peut être modifié à l'aide de la commande `` SHELL ''.

Sous forme de shell, vous pouvez utiliser \ '' (barre oblique inverse) pour continuer une seule instruction RUN '' sur la ligne suivante. Par exemple, considérez les deux lignes suivantes:

RUN /bin/bash -c 'source $HOME/.bashrc; \
echo $HOME'

Ensemble, ils correspondent à la ligne suivante:

RUN /bin/bash -c 'source $HOME/.bashrc; echo $HOME'

Pour utiliser un autre shell autre que / bin / sh, utilisez le format `ʻexec``, qui passe le shell souhaité. Par exemple:

RUN ["/bin/bash", "-c", "echo hello"]

** Attention **

Le format> `ʻexec`` est analysé comme un tableau JSON.

Autrement dit, vous devez utiliser des guillemets doubles (`` " ) avant et après le mot, pas des guillemets simples ( ' ).

Contrairement à la forme shell, la forme ʻexec`` n'appelle pas la commande shell. Cela signifie que le traitement normal du shell ne se produira pas. Par exemple, `` RUN ["echo", "$ HOME"] `` ne fait pas de substitution de variable pour `` $ HOME``. Si un shelling est nécessaire, utilisez le format shell ou exécutez directement le shell. Exemple: `` RUN ["sh", "-c", "echo $ HOME"] ``. Si vous exécutez directement le shell en utilisant le format ʻexec``, comme dans le format shell, c'est le shell, et non le Docker, qui étend les variables d'environnement.

** Attention **

Au format JSON, les contre-obliques doivent être échappées. Ceci est particulièrement pertinent pour Windows, où la barre oblique inverse est le séparateur de chemin. La ligne suivante est traitée comme un format shell car ce n'est pas un JSON valide et échoue de manière inattendue:

RUN ["c:\windows\system32\tasklist.exe"]

La syntaxe correcte pour cet exemple est:

RUN ["c:\\windows\\system32\\tasklist.exe"]

Le cache des instructions RUN '' n'est pas automatiquement désactivé lors de la prochaine construction. Le cache d'instructions comme RUN apt-get dist-upgrade -y '' sera réutilisé dans la prochaine version. Le cache d'instructions RUN '' peut être désactivé à l'aide de l'indicateur --no-cache(par exemple, docker build --no-cache '').

Consultez le Guide des meilleures pratiques Dockerfile (https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/) pour plus d'informations.

Le cache de l'instruction RUN peut être écrasé par les instructions ```ADDet COPY``.

Problème connu (`` RUN '')

CMD

L'instruction `` CMD '' a trois formes:

Il ne peut y avoir qu'une seule instruction CMD '' dans un Dockerfile. Si vous listez plusieurs CMD '', seul le dernier `` CMD '' sera valide.

L'objectif principal de CMD '' est de fournir un comportement par défaut pour l'exécution des conteneurs. Ces comportements par défaut peuvent inclure «exécutable» ou omettre «exécutable». Si vous omettez `ʻexecutable, vous devez également spécifier l'instruction` ʻENTRYPOINT``.

Si vous utilisez CMD pour fournir les arguments par défaut pour l'instruction ENTRYPOINT``, vous devez spécifier à la fois les instructions `` CMD`` et ENTRYPOINT`` au format tableau JSON. ..

** Attention **

Le format> `ʻexec`` est analysé comme un tableau JSON.

Autrement dit, vous devez utiliser des guillemets doubles (`` " ) avant et après le mot, pas des guillemets simples ( ' ).

Contrairement à la forme shell, la forme ʻexec`` n'appelle pas la commande shell. Cela signifie que le traitement normal du shell ne se produira pas. Par exemple, `` CMD ["echo", "$ HOME"] `` ne fait pas de substitution de variable avec `` $ HOME``. Si un shelling est nécessaire, utilisez le format shell ou exécutez directement le shell. Exemple: `` CMD ["sh", "-c", "echo $ HOME"] `` Si vous exécutez directement le shell en utilisant le format ʻexec``, comme dans le format shell, c'est le shell, et non le Docker, qui étend les variables d'environnement.

Lorsqu'elle est utilisée au format shell ou ```exec, l'instruction CMD`` définit la commande à exécuter lors de l'exécution de l'image.

Lors de l'utilisation de la forme shell de CMD, <command> '' est exécuté avec / bin / sh -c '':

FROM ubuntu
CMD echo "This is a test." | wc -

Si vous voulez exécuter <commande> sans shell, vous devez représenter la commande sous forme de tableau JSON et spécifier le chemin complet vers ```executable. Ce format de tableau est le format recommandé pour CMD ''. Les paramètres supplémentaires doivent être représentés individuellement sous forme de chaînes dans le tableau.

FROM ubuntu
CMD ["/usr/bin/wc","--help"]

Si vous voulez que le conteneur exécute le même ʻexécutable`` à chaque fois, vous devriez envisager d'utiliser ʻENTRYPOINT en combinaison avec` `CMD. Voir `ʻENTRYPOINT``.

Si l'utilisateur spécifie un argument pour l'exécution du docker (https://qiita.com/JhonnyBravo/items/eee5a91682f1d7c72f6e), la valeur par défaut spécifiée par `` CMD '' sera remplacée.

** Attention **

Ne confondez pas RUN '' avec CMD ''. RUN '' exécute réellement la commande et valide le résultat. CMD '' ne fait rien au moment de la construction, mais spécifie la commande que vous voulez que l'image exécute.

LABEL

LABEL <key>=<value> <key>=<value> <key>=<value> ...

L'instruction LABEL '' ajoute des métadonnées à l'image. LABEL '' est une paire clé / valeur. Pour inclure des espaces dans la valeur de `` LABEL '', utilisez des guillemets et des barres obliques inverses comme vous le feriez pour l'analyse de la ligne de commande.

Exemple d'utilisation:

LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"
LABEL version="1.0"
LABEL description="This text illustrates \
that label-values can span multiple lines."

Les images peuvent avoir plusieurs étiquettes. Vous pouvez spécifier plusieurs étiquettes sur une ligne. Avant Docker 1.10, cela réduisait la taille de l'image finale, ce qui n'est plus le cas. Vous pouvez également spécifier plusieurs étiquettes avec une seule instruction de l'une des deux manières suivantes:

LABEL multi.label1="value1" multi.label2="value2" other="value3"

LABEL multi.label1="value1" \
      multi.label2="value2" \
      other="value3"

Les étiquettes contenues dans l'image de base ou l'image parente (l'image de la ligne `` FROM '') sont héritées par l'image enfant. Si l'étiquette existe déjà mais que les valeurs sont différentes, la dernière valeur appliquée écrase la valeur précédemment définie.

Utilisez la commande docker image inspect '' pour afficher l'étiquette de l'image. Seules les étiquettes peuvent être affichées à l'aide de l'option --format ''.

docker image inspect --format='' myimage

{
  "com.example.vendor": "ACME Incorporated",
  "com.example.label-with-value": "foo",
  "version": "1.0",
  "description": "This text illustrates that label-values can span multiple lines.",
  "multi.label1": "value1",
  "multi.label2": "value2",
  "other": "value3"
}

MAINTAINER (non recommandé)

MAINTAINER <name>

L'instruction MAINTAINER définit le champ ```Authordans l'image générée. L'instruction LABEL '' vous donne beaucoup plus de flexibilité que le MAINTAINER '' pour définir les métadonnées requises. Utilisez plutôt LABEL ''. Vous pouvez facilement le visualiser en utilisant, par exemple, docker inspect ''. Pour définir le libellé correspondant au champ MAINTAINER '':

LABEL maintainer="[email protected]"

Ceci est affiché à partir de `` docker inspect '' avec d'autres étiquettes.

EXPOSE

EXPOSE <port> [<port>/<protocol>...]

L'instruction «EXPOSE» notifie à Docker qu'il écoutera sur le port réseau spécifié lors de l'exécution du conteneur. Vous pouvez spécifier si le port écoute sur TCP ou UDP. Si aucun protocole n'est spécifié, la valeur par défaut est TCP.

L'instruction «EXPOSE» n'expose pas réellement le port. Il agit comme une sorte de document entre la personne qui crée l'image et la personne qui gère le conteneur, et est destiné à exposer le port. Pour exposer réellement les ports lorsque le conteneur s'exécute, utilisez l'indicateur -p dans docker run pour créer un ou plusieurs ports Publiez et associez, ou utilisez l'indicateur `` -P '' pour exposer tous les ports exposés et les lier à des ports supérieurs.

Par défaut, «EXPOSE» suppose TCP, Vous pouvez également spécifier UDP.

EXPOSE 80/udp

Pour publier à la fois en TCP et UDP, écrivez les deux lignes suivantes:

EXPOSE 80/tcp
EXPOSE 80/udp

Dans ce cas, l'utilisation de -P dans docker run expose le port une fois pour TCP et une fois pour UDP. Notez que `` -P '' utilise un port d'hôte supérieur temporaire sur l'hôte, donc les ports ne sont pas les mêmes pour TCP et UDP.

Vous pouvez les remplacer lors de l'exécution en utilisant l'indicateur -p quel que soit le paramètre `ʻEXPOSE``.

Exemple:

docker run -p 80:80/tcp -p 80:80/udp ...

Voir Utilisation de l'indicateur -P '' pour configurer la redirection de port sur le système hôte. La commande docker network '' prend en charge la création d'un réseau pour la communication entre conteneurs sans avoir à exposer ou publier un port spécifique. En effet, les conteneurs connectés au réseau peuvent communiquer entre eux via n'importe quel port. Pour plus d'informations, consultez «Présentation des fonctionnalités du réseau docker» (https://docs.docker.com/engine/userguide/networking/).

ENV

ENV <key>=<value> ...

L'instruction ʻENV`` définit la variable d'environnement <key> sur la valeur <value> `. Cette valeur se trouve dans l'environnement de toutes les instructions ultérieures de l'étape de construction et peut souvent être remplacée en ligne. La valeur est interprétée pour d'autres variables d'environnement et sera supprimée si les guillemets ne sont pas échappés. Comme pour l'analyse de ligne de commande, vous pouvez utiliser des guillemets et des barres obliques inverses pour inclure des espaces dans la valeur.

Exemple:

ENV MY_NAME="John Doe"
ENV MY_DOG=Rex\ The\ Dog
ENV MY_CAT=fluffy

L'instruction ʻENV`` vous permet de définir plusieurs variables <key> = <valeur> ... `à la fois. Dans l'exemple ci-dessous, l'image finale donnera le même résultat final.

ENV MY_NAME="John Doe" MY_DOG=Rex\ The\ Dog \
    MY_CAT=fluffy

Les variables d'environnement définies à l'aide de «ENV» sont conservées lorsque le conteneur est exécuté à partir de l'image résultante. Vous pouvez utiliser docker inspect '' pour afficher la valeur et utiliser docker run --env = '' pour changer la valeur.

La persistance des variables d'environnement peut provoquer des effets secondaires inattendus. Par exemple, définir «ENV DEBIAN_FRONTEND = noninteractive» change le comportement de «apt-get» et peut dérouter les utilisateurs de l'image.

Si les variables d'environnement ne sont nécessaires que pendant la génération et non dans l'image finale, envisagez de définir la valeur pour une seule commande à la place.

RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y ...

Ou utilisez «ARG» qui n'est pas conservé dans l'image finale.

ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y ...

** Notation alternative **

L'instruction> ʻENV`` peut utiliser la syntaxe alternative ʻENV et omettre .

Exemple:

ENV MY_VAR my-value

Cette syntaxe ne permet pas de définir plusieurs variables d'environnement dans une seule instruction «ENV», ce qui peut prêter à confusion. Définissez une seule variable d'environnement ʻONE`` avec la valeur " TWO = THREE = world " `, par exemple:

ENV ONE TWO= THREE=world

Une autre syntaxe est prise en charge pour la compatibilité descendante, mais elle est obsolète pour les raisons mentionnées ci-dessus et peut être supprimée dans une version ultérieure.

ADD

«ADD» a deux formes:

ADD [--chown=<user>:<group>] <src>... <dest>
ADD [--chown=<user>:<group>] ["<src>",... "<dest>"]

Les chemins contenant des espaces nécessitent cette dernière forme.

** Attention **

La fonctionnalité --chown '' n'est prise en charge que dans le Dockerfile utilisé pour construire le conteneur Linux, pas dans le conteneur Windows. Le concept de propriété des utilisateurs et des groupes n'étant pas traduit entre Linux et Windows, utilisez / etc / passwd '' et `` / etc / group '' pour convertir les noms d'utilisateurs et de groupes en ID. Lorsqu'elle est utilisée, cette fonctionnalité est limitée à viable uniquement s'il s'agit d'un conteneur basé sur un système d'exploitation Linux.

L'instruction ʻADD`` copie l'URL d'un nouveau fichier, répertoire ou fichier distant à partir de <src> '' et l'ajoute au système de fichiers de l'image avec le chemin ` ''.

Vous pouvez spécifier plusieurs ressources `` '', mais s'il s'agit de fichiers ou de répertoires, le chemin sera interprété comme relatif à la source dans le contexte de construction.

Chaque <src> '' peut contenir des caractères génériques et la correspondance est effectuée à l'aide de la règle filepath.Match '' de Go. Par exemple, pour ajouter tous les fichiers commençant par `` hom '':

ADD hom* /mydir/

Dans l'exemple ci-dessous, ? '' Est remplacé par un seul caractère, tel que home.txt ''.

ADD hom?.txt /mydir/

<dest> '' est un chemin absolu ou un chemin relatif comme vu de WORKDIR``, et la source est copiée dans le conteneur de destination.

L'exemple suivant utilise un chemin relatif pour ajouter test.txt à <WORKDIR> / relativeDir /:

ADD test.txt relativeDir/

Cet exemple utilise un chemin absolu pour ajouter test.txt à `` / abstractDir / ''.

ADD test.txt /absoluteDir/

Si vous ajoutez des fichiers ou des répertoires contenant des caractères spéciaux (tels que ['' ou] ), vous devez échapper à ces chemins selon les règles de langue de Go afin qu'ils ne soient pas traités comme des modèles correspondants. Il y a. Par exemple, pour ajouter un fichier nommé `ʻarr [0] .txt, utilisez:

ADD arr[[]0].txt /mydir/

Avec tous les nouveaux fichiers, sauf si l'indicateur facultatif --chown '' spécifie un nom d'utilisateur, un nom de groupe ou une combinaison UID / GID spécifique pour revendiquer la propriété spécifique du contenu ajouté Le répertoire est créé avec un UID et un GID de 0. Sous la forme de l'indicateur --chown '', vous pouvez utiliser n'importe quelle combinaison de chaînes de nom d'utilisateur et de nom de groupe, ou des entiers directs UID et GID. Si vous spécifiez un nom d'utilisateur sans nom de groupe ou un UID sans GID, le même UID numérique que le GID est utilisé. Si un nom d'utilisateur ou de groupe est spécifié, utilisez les fichiers / etc / passwd '' et / etc / group '' du système de fichiers racine du conteneur pour passer du nom à l'UID ou GID entier. Chaque conversion est effectuée. L'exemple suivant montre une définition valide de l'indicateur --chown.

ADD --chown=55:mygroup files* /somedir/
ADD --chown=bin files* /somedir/
ADD --chown=1 files* /somedir/
ADD --chown=10:11 files* /somedir/

Si le système de fichiers racine du conteneur ne contient pas de fichier / etc / passwd ou / etc / group et que le nom d'utilisateur ou le nom de groupe est utilisé avec l'indicateur --chown , L'opération ```ADD`` provoque l'échec de la construction. L'utilisation d'ID numériques ne nécessite pas de recherche et est indépendante du contenu du système de fichiers racine du conteneur.

Si <src> '' est l'URL d'un fichier distant, la destination dispose de 600 autorisations. Si le fichier distant que vous obtenez a un en-tête HTTP Last-Modified, utilisez l'horodatage dans cet en-tête pour définir le mtime pour le fichier de destination. Cependant, comme tout autre fichier traité pendant `ʻADD, mtime n'est pas inclus dans la détermination si un fichier a changé et le cache doit être mis à jour.

** Attention **

Si vous passez un Dockerfile à STDIN ( docker build- <somefile) pour construire, le Dockerfile ne peut contenir que des instructions ADD basées sur l'URL car il n'y a pas de contexte de construction. Je vais. Vous pouvez également transmettre l'archive compressée via STDIN '': ( docker build- <archive.tar.gz``). Le Dockerfile à la racine de l'archive et le reste de l'archive seront utilisés comme contexte de construction.

Si le fichier URL est protégé en utilisant l'authentification, alors l'instruction ʻADD`` ne prend pas en charge l'authentification, alors utilisez RUN wget``, `RUN curl``, ou depuis le conteneur. Vous devez utiliser un autre outil.

** Attention **

La première instruction ADD détectée invalide le cache de toutes les instructions suivantes du Dockerfile si le contenu de <src> est modifié. Cela inclut la désactivation du cache de l'instruction `` RUN ''. Pour plus d'informations, consultez le Guide des meilleures pratiques Dockerfile - Exploiter le cache de build (https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache).

«ADD» suit les règles ci-dessous.

** Attention **

Le répertoire lui-même n'est pas copié, seul son contenu est copié.

  1. Tout ce qui existe dans le chemin de destination
  2. Le contenu de l'arborescence source en conflit est résolu avec une priorité `` 2 '' pour chaque fichier.

** Attention **

Le fait qu'un fichier soit identifié comme un format de compression reconnu dépend uniquement du contenu du fichier, et non du nom du fichier. Par exemple, si un fichier vide se termine par .tar.gz, il ne sera pas reconnu comme un fichier compressé, aucun message d'erreur de décompression ne sera généré, et le fichier sera simplement copié vers la destination.

COPY

`` COPY '' a deux formes:

COPY [--chown=<user>:<group>] <src>... <dest>
COPY [--chown=<user>:<group>] ["<src>",... "<dest>"]

Cette dernière forme est requise pour les chemins contenant des espaces.

** Attention **

La fonctionnalité --chown '' n'est prise en charge que dans le Dockerfile utilisé pour construire le conteneur Linux, pas dans le conteneur Windows. Puisque le concept de propriété des utilisateurs et des groupes n'est pas traduit entre Linux et Windows, utilisez / etc / passwd '' et `` / etc / group '' pour convertir les noms d'utilisateurs et de groupes en ID. Utiliser. Cette fonctionnalité est limitée à l'exécutable uniquement s'il s'agit d'un conteneur basé sur un système d'exploitation Linux.

L'instruction COPY '' copie un nouveau fichier ou répertoire de '' et l'ajoute au système de fichiers du conteneur avec le chemin `` ''.

Vous pouvez spécifier plusieurs ressources `` '', mais les chemins de fichier et de répertoire sont interprétés comme relatifs à la source dans le contexte de construction.

Chaque <src> '' peut contenir des caractères génériques et la correspondance est effectuée à l'aide de la règle filepath.Match '' de Go. Par exemple, pour ajouter tous les fichiers commençant par `` hom '':

COPY hom* /mydir/

Dans l'exemple ci-dessous, ? '' Est remplacé par un seul caractère, tel que home.txt ''.

COPY hom?.txt /mydir/

<dest> '' est un chemin absolu, ou un chemin relatif à WORKDIR '', et la source est copiée dans le conteneur de destination.

L'exemple suivant utilise un chemin relatif pour ajouter test.txt à `` / relativeDir / ''.

COPY test.txt relativeDir/

Cet exemple utilise un chemin absolu pour ajouter test.txt à `` / abstractDir / ''.

COPY test.txt /absoluteDir/

Lors de la copie de fichiers ou de répertoires contenant des caractères spéciaux (tels que ['' ou] ), échappez à ces chemins selon les règles de langue de Go afin qu'ils ne soient pas traités comme des modèles correspondants. est nécessaire. Par exemple, pour copier un fichier nommé `ʻarr [0] .txt, utilisez:

COPY arr[[]0].txt /mydir/

Avec tous les nouveaux fichiers, sauf si l'indicateur facultatif --chown '' spécifie un nom d'utilisateur, un nom de groupe ou une combinaison UID / GID spécifique pour revendiquer la propriété spécifique du contenu copié. Le répertoire est créé avec un UID et un GID de 0. Sous la forme de l'indicateur --chown '', vous pouvez utiliser n'importe quelle combinaison de chaînes de nom d'utilisateur et de nom de groupe, ou des entiers directs UID et GID. Si vous spécifiez un nom d'utilisateur sans nom de groupe ou un UID sans GID, le même UID numérique que le GID est utilisé. Si un nom d'utilisateur ou de groupe est spécifié, utilisez les fichiers / etc / passwd '' et / etc / group '' du système de fichiers racine du conteneur pour passer du nom à l'UID ou GID entier. Chaque conversion est effectuée. L'exemple suivant montre une définition valide de l'indicateur --chown.

COPY --chown=55:mygroup files* /somedir/
COPY --chown=bin files* /somedir/
COPY --chown=1 files* /somedir/
COPY --chown=10:11 files* /somedir/

Le système de fichiers racine du conteneur ne contient pas de fichier / etc / passwd ou / etc / group et le nom d'utilisateur ou le nom de groupe est utilisé avec l'indicateur --chown Si tel est le cas, la construction échouera avec l'opération `` COPY ''. L'utilisation d'ID numériques ne nécessite pas de recherche et est indépendante du contenu du système de fichiers racine du conteneur.

** Attention **

Si vous construisez en utilisant STDIN '' ( docker build- <somefile ''), vous ne pouvez pas utiliser `` COPY '' car il n'y a pas de contexte de construction.

Facultativement, COPY '' est un drapeau --from = '' qui peut être utilisé pour définir l'emplacement source sur l'étape de construction précédente (créé avec `` FROM .. AS '') Acceptez ». Utilisé à la place du contexte de construction soumis par l'utilisateur. Si une étape de construction avec le nom spécifié n'est pas trouvée, une image avec le même nom est utilisée à la place.

`` COPY '' suit les règles suivantes:

** Attention **

Le répertoire lui-même n'est pas copié, seul son contenu est copié.

** Attention **

La première instruction COPY '' détectée invalide le cache de toutes les instructions suivantes du Dockerfile si le contenu de '' est modifié. Cela inclut la désactivation du cache de l'instruction `` RUN ''. Pour plus d'informations, consultez le Guide des meilleures pratiques Dockerfile - Exploiter le cache de build (https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache).

ENTRYPOINT

`ʻENTRYPOINT`` a deux formes:

Le format recommandé est le format «exec»:

ENTRYPOINT ["executable", "param1", "param2"]

Format de la coque:

ENTRYPOINT command param1 param2

Vous pouvez utiliser ʻENTRYPOINT`` pour configurer le conteneur dans lequel ʻexecutable`` est exécuté.

Par exemple, l'exemple suivant démarre nginx avec le contenu par défaut et écoute sur le port 80.

$ docker run -i -t --rm -p 80:80 nginx

Les arguments de ligne de commande à docker run <image> '' sont ajoutés après tous les éléments du format `ʻexec````ENTRYPOINT et tous les éléments spécifiés à l'aide de CMDÉcraser. Cela vous permet de transmettre des arguments au point d'entrée. Autrement dit, docker run -dtransmet l'argument -d au point d'entrée. Vous pouvez remplacer l'instruction `ʻENTRYPOINT avec l'indicateur docker run --entrypoint``.

La forme shell n'utilise plus CMD ou l'exécution d'arguments de ligne de commande, mais a l'inconvénient que ```ENTRYPOINTest démarré comme une sous-commande de / bin / sh -c qui ne transmet pas de signal. il y a. Cela signifie que «exécutable» ne reçoit pas le PID 1 pour le conteneur et ne reçoit pas de signal Unix. Par conséquent, `ʻexecutable ne reçoit pas SIGTERM`` de docker stop .

Seule la dernière instruction `ʻENTRYPOINT`` du Dockerfile est valide.

Exemple de ```ENTRYPOINT`` au format Exec

Peut être modifié en utilisant l'une ou l'autre forme de CMD après avoir défini des commandes et des arguments par défaut assez stables en utilisant ʻENTRYPOINT`` sous la forme ʻexec`` Vous pouvez définir des comportements par défaut supplémentaires qui sont plus probables.

FROM ubuntu
ENTRYPOINT ["top", "-b"]
CMD ["-c"]

Lorsque vous exécutez le conteneur, vous pouvez voir que `` top '' est le seul processus.

$ docker run -it --rm --name test  top -H

top - 08:25:00 up  7:27,  0 users,  load average: 0.00, 0.01, 0.05
Threads:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   2056668 total,  1616832 used,   439836 free,    99352 buffers
KiB Swap:  1441840 total,        0 used,  1441840 free.  1324440 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
    1 root      20   0   19744   2336   2080 R  0.0  0.1   0:00.04 top

Vous pouvez utiliser `` docker exec '' pour examiner les résultats plus en détail.

$ docker exec -it test ps aux

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  2.6  0.1  19752  2352 ?        Ss+  08:24   0:00 top -b -H
root         7  0.0  0.1  15572  2164 ?        R+   08:25   0:00 ps aux

Vous pouvez également utiliser le test d'arrêt de docker '' pour demander que top '' soit arrêté correctement.

Le Dockerfile suivant montre comment exécuter Apache au premier plan (c'est-à-dire comme PID 1) en utilisant `ʻENTRYPOINT``.

FROM debian:stable
RUN apt-get update && apt-get install -y --force-yes apache2
EXPOSE 80 443
VOLUME ["/var/www", "/var/log/apache2", "/etc/apache2"]
ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]

Si vous avez besoin de créer un seul script de démarrage ʻexecutable``, utilisez les commandes ʻexec et` `gosu pour vous assurer que le dernier` ʻexécutable`` reçoit le signal Unix. Vous pouvez le faire.

#!/usr/bin/env bash
set -e

if [ "$1" = 'postgres' ]; then
    chown -R postgres "$PGDATA"

    if [ -z "$(ls -A "$PGDATA")" ]; then
        gosu postgres initdb
    fi

    exec gosu postgres "$@"
fi

exec "$@"

Enfin, si vous avez besoin d'effectuer un nettoyage supplémentaire (ou de communiquer avec d'autres conteneurs) à l'arrêt, ou si vous voulez régler plusieurs ʻexecutables``, le script ʻENTRYPOINT`` signalera un Unix. Vous devez vous assurer d'envoyer et de recevoir pour effectuer plus de travail.

#!/bin/sh
# Note: I've written this using sh so it works in the busybox container too

# USE the trap if you need to also do manual cleanup after the service is stopped,
#     or need to start multiple services in the one container
trap "echo TRAPed signal" HUP INT QUIT TERM

# start service in background here
/usr/sbin/apachectl start

echo "[hit enter key to exit] or run 'docker stop <container>'"
read

# stop service and clean up here
echo "stopping apache"
/usr/sbin/apachectl stop

echo "exited $0"

Si vous exécutez cette image avec dockerrun -it --rm -p 80:80 --name test apache '', vous pouvez voir le processus du conteneur avec docker exec '' ou `` docker top ''. Demandez aux scripts suivants d'arrêter Apache.

$ docker exec -it test ps aux

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0   4448   692 ?        Ss+  00:42   0:00 /bin/sh /run.sh 123 cmd cmd2
root        19  0.0  0.2  71304  4440 ?        Ss   00:42   0:00 /usr/sbin/apache2 -k start
www-data    20  0.2  0.2 360468  6004 ?        Sl   00:42   0:00 /usr/sbin/apache2 -k start
www-data    21  0.2  0.2 360468  6000 ?        Sl   00:42   0:00 /usr/sbin/apache2 -k start
root        81  0.0  0.1  15572  2140 ?        R+   00:44   0:00 ps aux

$ docker top test

PID                 USER                COMMAND
10035               root                {run.sh} /bin/sh /run.sh 123 cmd cmd2
10054               root                /usr/sbin/apache2 -k start
10055               33                  /usr/sbin/apache2 -k start
10056               33                  /usr/sbin/apache2 -k start

$ /usr/bin/time docker stop test

test
real	0m 0.27s
user	0m 0.03s
sys	0m 0.03s

Mise en garde

Vous pouvez utiliser --entrypoint pour remplacer le paramètre ʻENTRYPOINT``, mais cela ne peut définir binary`` que sur ʻexec (` `sh -c Non utilisé).

Mise en garde

Le format ʻexec`` est analysé comme un tableau JSON. Autrement dit, vous devez utiliser des guillemets doubles (`` " ) avant et après le mot au lieu de guillemets simples ( ' `).

Contrairement au format shell, le format «exec» n'appelle pas la commande shell. Cela signifie que le traitement normal du shell ne se produira pas. Par exemple, ʻENTRYPOINT [" echo "," $ HOME "] ne remplace pas la variable dans`` $ HOME``. Si un traitement shell est requis, utilisez le format shell ou exécutez directement le shell. Exemple: ʻENTRYPOINT [" sh "," -c "," echo $ HOME "] Si vous exécutez directement le shell en utilisant le format `ʻexec``, comme dans le format shell, c'est le shell, et non le Docker, qui étend les variables d'environnement.

Exemple de description du format du shell ENTRYPOINT

Si vous spécifiez une chaîne de caractères simple pour ʻENTRYPOINT``, elle sera exécutée avec / bin / sh -c``. Ce formulaire utilise le traitement du shell pour remplacer les variables d'environnement du shell et ignore les arguments de ligne de commande `` CMD`` ou [docker run](https://qiita.com/JhonnyBravo/items/eee5a91682f1d7c72f6e). N'oubliez pas de commencer par ʻexec pour` `docker stop pour vous avertir correctement d'un exécutable` ʻENTRYPOINT '' de longue durée.

FROM ubuntu
ENTRYPOINT exec top -b

L'exécution de cette image montre un seul processus PID 1.

$ docker run -it --rm --name test top

Mem: 1704520K used, 352148K free, 0K shrd, 0K buff, 140368121167873K cached
CPU:   5% usr   0% sys   0% nic  94% idle   0% io   0% irq   0% sirq
Load average: 0.08 0.03 0.05 2/98 6
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
    1     0 root     R     3164   0%   0% top -b

Nettoyer avec `` docker stop '':

$ /usr/bin/time docker stop test

test
real	0m 0.20s
user	0m 0.02s
sys	0m 0.04s

Si vous oubliez d'ajouter ʻexec`` au début de ʻENTRYPOINT``:

FROM ubuntu
ENTRYPOINT top -b
CMD --ignored-param1

Vous pouvez ensuite le faire (nommez l'étape suivante).

$ docker run -it --name test top --ignored-param2

Mem: 1704184K used, 352484K free, 0K shrd, 0K buff, 140621524238337K cached
CPU:   9% usr   2% sys   0% nic  88% idle   0% io   0% irq   0% sirq
Load average: 0.01 0.02 0.05 2/101 7
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
    1     0 root     S     3168   0%   0% /bin/sh -c top -b cmd cmd2
    7     1 root     R     3164   0%   0% top -b

La sortie de top montre que le `ʻENTRYPOINT`` spécifié n'est pas le PID 1.

Si vous exécutez ensuite le test d'arrêt du docker '', le conteneur ne s'arrêtera pas avec succès. Après le timeout, la commande stop '' force l'envoi d'un `` SIGKILL ''.

$ docker exec -it test ps aux

PID   USER     COMMAND
    1 root     /bin/sh -c top -b cmd cmd2
    7 root     top -b
    8 root     ps aux

$ /usr/bin/time docker stop test

test
real	0m 10.19s
user	0m 0.04s
sys	0m 0.03s

Comprendre l'interaction entre CMD et ```ENTRYPOINT``

Les instructions CMD et ENTRYPOINT`` définissent les commandes qui sont exécutées lorsque le conteneur est exécuté. Voici les règles qui décrivent la collaboration entre `` CMD`` et ENTRYPOINT``.

  1. Le Dockerfile doit spécifier au moins une commande CMD ou ```ENTRYPOINT``.
  2. Si vous voulez utiliser ʻexecutable`` dans un conteneur, vous devez définir ʻENTRYPOINT``.
  3. CMD doit être utilisé comme moyen de définir les arguments par défaut de la commande ```ENTRYPOINT`` ou comme moyen d'exécuter des commandes ad hoc dans un conteneur.
  4. L'exécution du conteneur avec des arguments alternatifs écrasera `` CMD ''.

Le tableau suivant montre les commandes exécutées pour différentes combinaisons ʻENTRYPOINT`` / `CMD``.

No ENTRYPOINT ENTRYPOINT exec_entry p1_entry ENTRYPOINT [“exec_entry”, “p1_entry”]
No CMD error, not allowed /bin/sh -c exec_entry p1_entry
CMD [“exec_cmd”, “p1_cmd”] exec_cmd p1_cmd /bin/sh -c exec_entry p1_entry
CMD [“p1_cmd”, “p2_cmd”] p1_cmd p2_cmd /bin/sh -c exec_entry p1_entry
CMD exec_cmd p1_cmd /bin/sh -c exec_cmd p1_cmd /bin/sh -c exec_entry p1_entry

** Attention **

Si CMD est défini à partir de l'image de base, le réglage ```ENTRYPOINTréinitialisera CMDà une valeur vide. Vous devez définir CMD '' dans l'image courante pour définir la valeur dans ce scénario.

VOLUME

VOLUME ["/data"]

L'instruction VOLUME '' crée un point de montage avec le nom spécifié et le marque comme contenant un volume monté en externe à partir de l'hôte natif ou d'un autre conteneur. La valeur est le tableau JSON VOLUME ["/ var / log /"] , ou VOLUME / var / logou Il peut s'agir d'une chaîne simple avec plusieurs arguments, tels que VOLUME / var / log / var / db``. Consultez Partage de directeurs via des volumes (https://docs.docker.com/storage/volumes/) pour plus d'informations, des cas d'utilisation et des instructions de montage via le client Docker.

La commande docker run initialise le volume nouvellement créé avec les données qui existent à l'emplacement spécifié dans l'image de base. Par exemple, considérez l'extrait de code Dockerfile suivant:

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

Ce Dockerfile est un docker run qui crée un nouveau point de montage sur / myvol et met un fichier Greeting sur le volume nouvellement créé. Ce sera l'image à copier.

Précautions pour la spécification du volume

Notez ce qui suit à propos des volumes Dockerfile:

USER

USER <user>[:<group>]

Ou

USER <UID>[:<GID>]

L'instruction ʻUSER`` est le nom d'utilisateur (ou UID) et éventuellement le groupe d'utilisateurs (ou UID) utilisé au moment de l'exécution de l'image et dans les instructions suivant RUN``, CMD`` et ʻENTRYPOINT`` dans le Dockerfile. Ou GID).

Si vous spécifiez un groupe d'utilisateurs, gardez à l'esprit que les utilisateurs n'ont que l'appartenance au groupe spécifié. Les autres appartenances aux groupes configurés sont ignorées.

** Avertissement **

Si l'utilisateur n'a pas de groupe principal, l'image (ou l'étape suivante) s'exécutera dans le groupe racine.

Sous Windows, vous devez d'abord créer un utilisateur s'il ne s'agit pas d'un compte intégré. Cela peut être fait en utilisant la commande `` netuser '', qui est appelée dans le cadre du Dockerfile.

FROM microsoft/windowsservercore
# Create Windows user in the container
RUN net user /add patrick
# Set it for subsequent commands
USER patrick

WORKDIR

WORKDIR /path/to/workdir

L'instruction WORKDIR est le répertoire de travail de toutes les instructions suivantes RUN, CMD, ```ENTRYPOINT, COPYet `ʻADDdans le Dockerfile. Ensemble. Si WORKDIR '' n'existe pas, il sera créé même s'il n'est pas utilisé dans les instructions Dockerfile suivantes.

L'instruction WORKDIR '' peut être utilisée plusieurs fois dans un Dockerfile. Si un chemin relatif est spécifié, il sera relatif au chemin de l'instruction précédente WORKDIR``. Par exemple:

WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd

La sortie de la dernière commande pwd '' dans ce Dockerfile est / a / b / c``.

L'instruction WORKDIR peut résoudre les variables d'environnement précédemment définies à l'aide de ```ENV``. Vous ne pouvez utiliser que des variables d'environnement définies explicitement dans le Dockerfile. Par exemple:

ENV DIRPATH=/path
WORKDIR $DIRPATH/$DIRNAME
RUN pwd

La sortie de la dernière commande pwd dans ce Dockerfile sera / path / $ DIRNAME.

ARG

ARG <name>[=<default value>]

L'instruction `ʻARG utilise l'indicateur --build-arg = `` lorsque l'utilisateur construit docker build Définit les variables qui peuvent être transmises au générateur avec la commande. Si l'utilisateur spécifie un argument de construction qui n'est pas défini dans le Dockerfile, la construction affichera un avertissement.

[Warning] One or more build-args [foo] were not consumed.

Le Dockerfile peut contenir une ou plusieurs instructions «ARG». Par exemple, ce qui suit est un Dockerfile valide.

FROM busybox
ARG user1
ARG buildno
# ...

** Avertissement **

Nous ne recommandons pas d'utiliser des variables de construction pour transmettre des informations sensibles telles que les clés github, les informations d'identification de l'utilisateur, etc. Les valeurs des variables au moment de la construction sont visibles par tous les utilisateurs de l'image à l'aide de la commande `` docker history ''.

Pour un moyen sécurisé d'utiliser des informations confidentielles lors de la création d'une image, utilisez BuildKit pour créer l'image (https://docs.docker.com/develop/develop-images/build_enhancements/#new- Voir docker-build-secret-information).

Valeur par défaut

L'instruction «ARG» peut éventuellement inclure une valeur par défaut.

FROM busybox
ARG user1=someuser
ARG buildno=1
# ...

Si l'instruction `ʻARG`` a une valeur par défaut et qu'aucune valeur n'est passée au moment de la construction, le constructeur utilisera la valeur par défaut.

Scope

La définition de la variable «ARG» prend effet à partir de la ligne définie dans le Dockerfile, pas de l'utilisation d'arguments sur la ligne de commande ou ailleurs. Par exemple, considérez le Dockerfile suivant.

FROM busybox
USER ${user:-some_user}
ARG user
USER $user
# ...

L'utilisateur crée ce fichier en appelant la commande suivante:

$ docker build --build-arg user=what_user .

La deuxième ligne, ʻUSER``, donne la valeur some_user`` parce que la variable utilisateur est définie dans la troisième ligne suivante. La quatrième ligne, ʻUSER, évalue` `what_user lorsque l'utilisateur est défini et la valeur what_user est passée à la ligne de commande. Avant d'être défini par l'instruction `ʻARG, l'utilisation d'une variable videra la chaîne.

L'instruction «ARG» sort du champ d'application à la fin de l'étape de construction dans laquelle elle est définie. Pour utiliser «arg» en plusieurs étapes, chaque étape doit inclure l'instruction «ARG».

FROM busybox
ARG SETTINGS
RUN ./run/setup $SETTINGS

FROM busybox
ARG SETTINGS
RUN ./run/other $SETTINGS

Utilisation de la variable «ARG»

Vous pouvez utiliser l'instruction «ARG» ou «ENV» pour spécifier les variables disponibles dans l'instruction «RUN». Les variables d'environnement définies à l'aide de l'instruction «ENV» écrasent toujours l'instruction «ARG» du même nom. Considérez ce Dockerfile, qui contient les instructions «ENV» et «ARG».

FROM ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER=v1.0.0
RUN echo $CONT_IMG_VER

Ensuite, supposons que cette image a été créée avec la commande suivante:

$ docker build --build-arg CONT_IMG_VER=v2.0.1 .

Dans ce cas, l'instruction RUN utilise v1.0.0 au lieu du paramètre ARG`` passé par user: v2.0.1``. Ce comportement est similaire à un script shell dans lequel une variable à portée locale écrase une variable passée en argument ou une variable héritée de l'environnement d'un point de vue définitionnel.

En utilisant l'exemple ci-dessus, mais avec une spécification différente «ENV», vous pouvez créer une interaction plus pratique entre les instructions «ARG» et «ENV».

FROM ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER=${CONT_IMG_VER:-v1.0.0}
RUN echo $CONT_IMG_VER

Contrairement à l'instruction «ARG», la valeur «ENV» est toujours conservée dans l'image construite. Prenons un docker build sans le drapeau --build-arg:

$ docker build .

En utilisant cet exemple de Dockerfile, CONT_IMG_VER est toujours conservé dans l'image, mais il s'agit de la v1.0.0 car c'est la valeur par défaut définie à la ligne 3 par l'instruction ```ENV``. ..

En utilisant la technique d'expansion variable de cet exemple, vous pouvez passer des arguments à partir de la ligne de commande Vous pouvez utiliser l'instruction `ʻENV`` pour les conserver dans l'image finale. L'expansion variable n'est prise en charge qu'avec une combinaison limitée d'instructions Dockerfile.

«ARG» prédéfini

Docker dispose d'un ensemble de variables prédéfinies «ARG» qui peuvent être utilisées sans l'instruction «ARG» correspondante dans le Dockerfile.

Pour les utiliser, passez-les simplement sur la ligne de commande avec des indicateurs.

--build-arg <varname>=<value>

Par défaut, ces variables prédéfinies sont exclues de la sortie de docker history ''. L'exclusion des variables prédéfinies réduit le risque de fuite accidentelle d'informations d'identification sensibles dans la variable HTTP_PROXY ''.

Envisagez de créer le Dockerfile suivant en utilisant, par exemple, `` --build-arg HTTP_PROXY = http: // user: pass @ proxy.lon.example.com ''.

FROM ubuntu
RUN echo "Hello World"

Dans ce cas, la valeur de la variable HTTP_PROXY '' n'est pas disponible dans historique du docker '' et n'est pas mise en cache. Si vous modifiez l'emplacement et que le serveur proxy est changé en `` http: // utilisateur: pass @ proxy.sfo.example.com '', les versions suivantes n'auront pas de cache manquant.

Si vous devez remplacer ce comportement, vous pouvez le remplacer en ajoutant l'instruction `ʻARG`` à votre Dockerfile comme suit:

FROM ubuntu
ARG HTTP_PROXY
RUN echo "Hello World"

Lorsque vous construisez ce Dockerfile, HTTP_PROXY '' est enregistré dans Docker history '', et changer sa valeur invalidera le cache de construction.

Global Scope Automatic Platform ARG

Cette fonctionnalité n'est disponible que si vous utilisez le backend BuildKit.

Docker prédéfinit un ensemble de variables `ʻARGavec des informations sur la plate-forme du nœud effectuant la construction (plate-forme de construction) et la plate-forme de l'image résultante (plate-forme cible). La plateforme cible peut être spécifiée avec le drapeau --platform`` dans docker build.

Les variables «ARG» suivantes sont définies automatiquement.

Ces arguments sont définis dans la portée globale et ne peuvent pas être utilisés automatiquement dans la phase de construction ou dans la commande RUN. Pour exposer l'un de ces arguments au cours de l'étape de génération, redéfinissez-le sans valeur.

Par exemple:

FROM alpine
ARG TARGETPLATFORM
RUN echo "I'm building for $TARGETPLATFORM"

Impact sur le cache de compilation

La variable «ARG» n'est pas conservée dans l'image construite comme la variable «ENV». Cependant, la variable «ARG» affecte le cache de construction de la même manière. Si le Dockerfile définit une variable ʻARG`` avec une valeur différente de celle des versions précédentes, vous obtiendrez un `cache miss`` lors de la première utilisation au lieu de cette définition. En particulier, toutes les instructions «RUN» qui suivent l'instruction «ARG» utilisent implicitement la variable «ARG» (comme variable d'environnement), ce qui peut conduire à des échecs de cache. Toutes les variables prédéfinies «ARG» sont exclues du cache à moins qu'il n'y ait une instruction «ARG» correspondante dans le Dockerfile.

Par exemple, considérez les deux fichiers Dockerfiles suivants.

FROM ubuntu
ARG CONT_IMG_VER
RUN echo $CONT_IMG_VER

FROM ubuntu
ARG CONT_IMG_VER
RUN echo hello

Si vous spécifiez --build-arg CONT_IMG_VER = <valeur> '' sur la ligne de commande, la deuxième ligne ne provoquera pas de cache manquant dans les deux cas. La troisième ligne provoque un échec du cache. ```ARG CONT_IMG_VER identifie la ligne RUN comme étant identique à l'exécution de CONT_IMG_VER = <valeur> echo hello, elle sera donc mise en cache lorsque <value> est modifiée. Une erreur se produira.

Prenons un autre exemple sur la même ligne de commande.

FROM ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER=$CONT_IMG_VER
RUN echo $CONT_IMG_VER

Dans cet exemple, l'erreur de cache se produit sur la ligne 3. Une erreur de cache se produit car la valeur de la variable «ENV» fait référence à la variable «ARG» et cette variable est modifiée sur la ligne de commande. Dans cet exemple, la commande «ENV» contient une valeur dans l'image.

Si l'instruction ʻENV`` remplace l'instruction ʻARG`` avec le même nom, comme dans ce Dockerfile:

FROM ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER=hello
RUN echo $CONT_IMG_VER

Dans la troisième ligne, la valeur de CONT_IMG_VER '' est une constante (bonjour), donc aucun échec de cache ne se produit. Par conséquent, les variables d'environnement et les valeurs utilisées dans RUN '' (ligne 4) ne changent pas entre les builds.

ONBUILD

ONBUILD <INSTRUCTION>

L'instruction «ONBUILD» ajoute à l'image une instruction de déclenchement qui sera exécutée plus tard lorsque l'image sera utilisée comme base pour une autre construction. Le déclencheur s'exécute dans le contexte d'une construction en aval, comme s'il était inséré immédiatement après l'instruction `` FROM '' dans le Dockerfile en aval.

Toute instruction de construction peut être enregistrée comme déclencheur.

Ceci est utile lors de la construction d'une image qui sera utilisée comme base pour la construction d'autres images. Par exemple, un environnement de construction d'application ou un démon qui peut être personnalisé avec votre propre configuration.

Par exemple, si l'image est un générateur d'application Python réutilisable, vous devrez peut-être ajouter le code source de l'application à un répertoire spécifique, puis appeler le script de génération. Vous ne pouvez pas simplement appeler ```ADDet RUN`` maintenant car le code source de l'application n'est pas encore accessible et varie d'une version à l'autre. Vous pouvez également fournir le Dockerfile de la plaque chauffante au développeur de l'application et le copier et le coller dans l'application, Ceci est inefficace, sujet aux erreurs et mélangé avec du code spécifique à l'application, ce qui rend la mise à jour difficile.

La solution est d'utiliser «ONBUILD» pour enregistrer une pré-instruction à exécuter plus tard dans la prochaine étape de construction.

Le mécanisme est le suivant.

  1. Lorsque la commande «ONBUILD» est émise, le générateur ajoute un déclencheur aux métadonnées de l'image en cours de construction. Sinon, l'instruction n'a aucun effet sur la construction actuelle.
  2. À la fin de la construction, une liste de tous les déclencheurs est enregistrée sous la clé `ʻOnBuilddans le manifeste de l'image. Ils peuvent être inspectés avec la commande docker inspect ''.
  3. Vous pouvez utiliser ultérieurement l'instruction FROM '' pour utiliser l'image comme base pour une nouvelle construction. Dans le cadre du traitement des instructions FROM '', le constructeur en aval recherche les déclencheurs ```ONBUILDet les exécute dans le même ordre où ils ont été enregistrés. Si l'un des déclencheurs échoue, l'instruction FROM '' sera abandonnée et la construction échouera. Si tous les déclencheurs réussissent, l'instruction `` FROM '' est terminée et la construction se poursuit normalement.
  4. Le déclencheur sera effacé de l'image finale après l'exécution. En d'autres termes, ils ne sont pas hérités par les builds «petits-enfants».

Par exemple, vous pouvez ajouter quelque chose comme ceci:

ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src

** Avertissement **

ʻONBUILD ONBUILD`` n'est pas autorisé à enchaîner les instructions ʻONBUILD``.

L'instruction ONBUILD '' peut ne pas déclencher l'instruction FROM '' ou `` MAINTAINER ''.

STOPSIGNAL

STOPSIGNAL signal

L'instruction STOPSIGNAL '' définit le signal d'appel système envoyé au conteneur pour se terminer. Ce signal doit être un nombre non signé valide qui correspond à une position dans la table syscall '' du noyau (par exemple 9), ou un nom de signal sous la forme SIGNAME '' (par exemple SIGKILL ''). Je peux.

HEALTHCHECK

La déclaration `` HEALTHCHECK '' se présente sous deux formes:

L'instruction `` HEALTHCHECK '' indique à Docker comment tester le conteneur pour s'assurer qu'il fonctionne toujours. Cela vous permet de détecter les cas où le serveur Web est bloqué dans une boucle infinie et ne peut pas gérer de nouvelles connexions, même si le processus serveur est toujours en cours d'exécution.

Si un conteneur a une vérification de l'état spécifiée, il a un état d'intégrité en plus de l'état normal. Cet état est initialement "Démarrage". Si vous réussissez la vérification de l'état, la vérification de l'état sera "normale" (quel que soit l'état précédent). Après un certain nombre de pannes consécutives, cela devient "anormal".

Les options qui apparaissent avant `` CMD '' sont:

La vérification de l'état s'exécute quelques secondes après le premier démarrage du conteneur, puis à nouveau quelques secondes après la fin de chaque vérification précédente.

Si une vérification dure plus longtemps que les secondes du délai d'expiration, la vérification est considérée comme infructueuse.

Les échecs successifs des contrôles de santé doivent être retentés pour que le conteneur soit considéré comme anormal.

La période de début fournit le temps d'initialisation du conteneur, ce qui nécessite du temps pour le bootstrap. Les échecs de sonde pendant cette période ne comptent pas dans le nombre maximal de tentatives. Toutefois, si la vérification de l'état réussit pendant la période de démarrage, le conteneur est considéré comme démarré et tous les échecs consécutifs sont comptés dans le nombre maximal de tentatives.

Il ne peut y avoir qu'une seule instruction HEALTHCHECK '' dans un Dockerfile. Si vous répertoriez plusieurs éléments, seul le dernier HEALTHCHECK '' sera valide.

La commande après le mot-clé CMD est soit une commande shell (par exemple, HEALTHCHECK CMD / bin / check-running) ou un tableau ```exec (comme toute autre commande Dockerfile). (Voir `ʻENTRYPOINT pour plus d'informations)

L'état de fin de la commande indique l'état de santé du conteneur. Les valeurs valides sont:

Par exemple, pour vérifier toutes les 5 minutes et permettre au serveur Web de servir la page principale de votre site dans les 3 secondes:

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

Pour aider au débogage d'une sonde ayant échoué, le texte de sortie (encodé en UTF-8) que la commande écrit dans stdout '' ou stderr '' est stocké dans l'état de santé et peut être recherché par `` docker inspect ''. .. Cette sortie doit être courte (actuellement, seuls les 4096 premiers octets sont stockés).

Lorsque l'état de santé d'un conteneur change, un événement `` health_status '' est généré avec le nouvel état.

La fonctionnalité `` HEALTHCHECK '' a été ajoutée dans Docker 1.12.

SHELL

SHELL ["executable", "parameters"]

Vous pouvez utiliser l'instruction SHELL '' pour remplacer le shell par défaut utilisé pour les commandes de style shell. Le shell par défaut pour Linux est ["/ bin / sh", "-c"] . Le shell par défaut pour Windows est ["cmd", "/ S", "/ C"] . L'instruction SHELL '' doit être au format JSON dans le Dockerfile.

L'instruction SHELL '' est disponible sur Windows avec deux shells natifs couramment utilisés ( cmd '' et powershell '') et un shell alternatif qui inclut sh ''. Particulièrement utile.

L'instruction SHELL '' peut être affichée plusieurs fois. Chaque instruction SHELL '' écrase toutes les instructions `` SHELL '' précédentes et affecte toutes les instructions suivantes. Exemple:

FROM microsoft/windowsservercore

# Executed as cmd /S /C echo default
RUN echo default

# Executed as cmd /S /C powershell -command Write-Host default
RUN powershell -command Write-Host default

# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]
RUN Write-Host hello

# Executed as cmd /S /C echo hello
SHELL ["cmd", "/S", "/C"]
RUN echo hello

Les instructions suivantes peuvent être affectées par l'instruction `` SHELL '' lorsque le format shell est utilisé dans le Dockerfile:

L'exemple suivant est un modèle courant trouvé sur Windows qui peut être simplifié à l'aide de l'instruction `` SHELL ''.

RUN powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"

La commande appelée par docker ressemble à ceci:

cmd /S /C powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"

Ceci est inefficace pour deux raisons. Tout d'abord, le processeur de commande indésirable cmd.exe '' (également connu sous le nom de shell) est appelé. Deuxièmement, chaque instruction RUN '' de style shell nécessite une `` commande powershell '' supplémentaire avant la commande.

Vous pouvez utiliser l'un des deux mécanismes pour rendre cela plus efficace. La première consiste à utiliser le format JSON de la commande RUN, qui ressemble à ceci:

RUN ["powershell", "-command", "Execute-MyCmdlet", "-param1 \"c:\\foo.txt\""]

Le format JSON est clair et n'utilise pas le cmd.exe '' inutile, mais les guillemets et les échappements nécessitent des informations plus détaillées. Un autre mécanisme consiste à utiliser l'instruction SHELL '' et le formulaire shell. Cela rend la syntaxe plus naturelle pour les utilisateurs Windows, en particulier lorsqu'elle est combinée avec des directives d'analyseur d'échappement.

# escape=`

FROM microsoft/nanoserver
SHELL ["powershell","-command"]
RUN New-Item -ItemType Directory C:\Example
ADD Execute-MyCmdlet.ps1 c:\example\
RUN c:\example\Execute-MyCmdlet -sample 'hello world'

Résultat de l'exécution:

PS E:\docker\build\shell> docker build -t shell .
Sending build context to Docker daemon 4.096 kB
Step 1/5 : FROM microsoft/nanoserver
 ---> 22738ff49c6d
Step 2/5 : SHELL powershell -command
 ---> Running in 6fcdb6855ae2
 ---> 6331462d4300
Removing intermediate container 6fcdb6855ae2
Step 3/5 : RUN New-Item -ItemType Directory C:\Example
 ---> Running in d0eef8386e97


    Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       10/28/2016  11:26 AM                Example


 ---> 3f2fbf1395d9
Removing intermediate container d0eef8386e97
Step 4/5 : ADD Execute-MyCmdlet.ps1 c:\example\
 ---> a955b2621c31
Removing intermediate container b825593d39fc
Step 5/5 : RUN c:\example\Execute-MyCmdlet 'hello world'
 ---> Running in be6d8e63fe75
hello world
 ---> 8e559e9bf424
Removing intermediate container be6d8e63fe75
Successfully built 8e559e9bf424
PS E:\docker\build\shell>

L'instruction SHELL '' peut également être utilisée pour changer le comportement du shell. Par exemple, sous Windows, vous pouvez utiliser SHELL cmd / S / C / V: ON | OFF '' pour changer la sémantique étendue des variables d'environnement différées.

L'instruction `` SHELL '' peut également être utilisée sous Linux si un shell alternatif tel que zsh, csh, tcsh est requis.

La fonctionnalité `` SHELL '' a été ajoutée dans Docker 1.12.

Fonction de montage externe

Cette fonctionnalité n'est disponible que si vous utilisez le backend BuildKit.

docker build est activé en utilisant une implémentation externe du générateur avec des directives de syntaxe, telles que le montage du cache, le build secret, le transfert ssh, etc. Prend en charge les fonctionnalités expérimentales. Consultez la documentation du référentiel BuildKit (https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md) pour ces fonctionnalités.

Exemple de description de Dockerfile

Voici quelques exemples de syntaxe Dockerfile:

# Nginx
#
# VERSION               0.0.1

FROM      ubuntu
LABEL Description="This image is used to start the foobar executable" Vendor="ACME Products" Version="1.0"
RUN apt-get update && apt-get install -y inotify-tools nginx apache2 openssh-server

# Firefox over VNC
#
# VERSION               0.3

FROM ubuntu

# Install vnc, xvfb in order to create a 'fake' display and firefox
RUN apt-get update && apt-get install -y x11vnc xvfb firefox
RUN mkdir ~/.vnc
# Setup a password
RUN x11vnc -storepasswd 1234 ~/.vnc/passwd
# Autostart firefox (might not be the best way, but it does the trick)
RUN bash -c 'echo "firefox" >> /.bashrc'

EXPOSE 5900
CMD    ["x11vnc", "-forever", "-usepw", "-create"]

# Multiple images example
#
# VERSION               0.1

FROM ubuntu
RUN echo foo > bar
# Will output something like ===> 907ad6c2736f

FROM ubuntu
RUN echo moo > oink
# Will output something like ===> 695d7793cbe4

# You'll now have two images, 907ad6c2736f with /bar, and 695d7793cbe4 with
# /oink.

Recommended Posts

Dockerfile Reference traduction japonaise
Docker mysql Quick Reference traduction japonaise
Traduction japonaise sosreport
traduction japonaise man systemd
streamlit explication traduction japonaise
Streamlit tutorial traduction japonaise
man systemd.service traduction japonaise
man nftables traduction japonaise
docker-compose --aide à la traduction en japonais
docker help traduction en japonais
docker build --aider la traduction en japonais
Traduction japonaise du manuel sysstat
Traduction japonaise du manuel Linux
docker run --aider la traduction en japonais
Tutoriel Biopython et traduction japonaise du livre de recettes (4.3)
Tutoriel Biopython et traduction japonaise de Cookbook (4.1)
Tutoriel Biopython et traduction japonaise de Cookbook (4.5)
Tutoriel Biopython et traduction japonaise du livre de recettes (4.7)
Traduction japonaise du manuel man-db
Traduction japonaise appropriée de pytorch tensor_tutorial
Tutoriel Biopython et traduction japonaise du livre de recettes (4.9)
Tutoriel Biopython et traduction japonaise du livre de recettes (4.6)
Traduction japonaise du manuel util-linux
Tutoriel Biopython et traduction japonaise du livre de recettes (4.2)
Tutoriel Biopython et traduction japonaise de Cookbook
Traduction japonaise du manuel iproute2
Traduction japonaise de documents Apache Spark - Soumission d'applications
Traduction japonaise de documents Apache Spark - Démarrage rapide
Mise en route: 30 secondes de traduction en japonais Keras
Tutoriel Biopython et traduction japonaise du livre de recettes (Chapitre 1, 2)
Traduction japonaise: PEP 20 - Le Zen de Python