Ceci est attendu. La clé environment: dans le docker-compose.yml revient à la spécifier dans la commande docker run pour démarrer le conteneur. build et dockerfile sont les anciennes clés utilisées pour construire l'image.

Cela n'est peut-être pas évident dans la documentation et pourrait être amélioré.

Docker ne prend pas en charge l'injection d'environnement dans l'environnement de construction (il doit faire partie du Dockerfile), mais je pense qu'il existe des propositions ouvertes pour ajouter la prise en charge de quelque chose comme ça.

Juste une référence pour tous ceux qui trouvent ce problème, voici la discussion de docker concernant les variables de construction: https://github.com/docker/docker/issues/14634 et PR correspondant: https://github.com/docker/docker / pull / 15182

Cela nous a mordu, a vraiment besoin de meilleurs documents.

La documentation est vraiment déroutante, par exemple parle de env-file, qui est utilisé pour docker-compose.yml et est utilisé pour docker run . Étant donné que docker-compose est un outil d'orchestration pour la création et l'exécution de conteneurs, il est facile de supposer que l'environnement s'appliquerait au temps de construction, en utilisant --env <key>=<value> ou quelque chose comme ça.

Mord moi aussi.
Juste pour laisser une note que les variables d'environnement peuvent être définies comme arguments de construction dans le fichier de composition. Comme d'autres sur ce fil, je m'attendais initialement à ce que env_file ou environment soit utilisé à la fois par build et run.
Vérifié avec compose le fichier v2, docker-compose v1.7, docker-engine v1.11.

Documents mis à jour sur https://github.com/docker/compose/pull/3747

Notez que si vous devez inclure des variables d'environnement à partir d'un fichier, vous pouvez effectuer les opérations suivantes. Cela nécessitera (dans la section de construction de docker-compose) des arguments définis à partir de ces variables, auxquels vous pouvez ensuite vous référer dans votre fichier docker. Cela signifie que même si vous ne pouvez pas réutiliser directement votre env_file, vous pouvez le faire avec un peu de travail supplémentaire.

env $(cat vars.env | xargs) docker-compose up --build <whatever>

la réponse à cette question de débordement de pile a aidé https://stackoverflow.com/questions/19537645/get-environment-variable-value-in-dockerfile

il est possible de mapper les variables d'environnement .env à ARGS à utiliser par le Dockerfile pendant la construction.

docker-compose.yml

version: "2"
services:

  lumen:
    build:
      context: .
      dockerfile: ./Dockerfile
      args:
        - PORT=${PORT}
    volumes:
       ...

Dockerfile

FROM php:7.0-apache
ARG PORT

ENV PORT "$PORT"

EXPOSE ${PORT}
...

@williamli Pouvez-vous ajouter un lien vers la question Stack Overflow?

Désolé les gars - je ne suis pas sûr de comprendre comment résoudre ce problème - et j'aimerais utiliser une image prédéfinie.

Par exemple, mon fichier de composition est:

version: '3'

prestations de service:
web1:
image: softwaremaker / web-w
environnement:

• wtmsdemo_customerapi01 = http: // api1 / api / valeurs
  ports:
• "89:80"
  dépend de:
• api1
  api:
  image: softwaremaker / api-w
  réseaux:
  défaut:
  externe:

nom: nat

J'avais l'habitude de penser que l'image api (softwaremaker / api-w) pourra se résoudre dans les variables d'environnement que j'avais définies ci-dessus mais cela ne fonctionne pas.

@PatrLind
Ajout d'un lien stackoverflow à mon commentaire d'origine.

https://stackoverflow.com/questions/19537645/get-environment-variable-value-in-dockerfile

Le problème est toujours pertinent pour les fichiers env autres que le fichier par défaut .env .
Le code Fe Next ne fonctionnera pas:

  nginx:
    env_file:
      - .env
      - .env.local
    environment:
     - SERVER_NAME=${SERVER_NAME}
    build:
      context: ./nginx
      dockerfile: Dockerfile
      args:
        server_name: ${SERVER_NAME}

tandis que SERVER_NAME est défini dans le deuxième fichier env ( .env.local ).
Je ne vois aucune option pour passer des variables d'environnement à partir de .env.local pour créer un contexte ((

@remort
Je peux également le confirmer, si des variables sont utilisées pendant la construction, elles ne sont transmises au processus de construction que si le fichier est appelé .env s'ils sont nommés .env.docker ils ne reçoivent pas ramassé. Même lorsque env_file est spécifié pour utiliser le fichier .env.docker .

Ma solution pour cela lors de ma construction en copiant l'autre fichier env nommé et en le renommant en .env

COPY .env.docker ${APP_HOME}/.env
WORKDIR $APP_HOME

Après cela, il a semblé ramasser les variables d'environnement lorsque le conteneur s'exécute

Système d'exploitation: macOS (10.14.6)
Version du bureau Docker: 2.1.0.5 (40693)
Version du moteur: 19.03.5
Rédiger: 1.24.1

Salut les gars,

Une petite question pour vous tous, est-ce que ce sera une meilleure façon de créer une image pour le développement? Cela fonctionne très bien jusqu'à présent. Cependant, est-ce la pratique recommandée? Toutes les images sont basées sur Buster.

''
DE redis: buster comme redis
RUN mkdir / env && env> /env/.env_redis
RUN cat / etc / passwd
RUN ls -lah / home
FROM ruby: slim-buster AS ruby
RUN mkdir / env && env> /env/.env_ruby

Nœud FROM: nœud AS lts-buster-slim
RUN mkdir / env && env> /env/.env_node

construire nginx

FROM nginx: dernier AS nginx
RUN mkdir / env && env> /env/.env_nginx

construire php

À PARTIR de php: fpm-buster AS php

À PARTIR de php: 7.3.14-fpm-buster AS php

RUN mkdir / env && env> /env/.env_php
COPY - de = redis / /
COPY - de = rubis / /
COPY - à partir de = noeud / /
COPY - de = nginx / /

AJOUTER conf / include-site.conf /etc/nginx/conf.d/include-site.conf
AJOUTER conf / supervisord.conf /etc/supervisord.conf

RUN su root
EXPOSER 80443
WORKDIR "/ var / www / html"

ENTRYPOINT ["/ bin / bash", "/start.sh"]

Le problème existe toujours.
La clé env_file dans la section build sera plus claire que de passer env vars via args à la build du conteneur.
Comme ça:

#NOT_WORKING
build:
      context: ./client
      dockerfile: Dockerfile
      env_file: ${CURRENT_ENV_FILE}

Parce que j'utilise des scripts shell pour construire et monter docker compose.
Pour la production, j'ai besoin d'un fichier env_file différent de celui de dev / local.
Et il existe de nombreux fichiers docker-compose.env.yml avec de nombreux arguments, donc ce n'est pas pratique comme je le pense

Je pense qu'il doit y avoir une manière élégante de contourner cela. J'aime vraiment la syntaxe du docker et utiliser des arguments au lieu de variables d'environnement n'a pas de sens pour moi. Je ne voudrais pas que quelqu'un modifie manuellement mes fichiers docker-compose. La modification des valeurs dans les fichiers .env me semble cohérente.