كنت أبحث في هذا فقط

الاستعمال: بناء عامل بناء [خيارات] مسار | URL | -

لذلك إذا قمت بتشغيل

عامل بناء عامل بناء - t my / thing my-dockerfile

يشكو من أن ملف القطران قصير جدًا.

يبدو لي أن خيار "PATH" لم يتم التخلص منه ، لذلك قد يكون له بعض المعنى القديم؟

لذلك - أتساءل عما إذا كان الكشف عن PATH هو ملف ، وليس Tarfile.

شخصيًا ، لدي مجموعة من ملفات Dockerfiles التي أستخدمها للاختبار ، وأفضّل وضعها جميعًا في دليل واحد ولديها أيضًا سياق كامل.

يشير هذا المسار إلى دليل ، وليس ملف Dockerfile محدد.

أوه ، ثم Tars هذا الدليل لإرساله إلى الخادم - رائع!

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

أو استخدام -f بنفس الطريقة - السماح لتعريفات Dockerfile الخاصة بك بالعيش بشكل منفصل عن الحمولة

الآن لمعرفة كيفية عمل الاختبارات ، جربها ومعرفة ما إذا كانت تعمل بالنسبة لي

لا يفسد أي شيء - المسار هو دليل يفترض فيه وجود Dockerfile

هذا ليس كل ما يفعله مع هذا المسار - قراءة الكود ، يتم إرسال "السياق" إلى الخادم عن طريق تحديد الدليل.

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

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

آه ، أرى ما تقوله - نعم - هذا بالضبط ما أريده - طريقة لتحديد ملف عامل إرساء بـ -f ، ثم الدليل PATH الذي قد يكون منفصلاً.

لذلك يمكنني الحصول على:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108 (إضافة توجيه التضمين إلى Dockerfiles) يضيف تجعدًا مثيرًا للاهتمام

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

مرح:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

كمكافأة إضافية - لا توجد اختبارات CmdBuild حتى الآن ، لذا خمن ما يمكنني تعلمه في البداية :)

SvenDowideit هل تعمل على هذا؟ كنت أفكر ربما في اختراقها اليوم

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

سأفعل :)

أود أن أرى هذه الوظيفة أيضًا. لدينا نظام يمكن تشغيله في 3 أوضاع مختلفة ونود نشر 3 حاويات مختلفة - 1 لكل وضع. هذا يعني 3 ملفات عامل إرساء متطابقة تقريبًا مع اختلاف CMD فقط. ولكن نظرًا لأن المسارات هي أدلة فقط ، وأن الدلائل هي سياق أوامر ADD ، فلا يمكنني جعل هذا يعمل الآن.

إذن: +1 مني!

يبدو أن هذا قد يكون له نفس الهدف النهائي مثل # 1618 (على الرغم من اختلاف الأساليب). تكمن الفكرة في استخدام Dockerfile واحد مع عدة تعليمات TAG ينتج عنها صور متعددة ، مقابل Dockerfiles متعددة ونظام تضمين كما هو موضح هنا. أفكار؟

يبدو كما لو كان بإمكانك توجيه ملف Dockerfile ، يجب أن تكون قادرًا على تحديد المسار أيضًا. مهتم بمعرفة ما يأتي من # 1618 ولكن أعتقد أن هذا يوفر العديد من الاحتمالات.

هذا هو المكان الذي أتواجد فيه: https://github.com/peterbraden/docker/compare/2112-specify-dockerfile؟

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

أتلقى نفس الخطأ ، أي أفكار

عامل بناء Dockerfile

تحميل السياق

2013/12/11 21:52:32 خطأ: خطأ في إنشاء: Tarball قصير جدًا

bscott جرب docker build . بدلاً من ذلك. يأخذ Build دليلاً وليس ملفًا ، وهذا هو "سياق البناء". :)

Worked Thx !، أود فقط الاختيار بين ملفات Docker المختلفة.

+1 مني.

أحتاج إلى إنشاء صور متعددة من مصدري. كل صورة هي مصدر قلق منفصل يحتاج إلى نفس السياق ليتم بناؤه. يعد تلويث ملف Dockerfile واحد (كما هو مقترح في # 1618) أمرًا متزعزعًا. انها تريد ان تكون أنظف بكثير بالنسبة لي للحفاظ على 3 منفصلة <image-name>.docker الملفات في مصدر بلدي.

أود أن أرى شيئًا كهذا مطبقًا.

هذا أكثر صعوبة في التنفيذ مما قد يبدو للوهلة الأولى. يبدو أن ./Dockerfile مخبوز تمامًا. بعد التحقيق الأولي على الأقل هذه الملفات متضمنة:

api/client.go
archive/archive.go
buildfile.go
server.go

يستخدم client archive لترابط build context وإرساله إلى server الذي يستخدم بعد ذلك archive إلى build context وسلم البايت إلى buildfile .

يبدو أن أسهل تطبيق قد يتضمن تغيير client و archive لاستبدال القطران ./Dockerfile بالملف المحدد عبر هذا الخيار. سأحقق أكثر.

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

+1 مني!

لقد كنت أتابع كلاً من # 1618 و # 2112 وهذا هو الحل الأكثر أناقة.

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

+1 كبديل عن # 2745.

+1

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

+1
أنا أقدر هذا التغيير

+1
حقا بحاجة الى هذا.

يجب أن يسمح 5033 بهذه الميزة. cc / @ crosbymichael

shykes ما رأيك في هذا التغيير؟ لا أعتقد أنك وافقت أو ربما تعرف حلاً أفضل لحل نفس المشكلة.

انا متردد.

من ناحية أخرى ، لا أريد تقييد قدرة الأشخاص على تخصيص تصميمهم.

من ناحية أخرى ، أخشى أن يحدث نفس الشيء كما هو الحال مع _run -v / host: / container_ و _expose 80: 80_. بعبارة أخرى ، سيسمح لـ 1٪ ممن يعرفون ما يفعلونه بإضافة تخصيص رائع - و 99٪ الآخرون يطلقون النار على قدمهم بشكل سيء للغاية.

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

لذا فإن سؤالي هو: ألا نجازف بوجود الكثير من مستودعات المصادر التي لا يمكن بناؤها بشكل متكرر باستخدام docker build

shykes أواجه المشكلة التي تصفها بسبب _ بسبب قيود ملف Dockerfile هذا. فيما يلي حالتان من حالات الاستخدام:

1. لدي بيئة بناء قائمة على Docker تنتج عنصرًا (ملف JAR في هذه الحالة). تختلف بيئة الإنشاء عن بيئة التشغيل (تبعيات مختلفة ، وصورة أكبر ، وما إلى ذلك ، لذلك لا أريد أن أرث بيئة الإنشاء في وقت التشغيل. من المنطقي جدًا أن يكون لديّ بناء Dockerfile وتشغيل بيئة وقت التشغيل حول JAR. لذلك لديّ ملف Dockerfile.build منفصل يقوم ببناء بيئة الإنشاء وتشغيلها وإنشاء JAR. ولكن نظرًا لعدم تمكني من تحديد ملف Dockerfile ، كان عليّ إنشاء ملف scripts/build ملف يقوم بعمل docker build < Dockerfile.build ثم يقوم بتركيب حجم المضيف مع docker run -v ... لتشغيل الإصدار (حيث لا يمكنني استخدام ADD w / piped-in Dockerfiles). ماذا أود أن أفعل بدلاً من ذلك هو أن أكون قادرًا على تشغيل docker build -t foobar/builder -f Dockerfile.build ، docker run foobar/builder ، docker build -t foobar/runtime ، docker run foobar/runtime واستخدام أوامر ADD في كل من Dockerfiles.
2. باستخدام تعليمات ONBUILD ، أود أن أكون قادرًا على وضع Dockerfiles في أدلة فرعية (أو أن يكون لديك ملفات Dockerfile.env ، إلخ في الجذر) التي تحتوي على Dockerfile الجذر في تعليمات FROM الخاصة بهم ، ولكن لا يزال بإمكانك استخدام جذر المشروع مثل سياق بنائهم. هذا مفيد ، على سبيل المثال ، في إدخال معلمات التكوين لبيئات مختلفة. سيظل ملف Dockerfile الجذر ينتج حاوية مفيدة ، لكن الآخرين سيخلقون متغيرات مختلفة نحتاجها.

لذلك أعتقد أن الشيء الذي أوده حقًا هو أن أكون قادرًا على فصل مفاهيم "بناء السياق" عن "موقع / اسم ملف Dockerfile." هناك الكثير من الطرق المحتملة للقيام بذلك ، بالطبع ، لكن هذا يبدو وكأنه طريقة مباشرة نسبيًا بالنسبة لي.

@ cap10morgan هل من الممكن أن

shykes https://github.com/shykes ليس هذا حلم قابلية النقل بالضبط
ما هو فهرس الصور ل؟ لماذا يجب أن تكون بيئات البناء
محمول كذلك؟

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

هذا يؤثر حقًا على فريقنا. في الإعداد لدينا نرغب في إنتاج عدة
صور من نفس "السياق". من خلال إضافة خيار --file يمكننا القيام به
ما نريد فعله حقًا - وهو إضافة foo.docker و bar.docker
في جذر المستودع الخاص بنا. بدلاً من ذلك ، ينتهي بنا الأمر بكتابة نصوص bash لنسخها
أطنان من الملفات في مواقع مؤقتة لإنشاء سياق ، وإعادة تسمية
اسمه ملفات عامل ميناء في السحر Dockerfile فقط هكذا docker build يمكن
الشغل.

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

يوم الإثنين ، 7 أبريل 2014 ، الساعة 4:23 مساءً ، كتب Solomon Hykes [email protected] :

@ cap10morgan https://github.com/cap10morgan أي فرصة يمكن أن تشير
أنا لمثالك 1 ، أو أي شيء يقترب منه؟ لذا يمكنني اللعب
حولها وتأكد من أننا نتحدث عن نفس الشيء.

قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/2112#issuecomment -39778691
.

shykes نظرًا لأن هذا يبدو أنه "يتعذر إصلاحه" ، فهل يمكنك الإشارة إلى المستندات أو شرح طريقة Docker المعتمدة للتعامل مع هذه المشكلة؟

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

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

+1 عند الحاجة إلى ذلك أيضًا - لدينا قاعدة رمز واحدة مع العديد من الخدمات الصغيرة التي يتم تطويرها هناك. نود أن نكون قادرين على إنشاء صور متعددة ، على سبيل المثال ، صورة واحدة تحتوي على services / base / * و services / fooservice / * ؛ وصورة أخرى تحتوي على الخدمات / القاعدة / * والخدمات / البارات / * وكذلك الملفات الثابتة / *.
لا يمكننا وضع Dockerfiles داخل مجلد الخدمة لأن Docker يتعامل مع هذا المجلد كسياق بعد ذلك ولا يمكننا إضافة أي شيء أعلى في بنية المجلد. لا يمكننا وضع ملفين Dockerfiles في الجذر لأنهما سيكون لهما نفس الاسم.
الحل الوحيد الذي لدينا هو وضع Dockerfile في مجلد الخدمة ثم كتابة برنامج نصي مخصص لتحليل ملف Dockerfile المحدد ، وتحديد المسارات التي سيرغب في إضافتها (جميعها محددة بالنسبة إلى جذر المشروع) ، ثم نسخها إلى ملف جديد المجلد المؤقت ، انسخ ملف Dockerfile المحدد إلى جذر هذا المجلد الجديد وأخيراً قم بتشغيل "docker build tempfolder". هل ذلك ضروري؟
كان من الممكن أن يكون الأمر أكثر بساطة إذا كان بإمكانك ببساطة إخبار "بناء عامل الإرساء" بشكل منفصل أين يوجد Dockerfile وأين هو السياق.

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

+1 ، الترميز حول هذا القيد يمثل ألمًا كبيرًا.

+1 لعلامة -f التي تحدد مسار Dockerfile منفصلًا عن سياق الإنشاء

يعد Docker أداة رائعة ، لكن هذا الاقتران الضيق للسياق وملف Dockerfile المحدد يلوث بالتأكيد فريق Docker قليلاً. لا تعكس بنية الدليل دائمًا بنية "الحاوية / النظام الفرعي" تمامًا.

ما مدى صعوبة الإصلاح؟ وكان هناك عدد قليل من العلاقات العامة لهذا ، لكن تم تجاهلهم.

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

قد يقودني هذا في الواقع إلى تخطي Docker في الوقت الحالي ، والعودة إلى Vagrant + Ansible. لطيف - جيد.

davber .dockerignore في -> # 6579

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

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

/ سم مكعبshykescreackcrosbymichaelvieux

+1 لعلم -f. أيضا متغير بيئة DOCKERFILE لتجاوز إعدادات البناء.

jakehow نعم هناك بالتأكيد عنصر من

ولكن في هذه الحالة ، كانت هناك إجابة واضحة عن السبب في أنه من الأفضل الاحتفاظ بالتعيين 1-1 لملف Dockerfile ودليل المصدر. سأكررها مرة أخرى: نريد الحفاظ على خاصية الوصف الذاتي لبنى عامل الميناء. حقيقة أنه يمكنك الإشارة إلى دليل التعليمات البرمجية المصدر ، _ مع عدم وجود معلومات أخرى خارج النطاق _ ، وإنشاء صورة منه وفقًا لمواصفات مطور المنبع ، يعد أمرًا قويًا للغاية ومميزًا رئيسيًا لـ Docker.

من المؤكد أن القدرة على دمج الدليل X ديناميكيًا مع Dockerfile Y on-the-fly مريحة إلى حد ما (على الرغم من أنني لم أشعر أبدًا بالحاجة الملحة لذلك ، وأنا أستخدم Docker كثيرًا). لكنه يجعل من السهل جدًا القيام بشيء غبي - أي كسر طبيعة الوصف الذاتي للبناء الخاص بك. وهذا يبدو وكأنه مقايضة سيئة للغاية. ومن هنا جاء قرار عدم تنفيذ هذه الميزة.

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

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

davber كان لدي انطباع بأن Vagrant لديه نفس التقييد لملف وصف واحد لكل مشروع (على الأرجح لأسباب مماثلة). كيف ستؤدي العودة إلى Vagrant إلى حل مشكلتك بالضبط؟

gabrtv هل تريد محاولة إعادة الصور المتعددة مرة أخرى؟ إليك اقتراح مبدئي:

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

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

shykes لا أعتقد أنني أشتري أن زيادة تعقيد تنسيق Dockerfile هي مقايضة جديرة بالاهتمام للاحتفاظ بملف Dockerfile واحد.

خذ على سبيل المثال ملفات makefiles - من الشائع أن يكون لدى المشروع "Makefile" ولكن يسمح لك أيضًا بتحديد ملف makefile مختلف باستخدام "-f".

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

أنت تقول "لذا سؤالي هو: ألا نجازف بوجود الكثير من مستودعات المصادر التي لا يمكن بناؤها بشكل متكرر باستخدام Docker build ،"

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

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

حسب فهمي ، تكمن المشكلة هنا في حقيقة أنه عندما
الأنابيب في Dockerfile (cat Dockerfile | بناء عامل الإرساء -) نفقد العمل
دليل ADD و CP.

سيتم حل المشكلة عن طريق إضافة علامة لبناء عامل ميناء يسمح لنا بذلك
تحديد مكان وجود محتويات المجلد المصدر؟

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

في هذا الاقتراح ، تحدد علامة --cwd المجلد الأساسي لـ ADD و CP
أوامر.

2014-06-29 19:42 GMT + 10: 00 Peter Braden [email protected] :

أنت تقول "إذن سؤالي هو: ألا نجازف بوجود الكثير من المصادر
المستودعات التي لا يمكن بناؤها بشكل متكرر مع بناء عامل الإرساء ، "

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

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

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

llonchj في الواقع https://github.com/dotcloud/docker/pull/5715 يحل ذلك (بطريقة ما) وهذا مدمج بالفعل للإتقان.

shykes منفتح بالتأكيد على

تعليق ل

سيكون من الجيد أن تكون قادرًا على تحديد [تم تنقيح الأمر] حتى أتمكن من إضافة ملفات ، ولدي أيضًا عدة ملفات dockerfiles.

لكل @ cap10morgan ...

لذلك أعتقد أن الشيء الذي أوده حقًا هو أن أكون قادرًا على فصل مفاهيم "بناء السياق" عن "موقع / اسم ملف Dockerfile."

أليس هذا بالضبط ما يفعله # 5715؟ كما أفهمها:

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

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

gabrtv يبدو لي أن # 5715 لا يتناسب مع معايير tar -C subfolder -c . | docker build -t gabrtv/myotherimage - هو ، بالنسبة لي ، غير واضح للغاية.

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

أنا شخصياً أحب الاقتراح الأخير المقدم من

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

rattrayalex صدقوني ، أنا أتفق مع هدف "وجود أمر واحد يعمل دائمًا". هناك فرصة جيدة أن ينتهي بي الأمر بكتابة الكود وتقديم العلاقات العامة. :غمزة:

وجهة نظري هي من وجهة نظر منظمة المشروع ، يجب أن نجري هذه المناقشة في مكان آخر بدلاً من قضية مطولة بعنوان Allow specifying of a dockerfile as a path, not piping in :

1. معظم المناقشة هنا غير مرتبطة بمقترح shykes الجديد في https://github.com/dotcloud/docker/issues/2112#issuecomment -47448314
2. تتم معالجة المشكلة الأساسية الأصلية (فصل سياق الإنشاء عن Dockerfile) بواسطة # 5715 ، على الرغم من أنها ربما لا ترضي الجميع

alonchj ...

حسب فهمي ، تكمن المشكلة هنا في حقيقة أنه عند توصيل ملف Dockerfile (cat Dockerfile | docker build -) نفقد دليل العمل لـ ADD و CP.

بعبارة أخرى ، إذا كنت موافقًا على docker build -t <image> -f <path-to-dockerfile> ، يمكنك استخدام tar -C <path-to-context> -c . | docker build -t <image> - كحل بديل وظيفيًا حتى نتمكن من وضع العلاقات العامة معًا لاقتراح shykes .

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

شكرًا لكل من شارك في هذه القضية اليوم:

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

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

يبدو الاقتراح المقدم من تعليق shykes كحل بالنسبة لي ، فهل كان هناك عمل سابق تم إنجازه في مكان ما يمكن التقاطه أو النظر إليه كمرجع؟

لن يكون "Dockerfile.frontend-prod" أفضل بحيث تكون جميع ملفات Dockerfiles
في دليل فرز بشكل طبيعي معا؟

آسف ، ولكن هذا مجرد سخيف. إذا كان الريبو الخاص بي يبني 100 خدمة ، فأنا بالتأكيد لا أرغب في الحصول على 100 Dockerfiles في الجذر. (مثال: dotCloud PAAS repo.)

لا أريد ملف Dockerfile واحد ضخم يحتوي على 100 قسم ، ولا.

أريد 100 ملف Dockerfiles ، وأريدهم في دلائل منفصلة.

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

مرة أخرى ، لا أفهم لماذا يعد وجود علامة إضافية لتحديد المسار إلى Dockerfile (الافتراضي إلى Dockerfile ) أمرًا مهمًا؟

بالإضافة إلى ذلك ، فإن الاقتراح الحالي ( <imagename>.Dockerfile ) لا يتم تعيينه على الإطلاق مع التصميم الحالي لـ Automated Builds. إذا تم اختراق إعادة شراء واحدة على أي من أنظمة البناء الخاصة بي ، فيمكن للمهاجم زيادة تحميل جميع عمليات إعادة الشراء الخاصة بي ...؟

jpetazzo مثل معظم الناس

_مرة أخرى ، لا أفهم لماذا يعد وجود علامة إضافية لتحديد المسار إلى Dockerfile (الافتراضي لملف Dockerfile فقط) أمرًا بالغ الأهمية؟ _

لقد قدمت حجة محددة أعلاه. لا تتردد في قراءتها وتقديم حجة مضادة.

إعادة: الفوضى. gabrtv كان لديه نفس القلق على IRC. بعد بعض النقاش توصلنا إلى هذا البديل:

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

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

بالإضافة إلى ذلك ، فإن الاقتراح الحالي (.Dockerfile) على الإطلاق مع التصميم الحالي لـ Automated Builds. إذا تم اختراق إعادة شراء واحدة على أي من أنظمة البناء الخاصة بي ، فيمكن للمهاجم زيادة تحميل جميع عمليات إعادة الشراء الخاصة بي ...؟

حسنًا ، كيف تم تسميتهم الآن؟ إذا كان لديك ريبو باسم "abc" مع Dockerfile عادي فقط ، فسيكون من المنطقي أن تكون الصورة التي تم إنشاؤها بواسطة ذلك تسمى "abc". إذا كان لديك repo "xyz" مع "Dockerfile.abc" و "Dockerfile.zzz" فيه ، فسيكون من المنطقي لك تسمية بنى من تلك كـ "xyz-abc" و "xyz-zzz".

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

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

shykes حسنًا ، إذا وصلنا إلى هذا الحد فيما يتعلق بامتلاك Dockerfile / * ، فلماذا لا نذهب إلى أبعد من ذلك ونجعل "docker build" يبحث ببساطة عن الملفات المسماة "Dockerfile. *" في جميع المجلدات الفرعية للدليل الحالي ، بشكل متكرر ، و تشغيل كل منهم في سياق الدليل الحالي؟ وبينما نحن في إذا ، قدم خيارًا لبناء واحد منهم فقط ... مثل "-f"؟ :)

... يكرهون أن يطلق عليهم سخيفة

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

أعتقد أن حجتك المحددة كانت "لا أريد أن يبدأ الناس في وضع Dockerfiles في أماكن عشوائية واستخدام -f بشكل منهجي عندما لا يكون ذلك ضروريًا تمامًا". هل هذا صحيح؟ في هذه الحالة ، من المنطقي تكليف ملف Docker واحد في الجزء العلوي من الريبو ، مع إدراج ملفات Dockerfiles الأخرى. إذا كان هذا الملف غير موجود ، فيمكن للمُنشئ رفض التشغيل (أو إصدار تحذير) ، وإذا كان يسرد ملف Docker واحدًا فقط ، فيمكن للمُنشئ أيضًا إصدار تحذير. لا أعتقد أن المقارنة بين -v و -p مناسبة هنا.

aigarius إذا فعلنا ذلك ، فسيكون من غير الواضح كيفية تعيين كل ملف Dockerfile فرعي إلى صورة فرعية. تتمثل ميزة كل من ./Dockerfile.* و ./Dockerfiles/* أنهما يرسمان مساحة اسم واحدة يمكننا استخدامها لتسمية الصور الناتجة. على النقيض من ذلك ، إذا كان لدي ./foo/Dockerfile.db و ./bar/Dockerfile.db ، وأنا docker build -t shykes/myapp . ، فأي واحد سيُطلق عليه shykes/myapp/db ؟

أي واحد يطلق عليه shykes / myapp / db؟

لا. في مثل هذا السيناريو ، ستقوم بتشفير مسار كامل إلى Dockerfile في الاسم ، لذلك سيكون لديك "shykes / myapp / bar / db" و "shykes / myapp / foo / db". هذا _ يفعل _ يقترب بشكل غير مريح من مساحة أسماء جافا ، لكنني سأترك للآخرين ليقرروا ما إذا كان ذلك جيدًا أم سيئًا.

shykes : بخصوص

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

لذا ، فإن مشاكلي هنا ذات شقين:

1. عدم الحصول على ملف فوضوي ضخم لجميع الخدمات
2. القدرة على بناء خدمة واحدة محددة في هذا الملف / مجموعة الملفات

مرة أخرى ، Docker هي فكرة وأداة عبقرية ، لذلك أريد أن يتخلى الناس مثلي عن Vagrant لنوع معين من الوظائف أو حالات الاستخدام.

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

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

يبدو أن هناك توترًا بين المشاركة والمرونة.

إذا كانت المشاركة هي أهم ميزة ، إذن نعم ، ملف عامل إرساء قياسي
من المنطقي.

لا أعتقد أن المشاركة هي أهم ميزة. يتم تحقيق المشاركة
عبر الصور.

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

يمنحنا الخيار -f المقصود المرونة التي نحتاجها. في الجهه المقلوبه،
القدرة على تحديد مسار مطلق لسياق البناء من شأنه أيضًا
الشغل.
في 3 تموز (يوليو) 2014 ، الساعة السادسة مساءً ، كتب "David Bergman" [email protected] :

آسف إذا كررت شيئًا تمت معالجته جيدًا أعلاه ، لكنني فشلت في رؤيته
كيف يكون أي حل أفضل من دعم خيار "-f". أي ، modulo
مشاكل التنفيذ بسبب بعض الاعتماد المتجذر على
Dockerfile المقيم في جذر السياق ، لا أرى أي عيب به
هو - هي.

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

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

متفقًا على أن -f يوفر أكبر قدر من المرونة مع الحد الأدنى من "المفاجأة" (لقد افترضت شخصيًا وجود مثل هذا العلم وجربته قبل المجيء إلى هذا الموضوع).
إن إضافة -c ، سواء من دليل أو القطران ، لتوفير السياق أيضًا يبدو أيضًا كإضافة رائعة. سيؤدي هذا إلى إزالة cd s الثابت من عمليات الإنشاء الكبيرة ، على سبيل المثال ؛ في الشركات.

علاوة على ذلك ، فإن التمهيدي الذي يحتوي على تعليمات لـ docker build -f foo/bar/Dockerfile -c foo/ لا يبدو أنه سيكون غير مقنع بالنسبة لي.
وافق أيضًا على أن docker build يمكنه البحث بسهولة عن Dockerfile s. بهذه الطريقة ، يتم تنظيم الريبو على هذا النحو:

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

من شأنه تجنب أي تعارضات محتملة في التسمية ( repo/bar/subbar ) ، ومن السهل تحديد المبلغ ، ويجب أن يكون منطقيًا في العديد من سياقات التطوير. سيسمح ذلك بسهولة استخدام كل من docker build ، والذي من شأنه أن يبني العديد من السياقات ، و docker build -f ، والذي يمكن أن يترك الدخيلة Dockerfile في معظم السياقات.

إذا كان -f هو ملف aa بدلاً من dir يحتوي على Docker ، فيجب أن يعمل ذلك أيضًا ، بحيث يمكن للمطور أن يمتلك ملف dockerfile لم يتم إنشاؤه عند تشغيل docker build .

فقط حتى لا يضيع هذا ، بالأمس في مناقشة IRC مع shykes ، كانت لديه فكرة أخرى حول تنفيذ هذا:

• يوجد Dockerfile رئيسي في جذر المستودع يحتوي على عدة أسطر فقط بتنسيق جديد مثل "INCLUDE foo / bar / Dockerfile AS bar-foo" لكل صورة يتم إنشاؤها
• يحتفظ كل مشروع فرعي (مثل وحدة شريطية من مشروع فرعي foo) ، الذي يحتاج إلى صورة منفصلة ، بملف Dockerfile عادي في foo / bar / Dockerfile. لا تزال المسارات في ملف Dockerfile هذا (للإضافة والنسخ) مرتبطة بجذر السياق ، وهو جذر المستودع (حيث يوجد ملف Dockerfile الرئيسي)
• استدعاء منتظم لـ "docker build -t mycorp / myapp." سيتم إنشاء جميع الصور المسجلة في ملف Dockerfile الجذر وتعيين أسماء لها مثل "mycorp / myapp / bar-foo" في هذا المثال
• يجب تقديم خيار سطر أوامر إضافي لـ "إنشاء عامل الإرساء" لإنشاء بعض الصور المعلنة فقط ، مثل "docker build -t mycorp / myapp - only bar-foo، baz-db"

فقط في حالة استمرار الأشخاص في البحث عن حل بديل:

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

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

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

ربما لن يتم تنفيذ "-f" للأسباب التي سبق تقديمها.

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

أعتقد أن # 7115 هو على الأرجح الحل المناسب لذلك

هناك أيضًا # 7204 الذي من شأنه أيضًا أن يلائم الكثير من حالة الاستخدام لهذا ، على ما أعتقد.

أنا لا أحب كلا الحلين المقترحين اللذين يتضمنان إضافة بناء الجملة إلى ملف الرصيف. لا يبدو أي منهما واضحًا. لا يزال # 7115 لا يبدو أنه سيحل حالة الاستخدام حيث أردت إنشاء عدة أنواع من الصور من ريبو واحد ، كما أفعل ، على سبيل المثال ، في أحد مشاريعي لإنشاء صورة "اختبار" و صورة "prod". يبدو 7204 # حلًا معقدًا للغاية يحل مشكلة مختلفة -f يسمح _configurability_ إلى بناء ، في حين أن كلا الحلين يعالجان _sub_builds_.

أود حقًا بعض التفسير لـ "من الضروري أن يعمل البناء تمامًا من مضيف إلى مضيف". لا أفهم لماذا هذا هو مثل هذا المبدأ الأساسي.

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

بالنسبة لي ، يبدو -f حلًا عمليًا ، ولكن إذا لم يكن مقبولًا ، فربما يمكننا التفكير في حل لا يتضمن تحويل ملف dockerfile إلى صيغة برمجة كاملة.

من الضروري أن يعمل البناء بنفس الطريقة تمامًا من مضيف إلى مضيف

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

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

يوم الاثنين ، 28 تموز (يوليو) 2014 ، الساعة 10:43 صباحًا ، Peter Braden [email protected]
كتب:

أنا لا أحب كلا الحلين المقترحين اللذين يتضمنان إضافة بناء الجملة إلى
ملف عامل ميناء. لا يبدو أي منهما واضحًا. # 7115
لا يزال https://github.com/docker/docker/issues/7115 لا يبدو كذلك
من شأنه حل حالة الاستخدام حيث أردت إنشاء عدة أنواع من الصور
من مستودع واحد ، كما أفعل ، على سبيل المثال ، في أحد مشاريعي إلى
إنشاء صورة "اختبار" وصورة "prod". # 7204
https://github.com/docker/docker/pull/7204 يبدو وكأنه ملف
حل معقد للغاية يحل مشكلة مختلفة -ف يسمح
_configurability_ لبناء ، في حين أن كلا الحلين يعالجان
_sub_builds_.

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

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

بالنسبة لي ، يبدو -f كحل عملي ، لكن إذا لم يكن مقبولاً ،
ثم ربما يمكننا التفكير في حل لا يتضمن قلب
dockerfile في بناء جملة برمجة متكامل.

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

بقدر ما أفهم الفكرة الأساسية هي أنه يمكنك سحب git repo وإذا رأيت Dockerfile هناك ، فيمكنك تنفيذ "docker build -t mytag". فيه والحصول على البنية الكاملة المتوقعة. المفتاح هنا هو أنه لا توجد تعليمات بناء مخصصة قد يخطئ الأشخاص أو لا يعرفون عنها.
ما يمكن أن يكون حل وسط هو طريقة لتعريف صور Docker متعددة في سياق واحد حيث يتم إنشاء كل منهم افتراضيًا بعلامات فرعية محددة مسبقًا ومن ثم يمكن أن يكون لديك خيار لإنشاء واحدة فقط من العديد من الصور الممكنة.
بهذه الطريقة يتم الحفاظ على بناء جملة البناء المشترك مع السماح أيضًا لكل من: 1) إنشاء الكثير من الصور المختلفة من سياق واحد ؛ 2) اختر فقط إنشاء واحد منهم باستخدام خيار "متقدم".
تم وصف الصيغة المقترحة في تعليقي أعلاه - https://github.com/docker/docker/issues/2112#issuecomment -48015917

algarius شكرًا ، أعتقد في هذه المرحلة أنه يجب علينا فتح اقتراح تصميم جديد لبناء جملة _INCLUDE_. للحصول على أمثلة لمقترحات التصميم ، راجع # 6802 أو # 6805.

تبدو العملية كما يلي:

• إرسال اقتراح التصميم
• ناقش اقتراح التصميم
• أوافق على اقتراح التصميم
• أرسل العلاقات العامة لاقتراح التصميم

لنكن صادقين ، لا يمكن تكرار الإنشاءات الآن.

إذا كان لدي RUN apt-get update && apt-get install build-essentials ruby python whatever في ملف Dockerfile الخاص بي ، فأنا بالفعل تحت رحمة
كل ما هو "الأحدث" في مستودعات إعادة الشراء عند النقطة التي أقوم فيها ببناء الصورة. لو
أنت تبني الصورة بعد أسبوع ، قد تحصل على إصدارات مختلفة من
التبعيات لتلك التي حصلت عليها.

codeaholics لكن هذا عليك لأنك لا تربط إصدارًا وخرج تمامًا عن سيطرة Docker.

ربما تعليق عادل

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

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

peterbraden في # 7115 ، بمجرد إضافة إمكانية إجراء مكالمات متعددة PUBLISH ، يمكنك الآن إنتاج صور متعددة. بعد ذلك ، يمكنك إضافة قابلية تكوين من خلال السماح بتحديد الصور الفرعية المراد إنشاؤها. المفتاح هو أن التكوين يحدث _ ضمن مجموعة الصور الفرعية التي يمكن اكتشافها بواسطة Docker_. بهذه الطريقة تحافظ على قابلية الاكتشاف.

shykes > بمجرد أن يعتمد
في حد ذاته ... تكرار البناء الخاص بك هو في الأساس صفر.

أنا موافق. أعتقد أن معظم ملفات Dockerfiles الخاصة بي تعتمد على المستودعات المناسبة والمناسبة
تتغير باستمرار. البناء اليوم ليس هو نفسه البناء
في الامس. الصورة المبنية هي المعيار الذهبي الوحيد للمنظمة البحرية الدولية.

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

أنا أحب Docker حتى الآن. رفاق العمل رائع! هذه المشكلة بالذات تحدث للتو
لتكون نقطة ألم.

يوم الاثنين ، 28 يوليو ، 2014 الساعة 12:25 مساءً ، سولومون هايكيس [email protected]
كتب:

@ peterbraden https://github.com/peterbraden في # 7115
https://github.com/docker/docker/issues/7115 ، بمجرد إضافة القدرة
لإجراء مكالمات متعددة للنشر ، يمكنك الآن إنتاج صور متعددة. ثم أنت
يمكن أن تضيف قابلية تكوين من خلال السماح بتحديد الصور الفرعية المراد بناؤها.
المفتاح هو أن التكوين يحدث _ ضمن مجموعة
الصور الفرعية التي يمكن اكتشافها بواسطة Docker_. بهذه الطريقة تحافظ على قابلية الاكتشاف.

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

thedeeno الهدف من Dockerfile هو تحديد كيفية تحويل مستودع كود المصدر إلى شيء يمكن لـ Docker تشغيله.

ماذا عن "هدف _a_ Dockerfile هو تحديد كيفية تحويل مستودع شفرة المصدر إلى شيء يمكن لـ Docker تشغيله."

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

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

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

@ peterbraden shykes أوافق على أن - f أبسط وبديهية. لقد وجدت هذه المشكلة في الأصل لأنني _ متوقعة_ أن يكون لدى Docker هذه الميزة بالفعل وبحثت عنها (على الأرجح عندما لا تعمل افتراضيًا) في اليوم الأول الذي بدأت فيه اختبارها لتطبيقاتنا.

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

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

تم إنشاء اقتراح جديد باستخدام فكرة INCLUDE - https://github.com/docker/docker/issues/7277

كملاحظة جانبية - قد يكون من المفيد التفكير في أمر "APT" أكثر كفاءة بدلاً من "RUN apt-get install -y ...." (ثم بعد ذلك YUM و EMERGE و PACMAN وأي شيء آخر)

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

أعتقد حقًا أننا جميعًا نتجاهل الفيل في الغرفة.

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

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

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

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

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

فكرة أن كل مشروع يمكن أن يختار شيئًا معقولًا للقيام به مقابل docker build . هي فكرة خيالية. المشاريع التي لا يمكن أن تفعل شيئًا معقولًا موجودة ، وفي العدد. السؤال الوحيد في هذه المرحلة هو ما إذا كانت Docker ستدعم الطبيعة متعددة الإنشاءات لتلك المشاريع بشكل مباشر أو ما إذا كانت ستعود إلى أدوات البناء التقليدية مثل make أو حتى البرامج النصية shell. يحدث هذا الآن : على سبيل المثال ، يستخدم Discourse ، وهو أحد أكبر المشاريع الموزعة على Docker ، نظام إنشاء محلي جزئيًا لحل هذه المشكلة.

drewcrawford كما ترى ، هذه هي المشكلة بالضبط. "بناء عامل ميناء". يجب أن تبني الصورة _the_. الصورة الحقيقية الوحيدة. من المفترض أن تقوم بتغيير معلمات تشغيل عامل الإرساء لضبط سلوك الصورة الواحدة والوحيدة في بيئات مختلفة.
في هذا السياق ، من المحتمل أن ترغب في إصدار إصدار ، فقط التطبيق ، ولا شيء آخر. كل الأشياء الأخرى ، مثل "صورة postgres" هي أشياء مختلفة يتم ربطها بتطبيقك في وقت التشغيل. يمكنك التقاط صورة الإصدار نفسها وتشغيلها باستخدام أمر غير افتراضي لتنفيذ اختباراتك فيها.
من الناحية المثالية ، مع دعم الصور المتعددة ، لن تضطر حتى للاختيار بين إصدارات "الإصدار" و "التصحيح" و "مع الاختبارات" - لديك فقط جميعها مع بنية أساسية و 3 فرق صغيرة مبنية على القمة.
إذا حاولت الانحناء عن Docker لطريقة التفكير القديمة ، فسوف تمر بوقت سيء. لا تحاول دق البرغي بمفك البراغي.

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

يُعد السماح بصور متعددة أسهل الطرق وأكثرها سهولة لدعم المتطلبات التي توفرها معظم التطبيقات التي يمكن الوصول إليها عبر الشبكة في العالم الحقيقي (بيئات متعددة ذات تبعيات مختلفة). هل جعل القواعد أكثر تعقيدًا بطريقة لا يمكن توصيلها من أجل حل هذا الأمر المرغوب؟ في النهاية ، أنت فقط تعيد هندسة وتشويش حقيقة أن لديك> 1 بيئة ذات تبعيات مختلفة يمكن التعبير عنها بسهولة بطريقة بسيطة مثل ملفات Dockerfiles المتعددة التي لا تحتاج إلى أي تفسير تقريبًا للمستخدمين النهائيين للبرنامج.

قدم drewcrawford مثالًا ملموسًا لكيفية التعامل مع هذا في تطبيق شائع حالي في العالم الحقيقي يتم توزيعه بدعم Docker. كيف يجب أن يفعلوا هذا؟

aigarius ليس الأمر أنني لا أفهم "طريقة عامل الميناء". أنا فقط أعتقد أنه خطأ.

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

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

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

shykesdrewcrawfordaigarius كنت قد كتبت مقترحا لخيار -f بسيط بنفس الطريقة كما هو موضحshykes في وقت سابق من هذا الموضوع هنا: # 7284

drewcrawford أنت محق ، لكي تكون واجهة المستخدم المفضلة للبناء ، يجب أن يكون docker build على الأقل بنفس القوة مثل على سبيل المثال. make . هناك طريقتان للقيام بذلك:

• 1) يمكننا أن نحاول إعادة تنفيذ كل ميزة في كل نوع مختلف من الصنع ، بالإضافة إلى كل بديل نصنعه هناك: Maven ، scons ، rake ، وبالطبع سكربتات شيل قديمة جيدة.

أو

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

عندما تقول make ، ما هي النكهة التي تشير إليها؟ أية نسخة؟ بنيت من svn الخروج بالضبط؟ مع أي خيارات البناء؟ أي مكتبة libc مرتبطة؟ نفس السؤال عن cc الذي ذكرته أيضًا. ربما لا يهم - ربما سيظهر تطبيقك تمامًا بغض النظر عن الإصدار العشوائي من make انتهى بي الأمر باستخدامه في الإنشاء. لكن مرة أخرى ، ربما يكون الأمر مهمًا. ربما تكون الطريقة الوحيدة بالنسبة لي للحصول على نفس التصميم تمامًا هي استخدام نفس بنية Make و Cc تمامًا التي استخدمتها. ولا توجد طريقة سهلة للقيام بذلك اليوم - ولكن هذا ما أرغب في القيام به.

لا أفكر حقًا في docker build كأداة بناء ، بالضبط - أكثر كأداة بناء ميتا: نقطة بداية معروفة يمكنك من خلالها إعادة تكوين أي بيئة بناء بشكل موثوق. هذا هو الدافع وراء # 7115.

shykes لا أعتقد أنه من الضروري تكرار _ كل ميزة حقًا من make و Maven و rake وما إلى ذلك. بعد كل شيء ، لا تكرر هذه الأدوات كل ميزة لبعضها البعض ، وبطريقة ما تتوافق.

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

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

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

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

مقترحات مثل # 7115 مثيرة للاهتمام ولكن ما لم أفقد شيئًا ما ، فهي ليست بديلاً فعالاً للأهداف. الهدف يخبرك بما يجب بناءه. يمنحك # 7115 DSL أكثر مرونة يمكنه بناء شيء واحد فقط. هذا شيء ، لكنه ليس ما هو مطلوب هنا.

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

drewcrawford فقط للتأكيد ، إذا سمح عامل الميناء بشيء مكافئ لعمل أهداف ، بحيث يمكنك 1) تحديد الهدف الذي يجب إنشاؤه ، على سبيل المثال. make clean; make foo ، 2) الافتراضي لبناء _جميع الأهداف ، و 3) لديك طريقة لتعداد الأهداف ... هل سيكون ذلك مرضي لك؟

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

هذا جيد.

@ shykesdrewcrawford : +1:

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

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

drewcrawford : +1: +1،000،000

هذا هو الموقف الذي أواجهه باستمرار:

أريد بناء حاويتين من نوع Docker من الريبو الخاص بي. ربما يكون أحدهم هو الخادم ، والآخر هو قاعدة البيانات. أو ربما يكون أحدهما هو الخادم والآخر هو عميل يقوم بإجراء اختبارات آلية ضد الخادم عبر مكالمات API.

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

أحتاج إما:

1. الأمر -f لتحديد الملف الذي سيتم استخدامه كملف Docker.
2. القدرة على إضافة ملف ليس المسار السفلي لملف Docker.

بما أنه قيل مرارًا وتكرارًا أن الرقم واحد محظور ، وأفترض أن الرقم الثاني أكثر صعوبة من الناحية الفنية ، فما هي الطريقة "المناسبة" للقيام بذلك؟

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

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

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

ShawnMilo نعم أعتقد أن معظم الناس يستخدمون أداة بناء (صنع ، أشعل النار ، إلخ) أو مجرد برمجة نصية قديمة بسيطة للقيام بذلك.

أظهر شخص ما أعلاه مقتطفًا يحتوي على صورة منشئ تتعامل مع هذا أيضًا.

ها هي طريقتي في التعامل مع هذه المشكلة. لا بد لي من إنشاء صورة لإصدارات مختلفة من النظام الأساسي ، دعنا نقول v2 و v3. لذلك لدي Dockerfile.v2 و Dockerfile.v3 عندما أرغب في إنشاء إصدار ، أقوم بتشغيل أول ln -s ./Dockerfile.v3 ./Dockerfile ثم docker build . الواقع لدي برنامج نصي وقمت بتشغيل ./build v3 أو ./build v2

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

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

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

duglin لديك كل دعمي.

هذا ما نفعله للتغلب على عدم وجود خيار -f في مشروعنا الحالي.

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

اعتبر هذا +1 لإضافة -f .

حاليًا أنا أدير أيضًا أشياء مثل kikito. لقد كتبت عدة نصوص برمجية لبناء صور مختلفة من نفس السياق ولكني أرغب في رؤية طريقة لتحديد ملف عامل ميناء من وسيطة CLI كما هو مقترح بالفعل. +1 لهذا الطلب.

+1000

لقد صادفت هذا اليوم عند محاولة بناء منصة مشتركة عبر مشروع golang باستخدام عامل الإرساء. يعمل هذا ، راجع boot2docker ، لكني بحاجة إلى Makefile الإرساء من الداخل والخارج معًا ، على سبيل المثال docker cp القطع الأثرية من عامل الإرساء الداخلي إلى دليل الإنشاء الخاص بي.

ومع ذلك ، إذا حاولت استخدام هذا في دليل فرعي من الريبو الخاص بي ، فسيتم كسر GOPATH ، لأن المجلد .git في جذر الريبو مفقود. أحتاج إلى ADD جذر الريبو ثم البناء داخل دليلي الفرعي ، لكن هذا لا يسمح به عامل التحميل.

بعد قراءة هذا الخيط الطويل ، رأيت قلقًا بشأن عدم القدرة على إعادة إنتاج البنيات. إحدى الطرق التي يمكن بها تخفيف ذلك هي السماح فقط لخيار -f بالإشارة داخل سياق الإنشاء أو إلى أسفل. بهذه الطريقة يمكنك الحصول على عدة ملفات Dockerfiles في الدلائل الفرعية وإنشائها من جذر الريبو. بالإضافة إلى ذلك ، يمكنك تقييد هذا ليكون ضمن حدود الريبو ، على سبيل المثال في نفس المستوى مثل .git / .hg / .foo وأقل ولكن ليس خارج الريبو.

هذا ما أفكر فيه

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

ينتج عن هذا 3 صور:

1. الصورة الرئيسية تسمى "myimage" ، والتي لا تحتوي على أي شيء فيها على سبيل المثال
2. صورة تسمى myimage-myname1
3. صورة تسمى myimage-myname2

تأخذ الكلمة الرئيسية BUILD اسمًا ومسارًا إلى ملف Dockerfile. يجب أن يكون ملف Dockerfile هذا ضمن السياق الأصلي.
سيكون لكل تعليمات بناء وصول إلى السياق الكامل من البناء الرئيسي.
على الرغم من أنه قد يكون من المفيد قصر السياق على dir-tree التي يحتوي عليها Dockerfile.

-1

يمكنك استخدام وحدة تغذية السياق لـ docker build - مثل dockerfeed لهذه الحالة الخاصة.

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

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

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

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

بدأت تشعر وكأنها منطقة الشفق.

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

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

يريد الآخرون أتمتة نشر برامجهم الداخلية الحالية ، والتي يمكن أن تكون بالفعل معقدة للغاية مع وجود الكثير من أدوات البناء ، ونظام CI وما إلى ذلك بالنسبة لهم Docker هو مجرد أداة أخرى يجب أن تتناسب مع بنيتهم ​​التحتية. وهم بحاجة إلى مزيد من المرونة في كيفية استخدام Docker.

أعتقد أن Docker (مثل .deb) يمكنه تلبية احتياجات كلا الطرفين ، ولكن يجب تقديم التنازلات.

المشكلة الأساسية هي: أين ينتهي هذا؟ تورينج الاكتمال لـ Dockerfile؟ على الاغلب لا. ستكون هناك دائمًا حاجة لمزيد من المرونة لحل الحالات الخاصة. ستدخل بعض الأفكار لغة Dockerfile ، والبعض الآخر لن يدخلها. نظرًا لأن docker قادر على تناول سياق عبر stdin على بناء ، يمكن تنفيذ الوظائف المفقودة عبر معالج مسبق.

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

لم ألق نظرة منذ فترة ولكن الطلب الأساسي هو هذا: أعطنا طريقة واضحة لتزويد كل من Dockerfile و context أثناء الإنشاء. صدمت بصراحة هذا بعد 8 أشهر وما زال مفتوحًا.

thedeeno هذا ممكن بالفعل
cat mystuff.tar.gz | docker build -

@ cpuguy83 لكن لا يمكنني توفير ملف Dockerfile صريح بهذا الأمر. حق؟

thedeeno نعم ، أنت تلطخ أي ملف Dockerfile تريده بأي سياق تريده.

@ cpuguy83thedeeno لا، هذا لا يعمل، لأنك ثم لا يمكن إضافة أي ملفات لأن أيا منها ليس في نطاق "كود]" تحصل عادة مع Dockerfile.

تحرير: هذا البيان خاطئ ؛ لقد أسأت فهم مثال @ cpuguy83 .

ShawnMilo نعم هو كذلك. أي شيء في القطران ضمن السياق.

@ cpuguy83 آسف ، خطأي. قرأته على عجل على أنه مجرد أنابيب في Dockerfile ، وليس كرة تار كاملة.

@ cpuguy83 لطيف! أنا أصوت بإغلاق ثم إذا كان يعمل كما تقترح.

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

استمروا في العمل العظيم!

لا يخفف إدخال سياق كامل ما نتحدث عنه أعلاه على الإطلاق.

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

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

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

هل فاتني شيء؟

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

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

@ cpuguy83 : نعم ، لذلك أريد أن يتعامل Docker مع ذلك بالنسبة لي ، نعم ، والذي سيتضمن اختيار جزء السياق من مكان واحد وملف Dockerfile من مكان آخر محتمل ، أو باسم غير قياسي. أي لدعم علامة "-f" منفصلة :-)

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

أي ، ما زلنا نريد استخدام نفس سياق الجذر.

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

@ cpuguy83 : هل يمكنك شرح كيف

تضمين التغريدة
رأيي في هذا هو:

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

وهذا:

docker build -t myimage .

قد ينتج عنه 3 صور ، "myimage" ، "myimage-myname1" ، "myimage-myname2".
سيكون لكل بناء داخلي وصول إلى سياق البناء الكامل كمسارات مطلقة. ستكون المسارات النسبية متعلقة بملف Dockerfile.
ويمكن أن تحتوي "myimage" على أشياء خاصة بها تتجاوز تعليمات BUILD فقط.

كما ذكرت سابقًا ، تفترض الكثير من الأدوات الجديدة في بيئة Docker الأكبر (والعظيمة!) أن كل ملف Dockerfile مرتبط بصورة Docker واحدة بالضبط. مختلف أدوات المنسق التي تشبه "التين". والكثير من الحلول السحابية الجديدة والقديمة التي تحتوي على دعم خاص لـ Docker لديها أيضًا هذا الافتراض الفردي. من المؤكد أنهم في العالم الذي تم إنشاؤه بواسطة خيار "-f" لا يتعين عليهم بعد ذلك الحصول على سياق فقط - مثل كرة القطران على سبيل المثال - ولكن أيضًا ملف Dockerfile الذي يحتمل أن يكون منفصلاً. لكن كل تحميل من هذا القبيل سيظل يتوافق مع صورة Docker واحدة بالضبط.

إذا سلكنا طريق فصل Dockerfile المحتمل عن جذر السياق ، آمل أن تبدأ هذه الأدوات في التعايش مع هذا السيناريو:

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

كلما طالت مدة بقائنا مع هذا الاقتران القوي لـ "Dockerfile" في المستوى الأعلى من السياق ، كلما كان ذلك أكثر جاذبية في البيئة. أي ، يجب أن نتصرف الآن ، حيث يتحرك عالم Docker بسرعة ، بسبب الذهول العام.

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

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

تماثل بين Dockerfiles والصور

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

hanikesn : تعليقان:

1. لماذا يتم كسر هذا الافتراض من خلال الاضطرار إلى نسخ Dockerfiles إلى مكانها قبل البناء ؛ سيظل ملف Dockerfile واحدًا <-> صورة واحدة؟
2. ما أجادله هو أنني أريد أي حل نتوصل إليه هنا للعمل مع مشهد Docker الحالي والمتزايد ، دون الحاجة إلى تغييرات كبيرة جدًا في هذا المشهد ؛ وأعتقد من خلال _keeping_ أن التشابه المذكور ، نقوم بذلك.

كانت الاقتراحات الأخرى هنا هي الحصول على Dockerfile واحد متعدد الصور ، من المحتمل أن ينادي بملفات Dockerfiles الفرعية. لن يعمل ذلك مع كيفية استخدام معظم الأدوات (الشكل وما إلى ذلك) حاليًا لـ Docker.

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

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

أقترح هذا الحل الذي أشرت إليه سابقًا:

$ docker-pre-processor [ --options ... ] . | docker build -

في حين أن --options هي القواعد التي يجب تغيير السياق في الدليل الحالي (هنا) وتمريره إلى عامل الإرساء. يجب القيام بذلك على الفور عن طريق إنشاء أرشيف tar مؤقت يحتوي على السياق. بهذه الطريقة يمكن أن يظل سياق المصدر كما هو. من الأسهل تغيير المعالج المسبق من بناء جملة Dockerfile.

itsafire

ماذا عن الأدوات التي تتوقع Dockerfiles اليوم؟ لقد أصبحوا أكثر وفرة باستخدام Amazon أو Google أو ما شابه. والتين وأطر تزامن مماثلة.

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

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

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

التجزؤ حول هذا الموقف يتعارض مع الهدف المعلن لفريق docker وهو "التكرار". هذه المناقشة والأخرى تدور حول حل هذه القضية.

أكثر من عام واحد وأكثر من 130 تعليقًا وأكثر من مشكلة بسيطة تؤثر على معظم المستخدمين ... لقد تأثرت. استمر في العمل الجيد ، Docker!

+1

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

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

طريقتي هي الحفاظ على جذر المشروع نظيفًا. لكن ADD ../src و -f deploy/Dockerfile لا يعمل. في الوقت الحالي ، لدي Dockerfile و .dockerignore في جذر المشروع ، لكن هذا مؤلم بالنسبة لي.

من جانبي ، قمت بإنشاء برنامج نصي يقوم بتجهيز مجلد بالملفات المطلوبة وتنفيذ سطر الأوامر القياسي docker build -t my/image . لأنني واجهت مشكلة أن الملف .dockerignore تم تجاهله بواسطة ADD ...

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

+1 لهذا. أحتاج إلى إضافة ملفات إلى صور مختلفة من نفس المجلد لخوادم مختلفة.

+1 أنا أستمتع بـ Docker حتى الآن ، ولكن نظرًا لطريقة إعداد فريقي ، أحتاج حقًا إلى طريقة لإنشاء عناصر نشر مختلفة تشترك في جزء كبير من التعليمات البرمجية ، من ريبو واحد. ليس حريصًا بشكل خاص على بنائها جميعًا في حاوية uberdocker حيث يتم ربط دورات نشرها / إطلاقها معًا بلا داعٍ. ما هي أفضل ممارسة للتغلب على هذا؟

jfgreen : ضع عدة ملفات Dockerfiles أينما تريد ، وقم بتسميتها كما تريد. ثم يكون لديك نص برمجي bash ينسخها واحدًا تلو الآخر إلى جذر الريبو مثل "./Dockerfile" ، يقوم بتشغيل "بناء عامل ميناء" ، ثم يحذفها. هذا ما أفعله لمشاريع متعددة وهو يعمل بشكل مثالي. لدي مجلد "dockerfiles" يحتوي على ملفات مسماة بأشياء مثل قاعدة البيانات والقاعدة والاختبارات وما إلى ذلك ، وكلها ملفات Dockerfiles.

ShawnMilo شكرًا ، يبدو أن هذا حل معقول للغاية.

+1

+1

+1 إلى -f . هناك تقصير عقلاني والذي إذا تم حذف العلم ، فإن Docker سيفعل الشيء الصحيح. - في حالة أنه لأي سبب من الأسباب ، فإن العرض المحدد جدًا للشيء الصحيح هو للمستخدم _الشيء الخطأ_ هناك -f . المقارنات أعلاه لأدوات مثل make أعتقد أنها معقولة. make هو أيضًا أداة مساعدة ذات رأي كبير تمت كتابتها في الأصل عام 1976 ، وبالتالي كان لديها قدر معقول من الوقت لتحقيق الاستقرار في مجموعة ميزات. أعتقد أنه من المفيد أنه في man make العلم الوحيد الذي يتم ذكره في الملخص الموجز للغاية هو ... -f .

       make [ -f makefile ] [ options ] ... [ targets ] ...

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

+1

+1 (أو مشاركة مدونة رسمية مع الحل البديل الموصى به)

+1

+1

crosbymichael أعتقد أنه يمكن إغلاق هذا الآن بسبب دمج # 9707

فوز.

إذا كنت ترغب جميعًا في تجربة هذه الميزة الجديدة ، يمكنك تنزيل الثنائيات للحصول على الماجستير على:

master.dockerproject.com

شكرا @ دوغلين !

: تصفيق:

شكرًا لك crosbymichael على الثنائي! : +1:

أحسنت يا رفاق! : تصفيق:

إذن فهو docker build -f Dockerfile.dev . ؟ تحرير: نعم