Moby: फ़ाइल ग्लोब के साथ Dockerfile COPY उपनिर्देशिकाओं से गंतव्य निर्देशिका में फ़ाइलों की प्रतिलिपि बनाएगा

docker info और uname -a से आउटपुट के साथ मूल संदेश अपडेट किया गया और इसे समस्या रिपोर्टिंग टेम्पलेट के अनुसार पुन: स्वरूपित किया गया।

मेरे पास यह 1.6.2 और 1.8 . पर है
https://gist.github.com/jrabbit/e4f864ca1664ec0dd288 दूसरे स्तर की निर्देशिकाओं को प्रथम स्तर की निर्देशिका के रूप में माना जाता है जो किसी कारण से होनी चाहिए?

उन गुग्लिंग के लिए: यदि आपको COPY * /src के साथ समस्या हो रही है तो COPY //src आज़माएं

@jfchevrette मुझे लगता है कि मुझे पता है कि ऐसा क्यों हो रहा है।
आपके पास COPY files/* /test/ है जो COPY files/dir files/file1 files/file2 files/file /test/ तक फैलता है। यदि आप इसे अलग-अलग COPY कमांड में विभाजित करते हैं (जैसे COPY files/dir /test/ ) तो आप देखेंगे कि (बेहतर या बदतर के लिए) COPY प्रत्येक arg dir की सामग्री को गंतव्य dir में कॉपी करेगा। तर्क डीआईआर ही नहीं, बल्कि सामग्री। यदि आपने तीसरे स्तर के डीआईआर जोड़े हैं तो मैं शर्त लगाता हूं कि वे चारों ओर रहेंगे।

मैं इस तथ्य से रोमांचित नहीं हूं कि COPY शीर्ष-स्तरीय dir को संरक्षित नहीं करता है, लेकिन यह कुछ समय से ऐसा ही है।

यदि संभव हो तो आप स्रोत पेड़ में एक स्तर ऊंचा कॉपी करके इसे कम दर्दनाक बनाने का प्रयास कर सकते हैं।

मुझे पूरा विश्वास है कि @duglin सही है और उस व्यवहार को बदलना बहुत जोखिम भरा हो सकता है। कई dockerfiles अनपेक्षित सामान को तोड़ या कॉपी कर सकते हैं।

हालाँकि मेरा तर्क है कि लंबे समय के लिए यह बेहतर होगा यदि COPY cp या rsync हैंडल ग्लब्स और फोल्डर पर ट्रेलिंग स्लैश जैसे टूल का अनुसरण कर रहा हो। यह निश्चित रूप से अपेक्षित नहीं है कि COPY एक सबफ़ोल्डर से मेल खाने वाले dir/* से गंतव्य IMO में फ़ाइलों की प्रतिलिपि बनाएँ

@jfchevrette हाँ - पहला मौका हमें मिलता है हमें इसे "ठीक" करना चाहिए।
इसे अभी के लिए बंद किया जा रहा है...

@duglin तो, बंद करने का मतलब है कि यह ठीक नहीं होगा?

@tugberkugurlu हाँ, कम से कम अभी के लिए। संपूर्ण बिल्ड इंफ्रास्ट्रक्चर को फिर से करने के लिए काम चल रहा है और जब हम ऐसा करते हैं तो हम कॉपी (या इसके नए समकक्ष) को उस तरह से कार्य कर सकते हैं जैसे इसे करना चाहिए।

@ डगलिन धन्यवाद। क्या इस मुद्दे को खुला रखना और यहां की स्थिति को अपडेट करना संभव है? या क्या इसके लिए कोई अन्य मुद्दा है जिसकी मैं सदस्यता ले सकता हूं?

@tugberkugurlu मुझे लगा कि हमें "क्लाइंट-साइड बिल्डर सपोर्ट" के लिए कोई समस्या है, लेकिन मुझे यह नहीं मिल रहा है। तो हमारे पास वही हो सकता है जो रोडमैप (https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax) कहता है।

जहां तक ​​मुद्दे को खुला रखने का संबंध है, मुझे नहीं लगता कि हम ऐसा कर सकते हैं। डॉकर जिस सामान्य नियम का पालन कर रहा है, वह किसी भी ऐसे मुद्दे को बंद करना है जो तुरंत कार्रवाई योग्य नहीं है। भविष्य के काम के मुद्दे आम तौर पर बंद कर दिए जाते हैं और फिर चीजों की स्थिति बदलने के बाद फिर से खोल दिया जाता है ताकि इस मुद्दे के लिए कुछ कार्रवाई (पीआर) की जा सके।

@duglin यह बहुत गंभीर मुद्दा है, आपको इसे बंद नहीं करना चाहिए क्योंकि समस्या 0.1 रिलीज में पेश की गई थी। 2.0 रिलीज के लिए इसे लक्षित करना अधिक उपयुक्त होगा (मील के पत्थर जीथब पर भी हैं)।

मुझे लगता है कि ज्यादातर लोग इसका इस्तेमाल करते हैं:

COPY . /app

और अन्य सभी फ़ोल्डरों को .gitignore में ब्लैकलिस्ट करें या एकल स्तर निर्देशिका संरचना है और COPY का उपयोग करें जिसमें वास्तव में mv शब्दार्थ है:

COPY src /myapp

मेरे लिए यह कल्पना करना काफी कठिन है कि कोई वास्तव में निर्देशिका संरचना को समतल करने के लिए COPY का उपयोग करेगा। इसके लिए दूसरा समाधान tar -cf .. & ADD tarfile.tar.gz का उपयोग कर रहा है। कम से कम इसे बदलना वास्तव में मददगार होगा। दूसरी बात निर्देशिका नामों में स्लैश का सम्मान कर रही है COPY src /src बनाम COPY src/ /src (जिसे वर्तमान में पूरी तरह से अनदेखा किया गया है)।

डगलिन ने इसे 1 सितंबर, 2015 को बंद कर दिया

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

@tjwebb अभी भी एक खुला मुद्दा है https://github.com/docker/docker/issues/29211 । इसे केवल तभी देखा जा सकता है जब इसे ठीक करने का कोई तरीका हो जो पूरी तरह से पिछड़ा संगत हो। यदि आपके पास कोई प्रस्ताव है तो हम सुझावों के लिए खुले हैं _how_ इसे लागू किया जा सकता है (यदि आप _do_, इसे लिखने के लिए स्वतंत्र महसूस करते हैं, और इस मुद्दे को जोड़ने के लिए एक प्रस्ताव खोलते हैं)। ध्यान दें कि cp को संभालने के तरीके में (उदाहरण के लिए), OS X और Linux के बीच पहले से ही अंतर है;

mkdir -p repro-15858 \
  && cd repro-15858 \
  && mkdir -p source/dir1 source/dir2 \
  && touch source/file1 source/dir1/dir1-file1 \
  && mkdir -p target1 target2 target3 target4 target5 target6

cp -r source target1 \
&& cp -r source/ target2 \
&& cp -r source/ target3/ \
&& cp -r source/* target4/ \
&& cp -r source/dir* target5/ \
&& cp -r source/dir*/ target6/ \
&& tree

ओएस एक्स:

.
├── source
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target1
│   └── source
│       ├── dir1
│       │   └── dir1-file1
│       ├── dir2
│       └── file1
├── target2
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target3
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target4
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target5
│   ├── dir1
│   │   └── dir1-file1
│   └── dir2
└── target6
    └── dir1-file1

20 directories, 12 files

उबंटू पर (/ बिन/श)

.
|-- source
|   |-- dir1
|   |   `-- dir1-file1
|   |-- dir2
|   `-- file1
|-- target1
|   `-- source
|       |-- dir1
|       |   `-- dir1-file1
|       |-- dir2
|       `-- file1
|-- target2
|   `-- source
|       |-- dir1
|       |   `-- dir1-file1
|       |-- dir2
|       `-- file1
|-- target3
|   `-- source
|       |-- dir1
|       |   `-- dir1-file1
|       |-- dir2
|       `-- file1
|-- target4
|   |-- dir1
|   |   `-- dir1-file1
|   |-- dir2
|   `-- file1
|-- target5
|   |-- dir1
|   |   `-- dir1-file1
|   `-- dir2
`-- target6
    |-- dir1
    |   `-- dir1-file1
    `-- dir2

24 directories, 12 files

diff --git a/macos.txt b/ubuntu.txt
index 188d2c3..d776f19 100644
--- a/macos.txt
+++ b/ubuntu.txt
@@ -11,15 +11,17 @@
 │       ├── dir2
 │       └── file1
 ├── target2
-│   ├── dir1
-│   │   └── dir1-file1
-│   ├── dir2
-│   └── file1
+│   └── source
+│       ├── dir1
+│       │   └── dir1-file1
+│       ├── dir2
+│       └── file1
 ├── target3
-│   ├── dir1
-│   │   └── dir1-file1
-│   ├── dir2
-│   └── file1
+│   └── source
+│       ├── dir1
+│       │   └── dir1-file1
+│       ├── dir2
+│       └── file1
 ├── target4
 │   ├── dir1
 │   │   └── dir1-file1
@@ -30,6 +32,8 @@
 │   │   └── dir1-file1
 │   └── dir2
 └── target6
-    └── dir1-file1
+    ├── dir1
+    │   └── dir1-file1
+    └── dir2

-20 directories, 12 files
+24 directories, 12 files

कृपया एक नया कमांड CP बनाएं और इसे इस बार ठीक करें।

मैं उपरोक्त को प्रतिध्वनित करूंगा, इसने अनगिनत विकास घंटे बर्बाद किए होंगे, यह अत्यंत गैर-सहज ज्ञान युक्त है।

मुझसे +1। यह वास्तव में बेवकूफी भरा व्यवहार है और इसे केवल एक CP कमांड जोड़कर आसानी से ठीक किया जा सकता है जो यह करता है कि COPY कैसा होना चाहिए।

"पीछे की ओर संगतता" एक पुलिस अधिकारी है

टीएल; डीआर संस्करण:

COPY * /app का उपयोग न करें, यह वह नहीं करता जो आप उससे करने की अपेक्षा करते हैं।
निर्देशिका ट्री को संरक्षित करने के बजाय COPY . /app का उपयोग करें।

कॉपी केवल इसके सबफ़ोल्डर को कॉपी करने में सक्षम है।

बस इस पर अनगिनत घंटे बिताए... यह इस तरह से भी क्यों काम करता है?

मैं Paket का उपयोग कर रहा हूं और निम्नलिखित को सही संरचना में कॉपी करना चाहता हूं:

.
├── .paket/
│   ├── paket.exe
│   ├── paket.bootstrapper.exe
├── paket.dependencies
├── paket.lock
├── projectN/

और COPY *paket* ./ करने से इसका परिणाम कंटेनर के अंदर होता है:

.
├── paket.dependencies
├── paket.lock

--glob या --recursive ध्वज को COPY और ADD के लिए जोड़ने के बारे में क्या?

कॉपी करें। /गंतव्य उप-फ़ोल्डरों को सुरक्षित रखता है।

तीन साल और यह अभी भी एक मुद्दा है: - /

क्या हमें ईटीए मिल सकता है, यह कब तय होगा

मुद्दा नहीं...
ऊपर से...
कॉपी करें।

सच है, आधे दिन तक धूम्रपान करने और यहाँ समाप्त होने के बाद अब कोई समस्या नहीं है। ज़रूर :)
आइए रचनात्मक बनें,

हमें वास्तव में _COPY_ के लिए एक नए _CP_ कमांड या --recursive ध्वज की आवश्यकता है ताकि पश्च संगतता संरक्षित रहे।

शीर्ष बिंदु यदि हम छवि निर्माण पर चेतावनी भी दिखाते हैं, जैसे:
Directory structure not preserved with COPY *, use CP or COPY . More here <link>. अगर हमें संभावित दुरुपयोग का पता चलता है।

मैं npm install कैश का बेहतर उपयोग करने के लिए उपनिर्देशिकाओं में नेस्टेड lerna package.json फ़ाइलों की प्रतिलिपि बनाने के लिए इसकी तलाश कर रहा हूं, जब निर्भरता बदलती है। वर्तमान में बदली गई सभी फाइलें निर्भरता को फिर से स्थापित करने का कारण बनती हैं।

ऐसा कुछ बहुत अच्छा होगा:

COPY ["package.json", "packages/*/package.json", "/app/"]

#29211 लोगों की जांच करें। इसे बंद कर दिया गया है और किसी को परवाह नहीं है।

@zentby वार्तालाप यहाँ है, समस्या को वहाँ ट्रैक किया गया है (चूंकि यह बंद है) ... यह भ्रमित करने वाला है।

COPY फाइलों और RUN cp -R कमांड के लिए एक समाधान है

COPY files /tmp/
RUN cp -R /tmp/etc/* /etc/ && rm -rf /tmp/etc

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

कैश को विकृत करने के लिए मुझे केवल फाइलों का एक सेट (मेरे मामले में, *.sln और *.csproj फ़ाइलें डॉटनेट कोर के लिए) कॉपी करने की आवश्यकता थी। एक काम यह है कि आप जो फाइलें चाहते हैं उनकी टार बॉल बनाएं और फिर डॉकर फाइल में टारबॉल जोड़ें। हाँ, अब आपके पास डॉकर फ़ाइल के अतिरिक्त एक शेल स्क्रिप्ट होनी चाहिए...

बिल्ड.शो

#!/bin/bash

# unfortunately there's no easy way to copy just the *.sln and *.csproj (see https://github.com/moby/moby/issues/15858)
# so we generate a tar file containing the required files for the layer

find .. -name '*.csproj' -o -name 'Finomial.InternalServicesCore.sln' -o -name 'nuget.config' | sort | tar cf dotnet-restore.tar -T - 2> /dev/null

docker build -t finomial/iscore-build -f Dockerfile ..

डॉकर फ़ाइल

FROM microsoft/aspnetcore-build:2.0
WORKDIR /src

# set up a layer for dotnet restore 

ADD docker/dotnet-restore.tar ./

RUN dotnet restore

# now copy all the source and do the dotnet buld
COPY . ./

RUN dotnet publish --no-restore -c Release -o bin Finomial.InternalServicesCore.sln

ऐसा करने के लिए आप कई COPY कमांड का उपयोग कर सकते हैं, लेकिन इससे कई छवि परतें बनाने और आपके अंतिम छवि आकार को फूलने का नुकसान होता है।

जैसा कि ऊपर उल्लेख किया गया है, आप निर्देशिका संरचना को संरक्षित करने वाले टैरबॉल बनाने के लिए एक सहायक बिल्ड स्क्रिप्ट में docker build कमांड को भी लपेट सकते हैं, और ADD उन्हें इसमें शामिल कर सकते हैं, लेकिन यह जटिलता जोड़ता है और docker-compose build जैसी चीजों को तोड़ देता है

वास्तव में, COPY को POSIX अनुरूप /bin/cp -r कमांड की तरह ही कार्य करना चाहिए, लेकिन ऐसा लगता है कि 'बैकवर्ड संगतता' के लिए ऐसा नहीं होगा, भले ही वर्तमान व्यवहार अनुभव वाले किसी भी व्यक्ति के लिए पूरी तरह से अनजान है * निक्स सिस्टम में।

मुझे जो सबसे अच्छा समझौता मिला है, वह हैक के रूप में मल्टी-स्टेज बिल्ड का उपयोग करना है:

FROM scratch as project_root
# Use COPY to move individual directories
# and WORKDIR to change directory
WORKDIR /
COPY ./file1 .
COPY ./dir1/ ./dir1/
COPY ./dir2/ .
WORKDIR /newDir
COPY ./file2 .

# The actual final build you end up using/pushing
# Node.js app as example
FROM node
WORKDIR /opt/app

COPY package.json .
RUN npm install

COPY --from=project_root / .
CMD ["npm", "start"]

यह एक Dockerfile के भीतर स्वयं समाहित है, और अंतिम छवि में केवल एक परत बनाता है, ठीक उसी तरह जैसे ADD project.tar कैसे काम करेगा।

डॉकर बिल्ड कैश को संरक्षित करने का प्रयास करते समय पूर्ण COPY कमांड वास्तव में मदद करेगा। ROS समुदाय पैकेजों के नेस्टेड कार्यक्षेत्र का उपयोग करके विकसित होता है, प्रत्येक अपनी स्वयं की package.xml फ़ाइल में निर्भरता की घोषणा करता है। इन फ़ाइलों का उपयोग किसी भी अपस्ट्रीम लाइब्रेरी को स्थापित करने के लिए एक निर्भरता प्रबंधक द्वारा किया जाता है। ये package.xml फ़ाइल आधारभूत कार्य निर्धारित होने के बाद पैकेज में कोड के लिए अपेक्षाकृत बार-बार wrt बदल जाती है। यदि निर्देशिका ट्री संरचना को एक प्रतिलिपि के दौरान संरक्षित किया गया था, तो हम कैशिंग को अधिकतम करने के लिए दो चरणों में डॉकटर बिल्ड के दौरान अपने कार्यक्षेत्र की प्रतिलिपि बना सकते हैं जैसे:

# copy project dependency metadata
COPY ./**/package.xml /opt/ws/

# install step that fetches unsatisfied dependency
RUN dependency_manager install --workspace /opt/ws/

# copy the rest of the project's code
COPY ./ /opt/ws/

# compile code with cached dependencies
RUN build_tool build --workspace /opt/ws/

इस प्रकार ऊपर निर्भरता स्थापित परत के लिए कैश केवल तभी बस्ट होगा यदि डेवलपर घोषित निर्भरता को बदल देता है, जबकि पैकेज के कोड में परिवर्तन केवल संकलन परत को नष्ट कर देगा।

वर्तमान में, सभी मिलान की गई package.xml फ़ाइलों को एक दूसरे के ऊपर गंतव्य निर्देशिका के मूल में कॉपी किया जा रहा है, जिसमें अंतिम ग्लोब वाली फ़ाइल केवल package.xml है जो छवि में बनी हुई है। जो वास्तव में उपयोगकर्ताओं के लिए काफी सहज ज्ञान युक्त नहीं है! कॉपी की गई फ़ाइलों को एक-दूसरे के ऊपर ओवरराइट क्यों किया जा रहा है, साथ ही अपरिभाषित व्यवहार जो अंततः छवि में बना रहता है।

यह मूल रूप से हर स्टैक में एक ऐसा दर्द है जिसमें पैकेज प्रबंधन होता है, इसलिए यह हम में से कई लोगों को प्रभावित करता है। क्या इसे ठीक किया जा सकता है? शीश। यह 2015 से एक मुद्दा है! CP की एक नई कमांड का उपयोग करने का सुझाव एक अच्छा है।

क्या हम इसे फिर से खोल सकते हैं? यह बहुत कठिन व्यवहार है कि COPY कमांड पथ मिलान के लिए एक गोलंग आंतरिक फ़ंक्शन का उपयोग करता है, न कि वास्तविक व्यापक-अपनाया गया मानक, जैसे ग्लोब

उन लोगों के लिए जो प्रायोगिक बिल्डकिट सिंटैक्स के साथ वर्कअराउंड का उपयोग करके ग्लोबिंग के माध्यम से कॉपी करना चाहते हैं, भले ही कैशिंग सटीक या मजबूत न हो, यहां टिप्पणियों पर एक नज़र डाल सकते हैं: https://github.com/moby/moby/issues /39530#मुद्दा टिप्पणी -530606189

मैं अभी भी इस मुद्दे को फिर से खोलना चाहता हूं ताकि हम चुनिंदा ग्लोब शैली प्रतियों पर कैश कर सकें।

मुझे अपने उदाहरण के लिए https://github.com/moby/moby/issues/15858#issuecomment -462017830 मल्टी-स्टेज बिल्ड के माध्यम से अपेक्षाकृत सरल समाधान का एहसास हुआ, और सोचा कि आप में से कई समान आवश्यकताओं के साथ कॉपी किए गए कैशिंग की सराहना कर सकते हैं निर्माण संदर्भ से कलाकृतियों। मल्टी-स्टेज बिल्ड का उपयोग करके, निर्देशिका को कैश करने के लिए फ़िल्टर/प्रीप्रोसेस करना संभव है:

# Add prior stage to cache/copy from
FROM ubuntu AS package_cache

# Copy from build context
WORKDIR /tmp
COPY ./ ./src

# Filter or glob files to cache upon
RUN mkdir ./cache && cd ./src && \
    find ./ -name "package.xml" | \
      xargs cp --parents -t ../cache

# Continue with primary stage
FROM ubuntu

# copy project dependency metadata
COPY --from=package_cache /tmp/cache /opt/ws/

# install step that fetches unsatisfied dependency
RUN dependency_manager install --workspace /opt/ws/

# copy the rest of the project's code
COPY ./ /opt/ws/

# compile code with cached dependencies
RUN build_tool build --workspace /opt/ws/

वास्तविक दुनिया में काम करने वाले उदाहरण के लिए, आप यहां भी देख सकते हैं: https://github.com/ros-planning/navigation2/pull/1122

मैं npm install कैश का बेहतर उपयोग करने के लिए उपनिर्देशिकाओं में नेस्टेड lerna package.json फ़ाइलों की प्रतिलिपि बनाने के लिए इसकी तलाश कर रहा हूं, जब निर्भरता बदलती है। वर्तमान में बदली गई सभी फाइलें निर्भरता को फिर से स्थापित करने का कारण बनती हैं।

ऐसा कुछ बहुत अच्छा होगा:

COPY ["package.json", "packages/*/package.json", "/app/"]

मेरे पास एक ही उपयोग का मामला है।

मैं npm install कैश का बेहतर उपयोग करने के लिए उपनिर्देशिकाओं में नेस्टेड lerna package.json फ़ाइलों की प्रतिलिपि बनाने के लिए इसकी तलाश कर रहा हूं, जब निर्भरता बदलती है। वर्तमान में बदली गई सभी फाइलें निर्भरता को फिर से स्थापित करने का कारण बनती हैं।

ऐसा कुछ बहुत अच्छा होगा:

COPY ["package.json", "packages/*/package.json", "/app/"]

यह मामला लेकिन यार्न कार्यक्षेत्रों के लिए।

यह 2020 है और यह अभी भी तय नहीं है।

अगर कोई डॉटनेट सेटिंग में इससे जूझ रहा है, तो मैंने इसे डॉटनेट कोर ग्लोबल टूल लिखकर हमारे लिए हल किया है जो *.csproj फाइलों के लिए निर्देशिका संरचना को पुनर्स्थापित करता है, जिससे पुनर्स्थापना का पालन किया जा सकता है। इसे यहां कैसे करें, इस पर प्रलेखन देखें।

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

यह आश्चर्यजनक है कि कॉपी कमांड को लागू करना पहले वर्ष में एक छात्र के लिए एक कार्य हुआ करता था, और अब कई वर्षों के अनुभव वाले कुशल प्रोग्रामर के लिए यह बहुत जटिल है ...

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

@बेनमक्कलम
एफवाईआई, सैद्धांतिक रूप से एक समान दृष्टिकोण का उपयोग अन्य सेटिंग्स में किया जा सकता है, लेकिन अनिवार्य रूप से उपकरण फ़ोल्डर संरचना को रिवर्स-इंजीनियरिंग कर रहा है,

क्या अधिकांश अवसरों के लिए केवल वही करना आसान नहीं है जो https://github.com/moby/moby/issues/15858#issuecomment -532016362 ने सुझाया है और प्रीफ़िल्टर करने के लिए एक मल्टी-स्टेज बिल्ड का उपयोग करें?

इसके अलावा dotnet restore मामले के लिए यह अपेक्षाकृत आसान पैटर्न है:

# Prefiltering stage using find -exec and cp --parents to copy out
# the project files in their proper directory structure.
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS dotnet-prep
COPY . ./src/
RUN mkdir ./proj && cd ./src && \
  find . -type f -a \( -iname "*.sln" -o -iname "*.csproj" \) \
    -exec cp --parents "{}" ../proj/ \;

# New build stage, independent cache
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS dotnet-build

# Copy only the project files with correct directory structure
# then restore packages
COPY --from=dotnet-prep ./proj ./src/
RUN dotnet restore

# Copy everything else
COPY --from=dotnet-prep ./src ./src/
# etc.

अभी भी डॉकर के लिए COPY कमांड पर एक सभ्य संस्करण को लागू करने के लिए उपयुक्त बहाना नहीं बनाता है जो कि सामान्य, समझदार सिंकिंग सेमेन्टिक्स का पालन करता है।
मेरा मतलब है; पर आना!

@rjgotten , मुझे यह पसंद है! मैंने जो किया उससे निश्चित रूप से बहुत आसान है और मैं नहीं देख सकता कि यह मेरी ज़रूरतों के लिए क्यों काम नहीं करेगा। मैं इसे कल जाने दूंगा और अगर यह काम करता है तो मैं इसे बेहतर दृष्टिकोण के रूप में अनुशंसा करने के लिए अपने डॉक्टर को बदल दूंगा।

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

क्या वास्तव में अतिरिक्त/दोहराए गए से ... की आवश्यकता है? हर बार जब आप रन करते हैं तो यह कैशिंग के लिए एक नई परत बनाता है, है ना? हो सकता है कि मुझे कुछ याद आ रहा हो, मुझे इस बारे में सोचने के बाद से कुछ समय हो गया है!

मुझे आश्चर्य है कि क्या पावरशेल डॉटनेट कोर छवियों में पूर्व-स्थापित है ...

मुझे लगता है कि यह वास्तव में है। जो इसे क्रॉस-प्लेटफ़ॉर्म तरीके से करना थोड़ा आसान बना देगा।

क्या वास्तव में अतिरिक्त/दोहराए गए से ... की आवश्यकता है?

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

दूसरा चरण _only_ प्रोजेक्ट से संबंधित फाइलों में कॉपी करके शुरू होता है और जब तक वे फाइलें समान होती हैं - यानी समान फाइल नाम; समान सामग्री; आदि - उस परत को बनाता है _वोंट_ अमान्य नहीं होता है। जिसका अर्थ है कि dotnet restore परत _also_ तब तक अमान्य नहीं होगी जब तक कि वे प्रोजेक्ट फ़ाइलें वास्तव में परिवर्तित नहीं हो जातीं।

इसके साथ बैठने के लिए कुछ समय था और अब मैं समझता हूँ! डॉकर मजेदार है क्योंकि जब तक आप हमेशा इसके साथ समय नहीं बिताते हैं, आप भूल जाते हैं कि सभी कमांड कैसे काम करते हैं। महत्वपूर्ण रूप से, मैं भूल गया था कि रन cmd केवल डॉकर छवि के फाइल सिस्टम पर काम कर सकता है, न कि निर्माण संदर्भ फाइलों पर। इससे पहले कि आप एक जटिल RUN cmd कर सकें, जो dirs को संरक्षित करता है, आपको सब कुछ कॉपी करने के लिए मजबूर होना पड़ता है। और इसीलिए हमें सभ्य COPY ग्लोबिंग की सख्त जरूरत है!

वह दृष्टिकोण
जैसा कि आप उल्लेख करते हैं, प्रारंभिक COPY cmd है, _everything_ को कॉपी करना और फिर यह .sln और .csproj फ़ाइलों को एक अलग /proj फ़ोल्डर में बाहर निकाल रहा है। कोई भी कोड परिवर्तन इन चरणों को अमान्य कर देगा। महत्वपूर्ण रूप से, यह जिस सीमा के आसपास काम कर रहा है, वह यह है कि भयानक RUN linux cmd केवल फाइलों पर काम कर सकता है _on docker image पहले से ही, लालची COPY द्वारा पहले लाया गया।

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

मेरा दृष्टिकोण
डॉटनेट पुनर्स्थापना को प्रभावित करने वाली फ़ाइलों को लाने के लिए कुछ और COPY आदेशों की कीमत पर इसके लिए केवल एक बिल्ड चरण का उपयोग करता है। मैं विशेष रूप से सभी .csproj फ़ाइलों को एक डीआईआर में समतल करता हूं, और फिर प्रविष्टि .sln फ़ाइल से सही निर्देशिका संरचना को फिर से बनाने के लिए अपने वैश्विक टूल का उपयोग करता हूं। इसके बाद ही मैं सभी src फाइलों पर कॉपी करता हूं, इसलिए मैं सभी src फाइलों को हमेशा कॉपी करने के बजाय, नियमित रूप से यहां तक ​​परतों को प्रभावी ढंग से कैश कर सकता हूं।

टेकअवे
मुझे लगता है कि यह लोगों के कोडबेस पर निर्भर करेगा कि प्रत्येक दृष्टिकोण कितना प्रभावी है। हमारे लिए, एक मोनो रेपो में, हमारे पास बहुत सारे साझा कोड हैं जो "सभी स्रोत ओवर" कॉपी में कॉपी हो जाते हैं। .dockerignore यहां मदद करता है, लेकिन इसे बनाए रखना मुश्किल है, इसलिए हम उस कॉपी में बहुत "लालची" हैं; तो यह काफी धीमा है। इस प्रकार, मेरा दृष्टिकोण, हालांकि थोड़ा अधिक जटिल है, शायद इस विकल्प की तुलना में हमारे लिए तेज़ होगा।

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

बिल्डकिट जांच
RUN --mount=type=bind - ऐसा लगता है कि यह हमें फैंसी linux cmd को बिल्ड संदर्भ के विरुद्ध करने की अनुमति देगा ( RUN के बजाय केवल छवि के फाइल सिस्टम तक सीमित है)। वास्तव में यह स्पष्ट रूप से निर्माण के संदर्भ में चूक करता है।

RUN --mount=type=cache - किसी प्रकार की पुन: प्रयोज्य कैश निर्देशिका की तरह लगता है (डॉकर बिल्ड के बीच?) जो संरक्षित है? तो संक्षेप में, हमें पैकेज पुनर्स्थापना के लिए कैश परत के बारे में बहुत अधिक चिंता करने की आवश्यकता नहीं होगी, क्योंकि पहले से पुनर्स्थापित किए गए पैकेजों के पुन: उपयोग किए गए कैश के साथ यह पहले से ही बहुत तेज़ हो जाएगा !?

मुझे लगता है कि समस्या अभी तक ठीक नहीं हुई है क्योंकि यह "बंद" है और लोगों को कामकाज के लिए उपयोग किया जाता है।

जब आप यह नहीं समझ पाते हैं कि लोग दूसरे प्रकार के कंटेनर में क्यों जाते हैं।

क्या कोई अन्य कंटेनर प्रकार है जिसका मैं उपयोग कर सकता हूं। विश्वास नहीं हो रहा है कि यह इतने सालों के बाद भी समर्थित नहीं है? क्या डॉकर एक ओपन सोर्स प्रोजेक्ट है, क्या कोई इसे ठीक कर सकता है?

कॉपी व्यवहार को cp -r जैसा बनाने के लिए हमारे पास अर्थली में एक COPY --dir विकल्प है। शायद इसे Dockerfile में भी पोर्ट किया जा सकता है?

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

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build

# Nugets restore
WORKDIR /src/allprojects          # just temporary storage for .csproj files
COPY */*.csproj ./
RUN for file in $(ls *.csproj); do dotnet restore ${file}; done

# Build/Publish
WORKDIR /src/solution             # actual folder with source code and full hierarchy 
COPY . .
RUN dotnet publish "MyProject/MyProject.csproj" -c Release -o /bublish/myproject

# Run Application
FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS base
WORKDIR /app
COPY --from=build /bublish/myproject .
ENTRYPOINT ["dotnet", "MyProject.dll"]

@zatuliveter
छूटी हुई परियोजनाओं के बारे में कुछ चेतावनियाँ हैं क्योंकि हम फ़ोल्डर पदानुक्रम को संरक्षित नहीं कर सकते हैं, लेकिन फिर भी यह समाधान काम कर रहा है।

नहीं; कि काम नहीं करता। और यहाँ क्यों है:

.NET कोर पैकेज मेटा-सूचना को ./obj प्रत्येक प्रोजेक्ट से संबद्ध उपनिर्देशिका में संग्रहीत करता है। उस जानकारी के बिना, पैकेज को स्थापित और उपयोग के लिए तैयार नहीं माना जाएगा। (मुझ पर विश्वास न करें? फिर अपना ./obj फ़ोल्डर फेंक दें और फिर उदाहरण के लिए VSCode में प्रोजेक्ट खोलें और देखें कि यह आपको पैकेज पुनर्स्थापना को फिर से चलाने के लिए कहता है। आगे बढ़ें; इसे आज़माएं।)

यदि प्रोजेक्ट फ़ाइलें जिन पर आप पैकेज पुनर्स्थापना निष्पादित करते हैं, निम्न dotnet build या dotnet publish से भिन्न निर्देशिका संरचना में हैं, तो वे आदेश पैकेज को पुनर्स्थापित के रूप में नहीं देखेंगे।

आपका समाधान पूरी तरह विफल नहीं होने का कारण यह है कि dotnet publish और dotnet build दोनों का अर्थ है dotnet restore । वे सक्रिय रूप से अप्रतिबंधित पैकेजों की जांच करते हैं और उन्हें ऑन-द-फ्लाई पुनर्स्थापित करते हैं। ऐसा करने से बचने के लिए, आपको सक्रिय रूप से --no-restore ध्वज को पास करना होगा, जो आप नहीं कर रहे हैं।

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

@rjgotten ,
आपके उत्तर और स्पष्टीकरण के लिए धन्यवाद।
वास्तव में सभी नगेट पैकेज 'बिल्ड' डॉकटर कंटेनर में global-packages फ़ोल्डर में कैश किए जाते हैं। मेरे मामले में यह /root/.nuget/packages/ फ़ोल्डर है, और obj फ़ोल्डर में इस वैश्विक भंडारण के संदर्भ में छोटी फाइलें हैं, इसलिए भंडारण की कोई बर्बादी नहीं है (जैसा कि आप उल्लेख करते हैं)।
दूसरा कम से कम x10 गुना तेजी से प्रकाशित करने के दौरान पुनर्स्थापित करें (मेरे मामले में) क्योंकि सभी नगेट्स कंटेनर में कैश किए जाते हैं।

@zatuliveter @rjgotten यहाँ अंत में जानकारी के लिए धन्यवाद। मैं इसी तरह के मुद्दों में भाग रहा था और आपके द्वारा दिए गए उदाहरणों में सुधार करने के लिए निम्नलिखित dockerfile के साथ आया था। बैश निश्चित रूप से मेरा मजबूत सूट नहीं है इसलिए मुझ पर आसान हो जाओ! हमारी सभी परियोजनाओं के लिए हमारी संरचना Project/Project.csproj है। यह सभी प्रोज फाइलों की प्रतिलिपि बनाता है, उन्हें सही जगह पर ले जाता है, और फिर पुनर्स्थापित/प्रतिलिपि/प्रकाशित करता है।

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ./*/*.csproj ./proj/
RUN for file in $(ls ./proj); do mkdir /src/${file%.*} && mv ./proj/${file} /src/${file%.*}/${file}; done
RUN dotnet restore "MyProject/MyProject.csproj"
COPY . .
WORKDIR "/src/MyProject"
RUN dotnet publish "MyProject.csproj" -c Release -o /app --no-restore