اسم المشروع ليس مهما. تعجبني فكرة اسم مشروع عشوائي. والأفضل من ذلك - هل يمكننا إنشاء تجزئة للمسار إلى fig.yml واستخدامه؟

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

القدرة على تجاوز اسم المشروع من متغيرات البيئة تجعل من السهل الحفاظ على هذه المتغيرات الفريدة والمتوقعة. أعتقد أنه بغض النظر عما يحدث ، نحتاج إلى دعم التجاوز من متغيرات البيئة.

تعجبني فكرة جعل اسم المشروع قابلاً للتكوين من ملف. أعتقد أن مناقشة مماثلة حدثت في (# 45). يبدو أن وجود اسم المشروع في .fig/project-name سيؤدي إلى الكثير من الملفات الصغيرة حقًا. أعتقد أنه سيكون من الأسهل وضعه في fig.yml نفسه (كما هو مقترح في # 45 ، وأحد مقترحات عامل الرصيف).

ما هي مزايا وضعه في دليل وملف منفصل؟

سبب وضعه في ملف منفصل له عدة أسباب ، سأحاول شرح تفكيري وراء ذلك ؛

• للاحتفاظ بالاسم الذي تم استخدامه لبدء_ المشروع (على سبيل المثال ، --project-name=foobar ) ، والذي يمكن أن يكون مختلفًا عن اسم المشروع التلقائي.
• وجود نسخ أو نسخ متعددة من مشروع يعمل على نفس الخادم ، دون تعارضها مع بعضها البعض
• أو باختصار ، يحمل .fig/project-name اسم _هذا المثال_ من المشروع.

ربما يجب تسمية الملف باسم instance-name أو ما شابه.

تعجبني فكرة جعل اسم المشروع قابلاً للتكوين من ملف

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

سيؤدي إلى الكثير من الملفات الصغيرة جدًا.

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

أعتقد أنه سيكون من الأسهل وضعها في التين

أعتقد أن كلا الخيارين يمكن أن يكونا مكملين ؛ استخدم الاسم من fig.yml كاسم افتراضي إذا لم يتم تجاوز الاسم بعلامة أو متغير env. ضع الاسم المستخدم فعليًا في _بدء_ المشروع داخل .fig/project-name

القدرة على تجاوز اسم المشروع من متغيرات البيئة تجعل من السهل الحفاظ على هذه المتغيرات الفريدة والمتوقعة. أعتقد أنه بغض النظر عما يحدث ، نحتاج إلى دعم التجاوز من متغيرات البيئة.

فضولي؛ كيف تتعاملون مع إدارة مشاريع متعددة؟ أي cd project-a && fig ps ثم cd project-b fig <something> ؟

شكرا لملاحظاتك!

فضولي؛ كيف تتعاملون مع إدارة مشاريع متعددة؟

عادةً ما أقوم بتشغيل fig من python-tox ، وهو ما يتيح لي تعيين البيئة ، لذا فأنا لا أضعها مطلقًا في قشرتي. أنا أميل أيضًا إلى استخدام tmux ، لذلك لدي قذائف مختلفة لكل مشروع.

أعتقد أن كلا الخيارين يمكن أن يكونا مكملين

رائع ، أوافق.

لا أعرف ما إذا كنت قد بعت على .fig/instance-name مقابل قول .fig-instance.yml والذي يمكن أن يحتوي على أي حالات تجاوز محددة ، لكنني أعتقد أن هذه نقطة ثانوية.

التفكير في اسم المشروع ؛ إذا فهمت موقفك بشكل صحيح ، فمن المهم أن تكون قادرًا على التحكم في _ الصور_ التي يتم إنتاجها ، على سبيل المثال myapp:build12345 ، أو أيضًا أسماء _containers_؟ فقط للتعرف على وضعك.

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

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

هل لديك أي أفكار حول إنشاء ملف "اسم المشروع" "بشكل ضمني" أو "صراحة" عبر fig init ؟ ربما إذا كان لدي بعض الوقت خلال الإجازات القادمة ، يمكنني تجربة بعض الشيء (لم أقم بتشفير أي شيء في Python ، لذلك سيكون _حقيقًا_ تجريبيًا :))

من المهم أن تكون قادرًا على التحكم في الصور التي يتم إنتاجها ، على سبيل المثال myapp: build12345 ، أو أيضًا أسماء الحاويات؟

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

لكنني أعتقد أن الأسماء المتوقعة للحاويات لا تزال مهمة. يمكنني التفكير في مهمتين حيث من المهم للأنظمة الخارجية (وليس الشكل فقط) أن تكون قادرة على تحديد الحاوية بالاسم:

• تنظيف البرامج النصية لإزالة الحاويات القديمة ، والقدرة على تحديد المشروع الذي أنشأ الحاوية
• تصحيح / فحص الحاويات

كلاهما سهل جدًا الآن لأنني أعرف بالفعل اسم الحاوية. إذا كان عليّ البحث عن اسم ، فسيكون الأمر أكثر تعقيدًا إلى حد ما.

لقد فكرت في أن التين يمكنه تتبع الحاويات عن طريق المعرف في مخزن محلي داخل دليل .fig

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

هل لديك أي أفكار حول إنشاء ملف "اسم المشروع" "بشكل ضمني" أو "بشكل صريح" عبر fig init؟

أعتقد ضمنيًا أنه سيكون أكثر توافقًا مع الإصدارات السابقة. أود تجنب fig init ما لم يكن ذلك ضروريًا للغاية. بدلاً من استخدام القائم على أساس ، كان بإمكاني رؤية إنشاء اسم مشروع ضمنيًا <basename>-<4 digit random id>

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

@ frank-dspeed شكرًا لإضافة واقعة الاستخدام الخاصة بك. إذا فهمت بشكل صحيح ، فإنك _ تبدأ_ حاوياتك مع التين ، ولكن _ "تديرها" _ مباشرة عبر Docker بعد ذلك ، مستفيدًا من اصطلاح التسمية الذي يستخدمه Fig.

ربما يثير هذا اهتمامك أيضًا: https://github.com/docker/docker/pull/9882 - سيوفر الحصول على البيانات الوصفية المزيد من الطرق لتحديد الحاويات ، وليس فقط اسمها.

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

أعتقد أن إدارة عدم غموض اسم المشروع لا ينبغي أن تكون مسؤولية التين.

عندما فهمت اقتراحك بشكل صحيح ، فإن إنشاء اسم عشوائي سيجعل الخيار FIG_PROJECT_VARIABLE --project-name والخيار

أعتقد أن إدارة عدم غموض اسم المشروع لا ينبغي أن تكون مسؤولية التين.

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

عندما فهمت اقتراحك بشكل صحيح ، فإن إنشاء اسم عشوائي سيجعل FIG_PROJECT_VARIABLE وخيار اسم المشروع - المشروع عديم الفائدة. وهو مفيد لخدمات "القوالب".

بعد المناقشة أعلاه ، أعتقد أن شيئًا كهذا سينجح

• إذا تم توفير --project-name ، فاستخدم ذلك (واكتب / حدّث .project-name ؟ لست متأكدًا)
• لم يتم توفير --project-name ، لكن FIG_PROJECT_NAME هو ، استخدم FIG_PROJECT_NAME (واكتب / حدّث إلى .project-name ؟)
• لا شيء مما سبق ، ولكن لم يتم تعيين .project-name ، استخدم .project-name
• لا شيء مما سبق؛ أنشئ اسمًا _random_ واكتبه على .project-name

من منظور شخص ما يستخدم التين في البرامج النصية التي تعتني بالاسم وتمريره إلى الشكل ، فإن تخزين اسم في موقع المشروع (وهو في حالتي بدلاً من القالب) لا معنى له.

ومع ذلك ، شعرت أنه من البديهي أن يتم استخدام اسم الدليل في اسم الحاويات الناتجة عندما قمت بتشغيل fig up .
ولنفترض أنك تنظر إلى docker ps -a ، فلن يكون ذلك مفيدًا جدًا إذا كان مليئًا بأسماء عشوائية.

هل خيار --random-name يساعد في وضعك؟
إلى جانب ذلك ، أعتقد أن القدرة على الاعتماد المسبق على بعض [a-zA-Z0-9_].* لتعكس بعض مسافات الأسماء ستكون مفيدة لعمليات النشر الأوسع.

ماذا عن استخدام fig.yml لتخزين مثل هذه المعلومات؟

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

وللحفاظ على BC ، في تكوين / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

jderusse أنا كثيرًا لشيء مثل ما اقترحته. ربما ترغب في إضافة اقتراحك إلى رقم 45 حيث ربما يكون هذا هو المكان الأفضل لمناقشته؟

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

في الأصل كنت أرغب في كتابة الاسم في docker-compose.yml ، لكن بعد التفكير في الأمر أكثر ، أحببت حقًا فكرة إنشاء ملف منفصل.

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

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

أوافق على ما قاله dnephin. ماذا عن ملف .docker-compose ؟ يمكننا سرد الخيارات الافتراضية لجميع وسيطات سطر الأوامر هناك.

تضمين التغريدة

mikehaertl لقد استخدمت مجلد .docker-compose في المثال الخاص بي ، لكن الملف يمكن أن يعمل أيضًا ، اعتمادًا على كمية المعلومات التي نريد تخزينها

thaJeztah أوه ، صحيح ، آسف. فاتني ذلك.

mikehaertl أعاد تسميتها للتو من .fig إلى .docker-compose ؛-)

حق :)

في الواقع أنا أفضل ملف بسيط. ماذا عن أسلوب ini؟ الخيارات العامة في الأعلى ، تحكم بخيارات محددة في قسم:

project-name = blabla

[build]
no-cache

بعض الأفكار عن المعلومات شبه ذات الصلة التي قد نرغب في تخزينها إما في نفس الملف أو في نفس الدليل:

• اسم الشبكة (قد يرغب المستخدمون في اسم شبكة مختلف عن اسم المشروع. لقد تلقينا بالفعل طلبًا واحدًا لذلك.)
• نسخة API العميل
• مضيف عامل ميناء
• قيمة المقياس الافتراضية

الآن بعد أن قمنا بدعم ملفات إنشاء متعددة ، قد يكون من المثير للاهتمام أيضًا تضمين المسارات إلى ملفات الإنشاء لاستخدامها كتكوين.

نسخة API العميل

ربما docker_host ؟

هذا يبدو جيدًا أيضًا (مضاف)

لقد واجهت هذه المشكلة للتو.

أنا في مرحلة حيث تمت تسوية البنية الأساسية لتكوين عامل الإرساء ، والآن أقوم بنسخه إلى خدمات أخرى. نظرًا لأن جميع المشاريع لها نفس البنية ، فإنها تستخدم جميعها نفس الدليل الفرعي (وبالتالي ، اسم المشروع الافتراضي). مما يعني أنه لا يمكنني تخزين خدمتين بأمان على نفس المضيف.

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

نفس الشيء هنا ، لقد قمت بحل مشكلة مماثلة مع أهداف Makefile . ولكن مع ذلك ، عندما تريد تنفيذ أوامر docker-compose المخصصة ، فأنت بحاجة إلى استخدام -p customname .

في الوقت الحالي ، أحاول معرفة كيفية منع إعدادات إنشاء عامل الإرساء في /home/alice/myproject و /home/bob/myproject من التنقل على حاويات بعضهم البعض. هل هناك طريقة لاشتقاق أسماء الحاويات من مسار الملف الكامل بدلاً من اسم الدليل الأخير فقط؟

@ chris-martin هذا مجرد حل بديل ...

alias docker-compose="docker-compose -p ${PWD}"

شرائط عامل ميناء إنشاء / من أسماء المشاريع ، رغم ذلك؟

هل تم توثيق الحروف المسموح بها في أسماء المشاريع؟

لقد انتهيت من تغيير هيكل الدليل الخاص بي ووضع docker-compose.yml في جذر المشروع ، وهو حل مناسب بدرجة كافية

يمنحك بعض الحماية ، إذا كنت تميل إلى وضع جميع مستودعات git الخاصة بك في نفس الدليل (على سبيل المثال ، $ HOME ، أو $ HOME / projects) ، ولكنه يصبح مزعجًا إذا كنت تستخدم بنية أخرى (على سبيل المثال ، دليل واحد لكل مؤسسة ، مثل I غالبًا) ، أو إذا كان جهازك يستخدم boot2docker ، والذي يميل إلى تسريب المعلومات عبر المستخدمين في نفس المربع إلا إذا كنت حريصًا على التأكد من أن جهاز الإرساء يمنحك أجهزة افتراضية مميزة.

أعتقد أن # 2294 أو كونك أكثر نظافة مع آلة الرصيف من شأنه أيضًا أن يحل مشاكلي.

أوصي أيضًا بوضعه في جذر المشروع والحصول على اسم مجلد مختلف.

في حالتي ، أرغب في تعيين الاسم الأولي للمشروع لأن لديّ جهازًا مشتركًا على AWS وعلى الرغم من أن لدي docker-compose.yml في الجذر ، يمكن للمستخدم استنساخ المستودع في دليل باسم مختلف. إذا حدث ذلك حاليًا ، فسيواجهون مشكلات في بدء / إيقاف الحاويات.

من خلال بناء الجملة الجديد v2 يمكن تنفيذ هذا كما هو مذكور في https://github.com/docker/compose/issues/745#issuecomment -74028861

إنها في الواقع مجرد container_name_prefix ، أليس كذلك؟

ههههههههههه

إنها في الحقيقة مجرد container_name_prefix ، أليس كذلك؟

يتم استخدامه أيضًا كـ volume_name_prefix ، image_name_prefix و network_name_prefix ، لذا أعتقد أن project_name مصطلح أكثر عمومية.

.docker-compose مألوفًا بالنسبة إلى docker-compose.override.yml بطرق كثيرة. بالإضافة إلى ذلك ، لماذا نقدم تنسيق تكوين آخر (على سبيل المثال ini) عندما حصلنا بالفعل على YAML؟
لذلك فأنا أؤيد اقتراح jderusse في # 745 (تعليق) لإضافة مفتاح project_name إلى docker-compose.yml ، لتمكين حالة استخدامJosephEarl.

يمكن بالفعل تنفيذ التخصيص الخاص بالمستخدم باستخدام docker-compose.override.yml واستبعاده عبر .gitignore .
إذا كنت ترغب في الحصول على ملف تجاوز ثالث خاص بالمستخدم ، أقترح .docker-compose.local-override.yml .

فيما يتعلق بهيكل YAML ، أقترح إنشاء مفتاح مستوى أعلى جديد يسمى project ، والذي يحتوي على project_name ، وقد يحتوي على متغيرات أخرى في المستقبل. هذا يتجنب تلويث مساحة الاسم ذات المستوى الأعلى. لتوضيح:

project:
  project_name: "your-project"
  network_prefix: "abc"

لاحظ أنه بدلاً من استخدام network_prefix ، قد يكون من المفهوم تخصيص أسماء الشبكات نفسها مباشرةً. كما أفهمها ، هناك حالتان:

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

الاقتراح المقترح أعلاه يبدو جيدًا بالنسبة لي ، وأنا أوافق على أننا لا نريد تقديم أي ملفات تهيئة إضافية

+1 على مفهوم هذه القضية
ولكن أيضًا قم بإجراء +1 على استخدام مفتاح في docker-compose.yml بدلاً من إضافة ملف آخر إلى مستودعاتنا.

لتلخيص التعليقات السابقة: اقتراح واحد لتسلسل البحث عن اسم المشروع سيكون على النحو التالي ؛ العناصر السابقة لها الأسبقية على العناصر اللاحقة:

1. استخدم --project-name إذا تم تحديد ذلك
2. استخدم COMPOSE_PROJECT_NAME إذا تم تحديد ذلك.
3. استخدم مفتاح project_name من docker-compose.yml (أو أينما تم تخزين هذا الإعداد).
4. استخدم basename من دليل المشروع

لست متأكدًا من أولوية 2 مقابل 3:

• للتوافق مع --project-name ، يجب بالتأكيد تجاوز project_name: COMPOSE_PROJECT_NAME project_name: .
• لكن: جعل الأسبقية COMPOSE_PROJECT_NAME project_name: يجعل من الممكن استخدام اسم المشروع الخطأ عن طريق الخطأ بسبب متغير البيئة يتم تعيينه ؛ قد يكون من الصعب تصحيحه. ربما يمكن أن تكون رسالة تحذير مشكلة في هذه الحالة؟

ماذا عن إدخال خاصية جديدة container_name_pattern بالقيمة الافتراضية %(project_name)s_%(service_name)s_%(instance_number)s للحفاظ على BC
تتيح لنا هذه المعلمة مجانًا تغييرها إلى hardcodedproject_%(service_name)s_%(instance_number)s وإصلاح هذه المشكلة نهائيًا

لقد وصلت للتو إلى هذه المشكلة بعد البحث عن هذه الوظيفة لمدة 10 دقائق.

أول شيء فعلته هو البحث عن المفتاح الصحيح في مستند مرجع إنشاء ملف ، لذا +1 لمفتاح project_name في docker-compose.yml

: +1: لاستراتيجية @ cr7pt0gr4ph7

+1 لاستراتيجية @ cr7pt0gr4ph7

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

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

https://github.com/docker/compose/issues/745#issuecomment -182296139 يبدو صحيحًا. سيكون لمتغير البيئة الأسبقية على القيمة الموجودة في ملف الإنشاء ، والذي يعمل كإعداد افتراضي (بافتراض أن اسم المشروع ينتمي إلى ملف الإنشاء).

شيء يجب مراعاته ، ماذا يحدث عند استخدام ملفات تكوين متعددة يحدد كل منها اسم مشروع؟

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

ربما يكون التحذير معقولًا ، أو ربما نتجاهله تمامًا (حيث يمكن تجاهل القيمة عن طريق تعيين خيار أو متغير بيئة أيضًا).

شيء يجب مراعاته ، ماذا يحدث عند استخدام ملفات تكوين متعددة يحدد كل منها اسم مشروع؟

إذا فعلت شيئًا مثل docker-compose -f compose1.yml -f compose2.yml up وقام كلا الملفين بتعريف اسم المشروع ، فيجب أن يكون الاسم المستخدم من compose2.yml .

أعتقد أن الجميع في حل أحبه بالفعل: -) أي project_name في docker-compose.yaml. أريد فقط أن أذكر حالة استخدام أخرى لوجود اسم المشروع في ملف docker-compose.yaml:

في صفحات خطأ الخادم الداخلي HTTP 500 في مشروعي ، أخبر المطور بكيفية إصلاح المشكلة أو استكشافها وإصلاحها ، على سبيل المثال أخبره أنه يمكنه zcat database-dump.tgz | docker exec -i projectname_db_1 psql إذا لاحظ الخادم عدم وجود قاعدة بيانات PostgreSQL و تم إنشاء المستخدم - ثم أرغب في اختيار projectname بنفسي ، وإلا لا يمكن نسخ رسائل المساعدة ولصقها في وحدة التحكم.

توافق على أنه يجب أن يكون هناك تحذير عندما يتجاوز COMPOSE_PROJECT_NAME اسم المشروع في compose.yml - يكون هذا السلوك منطقيًا استنادًا إلى أوامر Docker الحالية ، ولكنه ليس منطقيًا أو واضحًا للوافد الجديد.

+1 لاستراتيجية @ cr7pt0gr4ph7

حاولت البحث عن شيء ما قبل فتح المشكلة بنفسي حيث لم أجد شيئًا.
+1 project_name في ملف docker.compose.yml. مع الإصدار 2 ، أعتقد أن هذا منطقي أكثر فأكثر.

توافق على أنه يجب أن يكون هناك تحذير عندما يتجاوز COMPOSE_PROJECT_NAME اسم المشروع في compose.yml - يكون هذا السلوك منطقيًا استنادًا إلى أوامر Docker الحالية ، ولكنه ليس منطقيًا أو واضحًا للوافد الجديد.

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

هل سيكون من المقبول إنشاء علاقات عامة تستخدم فقط project_name من docker-compose.yml لبدء هذا؟ أم أننا نريد الأشياء الإضافية مثل استخدام قيمة project_name من آخر ملف yml المشار إليه على الفور؟

وماذا عن هذا؟

version: "2"
project:
    default_name: "app"

سوف أقوم بتغيير التنفيذ الخاص بي (https://github.com/docker/compose/pull/3118) لهذا التنسيق. لكنني لست متأكدًا من وجود أي حاجة إلى قسم project ....

+1 كن حريصًا على رؤية هذه الميزة

timgriffiths ، يبدو أن هذا ممكن في أحدث RC عن طريق إضافة ملف بيئة إلى مشروعك:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

deizel لذلك نظرت إلى ملف البيئة ، لكنني ما زلت أعتقد أن هناك حالة استخدام جيدة

في حالتنا ، لدينا ملفات Prod و Staging و UAT و Dev لتكوين ملفات فقط حتى نتمكن من بدء إصدار مختلف من حزمة التطبيقات الخاصة بنا ، وفي بعض الأحيان نريد الوقوف على بيئة التدريج و UAT على نفس السرب ، لذلك يمكنني استخدام البيئة المتغيرات أو ما لا ولكن هذا يعتمد على أن يتذكر المستخدم جميعًا لتعيين هذا ، حيث أنه كما لو كان في ملف الإنشاء ، سيتم فحص كل شيء في الريبو ويمكننا الاحتفاظ بكل شيء مضمّنًا وبسيطًا للشرح عبر جميع المستخدمين.

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

edevenport في حالتك ، يمكنك استخدام الخيار الخارجي لوحدات التخزين المسماة:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

شكرًا لك @ fesor - كان يجب أن

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

في هذه الحالة ، يصبح media projectname_media على المضيف ويفشل في التحميل ما لم يتم إنشاء حجم glusterfs مسبقًا باسم المشروع. لقد فكرت في تركيب مجلدات glusterfs على المضيف يدويًا واستخدام external في ملف docker-compose ، لكنني أفضل ألا أضطر إلى القيام بذلك يدويًا عبر جميع العقد مسبقًا.

edevenport أفهم ذلك. لكن يمكنك فقط إضافة هذا الحجم يدويًا باستخدام docker volume create واستخدامه:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

لذلك ليست هناك حاجة لتغيير المشروع ، والتخلص من أي بادئات.

تعتبر حالة بديلة . أستخدم غلافًا بسيطًا حول docker-compose فقط لعدم تذكر أسماء المشاريع.

fesor لذلك عملنا على حل المشكلة من خلال لصق ملفات الإنشاء في أسماء المجلدات الوصفية ، وهذا

timgriffiths لقد قمت بعمل

@ إذا كانت العلاقات العامة ستكون مثالية ، فهل من الممكن دمجها؟

الآن يوفر Compose ملف البيئة ، لذلك يمكن أن يستمر اسم المشروع هناك.

mkuzmin إنه لأمر محزن أن هناك COMPOSE_FILE لكن لا يوجد COMPOSE_OVERRIDE_FILE .

fesor AFAIK يمكنك تحديد ملفات متعددة

@ schmunk42 يمكنني تحديد اسم المشروع أيضًا. لكن هذا لا يحل المشكلة. أريد أن يكون لدي برنامج نصي شيء مثل هذا:

docker-compose up -d

بدلا من

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME في المثال أعلاه بواسطة CI. وميزة مثل .env file رائعة ولكنها ... عديمة الفائدة في حالة استمرار اسم المشروع.

أستخدم .env لمتغيرات DRY env (وللتركيب <1.7 لدي غلاف بسيط) ، لكنه لا يحل أي مشاكل أخرى. أشار timgriffiths بالفعل إلى حالة النشر على كتلة سرب.

COMPOSE_FILE=one.yml:two.yml هو كيفية تعيين ملفات متعددة. لذا قم فقط بتضمين ملف التجاوز في $COMPOSE_FILE

dnephin غاب عن هذه الميزة ، رائع.

حسنًا ... حول نشر السرب ، لقد قمت بالفعل بمعالجة ذلك من خلال COMPOSE_PROJECT_NAME في متغيرات ENV الخاصة بي في وظيفة jenkin ، لذا مشاكل فقط مع النشر اليدوي. ولا يسمح تطبيقي بإلغاء اسم المشروع الافتراضي ، لذا ...

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

على الرغم من أن الحل باستخدام .env لطيف ، إلا أنه لا يمكن استخدامه دائمًا (قد يكون الملف .env مستخدمًا بالفعل بواسطة تطبيقك). ولا يزال أيضًا حلًا بديلًا.

وقد رأيت أيضًا مشكلات جديدة أخرى قد تكون مرتبطة باسم المشروع تتسلل إلى أحدث الإصدارات (# 3966).

إذن ما هي المشكلة حقا؟

هل من الصعب حقًا إضافة توجيه تكوين جديد بسيط لملفات docker-compose.yml ؟

لا! القضية لم تكن أبدا صعوبة في التنفيذ.

على الرغم من أن الحل باستخدام .env لطيف ، إلا أنه لا يمكن استخدامه دائمًا (قد يكون الملف .env مستخدمًا بالفعل بواسطة تطبيقك). ولا يزال أيضًا حلًا بديلًا.

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

إذن ما هي المشكلة حقا؟

إن إضافة اسم المشروع إلى ملف docker-compose.yml يجعله أقل قابلية للنقل ، وهذا ليس شيئًا نريد تشجيعه. الآن بعد أن أصبحت هناك طريقة (مع .env ) لتحديد اسم المشروع باستمرار دون التضحية بإمكانية النقل لـ docker-compose.yml ، فإن حالة إضافته كخيار تكوين تكون أضعف. هذا هو السبب الرئيسي لعدم تحرك هذه المشكلة.

إضافة اسم المشروع إلى ملف docker-compose.yml يجعله أقل قابلية للنقل ،

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

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

بعبارة أخرى: ما الذي يجعل اسم المشروع مميزًا جدًا؟ هناك بالفعل العديد من الخيارات الأخرى في docker-compose.yml غير محمولة بالفعل. لماذا لا تمنح المطور خيار اختيار ما هو الأفضل لحالة استخدامه؟

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

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

إن إضافة اسم المشروع إلى ملف docker-compose.yml يجعله أقل قابلية للحمل ، وهذا ليس شيئًا نريد تشجيعه. الآن بعد أن أصبحت هناك طريقة (باستخدام .env) لتحديد اسم المشروع باستمرار دون التضحية بإمكانية نقل docker-compose.yml ، فإن حالة إضافته كخيار تكوين تكون أضعف. هذا هو السبب الرئيسي لعدم تحرك هذه المشكلة.

كيف تؤدي إضافة اسم المشروع إلى docker-compose.yml جعله أقل قابلية للنقل؟

IMHO هو في الواقع عكس ذلك ، كما هو موضح في # 3966 الذي أنشأهmikehaertl. توضح هذه المشكلة بوضوح أن عدم تخزين اسم المشروع في docker-compose.yml يجعل الأشياء أقل قابلية للنقل (كما في: وجود احتمال أكبر للتعارض مع مشاريع الإنشاء الأخرى التي بدأت من نفس الجهاز) نظرًا لأن Compose يعتمد على اتفاقية حول اسم مجلد الحاوية الذي لا يعرفه الكثير من الأشخاص ، على الأقل في البداية.

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

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

استنساخ الريبو
عامل الميناء يؤلف

الحل الآن هو إنشاء الملف الذي اقترحه @ schmunk42 .

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

أود أن أرى دعمًا لهذا في ملف docker-compose.yml . إذا احتاج المرء إلى تعيينه عبر متغير البيئة ، فيمكن تعريفه داخل ملف .env (إذا لم يتم تعيينه مباشرة على المضيف) واستخدامه عبر الاستبدال المتغير في ملف docker-compose.yml .

إذا تم السماح بالحاويات المسماة ، فلماذا لا يُسمح بالمشاريع المحددة؟

حالة الاستخدام التي يكون فيها تعريف اسم المشروع في ملف .yml مفيدًا هي التالية:
لدينا نفس ملف docker-compose لخوادم الويب المختلفة (بيانات اعتماد قاعدة بيانات مختلفة ، أحجام بيانات مختلفة ، بعض الاختلافات الصغيرة مثل الشعار ، إلخ). هناك 3 خدمات لكل تطبيق قيد التشغيل ، ويتم تهيئتها في ملف إنشاء. عند تشغيل عدة خوادم بجانب بعضها البعض ، سيكون من الجيد معرفة الخدمة التي تنتمي إلى أي مشروع.

يكون استبدال المتغير في اسم الحاوية مفيدًا ، مع $ COMPOSE_PROJECT_NAME كبادئة. حسنًا ، أنا أفهم حل ملف .env ، ولكن هذا لا يجعله أكثر "ملائمًا للمطور" في بيئة نشر (CI).

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

ببساطة ، هناك مجال كبير للخطأ في عمليات النشر الخطيرة. ما عليك سوى أن تنسى تحديد اسم المشروع ، سواء كان in -p أو .env أو أي مكان آخر: ستصبح غير متصل لبعض الوقت حتى تلاحظ ما حدث. والأسوأ من ذلك: أن خدمة التصادم تصبح غير متصلة بالإنترنت ، وليست الخدمة التي تعمل عليها. سيكون لديك يوم سعيد :(

dnephin ما الذي

ربما أنا الوحيد هنا الذي لديه بعض المخاوف من هذا ، لكن على أي حال.
في إعدادنا ، نقوم بتعديل ملفات .env و app.env لتبديل البيئات ، ولكن هذا يعتمد على وجود ملفات متعددة ودمج ملفات yml .

إذا تم تنفيذ هذا ، يرجى التفكير في BC.

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

@ schmunk42 نحن لا نقول أنه يجب إزالة ميزة .env . إذا كنت تفضل أن يكون اسم مشروعك في .env فلا تقم ببساطة بتكوينه في docker-compose.yml

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

Srsly ، الرجاء إضافة المشاريع المسماة. حالة الاستخدام:
المشروع الأول:
docker-compose up --build --remove-orphans

• nginx
• محتوى ثابت
  المشروع الثاني:
  docker-compose up --build --remove-orphans
• nginx
• محتوى ثابت

عندما يبدأ المشروع الثاني فإنه يقتل حاويات المشروع بمخرج 137 (كود 128 + المستوى 9).

الآن عليّ تشغيل docker system prune وإعادة بناء الشبكات كل يوم لأمنع نفسي من وجود عشرات الحاويات الميتة.

export COMPOSE_PROJECT_NAME=somethingnew

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

كانت الحجة الوحيدة حتى الآن هي الاحتفاظ بـ docker-compose.yml محمول. هذا لا معنى له ، لأن

• اسم المشروع في ملف المؤلف لا يجعله تلقائيًا غير قابل للنقل بعد الآن
• ليس كل شخص لديه هذا المطلب
  
  
  
  • لدينا بالفعل خيارات أخرى يمكن أن تحد من قابلية النقل بنفس الطريقة: networks ، port ، ...
  
  

كل هذا يتوقف إلى حد كبير على حالة الاستخدام المحددة. ولكن لمجرد أن البعض لا يريدون هذا الخيار لا ينبغي أن يعني أن على الجميع اتباع آرائهم!

mikehaertl لديك بالفعل أسماء مشاريع ثابتة. فقط ضع ملف .env وقم بتعيين متغير COMPOSE_PROJECT_NAME هناك. لا أرى أي فائدة في اسم المشروع في ملف الإنشاء بعد الآن.

fesor لا .env تحت التحكم في الإصدار لأنها تحتوي على إعدادات خاصة بالبيئة / الآلة - ولهذا السبب أيضًا أرغب في رؤية أسماء المشاريع قابلة للتهيئة في الملف docker-compose.yml .

@ fesor : أعتقد أن hasmo هو الصحيح في هذا. يجب أن يحتوي اسم المشروع على خيار التحديد في ملف compose.yml لأنه إذا كان مناسبًا لجميع المطورين الذين يستخدمون المشروع ، فيجب أن يكون في التحكم في الإصدار.

fesor أنا آسف ، لكن لا أعتقد أن التفضيل الشخصي هو حجة حقيقية. السؤال الحقيقي ليس ، لماذا لا نريد استخدام .env أو متغير البيئة. إنه العكس: لماذا لم يتم وضعه في ملف التكوين حيث ينتمي؟

يمكن تحديد جميع الخيارات التي يمكنك تمريرها إلى docker في سطر الأوامر تقريبًا في هذا الملف. تم استبعاد اسم المشروع فقط لأسباب غامضة. هل هذا شكل من أشكال الفصل العنصري بين الحجج؟ : PI المطالبة بحقوق متساوية لهم جميعا! دع المطور يقرر ولا تضع قيودًا مصطنعة عليه.

ومرة أخرى: لا أحد يأخذ منك الخيار القديم - نحن نريد هذا الخيار الإضافي في النهاية فقط. هذا عادل فقط.

dnephin : يبدو كما لو كنت أنت تنقيح cr7pt0gr4ph7 لهذه المشكلة .

هل ستكون على استعداد لقبول طلب سحب ينفذه ، أم أنك تنوي أن يكتبه أحد المشرفين؟

هههههههههههه

dnephinfesor وجود اسم المشروع في compose.yml * يسهل مخطط التكوين موحد

ليس من الواضح بالنسبة لي سبب أهمية اسم المشروع. يجب ألا يعتمد أي جزء من ملف التكوين على أي اسم مشروع محدد.

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

عندما يكون الإعداد الافتراضي غير صحيح ، فهناك طريقة للمطور لتجاوزه ( -p ، أو COMPOSE_PROJECT_NAME ) ، والتي يمكن أن تكون إما أسماء مستعارة أو وضعها في ملف .env .

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

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

_لماذا أستبعد COMPOSE_PROJECT_NAME و -p: _
في رأيي ، لا يتم حفظ COMPOSE_PROJECT_NAME و -p في الإنتاج حيث يجب أن تتذكر تعيينهما. أو قم بإنشاء برنامج نصي لبدء التشغيل وتذكر عدم استخدام عامل إنشاء الإنشاء مباشرة. عندما يعتمد الشخص "أ" على هذه الآلية ولا يعرفها الشخص "ب" ، يكون هذا بمثابة فشل معين.
(لقد قمت بالفعل بالتفصيل أعلاه)

dnephin بالنسبة لي وفريقي ، عادةً ما يتم تخزين منطق التطبيق في مجلد htdocs في مجلد مشروعنا. هذا يسمح لنا بالاحتفاظ بالوثائق / الموارد الأخرى ذات الصلة معًا في دليل واحد. كمطور يعمل مع المطورين عن بعد. من السهل بالنسبة لي أن أجعلهم يتبنون Docker إذا لم أضطر إلى افتراض أي شيء عن هيكل المجلد الخاص بهم. لقد ذكرت هذا في الماضي ، إن .env ليس خيارًا بالنسبة لي لأنه عادةً ليس جزءًا من الريبو الذي نشاركه جميعًا.

ليس من الواضح بالنسبة لي سبب أهمية اسم المشروع. يجب ألا يعتمد أي جزء من ملف التكوين على أي اسم مشروع محدد.

لقد حدث لي أكثر من مرة ، أنني قمت بـ "إنشاء عامل ميناء" على مضيف - وكان لدي حاوية مختلفة تنخفض عن تلك التي أريدها! فقط لأنني لم أتذكر ، كان هناك أيضًا تكوين في ملف .env .

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

ربما يكون هذا صحيحًا بالنسبة لك - فهو ليس لي ولكثيرين آخرين. بنية تطبيقي تشبه myapp/app/docker-compose.yml . لذلك تشترك جميع تطبيقاتي في اسم الدليل app . ولدي أكثر من حاوية واحدة على مضيف.

عندما يكون الإعداد الافتراضي غير صحيح ، فهناك طريقة للمطور لتجاوزه (-p ، أو COMPOSE_PROJECT_NAME) ، والتي يمكن أن تكون إما أسماء مستعارة أو وضعها في ملف env.

بجدية ، بدأت أشعر وكأنني هنا في رواية كافكا. أليس من الواضح أنه يمكنك وضع جميع خيارات سطر الأوامر لـ docker في docker-compose.yml - باستثناء هذا الاستثناء الكبير؟

بدلاً من سؤالنا مرارًا وتكرارًا وتجاهل إجاباتنا ، لماذا لا يبرر أحد المقاومة أخيرًا. ولا: "... لكنني لست بحاجة إليها" ليست حجة صحيحة!

dnephin لدي عدة مشاريع في العناصر المتعلقة بعمال التحميل في مجلد فرعي يسمى docker (يصبح سياق الإنشاء .. ، كل شيء يعمل بشكل جميل).

لتشغيل عدة مشاريع على خادم واحد ، يتعين علي حاليًا إنشاء docker/.env.dist في كل ريبو و cp docker/.env.dist docker/.env بعد git clone . خلاف ذلك ، اسم المشروع هو docker ، وهو ما لا أريده بوضوح. في حالات قليلة ، يحتوي .env على كلمات مرور وما إلى ذلك ، لذا فإن نسخ .env.dist مطلوب على أي حال ، ولكن في معظم الحالات ، يوجد .env ببساطة لأنه لا توجد طريقة لتعريف COMPOSE_PROJECT_NAME docker-compose.yml .

أفهم أنه قد تكون هناك بعض الثغرات في كيفية بدء تشغيل الحاويات وإيقافها إذا تم استخدام نفس COMPOSE_PROJECT_NAME مرتين داخل docker-compose.yml ، لكن هذا يحدث بالفعل إذا نسيت نسخ .env.dist أو عند تعيين نفس الاسم عن طريق الخطأ في ملفين مختلفين .env على نفس الخادم. بالنسبة لي ، سيكون الأمر مثاليًا إذا كان بإمكاني تحديد default_compose_project_name حقًا في docker-compose.yml ثم تجاوز القيمة في .env إذا ، دعنا نقول أنني أريد تشغيل نسخة مرحلية من بعض المشاريع . سيكون هذا 100٪ قبل الميلاد ، لكنه أكثر ملاءمة.

لقد ذكرت هذا في الماضي ، إن .env ليس خيارًا بالنسبة لي لأنه عادةً ليس جزءًا من الريبو الذي نشاركه جميعًا.

ربما ، هذا هو السبب الجذري لكل شيء ، لقد قلت قبل ذلك docker-compose "اختطف" هذا الملف واضطررنا إلى إعادة تسمية الأشياء إلى app.env .

ربما كان docker-compose.env هو الخيار الصحيح.

FWIW: نحن فقط نغير ملفات .env في الإنتاج ، يتم دمج ملفات yml مع docker-compose.override.yml إذا لزم الأمر.

الحل البديل أيضًا هو تحديد ملفات yml الخاصة بك بطريقة لا تبدأ بدون ملف .env ، على سبيل المثال. باستخدام متغير image: $IMAGE .

هذا حل بديل ل 4 docker- إنشاء ملفات في حالة دليل واحدة أعلى @ schmunk42 ؟ هل حقا؟

RobIsHere ولكن عليك استخدام -f أي حال ، أليس كذلك؟

ردًا على dnephin في هذا التعليق :

ليس من الواضح بالنسبة لي سبب أهمية اسم المشروع.

إنه مهم لأنه يؤثر على اسم حاويات Docker التي يديرها docker-compose . إذا نسيت تعيين اسم المشروع ، فلن يعثر docker-compose ps على الحاويات التي أنشأتها من قبل بـ docker-compose --project-name <project_name> up -d <container_name> .

أيضًا ، عند تشغيل الأمر العام docker ps ، سيتم تضمين اسم المشروع في قائمة الحاويات قيد التشغيل ، حتى تعرف من أين أتوا. على سبيل المثال ، إذا كنت تختبر العديد من مشاريع الأكواد في وقت واحد والتي تستخدم جميعها MySQL ، ولكل منها حاوية mysql ، فإن docker ps سيعرض قائمة غامضة من الحاويات. لذا ، فإن اسم المشروع مهم في سياق العديد من مشاريع Docker التي تعمل على نفس الجهاز.

يجب ألا يعتمد أي جزء من ملف التكوين على أي اسم مشروع محدد.

إن الاضطرار إلى تعيين اسم المشروع في مكان مختلف عن _كل متغير آخر مرتبط بمشروع Docker Compose_ لا معنى له.

الميزة الوحيدة المهمة لاسم المشروع هي أنه لا يتعارض مع اسم أي مشروع آخر ، وهو في الواقع حجة ضد وضعه في ملف docker-compose.yml.

للأسباب المذكورة في فقرتي الأولى ، فهذه ليست "الصفة المهمة الوحيدة لاسم المشروع" _. إنه لسهولة الاستخدام والفهم.

غالبًا ما يستخدم المطور في المشروع اسم دليل مختلف لكل مشروع ، لذلك غالبًا ما يكون الافتراضي هو الصحيح لمعظم حالات الاستخدام.

في الحالة غير الافتراضية حيث يضع المطور _ all_ ملفات Docker ذات الصلة في دليل docker ، وهي طريقة معقولة تمامًا لتنظيم مشروع Docker ، فإن السحر الذي يعيّن اسم المشروع سيخلق أسماء متضاربة للمشروع. لذا فإن نفس التعارضات التي ذكرتها تحدث في هذه الحالة بالذات. لا تحتاج إلى حماية المطور من تضارب اسم المشروع عندما يقومون بتعيين اسم المشروع بشكل صريح على أي حال.

عندما يكون الإعداد الافتراضي غير صحيح ، فهناك طريقة للمطور لتجاوزه (-p ، أو COMPOSE_PROJECT_NAME) ، والتي يمكن أن تكون إما أسماء مستعارة أو وضعها في ملف env.

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

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

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

يوافق جميع المشتركين في هذه المشكلة تقريبًا على هذه النقاط.

إضافة القدرة على تعيين اسم المشروع في docker-config.yml لن تتعارض حتى مع أي وظيفة حالية. لا يوجد سبب لعدم تنفيذه.

@ schmunk42 آخر مرة راجعت فيها ، لم يسمح عامل عامل

لقد وجدت أن هذا يمثل عقبة حقيقية عند اعتماد Docker لأول مرة لأن مثل RobIsHere يوضح. جميع أدلة مشروعي موجودة بالتنسيق myapp/htdocs/docker-compose.yml . في الأيام الأولى من استخدام Docker ، قمت بطريق الخطأ بحذف الحاويات الأخرى التي لم أكن أنوي القيام بها. كان من الأفضل أن يقوم عامل الإرساء بتسمية المشروع بشكل عشوائي بدلاً من استخدام اسم المجلد في حالتي.

لدي العديد من المطورين البعيدين الآخرين الذين بدأوا في استخدام Docker. كفريق ، من الأسهل بالنسبة لي دائمًا توجيه هؤلاء المطورين دائمًا / فقط docker-compose up لتشغيل هذه التطبيقات. كلما قل هؤلاء المستخدمون الأوائل الذين يعرفون عن Docker ، كان ذلك أفضل. بمجرد أن يروا القوة الكامنة وراءها ، سوف ينتقلون من تلقاء أنفسهم.

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

الحالات التي يكون فيها الإعداد الافتراضي غير مناسب:

• ملفات تكوين متعددة في نفس الدليل (يتطلب منك بالفعل تحديد -f لتشغيلها)
• باستخدام نفس اسم الدليل لجميع المشاريع (أعتقد أن هذا يتطلب منك أيضًا تحديد -f ، الحل المحتمل هو استخدام اسم دليل فريد).

dnephin أود أن أضيف ، حجر عثرة أقل

dnephin لقد كانت لديك أيضًا هذه المخاوف في هذا التعليق :

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

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

1. docker-compose.yml
2. متغير البيئة COMPOSE_PROJECT_NAME
3. خيار سطر الأوامر --project-name

آخر مرة راجعت فيها ، لم يسمح لنا عامل الميناء باختيار اسم ملف .env الخاص بنا.

fiveanddone AFAIK ، لا يمكنك القيام بذلك ، ولكنه سيؤدي أيضًا إلى نقل المشكلة ، حيث سيتعين عليك بعد ذلك معرفة ملف ENV الذي تحتاجه للمشروع.

في حالتنا مع phd5 ، src/ و .env هو فقط "control-environment-file" ، حاولت شرح ذلك هنا .
لا أحب هذا ولن أغيره بمفردي. أعلم أن هذا قد لا يكون ممكناً للعديد من المشاريع.
لكن الحصول على .env من تطبيقك على نفس مستوى docker-compose.yml الخاص بك يصبح مزعجًا للغاية ، لأنك أ) تحصل على متغيرات في "بيئة التحكم" التي لا تنتمي إليها و ب) يجب عليك إعادة توجيه هذه المتغيرات إلى الحاوية الخاصة بك ، إذا كنت بحاجة إليها هناك و ج) لا يمكنك تجاوز / تغييرها بعد الآن في ملف app.env .

dnephin ماذا عن تقديم docker-compose.env كملف env المفضل واستخدام .env كإجراء احتياطي. فعلت الشيء نفسه مع fig.yml مرة واحدة.

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

أعتقد أن جوهر المشكلة هو:

كان التصميم الأصلي لـ docker-compose up أمرًا واحدًا (قصيرًا) يمكنك تشغيله لتشغيل الخدمات. هذا ما يتوقعه المطورون منه. ومع ذلك ، لا يمكن تحقيق هذا السلوك لبعض المستخدمين (في هذه الحالات ).

هناك العديد من الطرق للتغلب على المشكلة ، ولكن لا يبدو أن أيًا منها يعمل مع الجميع.

أعتقد أن ترتيب الأسبقية (من الأعلى إلى الأدنى) يجب أن يكون شيئًا من هذا القبيل:

1. --project-name (تجاوز دائمًا)
2. متغير البيئة COMPOSE_PROJECT_NAME
3. ملف افتراضي يحدده المستخدم ، منفصل عن أي ملف له إصدار
4. افتراضي محدد من قبل المشروع ، يمكن إيداعه
5. اسم الدليل (الافتراضي عندما لا يتم تحديد أي شيء)

(3) يمكن تحقيقه باستخدام ملف .docker/project-name (كما هو مقترح في OP)
(4) يمكن تحقيقه باستخدام حقل في الملف docker-compose.yml

من المؤسف أن هناك العديد من الطرق المختلفة لتعيين اسم المشروع.

dnephin بخصوص 3 ، السماح للمستخدم بتعيين افتراضي ، هذا هو

حسنًا ... وماذا لو عممنا المشكلة قليلاً وقمنا ببساطة بتقديم قسم default_environment في docker-compose.yml ؟ بهذه الطريقة سنكون قادرين على تعيين COMPOSE_PROJECT_NAME بدون إدخال حقل خاص في yaml ، ولكننا سنكون قادرين أيضًا على تحديد المتغيرات الافتراضية الأخرى ، والتي من المحتمل أن تكون موجودة في مكان آخر في الملف. سيؤدي هذا إلى تقليل عدد الحالات التي يلزم فيها نسخ .env.dist إلى .env وستكون تكلفة نسيان القيام بذلك أقل.

مثال على الاستخدام:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

هذا yaml مشابه جدًا لما لدي في كثير من الأحيان - فهو يصف رسم تخطيطي ، والذي يحتوي دائمًا على خدمة تسمى web ، ولكن يمكن أيضًا نسخه احتياطيًا بواسطة خادم واجهة برمجة تطبيقات صغير وربما حاوية بها قاعدة بيانات. من المفترض أن https://github.com/jwilder/nginx-proxy يجلس في مقدمة كل شيء ويستمع إلى المنفذين الحقيقيين 80 و 443.

في الوقت الحالي ، بغض النظر عما إذا كنت أستخدم جهازًا محليًا أو خادمًا بعيدًا ، أحتاج إلى تذكر الحفاظ على .env وأيضًا للتأكد من تعيين _ all_ متغيرات البيئة هناك. دعنا نقول ، إذا نسيت SUBDOMAIN ، تبدأ الحاوية ، لكن خادم الويب يظل معطلاً.

مع وجود قسم default_environment تحت تصرفي ، كان بإمكاني وضع جميع متغيرات الإنتاج الخاصة بي في ملف واحد ولن أضطر إلى نسخ .env.dist عندما أكون على الخادم. على الجهاز المحلي ، في المثال أعلاه ، قمت فقط بوضع متغير واحد في .env ، والذي سيكون ROOT_HOST=example.com.dev (أو ربما يمكنني حتى export ROOT_HOST=example.com.dev في ملف تعريف bash؟ )

للتلخيص ، لا يمكن للقسم default_environment في docker-compose.yml فقط حل المشكلة التي نناقشها حاليًا ، ولكن يمكنه أيضًا تمكين بعض الحيل اللطيفة الإضافية ، مع كونه 100٪ قبل الميلاد وسهل الفهم!

WDYT؟

هذا يبدو لطيفًا ، قد يكون مفيدًا بالنسبة لي في بعض السيناريوهات.

ومع ذلك ، يجب أن تدرك أنه في ضوء المناقشة (الساخنة) أعلاه ، فإن ملف
يُترجم الحل تقريبًا إلى هذا: "بدلاً من إضافة ملف جديد إلى
yml ، ما رأيك بإضافة قسم جديد؟ " :)

الثلاثاء، 28 فبراير 2017، 00:02 الكسندر Kachkaev [email protected]
كتب:

حسنًا ... وماذا لو عممنا المشكلة قليلاً وقدمناها ببساطة
قسم default_env في docker-compose.yml. بهذه الطريقة نحدد
COMPOSE_PROJECT_NAME بدون إدخال حقل خاص في yaml ، لكن
سيتمكن أيضًا من تحديد المتغيرات الافتراضية الأخرى ، والتي من المحتمل أن تكون كذلك
موجودة في مكان آخر في الملف. سيؤدي ذلك إلى تقليل عدد الحالات
متى يجب نسخ .env.dist إلى .env وتكلفة النسيان
القيام بذلك سيكون أقل.

مثال على الاستخدام:

~ / project / sketches / sketch-42 / docker / docker-compose.yml

الإصدار 2"
default_env:
SUBDOMAIN = رسم -42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = رسم -42
خدمات:
الويب:
بناء:
سياق الكلام: ../
dockerfile: docker / Dockerfile
بيئة:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST} ، www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = وكيل
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST} ، www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
إعادة التشغيل: دائمًا
الشبكات:
- وكيل

الشبكات:
الوكيل:
خارجي:
الاسم: الوكيل

هذا yaml مشابه جدًا لما لدي في كثير من الأحيان - فهو يصف وجهة نظر
sketch ، والذي يحتوي دائمًا على خدمة تسمى الويب ، ولكن يمكن أيضًا نسخها احتياطيًا
بواسطة خادم واجهة برمجة تطبيقات صغير وربما حاوية بها قاعدة بيانات. فمن المفترض
أن https://github.com/jwilder/nginx-proxy يجلس في المقدمة ويستمع
إلى المنافذ الحقيقية 80 و 443.

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

مع وجود قسم default_env تحت تصرفي ، يمكنني الحصول على كل إنتاجي
المتغيرات في مكانها ولن أضطر إلى نسخ .env.dist على الخادم.
على الجهاز المحلي ، كنت سأضع متغيرًا واحدًا في .env ، والذي سيكون
ROOT_HOST = example.com.dev (أو ربما يمكنني تصدير ملفات
ROOT_HOST = example.com.dev في ملف تعريف bash؟)

للتلخيص ، قسم default_env في docker-compose.yml لا يمكنه ذلك فقط
حل المشكلة التي نناقشها الآن ، ولكن يمكن أيضًا تمكين بعض الاستخدام اللطيف
سيناريوهات!

WDYT؟

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

سيؤدي وجود "اسم_المشروع" داخل docker-compose.yml إلى حل مشكلة مع مكدسنا.
لدينا ريبو مترابط مع شجرة موحدة تتعامل مع مشاريع متعددة ، والتي تبدو إلى حد ما مثل هذا:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

من الواضح أنه أكثر تعقيدًا من ذلك في العالم الحقيقي ، لذلك لا يمكننا فقط نقل ملف docker-compose.yml إلى مجلد "projectA / projectB".

لدينا CLI في الجذر يسأل عن المشروعات التي سيتم تشغيلها ، وبما أن اسم المشروع يعتمد بشكل مباشر على المجلد الأصلي لـ docker_compose.yml ، فإننا نواجه تعارضات.

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

قال شخص ما هنا "إنه يعمل في معظم الأحيان لأن معظم المشاريع ، يقع docker-compose.yml داخل المجلد الجذر للمشروع ، والمشاريع لها اسم مختلف ، لتجنب التعارضات" ، لا يمكنني الاتفاق على ذلك هذه. ليس دائمًا داخل المجلد الجذر.

لماذا من الممكن تحديد "اسم الحاوية" في ملف docker-compose.yml (تعطيل التحجيم) لخدمة ، ولكن لا يمكن تحديد "اسم_المشروع" لملف docker-compose.yml نفسه ، بنفس مستوى "الإصدار" / "الخدمات" / "الشبكات" / "المجلدات"؟

يبدو هذا ضروريًا عند استخدام scale حتى تكون أسماء الحاويات واضحة. (على سبيل المثال ، <project_name>_<container_name>_1 ).

سيساعد هذا عند استخدام اسم الحاوية لنظام أسماء النطاقات.

جئت هنا على أمل أن يتم ذلك. غادر بخيبة أمل. 3 سنوات +

نعم ، إنها واحدة من أكثر مشكلات قابلية الاستخدام غباء لـ Docker ولا يتم إصلاحها.

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

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

ما الهدف من إنشاء عامل الإرساء إذا احتجنا إلى إضافة خيارات باستخدام cli؟
لقد تم الكتابة فوق بعض الحاويات بفضل نظام التسمية.

اليوم كنت أقوم بإعداد مشروع docker-compose آخر مع ملف .env لمنح المشروع اسمًا ثابتًا. لذلك اعتقدت أنني أتحقق من هذه المشكلة منذ أن مرت بضع سنوات منذ أن راجعت آخر مرة. لكن لا شيء جديد هنا بقدر ما أستطيع رؤيته؟ أعتقد أنه سيتعين علي الاستمرار في استخدام الحل البديل .env . بالنسبة لي ، يبدو أن تسمية مشروع في ملف yaml هو أبسط شيء يمكنك القيام به ، لكن أعتقد أن هناك شيئًا ما حول هذا الأمر لا أفهمه لأنه لم يتم حله بعد.

الحاجة إلى تحديد اسم المشروع خارجيا (عن طريق سطر الأوامر أو متغير) ولكن عدم القدرة على ضبطه في docker-compose.yml ملف - الملف الذي يحدد كل شيء آخر - هو مجرد الطائش. هناك الكثير من الحالات التي قد تحتاج فيها العملية إلى معالجة مجموعة معينة من الخدمات بناءً على ملف docker-compose.yml تعسفي بغض النظر عن اسم الدليل الأصلي أو بيئة shell أو وجود سطر معين في .env ملف docker-compose.yml حتى يمكن لوظائفي استخراجها واستخدامها.

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

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

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

لا أريد أن تضطر وظائف CI الخاصة بي إلى "اكتشاف" اسم المشروع بشكل مستمر - يجب ذكره بوضوح في docker-compose.yml حتى يمكن لوظائفي استخراجها واستخدامها.

هل لديك مشكلة في تسمية المكدس الخاص بك مثل "build1234" و / أو كيف تريد استخدام اسم المكدس في مكان آخر ، مثل docker exec build1234_myservice script.sh ؟

قد لا يناسب أي حالة استخدام ، ولكن لقولها ...

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

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

لا أريد أن أخبرك أنه يجب عليك تغيير سير العمل ، لأنني أزعجت أيضًا من هذه المشكلة.

فكرت في وضعي أكثر. ليس لدي بالفعل مشكلة في تعيين اسم المشروع خارجيًا ، وفي الواقع أفعل ذلك باستخدام علامة -p <project_name> ، مما يجعل من الممكن عزل المثيلات الفريدة للمكدس في CI وتشغيل حزم متعددة بشكل متزامن إذا ضروري. تحتاج سلسلة CI فقط إلى معرفة اسم المشروع هذا بحيث يمكن إنشاؤه تلقائيًا أو عشوائيًا (لكن معروفًا) ، فلا مشكلة. ليس لدي أيضًا مشكلة في استخدام متغير بيئة لتجاوز الاسم الافتراضي ، ومع ذلك أجد الحيلة .env غير واضحة.

ومع ذلك ، هناك مواقف أخرى يكون من المفيد فيها تحديد _default name_ للمشروع بشكل صريح في مكان ما. فلماذا يتخذ اسم الدليل الأصل كمصدر لهذا الاسم؟ هذه ، بالنسبة لي ، هي نقطة الضعف هنا. يمكن أخذها من أي مكان - يبدو اختيار الدليل الأصلي عشوائيًا وبدون سبب كبير (على سبيل المثال ، في جميع مشروعاتي تقريبًا ، يوجد ملف docker-compose.yml في دليل فرعي يسمى docker ). لذا ، إذا كان الأمر عشوائيًا ، فقم بتخزينه في مكان أكثر وضوحًا ، مثل ملف yml ، بدلاً من إنشاء آثار جانبية خارجية من خلال التأثير على أسماء الدليل الأصلي التي يجب أن تكون في كثير من الحالات مستقلة تمامًا عن محتوى الدليل (استنادًا إلى سنوات خبرة في العمل مع الموارد القابلة لإعادة الاستخدام).

يمكن أخذها من أي مكان - يبدو اختيار الدليل الأصلي عشوائيًا وبدون سبب كبير (على سبيل المثال في جميع مشاريعي تقريبًا ، يوجد ملف docker-compose.yml في دليل فرعي يسمى docker).

إذا كنت بحاجة إلى شيء آخر غير معرف عشوائي ، فلا أرى بديلاً حقيقيًا للدليل الأصلي. على الأقل لديك فرصة لمعرفة من أين "جاء" المكدس الخاص بك.
لكنني أتفق معك أيضًا ، نظرًا لأننا في مشاريعنا لدينا أكوام تجريبية في مجلدات tests والتي - بدون ملف .env - ستصطدم أيضًا بشكل سيء مع بعضها البعض. لهذا السبب اقترحت تفضيل ملف يسمى docker-compose.env والذي سيكون أكثر وضوحًا IMHO.

هل يمكنك يا رفاق إما إغلاق هذا الخطأ والاعتراف بأنك لا تهتم ، أو تنفيذ الشيء البسيط للغاية الذي تريده الغالبية العظمى منا؟ بعد 2.86 سنة. انزل من القدر. امتلك قراراتك أو أصلح أخطائك. ومع ذلك تريد أن تنظر إليه. افعل أكثر من لا شيء.

@ ماتسامان وجميع الأشخاص الذين

هل يمكنك يا رفاق إما إغلاق هذا الخطأ والاعتراف بأنك لا تهتم ، أو تنفيذ الشيء البسيط للغاية الذي تريده الغالبية العظمى منا؟ بعد 2.86 سنة. انزل من القدر. امتلك قراراتك أو أصلح أخطائك. ومع ذلك تريد أن تنظر إليه. افعل أكثر من لا شيء.

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

أنا أيضًا حزين لأن هذا لم يتم تنفيذه بعد. لكن في المصادر المفتوحة إما أن نساهم أو ننتظر بصبر.

حجج CLI:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

فشل.

ملف Env:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

فشل.

الحلول المقترحة مع اسم المشروع في ملف yml:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

ياي!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

س /

من هم يا رفاق"؟

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

هذا واضح تمامًا ليس هو الحال هنا: من المحتمل أن يكون التنفيذ سهلاً للغاية لمن هم على دراية بقاعدة الكود وأصعب بكثير بالنسبة لشخص من الخارج. لذلك لا يعني ذلك أنه لا يوجد أحد لديه الوقت للقيام بذلك بل أن المشرفين لا يريدون القيام بذلك. وهذا ما يجده المؤيدون هنا مزعجًا للغاية ، نظرًا للوقت الطويل الذي ظلت فيه هذه القضية مفتوحة الآن وكتلة: +1: هنا.

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

دعونا ننظر إلى هذا من نقطة أخرى.

إذا كنت في مجلد به ملف docker-compose.yml ، كيف يمكنني معرفة اسم المشروع الذي
هذا سؤال أساسي إلى حد ما ، لكن لا توجد إجابة سهلة عليه.

حاليًا (مرتبة حسب الأولوية):

• قيمة -p
• قيمة COMPOSE_PROJECT_NAME من بيئتك
• قيمة COMPOSE_PROJECT_NAME من ملف .env
• اسم الدليل الحالي

أن تكون مدافعًا عن الشيطان ، فلماذا تضيف واحدًا خامسًا إلى هذا الإعداد المربك بالفعل؟

على الرغم من قرار ذلك ، يجب أن تكون هناك معلومات "قابلة للتشغيل الجاف" حول الاسم الحالي. لا يحتوي هذا الخيار على docker-compose config ولا يحتوي على docker-compose ps إذا لم يكن المكدس قيد التشغيل.
ربما يكون docker-compose create هو أفضل خيار متاح حاليًا ، لكنه بعيد عن الكمال.

يجب أن يكون هناك شيء مثل docker-compose config --project-name على الأقل. أحتاج حاليًا إلى معرفة المواقع المذكورة أعلاه والتحقق منها بالترتيب الصحيح.

إذا كنت في مجلد به ملف docker-compose.yml ، فكيف يمكنني معرفة اسم المشروع الذي يحتويه المكدس الخاص بي؟

مرة أخرى: إذا كنت لا ترغب في استخدامه فلا تستخدمه! إذا كنت سعيدًا بحلك - فهذا جيد لك !! لن يتغير شيء بالنسبة لك ، لذلك لن تشعر بالارتباك على الإطلاق!

لكن ألا يمكنك قبول أن لدى الآخرين متطلبات مختلفة؟ كل ما نريده هو أن تتم إضافة هذه القطعة المفقودة منطقيًا في النهاية.

أن تكون مدافعًا عن الشيطان ، فلماذا تضيف واحدًا خامسًا إلى هذا الإعداد المربك بالفعل؟

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

أحتاج حاليًا إلى معرفة المواقع المذكورة أعلاه والتحقق منها بالترتيب الصحيح.

لماذا لا تعرف اسم عامل ميناء مشروعك ولماذا يعتبر ذلك مناسبًا لك؟ ولماذا لا تستخدم نفس الآلية في جميع مشاريعك إذا كانت تربكك كثيرًا؟

مرة أخرى: إذا كنت لا ترغب في استخدامه فلا تستخدمه! إذا كنت سعيدًا بحلك - فهذا جيد لك !! لن يتغير شيء بالنسبة لك ، لذلك لن تشعر بالارتباك على الإطلاق!

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

لكن ألا يمكنك قبول أن لدى الآخرين متطلبات مختلفة؟ كل ما نريده هو أن تتم إضافة هذه القطعة المفقودة منطقيًا في النهاية.

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

السبب الوحيد الذي قد يكون مربكًا هو أن اسم المشروع تم استبعاده من docker-compose.yml في المقام الأول. كل شيء سيكون في هذا الملف الآن. يمكننا تحديد قائمة الأسبقية - ليست مشكلة.

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

لماذا لا تعرف اسم عامل ميناء مشروعك ولماذا يعتبر ذلك مناسبًا لك؟

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

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

سيؤدي هذا إلى إنهاء مكدسك الأول ، وسيكون هو نفسه مع اسم المشروع في الملف yml .

ولماذا لا تستخدم نفس الآلية في جميع مشاريعك إذا كانت تربكك كثيرًا؟

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

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

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

وحتى لو فعلوا ذلك ، كل شيء على ما يرام. لا أفهم المشكلة التي تحاول بناءها هنا. أنت تبالغ في تعقيد الأمور.

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

3 من الخيارات الأربعة في شجرة الأولويات لا قيمة لها بمجرد أن يكون لديك عدة ملفات تكوين مسماة في دليل. لا تخبرني بإنشاء أدلة فرعية ، لأنني ما زلت أشارك ملف .env عبرها.

لا تخبرني بإنشاء أدلة فرعية ، لأنني ما زلت أشارك ملف .env عبرها.

هل تشارك ملفًا محددًا لتطبيق .env مستخدم في env_file ؟
أو الذي يستخدمه docker-compose ؟
أم تخلطهم؟

هذا غير منطقي. إذا لم يقم شخص ما بإضافة اسم المشروع إلى docker-compose.yml فلن يتغير شيء.

هذه ليست المشكلة ، ولكن عندما يتم إضافتها يتغير السلوك بشكل جذري.

عندما نقوم بنسخ مكدس إلى دليل جديد لإنشاء مثيل مؤقت (على سبيل المثال ، لاختبار ترقية) ، لا يتعين علينا لمس docker-compose.yml على الإطلاق. ولكن إذا كان هذا جزءًا من المكدس ، فسنحتاج إلى تحديد ما إذا كنا نتجاوزه بـ .env أو ما إذا كنا سنغيره بـ docker-compose.yml .

نعم، قد يكون من أنه لم يكن ينبغي المضافة في المقام الأول، ولكن وجود خيار آخر هنا أيضا لا يجعل الأمور أسهل وأكثر إيجازا.

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

أنا أفضل هذا

docker-compose -f service1.yml up -d

بدلا من ذلك هو أشبه بهذا

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42 هل تعتقد بجدية أن هذا هو الحل لكتابة "COMPOSE_PROJECT_NAME = ..." في كل مرة لكل أمر عامل عامل إنشاء عامل ، ربما بالإضافة إلى اسم ملف الإنشاء؟ يتطلب ذلك أيضًا معرفة اسم المشروع وتذكره. إن القدرة على تحديد اسم المشروع في متغير بيئة لها استخدامات مؤكدة ولكن في بعض الحالات تريد فقط أن يكون لديك دليل به ملفين yml وأن تكون قادرًا على إدارة المشاريع بسهولة بطريقة مضمونة دون الحاجة إلى ذلك تذكر أسماء المشاريع التي اخترتها منذ شهور ودون الحاجة إلى تذكر تصدير متغيرات البيئة.

ألا يمكنك استخدام مجلد واحد لكل خدمة ولا يزال لديك ملف .env في المجلد العلوي؟

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

فقط اكتب اسم المشروع في الملف (-path) 😉

أستسلم. من الواضح أن قاعدة العملاء لهذا قد تغيرت.

اسمحوا لي أن أعرف ما هو الخطأ في الاقتراح الذي قدمته لك.

كانت لدي نفس المخاوف في البداية ، لكننا قمنا بتعديل مهام سير العمل لدينا وفقًا للميزات المتاحة.

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

لا أريد حقًا التورط هنا ... لكن لا يمكنني المقاومة.

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

تضمين التغريدة

لا أتذكر قتل مكدس عن طريق الخطأ في العامين الماضيين ، من قبل أحد من فريقنا .

يجب أن اسأل. أرى أنكما جزء من منظمة codemix . هل انتم زملاء العمل؟ لتبدأ في التساؤل عما إذا كنتما خلف الكواليس متخلفان.

حاليًا (مرتبة حسب الأولوية):

1. قيمة -p
2. قيمة COMPOSE_PROJECT_NAME من بيئتك
3. قيمة COMPOSE_PROJECT_NAME من ملف env الخاص بك
4. اسم الدليل الحالي

أن تكون مدافعًا عن الشيطان ، فلماذا تضيف واحدًا خامسًا إلى هذا الإعداد المربك بالفعل؟

المشكلة كما أراها هي _كل قيمة مفردة_ متوفرة حاليًا للاستخدام _ خاصة بالبيئة _. لا توجد طريقة لتقديم خيار خاص بالمشروع.

1 + 2. يجب أن يتم توفيرها يدويًا بواسطة المستخدم الذي يستدعي الأمر.

1. _Could_ يمكن مشاركتها ، ولكن من الناحية العملية ، يجب تجاهل .env وعدم مشاركتها لسبب وجيه. (أعمل على حل هذا من خلال مشاركة .env.example ، لكن هذا لا يزال يتطلب خطوة يدوية إضافية.)
2. عشوائي بشكل فعال ، ومخصص للمستخدم / البيئة. (أنا أعتبر هذا أيضًا احتياطيًا ، لأن إنشاء _ يحتاج_ اسم مشروع. إنه ليس احتياطيًا جيدًا للغاية ، لأنه قد تكون هناك مشاريع في أدلة مختلفة تسمى نفس الشيء الذي قد يتعارض.)

في رأيي ، والعديد من هؤلاء الموجودين في هذا الموضوع ، يجب أن يكون هناك خيار يعيش بين 3 و 4 ، حيث يتم توفير اسم مشروع افتراضي _يمكن _ في أي ملف إنشاء عامل ميناء يتم استخدامه لهذا المشروع ويتم استخدامه كأول تراجع. سيتم بعد ذلك مشاركة هذه القيمة من قبل أي شخص ينشر هذا المشروع. ستتجاوز الخيارات من 1 إلى 3 هذه القيمة ، ولن يتم استخدام الخيار 4 إلا إذا لم يتم توفيره.

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

تضمين التغريدة

1. يمكن مشاركتها ، ولكن في الممارسة العملية ، يجب تجاهل .env وعدم مشاركته لسبب وجيه.

هذا يعتمد على الإعداد الخاص بك ، لقد تم تجاهل هذا في جميع مستودعات مشروعنا.
لكننا لا نتجاهلها في مستودعاتنا الخاصة بالتدريج والإنتاج فقط. إذا كنت تريد مشاركة الاسم الذي تم الالتزام به في docker-compose.yml فيمكنك أيضًا تنفيذ .env (هذا الملف مخصص فقط للأمر docker-compose - لا شيء آخر)

1. عشوائي بشكل فعال ، ومخصص للمستخدم / البيئة.

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

لدي بديل أخير لكم جميعًا:

docker stack deploy -c docker-compose.yml the-project-name

(*) متوفر فقط في وضع السرب

لا أستطيع أن أرى كيف يمكن وضع اسم المشروع في ملف yml في المستقبل ، سيتعارض تمامًا مع فكرة تعريف المكدس.

شكرا @ schmunk42. أعتقد أنك وأنت قد تعاملت مع الأمور بشكل جيد من بين جميع الآراء القوية المعروضة في هذا الموضوع.

سيقدم مصدرًا كبيرًا للأخطاء المحتملة في إعدادنا.

هناك مشكلة. أغلق القضية.

هذا يعتمد على الإعداد الخاص بك ، لقد تم تجاهل هذا في جميع مستودعات مشروعنا. لكننا لا نتجاهلها في مستودعاتنا الخاصة بالتدريج والإنتاج فقط.

إذن ، لا ينبغي تقديم هذه الميزة التي يريدها أي شخص آخر لأنها ستكسر بنية المستودع غير العادية؟

إذا كنت تريد مشاركة الاسم الذي تم إنشاؤه في docker-compose.yml فيمكنك أيضًا تنفيذ .env (هذا الملف مخصص فقط لأمر docker-compose - لا شيء آخر).

حسنًا ، إذا كان الشيء الوحيد في ملف .env هو COMPOSE_PROJECT_NAME ، إذن نعم. لكنها مليئة بالعديد من المتغيرات "الآمنة" الأخرى التي لا أريد الالتزام بها. وقمت باستيرادها إلى عامل بناء السفن باستخدام خاصية environment . هذا ما تستخدمه ملفات .env بشكل عام ...

ما زلت لا أفهم حقًا كيف سيؤدي ذلك إلى تعطيل الإعداد الخاص بك ، حيث إنه في اقتراحي يتجاوز فقط اسم المشروع الافتراضي المأخوذ من الدليل. وإذا كنت تعتمد على ذلك (لأنه دليل ملتزم بـ _into_ الريبو الخاص بك بدلاً من الدليل الذي تم نسخ الريبو الخاص بك إليه) ، فكيف يمكن تجاوزه من خلال إعداد docker-compose.yml (لأنه ملتزم أيضًا) إلى الريبو الخاص بك ؛ أنت تتحكم في كلا الأمرين في السيناريو الخاص بك)؟

@ schmunk42 ما تقوله هو "لا أريد ميزات جديدة ، لأنني لا أفهم إعداد مشروعي بعد الآن".

بجدية؟ هذه هي حجتك لماذا تريد من كل شخص آخر أن يفعل ذلك بدونها؟

فقط للتسجيل: أنا هنا أيضًا. لا تتردد في إغلاق القضية. أصبح النقاش هنا بلا معنى.

إذن ، لا ينبغي تقديم هذه الميزة التي يريدها أي شخص آخر لأنها ستكسر بنية المستودع غير العادية؟

أنا أعبر عن مخاوفي من أنه قد يقدم مصادر إضافية للأخطاء.

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

استخدم secrets.env لهؤلاء واستوردها عبر env_file .
كيف سيؤثر ذلك على سير عملك؟

هذا ما تستخدمه ملفات .env بشكل عام ...

صحيح ... لكنني ما زلت أعتقد أن المشكلة هي أن docker-compose يخطف ملف .env .

كيف سيكون الأمر ، إذا كان بإمكانك تعيين هذه المتغيرات بالإضافة إلى docker-compose.yml ، مثل IMAGE_VERSION ، في ملف يسمى docker-compose.env ؟

لم أجرؤ على اقتراح COMPOSE_COMMAND_ENV_FILENAME=.env - حتى الآن :)

ما زلت لا أفهم حقًا كيف سيؤدي ذلك إلى كسر الإعداد الخاص بك ، ...

صحيح أنه لا ينكسر على الفور ، ولكنه يتعلق فقط بنقطتي الأولى - وتقديم المزيد من الخيارات.

فكر في استخدام ملفات متعددة -f docker-compose.A.yml -f docker-compose.B.yml ، لنفترض أن A هو مشروعك ويعتمد على اسم المشروع حسب الدليل (نقوم بذلك ، نظرًا لأننا نتحكم فيه!) ، بينما B هو مجموعة من الخدمات الإضافية مع project_name: extra ، تم تقديمها عن طريق الخطأ أثناء الاختبار في مجلد يحتوي على ملف .env والذي تم استبدال اسم المشروع بـ COMPOSE_PROJECT_NAME=testing .

ولكن الآن أي مشروع يبدأ بدون ملف .env ، سيتم تسميته extra . 💥

نحن نقوم بدمج الملفات على عدة مستويات ، بما في ذلك عدة ملفات *.env ، إنها حالة استخدام صالحة جدًا.

بجدية؟ هذه هي حجتك لماذا تريد من كل شخص آخر أن يفعل ذلك بدونها؟

تحذير: خارج الموضوع قليلاً ، ولكن لا يزال مرتبطًا بعمال الشحن ...

• "لا أعتقد أننا بحاجة إليه حقًا"
• "لديها طبقات أكثر من الضرورية. أكثر تعقيدًا"

mikehaertl أتساءل حقًا أنك تراها بهذه الطريقة ؛)

مرحبا يا اصدقاء،

لقد تناولنا المناقشة الحماسية في هذا الموضوع (شكرًا لمن أبقوها حضاريًا ووديًا!) وبينما لا نزال نعتقد بشكل أساسي أن اسم المشروع لا ينتمي إلى ملف Compose ، توصلنا إلى ما نعتقد أنه حل وسط معقول مع العلاقات العامة التالية: # 5378. ومع ذلك ، فإننا نقدر تعليقاتك على هذا للتأكد من أنه يلبي احتياجاتك.

ها هي الجوهر:

• يمكنك إضافة إدخال x-project-name داخل ملف الإنشاء. يتم تجاهل هذا المفتاح افتراضيًا.
• عند تعيين COMPOSE_X_PROJECT_NAME في بيئتك (أو ملف .env ) ، سيحاول Compose استرداد اسم المشروع من الإدخال x-project-name داخل ملف Compose الخاص بك.
• هذا الخيار له أولوية أقل من COMPOSE_PROJECT_NAME و --project-name

يسعدني الرد على أي أسئلة أو مخاوف بخصوص هذا.

@ shin- لذا يجب تعيين COMPOSE_X_PROJECT_NAME على 1 لتفعيل الميزة؟

إذا كان الأمر كذلك ، فقد يكون COMPOSE_ENABLE_X_PROJECT_NAME أيضًا تسمية يجب التفكير فيها ، لكن هذه مجرد سنتان - لن أستخدمها على أي حال

@ schmunk42 ستعمل أي قيمة لـ "الحقيقة- y" ، ولكن نعم ، هذه هي الفكرة.

matsaman Cool ، شكرًا على التعليقات المفيدة

بدلاً من إخبارنا بأنه يتعين علينا إخبار المستخدمين النهائيين بتعيين متغير أو استدعاء معلمة ، فأنت تخبرنا أنه يتعين علينا إخبار المستخدمين النهائيين بتعيين متغير أو استدعاء معلمة.

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

@ shin - سأشرح كيف لا يحدث هذا التغيير أي فرق مفيد:

إن الاضطرار إلى تعيين متغير بيئة لتمكين البحث عن اسم المشروع في ملف الإنشاء يعادل تقريبًا {مقدار العمل وخطر النسيان والملاءمة} ، كإعداد متغير بيئة لاسم المشروع نفسه.

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

أعتقد أنه حل جيد جدًا ، لأنه لن يكسر BC وسيتجنب إدخال أخطاء أثناء الدمج كما وصفت أعلاه.

إن الاضطرار إلى تعيين متغير بيئة لتمكين البحث عن اسم المشروع في ملف الإنشاء يعادل تقريبًا {مقدار العمل وخطر النسيان والملاءمة} ، كإعداد متغير بيئة لاسم المشروع نفسه.

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

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

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

أحد أهم أهداف وجود اسم المشروع في ملف الإنشاء هو التأكد من تخزين كل متغير له علاقة بمشروع الإنشاء في التحكم في الإصدار.

تضمين التغريدة
إنه مصمم خصيصًا لمساعدة الأشخاص الذين لديهم ملفات إنشاء متعددة في نفس الدليل ، والذين لا يعد حل ملف .env خيارًا. إذا كان هذا يحتاج إلى التشغيل دائمًا لمشاريعك ، فمن السهل تعيينه في ملف .env الخاص بك ، أو .profile ، أو في أي مكان آخر يضمن دائمًا الحصول على x-project-name داخل الحساب.

بدلاً من إخبارنا بأنه يتعين علينا إخبار المستخدمين النهائيين بتعيين متغير أو استدعاء معلمة ، فأنت تخبرنا أنه يتعين علينا إخبار المستخدمين النهائيين بتعيين متغير أو استدعاء معلمة.

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

إذا قمت بذلك ، فقد تحصل على سلوك غير مرغوب فيه في مشاريع غير ذات صلة تمامًا.

هل يمكن أن تعطي مثالا؟ لا يمكنني التفكير في أي سلوك غير مرغوب فيه بمجرد تعيين COMPOSE_X_PROJECT_NAME في قشرتي.

أحد أهم أهداف وجود اسم المشروع في ملف الإنشاء هو التأكد من تخزين كل متغير له علاقة بمشروع الإنشاء في التحكم في الإصدار.

لماذا لا يمكنك استخدام .env لذلك؟ لا أحد يمنع تخزين .env في التحكم في الإصدار (نعم ، هذا ليس شائعًا).

كان لدينا .env في البداية. من الواضح أنك فاتتك المحادثة بأكملها.

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

لتوضيح بعض الالتباس

يمكنك فعل ذلك بالفعل

في السابق كان بإمكانك تعيين اسم مشروع باستخدام متغير البيئة. متغير البيئة الجديد ليس اسمًا ، إنه تبديل مكّن ميزة تتيح لك تعيين اسم مشروع في ملف الإنشاء.

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

إذا كنت تقصد "مشاريع أخرى" على أنها في ، "يمكن لشيء غير مؤلف أن يقرأ هذا ويكسر" أعتقد أن هذا غير واقعي. هناك الكثير من متغيرات البيئة المحددة في كل غلاف. متغير البيئة محدد بمساحة الاسم بشكل صحيح كـ "COMPOSE_X_".

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

إذا لم يكن أيًا من هذين ، فيرجى توضيح ذلك.

سيؤدي ذلك أيضًا إلى حدوث ارتباك عندما يسحب المطور مشروعًا من التحكم في الإصدار وينسى تعيين متغير البيئة.

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

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

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

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

جمال عامل عامل البناء هو up . ليست تعليمات حول كيفية إعداد تلك المكالمة.

تضمين التغريدة

مرة أخرى ، وضع a .env في المستودع ليس خيارًا بالنسبة لي.

هل تستطيع التمديد؟ أسمعك تمامًا عن المستخدمين ذوي المعرفة التقنية الأقل ، ولكن إذا لم يكن من المفترض أن يتفاعلوا مع الكود أو البيئة ، فلماذا يمثل تضمين ملف .env مع المشروع مشكلة؟

@ شين - نعم ، لا مشكلة.

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

يضم .env المعلمات المستخدمة في أطر عمل أخرى. بعض المتغيرات داخل .env هي بيانات اعتماد لخدمات خارجية مثل SMTP. يقوم معظم المطورين في فريقي بتوجيه هذه الخدمات إلى نقاط النهاية الخاصة بهم باستخدام ملف .env الخاص بهم. إذا لم يكن .env موجودًا ، فلدي قيم افتراضية.

بالنسبة للمطورين الأقل تقنيًا الذين ربما يرغبون فقط في تغيير بعض CSS ، يعمل التطبيق بشكل جيد بدون ملف .env . هذا على افتراض أنهم لا يسمون كل مجلد مشروع بنفس الاسم. :)

قد لا يبدو الأمر كثيرًا ولكن عندما تعمل مع العديد من المطورين والمصممين المنتشرين في جميع أنحاء البلاد - كلما كان الأمر أبسط كان ذلك أفضل.

لقد جعل Docker حياتي أسهل كثيرًا وأنا ممتن جدًا لهذا المشروع ، لكن يمكنني أن أتعلق بالإحباطات حول هذا الموضوع.

fiveanddone شكرا لك على البصيرة! لذا إذا كان الملف .env يُدعى docker-compose.env (أو ما شابه) بدلاً من ذلك ، فهل سيخفف ذلك من مخاوفك؟

@قصبة-

نعم ، سيكون لحالات الاستخدام الخاصة بي.

هل يتم تحميل ملف env تلقائيًا بواسطة Docker Compose؟

إذا لم يكن الأمر كذلك ، فهل يمكن تحميل docker-compose.env تلقائيًا؟

nhooey يتم تحميل ملف env تلقائيًا إذا كان اسمه .env . ويمكنك أيضًا تحديد ملف env لكل خدمة على حدة. انظر المستندات .

يتم تحميل ملف env تلقائيًا إذا كان اسمه .env. ويمكنك أيضًا تحديد ملف env لكل خدمة على حدة. انظر المستندات.

لا ينبغي أن يكون منتقي القاذورات هنا ، لكن هذا ليس صحيحًا حقًا. و IMHO أكبر مصدر لسوء فهم الموضوع بأكمله.

لا يتم تمرير أي من متغيرات .env خلال حاوية / خدمة ، إذا لم تقم بإعادة توجيهها صراحة ، باستخدام أي منهما

env_file: 
  - .env

أو

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

يتم تحميل الملف .env تلقائيًا ، نعم ، ولكن بدون مزيد من التكوين ، فإنه ينطبق فقط على متغيرات بيئة Compose CLI هذه.

أنا أؤيد بشدة إعادة تسمية ذلك إلى docker-compose.env افتراضيًا بل وأفضل - متغير لذلك ، لذلك يمكن استخدامه بطريقة BC مع إعداد ENV-var واحد فقط.

(شكراً لمن أبقوها حضارية وودية!)

أسمعك وأنا بالتأكيد مذنب لأنني لم أحتفظ دائمًا بهدوئي. اسف على ذلك. بعض التعليقات أحيانًا تجعلني أبدأ حقًا ... ستعمل على ذلك.

إذا كان اسم المشروع موجودًا في ملف الإنشاء ، فيمكن لأي مشروعين استخدام نفس الاسم ، مما يتسبب في حدوث تعارض ، مما يؤدي إلى تعطيل كلا المشروعين.

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

@ shin- هذا يبدو كما هو متفق عليه بشكل عام ، أن docker-compose.yml هو دائمًا جزء من مشروع ويعيش في مستودع المشروع. سأقول أن هذا ليس صحيحًا بالضرورة. لا يشارك البعض منا docker-compose.yml لكنهم يريدون الاحتفاظ بنسختهم المحلية مع التخصيصات المحلية (مثل إعدادات التطوير ، والاختبارات ، وما إلى ذلك).

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

إليك اقتراح: ماذا عن إضافة خيارين آخرين لاسم المشروع وإيقاف استخدام .env في V4 من docker-compose.yml ؟ أحدهما هو project_name في docker-compose.yml ، والآخر عبارة عن ملف .dockerproject يحتوي فقط على الاسم ولا يجب إرساله

هذا هو اقتراحي للأسبقية (الأعلى أولاً):

• -p CLI وسيطة
• .dockerproject
• project_name in docker-compose.yml (يجب تجنبه ، إذا تم توزيع docker-compose.yml مع المشروع)
• COMPOSE_PROJECT_NAME من البيئة
• COMPOSE_PROJECT_NAME من .env (مهمل)
• اسم الدليل

بهذه الطريقة ، لا يزال بإمكان المستخدمين النهائيين تجاوز اسم المشروع في .dockerproject حتى لو قام شخص ما بترميزه بشكل ثابت في docker-compose.yml الموزع.

تحديث: يمكنني أيضًا العيش باستخدام .dockerenv أو docker.env بدلاً من .dockerproject . ولكن يجب أن يكون لها أولوية أعلى لحل المشكلة ، حيث يحتاج البعض هنا إلى تجاوز أسماء المشاريع المشفرة في docker-compose.yml .

تحية للجميع،

بادئ ذي بدء ، شكرًا

لقد تحققت من صحة PR 5378 في مشروع الاختبار لحالة الاستخدام التالية: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). لذلك قمت بعمل git repo يوضح الاحتمالات المختلفة: https://github.com/estarter/compose_745

لقد وجدت PR # 5378 يغطي حالة الاستخدام جزئيًا. المشكلة هي أن الحل يتطلب COMPOSE_X_PROJECT_NAME متغير env. الحلول الممكنة:

1. استمر في المتغير env في مجلد المشروع. لقد جربت ملف .env ولكنه لا يعمل عندما يتم استدعاء docker-compose من موقع آخر (انظر مثال الأوامر ، إنشاء الملفات )
2. حدد COMPOSE_X_PROJECT_NAME بشكل عام (ملف شخصي أو ما يعادله). قد ينجح ذلك ولكن لا يمكن تحديده في المشروع ، أي أنه ليس حلاً لحالة الاستخدام الخاصة بنا defined by the project, that can be checked in
3. هل يوجد خيار اخر

آمل أن أتمكن من توضيح حالة الاستخدام التي تم تناولها هنا.

أعزائي المشرفين ، يرجى النظر في كيفية حل حالة الاستخدام عن طريق PR # 5369 والتي تقدم خاصية project_name الاختيارية في ملف docker-compose. تأخذ هذه الخاصية أولوية منخفضة ولكنها لا تعتمد على البيئة أو دليل العمل.

1. هل يوجد خيار اخر

يوجد هذا الخيار docker-compose --project-directory <PATH> (حدد دليل عمل بديل). يجب أن يعمل أيضًا مع ملف .env .

لإضافة حالة استخدام أخرى دقيقة إلى المزيج:
في حالة الاستخدام الخاصة بي ، لدي مستودعين ، أحدهما للمشروع الرئيسي (يستخدم للبناء / النشر) والآخر للمطورين (يحتوي على Dockerfile's و docker-compose.yml وما إلى ذلك)
في إعدادنا الحالي ، يوجد ريبو المشروع الرئيسي في الجذر. / ويتم سحب المستودع devops إلى دليل فرعي ./devops/

في هذا الإعداد ، لا يعمل استخدام ملف .env لأنه يجب أن يكون:

وضعها في المجلد حيث يتم تنفيذ أمر docker-compose (دليل العمل الحالي).
(مرجع الوثيقة)

هذا لا يعمل ، حيث يتم استدعاؤه على النحو التالي: docker-compose -f devops/docker-compose.yml
بالطبع ، يمكننا إضافة المعلمة -p هنا ، وهو ما نستخدمه حاليًا ، ولكنه عرضة للخطأ البشري كما تمت الإشارة إليه أعلاه.

إذا كان من الممكن قراءة ملف .env (أو ملف docker-compose.env المقترح) من نفس الدليل حيث يوجد docker-compose.yml ، فعندئذٍ سيعمل تحديد اسم المشروع هناك.

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

في النهاية ، هدفي هو الاحتفاظ بملفاتي المتعلقة بـ devops قائمة بذاتها بطريقة لا تلوث قاعدة رمز مشروعي الفعلي ، ولكن لا يزال من الممكن الوصول إليها / تشغيلها بالتوازي مع هذا الريبو.

يوجد هذا الخيار docker-compose --project-directory(حدد دليل عمل بديل). يجب أن يعمل أيضًا مع ملف .env.

@ schmunk42 يمكن أن تكون لقطة جيدة ، لكن --project-directory لا يعمل مع ملف env. حاولت كالتالي ، تم تجاهل ملف env ( ملفات المشروع ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

من الآن فصاعدًا ، سأحذف التعليقات التي لا تساهم في المحادثة بطريقة بناءة. ليس لدي اهتمام بالتفاعل مع الأطفال.

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

على .env الاسم نفسه
من الواضح الآن أن الاسم .env يُستخدم بواسطة العديد من البرامج والأطر ، ولا يُقصد به عادةً الالتزام بالتحكم في الإصدار. نحن حساسون جدًا لإجراء تغييرات عاجلة ، ولكن يمكننا تقديم اسم بديل (على سبيل المثال docker-compose.env ) مع الرجوع إلى الملف .env إذا لم يكن الأول موجودًا ، بقصد يمكن مشاركتها مع مستخدمين آخرين.

عند إضافة project_name إلى ملف الإنشاء
لقد كررنا موقفنا من هذا عدة مرات بالفعل - راجع تعليق دانيال الأخير لمعرفة بعض الأسباب التي نعارضها لإجراء هذا التغيير. ليس الأمر أنه صعب. ليس الأمر أننا لم نفكر في الأمر. لقد أمضينا الكثير من الوقت في تقييمه ، ونشعر أن جودة المشروع ستعاني كثيرًا نتيجة لإضافته (في هذا النموذج). من الناحية الواقعية ، من المحتمل أن يكون # 5378 هو أفضل تنازل يمكننا تقديمه لهذا العمل بطريقة قابلة للاشتراك ومتوافقة مع الإصدارات السابقة (تحرير: بالطبع ، أنا منفتح على الاقتراحات التي تعمل على تحسين هذا الاقتراح ضمن هذه المعلمات)

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

مع كل ما قيل ، هل هناك أي شخص لن يكون حلاً مرضيًا بالنسبة له docker-compose.env + # 5378؟ أتفهم أنه قد لا يكون الحل المفضل لديك ، لكني أسأل ما إذا كان يقدم تنازلات معقولة يمكنك التعامل معها.

كل المزاح جانبا ...

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

أعتقد أن المعسكر الذي يريد الحقل project-name (أو أيًا كان) له ما يبرره ، نظرًا لأن "اسم" المشروع أساسي للعديد من جوانب الأداة. قد يرغب الأشخاص في هذا المعسكر في كتابة هذا الاسم ببساطة في مكان ما لتجنب المشكلات المتعلقة بالحلول المؤقتة مثل متغيرات البيئة أو الأمر مثل الأعلام.

آمل أن يكون هذا بناء.

estarter كنت أعتبر هذا خطأ ، ربما يستحق فتح مشكلة منفصلة له

في الواقع ، أتوقع أن يعمل هذا مع الملف .env في الدليل PR_5378 :

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

عند إضافة اسم_المشروع إلى ملف الإنشاء

@ shin - على ما يبدو ، تم اتخاذ القرار بالفعل. لكني ما زلت أحاول فهم الخلفية. لقد سألت هذا من قبل ولم أحصل على إجابة (وهذا أحد الأسباب التي جعلت المناقشة مزعجة جدًا بالنسبة لي).

هل يمكنك مساعدتي في فهم سبب وجود container_name وحتى network في docker-compose.yml ؟ قد يكون الأول مصدرًا للنزاعات المحتملة أيضًا. وهذا الأخير خاص بالمضيف. باتباع منطقك لا ينبغي أن يكون هذان الشخصان (والآخرون) موجودين أيضًا. فشلت في رؤية الفرق بين project_name .

من فضلك ، لا تتجاهل هذا السؤال مرة أخرى.

@ michael-k هل تقول أن project_name هو نفسه container_name ؟ إذا كنت تقول ذلك ، فأود إخبارك أن مشروعًا واحدًا قد يتكون من عدة حاويات. أم أنني أسأت فهمك؟

بينما بالنسبة لـ network ، فهي ليست بالضرورة خاصة بالمضيف. هناك العديد من الحالات التي يتطلب فيها المشروع شبكة مركزية معزولة تتفاعل فيها حاوية واحدة مع شبكة أخرى. ويتم تخزين تكويناته في docker-compose.yml .

AyushyaChitransh انت container_name ، network وغيرها في docker-compose.yml بينما project_name يجب ألا يسمح لهم بالتواجد هناك؟ يشتركون جميعًا في نفس احتمالية حدوث تعارض أو تكوين خاص بالمضيف لا ينبغي مشاركته.

aanand أعرف عن هذه الفرصة. أيضًا ، يمكن إخبار نفس الشيء عن أسماء الحاويات ، لكن لدينا فرصة لتعيين اسم الحاوية في ملف الإنشاء ، أليس كذلك؟

نعم ، لكن لا أعتقد أن الإضافة كانت فكرة جيدة.

من المناقشة ذات الصلة حدد اسم الشبكة في ملف إنشاء عامل الإرساء .

estarter كنت أعتبر هذا خطأ ، ربما يستحق فتح مشكلة منفصلة له

@ schmunk42 أرى أن On --project-directory في تعليق Joffrey بالإضافة إلى # 4709 و # 4933 و # 4841

في الواقع ، أتوقع أن يعمل هذا مع ملف .env في الدليل PR_5378:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

لقد افترضت أن --project-directory يؤثر على المعلمة -f .
في الحقيقة ليس الأمر كذلك ، هذا الأمر يعطي IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

من الجيد جدًا ألا يؤثر --project-directory على -f - وإلا تخيل ما سيكون عليه استخدام --project-directory والعديد من ملفات إنشاء عامل الإرساء في دلائل مختلفة.

أنا مندهش للغاية لرؤية الكثير من المداولات حول شيء أعتبره مشكلة محلولة.

هذا هو ترتيب الأسبقية الذي اعتدت رؤيته:

1. مضمنة
2. خيار cli
3. بيئة
4. مشروع
5. تقصير عاقل

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

يبدو أن لدينا حججًا فلسفية حول النقاء والتي قد لا تكون مفيدة. من ناحية أخرى ، يعد استخدام نظام تكوين متتالي شائع جدًا لـ OSS مفيدًا للغاية.

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

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

لكن اسمحوا لي أن أكون صريحا بشأن هذا. لن يحدث هذا أبدًا في docker-compose . إذا كان هذا هو مسار الحل الوحيد الذي ترغب في قبوله لهذه المشكلة ، فسيتعين عليك اتباع عملية OSS ذاتها المتمثلة في تفرع المشروع والقيام به بنفسك. الرمز متاح ومشاركته مع ترخيص متساهل للغاية.

هل يمكنك مساعدتي في فهم سبب وجود Container_name وحتى الشبكة في docker-compose.yml؟ قد يكون الأول مصدرًا للنزاعات المحتملة أيضًا. وهذا الأخير خاص بالمضيف. باتباع منطقك لا ينبغي أن يكون هذان الشخصان (والآخرون) موجودين أيضًا. فشلت في رؤية الاختلاف في اسم المشروع.

بالنسبة إلى container_name ، تم تقديم هذا الخيار في وقت مبكر جدًا من عمر المشروع. كما أشار @ schmunk42 ، إذا أردنا فعل ذلك مرة أخرى ، فلن يكون هذا بالتأكيد في المواصفات. يتم إساءة استخدامه باستمرار وكان مصدر مشكلات لا حصر لها للمستخدمين على مر السنين.
بالنسبة إلى network ، لست متأكدًا تمامًا من كيفية مقارنتها في ذهنك؟

ماذا عن الخيار رقم 4 الذي ذكرته؟ رأيت بعض الحديث عن تقديم .docker-compose لإعدادات الدليل المحلي الخاصة. سيكون هذا أفضل بكثير (imo) لتقديم إشارات البيئة _x_ (التي لا تزال تتطلب إدارة البيئة).

سيكون مثل هذا:

# <my-project-dir>/.docker-compose
project_name: foobar

ما ورد أعلاه يختلف عن خيار متغير البيئة وأقل في قائمة الأسبقية.

هذا يحل حالة الاستخدام الخاصة بي بشكل جيد ويضع علامة على مسار تكوين قياسي آخر خارج القائمة.

thedeeno في أذهاننا ، فإن COMPOSE_PROJECT_NAME داخل الملف .env يحقق ذلك بالفعل (بنفس ترتيب الأولوية كما في المخطط التفصيلي الخاص بك). ومع ذلك ، فقد سمعنا أن .env هو اختيار ضعيف للاسم ، ولهذا السبب نحن نفكر في docker-compose.env كبديل. هل سيعمل هذا معك؟

في أذهاننا ، يقوم COMPOSE_PROJECT_NAME داخل ملف .env بإنجاز ذلك بالفعل

@ shin- هذا هو المكان الذي نختلف فيه. لا أعتقد ذلك.

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

يعمل هذا بشكل رائع للمساعدة مع number 3 أعلاه ، التكوين القائم على البيئة.

لا يمنحنا فتحة هروب ( number 4 ) عندما لا نريد أن تمتلك البيئة اسم المشروع.

في حالتي ، سيكون لدى المطورين لدينا ملف .env (وليس VC). يحتوي على أسرار لإدخالها في docker-compose.yaml . احب هذا.

لا نريد للمطورين أن يتحكموا في اسم المشروع ، مع ذلك ، لأنه مقترن بقوة ببعض الأدوات. نظرًا لأن .env لا يتحكم في الإصدار ، يتعين علينا أن نطلب من مطورينا تعيين COMPOSE_PROJECT_NAME يدويًا باستخدام هذا الأسلوب ؛ وهو الشيء الوحيد الذي لا يشبه الآخرين ، لأنه ليس سرًا.

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

سأعرض حالة استخدام واحدة من ممارستي:

أنا أستخدم ملف .env لتحديد إصدار الصورة ، ولتجنب sed / awk / perl / أي تحليل غريب ، قمت فقط بالكتابة فوق القيمة في CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

لاحقًا في docker-compose.yml ، تم تحديد الصورة على النحو التالي:

    image: my.registry.example.net/app:${APP_VERSION}

الآن إذا كنت بحاجة إلى المزيد من المتغيرات من هذا النوع ، فأنا بحاجة إلى إجراء بعض التحليل ، ما لم يتم دعم ملفات .env متعددة.

لذلك ، ربما تضيف أيضًا دعم "الدليل" ، مثل: docker-compose.env.d/* أو .docker-compose.env.d/* أو docker-compose.d/* .

ولكن على هذا النحو ، يمكن للكرة الأرضية أن تخلق على الفور مشاكل مطابقة النسخ الاحتياطية للمحرر ( *~ ، *.bak ) من الأفضل استخدام بعض الامتدادات بدلاً من ذلك: docker-compose.env.d/*.sh

... ولكن مرة أخرى ، ربما تجعله قابلاً للتكوين في docker-compose.yml ما هو مستوى الجذر .env يتم تحميل الملفات ، أو قد يؤدي ذلك إلى مشكلة بيضة الدجاج؟ لا أعرف كيف يعمل محلل التكوين :)

بعيدًا عن الموضوع قليلاً ، لكن COMPOSE_PROJECT_NAME env لا يسمح بالتحكم الكامل ببادئة ، سيظل يتم تجريده ليطابق A-Za-z0-9_ ... أردت استخدام - في البادئة الخاصة بي. (لا يمكنني العثور على المكان الذي أبلغت فيه عن هذا الآن ، لكن Afaik لم تتم معالجته)

سيكون من المنطقي السماح لنفس الأحرف التي يحدها عامل الإرساء نفسه.

glensc هناك الكثير من البنية التحتية لإدارة البيئة. أنا شخصياً لا أعتقد أن هذه مسؤولية docker-compose .

الشيء الوحيد الذي رأيته يفعله مشروع آخر هو مصدر .env تلقائيًا

glenscthedeeno من الناحية المثالية ، سيكون لدينا ملفان *.env ، أحدهما من المفترض مشاركته مع مستخدمين آخرين ، والآخر خاص ، مع تجاوز الأخير السابق عندما يحدد كلاهما نفس var؟

لقد تناولت أسماء .env القابلة للتكوين في تعليقي الأسبوع الماضي.

إن الحصول على docker-compose.env (بينما لا يزال التوريد التلقائي خاصًا .env ) سيكون مفيدًا لنا!

سنتعامل معه كملف rc ونلزمه بالتحكم في المصدر.

أعتقد أن وجود ملفات env عامة / خاصة ، يحل على الأرجح معظم حالات الاستخدام المذكورة هنا. إذا تم السماح باستخدام - في اسم المشروع أيضًا ، فسيكون ذلك رائعًا.

thedeenoglensc هل يمكن أن يرجى إعطاء حالة الاستخدام حيث كنت في حاجة الى ملف ENV الخاص تجاوز القيم في واحد العام؟

يجب عدم تحديد الأسرار في docker-compose.env ، حيث لن يتم إعادة توجيهها تلقائيًا إلى الحاويات. لا يزال بإمكانك استخدام ملف .env ثم القيام بكل ما تريد به. لكن يبدو الأمر محيرًا بالنسبة لي لمزج الإعدادات لـ docker-compose والحاويات في المكدس.

@ schmunk42 ليس لدي حالة الاستخدام هذه ، لذا لن أقدم الكثير من المساعدة هناك. أحتاج فقط إلى الالتزام بـ project_name للتحكم في الإصدار. docker-compose.env يحل ذلك.

لست متأكدا من اتباع الفقرة الثانية الخاصة بك. نستخدم .env للأسرار ونحقنها يدويًا بـ docker-compose.yaml .

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

هذا فقط لأن المكان الوحيد لتعريف ${variables} image لقيمة .env .

glensc متفق عليه!

لكن بدلاً من ذلك ، أقترح docker-compose.override.env لمواءمته مع ميزة التجاوز الحالية لملفات yml .

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

لست متأكدا من اتباع الفقرة الثانية الخاصة بك. نحن نستخدم .env للأسرار ونحقنها يدويًا في docker-compose.yaml.

thedeeno أفترض أنك تفعل هذا:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

والذي يجب أن يكون ممكنًا أيضًا مع docker-compose.override.env . أو يمكنك القيام بما يلي:

env_file:
  - .env

هل تقترح إسقاط .env لصالح عامل عامل أكثر تحديدًا
مسار؟

إذا تخطينا المصدر التلقائي لـ .env ، فسيؤثر ذلك سلبًا على
سير عمل الفريق. نحن نعتمد على هذا الملف لأدوات أخرى. سننتهي
وضع أسرارنا في قسمين (.env وهذا الملف الآخر الذي تقترحه)
الأماكن إذا توقف عامل الميناء عن النظر إلى .env.

يوم الخميس ، 23 نوفمبر 2017 الساعة 1:15 صباحًا Tobias Munk [email protected]
كتب:

glensc https://github.com/glensc متفق عليه!

لكن بدلاً من ذلك ، أقترح docker-compose.override.env لمواءمتها مع
ميزة التجاوز الحالية لملفات yml.

عامل ميناء compose.env
عامل ميناء compose.override.env
عامل ميناء compose.override.yml
عامل ميناء compose.yml

لست متأكدا من اتباع الفقرة الثانية الخاصة بك. نحن نستخدم .env للأسرار و
حقنها يدويًا في docker-compose.yaml.

thedeeno https://github.com/thedeeno أفترض أنك تفعل هذا:

بيئة:

• {SECRET_VAR_FROM_DOTENV} دولار

والذي يجب أن يكون ممكنًا أيضًا مع docker-compose.override.env. او انت
يمكن أن تفعل:

env_file:

• .env

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

هل تقترح إسقاط .env لصالح عامل عامل أكثر تحديدًا
مسار؟

ليس بالضرورة ، بالنسبة إلى BC docker-compose لا يزال بإمكانه البحث عن .env إذا لم يتم العثور على الآخرين ، كما هو الحال مع fig.yml مرة واحدة. على الرغم من أنه قد يكون من الصعب تحديد الحالات التالية:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

لن يتم استخدام .env في الحالة الأخيرة ، لكني متردد في كيفية التعامل مع الحالة الأولى والثانية ، نظرًا لأن بعض المستخدمين سيستخدمون .env كتجاوز ، والبعض الآخر كإجراء احتياطي.

بالنسبة لي ، يجب استخدام .env في جميع الحالات. إنه ملف ذو معنى خاص
في النظام البيئي الأوسع.

في الحالات الثالثة ، يكون الملف ذا الأسبقية الأقل فقط.

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

إذا كان ملف التكوين خارج الطاولة وهناك طريقة لإلزام ملف
project_name مع هذه المتتالية التي تتناولها من حيث البيئة ، سأستخدمها بسعادة
على أية حال!

يوم الخميس ، 23 تشرين الثاني (نوفمبر) 2017 ، الساعة 1:31 صباحًا Tobias Munk [email protected]
كتب:

هل تقترح إسقاط .env لصالح عامل عامل أكثر تحديدًا
مسار؟

ليس بالضرورة ، بالنسبة لـ BC docker-compose لا يزال بإمكانه إلقاء نظرة على .env إذا كان
لم يتم العثور على الآخرين ، كما هو الحال مع fig.yml مرة واحدة. على الرغم من أنه قد يكون
من الصعب تحديد الحالات التالية:

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

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

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

لن يتم استخدام .env في الحالة الأخيرة ، لكني متردد في كيفية التعامل معها
إلى الأولين ، نظرًا لأن بعض المستخدمين قد يستخدمون .env كتجاوز ، والبعض الآخر كملف
تراجع.

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

بالنسبة للشبكة ، لست متأكدًا تمامًا من كيفية مقارنتها في ذهنك؟

@قصبة-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

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

أنا معجب بـ "4 project.rc" على الرغم من أنني ربما أستخدم شيئًا مثل docker-project.yaml بدلاً من تنسيق مختلف. هذا هو بالضبط ما يصفه الإصدار الأصلي. بقدر ما أشعر بالقلق ، فإن أي مناقشة حول وضع اسم المشروع في ملف الإنشاء يجب أن تكون في مشكلة منفصلة.

كل ما أحتاجه هو طريقة لإلزام اسم مشروعي بالتحكم في المصدر.

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

my_project_network_on_my_localhost خطأ بالنسبة لي. لماذا تحتاج اسم المشروع في شبكة خارجية؟ لا يلزم مطابقة اسم مشروع الإنشاء.

يبدو أن my_project_network_on_my_localhost خاطئ بالنسبة لي.

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

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

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

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

نظرًا لوجوده في مجلد في حالتنا ، يمكننا فعل شيء مثل

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

للاختبار ... أو هذا

(cd production && docker-compose logs -f --tail 100)

للإنتاج (المكافأة: يمكنك تحديد DOCKER_HOST للإشارة إلى آلة أخرى ، ولكن فقط بـ docker-compose ).

لكن نعم ، إنه مجلد ، وليس ملفًا - ويتطلب cp .env-dist .env في مكانين للعمل ، وإلا فإنه يفشل مع ملف إنشاء غير صالح. في الواقع ، أردت فقط مشاركة سير العمل الأنيق هذا IMHO.

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

dnephin هناك أسباب.

نعم هناك حلول. السؤال هو جعلها أكثر ملاءمة ويمكن التنبؤ بها.

إليك أحد الأمثلة حيث يساعد اسم المشروع ذي الترميز الثابت: إعدادات عامل الإرساء في traefik على إنشاء قواعد المضيف للحاويات بالتنسيق التالي: <service>.<project>.<domain> . هذا التنسيق ليس من السهل تغييره. من المفيد جدًا لمطورينا استخدام نفس Fqdns لخدمات إنشاء عامل الإرساء لدينا. سيكون من الرائع لو تمكنا من استخدام إعداد التكوين الصفري ، حيث أن الطريقة الوحيدة لضمان الاتساق هي إما: أ) إجبارهم على استخدام اسم دليل معين لنسخهم ب) تحديد قواعد traefik يدويًا. كلاهما تمتص.

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

رفاق ، الكثير من المناقشات ... ما هي حالة هذا ، هل يمكنني تعيين اسم المشروع الافتراضي في ملف .docker-compose ؟
أو لا تزال بحاجة إلى مزيد من المناقشات في هذا الموضوع؟

يعد تخزين اسم المشروع في ملف docker-compose.yml منطقيًا عند استخدامه مع أدوات أخرى ، مثل PyCharm.

سيكون من الرائع تخزينه في نفس ملف YAML ولكن ربما يتم تجاوزه إذا لزم الأمر.

أعتقد أن جوهر هذه المشكلة يأتي من حقيقة أن الاسم الافتراضي للمشروع هو ببساطة (هل يجب أن أقول _naively_؟) باعتباره الاسم الأساسي للدليل الحالي. يؤدي هذا إلى ضغط مساحة اسم نظام الملفات (الهرمية) بشكل فعال إلى مساحة مسطحة ، وهو ما يمثل مشكلة بسبب تعارض الأسماء. على سبيل المثال ، يتسبب هذا في حدوث مشكلات للأشخاص الذين يقومون بتشغيل الخدمات في ~/fooproject/master و ~/barproject/master .

أعتقد أن أسماء المشاريع غير مهمة. لذلك ربما تكون إحدى الطرق لجعل تكوين عامل الإرساء قويًا هي إنشاء قواعد أسماء المشروع على المسار الكامل (مثل home_flaviovs_fooproject_master )؟

ومع ذلك ، أنا أحب الفكرة المستمرة. لتكون قادرًا على ربط اسم المشروع بـ Git هي حالة استخدام شائعة. ربما تكون قراءة ملف .env.default قبل .env حلاً بسيطًا لهذا (أي من راجع للشغل سيهتم بالقيمة 210 # طويلة الأمد أيضًا)؟

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

من الواضح أنه يمكنك تمديد هذا ليكون لديك وظيفة لكل مشروع أو شيء ما. أعتقد أنه قد يكون هناك عيوب في ذلك لكني لم أجدها.

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

لدي مشكلة في تضارب الصور ، ويبدو غريبًا حقًا أنني لا أستطيع تعيين اسم_المشروع في عامل الإرساء-compose.yml لأنه يبدو منطقيًا للغاية وحل مضيق للأمام. في الواقع ، كان أخذ الاسم من مجلد المشروع في المقام الأول فكرة سيئة. في كثير من الحالات ، يمكن أن تكون مجلدات المشاريع مثل / home / project1 / repository و / home / project2 / repository وما إلى ذلك ، في هذه الحالة ، أنشأ عامل الإرساء أسماء الصور نفسها مثل repository_app.

vedmant يمكنك تعيين اسم الصورة في docker-compose.yml ، فقط استخدم image و build .

إذن ... ماذا عن الفصل بمشاريع في مجلد يحمل نفس الاسم الآن؟

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

ربما تم اقتراح هذا بالفعل. ولكن لماذا لا تقوم بإجراء تغيير فاصل في version: 4 وإضافة بعض الكلمات الرئيسية الجديدة للسماح بتعيين اسم المشروع من docker-compose.yml ؟

اسمي .docker-compose / project-name لم يعمل ...
- عمل اسم المشروع

أود تعيين اسم المشروع في docker-compose.yml أيضًا.

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

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

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

ومع ذلك ، تظهر المشكلة عندما لا أريد أن يعيش ملف yml الخاص بالمهمة المخصصة في نفس دليل المستوى الأعلى (أو حتى نفس الريبو) مثل docker-compose.yml . على سبيل المثال ، ربما أرغب في وضع المهمة المخصصة docker-compose.adhoc.yml في مجلد فرعي ، مع DOCKERFILE والأصول التي تحتاجها المهمة معزولة / مجمعة بشكل جيد معًا لأنها تهمها الخاصة. بمجرد أن أنقله إلى مجلد فرعي ، لم يعد اسم المشروع مطابقًا. هذا يعني أنه لم يعد بإمكانه الوصول إلى نفس الأحجام / الشبكات وما إلى ذلك المحددة في المشروع الرئيسي.

إذا كان بإمكاني تحديد projectname في docker-compose.yml و docker-compose.adhoc.yml - فحينئذٍ يمكنني هيكلها كما أريد (حتى وضعها في الريبو المنفصل) وما زلت أعمل عليها دون الحاجة إلى ذلك تحديد وسيطات سطر أوامر إضافية باستمرار أو تبديل متغيرات البيئة حولها.

هذه مشكلة حقيقية بالنسبة لي ، لأنها تسبب تعارضًا في التسمية

لدي عدة مشاريع في الهيكل

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

الآن عندما أبدأ إنشاء عامل ميناء في مشروع واحد ، فإنه ينشئ شبكة backend_default ويضع حاويات البادئات التي لم يتم تسميتها صراحة بـ backend_ .. الآن إذا أردت بدء المشروع الآخر ، فلدي للعودة إلى المجلد الصحيح وتشغيل docker-compose down لمنع التعارضات - وإلا ستبدأ حاويات جديدة في نفس الشبكة ، ثم عند إيقاف تشغيلها ، ستشتكي من الأيتام ، عندما لا يكون هناك أي تعارض.

أيضا مشكلة بالنسبة لي. لدي العديد من المشاريع ، وأستخدم docker-compose للحوامل التجريبية الديناميكية على جهاز واحد ، وحامل لكل فرع.

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

لذا فإن "الماجستير" و "المطورين" يتضاربون بين المشاريع. يمكن أن يحل ملف .docker-compose المشكلة.

simplesmiler لخطر تكرار نفسي ، .env يحل ذلك بالفعل.

@ shin- غالبًا ما يُستخدم .env للأسرار التي لا تخضع للتحكم في الإصدار.

ما يريده simplesmiler هو طريقة لإلزام اسم المشروع بالتحكم في الإصدار _ مع الاحتفاظ بـ .env خارج التحكم في الإصدار_.

بقدر ما أستطيع أن أقول لا توجد طريقة للقيام بذلك بسهولة.

thedeeno هذا ليس ما يقوله

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

أتمنى لو عملنا معًا حتى نتمكن من تناول بعض القهوة. آمل ألا تعتقد أنني أحمق هنا.

ربما أتذكر هذا الموضوع بشكل غير صحيح: هل هناك طريقة لإلزام اسم المشروع بالتحكم في الإصدار مع الاحتفاظ بتجاهل .env ؟

هل هناك طريقة لإلزام اسم المشروع بالتحكم في الإصدار مع الاحتفاظ بالتجاهل env. أم أن هذه لا تزال قدرة مفقودة؟

ليس حاليا. كما ذكرت قبل بضعة أشهر ^ 1 ، فإن الخطة تتمثل في الحصول على docker-compose.env كملف env ثانوي يمكن تضمينه في التحكم في الإصدار. لقد تراجعت إلى حد ما في قائمة الأولويات ولكن آمل أن أصل إليها قريبًا.

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

هذه أخبار رائعة! قبول العلاقات العامة؟

لقد فقدت الأمل منذ فترة طويلة ولكن دعونا نجربها مرة أخرى:

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

كما أفهمها ، فبالنسبة للبعض هنا يكسر إعداد مشروعهم. لكن بالنسبة للغالبية في هذا الموضوع لن يكون مشكلة. إذن كيف يمكن أن يفرض هؤلاء القلة هذا التقييد على جميع الآخرين الذين يفتقدون هذه الميزة؟ لماذا لا يكون لدينا عدة خيارات لكيفية تكوين الاسم ثم ترك القرار لنا؟

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

أعتقد أنه يمكن للمرء أن يقول ، (تقريبًا) جميع الإعدادات في docker-compose.yml يتم تحديدها حسب اسم المشروع .

كما هو مقترح في # 4841 ، يجب أن يكون خيار تحديد ملف .env المراد استخدامه (أي --env-file ) مفيدًا جدًا.

roipoussiere انظر https://github.com/docker/compose/issues/4841#issuecomment -414543951

شكرا @ schmunk42.
لكن هذا يعني أنه يجب علي إنشاء تسلسل هرمي مثل:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

بدلاً من شيء أسهل مثل:

.
├── a.env
├── b.env

نعم ، راجع أيضًا https://github.com/docker/compose/issues/745#issuecomment -345054893 - قد تحتاج إلى فتح ذلك في نافذة جديدة ، نظرًا لأنه مخفي هنا أحيانًا : nerd_face:

أنا ثانية عرض --env-file . صنع تذكرة فقط لذلك. اذهب واعجبك إذا كنت تريد هذا الخيار.

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

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

ولكن لنفترض أنك تعمل مع Stripe ، وهو ما يسمح لك بالحصول على مفاتيح الاختبار والمفاتيح الحية ، AKA. مجموعتان من المفاتيح للعمل معها. في التطوير ، سيكون من الشائع جدًا أن تستخدم مفاتيح الاختبار ، وفي الإنتاج سينتهي بك الأمر باستخدام المفاتيح الحية.

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

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

ولكن في الإنتاج ، تشير إلى كل من .env و .env.prod في ملف إنشاء الإنتاج.

لكن هل ترى إلى أين يتجه هذا؟ في الوقت الحالي ، لا يتيح لك Docker Compose الحصول على ملفات اختيارية env_file . إذا لم يكن الملف موجودًا ، فسينفجر Docker Compose بمجرد محاولة تشغيل Docker Compose.

لذلك تحتاج تلقائيًا إلى وجود ملف .env في النهاية إذا كنت تخطط لاستخدامه مع env_file وهذا لا يقتصر على Stripe أيضًا. تحتوي الكثير من أطر عمل الويب على إعدادات معينة خاصة بالبيئة ولكنها ستتغير في كل من التطوير والإنتاج (على سبيل المثال ، SERVER_NAME مع Flask).

وهذا يعني أننا مقيدون بامتلاك شيء مثل ملف .env_example تلتزم به في التحكم في الإصدار ومن المتوقع أن يعيد المستخدم تسمية هذا الملف إلى .env ، وبعد ذلك سيحتوي هذا الملف داخل صديقنا القديم COMPOSE_PROJECT_NAME .

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

هل هذه المسألة على بعض خارطة الطريق من فضلك؟

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

في حالتنا ، يمكننا نوعًا ما التغلب على قيود إنشاء عامل الإرساء هذا من خلال إنشاء COMPOSE_PROJECT_NAME في ملف makefile الخاص بنا.

أود أن أرى هذا قابل للتكوين من داخل yaml نفسها.

هل هذا لا يزال مفتوحا؟ يا إلهي...

مشترك. أريد أيضًا أن أكون قادرًا على تعيين اسم المشروع في ملف إنشاء yaml.

هذا يستغرق إلى الأبد 🤦‍♂

سيكون من المفيد جدًا الحصول على هذه الميزة

ستكون هذه الميزة موضع ترحيب كبير في المشروع الذي أعمل عليه

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

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

أود إضافة متغير ENV إلى قائمة البدائل هذه.

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

إن امتلاكه ENV بدلاً من محتوى yaml يتعارض مع فلسفة مشاركة ملفات yaml بين المشاريع المختلفة. في الواقع ، تم توثيقه رسميًا: https://docs.docker.com/compose/extends/ (انظر "أمثلة على حالات الاستخدام" على سبيل المثال). إذا كنت تستخدم ملف yaml أساسيًا واحدًا ، ثم تجاوزت الملفات من أجل dev ، والاختبار ، والإنتاج ، والله يعلم ماذا أيضًا ، فلا معنى لتشغيله تحت اسم المشروع نفسه أو تعيين اسم المشروع بواسطة ENV / cli. سيقوم فقط بإنشاء مجموعات N * N بينما تكون على N صالحة.

لقد اجتزت العديد من هذه المناقشات وشاهدت عددًا كبيرًا من التعليقات من الأشخاص الذين يريدون أن يكون اسم المشروع قابلاً للتكوين في ملف YML. لكن لا يوجد تعليق واحد يشرح سبب عدم القيام بذلك. تعود هذه المناقشات شوط طويل.

كشخص يبحث عن حل سهل الاستخدام ويكتشف أنه لا توجد طريقة سهلة لتعيين اسم المشروع الذي لا يتطلب اهتمامًا دقيقًا من المستخدم بتنفيذ سطر الأوامر (الذي يتنافس مع الفكرة الأساسية للأداة التي تستخدمها مرر up وابدأ بطريقة سحرية مجموعة كاملة من الخوادم) - لقد صدمت أن هذا سؤال مفتوح. إذا كان هناك تفسير واضح لسبب إشكالية أو يتعلق بالتنفيذ ، سأكون مهتمًا.

قد يكون الحل الأنيق هو استخدام عنصر نائب في الخاصية container_name (وتسمية ديناميكية أخرى مثل وحدة التخزين والشبكة ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

مع هذا التكوين ، يمكن للمرء أن يستخدم

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

تحرير: هذا ليس حلاً مثاليًا ، لأنه سيتعارض مع الأشخاص الذين يستخدمون مشروعين مميزين في نفس اسم المجلد

تضمين التغريدة

قد يكون الحل الأنيق هو استخدام عنصر نائب في الخاصية container_name (وتسمية ديناميكية أخرى مثل وحدة التخزين والشبكة ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

مع هذا التكوين ، يمكن للمرء أن يستخدم

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

تحرير: هذا ليس حلاً مثاليًا ، لأنه سيتعارض مع الأشخاص الذين يستخدمون مشروعين مميزين في نفس اسم المجلد

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

في هذه المرحلة ، أريد حقًا فقط فهم سبب رفض المشرفين للحلول. يوجد بالفعل طلب سحب لحل.

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

لدينا هذه التعليقات 2:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

لكن يجب أن أعترف حتى بقراءة تلك التعليقات ، فأنا لا أفهم تمامًا لماذا لا تضيف اسم_المشروع إلى ملف yaml. بالنسبة لأولئك الذين يعتقدون أنه يجعل ملفات docker-compose.yaml الخاصة بهم أقل عمومية ، يجب ألا يضعوا الاسم في ملف yaml بعد ذلك ، ولكن من فضلك دع بقيتنا لديهم خيار للقيام بذلك.

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

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

(1) قد تؤدي إضافة اسم المشروع إلى ملف YML إلى جعل المشروع أقل قابلية لإعادة الاستخدام لأنه سيمنع ، أو على الأقل يعقد ، تشغيل ملف YML بأكثر من اسم مشروع واحد.
(2) "ستعاني جودة المشروع كثيرًا نتيجة لإضافته (بهذا الشكل)"
(3) "إذا كان اسم المشروع موجودًا في ملف الإنشاء ، فيمكن لأي مشروعين استخدام نفس الاسم ، مما يتسبب في حدوث تعارض قد يؤدي إلى تعطيل كلا المشروعين."

لدي أفكار حول هذه الأمور ، لكنني سأمتنع بالتعليقات حتى نتمكن من الاتفاق على المخاوف التي يجب معالجتها. هل هذا معقول؟

(4) التنفيذ بطريقة متوافقة مع الإصدارات السابقة (الأسبقية / ترتيب القيم)

(1) قد تؤدي إضافة اسم المشروع إلى ملف YML إلى جعل المشروع أقل قابلية لإعادة الاستخدام لأنه سيمنع ، أو على الأقل يعقد ، تشغيل ملف YML بأكثر من اسم مشروع واحد.

مرة أخرى ، هناك طريقة رسمية لتقسيم التكوين إلى قاعدة وملف وموروث - https://docs.docker.com/compose/extends/. تعذر على المرء إعداد اسم المشروع في التكوين الأساسي.

بالنسبة لي ، حالة الاستخدام الأساسية التي أبحث عنها هي القدرة على تشغيل مثيلات متعددة من المشروع محليًا (مطور ، بيئات اختبار ، إلخ).

ربما يكون الحل هو السماح لك إما بتعيين اسم المشروع بشكل صريح أو مسار اجتياز.

إذا قمت بتعيين اسم المشروع في ملف yaml بشكل صريح مثل my-project فيمكن حينئذٍ تبسيط الأمور لمثيل واحد من المشروع أو حيث أفعل شيئًا مثل إضافة جميع ملفات عامل الإرساء في مجلد docker عبر مشاريع متعددة.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

لكن هذا لا يساعد في حالات متعددة من نفس المشروع ، فكيف تفعل شيئًا مع اجتياز المسار

project_name: ../(*) لذلك بنفس المثال

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

بالمثل project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

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

نصف مزاح فقط: هذا يعني تكوين اسم ثابت في docker-compose.yml الخاص بي ، سأقوم بإنشاء ملف بالاسم الذي أريده ، ثم قم بتعيين project_name: name-of-the-file-named-like-the-name-i-want ؟

لدي حاليًا تحميل ملفات docker-compose في نفس الدليل. مثل dc-work.yml ، dc-server.yml ، وما إلى ذلك ، كل ذلك يقوم بتحميل خدمات مختلفة غير ذات صلة.

عندما أقوم بتشغيل docker-compose up dc-A.yml ، ثم تشغيل docker-compose up dc-B.yml ، فإن Docker يشير إلي أن هناك خدمات اليتيمة قيد التشغيل (بالطبع لا توجد ، هذا بسبب اسم المشروع الملعون).

هل حقا لا توجد طريقة لحل هذا؟ يبدو أن نقل كل ملف dc-A|B|C|etc.yml إلى الدليل الخاص به ، ثم الانتقال إلى كل ملف لتحميل جميع خدماتي ، بمثابة إهدار حقيقي للوقت ، أو هل فاتني شيء ما؟

لماذا لم تتم معالجة هذه المشكلة؟ تم تقديم الحل الواضح والمباشر بواسطة @ cr7pt0gr4ph7 هنا: https://github.com/docker/compose/issues/745#issuecomment -182296139. حصلت على الكثير من الأصوات. تم تناول كل المخاوف في المناقشة. والأهم من ذلك ، أنه يحل الكثير من المشكلات لكثير من الناس. ما يعطي؟

نواجه هذه المشكلة أيضًا لأننا نستخدم بنية دليل مشروع ثابتة مع مجلد .docker الذي يحتوي على جميع العناصر المتعلقة بـ docker ، لذلك انتهى بي الأمر مع الكثير من أسماء مشاريع docker. لذلك من الطبيعي أن يكون لديك عدة مرات ... لكن هذا الشيء الصغير الصغير ، يستمر في الوقوف في الطريق -> أيضًا ، PHPStorm وما إلى ذلك ليس لديه خيار تمرير وسيطة -p / - project-dir ولا يمكنني استخدم بالفعل a .env لهذا لأنه ، صدقوني ، سيتم نسيان تحديد القيمة الصحيحة ...

المطورين ، يرجى إخبارنا كيف تريد أن يتم حلها.

ربما تضيف خاصية إلى ملف docker-compose لتعيين اسم المشروع؟

تضمين التغريدة

المطورين ، يرجى إخبارنا كيف تريد أن يتم حلها.

هذا هو أفضل ملخص:
https://github.com/docker/compose/issues/745#issuecomment -182296139

كان هناك الكثير من النقاش. ليست هناك حاجة لمزيد من المناقشة. يحتاج القائمون على صيانة المشروع فقط إلى قراءة المواضيع (الجمع) والقيام بما يلزم.

بالنسبة لي لا يزال هذا: https://github.com/docker/compose/issues/745#issuecomment -248644429

بالنسبة لي لا يزال هذا: # 745 (تعليق)

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

Tbh ، إنها نقطة خلافية. انتقل الكثير منا إلى Kubernetes مقابل وظائف من النوع docker-compose . انها مطولة قليلا. ولكنه يعمل ويدعمه بائعو السحابة جيدًا.

تضمين التغريدة
نريد استخدام آلية لتعيين اسم المشروع كما هو موضح هنا: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. سطر الأوامر
2. متغير البيئة (ملف env.)
3. في إنشاء ملف مباشرة
4. مسار الملف

لا أعتقد أن هناك أي اعتراض على هذا.

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

إذا كان سير عملك يعتمد على مسار المجلد وبطريقة ما يتم إدخال project-name في التكوين الخاص بك ، على سبيل المثال. من خلال الدمج ، إنشاء ملفات متعددة ، قوالب ، ... - ستنتهي بنفس المشكلة - الكتابة فوق الحزم الموجودة.

آسف لقول هذا ، ولكن يجب إغلاق هذا كـ wontfix .. (تحرير) أو إصدار إصدار MAJOR (!) جديد

ههههههههههه

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

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

1. ماذا لو تم تنزيل ملف الإنشاء من git repo ، ثم في التنفيذ التالي ، ينقله مالك الريبو إلى مجلد فرعي مختلف؟ أو إعادة تسمية المجلد الموجود فيه؟ التأثير على سير العمل موجود بالفعل حيث يمكن نقل الملفات وهذا يؤثر على اسم المشروع.
2. إذا كنت تعتمد على اسم مشروع معين ، فقد اقترحنا آلية لضمان ذلك ، إما عن طريق استخدام متغير البيئة (ملف .env) أو باستخدام وسيط سطر الأوامر عند تنفيذ Docker compose - وكلاهما سيتجاوز أي قيمة حدثت في ملف الإنشاء (إذا تمت إضافته لسبب ما).

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

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

مشكلتي الرئيسية مع حل ملف .env هي أن هذا الملف يجب أن يكون في مسار العمل الخاص بتشغيل الأمر - بينما يحل docker-compose ملف الإنشاء إلى دليل رئيسي. لذلك ، يصبح من الضروري أن يقوم جميع المطورين إما (أ) بفحص الكود في المجلد الذي يحمل نفس الاسم (بافتراض وجود ملف docker-compose.yml في جذر إعادة تعيين التعليمات البرمجية) أو (B) تشغيل أوامر docker-compose فقط في يُنشئ المجلد الجذر في الريبو مكدسات متضاربة أو (C) لديهم أسماء مكدس مختلفة ويجب أن تقول جميع الوثائق والبرامج النصية replace stack name here .

إذا كان (C) هو ما يقترحه عامل الإرساء باعتباره الحل "المحمول" الموصى به ، فيجب أن يكون Docker-compose CLI مكتمل الميزات بأوامر Docker CLI ، وحتى ذلك الحين ، ما زلت أرى حالة استخدام لهذه الميزة.

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

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

لا أصدق أنه عام 2020 وما زلنا لم نصلح حالة الاستخدام الضخمة هذه. هذا ليس تغييرًا جذريًا ، فهو ميزة اختيارية تمامًا ومن المنطقي تمامًا. نظرًا لأن Kubernetes هي الآن أداة النشر الفعلية لـ docker ، أتخيل أن docker-compose لرؤية الاستخدام في عمليات التطوير / النشر المحلي وامتلاك ملف docker-compose في جذر المستودع لتشغيل الكود في المستودع محليًا هو أمر شائع جدًا حالة الاستخدام.

كتب @ dc-pm: "نظرًا لأن Kubernetes هي الآن أداة النشر الفعلية لعمال الإرساء"

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

والحق يقال ، حتى التعامل مع الحاويات في بيئة التطوير الخاصة بي هو الكثير من المتاعب اليومية. أنا فقط أدير البرامج ...

كتب @ dc-pm:

لا أصدق أنه عام 2020 وما زلنا لم نصلح حالة الاستخدام الضخمة هذه.

لا يقتصر الأمر على أنه لم يتم إصلاحه فحسب ، بل إن المطورين يرفضون بشدة إصلاحه.

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

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

اللوم ليس هو الحل.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

من الصعب جدًا إجراء تغيير عندما يعارضه المطورون ...

السبت، 14 مارس 2020 الساعة 03:19 انطوان Gravelot [email protected]
كتب:

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

اللوم ليس هو الحل.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/745#issuecomment-598991880 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
.

agravelot أعتقد أنه كان هناك بعض العلاقات العامة ، قد لا تكون مثالية. ولكن من خلال جميع أصحاب المناقشات لديهم توقعات محددة بوضوح شديد أنهم لا يريدون هذه الميزة. إنها ليست مسألة ترميز.

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

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

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

ما هي الطريقة الأكثر إيجابية للمضي قدمًا؟

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

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

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

لذلك أركض:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

لاحظ كيف تقول "Recreating database-dev" بينما أنا أشير بوضوح إلى الخدمة الموجودة في مشروع "prod". في الواقع يقوم بالكتابة فوق الحاوية الموجودة. يتم إنهاء قاعدة البيانات ويتم استبدال الحاوية بالأخير.

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

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

الكثير لنشر قيادة واحدة ، يا لها من مزحة مطلقة. في رأيي ، يعد .yml مكانًا رائعًا لتحديد اسم المشروع في هذا السياق.

بدلاً من ذلك ، تمكنت من وضع الخدمات في مشروع واحد - من خلال إعطائها أسماء مختلفة: "database-dev" و "database-prod". المشكلة الوحيدة في هذا النهج هي أن هناك تحذيرًا بشأن تحول الخدمة التي تم إنشاء مثيل لها سابقًا إلى يتيمة لأنها غير مذكورة في docker-compose.yml.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

هذا لا معنى له ، لماذا يجب أن يكون على هذا النحو. لماذا يجب أن يكون الأمر كذلك في الواقع؟

EDIT1: @ dc-pm @ CharlesReitzel ما رأيك؟ هل يمكنك إبداء أي تعليق على حالة الاستخدام الخاصة بي ، فقط في حالة ما إذا كانت غير صالحة :)
EDIT2: لقد وضعت كل من ملفات الإنشاء في دلائل منفصلة وفويلا

سوو؟

الصيانة ، أي شخص هنا؟
المطورين ينتظرون لمدة 6 سنوات!

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