Moby: नई सुविधा का अनुरोध: Dockerfile में विशिष्ट RUN कमांड के लिए कैशिंग को चुनिंदा रूप से अक्षम करें

मुझे लगता है कि इसका मुकाबला करने का तरीका डॉकरीफाइल में उस बिंदु को लेना है जिसे आप कैश करना चाहते हैं और टैग करना चाहते हैं कि आपके भविष्य में उपयोग करने के लिए एक छवि के रूप में डॉकरफाइल के FROM , जिसे तब बनाया जा सकता है -no-cache बिना परिणाम के, क्योंकि मूल छवि का पुनर्निर्माण नहीं किया जाएगा।

लेकिन क्या यह कैश्ड और गैर-कैश्ड कमांड को आसानी से इंटरलीव करने की सीमा नहीं होगी?

उदाहरण के लिए मान लें कि मैं अपने रेपो को अपडेट करना चाहता हूं और सर्वर से फाइलों को मिटाना चाहता हूं और बीच में चरणों का गुच्छा करना चाहता हूं - उदाहरण के लिए रेपो से सॉफ़्टवेयर इंस्टॉल करें (जिसे अपडेट किया जा सकता था) - डाउनलोड की गई फ़ाइल पर संचालन करें (जो बदल सकता था सर्वर) आदि।

हर बार कैश के बिना विशिष्ट कमांड चलाने के लिए डॉकरफाइल में डॉकटर को निर्दिष्ट करने के लिए आदर्श क्या होगा और कोई बदलाव नहीं होने पर पिछली छवि का पुन: उपयोग करें (उदाहरण के लिए रेपो में कोई अपडेट नहीं)।

क्या यह उपयोगी नहीं होगा ?

Dockerfile में CACHE ON और CACHE OFF के बारे में क्या? प्रत्येक निर्देश बाद के आदेशों को प्रभावित करेगा।

हाँ, मैं अपने डॉकरफाइल में git clone कमांड का उपयोग कर रहा हूं, और अगर मैं इसे अपडेट के साथ फिर से क्लोन करना चाहता हूं, तो मुझे उस से पुनर्निर्माण को ट्रिगर करने के लिए लाइन के अंत में एक टिप्पणी जोड़ने की जरूरत है। रेखा। मुझे इस चरण के लिए एक नया बेस कंटेनर बनाने की आवश्यकता नहीं है।

क्या एक कंटेनर आईडी को 'डॉकर बिल्ड' को "इस आईडी से पहले कैश न करें" निर्देश के रूप में पास किया जा सकता है? जिस तरह से 'डॉकर बिल्ड' डॉकरफाइल में एक बदली हुई लाइन तक सभी चरणों को कैश करेगा?

मैं सहमत हूं कि हमें बिल्ड कैश पर अधिक शक्तिशाली और बेहतर नियंत्रण की आवश्यकता है। वर्तमान में मुझे यकीन नहीं है कि उपयोगकर्ता को इसे कैसे उजागर किया जाए।

मुझे लगता है कि आगामी एपीआई एक्सटेंशन, विशेष रूप से नामकरण और आत्मनिरीक्षण के साथ यह आसान हो जाएगा।

एक बेहतरीन फीचर होगा। वर्तमान में मैं RUN a=a some-command जैसी मूर्खतापूर्ण चीजों का उपयोग कर रहा हूं, फिर कैश को तोड़ने के लिए RUN a=b some-command

कैश पर बेहतर नियंत्रण प्राप्त करने से सीआई से डॉकर का उपयोग करना बहुत अधिक खुश होगा।

@shykes

एक बूल से एक स्ट्रिंग में --no-cache बदलने के बारे में क्या है और क्या यह एक रेगेक्स लेता है जहां डॉकर में हम कैश को बस्ट करना चाहते हैं?

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

मैं सहमत हूं और आईआरसी पर इस सटीक सुविधा का सुझाव दिया है।

सिवाय मुझे लगता है कि रिवर्स संगतता को संरक्षित करने के लिए हमें एक नया ध्वज बनाना चाहिए ("--unache" कहें) ताकि हम --cached को एक (बहिष्कृत) बूल ध्वज के रूप में रख सकें जो "--uncache .*" को हल करता है।

शुक्र, 7 फरवरी, 2014 को सुबह 9:17 बजे, माइकल क्रॉस्बी सूचनाएं @github.com
लिखा था:

@shykes
एक बूल से एक स्ट्रिंग में --no-cache बदलने के बारे में क्या है और क्या यह एक रेगेक्स लेता है जहां डॉकर में हम कैश को बस्ट करना चाहते हैं?

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 अब सर्वर को एक मान्य रेगेक्स स्ट्रिंग भेजता है।
• बस --no-cache कॉल करने से डिफ़ॉल्ट रूप से .*
• फिर रेगेक्स का उपयोग एक नई विधि 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 - someRegex मेल खाने वाले किसी भी RUN या ADD आदेशों को अनदेखा करता है

ठीक है, यह सब ठीक है। समस्या यह है कि --no-cache एक बूल है, इसलिए मौजूदा व्यवहार वास्तव में है:

• --no-cache=true - कैशे को स्पष्ट रूप से अक्षम करें
• --no-cache=false - कैशे को स्पष्ट रूप से सक्षम करें
• --no-cache - --no-cache=true लिए आशुलिपि

मुझे यह भी लगता है कि हम इसे हल करने के लिए "सच्चे" और "झूठे" विशेष मामले रेगेक्स स्ट्रिंग्स बनाकर खुद को एक अक्षमता कर रहे हैं, क्योंकि इससे भविष्य में हमारे उपयोगकर्ताओं के लिए संभावित रूप से आश्चर्यजनक व्यवहार पैदा होगा। ("जब मैं 'सत्य' या 'झूठे' के रेगेक्स के साथ --no-cache उपयोग करता हूं, तो यह उस तरह काम नहीं करता जैसा इसे माना जाता है!")

@tianon हाँ तुम सही हो। जल्दी से देखा और लोग =सच/गलत का उपयोग कर रहे हैं।

जैसा कि आप सुझाव देते हैं, नया झंडा जोड़ने के लिए पीआर को संशोधित करने में खुशी हुई , अनुरक्षक क्या सोचते हैं (

@wagerlabs दृष्टिकोण के लिए +1

@crosbymichael , @timruffles क्या यह बेहतर नहीं होगा यदि Dockerfile के लेखक यह निर्णय लें कि कौन सा बिल्ड चरण कैश किया जाना चाहिए और कौन सा नहीं? डॉकरफाइल बनाने वाला व्यक्ति जरूरी नहीं कि छवि बनाने वाला ही हो। निर्णय को डॉकर बिल्ड कमांड में स्थानांतरित करने के लिए उस व्यक्ति से विस्तृत ज्ञान की आवश्यकता होती है जो केवल एक विशिष्ट डॉकरफाइल का उपयोग करना चाहता है।

एक कॉर्पोरेट वातावरण पर विचार करें जहां कोई व्यक्ति कुछ निर्भरताओं को अद्यतन करने के लिए मौजूदा छवि पदानुक्रम का पुनर्निर्माण करना चाहता है। मौजूदा Dockerfile ट्री किसी और के द्वारा सालों पहले बनाया जा सकता है।

@wagerlabs दृष्टिकोण के लिए +1

+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 मिनट में अला। यह मेरे लिए काम करता है क्योंकि मेरे पास हर बार डॉकरफाइल उत्पन्न करने वाली एक स्क्रिप्ट है, लेकिन यह उस स्क्रिप्ट के बिना काम नहीं करेगी।

सुविधा के लिए +1।

मैं भी इस सुविधा के लिए वोट करना चाहता हूं। गिट रिपॉजिटरी से कंटेनर के कुछ हिस्सों का निर्माण करते समय कैश परेशान होता है जो केवल मास्टर शाखा पर अपडेट होता है।
:+1:

@hiroprotagonist आपके ENTRYPOINT git pull होने से मदद मिल सकती है?

@amarnus मैं इसे विचार @tfoote था के लिए इसी तरह समाधान कर लिया है। मैं जेनकींस जॉब से बिल्ड चला रहा हूं और सीधे डॉकर बिल्ड कमांड चलाने के बजाय जॉब एक ​​बिल्ड स्क्रिप्ट शुरू करता है जो एक टेम्पलेट से डॉकरफाइल उत्पन्न करता है और गिट कमांड के ऊपर 'रन इको करंटमिलीज' लाइन जोड़ता है। सेड और पाइप्स की बदौलत यह कुछ ही मिनटों की बात थी। वैसे भी, मैं अभी भी इस सुविधा को डॉकरफाइल के हिस्से के रूप में पसंद करता हूं।

@wagerlabs दृष्टिकोण के लिए मेरा +1 जोड़ना। सीआई के साथ भी यह समस्या है। मैं अभी के लिए एक गतिशील इको रन स्टेटमेंट का उपयोग कर रहा हूं, लेकिन मुझे यह सुविधा पसंद आएगी।

कैश ऑन/ऑफ के लिए +1। मेरा उपयोग मामला सीआई स्वचालन भी है।

+1, विशेष रूप से एक रन कमांड कैश अंतराल सेट करने की क्षमता जैसे @ cressie176 उदाहरण

"उदाहरण के लिए रेपो अपडेट करना या रिमोट फाइल डाउनलोड करना"

+1

अगर यह किसी की मदद करता है, तो यहां कोड का टुकड़ा है जिसका उपयोग मैं अपने जेनकींस बिल्ड में कर रहा हूं:

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

कैश ऑन/ऑफ के लिए +1

कैश ऑन/ऑफ दृष्टिकोण के संभावित विकल्प के रूप में, "ALWAYS" जैसे अतिरिक्त कीवर्ड के बारे में क्या। कीवर्ड का उपयोग मौजूदा कमांड के संयोजन में किया जाएगा (उदाहरण के लिए "हमेशा चलाएं" या "हमेशा जोड़ें")। डिज़ाइन के अनुसार, "ALWAYS" कीवर्ड आसन्न कमांड को पूरा करने के लिए कैशे में नहीं जाता है। हालाँकि, यह परिणाम की तुलना CACHE से करता है (अर्थात दूसरी बार उसी लाइन को निष्पादित करने के लिए कैश), कैश्ड छवि से लिंक करता है यदि ALWAYS कमांड का परिणाम अपरिवर्तित रहता है।

मेरा मानना ​​​​है कि अंतर्निहित आवश्यकता "गैर-बेवकूफ निर्देशों" की पहचान करना है। ALWAYS कमांड इसे बहुत स्पष्ट रूप से करता है। मेरी धारणा यह है कि कैश ऑन/ऑफ दृष्टिकोण समान रूप से अच्छी तरह से काम कर सकता है, लेकिन कोड के ब्लॉक पर बहुत सारे स्विचिंग की भी आवश्यकता हो सकती है (जो उपयोगकर्ताओं को वास्तव में आवश्यकता से अधिक लाइनों को अवरुद्ध करने के लिए प्रोत्साहित कर सकती है)।

मैं आदेशों के उपसर्ग के लिए भी अधिक हूं, जैसे 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

जाहिर है आप अपना खुद का उपयोग केस और नेटवर्क यादृच्छिक जीन चुन सकते हैं। वैसे भी शायद यह कुछ लोगों को idk से बाहर निकालने में मदद करेगा।

@wagerlabs दृष्टिकोण के लिए एक और +1

सुविधा के लिए एक और +1। इस बीच @cruisibesarescondev वर्कअराउंड का उपयोग

सुविधा अनुरोध के लिए एक और +1। और समाधान के लिए @cruisibesarescondev को धन्यवाद

सुविधा के लिए एक और +1।

समाधान के लिए चीयर्स @cruisibesarescondev ।

मुझे लगता है कि ALWAYS कीवर्ड एक अच्छा तरीका है, विशेष रूप से क्योंकि इसमें सरल स्पष्ट शब्दार्थ हैं। थोड़ा और अधिक जटिल दृष्टिकोण न्यूनतम समय जोड़ना होगा, (बिल्डफार्म या निरंतर एकीकरण जैसी चीजों में उपयोगी)। उसके लिए मैं एक सिंटैक्स "हर XXX" का प्रस्ताव दूंगा जहां XXX एक टाइमआउट है। और अगर यह उस कमांड के कैशे के निर्माण के बाद से XXX से अधिक लंबा है, तो उसे कमांड को फिर से चलाना होगा। और जांचें कि क्या आउटपुट बदल गया है। यदि कोई परिवर्तन अंतिम अद्यतन समय को ध्यान में रखते हुए कैश्ड परिणाम का पुन: उपयोग नहीं करता है। इसका मतलब यह होगा कि हर 0 हमेशा की तरह ही होगा।

इस समय एक वर्कअराउंड के लिए मैं अजगर में एम्पी टेम्प्लेट का उपयोग करके अपनी डॉकरफाइल्स उत्पन्न करता हूं और मैं निम्नलिखित स्निपेट्स को एम्बेड करता हूं जो ऊपर के रूप में काम करता है सिवाय इसके कि दो लगातार रनों में एक ही परिणाम का पता नहीं चलता है, लेकिन हर 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।

+1 हमेशा वाक्यविन्यास के लिए।

हां, ALWAYS सिंटैक्स बहुत सहज दिखता है।

मुझे CACHE ON/OFF पसंद नहीं है क्योंकि मुझे लगता है कि लाइनें "स्वयं निहित" होनी चाहिए और Dockerfiles में ब्लॉक जोड़ने से बहुत सारी "परेशानी" होगी (जैसे कि "क्या यह लाइन कैश द्वारा कवर की गई है?" विलय करते समय .. ।)

@kuon मुझे लगता है कि पहले से ही कई कमांड हैं जो बाद के निर्देशों को प्रभावित करते हैं, जैसे USER और WORKDIR

हाँ, यह सच है, लेकिन मैं उनका उपयोग उसी कारण से नहीं करता। मैं हमेशा RUN cd ... && या RUN su -c ...&& करता हूं।

मैं एक ब्लॉक नोटेशन पसंद करूंगा:

CACHE OFF {
    RUN ...
}

यह अधिक स्पष्ट है और गलती से CACHE OFF लाइन डालने से बचें (यह एक सिंटैक्स त्रुटि को ट्रिगर करेगा)।

मैं इसे खत्म कर सकता हूं, डॉकरफाइल वास्तव में उत्पादन में नहीं चल रहे हैं (केवल छवि बनाते समय), इसलिए जब आप निर्माण करते हैं तो कैश अक्षम होने से वास्तव में बहुत नुकसान नहीं होगा। लेकिन मुझे यह भी लगता है कि डॉकरफाइल वास्तव में सीमित हैं (एक ही रन में && के साथ सभी कमांड को चेन करने के लिए, छवियों का एक गजियन बनाने से बचने के लिए, चर का उपयोग करने में सक्षम नहीं है ...)

हो सकता है कि यह समस्या एक नए Dockerfile प्रारूप का अवसर हो।

मैंने अभी जो कहा, उस पर वापस आना चाहूंगा। मैंने पढ़ा कि @shykes ने एक अन्य अंक में क्या कहा https://github.com/docker/docker/pull/2266 और मैं भी उससे सहमत हूं (Dockerfile को भाषा की तरह वास्तव में सरल असेंबली रहने की आवश्यकता है)।

मैंने कहा कि मुझे वेरिएबल या इस तरह की चीजें चाहिए, लेकिन इसे किसी अन्य भाषा द्वारा कवर किया जा सकता है, लेकिन इस मामले में, डॉकरफाइल में प्रत्येक पंक्ति स्वयं निहित होनी चाहिए, उदाहरण के लिए:

NOIMAGE ALWAYS RUN USER:jon  apt-get update

जो हमेशा कमांड (कोई कैशे नहीं) चलाएगा, लेकिन एक छवि भी नहीं बनाएगा और उपयोगकर्ता जॉन का उपयोग करेगा।

इस तरह की स्वयं निहित रेखा किसी भी अन्य भाषा से उत्पन्न करना बहुत आसान है। यदि आपको संदर्भ (उपयोगकर्ता, कैश, वर्कडिर) के बारे में चिंता करने की ज़रूरत है, तो यह अधिक त्रुटि प्रवण है।

क्या यह आसानी के लिए RUN! हो सकता है, कृपया?

इस पर कोई स्टेटस अपडेट?

कैश को चुनिंदा रूप से अक्षम करना बहुत उपयोगी होगा। मैं awscli कमांड (अमेज़ॅन एडब्ल्यूएस टूलकिट से) के माध्यम से रिमोट अमेज़ॅन एस 3 रिपोजिटरी से फाइलों को पकड़ता हूं, और मेरे पास एडीडी कमांड के माध्यम से कैश को बस्ट करने का कोई आसान तरीका नहीं है (कम से कम मैं डॉकरफाइल को संपादित किए बिना एक तरीका नहीं सोच सकता इसे ट्रिगर करने के लिए)। मेरा मानना ​​​​है कि रन का उपयोग करते समय कैश को चुनिंदा रूप से बस्ट करने के लिए उपयोगकर्ता को नियंत्रण वापस देने का एक मजबूत मामला है। अगर किसी के पास मेरे लिए कोई सुझाव है तो मुझे आपकी बात सुनकर खुशी होगी।

इस मुद्दे को थोड़ा ऊपर उठाना चाहता था क्योंकि यह एक ऐसी चीज है जिसकी हमें बहुत जरूरत है।

अभी भी आश्वस्त ALWAYS सिंटैक्स आदर्श है।

कैसे एक साधारण BREAK कथन के बारे में।

@ cpuguy83 जो मेरे विशेष उपयोग के मामले में भी काम करेगा।

मुझे यकीन नहीं है कि तकनीकी रूप से संभव है कि केवल एक कमांड को कैश न किया जाए, लेकिन बाकी को कैश किया जाए। शायद इसलिए नहीं क्योंकि डॉकर वृद्धिशील अंतर पर आधारित है।

BREAK लिए समर्थन होने के बावजूद मुझे @CheRuisiBesares के सुझाव के आधार पर मेरे वर्तमान वर्कअराउंड के साथ फीचर समानता प्रदान करेगा।

मेरी पिछली पोस्ट के बारे में, यह वास्तव में स्क्रिप्ट में उस बिंदु से कैश को बस्ट करने के लिए पर्याप्त होगा, बाकी सिर्फ बुद्धिमान स्क्रिप्ट डिज़ाइन के लिए होगा (और मेरा मानना ​​​​है कि यह अधिकांश लोगों की आवश्यकताओं को पूरा करेगा)। क्या यह कैश बस्ट को चुनिंदा रूप से अक्षम करने के बजाय करने योग्य है?

@orrery आप उस बिल्ड-स्टेप से पहले COPY _before_ जोड़कर कैश को "बस्ट" कर सकते हैं। यदि कॉपी की गई फ़ाइल (फाइलें) अलग हैं, तो उसके बाद के सभी चरणों में कैश का उपयोग नहीं किया जाना चाहिए ( इस अनुभाग को देखें)। गंदी चाल, लेकिन आपके मामले को सुलझा सकती है।

ALWAYS (या समान अवधारणाएं जैसे EVERY # DAYS ) की कुंजी संलग्न कमांड के बाद कैश तुलना है। मेरे लिए (और मैं कई अन्य लोगों को मानता हूं), लक्ष्य प्रति कैश को बस्ट करना नहीं है।

• लक्ष्य यह सुनिश्चित करना है कि हम कैश का उपयोग बंद कर दें यदि और जब कमांड का परिणाम बदलता है (यानी "सबसे हाल के संस्करण में अपग्रेड करें")।
• इसके विपरीत, यदि परिणाम कैश्ड संस्करण से मेल खाता है, तो हम कैश का लाभ उठाना चाहते हैं ।

यह @hellais द्वारा टिप्पणी को संबोधित करता है क्योंकि आप बाद के आदेशों के लिए कैश का लाभ उठा सकते हैं ... यदि और केवल अगर ALWAYS का आउटपुट कैश्ड संस्करण से मेल खाता है (यह आसानी से अधिकांश समय हो सकता है)।

स्वाभाविक रूप से, एक ही तर्क _could_ को CACHE ON/OFF मॉडल में शामिल किया जा सकता है। कैश के साथ तुलना बाद के सभी आदेशों को फिर से चलाने की तुलना में सस्ता होने की संभावना है, लेकिन फिर भी महंगा हो सकता है। यदि कैश ऑन/ऑफ ब्लॉक किसी उपयोगकर्ता को ऑफ ब्लॉक में अतिरिक्त कमांड शामिल करने के लिए प्रोत्साहित करता है (ऐसा कुछ जो ALWAYS साथ नहीं हो सकता), तो यह प्रदर्शन में महत्वपूर्ण अंतर में योगदान कर सकता है।

मैं बिल्कुल उसी स्थिति में हूं जैसे

EVERY सिंटैक्स के लिए +1। ALWAYS सिंटैक्स से भी काम हो जाएगा।

@claytondaley यह एक अच्छी बात है। हालांकि, कमांड के लिए कैशिंग को पूरी तरह से अक्षम करने की क्षमता होना अभी भी महत्वपूर्ण है। हमेशा एक छिपी हुई अवस्था होगी जो स्वाभाविक रूप से डॉकर के लिए अदृश्य है। उदाहरण के लिए कमांड निष्पादित करने से दूरस्थ सर्वर पर स्थिति बदल सकती है।

@mkoval , आप ALWAYS का उपयोग करने के लिए एक महत्वपूर्ण समय के रूप में _creating _ छिपे हुए राज्यों के बारे में एक अच्छा बिंदु लाते हैं, लेकिन मुझे नहीं लगता कि यह कैश को फिर से शुरू करने के आसपास मेरे तर्क को प्रभावित करता है। उदाहरण को ठोस बनाने के लिए (यदि कुछ हद तक तुच्छ है), एक कमांड जो किसी तृतीय पक्ष सिस्टम को अपग्रेड करता है:

• एक छिपी हुई स्थिति बनाता है ( ALWAYS चलाने की आवश्यकता है) और
• वर्तमान कंटेनर को नहीं बदलता है

यदि अगले आदेश में एक छिपी हुई स्थिति (तुच्छ रूप से, कंटेनर पर एक एमवी कमांड) शामिल नहीं है, तो कैश 100% विश्वसनीय होगा। वही कंटेनर, वही कमांड, छिपी जानकारी पर कोई निर्भरता नहीं।

यदि अगली कमांड (या किसी भी बाद की कमांड) में छिपी जानकारी शामिल है, तो उसे ALWAYS कीवर्ड का उपयोग करना चाहिए, केवल कैश को फिर से शुरू करना चाहिए यदि परिणामी कंटेनर कैश से मेल खाता हो।

@claytondaley आपका समाधान मेरे लिए बहुत ही सुरुचिपूर्ण और कुशल लगता है। अगर इसे लागू किया जाता है तो मैं बहुत आभारी रहूंगा। :+1: :ऑक्टोपस:

+1 इस सुविधा के लिए ALWAYS और हर X सुझाए गए सिंटैक्स का उपयोग करते हुए। कैश ऑन/ऑफ मुझे थोड़ा अजीब लगता है, लेकिन मैं इसका इस्तेमाल करूंगा। मुझे वास्तव में @claytondaley के कैश को फिर से शुरू करने का सुझाव भी पसंद है जहाँ संभव हो।

+1 हमेशा वाक्यविन्यास के लिए। विशेष रूप से गिट रेपो से कोड खींचने के लिए।

+1 इनमें से किसी भी समाधान के लिए।

मैं थोड़ा उलझन में हूँ। कैशिंग को बंद करने के बाद उसे वापस कैसे चालू किया जा सकता है? एक बार जब आप इसे बंद कर देते हैं और कंटेनर में किसी भी तरह का बदलाव करते हैं, तो क्या कैशिंग को बंद करने के दौरान चलने वाले उन डॉकरफाइल कमांड द्वारा किए गए किसी भी बदलाव को मूल रूप से टॉस आउट करना नहीं होगा? मैंने सोचा था कि कैशिंग करने का पूरा कारण यह था क्योंकि हम पिछले आदेशों की पूरी सूची जानते थे जो चल रहे थे और गारंटी दे सकते थे कि कंटेनर में जो था वह वही था। यदि आप कैशिंग बंद कर देते हैं (और मैं इसके लुक-अप पक्ष के बारे में बात कर रहा हूं) तो क्या यह गारंटी नहीं उड़ाता है? या यह सिर्फ कैश को पॉप्युलेट नहीं करने के बारे में है?

सुझावों के बारे में मेरी समझ यह है कि आप हमेशा कदम को फिर से चलाने के लिए डॉकरफाइल कमांड के हिस्से के रूप में "ALWAYS" निर्दिष्ट कर सकते हैं। उदाहरण के लिए "RUN ALWAYS git clone https://example.com/myrepo.git " हमेशा चलेगा (जिससे हमेशा रेपो की क्लोनिंग होती है)। फिर @claytondaley जो सुझाव दे रहा है वह यह है कि इस आदेश को फिर से चलाने के बाद, डॉकर कैश के विरुद्ध परिवर्तनों की जांच करता है। यदि चेकसम समान है (अर्थात यदि क्लोन किए गए रेपो में कोई परिवर्तन नहीं हुआ है, तो नवीनतम परत कैश में समान परत के समान है), हम कैश को चालू रख सकते हैं। आप सही कह रहे हैं कि एक बार कैश अमान्य हो जाने के बाद, बाद के सभी चरण कैश का उपयोग नहीं कर सकते हैं। ये सुझाव कैश का उपयोग कब करना है, इस पर नियंत्रण की अधिक ग्रैन्युलैरिटी को सक्षम करते हैं, और जहां संभव हो वहां कैश से फिर से शुरू करने के बारे में भी स्मार्ट हैं।

@curtiszimmerman... बिल्कुल

@duglin ... यदि हम गणितीय प्रॉक्सी का उपयोग करते हैं तो विचार अधिक स्पष्ट हो सकता है। कैश (इस संदर्भ में) action B के परिणाम की स्मृति मात्र है जब इसे state A लागू किया जाता है, इसलिए आपको इसे पुन: संसाधित करने की आवश्यकता नहीं है। मान लें, मैं आदेशों का एक क्रम चलाता हूं:

• 6
• हमेशा * x चलाएं जहां x का मूल्य गिट रेपो से डाउनलोड किया जाता है (और इस प्रकार बदल सकता है)
• + 12 चलाएं

पहली बार जब मैं कमांड चलाता हूं, तो x 8 है इसलिए मुझे निम्न अनुक्रम (और कैश) मिलता है:

• 6
• 48 (के परिणाम के रूप * x के लिए आवेदन किया 6 )
• 60 (के परिणाम के रूप + 12 के लिए आवेदन किया 48 )

यदि मेरी मशीन कभी भी 48 फिर से (किसी भी क्रम से) स्थिति में पहुँचती है ... और उसे आदेश दिया जाता है + 12 , तो मुझे फिर से प्रसंस्करण करने की आवश्यकता नहीं है। मेरा कैश जानता है कि इस आदेश का परिणाम 60 ।

कठिन हिस्सा यह पता लगाना है कि आप फिर से उसी स्थिति ( 48 ) में हैं।

• हम सैद्धांतिक रूप से हर कमांड के बाद मशीन की तुलना हर दूसरी कैश्ड इमेज से कर सकते हैं, लेकिन यह संसाधन गहन है और इसमें मैच खोजने की संभावना बहुत कम है।
• मेरा प्रस्ताव इसे सरल रखने का है। हर बार जब हम एक राज्य में होते हैं (उदाहरण के लिए 6 ) और एक कमांड (जैसे * x ) हिट करते हैं तो हम परिणाम की तुलना पिछली बार (या समय) के कैश से करते हैं, हम उसी स्थिति में थे एक ही कमांड चला रहे हैं। यदि इस प्रक्रिया के बाद मशीन की स्थिति समान है (उदाहरण के लिए अभी भी 48 ), तो हम कैश को फिर से शुरू करते हैं। यदि अगला आदेश अभी भी + 12 , तो हम परिणाम को संसाधित करने के बजाय कैश से खींचते हैं।

@claytondaley लेकिन मुझे समझ में नहीं आता कि आप वर्तमान स्थिति का निर्धारण कैसे करते हैं। जैसा कि आपने कहा, हम कंटेनर की सभी फाइलों की तुलना नहीं कर रहे हैं। जिस तरह से कैश अब काम करता है वह मूल रूप से अगले कमांड को केवल strcmp करना है जिसे हम वर्तमान कंटेनर से सभी ज्ञात बच्चों के कंटेनरों के खिलाफ चलाना चाहते हैं। जिस मिनट आप प्रवाह में एक कंटेनर छोड़ते हैं, मैं नहीं देखता कि आप कभी भी अपने वर्तमान कंटेनर को कैसे मान सकते हैं कि फाइल सिस्टम में सभी फाइलों की जांच करने वाले किसी अन्य कैश्ड कंटेनर की तरह है। लेकिन शायद मैं समझ नहीं पा रहा हूं कि तुम क्या कर रहे हो।

मुझे इसे फिर से लिखने दें .... एक यादृच्छिक कंटेनर दिया गया है (जो मूल रूप से आपके पास है यदि आप कैश का उपयोग नहीं कर रहे हैं) आप कैश में एक कंटेनर कैसे ढूंढ सकते हैं जो इससे मेल खाता है जो सभी फाइलों को अलग करता है कंटेनर?

@claytondaley @duglin यह निर्धारित करना कि क्या "कोई कैश नहीं" ऑपरेशन को बिना किसी बदलाव के कैश किया जा सकता है, जैसा कि आपने वर्णन किया है, एक कठिन समस्या है। यह कड़ाई से आवश्यक होने के बजाय एक अच्छा-से-अधिक है।

व्यक्तिगत रूप से, मुझे अधिक खुशी होगी यदि मेरे पास यह सुनिश्चित करने की क्षमता हो कि एक कमांड हमेशा चलता रहे। एक डॉकरफाइल लें जैसे:

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 कमांड मिलती है और यह करना आसान है। जो मुझे नहीं मिलता वह एक कमांड है जो इसे w/o diffing/hashing/जो भी संपूर्ण फाइल सिस्टम पर वापस कर देता है।

मैंने डॉकर की

• डॉकर प्रत्येक कमांड के लिए एक "लेयर" बनाता है।
• उस परत में केवल उस आदेश द्वारा बदली गई फ़ाइलें (या संभवतः "सहेजी गई" चाहे परिवर्तित या अपरिवर्तित हों) शामिल हैं।
• फ़ाइल सिस्टम की वर्तमान स्थिति तार्किक रूप से (यदि परिचालन में नहीं है) तब तक प्रत्येक परत की जाँच करके हासिल की जाती है जब तक कि उसे उस विशेष फ़ाइल का (सबसे हाल ही में अद्यतन) संस्करण नहीं मिल जाता।

इस मामले में, एक ही कमांड के दो उदाहरणों की तुलना अपेक्षाकृत सस्ती है। आपको केवल शीर्ष परत की तुलना करने की आवश्यकता है (क्योंकि प्रत्येक अंतर्निहित परत साझा की जाती है)। कमांड द्वारा बदली गई फाइलों की एक विशिष्ट सूची है। परत में केवल वे फ़ाइलें शामिल हैं। दी... आपको उस परत की सभी फाइलों की तुलना करनी होगी... लेकिन संपूर्ण फाइल सिस्टम की नहीं।

यह भी संभव है (हालांकि संपूर्ण होने की गारंटी नहीं है) केवल नई परत की तुलना पिछली बार कमांड चलाने के लिए की जाती है:

• ज्यादातर मामलों में (गिट पुल या सॉफ्टवेयर अपग्रेड), वर्तमान संस्करण या तो (1) पिछले संस्करणों के समान होगा या (2) एक नया संस्करण ... संस्करण।
• दुर्लभ मामलों में (जैसे देव-मास्टर में अपग्रेड करना और फिर एक स्थिर संस्करण में वापस जाना), पुराने संस्करण पर वापस जाना संभव है। हालांकि, ये बहुत दुर्लभ हैं ताकि ज्यादातर लोग शायद सबसे हाल के संस्करण की जांच कर रहे हों (अक्सर) बेहतर होंगे और दुर्लभ उदाहरण में वे रोलबैक करते हैं।

बेशक, आप पिछले सभी संस्करणों पर एक हैश जांच भी कर सकते हैं... इसके बाद एक पूर्ण फ़ाइल जांच... बिना ओवरहेड के पूर्ण समर्थन की पेशकश करने के लिए।

यदि आप https://github.com/docker/docker/pull/9934 के नीचे देखते हैं, तो आप Dockerfile कमांड के लिए समर्थन विकल्पों के बारे में एक चर्चा देखेंगे। क्या होगा यदि कोई --no-cache विकल्प सभी (या यहां तक ​​कि केवल RUN) पर उपलब्ध हो, जिसका अर्थ इस आदेश के लिए "कैश का उपयोग न करें"? उदाहरण:
RUN --no-cache apt-get install -y my-favorite-tool
यह तब शेष आदेशों के लिए भी कैश को स्वचालित रूप से अक्षम कर देगा (मुझे लगता है)।
क्या इससे मसला हल हो जाएगा?

"हमेशा चलाएं" और "रन --नो-कैश" के बीच जो शब्दार्थ रूप से समान हैं, मैं व्यक्तिगत रूप से अधिक प्राकृतिक दिखने वाले "हमेशा चलाएं" वाक्यविन्यास पसंद करूंगा। मैं उस पीआर पर आखिरी टिप्पणी से सहमत हूं: मुझे लगता है - विकल्प पठनीयता को तोड़ता है और डॉकरफाइल को बदसूरत बना देगा। इसके अतिरिक्त, मुझे लगता है कि डॉकरफाइल कमांडों को वास्तविक कमांडों की तुलना में बहुत अलग होने की आवश्यकता होगी जो उनका अनुसरण करते हैं। जटिल वाक्य रचना के एक उदाहरण के लिए "RUN --no-cache myapp --enable-cache" जैसे कुछ की कल्पना करें जो उस तरह के विकल्प के साथ खुद को जल्दी से व्यक्त करना शुरू कर देगा।

@curtiszimmerman आपका उदाहरण मेरे लिए बहुत स्पष्ट है। --no-cache RUN के लिए है जबकि --enable-cache myapp के लिए है। प्लेसमेंट मायने रखता है। उदाहरण के लिए देखें:
डॉकर रन -टी उबंटू एलएस -ला
लोग समझते हैं कि -ti 'रन' के लिए है जबकि '-la' 'ls' के लिए है। यह एक वाक्यविन्यास है जिसके साथ लोग सहज महसूस करते हैं।
हमेशा रन जैसी किसी चीज़ के साथ एक समस्या एक्स्टेंसिबिलिटी है। हमें एक सिंटैक्स की आवश्यकता है जो सभी डॉकरफाइल कमांड के लिए काम कर सके और वैल्यू पासिंग का समर्थन कर सके। उदाहरण के लिए, लोगों ने कुछ आदेशों के लिए USER निर्दिष्ट करने में रुचि व्यक्त की है।
रन USER=foo myapp
तकनीकी रूप से myapp के खोल के भीतर एक env var USER को 'foo' पर सेट कर रहा है। तो हम यहाँ अस्पष्ट हैं।
जबकि: RUN --user=foo myapp में यह समस्या नहीं है।
है: रन var=foo myapp
'var' या कुछ रन विकल्प प्राप्त करने का प्रयास कर रहे टाइपो नामक var को सेट और env करने का प्रयास कर रहा है?
IOW, एक मौजूदा वैध कमांड, IMO के साथ ओवरलैप होने की संभावना बहुत कम होती है जब हम चीजों को शुरू करते हैं - केवल एक शब्द की अनुमति देने की तुलना में

मैं वास्तव में रिवर्स अनुक्रम की वकालत करता हूं, EVERY <options> COMMAND । कई कारण:

• "उपयोगकर्ता" और "कैश" (कम से कम) के मामले में, वे वास्तव में पर्यावरण की विशेषताएं हैं जो किसी भी COMMAND को लपेट सकते हैं (हालांकि वे दूसरों को भौतिक रूप से प्रभावित नहीं कर सकते हैं)।
• सिंटैक्स RUN ALWAYS अर्थ है RUN कमांड दुभाषिया को बदलना, जो अनावश्यक लगता है।
• यह समस्या RUN EVERY 5 days साथ और भी बदतर है क्योंकि प्रत्येक से जुड़े विकल्प और भी अधिक अस्पष्टता पैदा करते हैं। EVERY 5 days RUN विकल्प को प्रभावित करने वाले आदेश के बारे में स्पष्ट है। हमारे पास RUN USER usr बनाम USER usr RUN साथ एक ही समस्या है। जब तक या तो (1) कमांड कीवर्ड कभी विकल्प नहीं होते या (2) उनसे बचने का एक आसान तरीका है, यह स्पष्ट है।

मैं उनके विकल्पों ( ALWAYS AS user RUN ... ) के साथ कमांड को प्रीफ़िक्स करके बोर्ड पर आ सकता था। मैं वास्तव में विकल्पों के लिए जीएनयू-स्टाइल लॉन्गॉप्ट्स का उपयोग करने के बारे में चिंतित हूं क्योंकि वे पुरानी या चमकदार आंखों से बहुत अलग नहीं हैं। मैं कल्पना कर सकता हूं कि 20 घंटे के बाद wtf चल रहा है, यह सोचकर मैं खुद को एक जटिल Dockerfile कमांड को घूर रहा हूं। लेकिन मैं भविष्यवाणी करता हूं --विकल्पों की परवाह किए बिना होने जा रहे हैं।

लेकिन मैं भविष्यवाणी करता हूं --विकल्पों की परवाह किए बिना होने जा रहे हैं।

इसके विपरीत अभी कुछ भी तय नहीं है; वाक्यविन्यास @duglin सुझाव दे रहा है कि एक वाक्यविन्यास के लिए एक _काउंटर प्रस्ताव_ है जिसे पहले प्रस्तावित/निर्णय लिया गया था। इसके बारे में अधिक जानकारी के लिए कृपया #9934 पढ़ें।

साथ ही, @duglin वह निर्णय लेने वाला व्यक्ति _not_ है (कम से कम, अकेले नहीं)। आपके द्वारा उठाए जा रहे कुछ बिंदुओं का उल्लेख दूसरे सूत्र में किया गया है।

मैं पठनीयता के बारे में आपकी चिंता साझा करता हूं, लेकिन यह भी सोचता हूं कि प्रस्तावित अन्य वाक्यविन्यासों में एक ही समस्या हो सकती है यदि एकाधिक विकल्प निर्दिष्ट किए जाने हैं।

पठनीयता के लिए डॉकरफाइल को प्रारूपित करके इस समस्या को दूर किया जा सकता है। मुझे लगता है कि उचित रूप से स्वरूपित होने पर पठनीयता एक चिंता का परीक्षण/जांच करने के लिए कुछ और उदाहरण लिखना अच्छा होगा।

और, हाँ, उस पर आपके इनपुट का स्वागत है।

मैं अभी भी बहुत -1 पर हूं कि Dockerfile को स्वयं परिभाषित करें कि कैश कहाँ है
लागू करना चाहिए और नहीं करना चाहिए। मुझे अभी तक a . का एक अच्छा उदाहरण देखना बाकी है
Dockerfile जिसे उचित रूप से कैश-बस्ट में फिर से नहीं लिखा जा सका और
स्वाभाविक रूप से जब अंतर्निहित संसाधन को अद्यतन करने की आवश्यकता होती है।

किसी विशेष स्थान पर कैश को रोकने के लिए "डॉकर बिल्ड" पर एक ध्वज होना
अधिक लचीला होगा, आईएमओ (और कैश का नियंत्रण वापस रखें
सिस्टम ऑपरेटर के हाथों में जो किसी भी तरह उस कैश को प्रबंधित करने के लिए मिलता है)।

@tianon -1 पर +1 (ताकि यह -1 हो!), और चरण N पर तोड़ने के लिए ध्वज जोड़ना उचित लगता है। यह देखते हुए कि एक बार कैश टूट जाने के बाद, यह बाकी Dockerfile के लिए वैसे भी टूट जाता है, मुझे लगता है कि यह समझ में आता है।

इसकी मुख्य आवश्यकता इसलिए है क्योंकि डॉकटर का कैशिंग तंत्र सीधे छवि के भंडारण और परिवहन से जुड़ा होता है, जो कुशल कैशिंग के लिए बनाता है लेकिन काफी बड़ी छवियों के व्यापार-बंद पर। तो चलिए इसे ठीक करते हैं!

डब्ल्यू/ओ कह रहा हूं कि मैं इस सुविधा के बारे में कैसा महसूस करता हूं - अभी तक निश्चित नहीं है, ईमानदार होने के लिए - आप लोग चरण एन पर रुकने के लिए किसी को ("डॉकर बिल्ड" से) कहने की कल्पना कैसे करते हैं? जब आज चरण N, कल चरण N+1 होगा, तो एक प्रकार से भंगुर लगता है।
ऐसा लगता है कि हमें डॉकरफाइल के भीतर किसी प्रकार का "लेबल" जोड़ने का एक तरीका चाहिए ताकि लोग उस लेबल को बिल्ड सीएमडी लाइन से संदर्भित कर सकें।
अगर हमारे पास वह था तो मुझे यकीन नहीं है कि मुझे इसके बीच बहुत अंतर दिखाई देता है और "STOP-CACHING" कमांड जोड़ने से Dockerfile में दिखाई देता है।
Dockerfile cmd का एक अच्छा उदाहरण क्या है जो हर बार कैश को बंद कर देगा?

खैर, यही कारण है कि मूल रूप से इसे बनाने के लिए चर्चा की गई थी
लाइन-कंटेंट-आधारित रेगेक्सपी, जिसके साथ मैं भी ठीक रहूंगा (विशेषकर तब से
यह जानने की तुलना में स्क्रिप्ट के लिए बहुत आसान है कि आप किस चरण संख्या को जानते हैं
कैश्ड नहीं चाहिए -- वैसे भी मैं करंट की पूरी कॉपी नहीं लिख रहा हूँ
बैश में डॉकरफाइल पार्सर, धन्यवाद: डी)।

टियांन ग्रेवी नोटिफिकेशन @github.com ने लिखा:

खैर, यही कारण है कि मूल रूप से इसे बनाने के लिए चर्चा की गई थी
लाइन-सामग्री-आधारित रेगेक्सपी, जिसके साथ मैं भी ठीक रहूंगा (विशेषकर
जबसे
यह जानने की तुलना में स्क्रिप्ट के लिए बहुत आसान है कि वास्तव में कौन सी चरण संख्या है
आप
कैश्ड नहीं चाहिए -- वैसे भी मैं करंट की पूरी कॉपी नहीं लिख रहा हूँ
बैश में डॉकरफाइल पार्सर, धन्यवाद: डी)।

अपने पहले के सुझाव को दोहराना चाहूंगा, कि हमेशा/कैश-ब्रेकिंग
"रन" बस "रन!" होना चाहिए। 1 शब्द कमांड संरचना (?) रखने के लिए।

ऐसा लगता है कि एक विशिष्ट चरण पर कैश को तोड़ने के लिए एक डॉकरफाइल (कुछ ऐसा जोड़कर जो मूल रूप से यादृच्छिक है क्योंकि यह प्लेसहोल्डर है) को संपादित करना मुश्किल लगता है। मैं एक docker build सीएलआई विकल्प का उपयोग करूंगा जो हमेशा एक निश्चित कदम चलाता है, लेकिन पूरी तरह से @duglin से सहमत है कि कमांड को खिलाने के लिए विशिष्ट लाइन नंबर को ट्रैक करना भारी है। मैं अपने git clone से ठीक पहले डॉकरीफाइल में कुछ यादृच्छिक वर्ण (!)

@curtiszimmerman मैंने सुझाव दिया (!) क्योंकि यह अंग्रेजी में तात्कालिकता के समान कुछ इंगित करता है। ("तुम्हें यह करना चाहिए!")

मुझे लगता है कि डॉकरफाइल यह परिभाषित करने के लिए कम से कम एक उपयुक्त स्थान है कि कौन से आदेश अन/कैश-सक्षम होना चाहिए। "--no-cache=git" के साथ निर्माण करने के बाद (मुझे एहसास है कि यह ऐसा कुछ नहीं है जिसे आपने सुझाया है, लेकिन आपने मेरे लिए उद्धरण/तुलना करने के लिए कुछ भी सुझाव नहीं दिया है) अधिक कठोर लगता है।

रन पर फोकस क्यों? किसी भी कमांड के लिए कैशे का भंडाफोड़ क्यों नहीं होने देते?
एक जोड़ने की तरह लगता है:
बस्ट-कैश
Dockerfile कमांड का प्रकार कहीं अधिक लचीला होगा। और वास्तव में लचीलापन जोड़ने के लिए, यह वैकल्पिक रूप से ध्वज की अनुमति दे सकता है:
बस्ट-कैश $doit
जहां यह केवल तभी लागू होता है जब $doit परिभाषित किया जाता है - फिर यदि हम बिल्ड पर -e विकल्प के लिए समर्थन जोड़ते हैं ( https://github.com/docker/docker/pull/9176 ) तो लोग ऐसा कर सकते हैं:
डॉकर बिल्ड-ई डूइट = सच ...

@zamabe ओह, मैं पूरी तरह से RUN! उपयोग करूंगा, क्षमा करें। यहाँ मैं यह कहने के लिए (!) का उपयोग कर रहा था "यह असामान्य है!" हर बार जब मैं किसी विशिष्ट चरण पर कैश को तोड़ना चाहता हूं तो डॉकरफाइल संपादित करने के बारे में। किसी भी तरह से मैं एक विशिष्ट कदम से पहले डॉकरफाइल के अंदर कैश को बस्ट कर सकता हूं (और अतिरिक्त जीत के लिए, यदि कैश-बस्टिंग कमांड के बाद का चरण कैश में क्या है, तो कैश से जारी रखने के लिए पर्याप्त स्मार्ट बनें ) BUST-CACHE या ALWAYS RUN (या RUN ALWAYS ) या RUN! ... वास्तव में इस सुविधा का समर्थन करने वाला कोई भी तंत्र, मैं इसका उपयोग करूंगा।

@ डगलिन क्षमा करें? बग शीर्षक RUN कहता है जो एक उदाहरण के रूप में देना आसान है।

@curtiszimmerman आह।

स्वगत कथन के रूप में; मुझे लगता है कि कैश पुनर्वैधीकरण (?) कैश अमान्यता से थोड़ा आगे है, यह बग ढूंढ रहा है। हालाँकि मुझे वह पसंद है जो आप सुझाव दे रहे हैं, मैं कैश-बस्टिंग कमांड को यथासंभव अंत के करीब रखने के लिए अपने डॉकरफाइल को फिर से व्यवस्थित करूंगा। यह एक _possible_ कैश हिट से प्राप्त लाभों को नकार देता है क्योंकि आप _always_ आवश्यक गणना/तुलना करते हैं, जो संभवतः Dockerfile बिल्ड को सामान्य रूप से समाप्त करने की तुलना में भारी जुर्माना है क्योंकि कैश-बस्टिंग का उपयोग करने वाले लोग शायद कैश मिस की उम्मीद/उम्मीद कर रहे हैं।

@zamabe सहमत हुए। मेरा सुझाव है कि यदि कार्यान्वयन ऐसा करने के लिए काफी छोटा है, तो शायद कैश से जारी रखने के लिए एक विशेष आदेश, जो कैश-बस्टिंग पहचानकर्ता से अलग है। हर बार कैश को अक्षम करने के लिए एक निश्चित बिंदु पर DISABLE-CACHE जैसा कुछ, और यदि आपके पास एक उपयोग का मामला है जहां शेष डॉकरफाइल कैश से जारी रहने के मुकाबले महंगा होगा, तो DISABLE-CACHE? जैसा कुछ होगा यदि संभव हो तो कैश से जारी रखें। यह कोई सुझाव नहीं है, मैं जिस बारे में बात कर रहा हूं उसे व्यक्त करने के लिए सिर्फ एक प्रदर्शन है।

गिट रेपो से पुल कोड के लिए +1

+1

यह बहुत बड़ा होगा! अभी मेरे पास गिट क्लोन के लिए कैश को तोड़ने के लिए गिट प्रतिबद्ध हैश को डॉकरफाइल (प्लेसहोल्डर को ओवरराइट करना) में मेरे निरंतर एकीकरण का हिस्सा है।

मैंने इस मुद्दे को हल करने के लिए यह पीआर प्रस्तुत किया: https://github.com/docker/docker/pull/10682 ।
हालांकि यह कैशिंग को वापस चालू करने का समर्थन नहीं करता है, मुझे नहीं लगता कि आज यह संभव है।

+1

मैं Dockerfile में एक यादृच्छिक संख्या उत्पन्न कर रहा हूँ और यह कैश हो जाता है ...
NOACACHERUN निर्देश के लिए +1

+1
कुछ रन के लिए वास्तव में उपयोगी होना चाहिए, हमें हर बार सब कुछ पुनर्निर्माण किए बिना करने की ज़रूरत है

मैं देख रहा हूं कि git clone कैश से टकराएगा लेकिन go get -d नहीं होगा। कोई विचार क्यों?

@LK4D4 @calavera @jfrazelle @crosbymichael @tiborvass_ के साथ सामूहिक समीक्षा

इसे बंद करना क्योंकि हम यह नहीं देखते हैं कि कई वास्तविक दुनिया उपयोग के मामले हैं (अधिक विवरण के लिए संबंधित #10682 देखें)।

रन के लिए +1। अच्छा होगा।

+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 के माध्यम से यहां पहुंचा।

मेरा उपयोग मामला:
मेरे पास एक डॉकटर कॉन्फ़िगरेशन है, जो इसके निर्माण के दौरान ड्राई-रन मोड में एक ग्रूवी माइक्रोसर्विस ऐप को ग्रेडल के माध्यम से कॉल करेगा। इसका परिणाम यह होगा कि सभी आश्रित जावा पुस्तकालय (दूरस्थ एमवीएन भंडार से) स्थानीय डॉकर एमवीएन भंडार में डाउनलोड किए जाएंगे। ड्राई रन सिर्फ ऐप चलाएगा और तुरंत वापस आ जाएगा लेकिन यह सुनिश्चित करता है कि सभी जावा लाइब्रेरी निर्भरताएं लोड हो जाएं।
डॉकर रन चरण के दौरान उसी ऐप को gradle --offline मोड के माध्यम से निष्पादित किया जाएगा। यानी माइक्रोसर्विस ऐप सिर्फ स्थानीय एमवीएन रिपॉजिटरी डायरेक्टरी से लोड होगा। कोई महंगा, समय लेने वाला दूरस्थ पुस्तकालय प्राप्त नहीं होगा। जब मैं अब इस तरह की लाइब्रेरी का एक नया स्नैपशॉट संस्करण जारी करता हूं, तो डॉकर एक बिल्ड के दौरान रिमोट फ़ेच को ट्रिगर नहीं करेगा (यानी वह मेरे ग्रेडल ड्रायरुन सीएमडी को कॉल नहीं करेगा), जब तक कि मैं डॉकर निर्देशिका को संशोधित नहीं करता।

मेरा उपयोग मामला: किसी छवि पर उपयोग करने के लिए लाइब्रेरी का नवीनतम तृतीय पक्ष संस्करण प्राप्त करें। मैं उसके लिए डॉकर हब का उपयोग कर रहा हूं और AFAIK, यह कुछ भी कैश नहीं करेगा। लेकिन कौन जानता है कि यह कब बदल सकता है।
यदि docker में NOCACHE जैसा कमांड फ्लैग होता है, तो यह गारंटी देता है कि, कोई फर्क नहीं पड़ता कि छवि कहाँ बनाई गई है।

नवीनतम संस्करण, आईएमएचओ की तुलना में बिल्ड सिस्टम "फीचर" पर निर्भर होना बदतर है।

एक नया सिंटैक्स जोड़ने के बारे में: FORCE RUN git clone .... ?

अभी मैं कैश को अमान्य करने के लिए RUN _=$(date) git clone ... का उपयोग कर रहा हूं।

@ c9s क्या यह वास्तव में काम करता है? मुझे नहीं लगता कि यह करता है।

@duglin सेटिंग पर्यावरण चर मेरे लिए काम करता है। "फोर्स रन" सिर्फ एक प्रस्ताव है:]

@ c9s मैं नहीं देखता कि env var कैसे काम कर सकता है क्योंकि यह कंटेनर के खोल द्वारा किया जाता है, न कि डॉकरफाइल प्रोसेसिंग। जब मैं 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 क्लोनिंग गिट रेपो (केस का उपयोग करें)

इतने सारे +1, यदि आप अपनी डॉकर फ़ाइल में गिट रेपो खींचते हैं, तो कैश आपकी छवियों को निर्माण से रोकता है। सीआई के माध्यम से बिल्ड को आगे बढ़ाना मुश्किल बनाता है।

+1 क्लोनिंग गिट रेपो (यह बहुत परेशान है कि छवि को हर बार एक गिट रेपो में एक छोटा संपादन किया गया है, खरोंच से बनाने की जरूरत है)

@Vingtoft यदि आप रेपो में फाइलों को अपडेट कर रहे हैं तो आपका कैश अमान्य है।

@itsprdp मुझे यह नहीं पता था, स्पष्ट करने के लिए धन्यवाद।

@itsprdp मैंने अभी परीक्षण किया है। जब मैं रेपो को अपडेट कर रहा हूं और छवि बना रहा हूं, तब भी डॉकर कैश का उपयोग कर रहा है।
शायद मैं कुछ गलत समझ रहा हूँ?

@itsprdp यह मेरे अनुभव में सही नहीं है। मैंने परीक्षण करने के लिए रेपो के लिए एक नई प्रतिबद्धता बनाई है, और फिर से निर्माण करते समय, यह उसी कैश का उपयोग करता है।

अगर मैं डॉकर फ़ाइल को रेपो से पहले बदलता हूं, तो निश्चित रूप से यह कैश बस्टेड हो जाएगा, हालांकि रेपो को अपडेट करने से यह समस्या ठीक नहीं होती है।

@RyanHartje भ्रम के लिए क्षमा करें। यदि भंडार अद्यतन किया गया है और योगदानकर्ताओं द्वारा विचार करने के लिए कुछ है तो इसे कैश को अमान्य करना चाहिए।
उपयोग के मामले @Vingtoft की अपेक्षा रिपॉजिटरी को कैश करना है और केवल रिपॉजिटरी में बदली गई फाइलों को अपडेट करना है। इसे लागू करना जटिल हो सकता है।

@itsprdp केवल रेपो में बदली गई फ़ाइलों को अपडेट करना बहुत ही बढ़िया होगा, लेकिन कम (या मुझे और कहना चाहिए?)
मेरे उपयोग-मामले (और कई अन्य) में वास्तविक गिट पुल में लंबा समय नहीं लगता है: यह विकास प्रवाह को मारने वाली हर चीज का निर्माण है।

+1, गिट क्लोन के दौरान उपयोग किया जाने वाला कैश :(

एक एकीकृत समाधान अच्छा होगा, लेकिन इस बीच आप एआरजी का उपयोग करके एक विशिष्ट डॉकरफाइल निर्देश पर कैश को बस्ट कर सकते हैं।

डॉकरफाइल में:

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

कमांड लाइन पर:

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

CACHEBUST को वर्तमान समय पर सेट करने का अर्थ है कि यह हमेशा अद्वितीय रहेगा, और Dockerfile में ARG घोषणा के बाद के निर्देशों को कैश नहीं किया जाएगा। ध्यान दें कि आप CACHEBUST बिल्ड-आर्ग को निर्दिष्ट किए बिना भी निर्माण कर सकते हैं, जिससे यह 1 के डिफ़ॉल्ट मान का उपयोग करेगा और कैश को संरक्षित करेगा। इसका उपयोग हमेशा गिट रेपो की ताजा प्रतियों की जांच करने, नवीनतम स्नैपशॉट निर्भरताओं को खींचने आदि के लिए किया जा सकता है।

संपादित करें: जो, उह, वही है जो @thaJeztah ने कहा था। मैं इसे उसके समाधान के अतिरिक्त विवरण के रूप में छोड़ दूँगा।

@ शेन-स्वयंसिद्ध 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 गिट रेपो के लिए कैश को

कैश ऑन के लिए +1 | बंद

+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 टैग की ओर इशारा करेंगे। इसका मतलब यह है कि जब तक हम package.json फ़ाइल को नहीं बदलते हैं, तब तक हम वास्तव में नवीनतम master नहीं करते हैं (आमतौर पर विवरण में केवल - और फिर परीक्षण के दौरान इसे हटा दें)।

RUN NO CACHE RUN की जगह लेने के लिए ऐसा लगता है कि यह एक अच्छा समाधान होगा।

+1

मेरे पास एनपीएम इंस्टॉल के लिए समान समस्या है जो कैश का उपयोग करती है और एनपीएम में मेरी नई प्रकाशित लाइब्रेरी का उपयोग नहीं करती है।

यह बहुत अच्छा होगा अगर मैं docker फ़ाइल में कैश प्रति रन कमांड को अक्षम कर सकता हूं।

@brycereynolds @mmobini कैश को मैन्युअल रूप से समाप्त करने के लिए https://github.com/docker/docker/issues/1996#issuecomment -172606763 देखें। हालाँकि, _not_ संकुल के एक विशिष्ट संस्करण को निर्दिष्ट करना जिसे स्थापित करने की आवश्यकता है, सबसे अच्छा अभ्यास नहीं हो सकता है, क्योंकि आपके Dockerfile (और स्रोत कोड) का अंतिम परिणाम अब प्रतिलिपि प्रस्तुत करने योग्य होने की गारंटी नहीं है (यानी, यह आज सफलतापूर्वक बनाता है, लेकिन नहीं करता है 'कल नहीं, क्योंकि पैकेजों में से एक को अपडेट किया गया था)। मैं इसे विकास के दौरान "ठीक" देख सकता हूं, लेकिन उत्पादन के लिए (और डॉकर हब पर स्वचालित निर्माण), सबसे अच्छा तरीका स्पष्ट रूप से एक संस्करण निर्दिष्ट करना है। ऐसा करने से उपयोगकर्ता उन सटीक पैकेजों को सत्यापित कर सकते हैं जिनका उपयोग छवि बनाने के लिए किया गया था।

मेरे पास एक उपयोग का मामला है जहां कैश को अमान्य करने में सक्षम नहीं होने से समस्याएं पैदा हो रही हैं। मैं डॉकर से ड्रॉपविज़ार्ड एप्लिकेशन (मावेन के साथ निर्मित जावा आरईएसटी सेवाएं) चला रहा हूं और एक स्वचालित प्रणाली मेरे लिए सभी कंटेनर निर्माण और तैनाती कर रही है। मैं अपने रेपो में एक डॉकरफाइल शामिल करता हूं और यह बाकी काम करता है। सिस्टम एक उत्पादन संस्करण और मेरे आवेदन के एक या अधिक विकास संस्करण चलाता है। विकास बिल्ड वे हैं जहां मुझे समस्याएं आ रही हैं।

विकास के दौरान, परियोजना की कुछ निर्भरता के संस्करण संख्या में स्नैपशॉट होते हैं। यह मावेन को निर्देश देता है कि संस्करण विकास के अधीन है और इसे हर निर्माण के साथ एक नया संस्करण लाना चाहिए। नतीजतन, एक समान फ़ाइल संरचना के परिणामस्वरूप दो अलग-अलग बिल्ड हो सकते हैं। यह वांछित व्यवहार है, क्योंकि हो सकता है कि बग्स को स्नैपशॉट निर्भरता में ठीक किया गया हो। इसका समर्थन करने के लिए, डॉकर को एक विशेष कमांड चलाने के लिए मजबूर करना मददगार होगा, क्योंकि फाइल सिस्टम की वर्तमान स्थिति के आधार पर कमांड के प्रभाव को निर्धारित करने का कोई तरीका नहीं है। अधिकांश जावा प्रोजेक्ट इसमें चलने वाले हैं, क्योंकि मावेन स्टाइल SNAPSHOT निर्भरता कई अलग-अलग बिल्ड सिस्टम द्वारा उपयोग की जाती है।

@ctrimble कैश को अमान्य करने के लिए आप --no-cache , या --build-arg का उपयोग कर सकते हैं।
आप सभी कैशेबल कमांड के साथ एक आधार छवि बनाकर --no-cache के प्रभाव को कम कर सकते हैं।

@ cpuguy83 उत्तर के लिए धन्यवाद। मैं धागा पढ़ता हूं और वर्तमान विकल्पों को समझता हूं। मैंने उस बिल्ड सिस्टम के साथ एक टिकट खोला है जिसका उपयोग मैं कैश बस्टिंग तर्क की आपूर्ति के लिए कर रहा हूं। एक ही एप्लिकेशन के लिए दो अलग-अलग छवियों का निर्माण करना बिल्ड को गति देने के लिए बहुत सारे हुप्स की तरह लगता है। कुछ निर्दिष्ट करने में सक्षम होना बहुत आसान होगा:

1. अगर फाइल सिस्टम समान है तो ऐसी चीजें करें जिन्हें कैश किया जा सकता है
2. ऐसा काम करें जो फ़ाइल सिस्टम को उसके निष्पादित होने के आधार पर बदल सकता है
3. कुछ और चीजें करें जिन्हें कैश किया जा सकता है यदि पिछले चरण ने फाइल सिस्टम को नहीं बदला है

यह पैटर्न डेवलपमेंट बिल्ड में बार-बार सामने आएगा। Dockerfile में इसके लिए शब्दार्थ होना अच्छा होगा।

@ctrimble कैश को एक चरण पर

@ cpuguy83 बिल्कुल। मेरे निर्माण प्रणाली के शब्दार्थ विकास के निर्माण के लिए अस्थायी हैं। मुझे कैशिंग पर सही बिल्ड का चयन करना है। मैं वास्तव में दोनों को प्राप्त करना चाहूंगा।

यहां काफी चर्चा हुई है, क्षमा करें यदि यह पहले से ही सुझाया गया है, लेकिन अगर ऐसा कुछ था तो क्या होगा:

CHECK [FILE_PATH]

सभी डॉकर फ़ाइल के एमडी 5 (या जो भी अन्य हैश हिप है) को स्टोर करेंगे और यदि यह बदलता है, तो उसके बाद के सभी चरण अमान्य हो जाते हैं।

मैं शायद कुछ ऐसा कर रहा हूँ:

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

एक समय अवधि के बाद कुछ कैसे समाप्त हो जाता है, यह भी एक चेक सक्षम करना चाहते हैं। apt प्लगइन के लिए Ansible का cache_valid_time पैरामीटर कुछ प्रेरणा प्रदान कर सकता है: http://docs.ansible.com/ansible/apt_module.html

उसके लिए, वाक्यविन्यास होगा:

EXPIRE 1234567 
RUN apt-get update
RUN bundle install

डॉकर अंतिम-रन समय को जानेंगे और गणना करेंगे कि क्या समय "अभी" के आधार पर बीत गया था।

@atrauzzi हम 1.13 में अभी निर्माण पर --squash समर्थन करते हैं (केवल अभी के लिए प्रायोगिक)।

@ 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
कृपया।

कैश ऑन|ऑफ +1

इन CACHE ON|OFF आदेशों के साथ समस्या यह है कि कैश को बंद करने के किसी भी चरण में, आगे के चरणों को कैश करने का कोई तरीका नहीं है। एकमात्र समझदार आदेश ENDCACHE ।

यह एक वैध विचार / लोकाचार है। कमांड को सभी गैर-कैश्ड परतों को एक साथ एक परत में उस बिंदु पर जोड़ना चाहिए जब कैश वापस चालू हो जाता है। बेशक आप अभी भी सबसे अच्छा नामकरण / शब्दार्थ की शुद्धता / सुविधा के पसंदीदा सिंटैक्स पर बहस कर सकते हैं।

+1

+1 में सुविधा होनी चाहिए

कैश ऑन|ऑफ +1 . के लिए सहमत

+1 अद्भुत होगा।

मुझे वास्तव में समझ में नहीं आया कि जिस तरह से डॉकर पहले कदमों को कैश करता है और आधा दिन यह जांचता रहता है कि मेरा सिस्टम सही तरीके से क्यों नहीं बन रहा है। यह "गिट क्लोन" कैशिंग था।

ALWAYS कीवर्ड रखना पसंद करेंगे।

यह कैसे बंद है?

सबसे अच्छा उपाय क्या है?

मैंने कोशिश की https://github.com/moby/moby/issues/1996#issuecomment -185872769 और यह काम कर गया
डॉकरफाइल में:

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

कमांड लाइन पर:

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

रन के समान एक नया कमांड क्यों न बनाएं लेकिन रन नो कैश के लिए कभी भी रन को कैश न करें?

मैं पुष्टि कर सकता हूं, @habeebr (https://github.com/moby/moby/issues/1996#issuecomment-295683518) - मैं इसे https://github.com/moby/moby/issues/1996# के संयोजन में उपयोग करता हूं

+1

RUNNC एक अच्छा विचार है!

यह मुद्दा क्यों बंद किया गया? असंख्य डुप्लिकेट के बीच अनिवार्य रूप से एक ही चीज़ के लिए पूछना और इनमें से एक से अधिक डुप्लिकेट के लंबे टिप्पणी इतिहास के बीच, यह स्पष्ट है कि इस कार्यक्षमता को उपलब्ध देखने में एक स्वस्थ रुचि है।

मुझे लगता है कि यह कठिन है, और शायद यह कि किसी ने पर्याप्त रूप से सुरुचिपूर्ण समाधान का सुझाव नहीं दिया है जो दोनों जरूरतों को पूरा करता है और एक आकर्षक डॉकर अतिरिक्त होने के लिए पर्याप्त साफ है ... लेकिन इसका मतलब यह नहीं है कि कोई ज़रूरत नहीं है।

इसे बंद करने के पक्ष में मैंने केवल एक और तर्क सुना है कि इसे पूरा करने के अन्य तरीके भी हैं ... कैश नियंत्रण की कमी को पूरा करने के एकमात्र उद्देश्य के लिए कई आधार चित्र बनाना बोझिल है, एक एआरजी के माध्यम से एक अमान्यता का अनुमान लगाना अस्पष्ट और अनपेक्षित है। मुझे लगता है कि उपयोगकर्ता इन "वर्कअराउंड" का उपयोग करना चाहते हैं, जितना कि डॉकर डेवलपर्स आधिकारिक तौर पर टूल में एक मैला हैक को शामिल करना चाहते हैं।

यह कठिन नहीं है: https://github.com/moby/moby/pull/10682
आसान समाधान, आसान UX। यह किया जाना चाहिए या नहीं, इस पर कोई स्पष्ट सहमति नहीं है।

वाह सिर्फ वाह...

मैंने इसके बारे में न सुनने के लिए इसे पहले ही लागू कर दिया होगा, इस बात से कोई फर्क नहीं पड़ता कि एक स्पष्ट सहमति है कि उपयोगकर्ता आधार इसे चाहता है। मैं इतने बड़े ओपन सोर्स प्रोजेक्ट के डेवलपर पक्ष में नहीं हूं, केवल बहुत छोटे हैं इसलिए शायद मुझे कुछ याद आ रहा है।

+1

समझदार सुरक्षा और बेहतर प्रदर्शन के लिए +1

+1

+1

+1

+1

+1

+1

क्या आप लोग +1 को स्पैम करना बंद कर सकते हैं? अपवोट करने के लिए सिर्फ रिएक्शन फीचर का इस्तेमाल करें।

कोई बदलाव?
अभी भी नहीं पता कि यह मुद्दा क्यों बंद है।
मेरी राय में यह एक आवश्यक विशेषता है जो रिमोट गिट रिपोजिटरी से पूरी तरह से संस्करण पुल को संभालती है।

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

इसे क्यों बंद करें? मुझे लगता है कि यह उपयोगी है

+1

+1

+1

वर्तमान में एक परत (और निम्नलिखित) के लिए कैश को अक्षम करने का सबसे आसान तरीका है:

डॉकरफाइल

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 निर्देश को डॉकरफाइल में यथासंभव नीचे रखना चाहिए (ताकि डॉकर बिल्ड कैश का अधिक से अधिक उपयोग कर सके) कैश अमान्य होने से पहले जितना संभव हो सके निर्माण प्रक्रिया)।

निर्माण प्रक्रिया में एक विशिष्ट बिंदु पर कैशे को अमान्य करने के लिए, आप पहले उल्लेखित --build-arg और ARG का उपयोग करने के बारे में किसी भी अन्य टिप्पणी का उल्लेख कर सकते हैं।

@shadycuz @curtiszimmerman हां, हम केवल CACHE OFF संरक्षित कर सकते हैं, लेकिन CACHE ON , क्योंकि यदि एक पूर्व परत को बदल दिया जाता है तो निम्नलिखित परतों को फिर से बनाने की आवश्यकता होती है।

मैं सहमत हूं कि तकनीकी दृष्टिकोण से CACHE ON कोई मतलब नहीं है। यह इरादे को और अधिक स्पष्ट रूप से व्यक्त करने में मदद करता है, हालांकि वास्तव में किन परतों को अमान्य करने का इरादा है।

एक अधिक लचीला समाधान कमांड के समान होगा RUN जिसने कुछ शेल कोड को यह निर्धारित करने की अनुमति दी कि क्या कैश को अमान्य किया जाना चाहिए। 0 के निकास कोड का अर्थ "कैश का उपयोग करें" और 1 "अमान्य कैश" हो सकता है। यदि कोई शेल कोड नहीं दिया गया है, तो यहां से कैश को अमान्य करने के लिए डिफ़ॉल्ट हो सकता है। उदाहरण के लिए कमांड को INVALIDATE कहा जा सकता है।

इसे बिना किसी टिप्पणी के बंद क्यों किया गया?

एक टिप्पणी थी, लेकिन इसे जीथब द्वारा छिपाया गया था
https://github.com/moby/moby/issues/1996#issuecomment -93592837

+1

यह सुविधा अभी मेरे लिए एक जीवन रक्षक होगी।

+1

इसे बंद करना क्योंकि हम यह नहीं देखते हैं कि कई वास्तविक दुनिया उपयोग के मामले हैं

212 टिप्पणियां और गिनती, लेकिन फिर भी कोई फायदा नहीं हुआ? काफी अज्ञानी लगता है।

+1

+1

+1

+1

+1

समस्या अभी भी यहाँ है और अभी भी एक समाधान की आवश्यकता है। वास्तविक दुनिया के बहुत सारे उपयोग अभी भी मौजूद हैं।

+1

मुझे संदेह है कि डॉकर डेवलपर्स के पास इसे लागू करने के लिए कोई प्रोत्साहन नहीं है, ताकि उनके केंद्रीकृत भवन बुनियादी ढांचे को नो-कैश अनुरोधों से डीडीएसएस किए जाने से बचाया जा सके।

मुझे यह भी संदेह है कि एक समानांतर बुनियादी ढांचा जो बिना कैश के निर्माण की सुविधा प्रदान करता है, उद्यम उपयोगकर्ताओं के लिए दिलचस्प होगा।

कुल मिलाकर यह मुद्दा एक सॉफ्टवेयर फीचर के बारे में नहीं है, बल्कि एक सर्विस स्केलिंग मुद्दा है।

@jaromil यह पूरी तरह से सच नहीं है, क्योंकि यह स्वयं-होस्ट किए गए भंडारों पर भी संभव नहीं है।

स्व-होस्ट किए गए भंडार को चलाने के लिए कौन सा सॉफ़्टवेयर है? मैं वास्तव में नहीं जानता कि आप क्या कहते हैं।
एक साधारण स्व-होस्टेड समाधान एक क्रॉन क्लोनिंग गिट रेपो और रननिग डॉकर बिल्ड --नो-कैश हो सकता है - मुझे यकीन है कि यह समस्या ओपन सोर्स सॉफ़्टवेयर पर नहीं हो सकती है: कोई भी डॉकर बिल्ड कमांडलाइन को संशोधित करने में सक्षम है।

@jaromil मुझे नहीं लगता कि यह समस्या है। DockerHub के ओपन सोर्स प्रोजेक्ट्स (साथ ही भुगतान वाले, वे बिल्ड की संख्या के लिए शुल्क नहीं लेते हैं) के लिए इसे रखना अधिक कुशल होगा। बार-बार निर्माण के साथ CI/CD वातावरण में, यह और भी खराब हो जाता है।

जब तक आपको ऐसा करने की आवश्यकता है (आप डॉकटर और गिट का उपयोग कर रहे हैं और साझा वॉल्यूम चलाने वाले 5 कंटेनर नहीं चाहते हैं), आपको कंटेनर का पुनर्निर्माण करना होगा और हर बार नया संस्करण अपलोड करने पर अपलोड करना होगा। पूरा कंटेनर।
इन-कोड नो-कैश फ्लैग के साथ, हर बार जब आप बिल्ड चलाते हैं तो आप संस्करण को अपडेट करने के लिए पूरे कंटेनर के बजाय उस सिंगल लेयर को बनाते और बदलते हैं।

स्वयं-होस्टिंग प्रतिनिधि के बारे में, आपको आश्चर्य होगा। मैं @bluzi टिप्पणी को समझता

ठीक है, यह निश्चित रूप से एक अधिक जटिल परिदृश्य है जिसकी मैं कल्पना कर रहा था। अब मुझे लगता है...एक प्रकार के nocache सिंगल लेयर हैश के साथ अपलोड करना... पुश और ओवरराइड, आप इसे नाम दें। मुझे यकीन नहीं है

TLDR: मुझे लगता है कि डॉकर प्रलेखन में कुछ सुधार बहुत मदद कर सकते हैं।

कैशिंग के साथ अपनी समस्याओं/भ्रम का सामना करने के बाद मैं यहां समाप्त हुआ। यहां और https://github.com/moby/moby/pull/10682 में सभी टिप्पणियों को पढ़ने के बाद, मुझे अपने विशेष उपयोग के मामले के लिए एक व्यावहारिक समाधान मिला। फिर भी किसी तरह मैं अभी भी इस पर डॉकर की प्रतिक्रिया से निराश महसूस कर रहा था, और ऐसा प्रतीत होता है कि कई अन्य लोग भी ऐसा ही महसूस करते हैं।

क्यों? इस बारे में कई अलग-अलग कोणों से सोचने के बाद, मुझे लगता है कि यहां समस्या अस्पष्ट उपयोग के मामलों का एक संयोजन है, प्रस्तावित परिवर्तनों के खिलाफ अत्यधिक सामान्यीकृत तर्क (जो मान्य हो सकते हैं लेकिन प्रस्तुत उपयोग मामलों को सीधे संबोधित नहीं करते हैं), और कमी की कमी कुछ सामान्य उपयोग के मामलों के लिए डॉकर की सिफारिशों के लिए प्रलेखन। शायद मैं चीजों को स्पष्ट करने और दस्तावेज़ीकरण की पहचान करने में मदद कर सकता हूं जिसे इस स्थिति में मदद करने के लिए सुधार किया जा सकता है।

लाइनों के बीच पढ़ना, मुझे ऐसा लगता है कि इस सुविधा अनुरोध पर अधिकांश शुरुआती टिप्पणीकार ऐसे समाधान से खुश होंगे जो डॉकरफाइल में एक विशिष्ट बिंदु पर कैश को अक्षम करने के लिए docker image build अतिरिक्त तर्कों का उपयोग करता है। ऐसा लगता है कि इसके लिए डॉकर का वर्तमान समाधान (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 लिए अतिरिक्त तर्क पारित करना एक समस्या है, तो शायद यह आपके उपयोग के मामले को विस्तार से बताते हुए एक टिप्पणी जोड़ने में मदद करेगा।)

इनमें से कई मामलों में, ऐसा लगता है कि उपयोग के मामले में वास्तव में डॉकरीफाइल में एक विशिष्ट बिंदु पर कैशिंग को अक्षम करने की क्षमता की आवश्यकता नहीं होती है (जो इस सुविधा अनुरोध का मूल बिंदु था)। इसके बजाय, ऐसा लगता है कि कई उपयोगकर्ता docker image build के "--no-cache" तर्क का उपयोग किए बिना और प्रत्येक से पहले Dockerfile में मैन्युअल संशोधन की आवश्यकता के बिना, Dockerfile के भीतर से कैशिंग को पूरी तरह से अक्षम करने की क्षमता से खुश होंगे। निर्माण। (उपयोग के मामलों का वर्णन करते समय, शायद यह उल्लेख करने में मदद मिलेगी कि क्या आंशिक कैशिंग वास्तव में आवश्यक है या कैश को पूरी तरह से अक्षम करना आपके उपयोग के मामले के लिए पर्याप्त होगा।)

ऐसे मामलों में जहां कोई सेवा उपयोगकर्ता की ओर से docker image build चलती है, ऐसा लगता है कि डॉकर ऐसी सभी सेवाओं की अपेक्षा कर रहा है जो या तो बिना शर्त कैश को अक्षम कर दें या उपयोगकर्ता को कैश को अक्षम करने का विकल्प दें। https://github.com/moby/moby/pull/10682#issuecomment-73777822 के अनुसार, डॉकर हब बिना शर्त कैश को निष्क्रिय कर देता है। यदि कोई सेवा पहले से ऐसा नहीं करती है, तो डॉकर ने https://github.com/moby/moby/pull/10682#issuecomment-159255451 ने सेवा प्रदाता को इसके बारे में शिकायत करने का सुझाव दिया है।

यह मुझे डॉकर के लिए docker image build चलाने वाली सेवाओं के संबंध में एक उचित स्थिति प्रतीत होती है। हालांकि, इस स्थिति को वास्तव में एक विशिष्ट स्थान पर आधिकारिक रूप से प्रलेखित करने की आवश्यकता है ताकि सेवा प्रदाता और उपयोगकर्ता दोनों जान सकें कि क्या उम्मीद की जानी चाहिए। ऐसा प्रतीत नहीं होता है कि यह स्थिति या डॉकर हब कैशिंग व्यवहार वर्तमान में उन ऑफ-द-कफ टिप्पणियों के अलावा कहीं भी प्रलेखित है जो उस विशाल/प्राचीन/बंद पुल अनुरोध के अंदर गहरे दबे हुए हैं, इसलिए यह कोई आश्चर्य की बात नहीं है कि सेवा प्रदाता और उपयोगकर्ता दोनों नियमित रूप से यह गलत हो जाओ। शायद docker build संदर्भ में जानकारी जोड़ने से बिल्ड सेवाओं द्वारा कैशिंग के उपयोग पर डॉकर की राय का वर्णन करने और डॉकर हब कैशिंग व्यवहार के बारे में डॉकर हब स्वचालित बिल्ड दस्तावेज़ीकरण में जानकारी जोड़ने से यह समस्या समाप्त हो सकती है?

उन मामलों के लिए जहां डॉकरफाइल अन्य उपयोगकर्ताओं को वितरित किए जाते हैं जो तब 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 build . चलाने की आदत को तोड़कर सभी को खुश करने में सक्षम हो सकता है। किसी भी प्रासंगिक डॉकर ट्यूटोरियल में कैशिंग व्यवहार और "--नो-कैश" तर्क का उल्लेख नहीं किया गया है (जैसे यह या यह
या यह )। इसके अलावा, जबकि docker build प्रलेखन "--no-cache" तर्क को सूचीबद्ध करता है, यह इसके महत्व की व्याख्या नहीं करता है या इस तथ्य को उजागर नहीं करता है कि यह कई सामान्य उपयोग के मामलों में महत्वपूर्ण है। (यह भी ध्यान दें कि docker image build प्रलेखन खाली है। इसे कम से कम docker build प्रलेखन का संदर्भ देना चाहिए।) ऐसा प्रतीत होता है कि केवल डॉकरफाइल संदर्भ और सर्वोत्तम अभ्यास दस्तावेज वास्तव में कैशिंग व्यवहार का वर्णन करते हैं और भूमिका का उल्लेख करते हैं। "--no-cache" तर्क का। हालाँकि, इन दस्तावेज़ों को केवल उन्नत Dockerfile लेखकों द्वारा पढ़े जाने की संभावना है। इसलिए, यह कोई आश्चर्य की बात नहीं है कि केवल उन्नत उपयोगकर्ता ही "--नो-कैश" तर्क से परिचित हैं, और अधिकांश उपयोगकर्ता केवल docker build . बिना अतिरिक्त तर्कों के ही चलेंगे और जब यह व्यवहार नहीं करता है तो भ्रमित हो जाते हैं वे या डॉकरफाइल लेखक कैसे अपेक्षा/चाहते हैं। शायद "--no-cache" तर्क का उल्लेख करने के लिए ट्यूटोरियल और docker build दस्तावेज़ को अपडेट करना और इसका महत्व इस समस्या को समाप्त कर सकता है?

+1

+1

डॉकर का आधिकारिक टूल बैशब्रू आपको छवियों का निर्माण करते समय तर्क जोड़ने नहीं देता है, इसलिए "आधिकारिक तौर पर समर्थित" उत्तर काम नहीं करता है।

+1

+1

मैं अभी जिस उपयोग के मामले को मार रहा हूं, वह निजी पैकेजों को स्थापित करने के लिए अस्थायी, अल्पकालिक रहस्यों को बिल्ड आर्ग्स के रूप में पारित करना चाहता है। यह पूरी तरह से कैशिंग को तोड़ देता है क्योंकि इसका मतलब है कि हर बार गुप्त परिवर्तन (मूल रूप से हर निर्माण), कैश का भंडाफोड़ हो जाता है और पैकेज फिर से स्थापित हो जाते हैं, भले ही एकमात्र परिवर्तन रहस्य है।

मैंने एआरजी को एक स्क्रिप्ट में उपभोग करके इसे बाईपास करने का प्रयास किया है जो एआरजी निर्दिष्ट करने से पहले कॉपी हो जाता है, लेकिन एआरजी इनपुट बदल जाने पर एआरजी घोषित होने के बाद डॉकर सबकुछ अमान्य कर देता है।

मैं जो व्यवहार देखना चाहता हूं वह है कि एआरजी को हमेशा कैशिंग के रूप में ध्वजांकित करने में सक्षम होना चाहिए, या तो डॉकरफाइल में या सीएलआई पर बिल्ड को कॉल करते समय। रहस्यों जैसे उपयोग के मामलों के लिए, आप अक्सर यही चाहते हैं; कैश के अमान्य होने पर पैकेज सूची की सामग्री को निर्देशित करना चाहिए, न कि ARG को दिया गया तर्क।

मैं इस सिद्धांत को समझता हूं कि इन अनुभागों को दूसरी छवि में खींचा जा सकता है जिसे तब आधार छवि के रूप में उपयोग किया जाता है, लेकिन यह तब अजीब होता है जब किसी प्रोजेक्ट द्वारा पैकेज का उपयोग किया जाता है, जैसे package.json, require.txt, Gemfile, आदि। . उस आधार छवि को भी लगातार लगातार बनाया जाएगा।

इस लाइन निर्देश से +1 से CACHE OFF - मैं सचमुच वर्षों से इसका इंतजार कर रहा हूं।

मुझे डॉकर हब/डॉकर क्लाउड पर कैश को अक्षम करना पड़ा है और इससे बहुत समय बच जाएगा और अगर मैं बड़ी परत को कैश कर सकता हूं और फिर डॉकरफाइल के अंत में एक नोचेचे अपडेट कमांड चला सकता हूं।

मैं जो व्यवहार देखना चाहता हूं वह है कि एआरजी को हमेशा कैशिंग के रूप में ध्वजांकित करने में सक्षम होना चाहिए, या तो डॉकरफाइल में या सीएलआई पर बिल्ड को कॉल करते समय। रहस्यों जैसे उपयोग के मामलों के लिए, आप अक्सर यही चाहते हैं; कैश के अमान्य होने पर पैकेज सूची की सामग्री को निर्देशित करना चाहिए, न कि ARG को दिया गया तर्क।

--build-arg PASSWORD=<wrong> --build-arg PASSWORD=<correct> तुलना में एक अलग परिणाम उत्पन्न कर सकता है, इसलिए मुझे यकीन नहीं है कि पैकेज सूची की सामग्री को देखकर उसके लिए काम करेगा। बिल्डर स्वयं यह अनुमान नहीं लगा सकता है कि चलाए जा रहे चरणों पर पर्यावरण चर की सेटिंग/परिवर्तन का क्या प्रभाव पड़ेगा ( make DEBUG=1 foo और make DEBUG=0 foo समान हैं?) वर्तमान में बनाया गया एकमात्र अपवाद xx_PROXY पर्यावरण चर के लिए है, जहां यह धारणा बनाई जाती है कि नेटवर्क-कनेक्शन के लिए एक प्रॉक्सी की आवश्यकता हो सकती है, लेकिन एक अलग प्रॉक्सी पर स्विच करने से एक ही परिणाम उत्पन्न होना चाहिए। तो इसके लिए काम करने के लिए, कैशिंग के लिए अनदेखा करने के लिए एक विशिष्ट पर्यावरण चर (/ निर्माण तर्क) को इंगित करने के किसी भी तरीके की आवश्यकता होगी।

ध्यान दें कि BuildKit के पास अब RUN --mount=type=secret और RUN --mount=type=ssh लिए प्रयोगात्मक समर्थन है, जो रहस्यों/प्रमाण-पत्रों को पारित करने के लिए सहायक हो सकता है, लेकिन अगर वे रहस्य बदलते हैं तो भी कैश को अमान्य कर सकता है (निश्चित नहीं; यह कुछ ऐसा हो सकता है बिल्डकिट इश्यू ट्रैकर में लाएं https://github.com/moby/buildkit/issues)।

मुझे डॉकर हब/डॉकर क्लाउड पर कैश अक्षम करना पड़ा है

क्या डॉकर हब/क्लाउड वास्तव में _use_ कैशिंग करता है? मुझे लगता है कि वहां कोई कैशिंग का उपयोग नहीं किया जाता है (जैसा कि; यह क्षणिक निर्माण वातावरण का उपयोग कर रहा है)

मुझे याद है कि डॉकरहब बिल्ड कैशिंग का उपयोग नहीं करता था, लेकिन मैं इस टिकट से ठीक पहले डॉकर क्लाउड पर अपने स्वचालित बिल्ड को देख रहा था और अब प्रत्येक शाखा के ऑटोबिल्ड स्लाइडर के बगल में बिल्डिंग कैशिंग स्लाइडर है, हालांकि यह डिफ़ॉल्ट रूप से बंद है।

मैं बिल्ड कैशिंग को सक्षम करने की हिम्मत नहीं करता क्योंकि git clone जैसे चरणों को नवीनतम रेपो डाउनलोड नहीं मिलेगा क्योंकि यह केवल निर्देश स्ट्रिंग की तुलना करता है जो नहीं बदलेगा। इस मुद्दे को आज एक सहकर्मी को समझाते हुए, जो वर्षों से हमारे पक्ष में कांटा रहा है, वह हैरान था क्योंकि यह कई उपयोग के मामलों के लिए एक बड़ी अपूर्णता की तरह लगता है।

मैं बहुत पसंद करूंगा कि प्रारंभिक git clone && make build को कैश किया जाए और फिर केवल एक बहुत छोटा कोड अपडेट प्राप्त करने के लिए NO CACHE एक git pull && make build चरण पर करें + निर्भरता पहले से ही अंतिम के रूप में स्थापित नहीं है परत, जिससे न केवल बिल्ड के लिए, बल्कि उन सभी क्लाइंट्स के लिए अधिक महत्वपूर्ण रूप से छवि के बड़े हिस्से को कुशलता से कैशिंग कर रहा है, जिन्हें अभी हर बार सैकड़ों एमबी परतों को फिर से डाउनलोड और बदलना होगा जो बेहद अक्षम है।

आकार इसलिए है क्योंकि कई परियोजनाओं में बड़ी संख्या में निर्भरताएँ होती हैं, उदा। सिस्टम पैकेज + पर्ल सीपीएएन मॉड्यूल + पायथन पीईपीआई मॉड्यूल इत्यादि।

एक बार जब आप सिस्टम पैकेज निर्भरता और सीपीएएन और पीईपीआई निर्भरता जोड़ते हैं तो अल्पाइन का उपयोग करना बहुत छोटा नहीं होता है क्योंकि मैं वर्षों से अल्पाइन का उपयोग यह देखने के लिए कर रहा हूं कि क्या मैं छोटी छवियां बना सकता हूं लेकिन एक बार जब आपके पास बहुत सारी निर्भरताएं होती हैं तो यह नहीं होता है यदि आधार छोटा होना शुरू होता है तो बहुत फर्क पड़ता है क्योंकि सिस्टम पैकेज जोड़ने से इसका अधिकांश भाग ठीक पीछे जुड़ जाता है।

पिछली परतों को कैशिंग करना जिसमें सभी सिस्टम पैकेज + CPAN + PyPI मॉड्यूल शामिल हैं, का मतलब होगा कि अपडेट की अंतिम परत में बहुत कम बदलाव होना चाहिए क्योंकि मैं ज्यादातर मामलों में काम कर रहे मॉड्यूल को अपडेट नहीं करूंगा (मैंने अपने बैश-टूल्स से स्क्रिप्ट का उपयोग किया था) उपयोगिता सबमॉड्यूल रेपो केवल उन पैकेजों को स्थापित करने के लिए जो पहले से स्थापित नहीं हैं ताकि अनावश्यक गैर-बगफिक्स अपडेट स्थापित करने से बचा जा सके)

मैं थोड़ी देर के लिए एआरजी बदलने जैसी चाल का उपयोग कर रहा था (एक विचार जो मुझे http://dev.im-bot.com/docker-select-caching/ जैसे ब्लॉगों के माध्यम से खोजने से मिला):

डॉकरफाइल में:

ARG NOCACHE=0

फिर डॉकर बिल्ड को इस तरह चलाएं:

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

लेकिन मुझे नहीं लगता कि डॉकर क्लाउड में यह संभव है।

पर्यावरण चर हैं लेकिन ऐसा लगता है कि गतिशील सामग्री का उपयोग करना संभव नहीं है जैसे कि उपरोक्त युग (या कम से कम दस्तावेज नहीं है जो मुझे मिल सकता है), और पर्यावरण चर के साथ मुझे यकीन नहीं है कि यह उस निर्देश रेखा के लिए कैशिंग को अमान्य कर देगा।

@thaJeztah हां, इस तरह के व्यवहार के आसानी से नकारात्मक परिणाम हो सकते हैं यदि गलत समझा जाता है या दुर्व्यवहार किया जाता है, लेकिन यह कुछ उपयोग के मामलों को बहुत अच्छी तरह से हल करेगा।

--build-arg PASSWORD=<wrong> --build-arg PASSWORD=<correct> तुलना में एक अलग परिणाम उत्पन्न कर सकता है, इसलिए मुझे यकीन नहीं है कि पैकेज सूची की सामग्री को देखने से उसके लिए काम होगा

यद्यपि आप सही हैं कि यह अलग-अलग परिणाम देगा, यदि पैकेज सूची नहीं बदली है, तो मुझे वास्तव में परवाह नहीं है कि पासवर्ड सही है या गलत; पैकेज पहले से ही पूर्व छवि में हैं, इसलिए इसे चलाने वाले उपयोगकर्ता के पास पहले से ही पहुंच है (यानी, यह सुरक्षा चिंता का विषय नहीं है), और यदि पासवर्ड पहले गलत था, तो मुझे उम्मीद है कि स्थापना को विफल करने के लिए डॉकरफाइल लेखक पर बोझ होगा। यदि यह आवश्यक है, तो इसका मतलब यह होगा कि आपको पासवर्ड ठीक करने के बाद भी पैकेजों को सही ढंग से स्थापित करने का मौका मिलेगा।

हां, मैं 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 ने दिखाया कि ऐसी फाइलें मौजूद थीं, वे हमेशा नहीं मिलीं, मुझे संदेह है कि विशेष फाइलों का उपयोग करने के खिलाफ कुछ सुरक्षा है।

अब मैं इसके बारे में डॉकरहब/डॉकर क्लाउड पर अधिक सोचता हूं, आप शायद डेटास्टैम्प वाली फ़ाइल जेनरेट करने के लिए प्री बिल्ड हुक का भी उपयोग कर सकते हैं और फिर उस परत से पहले छवि को कॉपी करें जिसे आप कैशबस्ट करना चाहते हैं, समान परिणाम प्राप्त करना, हालांकि एडीडी ऊपर दिखाया गया है कि मुझे लगता है कि स्थानीय डॉकटर और क्लाउड बिल्ड के लिए अधिक पोर्टेबल है।

हमें इस कैशे बस्टिंग वर्कअराउंड के लिए एक अधिक विश्वसनीय दिनांक मुद्रण साइट खोजने की आवश्यकता है - ये दोनों ऊपर दिए गए डेमो/कोटा हैं और इसलिए अविश्वसनीय और बेतरतीब ढंग से ब्रेक बिल्ड हैं।

पहला अपना दैनिक कोटा हर समय तोड़ता है और दूसरा अब यह त्रुटि दे रहा है

{"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 निर्देश में कमांड निर्दिष्ट रेपो के HEAD से SHA को आउटपुट करेगा, इस तरह मेरा 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 संशोधित करता हूं तो डॉकर अभी भी कैश्ड पुराने संस्करण का उपयोग करेगा।

यदि डॉकर को कॉपी की गई फ़ाइलों का चेकसम करना था और अगली बार यह निर्धारित करने के लिए उपयोग किया गया था कि क्या उसे कैश्ड परत का उपयोग करना चाहिए जो समस्या का समाधान करेगा।

अभी के रूप में मुझे --no-cache का उपयोग करने के लिए मजबूर किया गया है और यह आवश्यकता से अधिक डाउनलोड और प्रदर्शन करता है (समय और बैंडविड्थ बर्बाद कर रहा है)।

@brennancheung अगर ऐसा है, तो यह एक बग है। प्रतिलिपि प्रस्तुत करने योग्य चरणों के साथ एक अलग मुद्दा खोलने के लिए स्वतंत्र महसूस करें।

मुझे लगता है कि मुख्य बिंदु क्या है @ ब्रेननचेउंग
https://github.com/brennancheung कह रहा है, उदाहरण के लिए, जब आप
कॉन्फ़िगरेशन फ़ाइल लोड करना (या कुछ समान)। आपको इसकी आवश्यकता नहीं है
संपूर्ण एप्लिकेशन को पुनर्स्थापित करें, बस इन फ़ाइलों और आदेशों को अपडेट करें
इसके साथ जुड़े, डॉकर और वॉयला चलाएं, सिस्टम सेट हो गया है।
बेशक, कई बार आप कॉन्फ़िगरेशन फ़ाइल को अंत के करीब रख सकते हैं
आपका ढेर, लेकिन हमेशा ऐसा नहीं होता है।

एम एम आई।, 20। मर्ज़ 2019 उम 00:10 उहर श्राइब टिबोर वास <
सूचनाएं@github.com>:

@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

यदि डॉकरफाइल एक एआरजी चर को परिभाषित करता है जिसका मूल्य पिछले निर्माण से अलग है, तो इसके पहले उपयोग पर "कैश मिस" होता है, इसकी परिभाषा नहीं।

@samstav "पहला उपयोग" 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"

यदि आप अगली पीढ़ी के बिल्डर (बिल्डकिट) का उपयोग कर रहे हैं तो उपरोक्त कुछ हद तक निर्भर करता है, इसलिए DOCKER_BUILDKIT=1 सक्षम होने के साथ, क्योंकि बिल्डकिट अंतिम चरण के लिए आवश्यक नहीं होने पर बिल्डिंग चरणों को छोड़ सकता है (या बिल्डिंग चरणों को छोड़ सकता है) अगर उन्हें पूरी तरह से कैश किया जा सकता है)