Moby: طلب ميزة جديدة: تعطيل التخزين المؤقت لأوامر RUN محددة في Dockerfile بشكل انتقائي

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

ولكن ألن يحد هذا من تشذير الأوامر المخبأة وغير المخزنة مؤقتًا بسهولة؟

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

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

ألن يكون هذا مفيدًا؟

ماذا عن CACHE ON و CACHE OFF في Dockerfile؟ ستؤثر كل تعليمات على الأوامر اللاحقة.

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

هل يمكن تمرير معرّف الحاوية إلى "docker build" كإرشادات "لا تقم بالتخزين المؤقت بعد هذا المعرّف"؟ على غرار الطريقة التي سيخزن بها "بناء عامل الإرساء" جميع الخطوات مؤقتًا حتى سطر متغير في ملف Docker؟

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

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

ستكون ميزة رائعة. أستخدم حاليًا أشياء سخيفة مثل RUN a=a some-command ، ثم RUN a=b some-command لكسر ذاكرة التخزين المؤقت

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

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

ماذا عن تغيير --no-cache من منطقي إلى سلسلة وجعلها تأخذ regex حيث نريد كسر ذاكرة التخزين المؤقت في عامل الإرساء؟

docker build --no-cache "apt-get install" .

أوافق واقترحت هذه الميزة بالضبط على IRC.

باستثناء ما أعتقد أنه للحفاظ على التوافق العكسي ، يجب علينا إنشاء علامة جديدة (مثل "--uncache") حتى نتمكن من الاحتفاظ - مؤقتًا كعلامة منطقية (مهملة) يتم حلها إلى "--uncache. *"

الجمعة، 7 فبراير 2014 في 09:17، مايكل كروسبي [email protected]
كتب:

تضمين التغريدة
ماذا عن تغيير --no-cache من منطقي إلى سلسلة وجعلها تأخذ regex حيث نريد كسر ذاكرة التخزين المؤقت في عامل الإرساء؟

docker build --no-cache "apt-get install" .

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

ماذا الجميع اعتقد حول هذا الموضوع؟ أي شخص مستعد لتنفيذ الميزة؟

أنا على استعداد لإجراء طعنة في تنفيذ هذا اليوم إذا لم يبدأ أحد آخر؟

لقد بدأت العمل عليها - أردت التحقق من صحة الأسلوب الذي يبدو جيدًا.

• يصبح الحقل noCache البالغ buildfile *regexp.Regexp .
  
  
  
  • قيمة nil هناك تعني ما كان يستخدمه utilizeCache = true .
  
  
• يؤدي تمرير سلسلة إلى docker build --no-cache الآن إلى إرسال سلسلة regex للتحقق إلى الخادم.
• مجرد استدعاء --no-cache ينتج افتراضيًا هو .*
• ثم يتم استخدام regex في طريقة جديدة buildfile.utilizeCache(cmd []string) bool للتحقق من الأوامر التي تتجاهل ذاكرة التخزين المؤقت

شيء واحد: بقدر ما أستطيع أن أرى ، حزمة العلم / mflag لا تدعم علامات السلسلة بدون قيمة ، لذلك سأحتاج إلى القيام ببعض العبث الإضافي لدعم كل من --no-cache و --no-cache some-regex

أعتقد حقًا أن هذا يجب أن يكون علمًا جديدًا منفصلاً. سلوك وصياغة --no-cache معرّفان جيدًا بالفعل ويستخدمان في العديد والعديد من الأماكن من قبل العديد من الأشخاص المختلفين. كنت سأصوت لـ --break-cache أو شيء مشابه ، ولدي --no-cache يفعل بالضبط ما يفعله اليوم (نظرًا لأن هذا سلوك مفيد للغاية يعتمد عليه كثير من الناس ولا يزالون يريدون).

على أي حال ، IANTM (أنا لست المشرف) لذا فهذه مجرد أفكاري الشخصية. :)

tianon --no-cache هو منطقي حاليًا ، لذلك يؤدي هذا ببساطة إلى توسيع السلوك الحالي.

• docker build --no-cache - نفس السلوك السابق: تجاهل ذاكرة التخزين المؤقت
• docker build --no-cache someRegex - يتجاهل أي أوامر RUN أو ADD تتطابق مع someRegex

حسنًا ، هذا كل شيء على ما يرام. المشكلة هي أن --no-cache هو منطقي ، لذا فإن السلوك الحالي هو في الواقع:

• --no-cache=true - تعطيل ذاكرة التخزين المؤقت بشكل صريح
• --no-cache=false - تمكين ذاكرة التخزين المؤقت بشكل صريح
• --no-cache - اختصار لـ --no-cache=true

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

@ تيانون نعم أنت على حق. إلقاء نظرة سريعة ويستخدمه الأشخاص = صح / خطأ.

يسعدني تعديل العلاقات العامة لإضافة علامة جديدة كما تقترح ، ما رأي المشرفين (

+1 لمقاربةwagerlabs

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

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

+1 لمقاربةwagerlabs

+1 لمقاربةwagerlabs على الرغم من أنه سيكون أفضل إذا كانت هناك طريقة

CACHE [interval | OFF]
RUN apt-get update
CACHE ON

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

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

FROM ubuntu:13.10
ADD ./files/cachebusters/per-day /root/cachebuster
...
ADD ./files/cachebusters/per-build /root/cachebuster
RUN git clone [email protected]:cressie176/my-project.git /root/my-project

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

خطتي الحالية للتغلب على ذلك هي إدخال أوامر ديناميكيًا مثل RUN echo 2014-04-17-00:15:00 مع تقريب السطر المُنشأ إلى آخر 15 دقيقة لإلغاء صلاحية عناصر ذاكرة التخزين المؤقت عندما يقفز الرقم المقرّب. علاء كل 15 دقيقة. هذا يعمل بالنسبة لي لأن لدي برنامج نصي يقوم بإنشاء ملف dockerfile في كل مرة ، لكنه لن يعمل بدون هذا البرنامج النصي.

+1 لهذه الميزة.

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

hiroprotagonist وجود git pull في ENTRYPOINT قد يساعدك؟

amarnus لقد حللت على غرار فكرة tfoote . أقوم بتشغيل الإنشاء من وظيفة jenkins وبدلاً من تشغيل أمر docker build مباشرة ، تبدأ الوظيفة إنشاء سكريبت يقوم بإنشاء ملف Dockerfile من قالب ويضيف السطر "RUN echo التيارات ميليز" فوق أوامر git. بفضل sed والأنابيب كانت هذه مسألة دقائق. على أي حال ، ما زلت أفضل هذه الميزة كجزء من Dockerfile نفسه.

إضافة +1 لنهج wagerlabs . أيضا وجود هذه المشكلة مع CI. أنا ببساطة أستخدم بيان صدى ديناميكي RUN في الوقت الحالي ، لكني أحب هذه الميزة.

+1 لذاكرة التخزين المؤقت ON / OFF. حالة الاستخدام الخاصة بي هي أيضًا أتمتة CI.

+1 ، لا سيما القدرة على تعيين الفاصل الزمني لذاكرة التخزين المؤقت لأوامر التشغيل كما في مثال @ cressie176

"على سبيل المثال تحديث المستودعات أو تنزيل ملف بعيد"

+1

إذا كان ذلك يساعد أي شخص ، فإليك جزء الكود الذي أستخدمه في بناء Jenkins الخاص بي:

echo "Using build $BUILD_NUMBER for docker cachebusting"
sed -i s/cachebust_[0-9]*/cachebust_"$BUILD_NUMBER"/g Dockerfile

+1 لذاكرة التخزين المؤقت ON / OFF

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

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

أنا أيضًا أستخدم بادئة للأوامر ، مثل ALWAYS أو CACHE 1 WEEK ADD ...

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

From ubuntu:14.04

RUN apt-get -yqq update
RUN apt-get -yqq install git
RUN git clone https://github.com/coreos/fleet
ADD http://www.random.org/strings/?num=10&len=8&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new uuid
RUN cd fleet && git pull

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

+1 آخر لمقاربةwagerlabs

+1 آخر لهذه الميزة. وفي الوقت نفسه باستخدام الحل البديل cruisibesarescondev .

+1 لطلب الميزة. وشكرًا لـ cruisibesarescondev على الحل

+1 آخر لهذه الميزة.

هتاف cruisibesarescondev للحل البديل.

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

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

@{
import time
def cache_buster(seconds):
    ts = time.time()
    return ts - ts % seconds
}@

حيث أريد فرض إعادة التشغيل:

RUN echo @(cache_buster(60))

الذي يبدو مثل هذا في Dockerfile

RUN echo 1407705360.0

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

+1 لبناء الجملة دائمًا. +.5 لـ CACHE ON / CACHE OFF.

+1 لبناء الجملة دائمًا.

نعم ، يبدو بناء الجملة دائمًا بديهيًا جدًا.

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

kuon أعتقد أن هناك بالفعل عددًا من الأوامر التي تؤثر على التعليمات اللاحقة ، على سبيل المثال USER و WORKDIR

نعم ، هذا صحيح ، لكنني لا أستخدمها لنفس السبب. أقوم دائمًا بعمل RUN cd ... && أو RUN su -c ...&& .

أفضل تدوين الكتلة:

CACHE OFF {
    RUN ...
}

هذا أكثر وضوحًا وتجنب إدراج سطر CACHE OFF بالخطأ (سيؤدي إلى حدوث خطأ في بناء الجملة).

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

ربما تكون هذه المشكلة فرصة لتنسيق Dockerfile جديد.

أود أن أعود لما قلته للتو. قرأت ما قاله @ shykes في عدد آخر https://github.com/docker/docker/pull/2266 وأنا أتفق معه أيضًا (يحتاج Dockerfile إلى الاحتفاظ بتجميع بسيط حقًا مثل اللغة).

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

NOIMAGE ALWAYS RUN USER:jon  apt-get update

والذي سيؤدي دائمًا إلى تشغيل الأمر (بدون ذاكرة تخزين مؤقت) ، ولكنه أيضًا لن ينشئ صورة ويستخدم المستخدم jon.

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

هل يمكن أن يكون RUN! للتيسير من فضلك؟

أي تحديث حالة على هذا واحد؟

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

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

ما زلت مقتنعًا أن بناء الجملة ALWAYS هو الصيغة المثالية.

ماذا عن بيان بسيط BREAK .

@ cpuguy83 التي ستعمل أيضًا مع حالة الاستخدام الخاصة بي.

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

الحصول على دعم لـ BREAK الرغم من ذلك سيعطيني ميزة التكافؤ مع الحل الحالي الخاص بي بناءً على اقتراح منCheRuisiBesares.

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

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

مفتاح ALWAYS (أو مفاهيم مشابهة مثل EVERY # DAYS ) هو مقارنة ذاكرة التخزين المؤقت بعد الأمر المرفق. بالنسبة لي (وأفترض العديد من الآخرين) ، فإن الهدف ليس كسر ذاكرة التخزين المؤقت في حد ذاتها.

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

يتناول هذا التعليق من قبلhellais حيث يمكنك الاستفادة من مخبأ لأوامر لاحقة ... إذا وفقط إذا كان الناتج من ALWAYS يطابق النسخة المخبأة (هذا يمكن أن يكون بسهولة معظم الوقت).

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

أنا في نفس الموقف تمامًا مثل tfoote : أنا أستخدم Docker لـ CI

+1 بناء جملة EVERY . ستنجز بنية ALWAYS المهمة أيضًا.

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

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

• ينشئ حالة مخفية (يحتاج إلى تشغيل ALWAYS ) و
• لا يغير الحاوية الحالية

إذا لم يتضمن الأمر التالي حالة مخفية (أمر تافه ، أمر mv في الحاوية) ، فستكون ذاكرة التخزين المؤقت موثوقة بنسبة 100٪. نفس الحاوية ، نفس الأمر ، لا الاعتماد على المعلومات المخفية.

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

claytondaley يبدو الحل الخاص بك أنيقًا جدًا وفعالًا بالنسبة لي. سأكون ممتنا جدا إذا تم تنفيذ ذلك. : +1:: أخطبوط:

+1 لهذه الميزة باستخدام البنية المقترحة دائمًا وكل X. يشعر CACHE ON / OFF بأنه أخرق بعض الشيء بالنسبة لي ، لكنني سأستخدمه. أحب أيضًا اقتراح claytondaley لاستئناف ذاكرة التخزين المؤقت حيثما أمكن ذلك.

+1 لبناء الجملة دائمًا. خاصة بالنسبة لأكواد السحب من git repo.

+1 لأي ​​من هذه الحلول.

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

ما أفهمه من الاقتراحات هو أنه يمكنك تحديد "دائمًا" كجزء من أمر Dockerfile لتشغيل الخطوة مرة أخرى دائمًا. على سبيل المثال ، سيتم دائمًا تشغيل "RUN ALWAYS git clone https://example.com/myrepo.git " (وبالتالي دائمًا نسخ الريبو). ثم ما يقترحهclaytondaley هو أنه بعد تشغيل هذا الأمر مرة أخرى ، يتحقق Docker من التغييرات مقابل ذاكرة التخزين المؤقت. إذا كان المجموع الاختباري هو نفسه (على سبيل المثال ، إذا لم يكن للريبو المستنسخ أي تغييرات ، فإن أحدث طبقة متطابقة مع نفس الطبقة في ذاكرة التخزين المؤقت) ، فيمكننا الاستمرار في تشغيل ذاكرة التخزين المؤقت. أنت محق في أنه بمجرد إبطال ذاكرة التخزين المؤقت ، لا يمكن لجميع الخطوات بعد ذلك استخدام ذاكرة التخزين المؤقت. تتيح هذه الاقتراحات فقط مزيدًا من التفاصيل الدقيقة للتحكم في وقت استخدام ذاكرة التخزين المؤقت ، كما أنها ذكية أيضًا بشأن الاستئناف من ذاكرة التخزين المؤقت حيثما أمكن ذلك.

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

duglin ... قد تكون الفكرة أكثر وضوحًا إذا استخدمنا وسيطًا رياضيًا. ذاكرة التخزين المؤقت (في هذا السياق) هي مجرد ذاكرة لنتيجة action B عند تطبيقها على state A حتى لا تضطر إلى إعادة معالجتها. لنفترض أنني قمت بتشغيل سلسلة من الأوامر:

• تبدأ بـ 6
• قم دائمًا بتشغيل * x حيث يتم تنزيل قيمة x من مستودع git (وبالتالي يمكن أن تتغير)
• تشغيل + 12

في المرة الأولى التي أقوم فيها بتشغيل الأمر ، يكون x 8 لذا أحصل على التسلسل التالي (وأخزنه مؤقتًا):

• 6
• 48 (نتيجة تطبيق * x على 6 )
• 60 (نتيجة تطبيق + 12 على 48 )

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

الجزء الصعب هو معرفة ما إذا كنت في نفس الحالة ( 48 ) مرة أخرى.

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

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

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

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

أنا شخصياً سأكون أكثر من سعيد إذا كان كل ما أملك هو القدرة على ضمان تشغيل الأمر دائمًا. خذ ملف Dockerfile مثل:

RUN install_stuff_take_forever
RUN always_do_it   #will not run every time
RUN more_stuff

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

RUN install_stuff_take_forever
NOCACHE
RUN always_do_it
RUN more_stuff

pikeas لقد تلقيت أمر NOCACHE تمامًا وهذا سهل للقيام به. ما لم أحصل عليه هو أمر يعيد تشغيله بدون اختلاف / تجزئة / أيا كان نظام الملفات بأكمله.

قرأت شرح "الطبقة" الخاص بـ Docker ليعني أن:

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

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

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

• في معظم الحالات (git pull أو ترقية البرنامج) ، سيكون الإصدار الحالي إما (1) هو نفس الإصدارات الأخيرة أو (2) إصدارًا جديدًا ... ولكن لن يكون أبدًا - على الأقل نادرًا - عودة إلى الإصدار السابق الإصدار.
• في حالات نادرة (مثل الترقية إلى dev-master ثم الرجوع إلى إصدار ثابت) ، من الممكن العودة إلى إصدار أقدم. ومع ذلك ، فهذه نادرة جدًا ، لذا من المحتمل أن يكون معظم الأشخاص أفضل حالًا (بشكل متكرر) في التحقق فقط من أحدث إصدار وإعادة تشغيل الأوامر في حالة نادرة يقومون فيها بالتراجع.

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

إذا نظرت إلى الجزء السفلي من https://github.com/docker/docker/pull/9934 ، فسترى مناقشة حول خيارات الدعم لأوامر Dockerfile. ماذا لو كان هناك خيار - no-cache متاحًا للجميع (أو حتى RUN فقط) والذي يعني "عدم استخدام ذاكرة التخزين المؤقت" لهذا الأمر؟ على سبيل المثال:
تشغيل - no-cache apt-get install -y-my-favourite-tool
سيؤدي هذا بعد ذلك إلى تعطيل ذاكرة التخزين المؤقت تلقائيًا للأوامر المتبقية أيضًا (على ما أعتقد).
هل هذا يحل المشكلة؟

بين "RUN ALWAYS" و "RUN - no-cache" والتي هي متطابقة لغويًا ، أفضل شخصيًا بناء جملة "RUN ALWAYS" الأكثر طبيعية المظهر. أتفق مع التعليق الأخير على ذلك العلاقات العامة: أعتقد أن الخيار يكسر قابلية القراءة وسيجعل ملفات Dockerfiles قبيحة. بالإضافة إلى ذلك ، أعتقد أن أوامر Dockerfile يجب أن تكون مميزة جدًا عن الأوامر الفعلية التي تتبعها. تخيل شيئًا مثل "RUN - no-cache myapp --enable-cache" كمثال على بناء الجملة المعقدة والذي سيبدأ في التعبير عن نفسه بسرعة باستخدام هذا النوع من الخيارات.

curtiszimmerman مثالك واضح جدا بالنسبة لي. - no-cache is for RUN بينما - تمكين ذاكرة التخزين المؤقت لـ myapp. التنسيب مهم. على سبيل المثال ، انظر إلى:
تشغيل عامل ميناء -ti ubuntu ls -la
يفهم الناس أن -ti تعني "run" بينما "-la" تعني "ls". هذا بناء جملة يبدو أن الناس مرتاحون له.
إحدى المشكلات المتعلقة بشيء مثل RUN ALWAYS هي القابلية للتوسعة. نحتاج إلى بناء جملة يمكنه العمل مع جميع أوامر Dockerfile ودعم تمرير القيمة. على سبيل المثال ، أعرب الأشخاص عن اهتمامهم بتحديد المستخدم لأوامر معينة.
RUN USER = foo myapp
يقوم من الناحية الفنية بتعيين env var USER على "foo" داخل غلاف myapp. لذلك نحن هنا غامضون.
بينما: RUN --user = foo myapp ليس لديه هذه المشكلة.
هو: RUN var = foo myapp
تحاول تعيين var و env يسمى var أو خطأ إملائي يحاول الحصول على خيار RUN؟
IOW ، احتمالات التداخل مع أمر صالح موجود ، IMO ، أقل بكثير عندما نبدأ الأشياء - من مجرد السماح بكلمة هناك

أنا في الواقع أؤيد التسلسل العكسي ، EVERY <options> COMMAND . عدة اسباب:

• في حالة "المستخدم" و "ذاكرة التخزين المؤقت" (على الأقل) ، فإنهما في الحقيقة خصائص بيئة يمكن أن تلتف أي أمر (على الرغم من أنها قد لا تؤثر ماديًا على الآخرين).
• يعني بناء الجملة RUN ALWAYS تغيير مترجم الأوامر RUN ، والذي يبدو غير ضروري.
• هذه المشكلة أسوأ مع RUN EVERY 5 days لأن الخيارات المرفقة بكل شيء تخلق مزيدًا من الغموض. EVERY 5 days RUN واضح بشأن الأمر الذي تؤثر عليه الخيارات. لدينا نفس المشكلة مع RUN USER usr مقابل USER usr RUN . طالما أن (1) الكلمات الرئيسية للأوامر ليست خيارات أبدًا أو (2) هناك طريقة سهلة للهروب منها ، فهذا لا لبس فيه.

يمكنني الانضمام إلى الأوامر بخياراتها ( ALWAYS AS user RUN ... ). أنا مهتم حقًا باستخدام longopts على غرار GNU للخيارات لأنها ليست منفصلة جدًا عن العيون القديمة أو المزججة. يمكنني أن أتخيل نفسي أحدق في أمر Dockerfile المعقد بعد 20 ساعة أتساءل أن wtf مستمر. لكنني أتوقع - الخيارات ستحدث بغض النظر.

لكنني أتوقع - الخيارات ستحدث بغض النظر.

لم يتم تقرير أي شيء بعد ، على العكس من ذلك ؛ بناء الجملة الذي يقترحهduglin هو اقتراح _counter_ لصيغة تم اقتراحها / تم تحديدها مسبقًا. يرجى قراءة # 9934 لمزيد من المعلومات حول ذلك.

أيضًا ، duglin هو _not_ الشخص الذي يتخذ هذا القرار (على الأقل ، ليس بمفرده). تم ذكر بعض النقاط التي تثيرها في الموضوع الآخر.

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

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

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

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

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

+1 على -1tianon (أي -1!) ، وتبدو إضافة علامة للكسر عند الخطوة N أمرًا معقولاً. بالنظر إلى أنه بمجرد كسر ذاكرة التخزين المؤقت ، يتم كسرها لبقية Dockerfile على أي حال ، أعتقد أن هذا أمر منطقي.

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

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

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

كتب Tianon Gravi [email protected] :

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

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

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

curtiszimmerman لقد اقترحت (!) لأنه يشير إلى شيء يشبه الإلحاح في اللغة الإنجليزية. ("يجب علبك ان تفعل ذلك!")

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

لماذا التركيز على RUN؟ لماذا لا تسمح بضبط ذاكرة التخزين المؤقت لأي أمر؟
يبدو أن إضافة:
تمثال نصفي
سيكون نوع أمر Dockerfile أكثر مرونة بكثير. ولإضافة المرونة حقًا ، يمكن أن يسمح اختياريًا بعلامة:
BUST-CACHE $ doit
حيث يتم تطبيقه فقط إذا تم تعريف doit $ - ثم إذا أضفنا دعمًا لخيار a -e عند الإنشاء (https://github.com/docker/docker/pull/9176) ، فيمكن للأشخاص القيام بما يلي:
بناء عامل ميناء -e doit = ​​صحيح ...

zamabe أوه ، RUN! ، آسف. هنا كنت أستخدم (!) لأقول "هذا أمر غير عادي!" حول تحرير Dockerfile في كل مرة أرغب في كسر ذاكرة التخزين المؤقت في خطوة معينة. بأي طريقة يمكنني بها كسر ذاكرة التخزين المؤقت داخل Dockerfile قبل أن تكون خطوة معينة مفيدة (وللحصول على ربح إضافي ، إذا كانت الخطوة التي تلي أمر خرق ذاكرة التخزين المؤقت هي نفس النتيجة الموجودة في ذاكرة التخزين المؤقت ، فكن ذكيًا بما يكفي للمتابعة من ذاكرة التخزين المؤقت ). BUST-CACHE أو ALWAYS RUN (أو RUN ALWAYS ) أو RUN! ... حقًا ، أي آلية تدعم هذه الميزة ، سأستخدمها.

duglin آسف؟ يشير عنوان الخطأ إلى RUN وهو ما يسهل تقديمه كمثال.

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

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

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

+1 لسحب الرموز من git repo

+1

سيكون هذا ضخمًا! لدي الآن جزء من تكاملي المستمر في كتابة تجزئة git الالتزام في Dockerfile (الكتابة فوق عنصر نائب) فقط لكسر ذاكرة التخزين المؤقت لاستنساخ git.

لقد أرسلت هذا PR: https://github.com/docker/docker/pull/10682 لمعالجة هذه المشكلة.
في حين أنه لا يدعم إعادة تشغيل التخزين المؤقت ، لا أعتقد أن هذا ممكن اليوم.

+1

أقوم بإنشاء رقم عشوائي في Dockerfile ويتم تخزينه مؤقتًا ...
+1 لتعليمات NOCACHERUN

+1
يجب أن تكون مفيدة حقًا لبعض RUN التي نحتاج إلى القيام بها في كل مرة دون إعادة بناء كل شيء

لقد لاحظت أن git clone سيصل إلى ذاكرة التخزين المؤقت ولكن go get -d لن يصل إلى ذاكرة التخزين المؤقت. اي افكار لماذا؟

مراجعة _Collective مع @ LK4D4calaverajfrazellecrosbymichaeltiborvass_

إغلاق هذا لأننا لا نرى العديد من حالات الاستخدام في العالم الحقيقي (انظر رقم 10682 ذي الصلة لمزيد من التفاصيل).

+1 لـ RUN. سيكون جميلا.

+1

يقدم docker 1.9 متغيرات وقت البناء ؛ من الممكن (إساءة) استخدامها لفرض كسر ذاكرة التخزين المؤقت ؛ لمزيد من المعلومات ، راجع https://github.com/docker/docker/issues/15182

كيف هذه ليست ميزة بعد؟

@ hacksaw6 يمكنك إلقاء نظرة على ما قيل هنا: https://github.com/docker/docker/pull/10682

+1

+1

+1 كيف لم يعد هذا شيئًا حتى الآن !!! ؟؟؟!

+1 نحن بحاجة إلى هذه الميزة لتوفير المزيد من التحكم الدقيق للبناء.

+1

+1

+1

+1

1+ مفيد جدًا
(باستخدام timruffles الحل البديل في الوقت الحالي)

+1

+1

+1

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

+1 ، وصلت إلى هنا عبر Google بحثًا عن حل لاستنساخ git المخزن مؤقتًا.

حالة الاستخدام الخاصة بي:
لدي تكوين عامل إرساء ، والذي أثناء إنشائه سوف يستدعي عبر gradle تطبيقًا رائعًا للخدمة المصغرة في وضع التشغيل الجاف. سينتج عن ذلك تنزيل جميع مكتبات جافا التابعة (من مستودع mvn البعيد) في مستودع docker mvn المحلي. سيعمل التشغيل الجاف فقط على تشغيل التطبيق والعودة على الفور ولكنه يضمن تحميل جميع تبعيات مكتبة جافا.
أثناء مرحلة تشغيل عامل الإرساء ، سيتم تنفيذ التطبيق نفسه عبر وضع gradle - Offline. أي سيتم تحميل تطبيق microservice من دليل مستودع mvn المحلي. لن يتم جلب مكتبة عن بُعد باهظة الثمن وتستغرق وقتًا طويلاً. عندما أقوم الآن بإصدار نسخة لقطة جديدة لمكتبة كهذه ، لن يقوم عامل الإرساء بتشغيل عملية الجلب عن بُعد أثناء الإنشاء (أي أنه لن يقوم باستدعاء gradle dryrun cmd الخاص بي) ، إلا إذا قمت بتعديل دليل عامل الإرساء.

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

من الأسوأ الاعتماد على "ميزة" نظام البناء أكثر من الاعتماد على أحدث إصدار ، IMHO.

ماذا عن إضافة بناء جملة جديد: FORCE RUN git clone .... ؟

أستخدم الآن RUN _=$(date) git clone ... لإلغاء صلاحية ذاكرة التخزين المؤقت.

@ c9s هل هذا العمل فعلا؟ لا أعتقد ذلك.

duglin إعداد متغير البيئة يعمل بالنسبة لي. "FORCE RUN" هو مجرد اقتراح:]

@ c9s لا أرى كيف يمكن أن يعمل إعداد env var لأن ذلك يتم بواسطة غلاف الحاوية ، وليس معالجة Dockerfile. عندما أحاول استخدام RUN _=$(date) echo hi فإنه يستخدم ذاكرة التخزين المؤقت في الإصدار الثاني.

duglin أنت على حق: | لا يبطل ذاكرة التخزين المؤقت

@ c9s جرب هذا بدلاً من ذلك

FROM foo
ARG CACHE_DATE=2016-01-01
RUN git clone ...

docker build --build-arg CACHE_DATE=$(date) ....

thaJeztah شكرا! إنها تعمل!

+1 استنساخ git repos (حالة الاستخدام)

الكثير من إجراءات +1 ، إذا قمت بسحب git repo في ملف عامل الإرساء ، فإن ذاكرة التخزين المؤقت تمنع إنشاء صورك. يجعل من الصعب دفع التراكيب من خلال CI.

+1 استنساخ git repos (من المزعج جدًا أن الصورة تحتاج إلى الإنشاء من نقطة الصفر في كل مرة يتم فيها إجراء تعديل صغير في git repo)

Vingtoft إذا كنت تقوم بتحديث الملفات في الريبو ، فإن ذاكرة التخزين المؤقت الخاصة بك غير صالحة.

itsprdp لم أكن أعرف ذلك ، شكرًا

itsprdp لقد اختبرت للتو. عندما أقوم بتحديث الريبو وبناء الصورة ، لا يزال Docker يستخدم ذاكرة التخزين المؤقت.
ربما أسيء فهم شيء ما؟

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

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

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

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

+1 ، ذاكرة التخزين المؤقت المستخدمة أثناء استنساخ git :(

سيكون الحل المتكامل أمرًا رائعًا ، ولكن في هذه الأثناء يمكنك إخفاء ذاكرة التخزين المؤقت في تعليمات Dockerfile محددة باستخدام ARG .

في Dockerfile:

ARG CACHEBUST=1
RUN git clone https://github.com/octocat/Hello-World.git

في سطر الأوامر:

docker build -t your-image --build-arg CACHEBUST=$(date +%s) .

يعني تعيين CACHEBUST على الوقت الحالي أنه سيكون دائمًا فريدًا ، ولن يتم تخزين الإرشادات بعد إعلان ARG في Dockerfile مؤقتًا. لاحظ أنه يمكنك أيضًا الإنشاء بدون تحديد CACHEBUST build-arg ، مما سيجعله يستخدم القيمة الافتراضية 1 والاحتفاظ بالذاكرة المؤقتة. يمكن استخدام هذا دائمًا للتحقق من النسخ الحديثة من مستودعات git ، وسحب أحدث تبعيات SNAPSHOT ، وما إلى ذلك.

تحرير: وهو بالضبط ما قالتهhaJeztah . سأترك هذا كوصف إضافي لحله.

@ shane-axiom ماذا عن استخدام تجزئة git الالتزام كقيمة CACHEBUST ؟

export CACHEBUST=`git ls-remote https://[email protected]/username/myRepo.git | grep refs/heads/develop | cut -f 1` && \
echo $CACHEBUST && \
docker build -t myDockerUser/myDockerImage \
   --build-arg blah=blue \
   --build-arg CACHEBUST=$CACHEBUST \
   .

استنادًا إلى أدلة من http://stackoverflow.com/questions/15677439/how-to-get-latest-git-commit-hash-command#answer -15679887

pulkitsinghal هذا يبدو رائعًا لخرق ذاكرة التخزين المؤقت لـ git repos. بالنسبة للاستخدامات الأخرى (مثل سحب تبعيات SNAPSHOT ، إلخ) ، يعمل نهج الطابع الزمني دائمًا بشكل جيد.

+1 لـ CACHE ON | إيقاف

+1

+1

تذكر حول CheRuisiBesares aproach ، يمكنك دائمًا استخدام ADD https://www.random.org/strings/?num=16&len=16&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new uuid كحل بديل لمشكلات ذاكرة التخزين المؤقت.

لنشر حالة استخدام إضافية ....

COPY package.json /usr/src/
RUN npm install

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

يبدو أن إجراء RUN NO CACHE مقابل RUN سيكون حلاً جيدًا.

+1

لدي مشكلة مماثلة لتثبيت npm الذي يستخدم ذاكرة التخزين المؤقت ولا يستخدم مكتبتي المنشورة الجديدة في npm.

سيكون من الرائع أن أتمكن من تعطيل ذاكرة التخزين المؤقت لكل أمر RUN في ملف عامل الإرساء.

brycereynoldsmmobini نرى https://github.com/docker/docker/issues/1996#issuecomment -172606763 لخرق ذاكرة التخزين المؤقت يدويا. ومع ذلك ، _not_ تحديد إصدار معين من الحزم التي تحتاج إلى التثبيت قد لا يكون أفضل ممارسة ، لأن النتيجة النهائية لملف Dockerfile (وكود المصدر) لم يعد مضمونًا لإعادة إنتاجه (على سبيل المثال ، يتم إنشاؤه بنجاح اليوم ، ولكنه لا غدًا ، لأنه تم تحديث إحدى الحزم). أستطيع أن أرى أن هذا "موافق" أثناء التطوير ، ولكن بالنسبة للإنتاج (والبناء الآلي على Docker Hub) ، فإن أفضل طريقة هي تحديد إصدار صريحًا. يتيح القيام بذلك أيضًا للمستخدمين التحقق من الحزم الدقيقة التي تم استخدامها لإنتاج الصورة.

لدي حالة استخدام حيث يتسبب عدم القدرة على إبطال ذاكرة التخزين المؤقت في حدوث مشكلات. أقوم بتشغيل تطبيقات Dropwizard (خدمات Java REST التي تم إنشاؤها باستخدام Maven) من Docker ويقوم نظام آلي بتنفيذ جميع عمليات إنشاء الحاويات ونشرها من أجلي. أقوم بتضمين Dockerfile في الريبو الخاص بي وهو يقوم بالباقي. يقوم النظام بتشغيل إصدار إنتاج وإصدار تطوير واحد أو أكثر من تطبيقي. بناء التنمية هو المكان الذي أواجه فيه مشاكل.

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

ctrimble يمكنك استخدام --no-cache أو --build-arg لإبطال ذاكرة التخزين المؤقت.
يمكنك تقليل تأثير --no-cache خلال الحصول على صورة أساسية مع جميع الأوامر القابلة للتخزين المؤقت.

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

1. القيام بأشياء يمكن تخزينها مؤقتًا إذا كان نظام الملفات متطابقًا
2. القيام بشيء قد يغير نظام الملفات بناءً على وقت تنفيذه
3. القيام ببعض الأشياء الأخرى التي يمكن تخزينها مؤقتًا إذا لم تغير الخطوة السابقة نظام الملفات

سيظهر هذا النمط في تطوير يبني بشكل متكرر. سيكون من الجيد وجود دلالات لها في Dockerfile.

ctrimble سيؤدي خرق ذاكرة التخزين المؤقت في خطوة واحدة إلى

@ cpuguy83 بالضبط. تعتبر دلالات نظام البناء الخاص بي مؤقتة لعمليات التطوير. لا بد لي من تحديد البنيات الصحيحة على التخزين المؤقت. أود حقًا الحصول على كليهما.

كان هناك نقاش كبير هنا ، نعتذر إذا تم اقتراحه بالفعل ، ولكن ماذا لو كان هناك شيء مثل هذا:

CHECK [FILE_PATH]

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

من المحتمل أن أفعل شيئًا مثل:

CHECK Gemfile
CHECK package.json
CHECK composter.json
CHECK project.json

قد ترغب أيضًا في تمكين التحقق من أن بعض الكيفية تنقضي بعد فترة زمنية. قد توفر معلمة Ansible cache_valid_time للمكوِّن الإضافي apt بعض الإلهام: http://docs.ansible.com/ansible/apt_module.html

لذلك ، سيكون بناء الجملة:

EXPIRE 1234567 
RUN apt-get update
RUN bundle install

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

atrauzzi نحن ندعم فقط --squash على الإنشاء الآن في 1.13 (تجريبي فقط في الوقت الحالي).

@ cpuguy83 هل هناك أي مستندات أو تفسيرات حول --squash أي مكان يمكنني القراءة فيه؟ في البداية ، لا يجعل الاسم يبدو كما لو كان يفعل ما أفكر فيه. لكن قد أكون (وعلى الأرجح أكون) مخطئًا!

atrauzzi نعم ، في مرجع البناء.

بشكل أساسي ، يحافظ كل من --squash على ذاكرة التخزين المؤقت للطبقة ، وينشئ صورة ثانية كما لو أن كل شيء في Dockerfile حدث في طبقة واحدة.

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

@ cpuguy83 نقطة جيدة ، لم أفكر في ذلك ، وبالطبع أنا

ماذا عن نهج الطابع الزمني / المدة؟ هل هذا ممكن مع ما هو متاح بالفعل؟

ماذا عن نهج الطابع الزمني / المدة؟ هل هذا ممكن مع ما هو متاح بالفعل؟

من خلال بناء أرجس.

ARG expire_after=never
RUN do some thing

docker build --build-arg expire_after=2016-12-01 -t foo .

تغيير الحجج لكسر ذاكرة التخزين المؤقت

+1 لطريقة أنظف

+1 لطريقة أنظف

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

+1

هل أقترح تمرير رقم الخطوة إلى أمر الإنشاء؟

شيء من هذا القبيل:
docker build --step 5 .

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

+1
لو سمحت.

ذاكرة التخزين المؤقت ON | OFF +1

المشكلة مع هذه الأوامر CACHE ON|OFF هي أنه في أي خطوة يتم إيقاف تشغيل ذاكرة التخزين المؤقت ، لا توجد طريقة لتخزين المزيد من الخطوات مؤقتًا. الأمر المعقول الوحيد هو ENDCACHE .

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

+1

+1 ميزة يجب أن يكون

توافق على CACHE ON | OFF +1

+1 سيكون مذهلاً.

لم أفهم حقًا الطريقة التي يخزن بها Docker الخطوات مؤقتًا من قبل وقضيت نصف يوم في التحقيق في سبب عدم بناء نظامي بشكل صحيح. كان التخزين المؤقت "git clone".

أحب أن يكون لديك الكلمة الرئيسية ALWAYS .

كيف هو مغلق؟

ما هو أفضل حل بديل؟

حاولت https://github.com/moby/moby/issues/1996#issuecomment -185872769 ونجحت
في Dockerfile:

ARG CACHEBUST=1
RUN git clone https://github.com/octocat/Hello-World.git

في سطر الأوامر:

docker build -t your-image --build-arg CACHEBUST=$(date +%s)

لماذا لا تنشئ أمرًا جديدًا مشابهًا لـ RUN ولكن لا يخزن RUNNC مؤقتًا لـ RUN NO CACHE؟

أستطيع أن أؤكد ، habeebr (https://github.com/moby/moby/issues/1996#issuecomment-295683518) - أستخدمه مع https://github.com/moby/moby/issues/1996# طلب إصدار - 191543335

+1

RUNNC فكرة رائعة!

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

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

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

ليس من الصعب: https://github.com/moby/moby/pull/10682
حل سهل ، سهل UX. فقط لا يوجد إجماع واضح حول ما إذا كان ينبغي القيام بذلك.

رائع فقط رائع...

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

+1

+1 للأمان المعقول والأداء الأفضل

+1

+1

+1

+1

+1

+1

هل يمكنكم يا رفاق التوقف عن إرسال +1 بشكل غير مرغوب فيه؟ فقط استخدم ميزة رد الفعل للتأييد.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

لماذا أغلق هذا؟ أعتقد أنه مفيد

+1

+1

+1

الطريقة الأكثر بساطة حاليًا لتعطيل ذاكرة التخزين المؤقت للطبقة (وما يلي):

ملف Dockerfile

ARG CACHE_DATE
RUN wget https://raw.githubusercontent.com/want/lastest-file/master/install.sh -O - | bash

وعند إنشاء الصورة ، يجب إضافة --build-arg

docker build  --build-arg CACHE_DATE="$(date)"

ثم يتم تنفيذ الأمر wget كل مرة تقوم فيها بإنشاء الصورة ، بدلاً من استخدام ذاكرة التخزين المؤقت.

RUNNC أو CACHE OFF أمرًا رائعًا

في غضون ذلك ، يبدو هذا واعدًا:
http://dev.im-bot.com/docker-select-caching/

هذا هو:

سأذهب وأبقى هادئًا وأنضم إلى القطيع:

+1

نعم ، أحتاج إلى تخزين مؤقت انتقائي للأوامر. يخفق COPY بنسبة 80٪ من الوقت إذا قمت بتغيير كلمة واحدة فقط في ملف التكوين. لا أرغب أبدًا في تخزين COPY مؤقتًا ولكن تخزين كل شيء آخر مؤقتًا. سيكون الحصول على CACHE ON و CACHE OFF أمرًا رائعًا.

RUN X
RUN X
CACHE OFF
COPY /config /etc/myapp/config
CACHE ON

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

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

shadycuzcurtiszimmerman نعم، ونحن قد الحفاظ فقط CACHE OFF ولكن لا CACHE ON ، لأن الطبقات التالية تحتاج إلى إعادة بناء إذا تم تغيير طبقة السابقة.

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

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

لماذا تم إغلاق هذا بدون تعليق؟

كان هناك تعليق ، لكنه أخفى بواسطة جيثب
https://github.com/moby/moby/issues/1996#issuecomment -93592837

+1

ستكون هذه الميزة منقذة للحياة بالنسبة لي الآن.

+1

إغلاق هذا لأننا لا نرى العديد من حالات الاستخدام في العالم الحقيقي

212 تعليقًا والعد ، ولكن لا توجد حالة استخدام؟ يبدو جاهلا جدا.

+1

+1

+1

+1

+1

المشكلة لا تزال هنا وما زالت تتطلب حلا. لا يزال هناك الكثير من استخدامات العالم الحقيقي.

+1

أظن أن مطوري Docker ليس لديهم حافز لتنفيذ ذلك ، لحماية البنية التحتية المركزية للمباني الخاصة بهم من أن تكون DDs'ed من خلال طلبات عدم التخزين المؤقت.

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

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

jaromil هذا ليس صحيحًا تمامًا ، لأن هذا غير ممكن في المستودعات ذاتية

ما هو البرنامج الموجود لتشغيل مستودع مستضاف ذاتيًا؟ لا أعرف حقًا ما تشير إليه.
يمكن أن يكون الحل البسيط المستضاف ذاتيًا عبارة عن cron cloning git repos و runnig docker build - no-cache - أنا متأكد من أن هذه المشكلة لا يمكن أن تحدث في البرامج مفتوحة المصدر: يمكن لأي شخص بعد ذلك تعديل سطر أوامر docker build.

jaromil لا أعتقد أن هذه هي المشكلة. سيكون من الأكثر فاعلية الحصول عليها لمشاريع DockerHub مفتوحة المصدر (بالإضافة إلى المشاريع المدفوعة ، فهي لا تفرض رسومًا على عدد البنيات). في بيئة CI / CD ذات الإنشاءات المتكررة ، يزداد هذا الأمر سوءًا.

طالما أنك بحاجة إلى القيام بذلك (أنت تستخدم docker و git ولا تريد أن يكون لديك 5 حاويات تشغل وحدات تخزين مشتركة) ، يجب إعادة بناء الحاوية وتحميلها في كل مرة تقوم فيها بتحميل إصدار جديد. الحاوية بأكملها.
باستخدام علامة no-cache in-code ، في كل مرة تقوم فيها بتشغيل البنية ، تقوم فقط ببناء واستبدال تلك الطبقة المفردة بدلاً من الحاوية الكاملة لتحديث الإصدار.

حول مندوب الاستضافة الذاتية ، ستندهش. أفهم تعليق bluzi ، لا يوجد تأثير ddos ​​إذا كنت مضيفًا ذاتيًا (أو تستخدم aws ecr).

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

TLDR: أعتقد أن بعض التحسينات على وثائق Docker قد تساعد كثيرًا.

انتهى بي الأمر هنا بعد مواجهة مشاكلي الخاصة / الارتباك مع التخزين المؤقت. بعد قراءة جميع التعليقات هنا وفي https://github.com/moby/moby/pull/10682 ، وجدت حلاً عمليًا لحالة الاستخدام الخاصة بي. ومع ذلك ، بطريقة ما ما زلت أشعر بالإحباط من استجابة Docker لهذا ، ويبدو أن كثيرين آخرين يشعرون بنفس الطريقة.

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

عند القراءة بين السطور ، يبدو لي أن معظم المعلقين الأوائل على طلب الميزة هذا سيكونون سعداء بالحل الذي يستخدم وسيطات إضافية لـ docker image build لتعطيل ذاكرة التخزين المؤقت في نقطة معينة في Dockerfile. يبدو أن حل Docker الحالي لهذا (الموصوف في https://github.com/moby/moby/issues/1996#issuecomment-172606763) يجب أن يكون كافيًا في معظم هذه الحالات ، ويبدو أن العديد من المستخدمين سعداء بهذا . (إذا كان لدى أي شخص حالة استخدام حيث يمكنه تقديم حجج إضافية لـ docker image build ولكن هذا الحل لا يزال غير كافٍ ، فمن المحتمل أن يساعد في إضافة تعليق يشرح سبب عدم كفاية ذلك.)

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

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

في العديد من هذه الحالات ، يبدو أن حالة الاستخدام لا تتطلب في الواقع القدرة على تعطيل التخزين المؤقت في نقطة معينة في Dockerfile (والتي كانت النقطة الأصلية لطلب الميزة هذا). بدلاً من ذلك ، يبدو أن العديد من المستخدمين سيكونون سعداء بالقدرة على تعطيل التخزين المؤقت بالكامل من داخل Dockerfile ، دون استخدام الوسيطة "- no-cache" إلى docker image build ودون الحاجة إلى تعديلات يدوية على Dockerfile قبل كل يبني. (عند وصف حالات الاستخدام ، قد يكون من المفيد ذكر ما إذا كان التخزين المؤقت الجزئي مطلوبًا بالفعل أو ما إذا كان تعطيل ذاكرة التخزين المؤقت بالكامل سيكون كافيًا لحالة الاستخدام الخاصة بك.)

في الحالات التي تعمل فيها الخدمة docker image build نيابة عن المستخدم ، يبدو أن Docker يتوقع أن تقوم جميع هذه الخدمات إما بتعطيل ذاكرة التخزين المؤقت دون قيد أو شرط أو منح المستخدم خيارًا لتعطيل ذاكرة التخزين المؤقت. وفقًا لـ https://github.com/moby/moby/pull/10682#issuecomment-73777822 ، يقوم Docker Hub بتعطيل ذاكرة التخزين المؤقت دون قيد أو شرط. إذا لم تقم الخدمة بذلك بالفعل ، فقد اقترح Docker https://github.com/moby/moby/pull/10682#issuecomment-159255451 تقديم شكوى إلى مزود الخدمة بخصوص ذلك.

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

بالنسبة للحالات التي يتم فيها توزيع Dockerfiles على مستخدمين آخرين يقومون بعد ذلك بتشغيل docker image build بأنفسهم ، جادل بعض الأشخاص بأن استخدام الأمر البسيط docker build . (بدون وسيطات إضافية) شائع جدًا لدرجة أنه سيكون كذلك من غير المعقول لمنشئي Dockerfile أن يطلبوا من المستخدمين إضافة وسيطات ، بينما يطلب الأشخاص الآخرون (على سبيل المثال: https://github.com/moby/moby/issues/1996#issuecomment-72238673 https://github.com/moby/moby/pull / 10682 # issuecomment-73820913 https://github.com/moby/moby/pull/10682#issuecomment-73992301) قد جادل بأنه سيكون من غير المناسب منع المستخدمين دون قيد أو شرط من استخدام التخزين المؤقت عن طريق تجاوز ذاكرة التخزين المؤقت في Dockerfile. في حالة عدم وجود حالات استخدام مفصلة / مقنعة لهذا ، اتخذ Docker قرارًا تنفيذيًا لطلب حجج سطر أوامر إضافية للتحكم في التخزين المؤقت ، والذي يبدو أنه مصدر الكثير من الإحباط المستمر. (إذا كان لدى أي شخص حالة استخدام مقنعة تتعلق بهذا ، فمن المحتمل أن يساعد في إضافة تعليق يشرحها بالتفصيل.)

ومع ذلك ، يبدو لي أن Docker قد يكون قادرًا على إسعاد الجميع ببساطة عن طريق كسر عادة المستخدمين في تشغيل docker build . بدون حجج إضافية. لم يتم ذكر سلوك التخزين المؤقت والوسيطة "- no-cache" في أي من دروس Docker التعليمية ذات الصلة (مثل هذا أو هذا
أو هذا ). بالإضافة إلى ذلك ، في حين أن وثائق docker build تسرد الوسيطة "- no-cache" ، فإنها لا توضح أهميتها أو تبرز حقيقة أهميتها في العديد من حالات الاستخدام الشائع. (لاحظ أيضًا أن وثائق docker image build فارغة. يجب أن تشير على الأقل إلى وثائق docker build .) يبدو أن مرجع Dockerfile ووثائق أفضل الممارسات فقط هي التي تصف بالفعل سلوك التخزين المؤقت وتذكر الدور من حجة "- no-cache". ومع ذلك ، من المحتمل أن تتم قراءة هذه المستندات فقط بواسطة كتاب Dockerfile المتقدمين. لذا ، فليس من المستغرب أن المستخدمين المتقدمين هم فقط على دراية بالوسيطة "- no-cache" ، وأن معظم المستخدمين لن يقوموا إلا بتشغيل docker build . بدون وسيطات إضافية ثم يتم الخلط بينهم عندما لا يتصرفون كيف يتوقعون / يريد كاتب Dockerfile. ربما يؤدي تحديث الدروس ووثائق docker build لتذكر الوسيطة "- no-cache" وأهميتها إلى القضاء على هذه المشكلة؟

+1

+1

لا تسمح لك أداة docker الرسمية

+1

+1

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

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

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

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

+1 إلى CACHE OFF من هذا التوجيه السطر - لقد كنت أنتظر هذا لسنوات حرفيًا.

لقد اضطررت إلى تعطيل ذاكرة التخزين المؤقت على docker hub / docker cloud وهذا سيوفر أطنانًا من الوقت ويبني إذا كان بإمكاني تخزين الطبقة الكبيرة مؤقتًا ثم تشغيل أمر تحديث nocache بالقرب من نهاية ملف dockerfile.

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

يمكن أن ينتج عن --build-arg PASSWORD=<wrong> نتيجة مختلفة عن --build-arg PASSWORD=<correct> ، لذلك لست متأكدًا مما إذا كان مجرد النظر إلى محتويات قائمة الحزم سيعمل من أجل ذلك. لا يستطيع المنشئ أن يتوقع بنفسه تأثير إعداد / تغيير متغير البيئة على الخطوات التي يتم تشغيلها (هل make DEBUG=1 foo و make DEBUG=0 foo متماثلان؟). الاستثناء الوحيد الذي تم إجراؤه حاليًا هو متغيرات البيئة xx_PROXY ، حيث يُفترض أنه قد تكون هناك حاجة إلى وكيل لاتصالات الشبكة ، ولكن التبديل إلى وكيل مختلف يجب أن يؤدي إلى نفس النتيجة. لذلك لكي يعمل ذلك ، ستكون هناك حاجة إلى طريقة ما للإشارة إلى متغير بيئة معين (/ build arg) ليتم تجاهله للتخزين المؤقت.

لاحظ أن BuildKit لديه الآن دعمًا تجريبيًا لـ RUN --mount=type=secret و RUN --mount=type=ssh ، والذي قد يكون مفيدًا لتمرير الأسرار / بيانات الاعتماد ، ولكن قد لا يزال يبطل ذاكرة التخزين المؤقت إذا تغيرت هذه الأسرار (لست متأكدًا ؛ قد يكون هذا شيئًا طرح في أداة تعقب مشكلات buildkit https://github.com/moby/buildkit/issues).

لقد اضطررت إلى تعطيل ذاكرة التخزين المؤقت على docker hub / docker cloud

هل Docker Hub / Cloud في الواقع _use_ التخزين المؤقت؟ أعتقد أنه لا يتم استخدام التخزين المؤقت هناك (كما هو الحال في ؛ إنه يستخدم بيئات بناء سريعة الزوال)

أتذكر أن DockerHub اعتاد عدم استخدام التخزين المؤقت للبناء ، لكنني كنت أبحث في البنيات الآلية الخاصة بي على Docker Cloud قبل هذه التذكرة مباشرة ، وهناك شريط تمرير Building Caching بجوار شريط تمرير Autobuild لكل فرع الآن ، على الرغم من أنه مغلق افتراضيًا.

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

أفضل كثيرًا أن يتم تخزين git clone && make build المبدئي مؤقتًا ثم قم بإجراء NO CACHE على git pull && make build خطوة للحصول على تحديث رمز أصغر بكثير + التبعيات التي لم يتم تثبيتها بالفعل على أنها الأخيرة طبقة ، وبالتالي تخزين الجزء الأكبر من الصورة مؤقتًا بكفاءة ، ليس فقط للبنيات ، ولكن الأهم من ذلك لجميع العملاء الذين يتعين عليهم الآن إعادة تنزيل واستبدال مئات الميجابايت من الطبقات في كل مرة وهو أمر غير فعال للغاية.

يرجع الحجم إلى أن العديد من المشاريع لديها عدد كبير من التبعيات ، على سبيل المثال. حزم النظام + وحدات Perl CPAN + وحدات Python PyPI إلخ.

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

التخزين المؤقت للطبقات السابقة التي تتضمن جميع حزم النظام + وحدات CPAN + PyPI يعني أن القليل جدًا يجب أن ينتهي به الأمر إلى التغيير في آخر طبقة من التحديثات لأنني لن أقوم بتحديث الوحدات النمطية المثبتة العاملة في معظم الحالات (لقد استخدمت البرامج النصية من أدوات bash الخاصة بي ريبو الوحدة الفرعية المساعدة لتثبيت الحزم التي لم يتم تثبيتها بالفعل فقط لتجنب تثبيت تحديثات لا داعي لها غير إصلاح الأخطاء)

كنت أبحث في استخدام خدعة مثل تغيير ARG لفترة من الوقت (فكرة حصلت عليها من البحث في مدونات مثل http://dev.im-bot.com/docker-select-caching/):

في Dockerfile:

ARG NOCACHE=0

ثم قم بتشغيل docker build هكذا:

docker build --build-arg NOCACHE=$(date +%s) ...

لكنني لا أعتقد أن هذا ممكن في Docker Cloud.

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

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

يمكن أن ينتج عن --build-arg PASSWORD=<wrong> نتيجة مختلفة عن --build-arg PASSWORD=<correct> ، لذلك لست متأكدًا مما إذا كان مجرد النظر إلى محتويات قائمة الحزم سيعمل من أجل ذلك

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

نعم ، كنت أتخيل شيئًا مثل docker build --force-cache-build-arg SECRET=supersecret . هذا صعب جدًا ، أنا متأكد من أن شخصًا ما يمكن أن يأتي بشيء أفضل.

HariSekhon يبدو أن حالة الاستخدام الخاصة بك هي في الواقع عكس حالة الاستخدام الخاصة بي ، على الرغم من ذلك ، أليس كذلك؟ تريد قوة يغيب بشكل انتقائي ذاكرة التخزين المؤقت، بدلا من القوة انتقائي ضربت ذاكرة التخزين المؤقت؟

إضافة هذا عملت بالنسبة لي:

ADD http://date.jsontest.com/ /tmp/bustcache

لكن هذا الموقع معطل الآن. يجب أن يعمل هذا

ADD http://api.geonames.org/timezoneJSON?formatted=true&lat=47.01&lng=10.2&username=demo&style=full /tmp/bustcache

itdependsnetworks

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

لقد جربت هذا ويجب أن تتغير الملفات الخاصة الأخرى المماثلة في كل مرة

COPY /dev/random ...

لكن هذا لم ينجح على الرغم من أن RUN ls -l -R /etc أظهر أن مثل هذه الملفات كانت موجودة دائمًا لم يتم العثور عليها ، أظن أن هناك بعض الحماية ضد استخدام الملفات الخاصة.

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

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

الأول يكسر حصته اليومية طوال الوقت والثاني يعطي هذا الخطأ الآن

{"status": {
  "message": "the daily limit of 20000 credits for demo has been exceeded. Please use an application specific account. Do not use the demo account for your application.",
  "value": 18
}}

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

سيكون استخدام المثال:

FROM something
... 
CACHE_BUST git ls-remote my-git-repo HEAD
RUN git clone --depth=1 my-git-repo ...
...
CMD ["my-cmd"]

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

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

سيبدو سير العمل الحالي كما يلي:

ARG SHA_TO_BUILD
RUN echo SHA_TO_BUILD
RUN git clone ...
...everything else reliant on that clone

$> ./build-my-image.sh $(get-latest-sha)

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

هذه الميزة الرائعة ، لماذا لا تزال معلقة؟

حالة استخدام أخرى هي عندما تتغير محتويات الملف ولكن لم يتغير Dockerfile .

على سبيل المثال ، إذا كان لدي COPY file.txt . وقمت بتعديل file.txt Docker فسيظل يستخدم النسخة القديمة المخبأة.

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

اعتبارًا من الآن ، أضطر إلى استخدام --no-cache وهذا التنزيل والأداء أكثر مما هو مطلوب (إضاعة الوقت وعرض النطاق الترددي).

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

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

Am Mi. ، 20. März 2019 um 00:10 Uhr schrieb Tibor Vass <
[email protected]>:

brennancheung https://github.com/brennancheung إذا كان هذا هو الحال ،
إنه خطأ. لا تتردد في فتح مشكلة منفصلة بخطوات قابلة للتكرار.

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

-
تياجو رودريغيز

حاولت هذا https://github.com/moby/moby/issues/1996#issuecomment -185872769

لكنها تؤثر فقط على ذاكرة التخزين المؤقت عند / بعد الاستخدام الأول وليس مجرد تعريفها.

https://docs.docker.com/engine/reference/builder/#impact -on-build-caching

إذا كان Dockerfile يعرّف متغير ARG تختلف قيمته عن البنية السابقة ، فإن "خطأ ذاكرة التخزين المؤقت" يحدث عند استخدامه لأول مرة ، وليس عند تعريفه.

samstav "first use" يوجد أول RUN بعد ARG (إذا كان هذا ARG مع مرحلة بناء) ، لذلك:

ARG FOO=bar

FROM something
RUN echo "this won't be affected if the value of FOO changes"
ARG FOO
RUN echo "this step will be executed again if the value of FOO changes"

FROM something-else
RUN echo "this won't be affected because this stage doesn't use the FOO build-arg"

يعتمد ما سبق قليلاً إذا كنت تستخدم أداة إنشاء الجيل التالي (BuildKit) ، لذلك مع تمكين DOCKER_BUILDKIT=1 ، لأن BuildKit يمكنه تخطي مراحل البناء إذا لم تكن هناك حاجة إليها للمرحلة النهائية (أو تخطي مراحل البناء إذا كان من الممكن تخزينها مؤقتًا بالكامل)