À propos du sujet qui a tendance à être confondu avec ARG de Dockerfile qui est une construction en plusieurs étapes

TL;DR

Si vous utilisez ARG avec un Dockerfile de construction en plusieurs étapes, sachez que la portée est fermée à l'intérieur de la scène! Déclarez l'ARG à utiliser pour chaque étape! De plus, si l'ARG utilisé en plusieurs étapes a une valeur par défaut, définissez un ARG global et mettez-y la valeur par défaut!

Ce n'est pas grave si vous faites comme ça!

Dockerfile

#S'il existe une valeur par défaut pour l'ARG qui est couramment utilisée à chaque étape, définissez-la avant le premier FROM.
ARG YOUR_ARG="Default value"

FROM alpine:latest as first_stage
#ARG doit être déclaré pour chaque étape utilisée.
ARG YOUR_ARG
RUN echo "1st stage: ${YOUR_ARG}"

FROM alpine:latest as second_stage
#ARG doit être déclaré pour chaque étape utilisée.
ARG YOUR_ARG
RUN echo "2nd stage: ${YOUR_ARG}"

À propos de la relation entre la construction en plusieurs étapes et l'ARG

Dans les versions en plusieurs étapes, la portée d'ARG et d'ENV semble être limitée par étape. Le saviez-vous tous? Je ne savais pas jusqu'à ce que je réalise que je ne pouvais pas faire référence à la valeur d'ARG dans l'étape du Dockerfile que j'ai créé.

D'après ce commentaire

Correct, Dockerfile instructions, including ENV vars and ARG are scoped per build-stage, and will not be preserved in the next stage; this is by design. You can, however, set a global ARG (set before the first build-stage), and use that value in each build-stage; Les instructions Dockerfile, y compris ENV et ARG, sont définies pour chaque étape de construction et ne seront pas reportées à l'étape suivante. C'est ce que c'est par conception. Cependant, si vous utilisez l'ARG global (défini avant la première étape de construction), vous pouvez tirer parti de cette valeur pour chaque étape de construction.

... Apparemment ... Vraiment?

Il a également été fermement répertorié dans le Document officiel.

La portée variable de l'instruction ARG est jusqu'à la fin de l'étape de construction au cours de laquelle elle est définie. Si vous souhaitez utiliser ARG dans plusieurs étapes de construction, vous devez spécifier l'instruction ARG individuellement.

Quand j'ai lu le document pour la première fois, j'ai eu l'impression de penser: «Ahhhhh, je l'ai complètement compris», sans connaître le sens de l'étape de construction. .. ..

Voyons le mouvement d'ARG

Voyons en fait comment ARG fonctionne dans une construction en plusieurs étapes.

Environnement de vérification de fonctionnement de ce document

Au moment de la rédaction de cet article, nous avons confirmé l'opération avec les versions suivantes.

# docker --version
Docker version 18.09.1, build 4c52b90

Dockerfile

Le Dockerfile utilisé dans cette vérification est le suivant.

Dockerfile

#ARG1 déclare globalement et définit les valeurs par défaut globales.
ARG ARG1="arg1 global default value"
#ARG2 déclare globalement mais ne définit pas de valeur par défaut globale.
ARG ARG2
#ARG3 ne déclare pas globalement.
# ARG ARG3


FROM alpine:latest as first_stage

# first_Dans l'étape, chaque ARG est déclaré et la valeur par défaut de la portée est définie.
ARG ARG1="arg1 first stage value"
ARG ARG2="arg2 first stage value"
ARG ARG3="arg3 first stage value"
RUN echo -e "first_stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"


FROM alpine:latest as second_stage

# second_Dans l'étape, chaque ARG est déclaré, mais aucune valeur par défaut dans la portée n'est définie.
ARG ARG1
ARG ARG2
ARG ARG3
RUN echo -e "second_stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"


FROM alpine:latest as third_stage

# third_Au stade, ne déclarez pas tous les ARG.
# ARG ARG1
# ARG ARG2
# ARG ARG3
RUN echo -e "third_stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"

Chaque ARG est défini comme suit.

De plus, chaque étape est définie comme suit.

--build-arg Construire sans spécification

Lors de la construction de Docker Image, essayez de construire sans spécifier la valeur avec --build-arg.

# docker build . --no-cache
Sending build context to Docker daemon  14.85kB
...snip...
Step 7/14 : RUN echo -e "1st stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"
 ---> Running in 2bbe78634ee8
first_stage:
        ARG1=arg1 first stage value
        ARG2=arg2 first stage value
        ARG3=arg3 first stage value
...snip...
Step 12/14 : RUN echo -e "2nd stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"
 ---> Running in 0c28af93ea9b
second_stage:
        ARG1=arg1 global default value
        ARG2=
        ARG3=
...snip...
Step 14/14 : RUN echo -e "3rd stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"
 ---> Running in cbca9ed88691
third_stage:
        ARG1=
        ARG2=
        ARG3=
...snip...

• Dans first_stage, toutes sont les valeurs par défaut de la scène. En regardant ARG1, vous pouvez voir que les valeurs par défaut en cours sont prioritaires sur les valeurs par défaut globales. Il s'agit d'un mouvement qui utilise de préférence la valeur avec la portée la plus étroite, ce qui a du sens.
• Dans second_stage, seul ARG1 affiche la valeur globale par défaut. Vous avez déclaré ARG dans l'étape, mais si vous ne spécifiez aucune valeur, vous utiliserez la valeur par défaut globale. Rien n'est affiché dans ARG2 et ARG3, car il n'y a pas de place pour spécifier la valeur.
• Toutes les valeurs ne sont pas affichées dans third_stage. Le fait que même la valeur par défaut globale d'ARG1 ne soit pas affichée signifie que vous devez la déclarer pour chaque étape afin d'utiliser ARG.

--build-arg Construire avec des spécifications

Maintenant, essayez de construire avec la valeur spécifiée par --build-arg.

# docker build --build-arg ARG1="build arg1 value" --build-arg ARG2="build arg2 value" --build-arg ARG3="build arg3 value" . --no-cache
Sending build context to Docker daemon  14.85kB
...snip...
Step 7/14 : RUN echo -e "1st stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"
 ---> Running in 10b37c5a524b
first_stage:
        ARG1=build arg1 value
        ARG2=build arg2 value
        ARG3=build arg3 value
...snip...
Step 12/14 : RUN echo -e "2nd stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"
 ---> Running in e70e3ff9fe9b
second_stage:
        ARG1=build arg1 value
        ARG2=build arg2 value
        ARG3=build arg3 value
...snip...
Step 14/14 : RUN echo -e "3rd stage:\n\tARG1=${ARG1}\n\tARG2=${ARG2}\n\tARG3=${ARG3}"
 ---> Running in e675e8f648e8
third_stage:
        ARG1=
        ARG2=
        ARG3=
...snip...

• Toutes les valeurs pour first_stage et second_stage sont maintenant les valeurs spécifiées par --build-arg. Ceci est conforme à ce qui est décrit dans Official Document ARG Defaults. La valeur spécifiée par --build-arg est prioritaire à la fois sur la valeur par défaut globale et la valeur par défaut en cours.
• Dans third_stage, toutes les valeurs ne sont plus affichées. Même si la valeur est spécifiée par --build-arg, elle semble toujours indisponible à moins qu'elle ne soit déclarée à ce stade.

Sommaire

• Lors de l'utilisation d'ARG dans un Dockerfile de construction en plusieurs étapes, il est nécessaire de déclarer l'ARG à utiliser à toutes les étapes.
• Si vous souhaitez définir la valeur par défaut d'ARG utilisée en plusieurs étapes, vous pouvez définir l'ARG global (défini avant le premier FROM) et y mettre la valeur par défaut.
• La priorité de la valeur ARG est

1. Valeur spécifiée par --build-arg [Haute priorité]
2. Valeur par défaut dans la scène
3. Valeur par défaut globale [Faible priorité]

C'est ça.

Publicité

C'est une promotion du projet qui m'a poussé à remarquer le comportement d'ARG en construction en plusieurs étapes.

• docker-minecraft-bedrock

Exploitons facilement le serveur Bedrock de Minecraft! C'est un projet à l'effet. Minecraft se met parfois à jour, mais le client est principalement mis à jour seul, mais Bedrock Server n'est pas mis à jour automatiquement, téléchargeant manuellement la nouvelle version et extrayant le fichier Zip pour extraire le fichier binaire. J'ai dû le remplacer et redémarrer le service ... ou quelque chose comme ça. Ce projet ne doit être configuré qu'une seule fois et le serveur Bedrock sera mis à jour automatiquement! Au fait, Docker est utilisé pour construire Bedrock Server, donc il ne pollue pas l'environnement!

Merci!

Vraiment fait.