أنت تسلسلهم :)

على سبيل المثال ، إذا كان لديك Dockerfile واحد يقوم بإعداد عميل postgres العام وبيئة تطبيق python العامة ، فأنت تضع علامة على نتيجة هذا الإصدار (على سبيل المثال mygenericenv ) ، ثم تستخدم Dockerfiles اللاحقة FROM mygenericenv .

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

## Dockerfile.genericwebapp might have FROM ubuntu
cat Dockerfile.genericwebapp | docker build -t genericwebapp -
## Dockerfile.genericpython-web would have FROM genericwebapp
cat Dockerfile.genericpython-web | docker build -t genericpython-web -
## and then this specific app i'm testing might have a docker file that containers FROM genericpython-web
docker build -t thisapp .

يمكنني معرفة كيفية القيام بذلك ، على سبيل المثال genericA --> specificA ولكن هل هناك أي طريقة للقيام بشيء مثل:

genericA --
            \
             ---> specificAB
            /
genericB --

؟

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

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

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

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

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

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

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

نصيحتي هي التركيز على شيئين: 1) الكود المصدري ، و 2) الحاوية القابلة للتشغيل. هذه هي النقطتان الوحيدتان الموثوقتان للتكوين.

يوم الأحد ، 29 ديسمبر 2013 الساعة 1:46 مساءً ، anentropic [email protected]
كتب:

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

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

شكرا لإعطاء وجهة نظر أكثر.

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

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

أشعر أن المستندات لا توجهك حقًا لاستخدام Docker بطريقة معقولة في الوقت الحالي

anentropic الطريقة الصحيحة للقيام بذلك باستخدام Dockerfiles هي إنشاء صور متعددة باستخدام ملفات Dockerfiles متعددة.
إليك مثال: ينشئ Dockerfile 1 صورة عامة أعلى صورة Ubuntu الأساسية ، ويستخدم Dockerfile 2 الصورة الناتجة من Dockerfile 1 لإنشاء صورة لخوادم قاعدة البيانات ، ويستخدم Dockerfile 3 صورة خادم قاعدة البيانات ويقوم بتكوينها لدور خاص .

يجب أن يكون تشغيل docker build سهلًا جدًا ويجب عدم إضافة التعقيدات غير الضرورية.

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

فهمت ... لذلك في السيناريو الذي أوجزته مع فن ASCII أعلاه ، فإن طريقة Docker ستكون:

• ابدأ بـ Dockerfiles للصور المستقلة GenericA و GenericB
• لإنشاء صورة SpecificAB أود نسخ محتويات ملف Docker GenericB ولصقها في ملف Dockerfile جديد يبدأ بـ: FROM GenericA

المشكلة التي أراها هي أنه إذا كانت "الوصفة" (لاستعارة مصطلح الشيف) مقابل GenericB معقدة للغاية وتحتوي على العديد من الخطوات ، فلا توجد طريقة يمكنني من خلالها مشاركة هذه المعلومات ، باستثناء نشر Dockerfile _to Github_ لذلك أن يتمكن الآخرون من نسخ ولصق الأجزاء ذات الصلة في ملف Docker الخاص بهم.

هل حاولت استخدام الفهرس العام؟ على سبيل المثال ، أجريت بحثًا عن "postgres" ... كيف أحكم على فائدة (أو أميز بأي شكل من الأشكال بين) صور مثل هذه:

• https://index.docker.io/u/cthulhuology/postgres/
• https://index.docker.io/u/alvin/postgres/
• https://index.docker.io/u/antihero/postgres/
• https://index.docker.io/u/dbraden/postgres/

؟

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

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

ولكن يبدو أنه من العار أنه لا توجد طريقة (بصرف النظر عن النسخ واللصق) لمشاركة سلسلة الأوامر في Dockerfile كوصفة ... مثل اقتراح أمر "include" الذي تم رفضه هنا https: // github .com / dotcloud / عامل ميناء / سحب / 2108

anentropic يمكنك استخدام صورة موثوقة ويمكنك أيضًا العثور على postgres Dockerfile لبناء الصورة بنفسك.

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

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

الصور الأساسية مثل ubuntu و centos وبعض الصور من stackbrew/* هي صور يمكنك استخدامها لبناء ما تحتاجه.

مثال على صورة رائعة جاهزة للاستخدام هو stackbrew/registry . تتيح لك هذه الصورة اللعب مع سجل Docker خاص بمجرد الانتهاء من تنفيذ docker pull stackbrew/registry و docker run -p stackbrew/registry .

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

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

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

دعنا نفترض من أجل البساطة أنهم جميعًا يستخدمون نفس الصورة الأساسية R . تخيل أن لدي خدمة A وخدمة B . أريدهم في صور Docker منفصلة وكلاهما على نفس صورة Docker.

اكتب نصًا لتثبيت الخدمة A واكتب نصًا منفصلاً لتثبيت الخدمة B . ثم لديك git repo مع البرنامج النصي لـ A وآخر للنص B . أنشئ git repos لجميع صور Docker الثلاثة التي سيتم إنشاؤها. يحتوي كل منها على وحدات git الفرعية مع نص (نص) التثبيت الذي سيتم استخدامه. سيقوم كل Dockerfile ببساطة ADD ببرنامج نصي للتثبيت ثم RUN نص التثبيت والقيام بذلك لأحد البرنامجين أو كليهما. إذا كنت ترغب في إزالة البرنامج (النصوص) من الصورة ، فقم بإصلاحه بعد تشغيله.

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

أعتقد أنني أخطأت في فهم كيفية عمل ذلك ، لذا أرد للحصول على توضيح. أرغب في استخدام Ubuntu 11 مع الصور الرسمية لرسو السفن السيلينيوم. يستخدمون أوبونتو 15.

https://github.com/SeleniumHQ/docker-selenium/blob/master/Base/Dockerfile

ما هي الطريقة الصحيحة للقيام بذلك؟ لاستنساخ هذا الريبو وتحرير جميع الملفات ليقول Ubuntu 11 وليس 15؟ هذا لا يمكن أن يكون صحيحا ، أليس كذلك؟ هذا يعني أن أي شخص لديه أي خلاف مع أي جانب من جوانب الصور الرسمية لا يمكنه الاستفادة منها دون تكرار الكود الخاص بهم. أعتقد أنني أخطأت ، هل يمكن لأحد أن يشرح؟ ما هي الطريقة الصحيحة لاستخدام صورة السيلينيوم الرسمية مع أوبونتو 11؟

rjurney نعم ، هذه هي الطريقة التي ستعمل بها ؛ في المثال الخاص بك ، تم تطوير Dockerfile بأكمله مع وضع ubuntu: 15.04 في الاعتبار ؛ هل هذه الباقات متوفرة على ubuntu: 11؟ هل يعملون؟ هل يعمل السيلينيوم عليهم؟ من المحتمل أن يتم إجراء تعديلات في Dockerfile لجعله يعمل على إصدار آخر من Ubuntu.

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

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

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

(لاحظ أيضًا أنه لا توجد صورة رسمية ubuntu:11 )

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

يوم الأربعاء ، 9 ديسمبر 2015 ، سيباستيان فان ستيجن <
[email protected]> كتب:

rjurney https://github.com/rjurney نعم ، هكذا سيعمل ذلك ؛ في
مثالك ، تم تطوير Dockerfile بأكمله مع وضع ubuntu: 15.04 في الاعتبار ؛
هل هذه الباقات متوفرة على ubuntu: 11؟ هل يعملون؟ هل تشغيل السيلينيوم
عليهم؟ هناك احتمالات بأن التعديلات يجب إجراؤها في Dockerfile
لجعله يعمل على إصدار آخر من Ubuntu.

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

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

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

(لاحظ أيضًا أنه لا توجد صورة Uubuntu: 11 رسمية)

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

راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

تعد الوراثة المتعددة

كانت 12749 هي أحدث محاولة لإضافة مثل هذه الوظيفة - تم رفضها في النهاية لأن هناك عملًا آخر يجب القيام به أولاً.

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

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

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

حسنًا ، سعيد لسماع أنك على رأس هذا. شكرا لصبرك :)

في الأربعاء 9 ديسمبر 2015 الساعة 9:59 صباحًا ، كتب Brian Goff [email protected] :

rjurney https://github.com/rjurney الميراث المتعدد أيضًا
معقد للغاية وليس مجرد شيء تضيفه دون تفكير
للعواقب وحالات الزاوية وحالات عدم التوافق.

12749 https://github.com/docker/docker/pull/12749 كان الأحدث

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

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

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

راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

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

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

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

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

أنا أتفق مع كل ما قلته ، لذا +1.

في يوم الأربعاء الموافق 9 ديسمبر 2015 ، أرسل بيل سي ريمر إخطارات github.com
كتب:

rjurney https://github.com/rjurney من أين تحصل على معلوماتك.
على حد علمي ، لم يكن لدى Java وراثة متعددة ، ولن تفعل ذلك أبدًا.
أنا متأكد من أن الأمر نفسه ينطبق على العديد من اللغات. يعتبر الكثيرون متعددة
الوراثة ضارة للغاية ، حيث يمكن أن ينتج عنها شبه مستحيل
كود يمكن التنبؤ به. سيكون الأمر نفسه صحيحًا بالنسبة لحاوية عامل الإرساء.

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

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

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

راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

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

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

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

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

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

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

في حال كان أحد يهتم ...

العرض التقديمي نصف المعتمد حول الحلقات ووحدات الماكرو في Pig: http://wiki.apache.org/pig/TuringCompletePig
Pig Macro JIRA: https://issues.apache.org/jira/browse/PIG-1793
واجهة API لـ Pig JIRA: https://issues.apache.org/jira/browse/PIG-1333
واحد تم رفضه تمامًا لاحترام Apache Hive ... أضف SQL إلى Pig: https://issues.apache.org/jira/browse/PIG-824

أخيرًا ، خطرت لي فكرة قد تجعل هذا التغيير سهلاً ... ماذا لو لم تستطع ملفات INCLUDE أن ترث؟ على سبيل المثال ، يمكنك تجنب الاعتراضات عن طريق إبقاء الأمور بسيطة للغاية. تعامل مع الباقي لاحقًا حيث يتم تعلم المزيد. يمكن أن يكون هناك Dockerfile بسيط على سبيل المثال يقوم بتثبيت المتطلبات المسبقة والثنائيات ، ويقوم بإعداد الشياطين لـ MySQL على Ubuntu. إذا لزم الأمر ، يمكن إصدار هذا بواسطة إصدار Ubuntu و MySQL. أنا شخصياً سأقوم باختراق أداة للقيام بهذه التضمينات البسيطة واستخدامها لتنظيم ملفات dockerfiles الخاصة بي بهذه الطريقة. لا يمكنني الانتظار لطلب وإعادة استخدام الكود الخاص بي.

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

+1 للتضمين. أنا ببساطة بحاجة إلى صورة nginx و ssh مدمجة في صورة واحدة. لماذا هذا يجب أن يكون بهذه الصعوبة؟

فكرة عدم الحاجة إلى هذا أمر محير بصراحة إلى حد الوجود
مخادع. سيستخدم معظم المستخدمين هذا ، إذا تم إنشاؤه. "أضف ssh إلى
ubuntu "و" add nginx إلى ubuntu "هما مهمتان شائعتان جدًا للجميع
لا تحتاج للتكرار. ما يبدو أن Docker HQ يقوله حقًا حول هذا الأمر ،
"من الواضح أن هناك حاجة ، لكننا نعتقد أنها ستصبح قبيحة للغاية. لذلك نتظاهر". هو - هي
سيكون من الأفضل أن تكون صادقًا ومنفتحًا بشأن هذا الأمر.
آسف إذا كنت غريب الأطوار.

في يوم السبت 23 يناير 2016 الساعة 6:22 مساءً ، كتب Vazy [email protected] :

+1 للتضمين. أنا ببساطة بحاجة إلى صورة nginx و ssh مدمجة في صورة واحدة. لماذا
هل يجب أن يكون هذا صعبًا جدًا؟

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

راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

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

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

في الأحد يناير 24، 2016، فنسنت Demeester [email protected]
كتب:

rjurney https://github.com/rjurney دعنا ننتظر البناء العرضي ؛
لأنه بهذه الطريقة ، ستكون هناك أكثر من طريقة لبناء الصور (وبالتالي
يمكن أن يظهر منشئ مخصص يفعل ذلك). واحد من سبب عامل الميناء
المشرفون (العاملون أو الذين لا يعملون في Docker) هم منزعجون حيال ذلك ، هو
لأنه سيضيف تعقيدًا حيث نريد إضافة المرونة و
بساطة. من خلال استخراج المنشئ ، سيكون لدينا فصل أفضل لـ
القلق (بين بناء الصور وتشغيلها) والكثير من حالات الاستخدام
سيتم تنفيذها بحرية أكبر في بناة العرف.

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

راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

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

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

لذلك ، أرى هذه المشاكل من خلال الدمج.

1. معالجة تعارضات الدمج.
2. حل القواعد المختلفة (Ubuntu و CentOS).

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

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

هل هناك مشاكل أخرى أفتقدها هنا؟

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

قد يكون الأسلوب الأكثر واقعية هو نوع الحل النموذجي ، أي السماح بـ INCLUDE a Dockerfile _fragment_ (الذي لا يحتوي على عبارة FROM ، فقط قائمة من الأوامر) في ملف Dockerfile حقيقي ... يمكن مشاركة الأجزاء وإعادة استخدامها وتضمينها في أي ملف Dockerfile متوافق للصورة الأساسية

http://docktitude.io

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

jmcejuela في كثير من الحالات ، "reuse" هو إنشاء صور مخصصة لخدمة معينة ، والجمع بين تلك الصور / الحاويات لتشكيل تطبيقك. المكونات الفردية للتطبيق الخاص بك قابلة لإعادة الاستخدام (ربما يختلف تكوين الحاوية فقط) ، لكن الطريقة التي تجمع بها تشكل التطبيق الفعلي.

thaJeztah أفهم ، شكرا لك.

ولكن لجعله ملموسًا مثل الأشخاص الذين تم نشرهم من قبل ، لنفترض أنني أنشأت تطبيق ويب يقوم بتشغيل تطبيق scala (صورة A ) ، ثم اجعل خادم الويب باستخدام nginx (image B ) ، ثم استخدم ssh (image C ) ، وتحتاج إلى تطبيق python إضافي (image D ). لنفترض أنني أنشأت 4 ملفات Dockerfile لكل منها. كيف يمكنني دمجها مع Docker لإنشاء تطبيق الويب النهائي الخاص بي (صورة E ؟)

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

شكرا جزيلا على وقتك. ما زلت أتعلم Docker.

jmcejuela ، لن تجمع بين الصور _ ، بل يمكنك تشغيلها كحاويات منفصلة ، وتجعلهم يتعاونون لتشكيل التطبيق. يمكنك القيام بذلك باستخدام Docker Compose ، والذي يسمح لك بتحديد "المكدس" الخاص بك. على سبيل المثال ، راجع https://github.com/docker/example-voting-app/blob/master/docker-compose.yml (و README ؛ https://github.com/docker/example-voting-app/ blob / master / README.md)

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

يقبل jmcejuela Docker builder محتويات Dockerfile على STDIN ، لذلك يمكن للمرء أن ينشئ واحدًا بسهولة "نسبيًا"؟ إذا كان لابد من تمرير سياق ما ، فيجب عندئذٍ تمييز كل شيء وإدخاله في docker build . حسب تجربتي ، هذه هي أبسط طريقة ممكنة للحصول على تركيبة.

أنا النامية (واللعب مع) هذا النهج، الذي يبني قبالة مفهوم أعلاه. يقوم أحد تطبيقات nodejs بإعداد ملف TAR في الذاكرة (مع Dockerfile والملفات المضافة) ويقوم بتفريغه في STDOUT. يتم نقل STDOUT إلى docker build . يتم إصدار الأجزاء القابلة للتركيب واختبارها وإصدارها كوحدات NPM. لقد طرحت مثالًا قصيرًا جدًا ، يوضح صورة اختبار لـ crond - http://pastebin.com/UqJYvxUR

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

أيضًا ، تم اقتراح INCLUDE منذ فترة طويلة (https://github.com/docker/docker/issues/735).

jmcejuela الحقيقة هي أن معظم مستخدمي عامل

فقط إذا كنت تفعل ذلك بشكل خاطئ ، فإن الأمر docker exec كان موجودًا منذ فترة طويلة الآن ولم أكن بحاجة إلى ssh منذ ذلك الحين ...

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

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

anentropic وفقًا لخارطة طريق Docker ، قد يكون توفير الحاويات قيد التشغيل من خلال docker exec (يأتي) خاطئًا بنفس القدر.

ملاحظة: وصل محرك

rjurney ،: 100:

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

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

ربما يكون هذا مقترحًا في مكان آخر ، وفي هذه الحالة سيكون الارتباط جيدًا.

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

: +1: سأحب حلًا لهذا ويسعده على الأقل أنه يجري الحديث عنه. حتى لو تطلب الأمر أن تكون الصور الأساسية هي نفسها.

تبين أن النسخ من الصور الأخرى مقترح في مكان آخر. هذه هي المشكلة (https://github.com/docker/docker/issues/18596).

jakirkham شكرا ..

+1 لوظيفة الإرث المتعددة لعامل الإرساء

تعديل:

انظر أيضًا: https://github.com/docker/docker/issues/13026

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

يوم الجمعة ، 18 آذار (مارس) 2016 الساعة 9:01 صباحًا ، Alvin Chevolleaux < [email protected]

كتب:

رد thaJeztah https://github.com/thaJeztah جدا
المنير. أنا جديد على Docker ولا أفهم لماذا لا يمكنك الدمج
صور متعددة معًا ولكن يبدو أن Docker Compose هو الحل لـ
الجمع بين عدة _containers_ في تطبيق واحد كنت أبحث عنه
ل.

أعتقد أن المشكلة بالنسبة لي هي أنني اعتقدت أنني فهمت Docker في البداية
لكنني أكتشف الآن أنني لا أفعل ذلك. سأعود وأفعل المزيد
قراءة!

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

راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

rjurney نعم بعد النظر في Docker debian:jessie لكنني أريد أن يكون الإعداد الخاص بي قائمًا على Centos ، لذلك يبدو أنه إذا كنت أرغب في استخدام صورة معينة ، يجب أن أقبل بقية الإعداد أو نسخ ولصق ملف Dockerfile المصدر ولفّ صورتي من البداية ، لا يبدو أن هناك أرضية وسطية حيث يمكنني مزج الصور ومطابقتها.

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

INCLUDE مفيدًا للغاية بالنسبة لي أيضًا. بدونها ، تُركت لنسخ ولصق.

RomanSaveljev لم أفهم:

وفقًا لخريطة طريق Docker ، فإن توفير الحاويات التي يتم تشغيلها من خلال docker exec قد يكون (يأتي) خاطئًا بنفس القدر.

لا تذكر أنه سيتم إهمال docker exec . لطالما كان docker exec أداة تصحيح ، وكذلك يجب أن يكون SSH في حاوية Docker.

أشعر بالحماقة لمشاركتي في هذا ، لكن ما هذا بحق الجحيم ... سأقترح هذا مرة أخرى:

لماذا لا نبسط المشكلة ونبدأ بتطبيق INCLUDE بحيث لا يسمح بالميراث؟ بمعنى آخر ، يمكنك فقط تضمين الملفات التي لا تحتوي على ملف FROM.

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

يبدو أن هذا قرار سهل اتخاذه. لن يكون هناك الكثير من العمل. لن تكون معقدة. حق؟

rjurney هذا ما يفعله https://github.com/docker/docker/pull/12749 بشكل أساسي

rjurney : لا تشعر بالحماقة. في حين أن INCLUDE لا يغطي السؤال الأولي بشكل كامل ، إلا أنه خطوة في الاتجاه الصحيح. هناك عدة مشاكل مغلفة.

1. كيف تجمع بين عدة أجزاء من العمل المستقل؟
2. كيف يتم تخزين مثل هذه المجموعات بكفاءة؟
3. كيف تجمع عدة أجزاء من العمل على مستوى ثنائي ، وليس مستوى بناء؟

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

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

كما قال آخرون ، فإن قابلية تكوين Docker تتعلق بالتأليف على مستوى الخدمة.

: +1: defo يستحق التفكير في نموذج قابل للتركيب - سيكون من الرائع إذا كان بإمكانك استيراد السلوكيات إلى ملف عامل ميناء. على سبيل المثال ، لدي حالة استخدام الآن حيث أرغب في تضمين توفير apache في عدد من حاويات الإنشاء المختلفة جدًا استنادًا إلى Alpine linux - سيقوم البعض بإنشاء خدمات Java ، والبعض الآخر PHP وعقد أخرى.

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

إذن كيف يمكنني استخدام صور Ruby-2.3 و java-8؟ يستخدمون نفس صورة jessie debian مثل القاعدة (قرأت ملفات dockerfiles). أريد فقط تنفيذ الأوامر الموجودة في كلاهما. كما هو الحال ، كان علي نسخ / لصق ملف Java Dockerfile في Ruby Dockerfile. يحتاج التطبيق إلى كليهما ، ولا توجد طريقة على الإطلاق للتغلب على ذلك.

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

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

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

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

تحرير: آه ، فاتني مناقشة INCLUDE.

لماذا لا نبسط المشكلة ونبدأ بتطبيق INCLUDE بحيث لا يسمح بالميراث؟ بمعنى آخر ، يمكنك فقط تضمين الملفات التي لا تحتوي على ملف FROM.

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

يبدو أن هذا قرار سهل اتخاذه. لن يكون هناك الكثير من العمل. لن تكون معقدة. حق؟

: +1:

rjurney هذا في الأساس ما يفعله # 12749

: +1: ممتاز ، أتطلع إلى رؤية ما سيكون قادرًا على فعله في شكله النهائي.

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

أنا شخصياً لا أريده أن يفشل عندما يواجه FROM ، أريده أن يتجاهل FROM وأن يطبق باقي الأوامر بالتسلسل.

أن هذا لم يحدث حتى الآن بدون دعم من هو مصدر مفتوح
مهزلة.

يوم الخميس ، 19 كانون الثاني (يناير) 2017 الساعة 10:19 صباحًا ، أرسل كين ويليامز [email protected]
كتب:

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

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

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

-
راسل جورني twitter.com/rjurney راسل. [email protected] relato.io

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

أ (أوبونتو) -> ب (على سبيل المثال nginx)
أ (أوبونتو) -> ج (مثل العقدة)

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

أ -> ب -> ج '

يبدو أن هذه مشكلة أبسط لحلها.

cloutiertyler عادةً لا تحتاج تطبيقات Node.js إلى هذه الميزة للعمل مع Nginx (في رأيي). ستكون طريقة Docker عبارة عن حاويتين ، واحدة لـ Nginx والأخرى لـ Node. نقوم بتكوين حاوية Node لعرض منفذها فقط إلى حاوية Nginx ، والسماح لحاوية Nginx بالاستماع إلى المنفذ العام (مثل 80). أي سبب لماذا يجب أن يكون Nginx في نفس حاوية Node؟

قد يكون نموذج ملف Docker Compose

version: "2.1"

services:
  app: # Node.js application image
    build: .
  nginx: # Nginx container who can make request to app container
    image: nginx:1.10-alpine
    depends_on:
      - app
    ports:
      - "${PORT:-8080}:80" # public port, you may want PORT=80

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

راجع للشغل ، لا يتم إعادة التأسيس بالضبط ولكنه يفتح الكثير من حالات الاستخدام لملفات Dockerfiles.
يدعم Dockerfile الآن الإنشاءات متعددة المراحل. مثال:

FROM golang AS myapp
COPY . /myapp
RUN cd /myapp && go build

FROM scratch
COPY --from=myapp /myapp /usr/bin/myapp

يمكن أن يكون لديك العديد من المراحل كما تريد.
تقوم المعلمة --from بتحويل السياق إلى اسم هدف البناء المحدد.
عندما تكون docker build -t myapp . ، فإن الصورة الناتجة المسماة myapp:latest ستكون من المرحلة الأخيرة.
يمكنك أيضًا إنشاء مراحل محددة باستخدام docker build --target=myapp ، على سبيل المثال.

هناك بعض التحسينات الأخرى الرائعة على Dockerfile في 17.05 (متوفرة حاليًا باسم RC1) ، جربها!

الآن هذا مثير للاهتمام! لم أكن أعلم أنه يمكنك فعل ذلك. يجب أن أجرب ذلك لمعرفة ما إذا كان يحل حالات الاستخدام الشائعة الخاصة بي.

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

أرغب في الحصول على صورة Jenkins مثبت عليها Docker حتى أتمكن من البناء من داخل الحاوية. حقيقة الأمر هي أنه لا توجد طريقة للقيام بذلك دون تكرار عملية التثبيت لأحدهما أو الآخر في Dockerfile الخاص بي.

هذه هي الحالة التي لا تكون فيها الحجج الضئيلة حول هذا أمرًا ضروريًا لأن كل حاوية يجب أن تكون خدمة واحدة فقط من الواضح أنها لا تنطبق. تجمع "خدمتي الواحدة" بين وظائف Docker و Jenkins.

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

هل تريد تحطيم ملفي رصيف في ملف واحد حتى لا تضطر إلى نسخ / لصق الأشياء؟

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

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

لأولئك الذين يتساءلون عن الطريقة الصحيحة للقيام بذلك ، من منظور Docker ، خذ بضع دقائق للمراجعة:
https://github.com/floydhub/dockerfiles

هنا يقوم بإنشاء شجرة كاملة من Dockerfiles. عندما تنزل إلى أسفل الشجرة ، تجد مجموعات مختلفة من التبعيات ، كل منها من المستوى أعلاه في الشجرة. لذلك إذا اتبعت الشجرة من
-ubuntu->common-deps->python3->deepLearningBase->pyTorch
وأردت حقًا

-ubuntu->common-deps->python3->deepLearningBase->pyTorch 
+
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow 

كل ما ستفعله هو إضافة عقدة (مجلد) ضمن deepLearningBase لكليهما ، على سبيل المثال
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow-pyTorch

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

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

ثم ستتبع الشجرة إلى التصميم المطلوب ، وإذا لم يصنعها أي شخص آخر بعد ، فما عليك سوى إضافة عقدة ودمج 2 أو 3 سطور apt-get وإنشاء بيئتك الجديدة.

هذا يشبه أسلوب التكوين "اختر مغامرتك الخاصة". سيكون INCLUDE أبسط كثيرًا. حسنًا ، أريد فقط إنشاء صورة gcc باستخدام nano حتى لا أضطر إلى تثبيت nano من apt-get في كل مرة!

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

هذه حالة استخدام مشابهة تمامًا لحالة cloutiertyler التي علق عليها cloutiertyler ، حيث لا ينطبق حل @ frranklinyu ولا الإنشاءات متعددة المراحل التي تم التعليق عليها بواسطة @ cpuguy83 :

• أ (دبيان: سترتش-سليم)
  
  
  
  • dockerfileAB -> B (بيثون: امتداد نحيف)
  
  
  • dockerfileAC -> D ([مرحلة البناء] python-slim)
    
    
    
    
    
    • dockerfileDE -> E (ghdl / ext: vunit)
    
    
    
  
  
  • dockerfileAC -> C (ghdl / run: stretch-mcode)
  
  

أين:

• الخطوات من A إلى C هي بالضبط نفس الخطوات من B إلى D (ملف DockerfileAC).
• لا يعرف فريق تطوير B شيئًا عن C أو D أو E.
• لا يعرف فريق تطوير C شيئًا عن B أو D أو E.

يجب أن يكون لدى المستخدم الذي يرغب في إنشاء D (و / أو E) حق الوصول إلى dockerfileAC ، ولكن ليس مطلوبًا معرفة ملف dockerfileAB. لذلك ، يجب أن يكون لدى المستخدم فهم أفضل لتبعية واحدة (ج) من الأخرى (ب). من الناحية المثالية ، يجب أن يكون من الممكن الاعتماد على الفريقين A و B ، وبناء D فقط إما A + (diff(B,A) + diff(C,A)) (دمج) أو A + diff(B,A) + diff(C,A) (تغيير الأساسي).

نظرًا لأن GHDL ليست خدمة ويب و VUnit ليست عميل ويب ، يجب تثبيت كلتا الأداتين في نفس الصورة / الحاوية (E). لا تعد عمليات الإنشاء متعددة المراحل مفيدة ، لأننا نحتاج إلى إنشاء ملف dockerfile (ربما غير معروف) بملصقتين FROM ، فهي ليست سلسلة أمامية واحدة.

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

@ 1138-4EB راجع https://github.com/moby/buildkit

مذهل أن هذا لا يزال قضية وموضوع. ما مدى صعوبة "تضمين بعض الصور" ، ثم عند تحليلها ، تحقق من توافق القاعدة (في سلسلة FROM) وإذا كان الأمر كذلك ، فقم بتنفيذ بقية ملف ذلك في تلك المرحلة (كما لو كنت قد نسخت Dockerfile من المشروع ولصقها في لي)؟

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

rainabba هذا تعليق غير مفيد على
هناك سببان أساسيان وراء عدم القيام بذلك ، إما:

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

في الواقع ، عادة ما يكون كلاهما.

1. إنها مشكلة تحليل واستبدال سلسلة يمكن لأي مبرمج جديد أن ينجزها في كل 10 دقائق إذا عرف مكانه في الكود. أنا لا أقول أنه سيكون قابلاً للاستخدام في جميع الحالات ، ولكن بالنسبة للحالات المحدودة التي أراها مقترحة هنا مرارًا وتكرارًا (حيث تكون القواعد شائعة بشكل فعال) ، فهي لعبة قتال.

2. بالطبع لا ، يوفر هذا الخيط 102 سببًا لا يمكن أو لا ينبغي القيام به ، فلماذا يفكر أي شخص في القيام بذلك بغض النظر؟

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

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

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

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

لاحظت أن أحد زملائي يستخدم النمط التالي ، والذي قد يكون حلاً مناسبًا:

ARG from
FROM $from
... rest of dockerfile

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

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

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

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

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

أشعر أن شيئًا مثل INCLUDE سيكون مفيدًا جدًا

لدي دعم لوحدات الماكرو في https://github.com/larytet/dockerfile-generator/ يمكنني دعم "تضمين" أيضًا.

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

من فيدورا
تشمل ubuntu / ubuntu
تشمل دبيان / ديبيان

بشكل معقول ، أتوقع أن يبدأ هذا بصورة فيدورا.
ثم أضف صورة ubuntu ضمن المجلد / ubuntu. ثم أضاف
صورة دبيان تحت / debian.

هذا بالطبع سخيف ، ولهذا السبب أريد أن أخلط بين مجموعة من العمليات
أنظمة في صورة واحدة؟ لكن قد يكون المثال الأكثر فائدة:

من فيدورا
تشمل الصفيف من نوع plex / من نوع plex
تشمل commericalremover / plex / add-on / commerical remover

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

يوم الأربعاء ، 8 أغسطس 2018 ، الساعة 15:48 ، أركادي مياسنيكوف ، إخطارات github.com
كتب:

أشعر بشيء مثل INCLUDE
لدي دعم لوحدات الماكرو في
https://github.com/larytet/dockerfile-generator/ يمكنني إضافة "include"
دعم أيضا.

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

هذا الأخير ممكن بالفعل ؛ يقبل COPY --from كلاً من مرحلة البناء أو الصورة ، على سبيل المثال ؛

FROM busybox

COPY --from=alpine:latest / /
COPY --from=docker:latest /usr/local/bin/docker /usr/local/bin/

تعديل؛ أو لأخذ المثال الفعلي ؛

FROM fedora

COPY --from=ubuntu:latest / /ubuntu/
COPY --from=debian:latest / /debian/

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

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

يعتبر،

فاتورة

يوم الخميس ، 9 أغسطس 2018 الساعة 12:55 ، سيباستيان فان ستيجن إخطارات @github.com
كتب:

هذا الأخير ممكن بالفعل ؛ COPY - من يقبل كلا من أ
مرحلة البناء ، أو الصورة ، على سبيل المثال ؛

من BUSYBOX

نسخة - من = جبال الألب: الأحدث / /
نسخة - من = عامل إرساء: الأحدث / usr / local / bin / docker / usr / local / bin /

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

thaJeztah لا يزال استخدام

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

المشكلة التي يتم ذكرها أحيانًا لصور "أساسية" مختلفة (امتداد مقابل ubuntu مقابل جبال الألب مقابل ...) ، مع ذلك ، _is_ بسيط: يتطلب ألا يكون لـ DAG تبعيات الصورة مصدر واحد فقط (الصورة الحالية) ولكن أيضًا حوض واحد ("السلف" المشترك لجميع الصور في "التسلسل الهرمي").

في النهاية ، بالطبع ، ستحصل على القمامة في القمامة - هل الأمر مختلف تمامًا ، حقًا؟

FWIW ، حالات الاستخدام الخاصة بي هي:

1. تشغيل تطبيق ويب Tomcat مع قاعدة بيانات PostgreSQL ومخزن عناصر S3.
   بينما يمكن حل هذا باستخدام Docker Compose ، قد تكون الحاوية الواحدة أجمل.
2. تعمل الإنشاءات متعددة اللغات في حاويات Docker (على سبيل المثال في Jenkins و Circle CI ...).
   هناك صور رسمية لسلاسل الأدوات الأكثر شيوعًا ، ولكن الحصول على حاوية واحدة مجهزة للتعامل مع أكثر من تشغيل واحد في المشكلة التي تمت مناقشتها هنا بالضبط.

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

• https://github.com/avirshup/DockerMake
• http://docteurklein.github.io/2015/01/11/docker-auto-builds-and-me/
• https://blog.dockbit.com/templating-your-dockerfile-like-a-boss-2a84a67d28e9
• https://github.com/larytet/dockerfile-generator/

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

يعد طلب الميزة هذا شائعًا ولكن Docker مجاني كما هو الحال في Beer ولكن ليس بأي حال من الأحوال مجانيًا كما في Freedom.

rjurney مع تضمين دعم buildkit منذ 18.06 ، يمكن للمستخدمين توفير محلل الواجهة الأمامية للمُنشئ. يوجد بالفعل محلل Dockerfile تجريبي رسمي (من Docker Inc) يتضمن الكثير من الميزات الجديدة (دعم الأسرار للمبتدئين).

يمكنك بالطبع أيضًا إضافة سلوك "INCLUDE" الخاص بك في واجهة Dockerfile الأمامية المخصصة ، أو يمكنك القيام بشيء مختلف تمامًا ليس Dockerfile على الإطلاق (هناك مثال على buidpacks).

لاستخدام واجهة أمامية مخصصة ، ما عليك سوى توجيه Docker إلى صورة يمكنها التعامل معها. افعل ذلك كتعليق على السطر الأول من ملف Dockerfile (أو أي شيء سيكون) syntax = myCustomFrontendImage

مزيد من التفاصيل هنا:
https://docs.docker.com/develop/develop-images/build_enhancements/#overriding -default-frontends

مع تمكين buildkit ، يمكن لـ Docker إنشاء كل ما تريده (ليس بالضرورة أن يكون تنسيق Dockerfile) بأي ميزات تحتاجها.

يعد طلب الميزة هذا شائعًا ولكن Docker مجاني كما هو الحال في Beer ولكن ليس بأي حال من الأحوال مجانيًا كما في Freedom.

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

reitzig من الواضح أن هذا مجرد

لم أكن أعلم أنه تم ترخيص أباتشي الآن. أعتذر عن الملاحظة و
أعتقد أن هذا رائع!

رسل جورني rjurney http://twitter.com/rjurney
راسل. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

يوم الأربعاء ، 16 يناير 2019 ، الساعة 4:17 صباحًا ، كتب Raphael R. [email protected] :

طلب الميزة هذا شائع ولكن Docker مجاني كما هو الحال في Beer ولكن ليس من قبل
بأي وسيلة مجانية كما في Freedom.

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

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

أنا آسف ، لم أنم جيدًا وقد أخطأت. تعليقي يقف.
Free كما في Beer يعني Apache. Free كما في Freedom يعني سيطرة المجتمع.
مشروع أباتشي أو شكل آخر من أشكال الحكم.

رسل جورني rjurney http://twitter.com/rjurney
راسل. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

يوم الأربعاء 16 كانون الثاني (يناير) 2019 الساعة 12:32 مساءً Russell Jurney [email protected]
كتب:

لم أكن أعلم أنه تم ترخيص أباتشي الآن. أعتذر عن الملاحظة و
أعتقد أن هذا رائع!

رسل جورني rjurney http://twitter.com/rjurney
راسل. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

يوم الأربعاء 16 يناير 2019 الساعة 4:17 صباحًا Raphael R. [email protected]
كتب:

طلب الميزة هذا شائع ولكن Docker مجاني كما هو الحال في Beer ولكن ليس من قبل
بأي وسيلة مجانية كما في Freedom.

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

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

Free كما في Beer يعني Apache.

تعارض. يمكن أن تكون البرامج المجانية برامج مملوكة.

Free كما في Freedom يعني سيطرة المجتمع.

ما هي سيطرة المجتمع؟ المشاريع التي تديرها مؤسسة؟ إذن هل تعتبر VS Code و Atom Editor و Ubuntu برامج غير حرة؟ ثم يختلف تعريفك بشكل كبير عن التعريف الذي تقترحه FSF و EFF والعديد من المنظمات الأخرى.

أوافق على أن Docker Inc لا تناقش بنشاط مع المجتمع في هذه القضية ، لكن هذا لا علاقة له بـ "Free as in Freedom".

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

أوافق على أن Docker Inc لا تناقش بنشاط مع المجتمع في هذه المسألة

لقد جعلنا من الممكن دعم أي تنسيق بناء تريده عبر docker build . لا يدعم تنسيق Dockerfile "الرسمي" هذا الخيار ، لكن هذا لا يعني أن docker build لا يمكنه الاستفادة منه.
تحقق من https://matt-rickard.com/building-a-new-dockerfile-frontend/ كمثال لبناء واجهة أمامية مخصصة تعمل بـ docker build .
لاحظ أن هذه الواجهة هي مثال على كيفية القيام بشيء مختلف تمامًا عن تنسيق Dockerfile ، لكن هذا ليس ضروريًا. يمكنك استخدام تنسيق Dockerfile الحالي وإضافة الوظائف الخاصة بك إذا أردت.

بقدر إضافة شيء ما إلى تنسيق Dockerfile الرسمي .... سأقول إن المقترحات مرحب بها دائمًا ، يتم الاحتفاظ بالتنسيق في https://github.com/moby/buildkit.
ومع ذلك ، ضع في اعتبارك أن كل ميزة جديدة تعني عبئًا جديدًا للصيانة ، بما في ذلك في كثير من الأحيان الحد مما يمكن القيام به في المستقبل.

أعتقد أنه من المحتمل أن العديد من حالات الاستخدام للجمع بين عدة ملفات Dockerfiles يمكن حلها بالفعل باستخدام وظائف جديدة في Dockerfile ... تحديدًا القدرة على COPY --from و RUN --mount من الصور التعسفية.

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

ماذا لو كنت تستطيع أن تفعل هذا:

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   custom image (with both python and rust)
             \                                 /
              \----- rust:1.44-alpine3.12 ----/

_ لاحظ أن كلتا الصورتين من نسل نفس الصورة. هذا هو المفتاح!

بهذه السهولة:

FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

_بالمقارنة مع استخدام التعليمات "COPY - from image" (نسخ متعددة المراحل) ، لن تضطر إلى التفكير في تفاصيل التنفيذ (أي الملفات / متغيرات البيئة يجب نسخها) ._

كيف تبدو الآن إذا كنت تريد دمج الصور

FROM alpine:3.12.0

# INCLUDE rust:1.44-alpine3.12
COPY --from=rust:1.44-alpine3.12 / /
ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH \
    RUST_VERSION=1.44.1

# INCLUDE python:3.8.3-alpine3.12
COPY --from=python:3.8.3-alpine3.12 / /
ENV PATH /usr/local/bin:$PATH
ENV LANG C.UTF-8
ENV GPG_KEY E3FF2839C048B25C084DEBE9B26995E310250568
ENV PYTHON_VERSION 3.8.3
ENV PYTHON_PIP_VERSION 20.1.1
ENV PYTHON_GET_PIP_URL https://github.com/pypa/get-pip/raw/eff16c878c7fd6b688b9b4c4267695cf1a0bf01b/get-pip.py
ENV PYTHON_GET_PIP_SHA256 b3153ec0cf7b7bbf9556932aa37e4981c35dc2a2c501d70d91d2795aa532be79

_ENV- يتم نسخ التعليمات من ملفات Docker لهذه الصور.

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

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

bergkvist ، راجع https://github.com/moby/moby/issues/3378#issuecomment -381449355 و https://github.com/moby/moby/issues/3378#issuecomment -381641675.

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

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   \
             \                                   \
              \----- rust:1.44-alpine3.12 --------\ custom image 

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

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

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

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

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

منذ أن علقت هنا قبل 4 أيام ، قررت أن أتعلم Golang ، وأن أنظر إلى كود الواجهة الأمامية لكود moby / buildkit.

لقد قمت الآن بإنشاء واجهة أمامية مخصصة تقبل عبارات INCLUDE كما ناقشتها أعلاه.

#syntax=bergkvist/includeimage
FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

لاستخدام بناء الجملة المخصص ، تذكر تعيين DOCKER_BUILDKIT = 1 عند البناء.

DOCKER_BUILDKIT=1 docker build -t myimage .

الكود متاح هنا: https://github.com/bergkvist/includeimage
والصورة على Docker Hub: https://hub.docker.com/r/bergkvist/includeimage