هذا متوقع. المفتاح environment: في docker-compose.yml هو نفسه تحديده للأمر docker run لبدء الحاوية. build و dockerfile هي المفاتيح القديمة المستخدمة في إنشاء الصورة.

قد لا يكون هذا واضحًا من الوثائق ويمكن تحسينه.

لا يدعم Docker إدخال البيئة في بيئة الإنشاء (يجب أن يكون جزءًا من Dockerfile) ، لكنني أعتقد أن هناك بعض المقترحات المفتوحة لإضافة دعم لشيء من هذا القبيل.

مجرد مرجع لأي شخص يجد هذه المشكلة ، هنا مناقشة عامل ميناء بخصوص متغيرات وقت البناء: https://github.com/docker/docker/issues/14634 والعلاقات العامة المقابلة: https://github.com/docker/docker / سحب / 15182

هذا صعب علينا ، حقا بحاجة إلى مستندات أفضل.

التوثيق محير حقًا ، على سبيل المثال يتحدث عن ملف env ، والذي يستخدم لـ docker-compose.yml ويستخدم لـ docker run . نظرًا لأن docker-compose هي أداة تنسيق لبناء الحاويات وتشغيلها ، فمن السهل افتراض أن البيئة ستنطبق على بناء الوقت ، باستخدام --env <key>=<value> أو شيء من هذا القبيل.

عضني كذلك.
فقط لترك ملاحظة مفادها أن متغيرات البيئة يمكن تعيينها كأرقام بناء في ملف الإنشاء. مثل الآخرين في هذا الموضوع ، كنت أتوقع في البداية env_file أو البيئة ليتم استخدامها من قبل كل من البناء والتشغيل.
تم التحقق منه مع إنشاء ملف v2 و docker-compose v1.7 و docker-engine v1.11.

تم تحديث المستندات في https://github.com/docker/compose/pull/3747

لاحظ أنه إذا كنت بحاجة إلى تضمين متغيرات البيئة من ملف ، فيمكنك القيام بما يلي. سيتطلب ذلك (في قسم إنشاء عامل الإرساء) مجموعة من هذه المتغيرات ، والتي يمكنك الرجوع إليها بعد ذلك في ملف عامل الإرساء. هذا يعني أنه بينما لا يمكنك إعادة استخدام ملف env_file الخاص بك مباشرة ، يمكنك القيام بذلك بقليل من العمل الإضافي.

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

ساعدت الإجابة على سؤال تجاوز سعة المكدس هذا https://stackoverflow.com/questions/19537645/get-environment-variable-value-in-dockerfile

من الممكن تعيين متغيرات البيئة .env إلى ARGS لاستخدامها بواسطة Dockerfile أثناء الإنشاء.

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 هل يمكنك إضافة ارتباط إلى سؤال Stack Overflow؟

آسف يا رفاق - لست متأكدًا من أنني أفهم كيفية حل هذا - وأود استخدام صورة مسبقة الصنع.

على سبيل المثال ، ملف الإنشاء الخاص بي هو:

الإصدار: '3'

خدمات:
الويب 1:
الصورة: softwaremaker / web-w
بيئة:

• wtmsdemo_customerapi01 = http: // api1 / api / القيم
  الموانئ:
• "89:80"
  يعتمد على:
• api1
  API:
  الصورة: softwaremaker / api-w
  الشبكات:
  إفتراضي:
  خارجي:

الاسم: نات

كنت أعتقد أن صورة api (softwaremaker / api-w) ستكون قادرة على حل متغيرات البيئة التي أعددتها أعلاه ولكنها لا تعمل.

تضمين التغريدة
أضاف ارتباط stackoverflow إلى تعليقي الأصلي.

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

لا تزال المشكلة متعلقة بملفات env بخلاف الملف الافتراضي .env .
لن يعمل رمز Fe Next:

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

بينما يتم تعريف SERVER_NAME في ملف env الثاني ( .env.local ).
لا أرى أي خيارات لتمرير env vars من .env.local لبناء سياق ((

Remort
يمكنني تأكيد ذلك أيضًا ، إذا كان لدي متغيرات يتم استخدامها أثناء الإنشاء ، فسيتم تمريرها فقط إلى عملية الإنشاء إذا كان الملف يسمى .env إذا تم تسميتها .env.docker لم يحصلوا عليها التقط. حتى عندما يتم تحديد env_file لاستخدام الملف .env.docker .

الحل الذي قدمته لهذا أثناء الإنشاء بنسخ ملف env المسمى الآخر وإعادة تسميته إلى .env

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

بعد ذلك بدا أنه يلتقط متغيرات البيئة عند تشغيل الحاوية

نظام التشغيل: macOS (10.14.6)
إصدار سطح المكتب من Docker: 2.1.0.5 (40693)
إصدار المحرك: 19.03.5
تكوين: 1.24.1

اهلا ياجماعة،

سؤال سريع لكم جميعًا ، هل ستكون هذه طريقة أفضل لبناء صورة للتطوير؟ إنه يعمل بشكل جيد حتى الآن. ومع ذلك ، هل هذه هي الممارسة الموصى بها؟ تستند جميع الصور إلى باستر.

""
من ريديس: باستر مثل ريديس
قم بتشغيل mkdir / env && env> /env/.env_redis
RUN cat / etc / passwd
تشغيل ls -lah / home
من الياقوت: سليم-باستر مثل ياقوت
قم بتشغيل mkdir / env && env> /env/.env_ruby

من العقدة: عقدة lts-buster-slim AS
قم بتشغيل mkdir / env && env> /env/.env_node

بناء nginx

من nginx: أحدث AS nginx
قم بتشغيل mkdir / env && env> /env/.env_nginx

بناء php

من php: fpm-buster AS php

من php: 7.3.14-fpm-buster AS php

قم بتشغيل mkdir / env && env> /env/.env_php
نسخ - من = redis / /
نسخ - من = ياقوت / /
نسخ - من = عقدة / /
نسخ - من = nginx / /

إضافة conf / include-site.conf /etc/nginx/conf.d/include-site.conf
أضف conf / supervisord.conf /etc/supervisord.conf

RUN su root
اكسبوز 80443
WORKDIR "/ var / www / html"

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

لا تزال المشكلة قائمة.
سيكون مفتاح env_file في قسم البناء أكثر وضوحًا من تمرير متغيرات env من خلال args لبناء حاوية.
مثله:

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

لأنني أستخدم برامج نصية شل لبناء وإنشاء عامل ميناء.
للإنتاج ، أحتاج إلى env_file مختلفة عن dev / local.
وهناك العديد من ملفات docker-compose.env.yml مع العديد من الوسائط لذا فهي ليست ملائمة كما أعتقد

أعتقد أنه يجب أن يكون هناك طريقة أنيقة للتغلب على هذا. أنا حقًا أحب بناء جملة عامل الإرساء واستخدام الحجج بدلاً من متغيرات البيئة غير منطقي بالنسبة لي. لا أريد أن يغير شخص ما ملفات إنشاء عامل الإرساء يدويًا. يبدو أن تغيير القيم في ملفات .env يتفق معي.