Moby: إعادة تعيين الخصائص الموروثة من الصورة الأصلية

نرحب بالاقتراحات لبناء الجملة.

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

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

هل يوجد حل لهذا في الوقت الحالي؟ أقوم بتوسيع صورة باستخدام نقطة الدخول (https://github.com/jagregory/pandoc-docker/blob/master/Dockerfile) وأحتاج إلى إلغاء تعيين نقطة الدخول. حاولت استخدام ما يلي في Dockerfile الخاص بي:

FROM jagregory/pandoc
ENTRYPOINT [] # this basically gets ignored (bug?)

FROM jagregory/pandoc
ENTRYPOINT [""] # this will make docker try to exec '' (the empty string)

FROM jagregory/pandoc
ENTRYPOINT ["/bin/sh", "-c"] 
# this will only work if docker run args are quoted:
#   docker run dergachev/pandoc "echo a b c"

شكرا!

أرغب بالتأكيد في الحصول على طريقة ما لإزالة نقاط VOLUME الموروثة من الصور الأصلية.

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

فقط للتحديث من تعليق dergachev ، كان CMD [] و ENTRYPOINT [] يعملان في المرة الأخيرة التي اختبرتها فيها مؤخرًا ، ولا يزال من المفترض أن يعمل (أي شيء آخر سيكون جاهزًا لحفظ الأخطاء).

يمكنك إعادة تعيين جميع أوامر الخيار الفردي عبر

ENTRYPOINT []
CMD []
USER 0
WORKDIR /

يجب أن يترك هذا البيانات الوصفية المتبقية غير القابلة لإعادة الضبط مثل ENV ، VOLUME ، EXPOSE وربما ONBUILD .

(هذا قادم من # 8709)

إذا عرّضت مآخذ 9000-9002 في الوالد ، لكنني كنت بحاجة إلى إلغاء تعريض 9001 في الطفل ، فسأضطر حينئذٍ إلى الكتابة بأسلوب "عدم الضبط"

تعرض
اكسبوس 9000
اكسبوز 9002

الذي سيعمل ولكن

UNEXPOSE 9001

تبدو أجمل.

الميزة هي أنه لا يؤثر على أي تعرض من أعلى سلسلة الوراثة ، والتي قد أرغب في إضافتها لاحقًا.

+1 @ codeon-nat

تمت مناقشة هذا في # 8177 ، ونحن نغلق هذا لعدم وجود حالات استخدام في العالم الحقيقي.

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

أوافق ، على سبيل المثال ، على تمديد صورة nginx لبرنامج تفريغ SSL وأريد UNEXPOSE 80 لكن اترك 443 .

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

بغض النظر ، كان هذا مجرد تكوين سيء من جانبي.

(15 أبريل: "لا توجد حالات استخدام في العالم الحقيقي" ، فأنا مندهش من أنه لا يمكنك تخيل واحدة على الأقل وأغلقت هذا)

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

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

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

إضافة حالة استخدام إضافية - أنا أرث من صورة RabbitMQ الرسمية ، لكني أريد فقط كشف منافذ websocket (80 و 443) وليس منفذ AMQP الافتراضي (5672). يبدو أن هذا يجب أن يكون شيئًا معقولًا جدًا تريد القيام به؟

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

+1

الوراثة من php الرسمي وتريد استخدام مآخذ بدلاً من المنافذ ، لذا تحتاج إلى إزالة منفذ 9000 المكشوف

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

shykesicecrime كيف يتم هذا مغلقة الآن؟ هل من الصعب جدًا حلها باستخدام البنية الحالية وتحتاج إلى التوافق مع الإصدارات السابقة؟ ما هي الخطة؟

+1 - حالة استخدام العالم الحقيقي لتجاوز EXPOSE هنا.

بالنظر إلى أن هذا الأمر مستمر منذ أكثر من 3 سنوات (تم العثور على مشكلة يعود تاريخها إلى 2013) متى سنتمكن من إزالة المنافذ المكشوفة؟

+1. يجب أن تكون قادرًا على "UNEXPOSE" منفذي nginx الافتراضيين 80 و 443.

لهؤلاء الناس هنا يطلبون UNEXPOSE ؛ تعطي العبارة EXPOSE تلميحًا عن المنافذ المكشوفة بواسطة الحاوية ، لكنها لا تعرض هذه المنافذ في الواقع ؛ تحتاج إلى _publish_ تلك المنافذ ( -p / -P ) لعرضها على المضيف. بعبارات أخرى؛ حذف العبارة EXPOSE من ملف Docker لا يؤثر بشكل مباشر على الصورة (لا يزال بإمكانك ، على سبيل المثال ، الوصول إلى "المنفذ 80" من الحاوية).

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

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

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

kgx لا يسبب أي ضرر (بصرف النظر عن السمة المحتملة) ، ولكن أراد أن أوضح أن عدم القدرة على " UNVOLUME (أو UNSET VOLUME ) مدرجًا في قائمة أمنياتي الشخصية. :-)

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

إليك حالة استخدام: أنا أستخدم صورة عامل الإرساء الافتراضية لـ go-ethereum ، وأريد أن أكون قادرًا على إعداد إصدار تجريبي لن يتصل أبدًا بالعالم الخارجي. أحتاج إلى أن أكون قادرًا على الاتصال به من المضيف والحاويات الأخرى. الطريقة الأكثر أمانًا للقيام بذلك هي تغيير المنافذ لأن البرنامج يحاول بشدة الاتصال بالأقران. أحتاج أيضًا إلى أن أكون قادرًا على تجاوز CMD و ENTRYPOINT لإنشاء نسخة "إعداد قاعدة البيانات" من الصورة التي أقوم بتشغيلها مرة واحدة للحصول على الحجم المناسب الذي تم إنشاؤه. من الصعب للغاية سحب كل هذه الأشياء في Dockerfile.

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

--- مرسلة من بوكسر | http://getboxer.com

في 20 فبراير 2016 الساعة 08:57:00 بتوقيت جرينتش ، كتب barkthins [email protected] : هذه حالة استخدام: أنا أستخدم صورة عامل الإرساء الافتراضية لـ go-ethereum ، وأحتاج إلى أن أكون قادرًا على إعداد اختبار الإصدار الذي لن يتصل مطلقًا بالعالم الخارجي. أحتاج إلى أن أكون قادرًا على الاتصال به من المضيف والحاويات الأخرى. الطريقة الأكثر أمانًا للقيام بذلك هي تغيير المنافذ لأن البرنامج يحاول بشدة الاتصال بالأقران. أحتاج أيضًا إلى أن أكون قادرًا على تجاوز CMD و ENTRYPOINT لإنشاء نسخة "إعداد قاعدة البيانات" من الصورة التي أقوم بتشغيلها مرة واحدة للحصول على الحجم المناسب الذي تم إنشاؤه. من الصعب للغاية سحب كل هذه الأشياء في Dockerfile. —رد على هذا البريد الإلكتروني مباشرةً أو اعرضه على GitHub.

يمكن تجاوز CMD و ENTRYPOINT في وقت التشغيل ؛ docker run --entrypoint=foo myimage mycmd . السؤال هنا هو ما إذا كان من المفيد الحصول على صورة مختلفة ، بنقطة إدخال مختلفة / cmd أثناء الاختبار ، حيث لن تكون _اختبار_ الصورة الفعلية التي سيتم تشغيلها في الإنتاج. (مجرد ملاحظة جانبية)

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

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

من صفحة دليل Dockerfile:

     -- EXPOSE <port> [<port>...]
     The EXPOSE instruction informs Docker that the container listens

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

• النظام.*
  [...]
  التاريخ
  * مايو 2014 ، جمعه زاك دوفر (zdover at redhat dot com)
  على وثائق Docker.com Dockerfile. * فبراير 2015 ، تم التحديث بواسطة Brian Goff (
  [email protected])
  لسهولة القراءة * سبتمبر 2015 ، تم التحديث بواسطة Sally O'Malley (
  [email protected])

تبدو [خطتي المائلة] مضللة (أو على الأقل غامضة) إذا كان ما تقوله كذلك
صحيح.

يوم الخميس ، 28 من كانون الثاني (يناير) 2016 الساعة 6:43 صباحًا ، سيباستيان فان ستيجن <
[email protected]> كتب:

لأولئك الناس هنا يسألون عن UNEXPOSE ؛ بيان EXPOSE فقط
يعطي _hint_ المنافذ التي تتعرض لها الحاوية ، لكنها لا تعرضها
في الواقع _expose_ تلك المنافذ ؛ تحتاج إلى _publish_ تلك المنافذ (-p / -P)
لفضحهم على المضيف. بعبارات أخرى؛ حذف بيان EXPOSE
من ملف Dockerfile _ no_ تأثير مباشر على الصورة (يمكنك ذلك
لا يزال ، على سبيل المثال الوصول إلى "المنفذ 80" من الحاوية).

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

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

شارك حاليًا في تأليف كتاب على Docker: احصل على خصم 39٪ باستخدام الرمز 39miell
http://manning.com/miell/؟a_aid=zwischenzugs&a_bid=e0d48f62

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

thaJeztah نحن بحاجة إلى كشف

هناك العديد من الحلول التي تقرأ البيانات الوصفية للحاوية وتوفر تكوينًا إضافيًا في المنبع. فمثلا؛ مع HAPROXY ، لا بد لي من تعيين EXCLUDE_PORTS=8080 لمنعه من محاولة توفير الوصول الديناميكي إلى هذا المنفذ على تطبيقات Tomcat الخاصة بي.

ينظر المطورون إلى المنافذ المكشوفة ويضعون افتراضات حول سلوك الحاوية. على سبيل المثال ، لدي صورة أساسية تمتد إلى Tomcat (EXPOSE 8080) ولكن الصورة تستخدم منفذًا مختلفًا عن المنفذ الافتراضي (EXPOSE 8888). إذا قمت بإضافة خادم ويب في صورة مركبة (على سبيل المثال ، تشغيل NGINX و Tomcat) ، فأنت تقدم المحتوى عبر HTTP (EXPOSE 80 و EXPOSE 443).

في المثال الأخير ، يمكنك الحصول على صورة توثق ذاتيًا على أنها تعرض 8080 و 8888 و 80 و 443 حيث يكون 80/443 مناسبًا فقط.

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

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

ما هو الوضع على هذا؟

حالة BillBrower هي أنهم أغلقوا المشكلة دون تقديم مبرر لسبب اعتقادهم أنها ليست مشكلة. من الواضح بالنسبة للكثيرين منا أنها لا تزال تمثل مشكلة عالمية حقيقية تصيب حياتنا اليومية ؛)

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

تم إغلاق العلاقات العامة التي نفذت هذا لأن هناك مشرفين غير متأكدين من الميزة ، ويبحثون عن المزيد من الأمثلة الفعلية لاستخدامها ؛ https://github.com/docker/docker/pull/8177#issuecomment -93587164

نحن نغلق هذا لأننا لا نتفق في الغالب ، ولكن لا تتردد في إثبات خطأنا في التعليقات ويمكننا إعادة النظر

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

شكراthaJeztah. هذا يجعل الامر منطقيا. أنا أقدر لك شرح السبب المنطقي وراء القرار الأصلي وتحديد ما تحتاج إلى رؤيته إذا كنا نريد أن يحدث هذا.

حالة استخدام واحدة لطلب _UNVOLUME_

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

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

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

ملاحظة: لا يمكنني استخدام أمر docker volume لأن كل ذلك بدأ بواسطة Marathon ويجب أن يكون قابلاً للاستخدام في أمر تشغيل عامل إرساء واحد.

+1 UNEXPOSE المطلوبة

+1 ل UNEXPOSE

+1 ل UNEXPOSE

+1 ل UNEXPOSE

+100 ل UNEXPOSE

+9000 ل UNEXPOSE

+ ∞
على سبيل المثال ، أستخدم المستودع الرسمي nginx (من nginx: مستقر) ، والذي يحتوي على ملف Docker:

EXPOSE 80 443

لكنني أريد أن أزيل طبقة أخرى ، المنفذ 80. على سبيل المثال:

UNEXPOSE 80

لو سمحت!
أضف هذه الميزة !!!!

frekele ، إذا كنت والدتك أو والدك ، فلن تحصل عليه. مستحيل.

UNEXPOSE +++
ميزة ضرورية للغاية!

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

underyx هذا بعيد المنال ، لكنني سأعض لأنني ما زلت أرى الناس يقولون هذا. إنه أكثر دقة مما تعتقد. بالنسبة للعديد من الفرق الكبيرة ، فإن عدد التعليقات على قضية ما هو الطريقة الوحيدة لقياس المشاركة ، حيث تم تصميم ردود الفعل كميزة اجتماعية - وليست آلية تصويت ، وبالتالي فهي ليست طريقة موثوقة لتشغيل التقارير عبر GH API (على سبيل المثال غير قابل للفرز ، من بين أشياء أخرى). إضافةً إلى ذلك ، تؤدي إضافة تعليق إلى اشتراكي تلقائيًا في سلسلة الرسائل ، وهو ما أريده في معظم الحالات - وإلا سأضطر إلى النقر فوق 👍 _و_ أيضًا النقر فوق "اشتراك".
راجع https://github.com/isaacs/github/issues/9#issuecomment -195120703 (الخيط بأكمله جيد ، لكن هذا هو الوقت الذي أضاف فيه GH ردود الفعل).
الآن دعونا لا نشوش المناقشة ؛)
/offtopic .

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

duglin هل ربما أنت مهتم بالعمل على هذا؟

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

EXPOSE  (all or specific one)
ENV  (specific - not sure we need to clear all yet)
LABEL  (ditto)
VOLUME  (all or just specific paths? probably both)
CMD  (possible but only using the json format)
ENTRYPOINT  (possible with json format)

هل فوت اي شيء؟

+10000 لمستوى UNVOLUME

duglin أعتقد أن البدء بالأشياء غير الممكنة حاليًا ، والأكثر طلبًا سيكون الأفضل ( EXPOSE ، VOLUME ). لم أر العديد من الطلبات للآخرين (لكن ليس ضدها).

استخدم PR الأصلي UNSET <SOMETHING> ، ولكن تم تغييره لاحقًا إلى UN<SOMETHING> . أنا _ شخصيًا_ أحببت أول واحد أكثر (أكثر عمومية) ، لكن @ shykes فضل UN<SOMETHING> ، لست متأكدًا مما إذا كان ذلك قد تغير.

UNVOLUME سيكون رائعًا.

حالة الاستخدام الخاصة بي: أنا أستخدم صورة mysql وأريد تثبيت قاعدة البيانات الخاصة بي الموجودة في الدليل /var/lib/mysql جديدة ولكن لا يمكنني ذلك لأنه تم الإعلان عن وحدة تخزين في ملف Dockerfile الأصلي.

thaJeztah أجد UNSET <something> أسهل في القراءة وليس غريبًا ؛ لا حاجة للبدء في اختراع الكلمات. إنه مألوف أيضًا عند كتابة البرامج النصية للناس. يمكن للمرء أن يفعل أيضا

UNSET  EXPOSE VOLUME LABEL

مثالي ،

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

يمكنني تعديل الصورة الأساسية إلى UNVOLUME تلك المجلدات ولكن بعد ذلك سأحتاج إلى الحفاظ على تلك الصورة إلى الأبد ... ذهب سحر استخدام "الأحدث" :(

+1 ل UNEXPOSE :)

+1 لحجم غير محدد أو أفضل من ذلك.

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

دون القلق بشأن الاضطرار إلى تحميل وحدات التخزين.

لا أعتقد أنه ستكون هناك حاجة لذلك ؛ ينشئ تعريف VOLUME في Dockerfile تلقائيًا وحدة تخزين "مجهول" من المحتوى في ذلك الموقع في الصورة.

duglin ، هل تعمل بالفعل على هذا؟ إذا لم يكن الأمر كذلك ، فسوف آخذه وأبدأ بأكثر طلب (الحجم والتعرض). دعني أعلم.

runcom اذهب لذلك - لم أتمكن من العثور على الوقت حتى الآن.

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

سيكون من الممكن إزالة VOLUME و EXPOSE من الصور الرسمية إذا
هم مشكلة.

في 28 يناير 2017 21:23 ، كتب "henryptung" [email protected] :

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

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

+1 لـ UNVOLUME

+1 لـ UNVOLUME

حالة الاستخدام الخاصة بي لـ UNVOLUME:

استخدام مكتبة / صور worpress في سيناريو S2I حيث يتم نسخ مصدر موقع الويب إلى / var / www / html

يضغط VOLUME على ذلك عن طريق تركيب FS فارغ على الصورة الناتجة. -> مكتبة / وورد لا يمكن استخدامها.

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

يقوم أمر docker run بتهيئة وحدة التخزين المنشأة حديثًا بأي بيانات موجودة في الموقع المحدد داخل الصورة الأساسية.

https://docs.docker.com/engine/reference/builder/#/volume

هناك حل بديل باستخدام أداة حفظ / تحميل عامل الإرساء ، راجع http://stackoverflow.com/q/42316614/808723

+1 لـ UNVOLUME

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

+1 لـ UNVOLUME ، UNEXPOSE ، UNENV ، ...

يبدو أن هذا كان مفتوحًا منذ فترة. أي جر هنا؟
أريد أيضًا استخدام صورة PHP fpm alpine الرسمية ومآخذ UNIX بدلاً من منفذ TCP 9000.
لا يمكن تجاوز EXPOSE من الأصل ، ويفضل عدم إنشاء تلك الصورة لمجرد التخلص من EXPOSE.

+1

+1

أحب القدرة على إلغاء تعيين أمر مستوى الصوت. تقوم الصورة الرسمية لـ Wordpress بتفريغ قاعدة الشفرة الكاملة الخاصة بها بقوة في مجلد - أفضل كثيرًا وجود مجلد فقط لمجلد wp-content / uploads حتى يمكن تخزين باقي قاعدة التعليمات البرمجية في الصورة.

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

+1 مني

حالة الاستخدام ل UNEXPOSE

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

تخيل الآن أنني أستخدم المسجل مع rancher CNI - والذي يقفلني على المنفذ الداخلي.
https://github.com/gliderlabs/registrator/issues/541#issuecomment -305012416
هذا يعني أنه يمكنني تشغيل منفذ داخلي واحد فقط 8080 لكل مضيف. (بما أنني يجب أن أفعل تعيينات المنافذ 8080: 8080)

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

جوليان ، لا أعرف كيف لديك تعيين 1 إلى 1. بالنسبة لي المسجل باسم
لا علاقة له بتوجيه حركة المرور ، فهو يسجل فقط ويلغي التسجيل
تشغيل الحاويات. على سبيل المثال ، أستخدمه بطريقة سيحافظ عليها المسجل
مثيل Etcd عن طريق وضع IP المخصص لـ Docker والمنفذ المكشوف في
هناك. ثم باستخدام confd ، ستشاهد مثيل Etcd وتقوم بتحديث nginx
التكوين في الحاوية الخاصة به.
يوم السبت ، 17 يونيو 2017 الساعة 04:06 ، Julian Gamble [email protected]
كتب:

حالة الاستخدام ل UNEXPOSE

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

تخيل الآن أنني أستخدم المسجل مع Rancher CNI - والذي يغلقني
إلى المنفذ الداخلي.
gliderlabs / المسجل # 541 (تعليق)
https://github.com/gliderlabs/registrator/issues/541#issuecomment-305012416
هذا يعني أنه يمكنني تشغيل منفذ داخلي واحد فقط 8080 لكل مضيف. (منذ لدي
للقيام 8080: 8080 تعيينات المنافذ)

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

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

مرحبا برادلي ،

شكرا لاطلاعك على هذا. أنا أستخدم المسجل بالاشتراك مع ipsecurity المدمج في Rancher. كما ترى من الرابط هنا:
https://github.com/gliderlabs/registrator/issues/541#issuecomment -305012416
تم تقييد إمكانية عرض المنافذ الخارجية في المسجل في حاويات المزارع المجدولة. هذا يعني أنه يمكنك استخدام المنافذ الداخلية فقط.

يمكنك أن ترى أن هناك مستخدمين يبدأون القلق بحثًا عن حل هنا:
https://forums.rancher.com/t/do-you-kill-registrator/5152

والحل المقترح هنا:
https://github.com/cabrinoob/rancher-registrator
(وهو ما لم يكن ممكنا لبعض الناس).

قد تجد المزيد إذا قمت بالبحث في Google عن "registrator rancher".

يوصون بتشغيل المسجل في الوضع "الداخلي" - حيث تقوم بتعيين المنافذ الداخلية الخاصة بك 1: 1 إلى المنافذ الخارجية الخاصة بك. يؤدي هذا إلى مشكلة مع UNEXPOSE - نفاد المنافذ الداخلية بسرعة.

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

شكرا لاطلاعك على هذا.

هتافات
جوليان

مرت 3.5 سنوات ولم يحرز أي تقدم في هذه القضية؟ ...

+10086 لـ UNEXPOSE. في بعض الأحيان قد لا تكون الصورة الأصلية رسمية ، فهي تستخدم منافذ غير رسمية ، يجب أن تكون لدينا القدرة على الكتابة فوق المنافذ.

@ pumba-lt
أراهن أن سبب عدم رؤية هذا القرار هو أنهم لا يعرفون كيفية القيام بذلك تقنيًا.

كما أنه يضيف تعقيدًا إلى لغة Dockerfile عندما تكون هناك حلول بديلة واضحة. لا تضغط كثيرًا على التكوين في Dockerfile الأصلي واترك إذا كان للصور الموروثة بدلاً من ذلك. (الملقب: توقف عن تحديد مصادر الصور العشوائية على Docker hub: D)

نظرًا لأن docker 17.05 ، هناك أيضًا طريقة جديدة للقيام بالبنيات متعددة المراحل التي تزيل معظم الحاجة لهذه المشكلة (هذا هو Dockerfile ):

# First import the original image
FROM nginx AS source-image

# Second step of the build, start with an empty image
FROM scratch
# Copy the data from the original image
COPY --from=source-image / /
# Re-define all the config
EXPOSE 80
STOPSIGNAL SIGTERM
CMD ["nginx", "-g", "daemon off;"]

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

zimbatm - هذا رائع!

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

التغيير في حد ذاته ليس معقدًا للغاية ؛ يمكن العثور على تنفيذ في هذا PR ؛ https://github.com/moby/moby/pull/8177. لم يكن هناك إجماع في ذلك الوقت ، لكن إذا اتبعت تعليقي من يناير ؛ https://github.com/moby/moby/issues/3465#issuecomment -247405438 ، تغيرت الأمور و (ما لم يغير الناس رأيهم منذ ذلك الحين) ، فإننا نقبل مساهمة لتنفيذ ذلك.

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

zimbatm نعم ، nginx كأصل ، لذلك يمكن أن يؤدي إلى الحاجة إلى تنزيل المزيد من الصور. فمثلا؛

صورة nginx الأصلية:

$ docker inspect nginx -f '{{json .RootFS.Layers}}' | jq .

[
  "sha256:54522c622682789028c72c5ba0b081d42a962b406cbc1eb35f3175c646ebf4dc",
  "sha256:1c3fae42c5007fd0e70309b5b964eb5d49046562bd425424da734784098894e7",
  "sha256:87823f21b7939eac6e099fa878871a806c1904a7698793edb63bf6e5f5371e1f"
]

وصورة nginx التي أنشأتها ؛

$ docker inspect nginx2 -f '{{json .RootFS.Layers}}' | jq .
[
  "sha256:9a71ba430225d4f24e0d57837a71b6b2b68bf88ca7530c0a89c98783c98531b5"
]

شكرا لتحديث thaJeztah

هل لي أن أكرر اقتراحي لاستخدام

UNSET XXXX

بدلاً من اختراع مفردات جديدة وغريبة (على سبيل المثال: UNVOLUME).

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

UNSET VOLUME EXPOSE LABEL

أنا شخصياً موافق على القيام بعمل UNSET ، ربما لن يكون القيام بواحد أو الآخر تغييرًا كبيرًا ، لذلك سأترك ذلك لعملية المراجعة عند وصول العلاقات العامة

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

يتيح إما قبول هذا والعمل عليه أو رفضه

rajiff انظر تعليقي أعلاه https://github.com/moby/moby/issues/3465#issuecomment -313549657 المساهمات مرحب بها

التغيير في حد ذاته ليس معقدًا للغاية ؛ يمكن العثور على تنفيذ في هذا PR ؛ # 8177. لم يكن هناك إجماع في ذلك الوقت ، لكن إذا اتبعت تعليقي من يناير ؛ # 3465 (تعليق) ، تغيرت الأمور و (ما لم يغير الناس رأيهم منذ ذلك الحين) ، فإننا نقبل مساهمة لتنفيذ ذلك.

لذا ، إذا كان الإجماع قد تغير ، فلماذا لا نعيد فتح

لذا ، إذا كان الإجماع قد تغير ، فلماذا لا نعيد فتح # 8177؟

تم فتح هذا العلاقات العامة منذ أكثر من ثلاث سنوات ؛ لم يعد القانون ساريًا

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

يمكننا استخدام شيء مثل:
من الصورة الأساسية (VOLUME ، EXPOSE ، PORT ، ..)
أو إذا كنت تريده حقًا بالنفي:
من الصورة الأساسية (*، -VOLUME، -EXPOSE)
أو لديك صياغة أفضل ؛)

يبدو لي أن كل هذا يجب أن يكون جزءًا من أمر FROM في المقام الأول.

تغيير الحجم من داخل Dockerfile: إذا غيرت أي خطوات بناء البيانات داخل وحدة التخزين بعد الإعلان عنها ، فسيتم تجاهل هذه التغييرات.

لا يبدو هذا صحيحًا تمامًا. لا يزال بإمكانك القيام بذلك:

VOLUME /avolume/subdir
WORKDIR /avolume
COPY ./Dockerfile /avolume/subdir

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

لا يعمل تجاوز الصورة / الحاوية الرئيسية ENTRYPOINT في الإصدارات الأحدث.

17.09.1-ce

$ docker run --name=experiment --entrypoint=/bin/bash ubuntu:16.04
$ docker inspect experiment --format "{{.Config.Entrypoint}}"
[/bin/bash]
$ IMAGE=$(docker commit -c "ENTRYPOINT []" experiment)
$ docker inspect $IMAGE --format "{{.Config.Entrypoint}}"
[]

منذ إصدار 17.10.0-ce

$ docker run --name=experiment --entrypoint=/bin/bash ubuntu:16.04
$ docker inspect experiment --format "{{.Config.Entrypoint}}"
[/bin/bash]
$ IMAGE=$(docker commit -c "ENTRYPOINT []" experiment)
$ docker inspect $IMAGE --format "{{.Config.Entrypoint}}"
[/bin/bash]

UNSET ENTRYPOINT أيضًا لا يعمل.
هل هي حشرة؟

@ alexey-igrychev هل يمكنك فتح قضية منفصلة لذلك؟ المشكلة التي تعلق عليها هي _تطلب ميزة_ لتنفيذ تعليمات UNSET xx في ملف Dockerfile. (لم يتم تنفيذ التعليمات UNSET بعد ، لذلك هذا متوقع.)

كحل بديل لهذه المشكلة ، يبدو أن استخدام [""] بدلاً من [] لنقطة الإدخال يعمل ؛

IMAGE=$(docker commit -c "ENTRYPOINT [\"\"]" experiment)
docker inspect $IMAGE --format "{{.Config.Entrypoint}}"
[]

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

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

انظر تعليقي السابق (تعليقاتي) ؛ https://github.com/moby/moby/issues/3465#issuecomment -247405438

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

duglin هل ربما أنت مهتم بالعمل على هذا؟

و https://github.com/moby/moby/issues/3465#issuecomment -313549657

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

تأتي حالة الاستخدام الخاصة بي من docker-compose.yaml: أرغب في الحصول على ملف إنشاء للتطوير مع تجاوزات للإنتاج تضيف وكيل TLS العكسي ، مستودع Maven ، يستحوذ على PORT 80/443 ، ويفتح المنفذ 80 و 5432 الذي يعرض ملف تكوين التطوير. أو إنشاء ملف للإنتاج مع تجاوز التطوير.

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

شكرًا thaJeztah - هل يمكنك من فضلك توجيهنا إلى سطر التعليمات البرمجية الذي يعتبر

لم أعمل كثيرًا على كود المنشئ بنفسي ، ولكن من المحتمل أن تكون التغييرات في حزمة https://github.com/moby/moby/tree/master/builder .

هذه القضية لها 3 سنوات! هل من الصعب للغاية الاتفاق على ميزة أساسية ، أم أنني أفتقد شيئًا ما؟

caruccio نعم ، لقد فقدت شيئًا ما: مرر لأعلى 4 تعليقات https://github.com/moby/moby/issues/3465#issuecomment -356988520

لدي أيضًا حالتان من حالات الاستخدام (أحدهما مشروع شخصي ، والثاني مشروع عمل) حيث أرغب في زيادة تحميل كشف حساب VOLUME و EXPOSE و ENTRYPOINT من a صورة الوالد.

بينما لدي حل بديل لـ ENTRYPOINT بمجرد تعيين نقطة إدخال فارغة جديدة بـ ENTRYPOINT [] ، ويمكنني على الأرجح تعلم التعايش مع تجاهل EXPOSE ، ... رأسي حول كيفية عدم وراثة تعريفات VOLUME .

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

هناك حل.

يمكنك دائمًا docker save image -o image.tar ، فك ضغط هذا الأرشيف ، وتحرير البيانات الوصفية ، وإعادة حزم لـ docker load -i image2.tar . بهذه الطريقة يمكن للمرء إنشاء صورة 2 لا تحتوي على أي من إعلانات VOLUME السابقة فيها.

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

عمل رائع gdraheim ! حل عملي في أقل من 250 سطرًا من بيثون.

gdraheim نجاح باهر ، هذا رائع! من README:

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

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

لقد قمت بتوسيع docker-copyedit لتغطية جميع إدخالات البيانات الوصفية للصورة ، بحيث يمكنها العمل على جميع الخصائص الموروثة حتى بعد الحالات الإشكالية لقوائم EXPOSE و VOLUME. سيكون ذلك المستخدم ، والعمل ، والعلامات ، وإعدادات البيئة المحيطة بالأشياء التي نراها كثيرًا. نسخ ENTRYPOINT إلى CMD هو أيضًا تعديل أقوم به بشكل منتظم تمامًا. لا حاجة للقيام بخطوة وسيطة لبناء عامل ميناء بعد الآن ، ما عليك سوى الانتقال إلى نسخة Docker- copy . ؛)

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

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

القضية لا تزال مفتوحة. إنه مفتوح المصدر. نرحب بالمساهمات https://github.com/moby/moby/issues/3465#issuecomment -356988520

thaJeztah انظر https://github.com/docker/compose/pull/3939

هل أنا محق في التفكير في أنه سيتم إصلاح هذا في moby / buildkit الآن؟ أرى معظم البنية التحتية لأوامر Dockerfile هناك.

أنا أيضًا معجب بـ UNSET ، مثل

UNSET EXPOSE 9000

أو

UNSET LABEL foo

لذلك ، أنا أبحث في الأوامر التي تحتوي على نماذج أوامر فرعية ، مثل نموذج HEALTHCHECK CMD ولاحظت أن HEALTHCHECK يحتوي بالفعل على نموذج غير محدد ...

HEALTHCHECK NONE

يعد هذا اختيارًا مثيرًا للاهتمام ، ولكن HEALTHCHECK يحدد أيضًا تكوينًا واحدًا فقط (ويتجاوز مع الأحدث) ، ولا يسمح بتعريف عدة ، مثل LABEL ، EXPOSE ، و VOLUME تفعل.

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

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

+1 كشف []

لذلك .... لمدة 5 سنوات فريق Docker غير قادر على تنفيذ مشغل UNSET ، رائع

كما قال AnthonyMastrean ، هل يجب علينا نقل هذه المشكلة إلى مشروع moby/buildkit ؟

هناك أيضًا PR ، موثق جيدًا ومختبر ولكن ليس مدمجًا ، فهل يجب علينا نقل / إعادة تحديد هذه العلاقات العامة أيضًا؟

ستكون هذه الميزة موضع تقدير حقًا وستعالج مشكلة مع الصور المستندة إلى nginx في Azure.

UNSET ، CLEAR ، RESET ، OVERRIDE ، IGNORE سيكون جيدًا - سأتجنب UNxxx لأن ذلك قم بتكرار قائمة المفاتيح المحجوزة لدعم وتوثيق.

يمكن أيضًا تحديد ما يجب تجاهله / إعادة تعيينه عند استخدام FROM ، على سبيل المثال

FROM nginx:1.13 IGNORE EXPOSE, ENTRYPOINT

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

FROM postgres as orig

FROM alpine:3.8 as postgres
COPY --from=orig / /
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 5432
CMD ["postgres"]

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

kotofos لماذا لا FROM scratch as postgres ؟

تضمين التغريدة سيكون scratch بالتأكيد أفضل لأنك تقوم بالكتابة فوق نظام الملفات بأكمله

آخر مرة قمت باختباره ، COPY --from=xxx ... لن يحافظ على نظام الملفات
الملكية ، لذلك قد ترغب في توخي الحذر مع هذا الحل.

tianon أنت على صواب ، ولكن بالنسبة للحاويات أحادية العملية ، لا ينبغي أن تكون هذه مشكلة حيث يمكنك استخدام علامة --chown لتعيين المستخدم الذي تقوم بتنفيذه كما هو الحال في الحاوية

https://docs.docker.com/engine/reference/builder/#copy

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

لذا: هل يمكننا على الأقل الحصول على "UNEXPOSE" لإغلاق كل تلك المنافذ المفتوحة أو الحصول على نفس السلوك على الأقل مثل CMD و ENTRYPOINT (يفوز الأخير)؟ إنها الخاصية "غير المحددة" الأكثر طلبًا والمخاطر الأمنية المحتملة للمستخدمين غير المدركين للسلوك (غير الحدسي) ، مع الأخذ في الاعتبار سلوك "آخر واحد يفوز" من الأوامر الأخرى.

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

FROM postgres as orig

FROM alpine:3.8 as postgres
COPY --from=orig / /
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 5432
CMD ["postgres"]

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

FROM postgres:11.2-alpine
ENV PGDATA /var/lib/postgresql/test-data

# stuff that will create all my schemas
COPY create-scripts /docker-entrypoint-initdb.d/

# a weird way to trigger the entrypoint script to run the stuff in docker-entrypoint-initdb.d but not hang after starting postgres
RUN /docker-entrypoint.sh postgres --version

هل هناك بعض الفوائد في الحصول على ملفات الرصيف من EXPOSE و VOLUME على الإطلاق؟ بعد كل شيء ، يمكنك تحديدها بسهولة في docker run (وفي ملفات docker-compose ) ، مع --expose (أو -p ) ووحدات التخزين المسماة أو روابط الربط. لقد تعرضت للعض بسببهم أكثر من مرة ولا توجد طريقة لإعادة تعيينهم (إنشاء ملف عامل ميناء جديد ليس قابلاً للتطبيق كثيرًا ، خاصة عند توسيع الصور الرسمية أو الصور التي تم إنشاؤها باستخدام ملفات makefiles). أراهم على أنهم مناهضون للنمط وأعتقد أنه سيكون من الأفضل إهمالهم .

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

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

zarelit لا أعرف بالضبط كيف يعمل gitlab-runner ، لكن أعتقد أنه يجب أن تكون هناك طريقة لتحديد المنافذ التي سيتم فحصها خارج Dockerfile (لقد وجدت مشكلة ربما ترجع إلى ذلك ، لأن MySQL تكشف منفذين ولكن يجب أن يتحقق فقط من المنفذ 3306: https://gitlab.com/gitlab-org/gitlab-runner/issues/4143). مما أراه ، فإنه يستخدم أيضًا المنفذ المكشوف لملف Dockerfile الأخير فقط.

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

كما أنه لا يسمح لك بنقل الملفات إلى هذا الدليل أثناء الإنشاء (على افتراض أنك لا تريد استخدامه كمجلد ، ولكنه يرث Dockerfile الذي يعرّف الدليل على أنه وحدة تخزين ، مثل wordpress التي تحدد /var/www/html/ كحجم ، وكنت بحاجة إلى استخدام بعض الاختراقات لاستخدام دليل آخر).

باستخدام -v فإنك تعلن صراحة أنك تريد الحجم وتجنب المفاجآت غير المرغوب فيها بسبب السحر الأسود لـ VOLUME في Dockerfile.

أيضًا ، قد ينتهي الأمر بإنشاء الكثير من المجلدات المجهولة:

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

المصدر: https://boxboat.com/2017/01/23/volumes-and-dockerfiles-dont-mix/

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

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

لأي شخص يجدها مفيدة ، لا تتردد في استخدام صور dockboat.qa . إنها امتدادات للعديد من صور عمال الرصيف الرسمية مع إزالة الأحجام. مستودع GitHub الموثق بالحد الأدنى هنا حيث يتم رفع الأحمال الثقيلة: https://github.com/TugboatQA/images

هل هناك بعض الفوائد في الحصول على ملفات الرصيف من EXPOSE و VOLUME على الإطلاق؟ بعد كل شيء ، يمكنك تحديدها بسهولة في docker run (وفي ملفات docker-compose ) ، مع --expose (أو -p ) ووحدات التخزين المسماة أو روابط الربط. لقد تعرضت للعض بسببهم أكثر من مرة ولا توجد طريقة لإعادة تعيينهم (إنشاء ملف عامل ميناء جديد ليس قابلاً للتطبيق كثيرًا ، خاصة عند توسيع الصور الرسمية أو الصور التي تم إنشاؤها باستخدام ملفات makefiles). أراهم على أنهم مناهضون للنمط وأعتقد أنه سيكون من الأفضل إهمالهم .

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

@ m451 قد يكون تشغيل عامل

بدلاً من docker run some_image يمكنك بسهولة تشغيل docker run --expose 3000 -v my_volume:/container/dir some_image والحصول على فهم واضح للمنافذ المكشوفة للمضيف والأحجام التي ستستمر حتى بعد تدمير الحاوية.

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

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

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

هل هناك بعض الفوائد في الحصول على ملفات الرصيف من EXPOSE و VOLUME على الإطلاق؟ بعد كل شيء ، يمكنك تحديدها بسهولة في docker run (وفي ملفات docker-compose ) ، مع --expose (أو -p ) ووحدات التخزين المسماة أو روابط الربط. لقد تعرضت للعض بسببهم أكثر من مرة ولا توجد طريقة لإعادة تعيينهم (إنشاء ملف عامل ميناء جديد ليس قابلاً للتطبيق كثيرًا ، خاصة عند توسيع الصور الرسمية أو الصور التي تم إنشاؤها باستخدام ملفات makefiles). أراهم على أنهم مناهضون للنمط وأعتقد أنه سيكون من الأفضل إهمالهم .

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

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

@ m451 قد يكون تشغيل عامل

بدلاً من docker run some_image يمكنك بسهولة تشغيل docker run --expose 3000 -v my_volume:/container/dir some_image والحصول على فهم واضح للمنافذ المكشوفة للمضيف والأحجام التي ستستمر حتى بعد تدمير الحاوية.

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

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

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

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

لقد كانت Dockerfiles طريقة رائعة لتوحيد هذه الفوضى.

@ m451 أتفق معك في ذلك ، لكن من الجيد اعتبار أن مجرد تعريض منفذ لا ينقل معلومات مفيدة. ما نوع البيانات / الاتصالات التي يتوقعها المنفذ المكشوف؟ إذا كان هناك عدة منافذ ، فماذا يفعل كل منفذ؟

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

باستخدام VOLUME وفضح كنوع من التوثيق لا يبرر سيئة (أو عدم وجود) وثائق. وقد يضر أيضًا (وربما سيؤذي) بعض مستهلكي الصورة.

@ m451 أتفق معك في ذلك ، لكن من الجيد اعتبار أن مجرد تعريض منفذ لا ينقل معلومات مفيدة. ما نوع البيانات / الاتصالات التي يتوقعها المنفذ المكشوف؟ إذا كان هناك عدة منافذ ، فماذا يفعل كل منفذ؟

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

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

ومع ذلك ، أوافق على أن المستندات الجيدة مهمة. ومع ذلك ، في RL ، لا أحد يريد قراءة المستندات لساعات فقط لمعرفة المنافذ التي يجب فتحها. لا يجلب أي فائدة لمهام العمليات اليومية.

قطعة الفطيرة الخاصة بي.

استخدام VOLUME في Dockerfile لا قيمة له . إذا احتاج المستخدم إلى المثابرة ، فسيكون على يقين من توفير تعيين وحدة التخزين عند تشغيل الحاوية المحددة. كان من الصعب جدًا تتبع أن مشكلتي المتمثلة في عدم القدرة على تعيين ملكية الدليل (/ var / lib / influxdb) كانت بسبب إعلان VOLUME في ملف Dockerfile الخاص بـ InfluxDB. بدون خيار نوع التخلص منه تمامًا ، لا يمكنني تغيير أي شيء متعلق بالمجلد المحدد. هذا أقل من مثالي ، خاصة عندما تكون مدركًا للأمان وترغب في تحديد معرف فريد معين ، يجب تشغيل الصورة ، لتجنب مستخدم عشوائي ، لديه أذونات أكثر من اللازم ، يقوم بتشغيل البرنامج على مضيفك.

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

من nginx: الأحدث
بعد النشر في heroku ، تم الكشف عن منفذ 80 بواسطة nginx ، لكن هذا لن يسمح به heroku ، فماذا يمكنني أن أفعل؟ انسخ كل ملف dockerfile من nginx وأزل EXPOSE 80؟

لن أكتب أي جديد ... ولكن سيكون من الجيد جدًا تجاوز توجيه EXPOSE.

مشاركة هذا - https://github.com/gdraheim/docker-copyedit/blob/master/docker-copyedit.py (ليس إبداعي ، لأكون واضحًا ، شكرًا gdraheim!)

ساعدني هذا في إزالة وحدة تخزين من حاوية postgres تم تعيينها في ملف dockerfile باستخدام الأمر:

python docker-copyedit.py FROM postgres:11.5-alpine INTO postgres:11.5-alpine remove volume /var/lib/postgresql/data

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

 ./docker-copyedit.py FROM image1 INTO image2 -vv \
     REMOVE PORT 4444
 ./docker-copyedit.py FROM image1 INTO image2 -vv \
     remove port ldap and rm port ldaps
 ./docker-copyedit.py FROM image1 INTO image2 -vv \
     remove all ports
 ./docker-copyedit.py FROM image1 INTO image2 -vv \
     add port ldap and add port ldaps

LABEL هي "خاصية" أخرى (لم يتم ذكرها بعد) والتي يمكن أن تستخدم القدرة على "unset"

كما هو مذكور في منشور SO هذا: https://stackoverflow.com/questions/50978051/how-do-i-unset-a-docker-image-label

حالة استخدام أخرى لإعادة تعيين / إزالة VOLUME من الصور الأولية:

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

أعمل على توسيع صورة قاعدة بيانات oracle لكن حجمها /opt/oracle/oradata .

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

لقد قمت بحلها على النحو التالي:

لقد استخدمت docker-copyedit لإزالة المجلد ، ثم قمت بكتابة برنامج نصي bash لإنشاء قاعدة البيانات (يمكنك إلقاء نظرة على البرامج النصية لبدء التشغيل من oracle لترى كيف يتم ذلك). الآن مع PDB المكون مسبقًا ، يستغرق تشغيل حاوية من الصورة 25 ثانية فقط. لكن الصورة تصبح كبيرة حقًا.

قد يكون النهج الأفضل هو توسيع مواصفات عامل الإرساء الحالية لتشمل مفهوم متغيرات env اللاصقة / خيار التجاوز ، مثل ؛

على سبيل المثال مشروعي بناءً على صورة القط المنبع:

--ENV CATALINA_HOME / بعض / أخرى / مسار
من القط: 8.5.54-jdk8-openjdk
...

عندما يتم التصريح عن ENV مع - يجب ترقيته إلى الحالة اللاصقة والاحتفاظ بالقيمة المعلنة / تجاوز أي قيمة مصادفة لهذا المتغير لاحقًا في سلسلة معالجة Dockerfile.

--ENV = من هذه النقطة إلى الأمام في Dockerfile.

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

لن تحتاج إلى UNVOLUME ، إذًا لأن الأسلوب الصحيح هو أن يتم الإعلان عن VOLUME بمرجع ENV يمكن لشخص آخر تجاوزه.

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

ENV PROJ_VOL / بعض / المسار
الحجم $ PROJ_VOL

يبدو أن ENTRYPOINT [] و ENTRYPOINT [""] كلاهما يبطل ذاكرة التخزين المؤقت في كل إصدار عند عدم استخدام BuildKit. بسيط Dockerfile للتوضيح:

FROM jrottenberg/ffmpeg:4.3-alpine311 as base

ENTRYPOINT []

RUN echo "HERE!"

لن تستخدم الخطوتان 2 و 3 ذاكرة التخزين المؤقت أبدًا. هذا هو الحل الخاص بي:

FROM jrottenberg/ffmpeg:4.3-alpine311 as base

ENTRYPOINT ["/usr/bin/env"]

RUN echo "HERE!"

لا يمكنني إعادة إنتاج فشل ذاكرة التخزين المؤقت على النمط الأول:: confused:

$ cat Dockerfile
FROM alpine:3.12
ENTRYPOINT []
RUN echo 'HERE!'

$ docker build .
Sending build context to Docker daemon  17.25MB
Step 1/3 : FROM alpine:3.12
 ---> a24bb4013296
Step 2/3 : ENTRYPOINT []
 ---> Running in d921be2e563d
Removing intermediate container d921be2e563d
 ---> 7801c649d895
Step 3/3 : RUN echo 'HERE!'
 ---> Running in 9e2ca2cf1f9f
HERE!
Removing intermediate container 9e2ca2cf1f9f
 ---> d398fdd442b1
Successfully built d398fdd442b1

$ docker build .
Sending build context to Docker daemon  17.25MB
Step 1/3 : FROM alpine:3.12
 ---> a24bb4013296
Step 2/3 : ENTRYPOINT []
 ---> Using cache
 ---> 7801c649d895
Step 3/3 : RUN echo 'HERE!'
 ---> Using cache
 ---> d398fdd442b1
Successfully built d398fdd442b1

أعتقد أنه يجب عليك استخدام صورة تحدد ENTRYPOINT . حاول استخدام الصورة التي فعلتها أو mysql .

هذا مثير للاهتمام - يمكنني التكاثر باستخدام mysql:8.0 . علة صلبة! : +1: