إلى أي مدى تريد أن تذهب مع معايير UNIX المعمول بها هذه؟ (FWIW ، إنه ليس معيارًا فعليًا ، إنه معيار فعلي.)

باعتباري شخصًا يحاول عن طريق الخطأ استخدام توسعات معلمات POSIX في Dockerfiles ، إذا كانت مدعومة على الإطلاق في docker-compose.yml ، فسيكون ذلك بمثابة عربة سعيدة.

kojiromike Hmm ، لذا فإن توسيع معلمة POSIX هو في الواقع ما كنت أسعى إليه ، لكن قراءة المستندات يبدو أنني أخطأت في تذكر بناء الجملة / الدلالات.

تحرير: لقد قمت بتحديث أفكاري حول بناء الجملة في الوصف.

لقد كنت أتابع الموضوع القديم وأردنا بشكل عاجل الحصول على هذه الميزة. أخيرًا ، كان الألم كبيرًا جدًا وقمنا بإنشاء برنامج yaml preprocessor bahs لاستبدال المتغيرات بأسلوب POSIX. كان يعمل بشكل جيد ولكن في النهاية توقفنا عن استخدامه ، لأنه كان به مشكلة واحدة. يجب عليك تشغيل المعالج المسبق أولاً وتعيين جميع المعلمات قبل أن تحصل على الحل النهائي. نحن الآن نستخدم ميزة docker yaml extends. لأنه يسمح لنا بالتحقق من التكوين الفعلي وتنفيذه فقط على الهدف. نحن نعرف بشكل أفضل ما سيحدث.

على الرغم من أنني كنت مؤيدًا لمتغيرات تمرير تكوين عامل الإرساء ، إلا أنني لست متأكدًا الآن.

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

انظر إلى المثال الفعلي وكيف يكون مطولًا. لا يوجد سوى سطرين مهمين.

#Common 
elasticsearch:
  image: zinvoice/elasticsearch
  hostname: elasticsearch
  restart: always
  dns: 172.17.42.1
  ports:
    - "9200:9200"
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - /etc/timezone:/etc/timezone:ro
    - /data/elasticsearch:/opt/elasticsearch/data/elasticsearch

logstash:
  image: zinvoice/logstash
  hostname: logstash
  dns: 172.17.42.1
  restart: always
  ports:
    - "5000:5000"
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - /etc/timezone:/etc/timezone:ro

kibana:
  image: zinvoice/kibana
  hostname: kibana
  dns: 172.17.42.1
  restart: always
  ports:
    - "5601:5601"
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - /etc/timezone:/etc/timezone:ro

logspout:
  image: zinvoice/logspout
  hostname: logspout
  command: logstash://logstash.docker:5000
  restart: always
  dns: 172.17.42.1
  ports:
    - "8003:8000"
  volumes:
    - /var/run/docker.sock:/tmp/docker.sock

doorman:
  image: zinvoice/doorman
  hostname: doorman
  restart:  always
  dns: 172.17.42.1
  ports:
    - "8085:8085"

# inherited
elasticsearch:
  extends:
    file: ../common.yml
    service: elasticsearch

logstash:
  extends:
    file: ../common.yml
    service: logstash

kibana:
  extends:
    file: ../common.yml
    service: kibana

logspout:
  extends:
    file: ../common.yml
    service: logspout

doorman:
  environment:
    - DOORMAN_GITHUB_APPID=xxxxxxxx
    - DOORMAN_GITHUB_APPSECRET=xxxxxx
  links:
    - nginxtrusted
  extends:
    file: ../common.yml
    service: doorman

لذا فإن توصيتي لإصلاح عامل الإرساء يمتد لجعله أقل إسهابًا. ليس عليك حتى كتابة هذا القدر من الكود لأن YAML يوفر جميع الوظائف التي تحتاجها. إذا التزمت بـ YAML القياسي ، فيمكن تحليل الملف أو إنشاؤه بواسطة أدوات وواجهات مستخدم أخرى.

ألق نظرة على YAML "node anchors" و YAML "file merge" فقد يكون الحل الأمثل.

لمعلوماتك: هذه المناقشة مستمرة الآن في # 1380

@ Vad1mo أوافق على أن extends قاصر في قضيتك. هناك الكثير من الأشياء التي يمكننا القيام بها لتحسين هذه التجربة - هل يمكنك فتح مشكلة منفصلة لها ، حتى لا يتم تجاوزها هنا؟

بالطبع! أردت فقط أن أوضح أن هذا يمكن أن يكون بديلاً سهلاً وأنيقًا.
إذا كان التأليف يمتد إلى نصف الطريق الذي يجتازه متغيرًا جدًا ، فإن امتدادات التركيب المحسّنة ستجعل تمرير المتغير قديمًا. وجود مفاهيم أقل لفهمها يسهل على المستخدم.

حالة الاستخدام الخاصة بي هي السماح لـ $PWD volumes ، لذلك يمكن لكل مطور في الفريق استنساخ الريبو إلى أي مكان ولا يزال يتم تثبيت المسارات بشكل صحيح.

elasticsearch:
  image: zinvoice/elasticsearch
  volumes:
    - $PWD:/app

mattes أعتقد أنه مدعوم بالفعل ، أعتقد أن .:/app مدعوم أيضًا

aanand بصفتي PoC قمت باختراق قذر لـ POSIX PE في Python . أيام السبت.

kojiromike تبدو رائعة. اسمحوا لي أن أعرف إذا كنت تخطط للاستمرار في ذلك.

aanand أعتزم ذلك ، لكن بالتأكيد بها بعض الأخطاء في الوقت الحالي (وأعتقد أنه ربما كانت فكرة سيئة استخدام shlex ). تقارير الأخطاء والعلاقات العامة مرحب بها ، بالطبع.

dnephin ماذا عن $HOME / ~ ؟

nafg كلاهما مدعوم لمسار المضيف لوحدة تخزين

dnephin مثير للاهتمام ، b / c بطريقة ما انتهى بي الأمر بدليل باسم "$ HOME" ...

aanand مثل VARIABLE: default }" ، مع global_extends (أو "استيراد") ، سيصبح هذا قوياً إلى حد ما.

س: هل سيسمح ذلك بتحديد رقم المنفذ الذي يتعرض للمضيف؟ مثل - "$ {WEB_ PORT: 80 }: 80"؟
حالة الاستخدام هي أن تكون قادرًا على تدوير العديد من مثيلات التطبيق بسهولة على نفس الجهاز / المجموعة ، وعادةً ما تستمع إلى منافذ مختلفة أو يتم تعيينها لأسماء نطاقات محلية مختلفة.

نعم ، ستكون قادرًا على فعل ذلك.

أرغب في استخدام المتغيرات في المجلدات مع docker-compose scale my_app=3 . لدي هذا docker-compose.yml

server:
  image: alexanderilyin/docker-teamcity-server
  ports:
   - "8111:8111"
  volumes:
    - .TeamCity:/root/.BuildServer
  links:
   - mysql
mysql:
  image: alexanderilyin/docker-mysql
  volumes:
    - .MySQL:/var/lib/mysql
  environment:
    MYSQL_DATABASE: teamcity
    MYSQL_USER: teamcity
    MYSQL_PASSWORD: teamcity
    MYSQL_ALLOW_EMPTY_PASSWORD: yes
agent:
  image: alexanderilyin/docker-teamcity-agent
  links:
   - server

وأريد أن أكون قادرًا على استخدام scale للوكلاء واستخدام وحدات التخزين الديناميكية لهم للاحتفاظ بالبيانات بين عمليات الإطلاق ، على سبيل المثال:

agent:
  image: alexanderilyin/docker-teamcity-agent
  volumes:
    - .agent_{$AGENT_INSTANCE_ID}:/opt/buildAgent
  links:
   - server

آمل أن يكون من الممكن إقحام المتغيرات كجزء من اسم الصورة أيضًا
نحن نستخدم https://github.com/openshift/source-to-image لبناء حاوية محلية على CI لكل فرع ثم إجراء الاختبارات عليها باستخدام docker-compose.
يعد إجراء الاختبارات باستخدام الصورة الديناميكية أمرًا معقدًا للغاية مع إنشاء عامل ميناء ويتطلب عرض نموذج يدوي ..: -1:

ولكن يمكنك تعيين COMPOSE_PROJECT_NAME للتحكم في البادئة لكل تشغيل لتتمكن من القيام بذلك بشكل صحيح بالفعل؟ إذا كان الأمر كذلك ، فلا داعي لوجود منطق معقد وملفات yml غير قابلة للقراءة حول الأسماء.

andrerom لا تتبع. وفقًا للمستندات التي تتحكم في Sets the project name, which is prepended to the name of every container started by Compose بينما نحاول تعيين خاصية صورة بدلاً من ذلك:

web:
  image: <I_AM_DYNAMIC>

آه ، خطأي.

اعتقدت قصدت

<I_AM_DYNAMIC>:
  image: nginx

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

حالة استخدام إضافية _ (والتي قد تكون ما يدور في ذهن @ Maxim-Filimonov) _: القدرة على تجاوز العلامة لاستخدام صورة ، بحيث يمكنك استخدام: الأحدث افتراضيًا ، ولكن قم بالتغيير لاختبار شيء آخر بسهولة دون تغيير yml ملف _ (مطلوب لحالات استخدام CI بشكل أساسي) _.

andrerom هذا هو بالضبط حالة استخدامنا: +1:

هل سيعمل هذا أيضًا مع أشياء مثل ؟؟

web:
  environment:
    - FOO=${whoami}

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

في هذه الحالة بالذات ، من المحتمل أن يمنحك متغير البيئة $USER نفس الشيء.

aanand لماذا لا تستخدم أيًا من محركات القوالب الموجودة الموجودة بالفعل؟ Jinja2 هناك ويعمل بشكل جيد.

كما ذكرنا سابقًا - يعد تنفيذ القوالب الخاصة بنا مهمة غير تافهة (و regexps ليست بهذه الروعة) لذا يجب علينا استخدام واحدة موجودة بالفعل ، والتي ثبت أنها قوية.

بدلاً من ذلك ، قد نستخدم مراجع YAML والمراجع https://gist.github.com/bowsersraduate/979804

ولكن بعد ذلك نحن مقيدون باستخدام المتغيرات (حقن اسم متغير في منتصف المحتوى).

+1 لـ Jinja2: من المؤكد أنه سيتناسب مع القالب واستخداماته غير المعقولة
حالة الاستخدام هذه بالضبط (إنشاء نماذج في ملفات yml)

في الثلاثاء 26 مايو 2015 الساعة 1:25 ظهرًا ، كتب tonnzor [email protected] :

aanand https://github.com/aanand لماذا لا تستخدم أي قالب موجود
المحركات الموجودة بالفعل؟ Jinja2 هناك ويعمل بشكل جيد.

كما ذكرنا من قبل - تنفيذ القوالب الخاصة بنا هو مهمة غير تافهة
(و regexps ليست بهذه الروعة) لذا يجب أن نستخدم واحدة موجودة بالفعل ،
التي أثبتت صلتها.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/1377#issuecomment -105493447.

Jinja2 يفعل _lot_ أكثر مما نحتاج:

• الشرطية
• حلقات
• التمديد / الميراث
• تعليقات
• المرشحات

نحن لا نضيف أيًا من هذه الأشياء إلى Compose. إذا كان من الممكن تكوين Jinja2 لاستيفاء المتغيرات فقط ، فقد يكون مرشحًا.

في الواقع قد يكون التكرار مثيرًا للاهتمام.

افترض أن لديك قائمة بالعملاء الذين تريد بدء الحاويات لهم
حيث تضع بعض المتغيرات الخاصة بالعميل في البيئة.

قد يكون التمديد / الميراث ممتعًا لتحسين التيار
آلية تمديد بدائية.

يمكن أن تكون المرشحات رائعة للقيام بشيء ما باستخدام المتغيرات الحالية.

يوم الثلاثاء ، 26 مايو ، 2015 الساعة 1:56 مساءً ، Aanand Prasad [email protected]
كتب:

Jinja2 يفعل _lot_ أكثر مما نحتاج:

• الشرطية
• حلقات
• التمديد / الميراث
• تعليقات
• المرشحات

نحن لا نضيف أيًا من هذه الأشياء إلى Compose. إذا كان من الممكن تكوين Jinja2
لاستيفاء المتغيرات فقط ، فقد يكون مرشحًا.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/1377#issuecomment -105498909.

قد تكون ميزات مثيرة للاهتمام ، لكنها تأتي مع تعقيد أكثر بكثير مما أشعر بالراحة عند تقديمه إلى كل من تنسيق الملف والملف ، وسنقوم بربطهما بلغة قوالب معينة (على حد علمي) بتنفيذ واحد ولا المواصفات. إنه ببساطة غير ممكن.

aanand بعض الملاحظات هنا:

1. Jinja2 صلب ويستغرق الأمر دقائق للقيام بمعالجة مسبقة لـ YAML معها:

من قالب استيراد jinja2
template = Template ("مرحبًا {{name}}!")
template.render (الاسم = "أناند")
مرحبا اناند!

إذا كنت تريد المزيد من الأمان - يمكنك استخدام وضع الحماية الثابت:

من jinja2.sandbox استيراد ImmutableSandboxedEnvironment
env = ImmutableSandboxedEnvironment ()
template = env.from_string ("مرحبًا {{name}}!")
template.render (الاسم = "أناند")
مرحبا اناند!

في حالتنا سيكون:

استيراد نظام التشغيل
من jinja2.sandbox استيراد ImmutableSandboxedEnvironment
env = ImmutableSandboxedEnvironment ()
template = env.from_string ("مرحبًا {{name}}!")
template.render (** os.environ)

1. ألا نريد مرشحات؟ باستخدام الفلتر ، يمكنك تحديد القيمة الافتراضية بسهولة ({{القيمة | الافتراضية ("الافتراضية")}})
2. هل نحتاج حقًا إلى الاهتمام بالمستخدمين الذين يستخدمون ميزات Jinja الموسعة لربط ملف YAML؟ بنفس الطريقة يمكن للمستخدم إنتاج ملف YAML غير صالح يدويًا. أعتقد أننا يجب أن نبقي الأمر بسيطًا - حاول معالجة نموذج Jinja المعطى وإرجاع الخطأ إذا كان هناك خطأ أو أن YAML المنتج غير صالح (نفس ما تفعله الآن).
3. إذا كنت لا ترى Jinja2 كحل - سيكون من الرائع على الأقل استخدام {{متغير}} كتركيب.
4. يستخدم Django التعبير العادي لتحليل القالب وإنشائه. إنها درجة إنتاج لفترة طويلة وتعيش بشكل جيد معها.

استيراد نظام التشغيل
إعادة الاستيراد
template = "مرحبًا {{name}}!"
re.sub ("{{\ s _ ([a-zA-Z0-9 _] +؟) \ s_}}"، lambda m: os.environ.get (m.group (1)، '')، template)

على أي حال - نحتاج إلى عرض هذه الميزة ، مهما كان الحل الذي نتخذه.

أنا +1 على استخدام الحل النموذجيه عام إذا تعتبر القوالب. على سبيل المثال http://mustache.github.io ، وهو متوفر بعدة لغات. هذا مجرد مثال ، يمكن اعتبار محركات القوالب الأخرى على قدم المساواة

aanand أنا أفهم وجهة
إيجاز تكوين dsl.

ربما يجب أن يتم ذلك كمشروع خارجي ، على سبيل المثال ، الملحن الفوقي. ذلك
يأخذ compose.tpl.yml ومتغيرات .yml ، ينشئ عامل تركيب عامل تركيب.
وها نحن ننطلق.
كما أظهر tonnzor ، يمكن القيام بقطعة صغيرة من كود الثعبان.

هذا من شأنه أن يقدم قوالب قوية لأولئك الذين يحتاجون إليها بدونها
إدخال التعقيد للمهام البسيطة.

يوم الثلاثاء 26 مايو 2015 الساعة 4:52 مساءً ، سيباستيان فان ستيجن <
[email protected]> كتب:

أقوم بإجراء +1 على استخدام حل قوالب _generic إذا كانت القوالب كذلك
اعتبر. على سبيل المثال http://mustache.github.io ، وهو متوفر في كثير
اللغات. هذا مجرد مثال ، يمكن أن تكون محركات القوالب الأخرى
تعتبر على قدم المساواة

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/1377#issuecomment -105551631.

حسنًا ... هذا هو الاقتراح الآن باستخدام لغة قوالب داخل compose.yml (وهي لغة وصفية لتكوين حاويات Docker) ، لأشياء مثل command و entrypoint ، والتي تقبل بالفعل كلا exec قيم النمط sh -c ؟ قد يكون هذا محيرًا ، لأنه بعد عرض القالب ، من المفترض أن يتم تفسير أمر shell الناتج ، لذلك إذا حدث أن توسع متغير إلى * فسيتم توسيعه بشكل أكبر. يصبح الهروب من التسلسلات في لغة أو أخرى أمرًا صعبًا عندما يكون لديك هذه الطبقات العديدة من التفسير الخاطئ.

kojiromike لست متأكدًا من إذا كان سيتم استخدامه! أفضل استخدام شيء معروف. السؤال الأساسي هو ؛ يجب أن يكتب عامل الميناء كتابة الاستبدال من الصفر ، أو يستخدم شيئًا موجودًا.

في الثلاثاء ، 26 مايو 2015 ، الساعة 11:02 صباحًا كريستوف ويتزاني [email protected]
كتب:

aanand أنا أفهم وجهة
إيجاز تكوين dsl.

ربما يجب أن يتم ذلك كمشروع خارجي ، على سبيل المثال ، الملحن الفوقي. ذلك
يأخذ compose.tpl.yml ومتغيرات .yml ، ينشئ عامل تركيب عامل تركيب.
وها نحن ننطلق.

يمكنك القيام بذلك اليوم دون أي مشروع جديد. أنا متأكد من أن jinja يمكن أن تكون
تم استدعاؤه من سطر الأوامر بطريقة ما. شخصيا أنا فقط استخدم envsubst
أمر.

ما سيكون مفيدًا حقًا هو إذا كان بإمكان إنشاء قراءة الملف من stdin.
هذا من شأنه أن يلغي الحاجة إلى ملف وسيط.

كما أظهر tonnzor ، يمكن القيام بقطعة صغيرة من كود الثعبان.

هذا من شأنه أن يقدم قوالب قوية لأولئك الذين يحتاجون إليها بدونها
إدخال التعقيد للمهام البسيطة.

يوم الثلاثاء 26 مايو 2015 الساعة 4:52 مساءً ، سيباستيان فان ستيجن <
[email protected]> كتب:

أقوم بإجراء +1 على استخدام حل قوالب _generic إذا كانت القوالب كذلك
اعتبر. على سبيل المثال http://mustache.github.io ، وهو متوفر في كثير
اللغات. هذا مجرد مثال ، يمكن أن تكون محركات القوالب الأخرى
تعتبر على قدم المساواة

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/1377#issuecomment -105551631.

قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/1377#issuecomment -105554730. src = "
https://ci6.googleusercontent.com/proxy/iSBXyl7D8PwFM4p1mGPHCR7bQctunieGbhyGkvo0QIMIjmAYE3I0Mt96yl1fGrqcuOzxV4APP8ZRIw-5_qd6nzps9Mpr6jTAydCC4xs8JDgqm93aIbWvN1eMlxykrz7iwYooyAQdqL4RFJokeEbnBkZm5mhgKg=s0-d-e1-ft#https://github.com/notifications/beacon/AAGAUO8xqz29B2SUoG7QFPUy848_JJW9ks5oNIJlgaJpZM4EMysO.gif
">

+1 لقراءة الملف من stdin. ليس لدي مشكلة في استخدام حل قالب خارجي ولكن عدم وجود ملفات وسيطة سيكون أمرًا رائعًا.

تبدو هذه خطوة أولى رائعة وميزة مشتركة للعديد من أدوات cli. لنفعل ذلك

: +1:

على سبيل المثال

envsubst compose.tmpl.yml | docker-compose -f - up -d

wfm. : +1:

لاحظت للتو أن عامل الإرساء / التوزيع يتعامل مع تجاوز القيم في ملف yml عبر متغيرات البيئة ، ولكن باستخدام نهج مختلف https://github.com/docker/distribution/blob/master/docs/configuration.md#override -configuration-options

^^ aanand

thaJeztah التي ستعمل معنا أيضًا. يمكننا استخدام متغيرات البيئة لتجاوز الأوامر بعد ذلك

DOCKER_COMPOSE_IMAGE_NAME='my_image:is_dynamic'

نهج مثير للاهتمام ، لكنني لست من المعجبين - أسماء متغيرات بيئة مطولة ، والكثير من التكرار إذا كنت تريد استخدام قيمة واحدة في أماكن متعددة ، كل شيء ضمني ، لا يوجد استيفاء داخل السلاسل.

aanand لم يبع هذا النهج حقًا أيضًا ، لكنه أراد الإشارة إليه لأنه مشروع آخر ضمن منظمة "Docker".

عثرت للتو على https://github.com/kelseyhightower/confd والتي قد تكون ذات فائدة. يستخدم http://golang.org/pkg/text/template/#pkg -overview

olalonde لسوء الحظ ، فإن compose مكتوب بلغة Python ، لذا لن تعمل قوالب Go.

aanand أنا +20 في

كتبت حزمة بيثون صغيرة تساعدني في ذلك. تتمثل الخطة في تمرير جميع الأوامر عبر نفق لإنشاء عامل الإرساء حتى تتمكن من استخدامها بشكل مكافئ.
تحقق من ذلك على https://github.com/webcrofting/meta-compose/

يبدو التأليف الفوقي رائعًا حقًا. يجب أن تكون متكاملة لتكوين عامل الإرساء!

إجراء 1+ كبير هنا - لست متحمسًا بشأن المعالجة المسبقة للقالب ، لكن سحب متغيرات البيئة بطريقة أو بأخرى سيكون أمرًا رائعًا. من المحتمل أن يكون توسع POSIX أنظف من Jinja2 ، لكن كلا الحالتين جيد.

+1 كبيرة من هنا أيضًا. حالة الاستخدام الخاصة بي هي أكثر لإضافة دعم معرّف إعلان ديناميكي لحاوية كافكا وهو أمر حيوي لمنتجي البيانات (والتي يمكن أن تكون حاويات أخرى).

أنا متحمس أيضًا لهذه الميزة.

من المحتمل أن يكون توسع POSIX أنظف من Jinja2 ، لكن كلا الحالتين جيد.

أعتقد أن الحجة الأخرى المؤيدة لتوسيع POSIX هي أنه ليس منطقًا. يدعم Jinja2 درجة معينة من المنطق الشرطي / الحلقة (كما تفعل معظم محركات القوالب ، حتى تلك التي تدعي أنها "أقل منطقية"). يعد خلط منطق القوالب و YAML أمرًا غريبًا جدًا في تجربتي. هل يمكن لأي شخص أن يفكر في حالة استخدام لمثل هذا المنطق؟ إذا لم يكن الأمر كذلك ، فقد يكون من الأفضل تجنب الدعم على وجه التحديد في الوقت الحالي.

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

إذا كنت تفعل ، بأي نوع من الآلية؟ إذا لم تقم بذلك ، فيمكن للأشخاص البدء في إنشاء بعض أدوات الطرف الثالث لإدارة الميزة.

شكرا لك !

حسنًا ، لقد رأيت للتو https://github.com/docker/compose/pull/76. أعتقد أن الجواب موجود ...

سار بضع دورات على القضايا المرتبطة / العلاقات العامة.

رفض مجتمع AFAIK و nginx اعتماد أي محرك قالب لملفات التكوين ، حتى بالنسبة لاستبدال متغير بسيط. لماذا ا؟ ربما ، ما زالوا يختارون محرك نموذج مثالي: ابتسامة :. نتيجة؟ الم (نسبيا)!

hadim

قراءة العديد من القضايا والعلاقات العامة ، ليس من الواضح ما إذا كنت تريد حقًا تنفيذها أم لا.

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

شكرا لك aanand !

شكرا ، aanand.

+1 بالنسبة لي. أحتاج إلى تمرير --dns = (عنوان جسر docker0) ، وأحتاجه للعمل إذا تغير ذلك في الإصدارات المستقبلية من عامل الإرساء ، لذلك فإن متغير البيئة و / أو shell مثالي. لا يعمل تكوين الفوقية بالنسبة لي ، حيث يجب أن يدعم DOCKER_HOST عن بُعد وعلى سبيل المثال عبر docker-swarm ، وليس محليًا فقط.

: +1: سيكون هذا لطيفًا جدًا. في الوقت الحالي ، إما أن ينتهي بي الأمر بإنشاء ملف .yml عبر برنامج نصي آخر ، أو لا أستخدم عامل إنشاء السفن تمامًا ، ووحدات الإرساء المرتبطة يدويًا.

:رضى وقبول:

أعتقد أن الاستيفاء الأساسي لمتغير البيئة سيكون مفيدًا جدًا للأشياء البسيطة.

زوجان من حالات الاستخدام البسيطة:

• القدرة على تحديد علامة الصورة بشكل ديناميكي لسحبها من مستودع بعيد.
• القدرة على تعيين تعيين المنفذ للحاوية.

أدوات مثل Ansible تقوم بالفعل بعمل قوالب بشكل جيد للغاية ، لذلك لست متأكدًا من الحاجة إلى محرك قالب كامل. لكن عدم القدرة على الحصول على أي محتوى ديناميكي في ملف comose.yml أمر محدود للغاية.

بخصوص PR # 1488 المدمج ، أنا مهتم بشكل خاص بتوصيل ملف التكوين إلى docker-compose . لا أستطيع أن أفهم سبب عدم قدرة docker-compose المتابعة من عملية العقدة.

var spawn = require('child_process').spawn;

var compose = spawn('docker-compose', ['--file' + '-' + 'up']);

compose.stdin.setEncoding = 'utf-8';

compose.stdout.on('data', function (data) {
    console.log('"docker-compose --file - up" stdout: "%s".', data);
});

compose.stderr.on('data', function (data) {
    console.log('"docker-compose --file - up" returned an error: "%s".', data);
});

compose.on('close', function (code) {
    if (code !== 0) {
        console.log('"docker-compose --file - up" existed with an erroneous code: "%s".', code);
    } else {
        console.log('"docker-compose --file - up" existed with code: "%s". SUCCESS!', code);
    }
});

compose.stdin.write("redis: {\"image\": \"redis\"}\n");
compose.stdin.end();

هل من أمثلة حول كيفية توجيه البيانات من Node.js؟

شيء آخر وجدته هو أن docker-compose 1.4.0-RC1 يرسل بعض الرسائل التي تبدو عادية مثل Starting... أو Attaching... إلى stderr بدلاً من stdout .

kadishmal هل يمكنك فتح قضايا منفصلة لهذه من فضلك؟

آخر مرشح تركيب / التنفيذ: النموذجيه سلسلة بايثون، على النحو المحدد في PEP 0292 ونفذت في string.Template .

إنه مشابه جدًا لتوسيع معلمة POSIX:

• $foo يتوسع إلى قيمة foo
• ${foo} يتوسع إلى قيمة foo
• $ ، ${ ، $} ، ${} ، ${foo ، $ {foo} ، ${ foo} ، ${foo } أخطاء

عيوب:

• لا توجد قيمة افتراضية أو بناء جملة "قيمة مطلوبة". ومع ذلك ، يمكننا أن نقرر لاحقًا ما إذا كنا نريد ما يكفي لاستحقاق كتابة كود القالب الخاص بنا.
• لا تعرض رسائل الخطأ أي معلومات يمكن للجهاز قراءتها حول مكان وجود خطأ في بناء الجملة (بدون إجراء مطابقة regex على سلسلة الخطأ ، أي).
• يختلف بناء جملة الهروب عن POSIX: $$ بدلاً من \$ .

قد تكون هذه في الواقع نعمة مقنعة: YAML لا تحب \$ ، وتتطلب منك الهروب المزدوج. لا أعتقد أن إخبار الناس بكتابة \\$ لمجرد الحصول على علامة الدولار سوف يطير.

لقد أطلقت عملية تنفيذ في # 1765.

+1

لست متأكدًا مما إذا كان هذا هو المكان المناسب لذلك ، أو ما إذا كان يجب علي إنشاء عدد جديد.

أعتقد أن أسبقية البيئة يجب أن تكون في الاتجاه المعاكس ، أي أن متغيرًا من الغلاف الذي يستدعي عامل عامل التركيب يجب أن يتجاوز أي متغير داخل docker-compose.yml ، والذي بدوره يجب أن يتجاوز أي متغير محدد بواسطة الحاوية.

إليك ما يحدث حاليًا عندما أحاول:

docker-compose.yml:

test:
    image: ubuntu
    environment:
        - FOO="from compose"

ثم قم بتشغيله باستخدام الأمر env :

docker-compose run test env | grep FOO

يعطي FOO="from compose" ، كما هو متوقع. لكن بعد ذلك:

FOO="from shell" docker-compose run test env | grep FOO

يعطي أيضًا FOO="from compose" ، لكن هنا كنت أتوقع FOO="from shell" .

قد لا يزال بعض الأشخاص بحاجة أيضًا إلى الاستيفاء المتغير لحالات الاستخدام الأخرى ، ولكن تغيير هذا من شأنه أن يلبي الحالة "الافتراضية" - تعريف / قيمة environment: فعليًا في docker-compose.yml هو الافتراضي ، ويمكن تجاوزه في وقت التشغيل إذا لزم الأمر ، دون الحاجة إلى أي صيغة YAML إضافية.

fazy لم تأخذ في الحسبان أن الأمر env تم تنفيذه في الحاوية test المعزولة التي تكون فيها FOO from compose (فقط كما يجب أن يكون وكما تم تكوينه في ملف docker-compose ). ولكن خارج تلك الحاوية ، إذا كانت العملية docker-compose تحتوي على نوع من وظيفة الطباعة لمتغير البيئة الذي قمت بإعداده قبل الأمر الذي كان سيطبع "من shell" لأنه القيمة للمضيف (وكذلك لـ عملية docker-compose ) التي تقوم بتشغيلها عليها. ربما كنت تتوقع أن تكون FOO from shell في هذه الحالة ، لكن شخصيًا سأكون مندهشًا جدًا إذا كانت كذلك. (أتمنى على الرغم من لغتي الإنجليزية أن تفهم وجهة نظري).

smileart شكرا ، أعتقد أنني أرى ما تقوله.

ومع ذلك ، فإن الحاوية test ليست معزولة تمامًا ، فهي تحصل على بيئتها من docker-compose (أو على الأقل ، يمكن لـ docker-compose تعيين متغيرات البيئة في الحاوية التي تم إطلاقها) ، و docker-compose يمكن أن يرى نفسه متغير البيئة "الخارجي".

يمكنك أن ترى مع هذا docker-compose.yml:

test:
    image: ubuntu
    environment:
        - FOO

ثم الأمر:

FOO="from shell" docker-compose run test env | grep FOO

يعطي بالفعل نتيجة "من قذيفة".

لذا فإن سؤالي عن الأسبقية. من خلال تحديد اسم المتغير هنا فقط ، - FOO ، يمكنني حقن المتغير من الخارج. ولكن إذا قمت بتحديد - FOO=something _ وأدخلت متغيرًا من الخارج ، فما الذي يجب أن يكون له الأولوية؟ IMHO يجب أن يكون للمتغير المحدد في سطر الأوامر الأسبقية على ملف التكوين.

fazy أوه ، آسف ، لم أجرب FOO="from shell" docker-compose run test env | grep FOO بدون تحديد قيمته في docker-compose.yml ولم أكن أعرف أنه يعطينا قيمة FOO للمضيف. لذلك لن يكون الأمر غريبًا بالنسبة لي فقط: مبتسم: اعتقدت أن إعداد متغير بيئة قبل docker-compose سيؤثر على docker-compose و docker-compose فقط دون إلقائه في حاوية. الآن أرى ماذا تقصد.

لقد عثرت للتو على عيب الهروب من $ المذكور في https://github.com/docker/compose/issues/1377#issuecomment -124571722. أولاً ، فعلت فقط FOO=ba$e ثم FOO='ba$e' (متجاهلًا أنه تم التقاطها "عارية") ، ثم FOO=ba\$e ، ثم FOO=ba\\$e ، ثم استسلمت وذهبت المستندات ، فقط لتندهش عندما تجد أن " $ هو حرف الهروب لـ $ ". بالنسبة لي ، لم يكن هذا على وجه الخصوص "أقل مفاجأة".

ومع ذلك ، لا أعرف ما هو الحل الجيد.

@ ct-clearhaus Compose ليس البرنامج الوحيد الذي يستخدم $ للهروب من $ . ستجد هذا أيضًا في ملفات makefiles. لذا فإن هذا المصطلح مألوف بالنسبة لبعض الناس.

أنا أحب تطبيق استبدال المتغير الحالي. ومع ذلك ، يمكنني حقًا استخدام القدرة على تعيين افتراضي ، وفقًا لاقتراحaanand الأصلي. أعتقد أن بنية POSIX مثالية:

${ENV-default}

استخدامي المحدد هو أنني أريد أن أكون قادرًا على تحديد منفذ المضيف الذي تعمل عليه الخدمة:

PORT=8123 docker-compose up

بإضافة هذا إلى docker-compose.yml :

web:
  ports:
    - "${PORT-8000}:5000"

هل هذه الميزة لا تزال في الخطة وفي طور الإعداد؟

حاولت حل مشكلتي مع الامتدادات ، لكنها أصبحت شديدة الفوضى. لم أضطر فقط إلى تكرار كل ما لدي من docker-compose.yml فقط لتغيير إعداد واحد ، لا توجد أيضًا طريقة _change_ إعداد منفذ مكشوف ، يمكنك فقط add to قائمة المنافذ المكشوفة ، والتي ليس مثاليا بالنسبة لي.

لماذا لا تفشل Docker-Compose عندما لا يتم تعيين متغيرات البيئة؟ إنه يسجل تحذيرًا ويستمر. لن يكون مجرد العودة والخطأ نهجًا أفضل ...
WARNING: The FOO variable is not set. Defaulting to a blank string.

+1 لبناء جملة POSIX لإعلان القيم الافتراضية

ربما أفتقد شيئًا واضحًا ، لكني أود أن أتمكن من استخدام متغيرات البيئة من ملف env لتعيين قيمة متغير البيئة ، على سبيل المثال:

عامل ميناء compose.env:

DB_PASSWORD=test

عامل ميناء يؤلف.

...
service:
    database:
        env_file:
            - ./docker-compose.env
        environment:
            - MYSQL_PASSWORD=${DB_PASSWORD}
    webserver:
        env_file:
            - ./docker-compose.env
        environment:
            - WORDPRESS_DB_PASSWORD=${DB_PASSWORD}

هل يمكن تحقيقه بطريقة أخرى؟ لا أريد أن يكون لدي ملف قالب yaml يحتاج إلى أن يتم تمريره من خلال envsubst.

لماذا لا تضع هذه القيمة مباشرة في env_file بالطريقة التي تريدها؟

2636 سوف يدعم ملف env للقيم الافتراضية

هذا يعني أن وجود متغير يجب أن يكون بنفس القيمة في مكانين ، يجعل الأمر أسهل إذا كنت تحتاج فقط إلى تغيير واحد. # 2636 تبدو واعدة.

نحن بحاجة ماسة إلى آلية لدعم المتغيرات الافتراضية الآن ، حيث تجبرنا القيود الحالية على استخدام البرامج النصية المجمعة للمساعدة في إنشاء عامل الإرساء. أحتاج إلى أشياء مثل NODE_ENV=${NODE_ENV:-dev} للعمل ، وللتيسير سيكون من الجيد أن يكون لديك SOME_NUMBER=$((96*60)) للعمل. هل كان هذا مقررًا للنسخة القادمة؟

+1 للقيم الافتراضية

+1 للقيم الافتراضية. أصبح هذا أمرًا بالغ الأهمية بالنسبة لنا.

أوافق @ darkn3rd - أحتاج إلى الحصول على معرف المستخدم ومعرف مجموعة المستخدمين

فقط إذا كنت أستطيع أن أفعل:

    user: $((id -u)):$((id -g))

من شأنها أن تحل مشاكلي كلها

mgor يبدو أنه يمكنك تمريره عبر envsubst ؟

env $(cat docker-compose.env | xargs) envsubst < docker-compose.tmpl > docker-compose.yml

يجب أن تفعل ذلك (دون تلويث البيئة المستمرة) ، على ما أعتقد.

OJFordmgor لا توجد نية لسرقة الخيط ولكني قمت ببناء أدوات CLI للحصول على سير عمل أنظف ؛ إنفست و slv .

envset development -- slv docker-compose.tpl > docker-compose.yml

سوف يقوم envset بتحميل المتغيرات من ملف env إلى جلسة shell الحالية ، slv يقوم باستبدال القالب باستخدام المتغيرات البيئية.

أوافق OJFord لكن هذا ليس ما أحتاجه ...
اسمحوا لي أن أدق: نحن فريق مكون من 40 مطورًا يستخدمون مكدسًا مختلفًا. نحن نستخدم git للحصول على التعليمات البرمجية.

إذا طلبت منهم تعديل docker-compose.yml الذي يتم تسليمه من خلال git ، لذلك أنا متأكد من أن شخصًا ما سيقوم بدفع ملف docker-compose.yml المعدل ... صدقني ، سيكون هذا هو الحال.

يمكنني "إنشاء ملف مؤلف أساسي" يتم تجاهله بواسطة git وتمديده بواسطة docker-compose.yml ، ولكن لإنشائه ، سأحتاج إلى تقديم ملف Makefile أو bashscript ... سيأتي اليوم الذي تأتي فيه "قاعدة" سيكون هناك حاجة لتغيير ملف عامل ميناء ، ولن يدرك الفريق أنهم سيحتاجون إلى إعادة تشغيل الجيل.

نفس الشيء بالنسبة لملف "env" ، هذا جميل جدا ، لكنه لا يعمل مع "build" و أنا بحاجة لأن أطلب من فريقي إنشاء هذا الملف.

حقًا ، إذا كان بإمكان docker-compose الحصول على قيم من bash (أو أي حل آخر يقوم بإرجاع شيء آخر مثل ENV var) في ملف yaml فسيحل الكثير من الاحتياجات.

المثال الخاص بي في أمري السابق هو مثال مثالي: أحتاج إلى الحصول على معرف المستخدم و gid وهذه القيم لم يتم تعيينها بواسطة متغيرات ENV. لذلك أحتاج إلى مطالبة فريقي بكتابة معرفاتهم في ملف .env ... أمر بسيط بالنسبة لي ولك ، وليس للجميع.

على وجه الدقة: أحتاج إلى تقديم ملف إنشاء عامل ميناء لا ينبغي للفريق تغييره ، لأنه موجود في مستودع git.

طلب السحب هذا هو مثال بسيط يناسبني. ربما يمكنك مساعدتي لأعمل أفضل.

حاولت باستخدام توجيهات البيئة والمستخدم من ملف docker-compose.yml. يعمل بشكل جيد في الوقت الحالي.

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

default:
  extends:
    file: base.yml
    service: base-${LOG_FORMAT:docker}
  labels:
    - "net.company.npmjs.datacenter=${DATA_CENTER}"
    - "net.company.npmjs.env=${ENV}"
    - "net.company.npmjs.hostname=${HOSTNAME}"
    - "net.company.npmjs.role=${NPMO_ROLE}"
    - "net.company.npmjs.log=${LOG_FORMAT}"

base-syslog:
  log_driver: syslog
  log_opt:
    tag: "{{.ImageName}}/{{.Name}}/{{.ID}}"

base-docker:
  log_driver: json-file
  log_opt:
    max-size: "128m"
    max-file: "4"

متى سيكون هذا متاح؟ أنا على إنشاء 1.7.0 وما زال هذا غير موجود :(

من فضلك من فضلك اعطنا القيم الافتراضية!

marcellodesales : ربما يمكنك الاستفادة من استخدام ملف docker-compose.override.yml بطريقة ما. تحقق من هذه الميزة.

أيضا +1 على env vars. إنها نقطة الألم الرئيسية لدينا مع عامل البناء في الوقت الحاضر.

أود أن أصر على رقم PR # 3367 الخاص بي حتى أتمكن من الحصول على قيم معينة من المضيف. :)

pataquets لا أعتقد أنني أريد إنشاء ملف تجاوز آخر ... يعرض ملف base.yml ، كما هو موضح أعلاه ، جميع العناصر المدعومة من حيث برنامج تشغيل المسجل ، وما إلى ذلك ... أريد فقط التبديل ولها القيم الافتراضية. أعتقد أننا سنحتاج إلى الاحتفاظ بالمزيد من ملفات yml. لكنني سأضع ذلك في الاعتبار فقط في حالة.

+1

+1

+1

+1

أي إشعار حول استخدام متغيرات البيئة في Docker-compose؟

+1

+1

لمعلوماتك: متغيرات البيئة لأعمال تكوين عامل الإرساء اعتبارًا من 1.7.0. يمكنك أيضًا تعيين المتغيرات الافتراضية لـ docker-compose في .env في نفس الدليل كملف الجذر docker-compose.yml . لا ينبغي الخلط بين هذا وبين envfiles محرك الرصيف ، لأن هذا شيء مختلف.

هل هناك طريقة لتعيين اسم الخدمة كمتغير؟

بدلا من كتابة هذا

services:
   site_db:
     image: mysql:5.7

يمكننا الكتابة

services:
   ${CONTAINER_NAME}:
     image: mysql:5.7

هدفي هو الاحتفاظ بنفس docker-compose.yml عبر مواقع متعددة ، وتغيير ملف .env . في الوقت الحالي ، ما زلت بحاجة إلى تعديل اسم الحاوية لأنني أقوم بتشغيل العديد من التطبيقات على نفس المضيف. وأود أن يكون لكل خدمة اسمها الخاص للتوضيح.

LouWii يمكنك استخدامه

services:
    site_db:
      container_name: "${CONTAINER_NAME}"
      image: mysql:5.7

أو (إنشاء تنسيق الملف 2.1 والإصدارات الأحدث)

services:
    site_db:
      container_name: "${CONTAINER_NAME:-defaultname}"
      image: mysql:5.7

لكن لماذا لا تحدد اسم المشروع؟ اسم المشروع هو _intended_ لذلك ، لأنه يسبق / مساحات الأسماء أسماء الحاويات التي تم إنشاؤها لمنع التعارض مع المشاريع الأخرى على نفس المضيف. راجع https://docs.docker.com/compose/reference/envvars/#/composeprojectname

thaJeztah شكرا! ما زلت أتعلم كيفية تأليف Docker و Docker. يبدو أن تعيين اسم المشروع هو خيار أفضل ، فهو منطقي تمامًا في استخدامي.

هل هناك أي طريقة للكتابة داخل الأقواس المقحمة؟ على سبيل المثال ${HOST_PORT + 1} .

يمكنك تمرير الملف عبر Jinja أو شيء من هذا القبيل ...

في الثلاثاء ، 24 يناير 2017 ، 5:36 صباحًا Sam A. Horvath-Hunt [email protected]
كتب:

هل هناك أي طريقة للكتابة داخل الأقواس المقحمة؟ على سبيل المثال $ {HOST_PORT

• 1}.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/1377#issuecomment-274767368 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAGAUN5ZrU39dnVVVVASwIHr5mGqJFxh3ks5rVdRIgaJpZM4EMysO
.

هل يمكنني الهروب من $ ؟

environment:
   PATH: "$PATH:/home/appuser/.bundler/bin"

ينتج عن هذا حاليًا استيفاء متغير PATH الخاص بالمضيف وليس الحاوية

هل تم العثور على ملف docker-compose.yml واحد فقط؟
كيف يمكنني اضافته او تعديله؟
شكرا لك مقدما

logicminds على الرغم من أنني لم أتمكن من العثور عليه موثقًا في أي مكان ، فقد وجدت $$ يقحم إلى $ هارب.

environment:
   PATH: "$$PATH:/home/appuser/.bundler/bin"

elquimista لديه حل وجدته مفيدًا https://github.com/mhart/alpine-node/issues/48#issuecomment -430902787