Comment utiliser les fichiers args:, environment:, env_file: et .env avec la commande docker-compose

Dans docker-compose v3, je me perdais parfois à cause de l'utilisation de args:, environment:, env_file: et du fichier .env, donc je l'ai organisé pour moi-même.

Sommaire

À propos de args:

--C'est une variable de construction ――Ainsi, il n'existe pas au moment de run --Si vous déclarez la même variable, c'est docker-compose.yml> Dockerfile

Le déclarer dans docker-compose.yml équivaut à le déclarer dans Dockerfile.

À propos de environnement:

Vous pouvez définir des variables d'environnement
Les variables déclarées dans docker-compose.yml seront ajoutées / écrasées au moment de run.
Notez que ce que vous déclarez avec l'instruction ENV de Dockerfile peut être utilisé comme une variable de l'instruction ARG au moment de build.
Et au moment de build, vous devez faire attention car la variable déclarée dans docker-compose.yml n'est pas transmise comme mentionné ci-dessus.

À propos de env_file:

--C'est un mécanisme pour ajouter des variables d'environnement à partir d'un fichier --Si une variable d'environnement avec le même nom existe, la priorité est environnement:> env_file: --Si vous spécifiez plusieurs env_file:, la dernière valeur de la liste sera ajoutée / écrasée.

À propos de .env

Le fichier spécial utilisé par docker-compose est .env.
Le fichier qui rend la fonction de substitution de variable pratique est .env.
(Probablement) Vous ne pouvez pas utiliser le nom de fichier .env comme un autre nom.
Les variations déclarées et définies dans .env peuvent être utilisées comme variables sur docker-compose.yml.

Le code est https://github.com/hokutoasari/how-to-use-args-environment-env-file-dotenv-file-with-docker-compose.

Comment utiliser args:

Tout d'abord, le document officiel.

https://docs.docker.com/compose/compose-file/#args

Add build arguments, which are environment variables accessible only during the build process.

Traduction gratuite: vous pouvez définir des variables pour la construction.

Un mécanisme qui vous permet de définir des variables de construction.

Puisque «variables d'environnement» est confondue avec les soi-disant «variables d'environnement» spécifiées par «environnement:» décrites plus loin, elles sont lues comme «variables de construction» ici.

ARG_VALUE1 --Déclarez et définissez les valeurs jusqu'à ARG_VALUE4 comme suit, puis vérifiez le comportement.

	Dockerfile	docker-compose.yml
ARG_VALUE1	arg1_in_Dockerfile
ARG_VALUE2	arg2_in_Dockerfile	arg2_in_yml
ARG_VALUE3		arg3_in_yml
ARG_VALUE4

./args/Dockerfile

`./args/Dockerfile`


FROM busybox

ARG ARG_VALUE1="arg1_in_Dockerfile."
ARG ARG_VALUE2="arg2_in_Dockerfile."

RUN echo "ARG_VALUE1 is ${ARG_VALUE1}" \
  && echo "ARG_VALUE2 is ${ARG_VALUE2}" \
  && echo "ARG_VALUE3 is ${ARG_VALUE3}" \
  && echo "ARG_VALUE4 is ${ARG_VALUE4}"
RUN echo "ARG_VALUE1 is $ARG_VALUE1" >> /tmp/outs.txt \
  && echo "ARG_VALUE2 is $ARG_VALUE2" >> /tmp/outs.txt \
  && echo "ARG_VALUE3 is $ARG_VALUE3" >> /tmp/outs.txt \
  && echo "ARG_VALUE4 is $ARG_VALUE4" >> /tmp/outs.txt

CMD cat /tmp/outs.txt \
  && echo "-----" \
  && echo "ARG_VALUE1 is ${ARG_VALUE1}" \
  && echo "ARG_VALUE2 is ${ARG_VALUE2}" \
  && echo "ARG_VALUE3 is ${ARG_VALUE3}" \
  && echo "ARG_VALUE4 is ${ARG_VALUE4}"

./args/docker-compose.yml

`./args/docker-compose.yml`


version: '3'
services:
  with-args:
    build:
      context: ./
      args:
        ARG_VALUE2: "arg2_in_yml"
        ARG_VALUE3: "arg3_in_yml"

Courir.

% docker-compose build --no-cache && docker-compose up
...Abréviation...
Step 4/6 : RUN echo "ARG_VALUE1 is ${ARG_VALUE1}"   && echo "ARG_VALUE2 is ${ARG_VALUE2}"   && echo "ARG_VALUE3 is ${ARG_VALUE3}"   && echo "ARG_VALUE4 is ${ARG_VALUE4}"
 ---> Running in 64893f52d5bc
ARG_VALUE1 is arg1_in_Dockerfile.
ARG_VALUE2 is arg2_in_yml
ARG_VALUE3 is
ARG_VALUE4 is
Removing intermediate container 64893f52d5bc
 ---> a66e7626d5eb
...Abréviation...
[Warning] One or more build-args [ARG_VALUE3] were not consumed
...Abréviation...
with-args_1  | ARG_VALUE1 is arg1_in_Dockerfile.
with-args_1  | ARG_VALUE2 is arg2_in_yml
with-args_1  | ARG_VALUE3 is
with-args_1  | ARG_VALUE4 is
with-args_1  | -----
with-args_1  | ARG_VALUE1 is
with-args_1  | ARG_VALUE2 is
with-args_1  | ARG_VALUE3 is
with-args_1  | ARG_VALUE4 is
args_with-args_1 exited with code 0

résultat.

	Dockerfile	docker-compose.yml	Au moment de la construction
ARG_VALUE1	arg1_in_Dockerfile		arg1_in_Dockerfile
ARG_VALUE2	arg2_in_Dockerfile	arg2_in_yml	arg2_in_yml
ARG_VALUE3		arg3_in_yml	[Warning]
ARG_VALUE4

La valeur est remplacée par args: dans docker-compose.yml --Avertissement s'il y a des variables inutilisées dans args: déclarées dans docker-compose.yml --Il n'y a pas d'avertissement pour les variables utilisées dans Dockerfile mais non déclarées dans docker-compose.yml. ――Bien sûr, il n'est pas disponible au moment de run

Comment utiliser l'environnement:

Tout d'abord, le document officiel.

https://docs.docker.com/compose/compose-file/#environment

Add environment variables.

Un mécanisme qui vous permet d'ajouter des variables d'environnement.

Contrairement à la variable de construction mentionnée ci-dessus, il s'agit d'une instruction pour définir la soi-disantvariable d'environnement.

ENV_VALUE1 --Déclarez et définissez des valeurs jusqu'à ENV_VALUE4 comme suit, puis vérifiez le comportement.

	Dockerfile	docker-compose.yml
ENV_VALUE1	env1_in_Dockerfile
ENV_VALUE2	env2_in_Dockerfile	env2_in_yml
ENV_VALUE3		env3_in_yml
ENV_VALUE4

./environment/Dockerfile

**`./environment/Dockerfile*`**


FROM busybox

ENV ENV_VALUE1="env1_in_Dockerfile."
ENV ENV_VALUE2="env2_in_Dockerfile."

RUN echo "ENV_VALUE1 is ${ENV_VALUE1}" \
  && echo "ENV_VALUE2 is ${ENV_VALUE2}" \
  && echo "ENV_VALUE3 is ${ENV_VALUE3}" \
  && echo "ENV_VALUE4 is ${ENV_VALUE4}" \
RUN echo "ENV_VALUE1 is $ENV_VALUE1" >> /tmp/outs.txt \
  && echo "ENV_VALUE2 is $ENV_VALUE2" >> /tmp/outs.txt \
  && echo "ENV_VALUE3 is $ENV_VALUE3" >> /tmp/outs.txt \
  && echo "ENV_VALUE4 is $ENV_VALUE4" >> /tmp/outs.txt

CMD cat /tmp/outs.txt \
  && echo "-----" \
  && echo "ENV_VALUE1 is ${ENV_VALUE1}" \
  && echo "ENV_VALUE2 is ${ENV_VALUE2}" \
  && echo "ENV_VALUE3 is ${ENV_VALUE3}" \
  && echo "ENV_VALUE4 is ${ENV_VALUE4}"

./environment/docker-compose.yml

`./environment/docker-compose.yml`


version: '3'
services:
  with-environment:
    environment:
      ENV_VALUE2: "env2_in_yml"
      ENV_VALUE3: "env3_in_yml"

Courir.

% docker-compose build --no-cache && docker-compose up
...Abréviation...
Step 4/6 : RUN echo "ENV_VALUE1 is ${ENV_VALUE1}"   && echo "ENV_VALUE2 is ${ENV_VALUE2}"   && echo "ENV_VALUE3 is ${ENV_VALUE3}"   && echo "ENV_VALUE4 is ${ENV_VALUE4}"
 ---> Running in bb4ae383c1e7
ENV_VALUE1 is env1_in_Dockerfile.
ENV_VALUE2 is env2_in_Dockerfile.
ENV_VALUE3 is
ENV_VALUE4 is
Removing intermediate container bb4ae383c1e7
 ---> a01b51cd008a
...Abréviation...
with-environment_1  | ENV_VALUE1 is env1_in_Dockerfile.
with-environment_1  | ENV_VALUE2 is env2_in_Dockerfile.
with-environment_1  | ENV_VALUE3 is
with-environment_1  | ENV_VALUE4 is
with-environment_1  | -----
with-environment_1  | ENV_VALUE1 is env1_in_Dockerfile.
with-environment_1  | ENV_VALUE2 is env2_in_yml
with-environment_1  | ENV_VALUE3 is env3_in_yml
with-environment_1  | ENV_VALUE4 is
environment_with-environment_1 exited with code 0

résultat.

	Dockerfile	docker-compose.yml	Au moment de la construction	Quand courir
ENV_VALUE1	env1_in_Dockerfile		env1_in_Dockerfile	env1_in_Dockerfile
ENV_VALUE2	env2_in_Dockerfile	env2_in_yml	env2_in_Dockerfile	env2_in_yml
ENV_VALUE3		env3_in_yml		env3_in_yml
ENV_VALUE4

--Au moment de build, la valeur décrite dans Dockerfile est utilisée. --Au moment de run, la valeur définie dans docker-compose.yml est transmise et écrasée.

InstructionENV et environnement: Pour la fin, sachez qu'il définit les variables d'environnement.
Notez que la valeur préparée par l'instruction ENV peut être utilisée comme une variable de construction au moment de build.

Comment utiliser env_file:

Tout d'abord, le document officiel.

https://docs.docker.com/compose/compose-file/#env_file

Add environment variables from a file.

Un mécanisme pour ajouter des «variables d'environnement» à partir d'un «fichier».

ENV_VALUE1 --Déclarez et définissez des valeurs jusqu'à ENV_VALUE5 comme suit, puis vérifiez le comportement.

	Dockerfile	docker-compose.yml	some_env.env
ENV_VALUE1	env1_in_Dockerfile
ENV_VALUE2	env2_in_Dockerfile	env2_in_yml
ENV_VALUE3		env3_in_yml	env3_in_file
ENV_VALUE4			env4_in_file
ENV_VALUE5

./env_file/Dockerfile

`./env_file/Dockerfile`


FROM busybox

ENV ENV_VALUE1="env1_in_Dockerfile."
ENV ENV_VALUE2="env2_in_Dockerfile."

RUN echo "ENV_VALUE1 is ${ENV_VALUE1}" \
  && echo "ENV_VALUE2 is ${ENV_VALUE2}" \
  && echo "ENV_VALUE3 is ${ENV_VALUE3}" \
  && echo "ENV_VALUE4 is ${ENV_VALUE4}" \
  && echo "ENV_VALUE5 is ${ENV_VALUE5}"
RUN echo "ENV_VALUE1 is $ENV_VALUE1" >> /tmp/outs.txt \
  && echo "ENV_VALUE2 is $ENV_VALUE2" >> /tmp/outs.txt \
  && echo "ENV_VALUE3 is $ENV_VALUE3" >> /tmp/outs.txt \
  && echo "ENV_VALUE4 is $ENV_VALUE4" >> /tmp/outs.txt \
  && echo "ENV_VALUE5 is $ENV_VALUE5" >> /tmp/outs.txt

CMD cat /tmp/outs.txt \
  && echo "-----" \
  && echo "ENV_VALUE1 is ${ENV_VALUE1}" \
  && echo "ENV_VALUE2 is ${ENV_VALUE2}" \
  && echo "ENV_VALUE3 is ${ENV_VALUE3}" \
  && echo "ENV_VALUE4 is ${ENV_VALUE4}" \
  && echo "ENV_VALUE5 is ${ENV_VALUE5}"

./env_file/docker-compose.yml

`./env_file/docker-compose.yml`


version: '3'
services:
  with-env_file:
    build:
      context: ./
    environment:
      ENV_VALUE2: "env2_in_yml"
      ENV_VALUE3: "env3_in_yml"
    env_file:
      - some_env.env

./env_file/some_env.env

`./env_file/some_env.env`


ENV_VALUE3="env3_in_file"
ENV_VALUE4="env4_in_file"

Courir.

% docker-compose build --no-cache && docker-compose up
...Abréviation...
Step 4/6 : RUN echo "ENV_VALUE1 is ${ENV_VALUE1}"   && echo "ENV_VALUE2 is ${ENV_VALUE2}"   && echo "ENV_VALUE3 is ${ENV_VALUE3}"   && echo "ENV_VALUE4 is ${ENV_VALUE4}"   && echo "ENV_VALUE5 is ${ENV_VALUE5}"
 ---> Running in 5851a9b3aa91
ENV_VALUE1 is env1_in_Dockerfile.
ENV_VALUE2 is env2_in_Dockerfile.
ENV_VALUE3 is
ENV_VALUE4 is
ENV_VALUE5 is
Removing intermediate container 5851a9b3aa91
 ---> 39f56354d7cd
...Abréviation...
with-env_file_1  | ENV_VALUE1 is env1_in_Dockerfile.
with-env_file_1  | ENV_VALUE2 is env2_in_Dockerfile.
with-env_file_1  | ENV_VALUE3 is
with-env_file_1  | ENV_VALUE4 is
with-env_file_1  | ENV_VALUE5 is
with-env_file_1  | -----
with-env_file_1  | ENV_VALUE1 is env1_in_Dockerfile.
with-env_file_1  | ENV_VALUE2 is env2_in_yml
with-env_file_1  | ENV_VALUE3 is env3_in_yml
with-env_file_1  | ENV_VALUE4 is env4_in_file
with-env_file_1  | ENV_VALUE5 is
env_file_with-env_file_1 exited with code 0

résultat.

	Dockerfile	docker-compose.yml	some_env.env	Au moment de la construction	Quand courir
ENV_VALUE1	env1_in_Dockerfile			env1_in_Dockerfile	env1_in_Dockerfile
ENV_VALUE2	env2_in_Dockerfile	env2_in_yml		env2_in_Dockerfile	env2_in_yml
ENV_VALUE3		env3_in_yml	env3_in_file		env3_in_yml
ENV_VALUE4			env4_in_file		env4_in_file
ENV_VALUE5

La valeur de environment: a priorité sur la valeur spécifiée par env_file: --Si spécifié dans env_file: et non défini dans docker-compose.yml, la valeur spécifiée dans env_file: est utilisée.
Bien que je n'ai pas expérimenté, comme décrit dans le document, si vous spécifiez plusieurs fichiers dans env_file:, la dernière valeur de la liste sera ajoutée / écrasée.

Comment utiliser le fichier .env

Le fichier .env est un fichier qui est traité spécialement dans docker-compose.

Utilisé dans la fonction de remplacement de variable.

Fonction de remplacement variable

Le fichier .env est utilisé par la fonction de remplacement de variable de docker-compose, alors essayez d'abord la fonction de remplacement de variable.

Documentation officielle. https://docs.docker.com/compose/compose-file/#variable-substitution

Your configuration options can contain environment variables. Compose uses the variable values from the shell environment in which docker-compose is run.

Traduction gratuite: Vous pouvez utiliser la variable d'environnement du shell qui exécute docker-compose comme variable de docker-compose.

Préparez . / Variable-substitution / docker-compose.yml avec le contenu suivant.

`./variable-substitution/docker-compose.yml`


version: '3'
services:
  variable-substitution:
    image: busybox:${BUSYBOX_VERSION}

Définissez temporairement la variable d'environnement BUSYBOX_VERSION = latest et docker-compose up. (Comme il n'y a pas besoin de build, il sera directement up.)

% env BUSYBOX_VERSION="latest" docker-compose up
...Abréviation...
variable-substitution_variable-substitution_1 exited with code 0

Je l'ai remonté en toute sécurité et j'ai terminé.

De même, définissez BUSYBOX_VERSION = musl sur la variable d'environnement et faites docker-compose up.

% env BUSYBOX_VERSION="musl" docker-compose up
...Abréviation...
variable-substitution_variable-substitution_1 exited with code 0

Cela a également été réussi et terminé.

Pour confirmation, consultez la liste d'images à portée de main avec les images docker.

% docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
busybox             musl                8bce8d24824c        5 weeks ago         1.47MB
busybox             latest              f0b02e9d092d        5 weeks ago         1.23MB

Certes, j'ai confirmé qu'il y avait une image avec le TAG «latest», «musl».

De cette manière, docker-compose a un mécanisme pour passer les variables d'environnement de l'environnement dans lequel le shell est exécuté à docker-compose.

C'est l'une des fonctions de remplacement variables.

fichier .env

La documentation officielle dit:

https://docs.docker.com/compose/compose-file/#variable-substitution

You can set default values for environment variables using a .env file, which Compose automatically looks for. Values set in the shell environment override those set in the .env file.

Traduction gratuite: docker-compose définit la variable d'environnement par défaut lorsqu'il trouve le fichier .env. De plus, les valeurs définies à partir des variables d'environnement du shell seront écrasées par les valeurs définies dans le fichier .env.

Préparez le fichier . / Variable-substitution-dotenv / .env comme indiqué ci-dessous.

`./variable-substitution-dotenv/.env`


BUSYBOX_VERSION=latest

Même contenu que précédemment, mais préparez . / Variable-substitution-dotenv / docker-compose.yml.

`./variable-substitution-dotenv/docker-compose.yml`


version: '3'
services:
  variable-substitution-dotenv:
    image: busybox:${BUSYBOX_VERSION}

Dans cet état, essayez up sans définir de variable d'environnement temporaire.

Il peut être plus facile de comprendre l'opération si vous supprimez le conteneur pré-créé de docker rm et supprimez également les images extraites avec docker rmi.

% docker-compose up
Creating network "variable-substitution-dotenv_default" with the default driver
Pulling variable-substitution-dotenv (busybox:latest)...
latest: Pulling from library/busybox
9758c28807f2: Pull complete
Digest: sha256:a9286defaba7b3a519d585ba0e37d0b2cbee74ebfe590960b0b1d6a5e97d1e1d
Status: Downloaded newer image for busybox:latest
Creating variable-substitution-dotenv_variable-substitution-dotenv_1 ... done
Attaching to variable-substitution-dotenv_variable-substitution-dotenv_1

Vous pouvez voir que «dernier» a été récupéré avec succès.

Ensuite, réécrivez . / Variable-substitution-dotenv / .env avec le contenu suivant.

`./variable-substitution-dotev/.env`


BUSYBOX_VERSION=musl

Dans cet état, réessayez docker-compose up.

% docker-compose up
Pulling variable-substitution-dotenv (busybox:musl)...
musl: Pulling from library/busybox
7c3804618ebb: Pull complete
Digest: sha256:605de95bca536139f324abdecf88dcab492c8457346e7fc92e37dff6e263f341
Status: Downloaded newer image for busybox:musl
Recreating variable-substitution-dotenv_variable-substitution-dotenv_1 ... done
Attaching to variable-substitution-dotenv_variable-substitution-dotenv_1
variable-substitution-dotenv_variable-substitution-dotenv_1 exited with code 0

Vous pouvez voir que «musl» a été tiré et remonté avec succès.

De cette façon, l'utilisation du fichier .env permet de passer des variables à docker-compose sans polluer les variables d'environnement de l'environnement d'exécution du shell.

À propos, le document officiel contient les notes suivantes.

Note when using docker stack deploy The .env file feature only works when you use the docker-compose up command and does not work with docker stack deploy.

Traduction gratuite

Remarque: pour ceux qui utilisent docker stack deploy Cette fonction utilisant le fichier .env fonctionne uniquement avec la commande docker-compose up. Cela ne fonctionne pas avec docker stack deploy.

Puisqu'il s'agit d'une note lors de l'utilisation de docker stack deploy, je pense qu'il est écrit comme ne fonctionne que lorsque vous utilisez la commande docker-compose up, mais en réalité ce n'est pas seulement la commande docker-compose up, mais docker-compose up `Travaillez pour les commandes.

Plus précisément, il fonctionne également avec les commandes docker-compose build et docker-compose config.

En guise de test, si vous exécutez docker-compose config dans l'état actuel, ce sera comme suit. (docker-compose config est une commande pour vérifier le yml final à exécuter.)

% docker-compose config
services:
  variable-substitution:
    image: busybox:musl
version: '3'

Vous pouvez voir que la partie $ {BUSYBOX_VERSION} est développée en une variable et devient busybox: musl.

Ensuite, réécrivez . / Variable-substitution-dotenv / .env avec le contenu suivant et exécutez docker-compose config pour obtenir ce qui suit.

`./variable-substitution-dotenv/.env`


BUSYBOX_VERSION=latest

% docker-compose config
services:
  variable-substitution:
    image: busybox:latest
version: '3'

De même, vous pouvez voir que la partie $ {BUSYBOX_VERSION} est étendue à busybox: latest.

Il a été confirmé que les variables peuvent être passées à docker-compose en utilisant le fichier .env.

Il est facile de mal comprendre la fonction de remplacement de variable en utilisant le fichier .env et comment la gérer.

Bien entendu, les configurations suivantes «.env», «Dockerfile» et «docker-compose.yml» ne peuvent pas être «build».

./variable-substitution-dotenv-dockerfile-not-work/.env

`./variable-substitution-dotenv-dockerfile-not-work/.env`


BUSYBOX_VERSION="latest"

./variable-substitution-dotenv-dockerfile-not-work/Dockerfile

`./variable-substitution-dotenv-dockerfile-not-work/Dockerfile`


FROM busybox:${BUSYBOX_VERSION}

./variable-substitution-dotenv-dockerfile-not-work/docker-compose.yml

`./variable-substitution-dotenv-dockerfile-not-work/docker-compose.yml`


version: '3'
services:
  variable-substitution-dotenv-dockerfile-not-work:
    build:
      context: ./

Courir.

% docker-compose build --no-cache
Building variable-substitution-dotenv-dockerfile-not-work
Step 1/1 : FROM busybox:${BUSYBOX_VERSION}
ERROR: Service 'variable-substitution-dotenv-dockerfile-not-work' failed to build : invalid reference format

Il est naturel que vous lisiez jusqu'à présent le contrôle de fonctionnement et le document officiel, mais il est dans l'état suivant.

La variable BUSYBOX_VERSION de busybox: $ {BUSYBOX_VERSION} utilisée au début de Dockerfile n'est pas déclarée comme Dockerfile comme une variable de construction.
Le mécanisme pour passer des variables à docker-compose en utilisant le fichier .env, bien sûr, ne transmet que les valeurs jusqu'à docker-compose.
En d'autres termes, la variable n'est pas passée à Dockerfile

Pour pouvoir construire, vous devez avoir la configuration suivante.

./variable-substitution-dotenv-dockerfile-work/.env

`./variable-substitution-dotenv-dockerfile-work/.env`


BUSYBOX_VERSION="latest"

./variable-substitution-dotenv-dockerfile-work/Dockerfile

`./variable-substitution-dotenv-dockerfile-work/Dockerfile`


ARG BUSYBOX_VERSION
FROM busybox:${BUSYBOX_VERSION}

./variable-substitution-dotenv-dockerfile-work/docker-compose.yml

`./variable-substitution-dotenv-dockerfile-work/docker-compose.yml`


version: '3'
services:
  variable-substitution-dotenv-dockerfile-work:
    build:
      context: ./
      args:
        BUSYBOX_VERSION: ${BUSYBOX_VERSION}

Courir.

% docker-compose build --no-cache
Building variable-substitution-dotenv-dockerfile-work
Step 1/2 : ARG BUSYBOX_VERSION
Step 2/2 : FROM busybox:${BUSYBOX_VERSION}
latest: Pulling from library/busybox
9758c28807f2: Pull complete
Digest: sha256:a9286defaba7b3a519d585ba0e37d0b2cbee74ebfe590960b0b1d6a5e97d1e1d
Status: Downloaded newer image for busybox:latest
 ---> f0b02e9d092d

Successfully built f0b02e9d092d
Successfully tagged variable-substitution-dotenv-dockerfile-work_variable-substitution-dotenv-dockerfile-work:latest

--Déclarez la variable BUSYBOX_VERSION en utilisant l'instruction ARG dans le Dockerfile

Déclarez la variable BUSYBOX_VERSION dans la section args: de docker-compose.yml
Aussi, dans la clause args: de docker-compose.yml, assignez la variable BUSYBOX_VERSION de .env à la déclaration de variable BUSYBOX_VERSION. --Définissez la valeur de la variable BUSYBOX_VERSION dans le fichier .env

Maintenant, en changeant la valeur de BUSYBOX_VERSION définie dans .env, vous pouvez changer la valeur sans polluer les variables d'environnement de l'environnement d'exécution du shell.

Cependant, dans l'exemple ci-dessus, le nom de variable BUSYBOX_VERSION est utilisé à divers endroits ( .env, Dockerfile et docker-compose.yml), ce qui est un peu difficile à comprendre.

Pour le dire un peu plus clairement et explicitement, .env, Dockerfile et docker-compose.yml sont les suivants.

./variable-substitution-dotenv-dockerfile-work-easy-to-read/.env

`./variable-substitution-dotenv-dockerfile-work-easy-to-read/.env`


DOCKER_COMPOSER_BUSYBOX_VERSION="latest"

./variable-substitution-dotenv-dockerfile-work-easy-to-read/Dockerfile

`./variable-substitution-dotenv-dockerfile-work-easy-to-read/Dockerfile`


ARG BUSYBOX_VERSION="latest"
FROM busybox:${BUSYBOX_VERSION}

./variable-substitution-dotenv-dockerfile-work-easy-to-read/docker-compose.yml

`./variable-substitution-dotenv-dockerfile-work-easy-to-read/docker-compose.yml`


version: '3'
services:
  variable-substitution-dotenv-dockerfile-work-easy-to-read:
    build:
      context: ./
      args:
        BUSYBOX_VERSION: ${DOCKER_COMPOSER_BUSYBOX_VERSION}

Déclarez la variable BUSYBOX_VERSION dans Dockerfile à l'aide de l'instruction ARG, et déclarez utiliser latest comme valeur par défaut si aucune valeur n'est transmise par docker-compose.
Déclarez la variable BUSYBOX_VERSION dans la section args: de docker-compose.yml
Aussi, dans la clause args: de docker-compose.yml, assignez la variable DOCKER_COMPOSER_BUSYBOX_VERSION de .env à la déclaration de variable BUSYBOX_VERSION. --Définissez la valeur de la variable DOCKER_COMPOSER_BUSYBOX_VERSION dans le fichier .env

Les mots «variables» et «variables d'environnement» sont souvent déroutants, donc si vous regardez les noms de variables spécifiques, vous pouvez voir ce qui est hérité en tant que variables et valeurs.

Tout simplement parce que le nom (étiquette) est compliqué, vous pouvez comprendre le mécanisme de transmission du nom et de la valeur de la variable sous la forme .env-> docker-compose.yml-> Dockerfile.

Concernant la fonction de remplacement de variable utilisant le fichier .env (je doute que cette expression soit correcte ...) ** La fonction de remplacement de variable utilisant le fichier .env a une variable dans docker-compose.yml Cela peut être plus facile à comprendre si vous le considérez comme un mécanisme de transmission de valeurs **.

Un peu à part

En fait, je ne recommande pas le style d'écriture suivant comme illustré ci-dessus.

ARG BUSYBOX_VERSION="latest"
FROM busybox:${BUSYBOX_VERSION}

Par exemple, en raison des restrictions des actions github (etc.), les cas suivants demeurent.

La première instruction du fichier Dockerfile doit être FROM.

https://docs.github.com/ja/free-pro-team@latest/actions/creating-actions/dockerfile-support-for-github-actions#from

En premier lieu, compte tenu de l'uniformité de l'environnement (de développement | exécution), il est souhaitable d'utiliser une valeur fiable pour la valeur TAG de FROM sans même utiliser "latest".

Bien sûr, il peut y avoir des cas où ce n'est pas le cas, mais il existe des problèmes tels que le refus de mises à niveau majeures de la version en fonction du moment de la construction.

Exemple d'utilisation

Par exemple, lorsque vous faites docker-compose build, vous pouvez contrôler l'exécution de yarn run {script} par des environnements locaux, de préparation, de production et autres.

Supposons que vous ayez des environnements de construction séparés pour les environnements local, intermédiaire et de production, et que chacun ait un fichier .env.

Local .env *

`.env`


#...Abréviation...
DOCKER_COMPOSE_BUILD_TYPE="dev"
#...Abréviation...

Pour la mise en scène de .env *

`.env`


#...Abréviation...
DOCKER_COMPOSE_BUILD_TYPE="dev"
#...Abréviation...

Pour la production .env *

`.env`


#...Abréviation...
DOCKER_COMPOSE_BUILD_TYPE="prod"
#...Abréviation...

Supposons également que ces .envs soient gitignore et ne soient pas gérés par le référentiel.

Dans cet état, en préparant comme suit Dockerfile et docker-compose.yml, il est possible de contrôler chaque environnement tout en conservant un code source unique.

Dockerfile

#...Abréviation...
ARG BUILD_TYPE="local"
#...Abréviation...
RUN yarn run ${BUILD_TYPE}
#...Abréviation...

docker-compose.yml

`docker-compose.yml`


#...Abréviation...
    build:
#...Abréviation...
      args:
        BUILD_TYPE: ${DOCKER_COMPOSE_BUILD_TYPE}
#...Abréviation...

Vous pouvez également utiliser environnement: pour changer la destination du journal, le pilote de messagerie et le pilote de base de données pour chaque environnement.

Si vous développez en utilisant php, vous pouvez activer et désactiver xdebug, et vous pouvez modifier librement diverses valeurs de paramètres via .env de chaque individu.