Moby: बाहर रखी गई फाइलों के साथ कॉपी करना संभव नहीं है

देखें https://docs.docker.com/reference/builder/#dockerignore -file
आप प्रोजेक्ट की जड़ में .dockerignore फ़ाइल में प्रविष्टियाँ जोड़ सकते हैं।

.dockerignore इस समस्या का समाधान नहीं करता है। जैसा कि मैंने लिखा, "दूसरा भाग एक और कॉपी के अधीन है"।

तो आप किसी अन्य प्रति के आधार पर सशर्त प्रतिलिपि बनाना चाहते हैं?

संदर्भ में बहुत सी निर्देशिकाएँ A1...A10 और एक निर्देशिका B. A1...A10 का एक गंतव्य है, B का दूसरा गंतव्य है:

COPY A1 /some/where/A1/
COPY A2 /some/where/A2/
...
COPY A10 /some/where/A10/
COPY B some/where/else/B/

और यह अटपटा है।

इसका कौन सा हिस्सा अजीब है? उन सभी को व्यक्तिगत रूप से सूचीबद्ध करना?

COPY A* /some/where/
COPY B /some/where/else/

क्या यह काम करता हैं?

A1..A10, B नाम नकली थे। इसके अलावा, COPY A* ... निर्देशिकाओं के _contents_ को एक साथ फेंकता है।

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

(BTW, #6094 (निम्नलिखित सिम्लिंक) इस मामले में मदद करेगा। लेकिन जाहिर है, यह कोई विकल्प भी नहीं है।)

@bronger अगर COPY बिल्कुल cp जैसा व्यवहार करता है, तो क्या यह आपके उपयोग-मामले को हल करेगा?

मुझे यकीन नहीं है कि मैं 100% समझता हूं।
हो सकता है कि @duglin एक नज़र डाल सके।

@bronger मुझे लगता है कि @ cpuguy83 ने सही प्रश्न पूछा है, यदि आप 'cp' का उपयोग कर रहे हैं तो आप इसे कैसे हल करेंगे? मैंने देखा और 'सीपी' पर किसी प्रकार के बहिष्करण विकल्प पर ध्यान नहीं दिया, इसलिए मुझे यकीन नहीं है कि आप इसे 'डॉकर बिल्ड' के बाहर कैसे हल करेंगे।

सीपी व्यवहार के साथ, मैं यह कहकर स्थिति को सुधार सकता था

COPY ["A1", ... "A10", "/some/where/"]

यह अभी भी एक मामूली रखरखाव समस्या है क्योंकि अगर मैं "ए 11" निर्देशिका जोड़ता हूं तो मुझे उस पंक्ति के बारे में सोचना होगा। लेकिन यह स्वीकार्य होगा।

इसके अलावा, सीपी को बहिष्करण की आवश्यकता नहीं है, क्योंकि हर चीज की नकल करने और अवांछित भागों को हटाने से नकल से परे लगभग कोई प्रदर्शन प्रभाव नहीं पड़ता है। डॉकर की कॉपी के साथ, इसका मतलब है कि हर बार बी बदलने पर गलत तरीके से अमान्य कैश, और बड़ी छवियां।

@bronger आप कर सकते हैं:

COPY a b c d /some/where

जैसे आप सुझाव दे रहे थे।

RUN rm ... के बाद COPY ... करने के लिए, हाँ आपके पास अतिरिक्त परत होगी, लेकिन आप अभी भी कैश का उपयोग करने में सक्षम होना चाहिए। यदि आप इसके कारण कैश मिस देखते हैं तो मुझे बताएं, मुझे नहीं लगता कि आपको ऐसा करना चाहिए।

लेकिन

COPY a b c d /some/where/

निर्देशिकाओं /some/where/{a,b,c,d} को बनाने के बजाय निर्देशिका एबीसीडी की सामग्री को एक साथ कॉपी करता है। यह src निर्देशिका में संलग्न एक स्लैश के साथ rsync की तरह काम करता है। इसलिए, _चार_ निर्देश

COPY a /some/where/a/
COPY b /some/where/b/
COPY c /some/where/c/
COPY d /some/where/d/

की आवश्यकता है।

कैश के लिए ... अगर मैं कहूं

COPY . /some/where/
RUN rm -Rf /some/where/e

तो कैश का उपयोग नहीं किया जाता है यदि ई बदल जाता है, हालांकि ई प्रभावी रूप से ऑपरेशन में शामिल नहीं है।

@bronger हाँ, दुख की बात है कि आप सही हैं। मुझे लगता है कि हम एक --exclude zzz प्रकार का ध्वज जोड़ सकते हैं, लेकिन प्रति https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax इसे बहुत अधिक नहीं मिल सकता है अभी कर्षण।

काफी उचित। तब मैं कुछ समय के लिए एक कॉपी + आरएम का उपयोग करूंगा और एक फिक्समी टिप्पणी जोड़ूंगा। अपना समय देने के लिए धन्यवाद!

बस करने के लिए: +1: यह मुद्दा। मुझे नियमित रूप से खेद है कि COPY rsync के अनुगामी स्लैश शब्दार्थ को प्रतिबिंबित नहीं करता है। इसका मतलब है कि आप एक ही कथन में एकाधिक निर्देशिकाओं की प्रतिलिपि नहीं बना सकते हैं, जिससे परत प्रसार हो सकता है।

मैं नियमित रूप से एक मामले का सामना करता हूं जहां मैं एक को छोड़कर कई निर्देशिकाओं की प्रतिलिपि बनाना चाहता हूं (जिसे बाद में कॉपी किया जाएगा, क्योंकि मैं चाहता हूं कि इसमें अलग-अलग परत-अमान्य प्रभाव हों), इसलिए --exclude भी उपयोगी होगा।

साथ ही, man rsync से:

       A trailing slash on the source changes this behavior to avoid  creating
       an  additional  directory level at the destination.  You can think of a
       trailing / on a source as meaning "copy the contents of this directory"
       as  opposed  to  "copy  the  directory  by name", but in both cases the
       attributes of the containing directory are transferred to the  contain‐
       ing  directory on the destination.  In other words, each of the follow‐
       ing commands copies the files in the same way, including their  setting
       of the attributes of /dest/foo:

              rsync -av /src/foo /dest
              rsync -av /src/foo/ /dest/foo

मुझे लगता है कि बहुत सारे जंगली Dockerfile s को तोड़े बिना इसे अब बदला नहीं जा सकता।

एक ठोस उदाहरण के रूप में, मान लें कि मेरे पास इस तरह दिखने वाली एक निर्देशिका है:

/vendor
/part1
/part2
/part3
/...
/partN

मुझे ऐसा कुछ चाहिए जो दिखता है:

COPY /vendor /docker/vendor
RUN /vendor/build
COPY /part1 /part2 ... /partN /docker/ # copy directories part1-N to /docker/part{1..N}/
RUN /docker/build1-N.sh

ताकि part1-N /vendor की इमारत को अमान्य न करे। (चूंकि /विक्रेता part1-N की तुलना में शायद ही कभी अपडेट किया जाता है)।

मैंने पहले अपनी निर्देशिका में part1-N डालकर इस पर काम किया है, इसलिए:

/vendor
/src/part1-N

लेकिन मुझे परियोजनाओं में भी इस समस्या का सामना करना पड़ा है कि मैं इतनी आसानी से पुनर्व्यवस्थित करने के लिए स्वतंत्र नहीं हूं।

@praller अच्छा उदाहरण, हम ठीक उसी मुद्दे का सामना कर रहे हैं। मुख्य समस्या यह है कि Go's filepath.Match नियमित अभिव्यक्तियों की तुलना में अधिक रचनात्मकता की अनुमति नहीं देता है (अर्थात कोई विरोधी पैटर्न नहीं)

मैं इसके लिए कुछ हद तक क्रैक-ब्रेन वर्कअराउंड लेकर आया हूं। कॉपी निर्देशिकाओं को बाहर नहीं कर सकता, लेकिन _can_ जोड़ें tgz का विस्तार करें।

यह एक अतिरिक्त निर्माण चरण है:
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz ।
डोकर निर्माण ...

फिर अपने डॉकरफाइल में:
जोड़ें ./all_but_deferred.tgz /application_dir/
.. शायद ही कभी बदलती परतों में सामान ..
जोड़ें । /application_dir/
.. अक्सर बदलती परतों में सामान

यह टार का पूरा सिंटैक्स देता है जिसमें शामिल/बहिष्कृत/जो कुछ भी शामिल/बहिष्कृत करने की कोशिश कर रहे बर्बाद परतों के गोब्स के बिना शामिल है।

@ जेसन-केन यह अच्छी चाल है, साझा करने के लिए धन्यवाद। एक छोटी सी बात: ऐसा लगता है कि आप z (gzip) ध्वज को tar में नहीं जोड़ सकते - यह sha256 चेकसम मान को बदल देता है, जो डॉकर कैश को अमान्य कर देता है। अन्यथा यह दृष्टिकोण मेरे लिए बहुत अच्छा काम करता है।

इस मुद्दे के लिए +1, मुझे लगता है कि इसे उसी तरह समर्थित किया जा सकता है जिस तरह से बहुत सारे ग्लोब पुस्तकालय इसका समर्थन करते हैं:

node_modules को छोड़कर सब कुछ कॉपी करने का प्रस्ताव यहां दिया गया है

COPY . /app -node_modules/

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

मैं

मुझे एक ही समस्या है हालांकि docker cp के साथ, मैं एक को छोड़कर सभी फाइलों को एक फ़ोल्डर से कॉपी करना चाहता हूं

ठीक वही मुद्दा यहाँ। मैं एक गिट रेपो की प्रतिलिपि बनाना चाहता हूं और .git निर्देशिका को बाहर करना चाहता हूं।

@oaxlin आप उसके लिए .dockerignore फ़ाइल का उपयोग कर सकते हैं।

@antoineco क्या आप सुनिश्चित हैं कि यह काम करेगा? मैंने कोशिश किए कुछ समय हो गया है लेकिन मुझे पूरा यकीन है कि .dockerignore कम से कम उस समय docker cp के साथ काम नहीं करता था

@ kkozmic-seek बिल्कुल सुनिश्चित :) लेकिन आपके द्वारा उल्लिखित docker cp CLI उपकमांड Dockerfile में पाए गए COPY स्टेटमेंट से अलग है, जो कि इस मुद्दे का दायरा है।

docker cp का वास्तव में Dockerfile और . dockerignore, लेकिन दूसरी ओर इसका उपयोग छवियों के निर्माण के लिए नहीं किया जाता है।

वास्तव में इसे भी पसंद करेंगे - निर्माण को गति देने के लिए मैं कुछ फ़ोल्डर को बिल्ड के पुराने हिस्सों में कॉपी कर सकता हूं और फिर कैश मेरी मदद करेगा ...

मुझे यकीन नहीं है कि मैं समझता हूं कि उपयोग का मामला क्या है, लेकिन COPY समस्या को हल करने से पहले केवल फाइलों को बाहर करने के लिए स्पर्श नहीं करेगा?

RUN touch /app/node_modules
COPY . /app
RUN rm /app/node_modules

AFAIK COPY फ़ाइल को अधिलेखित नहीं करता है, इसलिए मुझे लगता है कि यह काम कर सकता है।

ओह, कोई बात नहीं, ऐसा लगता है कि COPY वास्तव में फाइलों को अधिलेखित कर देता है। अब मैं https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ से थोड़ा हैरान हूं, जो npm इंस्टॉल करता है और फिर COPY . /usr/src/app करता है। मुझे लगता है कि यह मानता है कि node_modules डोकर पर ध्यान नहीं दिया गया है? दूसरी ओर, COPY_NO_OVERWRITE (बेहतर नाम की आवश्यकता) कमांड कॉपी के दौरान फाइलों को अनदेखा करने का एक तरीका हो सकता है (आपको उन चीजों के लिए खाली फाइलें/डीआईआर बनाना होगा जिन्हें आप अनदेखा करना चाहते हैं)।

एफडब्ल्यूआईडब्ल्यू, मुझे यह बहुत बदसूरत लगता है।

मुझे एक और हैक समाधान मिला:

उदाहरण परियोजना संरचना:
अनुप्रयोग/
विन्यास/
स्क्रिप्ट/
कल्पना/
स्थिर/
...

हम चाहते हैं:

1. स्थिर कॉपी करें/
2. अन्य फाइलों को कॉपी करें
3. ऐप कॉपी करें/

हैक समाधान:
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

दूसरा ADD इसके बराबर है: "./st " और "./a" को छोड़कर सभी को कॉपी करें।
सुधार के लिए कोई विचार?

टिप्पणी की स्थिति कौन सी है?

मैं

मैं

मैं

मैं

.gitignore की तुलना में एक ही तरीके से .dockerignore फ़ाइल रखने के बारे में क्या?

@mirestrepo इस मुद्दे पर पहले दो अनुवर्ती देखें।

वर्तमान में यह सी #/डॉटनेट विकास के लिए एक मेगा परफ nerf है।

जो मैं चाहता हूं:

• सबसे पहले सभी बाहरी dll को docker इमेज में कॉपी करें (My*.dll को छोड़कर सब कुछ)
• फिर मेरे सभी dll (My.*.dll से शुरू) की प्रतिलिपि बनाएँ।

अब ऐसा लगता है कि यह (आसानी से) संभव नहीं है क्योंकि मैं इसके अलावा सब कुछ कॉपी नहीं कर सकता।

तो या तो dll को डबल कॉपी किया जाता है जो docker file size को बढ़ाता है या सब कुछ एक लेयर में कॉपी किया जाता है।
बाद में एक मेगा nerf होने के कारण बाहरी dll को कैश किए जाने के बजाय हर बार कॉपी किया जाता है।

@adresdvila solutoin के लिए धन्यवाद मैं इसे इसमें विभाजित करने में सक्षम था:

COPY ["[^M][^y]*","/app/"] 
COPY ./My* /app/

हालाँकि यह अभी भी समस्या को छोड़ देता है कि .json फ़ाइलों को पहले कमांड पर कॉपी किया जाता है

@antoineco को धन्यवाद कहने के लिए बस चिल्लाना मेरी समस्या हल हो गई है। मैं अब अपनी डॉकटर छवियों में .git निर्देशिका की प्रतिलिपि नहीं बनाता।

इसने छवि आकार में नाटकीय रूप से सुधार किया, और मेरी छवि को डॉकर कैशिंग सिस्टम के लिए और अधिक अनुकूल बना दिया।

मेरी भी यही समस्या है। मेरे पास एक बड़ी फाइल है जिसे मैं बाकी फाइलों से पहले कॉपी करना चाहता हूं ताकि संदर्भ में कोई भी बदलाव इसे दोहराए नहीं क्योंकि कॉपी करने में बहुत समय लगता है (7 जीबी बिन फाइल)। क्या कोई नया उपाय है?

COPY और प्रून दृष्टिकोण के साथ समस्या यह है कि प्रूनिंग से पहले की परत में अभी भी सभी डेटा मौजूद हैं।

COPY . --exclude=a --exclude=b बेहद उपयोगी होगा। आप क्या सोचते हैं, @cpuguy83?

@ नोवाकर मुझे यह पसंद है। वैसे भी tar और rsync के अनुरूप लगता है।
मुझे लगता है कि इसे डॉकरीग्नोर के समान प्रारूप का समर्थन करना चाहिए?

@tonistiigi @dnephin

मेरे विचार से इस मामले को #32507 द्वारा नियंत्रित किया जाएगा।

@ cpuguy83 हाँ। विशेष रूप से, COPY --chown=uid:gid . के अनुरूप

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

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 डेटा की प्रतिलिपि बनाने के आसपास केंद्रित है जिसे छवि में समाप्त होना है, लेकिन केवल एक ही नहीं, बल्कि कई COPY कथनों में बिखरा हुआ है। लक्ष्य स्पष्ट COPY first second third .... eleventh destination/ से बचना है जब प्रोजेक्ट में रूट में बहुत सारी निर्देशिकाएं हों और यह परिवर्तन/वृद्धि के अधीन हो।

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

विचार यह है कि RUN --mount बहुत सारी समस्याओं को हल करने में सक्षम है। COPY --exclude केवल एक ही समस्या का समाधान करता है।

मैं व्यक्तिगत समस्याओं को हल करने के लिए सिंटैक्स का एक गुच्छा जोड़ने के बजाय कुछ ऐसा जोड़ना चाहता हूं जो बहुत सारी समस्याएं हल करता है। आप RUN --mount... rsync --exclude ... (या कुछ स्क्रिप्ट जो अलग-अलग चीजों की प्रतिलिपि बनाते हैं) का उपयोग करेंगे और यह COPY --exclude के बराबर होगा।

@dnephin ओह, मैंने RUN --mount rsync के बारे में नहीं सोचा था! उत्कृष्ट! मैं

यह वाकई बेहतरीन है। हालाँकि आप कैशिंग का कुशलतापूर्वक लाभ उठाने में सक्षम नहीं होंगे @Nowaker , क्योंकि कैश को अमान्य कर दिया जाएगा यदि माउंटेड डायरेक्टरी में कुछ भी बदलता है, न कि केवल वही जो आप rsync करना चाहते हैं।

यदि आप उस rsync के आउटपुट को किसी अन्य चीज़ के लिए इनपुट के रूप में उपयोग करते हैं और वास्तव में कोई फ़ाइल नहीं बदली है तो कैश फिर से उठाएगा। यदि आप वास्तव में इसके लिए तैयार हैं तो आप इसे वर्तमान में https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140 जैसी किसी चीज़ के साथ कर सकते हैं। केवल RUN --mount (या बिल्डकिट में एलएलबी) में परिवर्तन यह है कि आपको वास्तव में चरणों के बीच फ़ाइलों की प्रतिलिपि बनाने की ज़रूरत नहीं है, लेकिन उन्हें सीधे एक्सेस कर सकते हैं, इसलिए यह बहुत तेज़ है।

कैसे उपयोग करने के बारे में https://docs.docker.com/develop/develop-images/multistage-build/?

FROM php:7.2-apache as source
COPY ./src/ /var/www/html/
RUN rm -rf /var/www/html/vendor/
RUN rm -rf /var/www/html/tests/

FROM php:7.2-apache
COPY --from=source /var/www/html/ /var/www/html/

@antoineco Welp, तो यह अब और उत्कृष्ट नहीं है। इंगित करने के लिए धन्यवाद ..

@MartijnHols यह एक अच्छा समाधान है। पोस्ट करने का शुक्रिया।

अनुरक्षकों के लिए: उस ने कहा, हम कह सकते हैं "क्यों लागू करें --COPY में, आप बहु-स्तरीय निर्माण में RUN chown का उपयोग कर सकते हैं"। हमें विवेक के लिए --exclude की आवश्यकता है। Dockerfiles में इन दिनों बहुत सारे समाधान हैं।

मेरे पास एक उपयोग का मामला है जो COPY --exclude से लाभान्वित होगा। मेरे पास एक बड़ा डेटा फ़ोल्डर है जिसे पूरी तरह से कंटेनर में कॉपी करने की आवश्यकता है। उस निर्देशिका की सामग्री बार-बार परिवर्तन के अधीन है। कैश प्रदर्शन को बेहतर बनाने के लिए, निर्देशिका में एक बड़ी फ़ाइल है जिसे मैं बाकी की प्रतिलिपि बनाने से पहले अपनी परत में कॉपी करना चाहता हूं। अभी तक, इस प्रकार के कंटेनर का वर्णन करना अनावश्यक रूप से क्रियात्मक है।

आवश्यकताओं के आसपास केंद्रित स्तरित कैशिंग का उपयोग करने का सही तरीका क्या है। txt

मेरे पास यह है:

/root-app
 - /Dockerfile
 - /requirements.txt
 - /LICENSE
 - /helloworld.py
 - /app-1
     -/app-1/script1
     -/app-1/script2
     -/app-1/script3
 - /app-2
     -/app-2/script1

और डॉकरफाइल:

FROM python:slim
COPY ./requirements.txt /
RUN pip install --trusted-host pypi.python.org -r /requirements.txt
WORKDIR /root-app
COPY . /helloworld
CMD ["python", "helloworld.py"]

कैश बनाने की आवश्यकताओं को बाहर करने के लिए दूसरे COPY कमांड का उपयोग करने का सही तरीका क्या है ... और इसी तरह मेरे ऐप -1 और ऐप -2 को परत करें यदि वे बहुत अधिक नहीं बदलते हैं?

@axehayz सुनिश्चित नहीं है कि आप यही पूछ रहे हैं, लेकिन मैं https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8 में नोड वर्कफ़्लो के समान कुछ करूँगा।

यानी आपकी दूसरी प्रति के लिए बस COPY . होना ठीक है; जब तक आपका pip install पहले आता है, यह संस्थापित पैकेजों के लिए संचित कैश को अमान्य नहीं करेगा।

एक ही समस्या का सामना करना पड़ा। फिलहाल मैं विभिन्न निर्देशिकाओं में फाइलों का विस्तार करना पसंद करूंगा।

मेरे पास COPY --exclude=... --exclude=... के लिए एक और मामला है

मैं अपनी छवि का आकार कम करने के लिए एक कॉपी --from=oldimage करने की कोशिश कर रहा हूं और मुझे अधिकांश फाइलों की प्रतिलिपि बनाने की जरूरत है, लेकिन उनमें से कुछ के बिना। मैं इसे निर्देशिका द्वारा निर्देशिका कर सकता हूं, जो दर्दनाक है, लेकिन काम करता है ... लेकिन या तो डीआईआर/फाइलों की एक सूची को शामिल करने में सक्षम होना या एकाधिक - बहिष्कृत विकल्प प्रदान करना इतना बेहतर और बनाए रखने में आसान होगा।

तो साढ़े तीन साल के बाद भी कोई पावती नहीं है?

@asimonf उपयोग के मामले को समझने के लिए बहुत सारी पावती और आगे और पीछे है। मुझे लगता है कि आपका मतलब यह काम किसी ने नहीं किया है? वह सही है। हम सभी को उन चीजों पर चुनाव करना है जिन पर हम काम करते हैं।

ईमानदारी से, यह मौजूदा कार्यक्षमता का उपयोग करके बहुत आसानी से किया जा सकता है, भले ही इसका मतलब है कि इसे करने के लिए आपको अपने डॉकरफाइल में थोड़ा अतिरिक्त लिखना होगा।

# haven't tested exact syntax, but this is the general idea
FROM myRsync AS files
COPY . /foo
RUN mkdir /result && rsync -r --exclude=<pattern> /foo/ /result/

FROM scratch
COPY --from=files /result/* /

बिल्डकिट के साथ आपको एक अतिरिक्त चरण की भी आवश्यकता नहीं है

#syntax=docker/dockerfile:experimental
..
RUN --mount=target=/ctx rsync ... /ctx/ /src/

जब तक मैं मल्टी स्टेज बिल्ड का उपयोग करके कुछ याद नहीं कर रहा हूं, यहां समाधान की तरह प्रतीत नहीं होता है। COPY चरण में कैश अभी भी अमान्य है।

जब तक मैं मल्टी स्टेज बिल्ड का उपयोग करके कुछ याद नहीं कर रहा हूं, यहां समाधान की तरह प्रतीत नहीं होता है। COPY चरण में कैश अभी भी अमान्य है।

यह सही है। जैसा कि यह मुद्दा है जो मैं अभी कर रहा हूं।

मल्टी-स्टेज मेरे लिए बहुत अच्छा काम करता है।

कैश का पूरी तरह से लाभ उठाने के लिए, मैं अपने निर्माण को बहु-चरण में तोड़ रहा हूं, ऐसा कुछ ऐसा दिखता है:

FROM alpine as source

WORKDIR /app
COPY . ./
RUN scripts/stagify-files

FROM node:12.4.0

WORKDIR /app

# Step 0: Setup environments
COPY --from=source /app/stage0 ./
RUN stage0-build.sh

# Step 1: Install npm packages
COPY --from=source /app/stage1 ./
RUN stage1-build.sh

# Step 2: Build project
COPY --from=source /app/stage2 ./
RUN stage2-build.sh

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

@cfletcher मुझे यकीन नहीं है कि मैं पूरी तरह से आपका मतलब समझता हूं।

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

जैसा कि मैंने कल्पना की है, मैंने जो दृष्टिकोण प्रस्तावित किया है वह सामान्य है। मान लीजिए कि आपके प्रोजेक्ट में 100 फाइलें हैं। यह केवल उनमें से 1 को स्टेज 0 बनाने के लिए चुनता है, फिर उनमें से 1+10 को स्टेज 1 बनाने के लिए और फिर सभी 100 को स्टेज 2 बनाने के लिए चुनता है। प्रत्येक चरण पिछले एक के ऊपर स्टैक्ड होता है, और एक अलग बिल्ड कमांड होता है। जटिल परियोजना संरचना के लिए, इसका सीधा सा मतलब है कि स्टैगिफाई-फाइल लॉजिक जटिल होगा।

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

कॉपी के लिए किसी प्रकार का बहिष्कृत तर्क भी चाहेंगे। हमारे पास रूट निर्देशिका में 20+ फ़ाइलें और 10+ निर्देशिकाएं हैं। हम 2 निर्देशिकाओं और कुछ फाइलों पर भारी कोड करते हैं। मैं इन्हें दो कॉपी परतों में विभाजित करना चाहता हूं। एक स्थिर फाइलों और निर्देशिकाओं के लिए जिन्हें हम कभी स्पर्श नहीं करते हैं, और दूसरी उन फाइलों और निर्देशिकाओं के लिए जिन्हें हम हमेशा स्पर्श करते हैं।

यह बहुत दुख की बात है कि इस पर अभी भी ध्यान नहीं दिया जा रहा है। इससे मुझे प्रति बिल्ड 5 मिनट बचाने में मदद मिलती अगर मैं कैश को अमान्य न करने के लिए एक निर्देशिका को बाहर कर सकता था।

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

यह एक साधारण --exclude ध्वज को COPY में जोड़ना इतना कठिन बिक्री है। यह TOP30 सबसे अधिक वोट प्राप्त टिकटों में है, और अन्य TOP30 टिकटों की तुलना में अपेक्षाकृत आसान कार्यान्वयन-वार है। :(

यह विवादास्पद नहीं है, इसके लिए काम की आवश्यकता है।

@cpuguy83 याय। यह विवादास्पद/कुछ हद तक अस्वीकृत जैसा लग रहा था। क्या इसका मतलब यह है कि COPY --exclude के साथ एक उचित पीआर को स्वीकार किया जाएगा, अगर यह गुणवत्ता मानकों को पारित करता है?

मैं प्रत्येक अनुरक्षक के लिए बात नहीं कर सकता, लेकिन मैंने इस बारे में एक या दो महीने पहले @tonistiigi से बात की है और IIRC सबसे बड़ी बाधा है कि यह कैसे dockerignore, वाक्य रचना, आदि से संबंधित है (और तथ्य यह है कि dockerignore वाक्य रचना के लिए अपर्याप्त है)।

परिवर्तन को बिल्डकिट में जाने की आवश्यकता होगी।

COPY --exclude=... --exclude=... अपवोट करना - मेरे मोनोलिथ रेपो के मामले में भी आवश्यक है

अपवोटिंग! मैंने COPY !(excludedfile) . के साथ प्रयास किया जो बैश पर काम करना चाहिए लेकिन यह डॉकर पर नहीं है

मुझे Dockerfile में प्रत्येक COPY स्टेटमेंट के लिए Dockerfile .dockerignore फ़ाइल के अंदर सब कुछ दोहराने के सुझाव पसंद नहीं हैं। छवि का एक हिस्सा होने के साथ DRY बने रहने में सक्षम होना और प्राथमिकता नहीं होनी चाहिए, इम्हो।

#33923 को देखते हुए, मुझे नहीं लगता कि यह संयोग है कि आप बिल्ड संदर्भ से जो बाहर करना चाहते हैं वह ठीक वही सामान है जिसे आप COPY स्टेटमेंट से बाहर करना चाहते हैं। मेरा मानना ​​​​है कि ऐसा कुछ एक अच्छा समाधान होगा:

COPY --use-dockerignore <source> <target>

या शायद कुछ ऐसा भी:

COPY --use-ignorefile=".gitignore" <source> <target>

यह देखते हुए कि कैसे .dockerignore आमतौर पर .gitignore का 90% पुनरुत्पादन होता है, प्रत्येक COPY कथन के लिए प्रत्येक अनदेखा फ़ाइल और फ़ोल्डर को फिर से दोहराने के लिए यह अतिरिक्त कष्टप्रद लगता है। कोई बेहतर तरीका ज़रूर होगा।

@asbjornu .gitignore और .dockerignore एक जैसी चीजें बिल्कुल नहीं हैं। विशेष रूप से मल्टीस्टेज बिल्ड के लिए जहां एक बिल्ड स्टेज पर कलाकृतियां उत्पन्न होती हैं और गिट में बिल्कुल भी मौजूद नहीं होती हैं, फिर भी परिणामी छवि में शामिल किया जाना चाहिए।
और हाँ, मल्टीस्टेज बिल्ड के साथ शुरू की गई हर चरण में अलग-अलग .dockerignore फ़ाइलों का उपयोग करने की क्षमता होनी चाहिए - बिल्कुल।

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

इस मुद्दे को खोले हुए 5 साल हो गए हैं। सितंबर 2020 में, मैं अभी भी यही चाहता हूं। बहुत से लोगों ने हैक करने का सुझाव दिया है लेकिन उनमें से लगभग सभी और अन्य लोगों ने किसी न किसी रूप में exclude ध्वज का अनुरोध किया है। कृपया इस मुद्दे को अभी और अधिक समय तक अनसुलझे न रहने दें।

यदि आप कुछ चाहते हैं, तो आपको उस पर काम करना होगा या उस पर काम करने के लिए किसी को ढूंढना होगा।

यदि आप कुछ चाहते हैं, तो आपको उस पर काम करना होगा या उस पर काम करने के लिए किसी को ढूंढना होगा।

पहले हमें यह जानना होगा कि क्या अपस्ट्रीम ऐसा चाहता है।

https://github.com/moby/moby/issues/15771#issuecomment -550571058

स्रोत कोड की समीक्षा के बाद, मुझे लगता है कि हमें यहां कॉपी फ़ंक्शन का विस्तार करना चाहिए https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go सबसे पहले। उसके बाद, हम libsolver में backend.go का विस्तार कर सकते हैं, और उसके बाद ही AST और बिल्डकिट के फ्रंटएंड का विस्तार संभव होगा।
लेकिन उसके बाद, कॉपी यूनिक्स सीपी की तुलना में rsync सिमेंटिक के करीब होगी।

अद्यतन: हाँ, copy.go को विस्तारित करने के बाद सब कुछ https://github.com/moby/buildkit/pull/1492 के साथ-साथ बहिष्करणों की पार्सिंग सूची के करीब होगा।