Se esperaba esto. La clave environment: en docker-compose.yml es lo mismo que especificarla en el comando docker run para iniciar el contenedor. build y dockerfile son las claves antiguas utilizadas para construir la imagen.

Esto quizás no sea obvio en la documentación y podría mejorarse.

Docker no admite la inyección de entorno en el entorno de compilación (debe ser parte del Dockerfile), pero creo que hay algunas propuestas abiertas para agregar soporte para algo así.

Solo una referencia para cualquiera que encuentre este problema, aquí está la discusión de Docker sobre las variables de tiempo de compilación: https://github.com/docker/docker/issues/14634 y PR correspondiente: https://github.com/docker/docker / tirar / 15182

Esto nos hizo daño, realmente necesita mejores documentos.

La documentación es realmente confusa, por ejemplo, habla de env-file, que se usa para docker-compose.yml y se usa para docker run . Dado que docker-compose es una herramienta de orquestación para construir y ejecutar contenedores, es fácil asumir que el entorno se aplicaría al tiempo de compilación, usando --env <key>=<value> o algo como esto.

También me mordió.
Solo para dejar una nota de que las variables de entorno se pueden establecer como argumentos de compilación en el archivo de redacción. Como otros en este hilo, inicialmente esperaba que env_file o environment fueran utilizados tanto por build como por run.
Verificado con compose file v2, docker-compose v1.7, docker-engine v1.11.

Documentos actualizados en https://github.com/docker/compose/pull/3747

Tenga en cuenta que si necesita incluir env vars desde un archivo, puede hacer lo siguiente. Esto requerirá (en la sección de compilación de docker-compose) args establecidos a partir de estas variables, que luego puede consultar en su archivo de docker. Esto significa que si bien no puede reutilizar directamente su archivo env_file, puede hacerlo con un poco de trabajo adicional.

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

la respuesta a esta pregunta de desbordamiento de pila ayudó a https://stackoverflow.com/questions/19537645/get-environment-variable-value-in-dockerfile

es posible mapear las variables de entorno .env a ARGS para que las utilice el Dockerfile durante la compilación.

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 ¿Puedes agregar un enlace a la pregunta de Stack Overflow?

Lo siento chicos, no estoy seguro de entender cómo resolver esto, y me gustaría usar una imagen prediseñada.

Por ejemplo, mi archivo de redacción es:

versión: '3'

servicios:
web1:
imagen: softwaremaker / web-w
medio ambiente:

• wtmsdemo_customerapi01 = http: // api1 / api / values
  puertos:
• "89:80"
  depende de:
• api1
  api:
  imagen: softwaremaker / api-w
  redes:
  defecto:
  externo:

nombre: nat

Solía ​​pensar que la imagen de la API (softwaremaker / api-w) podrá resolverse en las variables de entorno que configuré anteriormente, pero no funciona.

@PatrLind
Agregué un enlace de stackoverflow a mi comentario original.

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

El problema sigue siendo relevante para los archivos env que no sean el archivo .env predeterminado.
El código de Fe Next no funcionará:

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

mientras que SERVER_NAME está definido en el segundo archivo env ( .env.local ).
No veo opciones para pasar env vars de .env.local para construir el contexto ((

@remort
También puedo confirmar esto, si tengo variables en uso durante la compilación, solo se pasan al proceso de compilación si el archivo se llama .env si se llaman .env.docker no obtienen recogido. Incluso cuando se especifica env_file para usar el archivo .env.docker .

Mi solución para esto durante mi compilación copiando el otro archivo env con nombre y renombrándolo a .env

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

Después de esto, pareció recoger las variables de entorno cuando se ejecuta el contenedor.

Sistema operativo: macOS (10.14.6)
Versión de escritorio de Docker: 2.1.0.5 (40693)
Versión del motor: 19.03.5
Redactar: 1.24.1

Hola chicos,

Una pregunta rápida para todos ustedes, ¿será esta una mejor manera de crear una imagen para los desarrolladores? Funciona bien hasta ahora. Sin embargo, ¿es esta la práctica recomendada? Todas las imágenes están basadas en buster.

''
DESDE redis: buster as redis
EJECUTAR mkdir / env && env> /env/.env_redis
EJECUTAR cat / etc / passwd
EJECUTAR ls -lah / home
DE ruby: slim-buster COMO ruby
EJECUTAR mkdir / env && env> /env/.env_ruby

DESDE el nodo: nodo AS lts-buster-slim
EJECUTAR mkdir / env && env> /env/.env_node

construir nginx

DESDE nginx: lo último como nginx
EJECUTAR mkdir / env && env> /env/.env_nginx

construir php

DESDE php: fpm-buster AS php

DESDE php: 7.3.14-fpm-buster AS php

EJECUTAR mkdir / env && env> /env/.env_php
COPIA --desde = redis / /
COPIA --desde = ruby ​​/ /
COPIA --desde = nodo / /
COPIA --desde = nginx / /

AÑADIR conf / include-site.conf /etc/nginx/conf.d/include-site.conf
AÑADIR conf / supervisord.conf /etc/supervisord.conf

EJECUTAR su raíz
EXPONER 80 443
WORKDIR "/ var / www / html"

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

El problema sigue existiendo.
La clave env_file en la sección de compilación será más clara que pasar env vars a través de argumentos a la compilación del contenedor.
Me gusta esto:

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

Porque estoy usando scripts de shell para compilar y componer Docker.
Para la producción, necesito un archivo env_file diferente al de dev / local.
Y hay muchos archivos docker-compose.env.yml con muchos argumentos, por lo que no es conveniente como creo

Creo que debe haber una forma elegante de evitar esto. Realmente me gusta la sintaxis de la ventana acoplable y el uso de argumentos en lugar de variables de entorno no tiene sentido para mí. No quisiera que alguien cambiara manualmente mis archivos de composición de docker. El cambio de valores en los archivos .env me parece consistente.