Dies wird erwartet. Der Schlüssel environment: in docker-compose.yml der Angabe im Befehl docker run , um den Container zu starten. build und dockerfile sind die alten Schlüssel, die zum Erstellen des Bildes verwendet werden.

Dies ist möglicherweise aus der Dokumentation nicht ersichtlich und könnte verbessert werden.

Docker unterstützt das Injizieren einer Umgebung in die Build-Umgebung nicht (sie muss Teil der Docker-Datei sein), aber ich glaube, es gibt einige offene Vorschläge, um Unterstützung für so etwas hinzuzufügen.

Nur eine Referenz für alle, die dieses Problem finden. Hier finden Sie eine Docker-Diskussion zu Build-Time-Variablen: https://github.com/docker/docker/issues/14634 und die entsprechende PR: https://github.com/docker/docker / pull / 15182

Das hat uns hart gebissen, braucht wirklich bessere Dokumente.

Die Dokumentation ist wirklich verwirrend, z. B. spricht man von env-file, die für docker-compose.yml und für docker run . Angesichts der Tatsache, dass Docker-Compose ein Orchestrierungswerkzeug zum Erstellen und Ausführen von Containern ist, kann leicht davon ausgegangen werden, dass die Umgebung für die Erstellungszeit mit --env <key>=<value> oder ähnlichem gilt.

Hat mich auch gebissen.
Nur um einen Hinweis zu hinterlassen, dass Umgebungsvariablen als Build-Argumente in der Compose-Datei festgelegt werden können. Wie andere in diesem Thread hatte ich ursprünglich erwartet, dass env_file oder Umgebung sowohl vom Build als auch vom Run verwendet werden.
Verifiziert mit Compose File v2, Docker-Compose v1.7, Docker-Engine v1.11.

Aktualisierte Dokumente unter https://github.com/docker/compose/pull/3747

Beachten Sie, dass Sie Folgendes tun können, wenn Sie env vars aus einer Datei einfügen müssen. Dies erfordert (im Docker-Compose-Build-Abschnitt) Argumente, die aus diesen Variablen festgelegt wurden und auf die Sie dann in Ihrer Docker-Datei verweisen können. Dies bedeutet, dass Sie Ihre env_file zwar nicht direkt wiederverwenden können, dies jedoch mit ein wenig zusätzlicher Arbeit tun können.

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

Die Antwort auf diese Frage zum Stapelüberlauf half https://stackoverflow.com/questions/19537645/get-environment-variable-value-in-dockerfile

Es ist möglich, die Umgebungsvariablen .env ARGS zuzuordnen, die von der Docker-Datei während der Erstellung verwendet werden.

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 Können Sie der Frage zum

Sorry Leute - ich bin mir nicht sicher, wie ich das lösen soll - und ich möchte ein vorgefertigtes Image verwenden.

Zum Beispiel ist meine Erstellungsdatei:

Version: '3'

Dienstleistungen:
web1:
Bild: Softwarehersteller / Web-W
Umgebung:

• wtmsdemo_customerapi01 = http: // api1 / api / values
  Häfen:
• "89:80"
  kommt drauf an:
• api1
  api:
  Bild: Softwarehersteller / api-w
  Netzwerke:
  Standard:
  extern:

Name: nat

Früher dachte ich, dass das API-Image (Software / API-W) in die Umgebungsvariablen aufgelöst werden kann, die ich oben eingerichtet habe, aber es funktioniert nicht.

@PatrLind
Stackoverflow-Link zu meinem ursprünglichen Kommentar hinzugefügt.

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

Das Problem ist weiterhin für andere env-Dateien als die Standarddatei .env relevant.
Fe Nächster Code funktioniert nicht:

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

während SERVER_NAME in der zweiten env-Datei definiert ist ( .env.local ).
Ich sehe keine Optionen, um env vars von .env.local zu übergeben, um den Kontext zu erstellen ((

@remort
Ich kann dies auch bestätigen. Wenn während des Builds Variablen verwendet werden, werden diese nur an den Build-Prozess übergeben, wenn die Datei .env wenn sie .env.docker heißen, die sie nicht erhalten abgeholt. Selbst wenn env_file angegeben ist, um die Datei .env.docker verwenden.

Meine Lösung dafür während meines Builds Kopieren der anderen benannten env-Datei und Umbenennen in .env

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

Danach schien es die Umgebungsvariablen aufzunehmen, wenn der Container ausgeführt wird

Betriebssystem: macOS (10.14.6)
Docker Desktop Version: 2.1.0.5 (40693)
Motorversion : 19.03.5
Verfassen : 1.24.1

Hallo Leute,

Eine kurze Frage an euch alle: Wird dies ein besserer Weg sein, um ein Image für Entwickler zu erstellen? Es funktioniert soweit gut. Ist dies jedoch die empfohlene Vorgehensweise? Alle Bilder basieren auf Buster.

`` `
FROM redis: Buster als Redis
RUN mkdir / env && env> /env/.env_redis
RUN cat / etc / passwd
RUN ls -lah / home
VON Rubin: Slim-Buster als Rubin
RUN mkdir / env && env> /env/.env_ruby

FROM-Knoten: lts-buster-slim AS-Knoten
RUN mkdir / env && env> /env/.env_node

Nginx bauen

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

PHP bauen

VON PHP: Fpm-Buster AS PHP

AB PHP: 7.3.14-fpm-Buster AS PHP

RUN mkdir / env && env> /env/.env_php
COPY --from = redis / /
KOPIEREN --von = Rubin / /
KOPIEREN --von = Knoten / /
KOPIEREN --von = nginx / /

ADD conf / include-site.conf /etc/nginx/conf.d/include-site.conf
ADD conf / Supervisord.conf /etc/supervisord.conf

RUN su root
EXPOSE 80 443
WORKDIR "/ var / www / html"

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

Problem besteht noch.
Der Schlüssel env_file im Build-Abschnitt ist klarer als das Übergeben von env-Variablen durch Argumente an den Container-Build.
So was:

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

Weil ich Shell-Skripte verwende, um Docker Compose aufzubauen und aufzubauen.
Für die Produktion brauche ich eine andere env_file als für dev / local.
Und es gibt viele docker-compose.env.yml-Dateien mit vielen Argumenten, so dass es meiner Meinung nach nicht praktisch ist

Ich denke, es muss einen eleganten Weg geben, um das zu umgehen. Ich mag die Docker-Syntax sehr und die Verwendung von Argumenten anstelle von Umgebungsvariablen macht für mich keinen Sinn. Ich möchte nicht, dass jemand meine Docker-Compose-Dateien manuell ändert. Das Ändern von Werten in den .env-Dateien erscheint mir konsistent.