Docker
Dockerfiles

Introduction

Remarques

# This is a comment
INSTRUCTION arguments

# escape=`

HelloWorld Dockerfile

Un fichier Dockerfile minimal ressemble à ceci:

FROM alpine
CMD ["echo", "Hello StackOverflow!"]

Cela indiquera à Docker de créer une image basée sur Alpine ( FROM ), une distribution minimale pour les conteneurs et d'exécuter une commande spécifique ( CMD ) lors de l'exécution de l'image résultante.

Construisez et exécutez-le:

docker build -t hello .
docker run --rm hello

Cela va sortir:

Hello StackOverflow!

Copier des fichiers

Pour copier des fichiers à partir du contexte de génération dans une image Docker, utilisez l'instruction COPY :

COPY localfile.txt containerfile.txt

Si le nom du fichier contient des espaces, utilisez la syntaxe alternative:

COPY ["local file", "container file"]

La commande COPY prend en charge les caractères génériques. Il peut être utilisé par exemple pour copier toutes les images dans le répertoire images/ :

COPY *.jpg images/

Remarque: dans cet exemple, les images/ peuvent ne pas exister. Dans ce cas, Docker le créera automatiquement.

Exposer un port

Pour déclarer des ports exposés à partir d'un fichier Docker, utilisez l'instruction EXPOSE :

EXPOSE 8080 8082

Les paramètres des ports exposés peuvent être remplacés à partir de la ligne de commande Docker, mais il est recommandé de les définir explicitement dans le fichier Docker car cela aide à comprendre ce que fait une application.

Dockerfiles meilleures pratiques

Opérations communes de groupe

Docker construit des images en tant que collection de calques. Chaque couche ne peut ajouter que des données, même si ces données indiquent qu'un fichier a été supprimé. Chaque instruction crée un nouveau calque. Par exemple:

RUN apt-get -qq update
RUN apt-get -qq install some-package

A quelques inconvénients:

• Il va créer deux couches, produisant une image plus grande.
• Utiliser apt-get update seul dans une instruction RUN entraîne des problèmes de mise en cache et, par la suite, les instructions d' apt-get install peuvent échouer . Supposons que vous modifiez ultérieurement apt-get install en ajoutant des paquets supplémentaires, puis que docker interprète les instructions initiales et modifiées comme étant identiques et réutilise le cache des étapes précédentes. En conséquence, la commande apt-get update n'est pas exécutée car sa version en cache est utilisée lors de la génération.

Au lieu de cela, utilisez:

RUN apt-get -qq update && \
    apt-get -qq install some-package

comme cela ne produit qu'une couche.

Mentionnez le mainteneur

C'est généralement la deuxième ligne du fichier Docker. Il indique qui est responsable et sera en mesure d'aider.

LABEL maintainer John Doe <[email protected]>

Si vous le sautez, cela ne cassera pas votre image. Mais cela n’aidera pas non plus vos utilisateurs.

Être concis

Gardez votre fichier Dockerfile court. Si une configuration complexe est nécessaire, envisagez d'utiliser un script dédié ou de configurer des images de base.

Instruction utilisateur

USER daemon

L'instruction USER définit le nom d'utilisateur ou l'UID à utiliser lors de l'exécution de l'image et pour toutes les instructions RUN , CMD et ENTRYPOINT qui suivent dans le Dockerfile .

Instruction WORKDIR

WORKDIR /path/to/workdir

L'instruction WORKDIR définit le répertoire de travail pour toutes les instructions RUN , CMD , ENTRYPOINT , COPY et ADD qui le suivent dans le fichier Dockerfile. Si le WORKDIR n'existe pas, il sera créé même s'il n'est utilisé dans aucune instruction Dockerfile ultérieure.

Il peut être utilisé plusieurs fois dans le Dockerfile . Si un chemin relatif est fourni, il sera relatif au chemin de l'instruction WORKDIR précédente. Par exemple:

WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd

La sortie de la commande pwd finale dans ce Dockerfile serait /a/b/c .

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

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

La sortie de la commande pwd finale dans ce fichier Docker serait /path/$DIRNAME

Instruction VOLUME

VOLUME ["/data"]

L'instruction VOLUME crée un point de montage avec le nom spécifié et le marque comme contenant des volumes montés en externe à partir d'un hôte natif ou d'autres conteneurs. La valeur peut être un tableau JSON, VOLUME ["/var/log/"] ou une chaîne simple avec plusieurs arguments, tels que VOLUME /var/log ou VOLUME /var/log /var/db . Pour plus d'informations / exemples et instructions de montage via le client Docker, reportez-vous à la documentation sur les répertoires partagés via des volumes.

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

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

Ce fichier Dockerfile génère une image qui provoque l'exécution du menu fixe, pour créer un nouveau point de montage sur / myvol et copier le fichier de message d'accueil dans le volume nouvellement créé.

Remarque: Si des étapes de génération modifient les données dans le volume après sa déclaration, ces modifications seront ignorées.

Remarque: La liste est analysée en tant que tableau JSON, ce qui signifie que vous devez utiliser des guillemets (“) autour des mots et non des guillemets simples (').

Instruction COPY

COPY a deux formes:

COPY <src>... <dest>
COPY ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

L'instruction COPY copie les nouveaux fichiers ou répertoires de <src> et les ajoute au système de fichiers du conteneur sur le chemin <dest> .

Plusieurs ressources <src> peuvent être spécifiées, mais elles doivent être relatives au répertoire source en cours de construction (contexte de la génération).

Chaque <src> peut contenir des caractères génériques et la correspondance sera effectuée à l'aide des règles du filepath.Match de filepath.Match de Go. Par exemple:

COPY hom* /mydir/        # adds all files starting with "hom"
COPY hom?.txt /mydir/    # ? is replaced with any single character, e.g., "home.txt"

Le <dest> est un chemin absolu ou un chemin relatif à WORKDIR dans lequel la source sera copiée dans le conteneur de destination.

COPY test relativeDir/   # adds "test" to `WORKDIR`/relativeDir/
COPY test /absoluteDir/  # adds "test" to /absoluteDir/

Tous les nouveaux fichiers et répertoires sont créés avec un UID et un GID de 0.

Remarque: Si vous générez à l'aide de stdin ( docker build - < somefile ), il n'y a pas de contexte de génération, COPY ne peut donc pas être utilisé.

COPY obéit aux règles suivantes:

• Le chemin <src> doit se trouver dans le contexte de la génération; vous ne pouvez pas COPY ../squelque chose / quelque chose, car la première étape de la construction d'un menu fixe consiste à envoyer le répertoire de contexte (et ses sous-répertoires) au démon docker.

• Si <src> est un répertoire, tout le contenu du répertoire est copié, y compris les métadonnées du système de fichiers. Remarque: le répertoire lui-même n'est pas copié, mais uniquement son contenu.

• Si <src> est un autre type de fichier, il est copié individuellement avec ses métadonnées. Dans ce cas, si <dest> se termine par une barre oblique /, il sera considéré comme un répertoire et le contenu de <src> sera écrit dans <dest>/base(<src>) .

• Si plusieurs ressources <src> sont spécifiées, que ce soit directement ou en raison de l'utilisation d'un caractère générique, alors <dest> doit être un répertoire et doit se terminer par une barre oblique / .

• Si <dest> ne se termine pas par une barre oblique, elle sera considérée comme un fichier normal et le contenu de <src> sera écrit sur <dest> .

• Si <dest> n'existe pas, il est créé avec tous les répertoires manquants sur son chemin.

Instruction ENV et ARG

ENV

ENV <key> <value>
ENV <key>=<value> ...

L'instruction ENV définit la variable d'environnement <key> sur la valeur. Cette valeur sera dans l'environnement de toutes les commandes Dockerfile «descendantes» et peut également être remplacée en ligne.

L'instruction ENV a deux formes. Le premier formulaire, ENV <key> <value> , définira une variable unique sur une valeur. La chaîne entière après le premier espace sera traitée comme la <value> - y compris les caractères tels que les espaces et les guillemets.

La deuxième forme, ENV <key>=<value> ... , permet de définir plusieurs variables à la fois. Notez que la seconde forme utilise le signe égal (=) dans la syntaxe, alors que la première forme ne le fait pas. Comme pour l'analyse de ligne de commande, les guillemets et les barres obliques inverses peuvent être utilisés pour inclure des espaces dans les valeurs.

Par exemple:

ENV myName="John Doe" myDog=Rex\ The\ Dog \
    myCat=fluffy

et

ENV myName John Doe
ENV myDog Rex The Dog
ENV myCat fluffy

produira les mêmes résultats nets dans le conteneur final, mais la première forme est préférable car elle produit une seule couche de cache.

Les variables d'environnement définies à l'aide de ENV persisteront lorsqu'un conteneur est exécuté à partir de l'image résultante. Vous pouvez afficher les valeurs à l'aide de docker run --env <key>=<value> et les modifier à l'aide de docker run --env <key>=<value> .

ARG

Si vous ne souhaitez pas conserver le paramètre, utilisez plutôt ARG . ARG définira les environnements uniquement pendant la construction. Par exemple, paramètre

ENV DEBIAN_FRONTEND noninteractive

peut confondre les utilisateurs d' apt-get sur une image basée sur Debian quand ils entrent dans le conteneur dans un contexte interactif via docker exec -it the-container bash .

Au lieu de cela, utilisez:

ARG DEBIAN_FRONTEND noninteractive

Vous pouvez également définir une valeur pour une seule commande uniquement en utilisant:

RUN <key>=<value> <command>

Instruction EXPOSE

EXPOSE <port> [<port>...]

L'instruction EXPOSE informe Docker que le conteneur écoute les ports réseau spécifiés au moment de l'exécution. EXPOSE ne rend pas les ports du conteneur accessibles à l'hôte. Pour ce faire, vous devez utiliser l' -p pour publier une plage de ports ou l' -P pour publier tous les ports exposés. Ces indicateurs sont utilisés dans le docker run [OPTIONS] IMAGE [COMMAND][ARG...] pour exposer le port à l'hôte. Vous pouvez exposer un numéro de port et le publier en externe sous un autre numéro.

docker run -p 2500:80 <image name>

Cette commande crée un conteneur portant le nom <image> et lie le port 80 du conteneur au port 2500 de la machine hôte.

Pour configurer la redirection de port sur le système hôte, consultez l’ -P . La fonctionnalité réseau Docker prend en charge la création de réseaux sans avoir à exposer les ports du réseau. Pour plus d'informations, consultez la présentation de cette fonctionnalité.

Instruction LABEL

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

L'instruction LABEL ajoute des métadonnées à une image. Un LABEL est une paire clé-valeur. Pour inclure des espaces dans une valeur LABEL , utilisez des guillemets et des barres obliques inverses comme vous le feriez dans l'analyse de ligne de commande. Quelques exemples 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."

Une image peut avoir plusieurs étiquettes. Pour spécifier plusieurs étiquettes, Docker recommande de combiner les étiquettes dans une seule instruction LABEL si possible. Chaque instruction LABEL produit un nouveau calque qui peut entraîner une image inefficace si vous utilisez plusieurs étiquettes. Cet exemple se traduit par une couche d'image unique.

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

Ce qui précède peut aussi être écrit comme suit:

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

Les étiquettes sont additives, y compris les LABEL dans les images FROM . Si Docker rencontre une étiquette / clé qui existe déjà, la nouvelle valeur remplace toutes les étiquettes précédentes avec des clés identiques.

Pour afficher les étiquettes d'une image, utilisez la commande docker inspect.

"Labels": {
    "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"
},

Instruction CMD

L'instruction CMD a trois formes:

CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)

Il ne peut y avoir qu'une seule instruction CMD dans un Dockerfile . Si vous listez plusieurs CMD seul le dernier CMD prendra effet.

Le but principal d'un CMD est de fournir des valeurs par défaut pour un conteneur en cours d'exécution. Ces valeurs par défaut peuvent inclure un exécutable ou omettre l'exécutable. Dans ce cas, vous devez également spécifier une instruction ENTRYPOINT .

Remarque: Si CMD est utilisé pour fournir des arguments par défaut pour l'instruction ENTRYPOINT instructions CMD et ENTRYPOINT doivent être spécifiées avec le format de tableau JSON.

Remarque: Le formulaire d'exécution est analysé en tant que tableau JSON, ce qui signifie que vous devez utiliser des guillemets (“) autour des mots et non des guillemets simples (').

Remarque: Contrairement au formulaire shell, le formulaire exec n'invoque pas un shell de commandes. Cela signifie que le traitement normal du shell ne se produit pas. Par exemple, CMD [ "echo", "$HOME" ] ne fera pas de substitution de variable sur $HOME . Si vous voulez un traitement du shell, utilisez soit la forme du shell, soit exécutez un shell directement, par exemple: CMD [ "sh", "-c", "echo $HOME" ] .

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

Si vous utilisez la forme shell du CMD , la commande s'exécutera dans /bin/sh -c :

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

Si vous voulez exécuter votre commande sans shell, vous devez exprimer la commande en tant que tableau JSON et donner le chemin d'accès complet à l'exécutable. Cette forme de tableau est le format préféré de CMD . Tout paramètre supplémentaire doit être exprimé individuellement sous la forme de chaînes dans le tableau:

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

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

Si l'utilisateur spécifie des arguments pour exécuter le menu fixe, il remplacera la valeur par défaut spécifiée dans CMD .

Remarque: ne confondez pas RUN avec CMD . RUN exécute une commande au moment de la création de l'image et valide le résultat. CMD n'exécute rien au moment de la construction, mais spécifie la commande prévue pour l'image.

Instruction MAINTAINER

MAINTAINER <name>

L'instruction MAINTAINER vous permet de définir le champ Auteur des images générées.

N'UTILISEZ PAS LA DIRECTIVE MAINTAINER

Selon la documentation officielle de Docker, l'instruction MAINTAINER est obsolète. Au lieu de cela, on devrait utiliser l'instruction LABEL pour définir l'auteur des images générées. L'instruction LABEL est plus flexible, permet de définir des métadonnées et peut être facilement visualisée avec le docker inspect commandes docker inspect .

LABEL maintainer="[email protected]"

À partir de l'instruction

FROM <image>

Ou

FROM <image>:<tag>

Ou

FROM <image>@<digest>

L'instruction FROM définit l'image de base pour les instructions suivantes. En tant que tel, un Dockerfile valide doit avoir FROM comme première instruction. L'image peut être n'importe quelle image valide - il est particulièrement facile de commencer en tirant une image des référentiels publics.

FROM doit être la première instruction de non-commentaire du fichier Dockerfile.

FROM peut apparaître plusieurs fois dans un seul fichier Dockerfile afin de créer plusieurs images. Notez simplement le dernier identifiant d'image généré par le commit avant chaque nouvelle commande FROM .

La balise ou les valeurs de résumé sont facultatives. Si vous omettez l'un ou l'autre, le générateur prend la dernière valeur par défaut. Le générateur renvoie une erreur s'il ne peut pas correspondre à la valeur de la balise.

Instruction RUN

RUN a 2 formes:

RUN <command> (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
RUN ["executable", "param1", "param2"] (exec form)

L'instruction RUN exécute toutes les commandes d'un nouveau calque au-dessus de l'image en cours et valide les résultats. L'image Dockerfile résultante sera utilisée pour l'étape suivante du Dockerfile .

La superposition des instructions RUN et la génération de commits sont conformes aux concepts de base de Docker où les commits sont peu coûteux et les conteneurs peuvent être créés à partir de n'importe quel point de l'historique d'une image, un peu comme le contrôle de source.

La forme exec permet d'éviter munging de chaîne de coquille, et à RUN commandes à l' aide d' une image de base qui ne contient pas le fichier exécutable d'enveloppe spécifiée.

Le shell par défaut du formulaire shell peut être modifié à l'aide de la commande SHELL .

Dans la forme du shell, vous pouvez utiliser un \ (backslash) pour continuer une seule instruction RUN sur la ligne suivante. Par exemple, considérons ces deux lignes:

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

Ensemble, ils sont équivalents à cette seule ligne:

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

Remarque: Pour utiliser un shell différent de «/ bin / sh», utilisez le formulaire exec en passant dans le shell souhaité. Par exemple, RUN ["/bin/bash", "-c", "echo hello"]

Remarque: Le formulaire d'exécution est analysé en tant que tableau JSON, ce qui signifie que vous devez utiliser des guillemets ( “ ) autour des mots et non des guillemets simples ( ' ).

Remarque: Contrairement au formulaire shell, le formulaire exec n'invoque pas un shell de commandes. Cela signifie que le traitement normal du shell ne se produit pas. Par exemple, RUN [ "echo", "$HOME" ] ne fera pas de substitution de variable sur $HOME . Si vous voulez un traitement du shell, utilisez soit le shell, soit exécutez directement un shell, par exemple: RUN [ "sh", "-c", "echo $HOME" ] .

Remarque: Dans le formulaire JSON, il est nécessaire d'échapper les barres obliques inverses. Ceci est particulièrement pertinent sous Windows où la barre oblique inverse est le séparateur de chemin. La ligne suivante serait sinon traitée en tant que formulaire shell en raison de ne pas être JSON valide, et échouer de manière inattendue: RUN ["c:\windows\system32\tasklist.exe"]

La syntaxe correcte pour cet exemple est la suivante: RUN ["c:\\windows\\system32\\tasklist.exe"]

Le cache pour les instructions RUN n'est pas automatiquement invalidé lors de la prochaine génération. Le cache pour une instruction comme RUN apt-get dist-upgrade -y sera réutilisé lors de la prochaine génération. Le cache pour les instructions RUN peut être invalidé à l'aide de l'indicateur --no-cache, par exemple docker build --no-cache.

Reportez-vous au guide Dockerfile Best Practices pour plus d'informations.

Le cache pour les instructions RUN peut être invalidé par les instructions ADD . Voir ci-dessous pour plus de détails.

Instruction ONBUILD

ONBUILD [INSTRUCTION]

L'instruction ONBUILD ajoute à l'image une instruction de déclenchement à exécuter ultérieurement, lorsque l'image est utilisée comme base pour une autre version. Le déclencheur sera exécuté dans le contexte de la construction en aval, comme s'il avait été inséré immédiatement après l'instruction FROM dans le fichier Dockerfile en aval.

Toute instruction de construction peut être enregistrée en tant que déclencheur.

Ceci est utile si vous créez une image qui sera utilisée comme base pour construire d'autres images, par exemple un environnement de génération d'application ou un démon qui peut être personnalisé avec une configuration spécifique à l'utilisateur.

Par exemple, si votre image est un générateur d'application Python réutilisable, le code source de l'application doit être ajouté dans un répertoire particulier et un script de génération peut ensuite être appelé. Vous ne pouvez pas simplement appeler ADD et RUN maintenant, car vous n'avez pas encore accès au code source de l'application, et il sera différent pour chaque génération d'application. Vous pouvez simplement fournir aux développeurs d'applications avec un Dockerfile standard pour copier-coller dans leur application, mais cela est inefficace, sujet aux erreurs et difficile à mettre à jour car il se mélange au code spécifique à l'application.

La solution consiste à utiliser ONBUILD pour enregistrer les instructions à exécuter ultérieurement, lors de la prochaine étape de la génération.

Voici comment cela fonctionne:

Lorsqu'il rencontre une instruction ONBUILD , le générateur ajoute un déclencheur aux métadonnées de l'image en cours de création. L'instruction n'affecte pas la construction en cours.

À la fin de la construction, une liste de tous les déclencheurs est stockée dans le manifeste de l'image, sous la clé OnBuild. Ils peuvent être inspectés avec la commande docker inspect . Plus tard, l'image peut être utilisée comme base pour une nouvelle construction, en utilisant l'instruction FROM . Dans le cadre du traitement de l'instruction FROM , le générateur en aval recherche les déclencheurs ONBUILD et les exécute dans l'ordre dans ONBUILD ils ont été enregistrés. Si l'un des déclencheurs échoue, l'instruction FROM est abandonnée, ce qui entraîne l'échec de la génération. Si tous les déclencheurs réussissent, l'instruction FROM termine et la construction se poursuit normalement.

Les déclencheurs sont effacés de l'image finale après leur exécution. En d'autres termes, ils ne sont pas hérités par les constructions de «petits-enfants».

Par exemple, vous pourriez ajouter quelque chose comme ceci:

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

Avertissement: le chaînage des instructions ONBUILD utilisant ONBUILD ONBUILD n'est pas autorisé.

Avertissement: l'instruction ONBUILD ne peut pas déclencher d'instructions FROM ou MAINTAINER .

Instruction STOPSIGNAL

STOPSIGNAL signal

L'instruction STOPSIGNAL définit le signal d'appel système qui sera envoyé au conteneur pour quitter. Ce signal peut être un nombre non signé valide correspondant à une position dans la table syscall du noyau, par exemple 9, ou un nom de signal au format SIGNAME, par exemple SIGKILL.

HEALTHCHECK Instruction

L'instruction HEALTHCHECK a deux formes:

HEALTHCHECK [OPTIONS] CMD command (check container health by running a command inside the container)
HEALTHCHECK NONE (disable any healthcheck inherited from the base image)

L'instruction HEALTHCHECK indique à Docker comment tester un conteneur pour vérifier qu'il fonctionne toujours. Cela peut détecter des cas tels qu'un serveur Web bloqué dans une boucle infinie et incapable de gérer de nouvelles connexions, même si le processus du serveur est toujours en cours d'exécution.

Lorsqu'un contrôle d'intégrité est spécifié pour un conteneur, son état d'intégrité s'ajoute à son statut normal. Ce statut commence initialement. Chaque fois qu'un bilan de santé passe, il devient sain (quel que soit l'état dans lequel il se trouvait auparavant). Après un certain nombre d'échecs consécutifs, cela devient malsain.

Les options pouvant apparaître avant CMD sont les suivantes:

--interval=DURATION (default: 30s)
--timeout=DURATION (default: 30s)
--retries=N (default: 3)

Le bilan de santé commence par un intervalle de secondes après le démarrage du conteneur, puis à nouveau quelques secondes après la fin de chaque vérification précédente.

Si une seule exécution de la vérification dure plus longtemps que le délai d'attente, la vérification est considérée comme ayant échoué.

Il faut réessayer les échecs consécutifs du bilan de santé pour que le conteneur soit considéré comme malsain.

Il ne peut y avoir qu’une HEALTHCHECK instruction HEALTHCHECK dans un Dockerfile . Si vous en HEALTHCHECK plus d'un, seul le dernier HEALTHCHECK prendra effet.

La commande après le mot-clé CMD peut être une commande shell (par exemple, HEALTHCHECK CMD /bin/check-running ) ou un tableau exec (comme pour les autres commandes Dockerfile; voir par exemple ENTRYPOINT pour plus de détails).

Le statut de sortie de la commande indique l'état d'intégrité du conteneur. Les valeurs possibles sont:

• 0: success - le conteneur est sain et prêt à l'emploi
• 1: unhealthy - le conteneur ne fonctionne pas correctement
• 2: starting - le conteneur n'est pas encore prêt à être utilisé, mais fonctionne correctement

Si la sonde renvoie 2 («commençant») lorsque le conteneur est déjà sorti de l'état «de démarrage», il est traité comme «non sain».

Par exemple, pour vérifier toutes les cinq minutes ou pour qu'un serveur Web puisse diffuser la page principale du site en trois secondes:

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

Pour aider à déboguer les sondes défaillantes, tout texte de sortie (encodé en UTF-8) que la commande écrit sur stdout ou stderr sera stocké dans l'état de santé et peut être interrogé avec docker inspect . Une telle sortie doit rester courte (seuls les premiers 4096 octets sont stockés actuellement).

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

La fonctionnalité HEALTHCHECK été ajoutée dans Docker 1.12.

Instruction SHELL

SHELL ["executable", "parameters"]

L'instruction SHELL permet de SHELL le shell par défaut utilisé pour les commandes de type shell. Le shell par défaut sous Linux est ["/bin/sh", "-c"] et sous Windows, ["cmd", "/S", "/C"] . L'instruction SHELL doit être écrite sous forme JSON dans un fichier Docker.

L'instruction SHELL est particulièrement utile sous Windows où il y a deux shells natifs couramment utilisés et très différents: cmd et powershell, ainsi que des shells alternatifs disponibles, y compris sh.

L'instruction SHELL peut apparaître plusieurs fois. Chaque instruction SHELL remplace toutes les instructions SHELL précédentes et affecte toutes les instructions suivantes. Par exemple:

FROM 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 leur forme de shell est utilisée dans un fichier Dockerfile: RUN , CMD et ENTRYPOINT .

L'exemple suivant est un modèle commun trouvé sous Windows, qui peut être rationalisé à l'aide de l'instruction SHELL :

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

La commande appelée par docker sera:

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

Ceci est inefficace pour deux raisons. Tout d'abord, un processeur de commandes cmd.exe (aka shell) non nécessaire est appelé. Deuxièmement, chaque instruction RUN de la forme shell nécessite une commande powershell supplémentaire préfixant la commande.

Pour rendre cela plus efficace, l'un des deux mécanismes peut être utilisé. L'une consiste à utiliser la forme JSON de la commande RUN telle que:

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

Bien que le formulaire JSON ne soit pas ambigu et n'utilise pas le fichier cmd.exe inutile, il nécessite plus de verbosité en citant et en échappant. L'autre mécanisme consiste à utiliser l'instruction SHELL et la forme du shell, ce qui rend la syntaxe plus naturelle pour les utilisateurs Windows, en particulier lorsqu'elle est associée à la directive d'échappement parser:

# escape=`

FROM windowsservercore
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ésultant en:

PS E:\docker\build\shell> docker build -t shell .
Sending build context to Docker daemon 3.584 kB
Step 1 : FROM windowsservercore
 ---> 5bc36a335344
Step 2 : SHELL powershell -command
 ---> Running in 87d7a64c9751
 ---> 4327358436c1
Removing intermediate container 87d7a64c9751
Step 3 : RUN New-Item -ItemType Directory C:\Example
 ---> Running in 3e6ba16b8df9


Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/2/2016   2:59 PM                Example


 ---> 1f1dfdcec085
Removing intermediate container 3e6ba16b8df9
Step 4 : ADD Execute-MyCmdlet.ps1 c:\example\
 ---> 6770b4c17f29
Removing intermediate container b139e34291dc
Step 5 : RUN c:\example\Execute-MyCmdlet -sample 'hello world'
 ---> Running in abdcf50dfd1f
Hello from Execute-MyCmdlet.ps1 - passed hello world
 ---> ba0e25255fda
Removing intermediate container abdcf50dfd1f
Successfully built ba0e25255fda
PS E:\docker\build\shell>

L'instruction SHELL pourrait également être utilisée pour modifier la manière dont fonctionne un shell. Par exemple, en utilisant SHELL cmd /S /C /V:ON|OFF sous Windows, la sémantique d'extension de variable d'environnement retardée pourrait être modifiée.

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

La fonctionnalité SHELL été ajoutée dans Docker 1.12.

Installer des paquets Debian / Ubuntu

Exécutez l'installation sur une seule commande d'exécution pour fusionner la mise à jour et installer. Si vous ajoutez plus de paquetages ultérieurement, cela lancera à nouveau la mise à jour et installera tous les paquetages nécessaires. Si la mise à jour est exécutée séparément, elle sera mise en cache et les installations du package risquent d'échouer. La définition de l'interface sur non-interactive et la transmission de l'option -y à l'installation est nécessaire pour les installations par script. Le nettoyage et la purge à la fin de l'installation minimisent la taille de la couche.

FROM debian

RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get install -y \
    git \
    openssh-client \
    sudo \
    vim \
    wget \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*