डॉकर के निर्माण संदर्भ के बाहर की फाइलें कैसे शामिल करें?

Question

मैं डॉकर फ़ाइल में "ADD" कमांड का उपयोग करके डॉकर के बिल्ड संदर्भ के बाहर की फ़ाइलों को कैसे शामिल कर सकता हूं?

डॉकर प्रलेखन से:

पथ निर्माण के संदर्भ में होना चाहिए; आप ADD ../something/something को नहीं कर सकते, क्योंकि डॉक बिल्ड का पहला चरण डॉक्यूमेंट डेमन को संदर्भ निर्देशिका (और उपनिर्देशिका) भेजना है।

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

इसके अलावा, ऐसा प्रतीत होता है कि डॉकर अभी तक (और कभी नहीं हो सकता है) सहानुभूति का समर्थन नहीं करता है : डॉकरीफाइल एडीडी कमांड मेजबान # 1676 पर सहिंबल का पालन नहीं करता है।

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

Comments

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

— टाइगरबियर

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

— जर्सी बीन

मुझे एक अच्छी संरचना मिली और मैं stackoverflow.com/a/53298446/433814

— Marcello de Sales

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

— डेविस एल

Answer 1

इसके चारों ओर काम करने का सबसे अच्छा तरीका -f का उपयोग करते हुए निर्माण संदर्भ के स्वतंत्र रूप से डॉकरफाइल को निर्दिष्ट करना है।

उदाहरण के लिए, यह कमांड आपकी वर्तमान निर्देशिका में किसी भी चीज़ में ADD कमांड को एक्सेस देगा।

docker build -f docker-files/Dockerfile .

अद्यतन : डॉकर अब बिल्ड संदर्भ (18.03.0-ce, https://github.com/docker/cli/pull/886 में तय ) के बाहर डॉकरीफाइल रखने की अनुमति देता है । तो आप भी कुछ ऐसा कर सकते हैं

docker build -f ../Dockerfile .

Comments

@Ro। आप कंपोज़ फ़ाइल में अनुभाग में dockerfile:प्रॉपर्टी का उपयोग करते हैं docs.docker.com/compose/compose-file/#/compose-file-referencebuild:

— Emerson Farrugia

मुझे "Dockerfile का निर्माण संदर्भ के भीतर होना चाहिए" मिलता है - मैं वास्तव में एक Dockerfile रखना चाहूंगा जो वर्तमान बिल्ड संदर्भ से नीचे रह सकती है। आपके उदाहरण में आपके पास वर्तमान निर्माण के संदर्भ में / नीचे डॉकफाइल है, जो निश्चित रूप से काम करता है।

— अलेक्जेंडर मिल्स

हाँ, मैं सिर्फ एक साझा डॉकफ़ेयर चाहता हूं जो कई उपनिर्देशिकाओं से मेल खाता है, जिनमें से सभी "बिल्ड संदर्भ" हैं

— अलेक्जेंडर मिल्स

क्या यह ओपी ADDको संदर्भ निर्देशिका से बाहर होने वाली फ़ाइल के लिए समस्या को हल करता है ? यही मैं करने की कोशिश कर रहा हूं, लेकिन मुझे नहीं लगता कि -fबाहरी फ़ाइलों को उपयोग करने योग्य बनाता है।

— श्रीधर सरनोबत

यह पर्याप्त नहीं कर सकता .. मेरे docker-compose.yml में मेरे पास है build: context: .., dockerfile: dir/Dockerfile:। अब मेरा बिल्ड संदर्भ मूल निर्देशिका है!

— माइक ग्लीसन जूनियर क्यूटूरियर

Answer 2

मैं अक्सर खुद --build-argको इस उद्देश्य के लिए विकल्प का उपयोग करते हुए पाता हूं । उदाहरण के लिए डॉकफाइल में निम्नलिखित डालने के बाद:

ARG SSH_KEY
RUN echo "$SSH_KEY" > /root/.ssh/id_rsa

आप बस कर सकते हैं:

docker build -t some-app --build-arg SSH_KEY="$(cat ~/file/outside/build/context/id_rsa)" .

लेकिन डॉकर प्रलेखन से निम्नलिखित चेतावनी पर ध्यान दें :

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

Comments

यह एक बड़ी चेतावनी के बिना खराब सलाह है। डॉक डॉक्यूमेंटेशन से: "वार्निंग: जीथब कीज़, यूज़र क्रेडेंशियल्स आदि जैसे सीक्रेट पासिंग के लिए बिल्ड-टाइम वैरिएबल का उपयोग करने की अनुशंसा नहीं की गई है। बिल्ड-टाइम वैरिएबल वैल्यू इमेज के किसी भी यूज़र को डॉक हिस्ट्री कमांड के साथ दिखाई देते हैं।" [१] दूसरे शब्दों में, इस उदाहरण में दिया गया उदाहरण docker छवि में निजी SSH कुंजी को प्रकट करता है। कुछ संदर्भों में, यह ठीक हो सकता है। docs.docker.com/engine/reference/builder/#arg

— sheldonh

अंत में, इस सुरक्षा समस्या को दूर करने के लिए, आप स्क्वाशिंग

— Jojo

Answer 3

लिनक्स पर आप उन्हें सिम्प्लेक्स करने के बजाय अन्य निर्देशिकाओं को माउंट कर सकते हैं

mount --bind olddir newdir

अधिक जानकारी के लिए /superuser/842642 देखें ।

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

Comments

केवल रूट ही निर्देशिकाओं को बाँध सकता है

— jjcf89

Answer 4

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

• Dockerfile: केवल अपने स्वयं के सापेक्ष पथ के तहत फाइलें देखेंगे
• प्रसंग: "स्पेस" में एक जगह जहाँ फ़ाइलें आप साझा करना चाहते हैं और आपका डॉकरीफाइल कॉपी किया जाएगा

इसलिए, उस कहा के साथ, यहां डॉकरफाइल का एक उदाहरण है जिसे एक फ़ाइल नामक पुन: उपयोग करने की आवश्यकता है start.sh

Dockerfile

यह ALWAYSअपने सापेक्ष पथ से लोड होगा, localआपके द्वारा निर्दिष्ट रास्तों के संदर्भ के रूप में वर्तमान dir होने से ।

COPY start.sh /runtime/start.sh

फ़ाइलें

इस विचार को ध्यान में रखते हुए, हम डॉकफाइल्स के लिए विशिष्ट चीजों के निर्माण के लिए कई प्रतियां होने के बारे में सोच सकते हैं, लेकिन उन्हें सभी तक पहुंच की आवश्यकता है start.sh।

./all-services/
   /start.sh
   /service-X/Dockerfile
   /service-Y/Dockerfile
   /service-Z/Dockerfile
./docker-compose.yaml

इस संरचना और उपरोक्त फाइलों को ध्यान में रखते हुए, यहाँ एक docker-compose.yml है

डोकर-compose.yaml

• इस उदाहरण में, आपका sharedसंदर्भ dir runtimedir है।
  • यहां एक ही मानसिक मॉडल, सोचें कि इस dir के तहत सभी फाइलें तथाकथित पर स्थानांतरित हो जाती हैं context।
  • इसी तरह, केवल उस डॉकरीफाइल को निर्दिष्ट करें जिसे आप उसी डायर में कॉपी करना चाहते हैं। आप इसका उपयोग करके निर्दिष्ट कर सकते हैं dockerfile।
• वह निर्देशिका जहां आपका मुख्य कंटेंट स्थित है, वह सेट होने वाला वास्तविक संदर्भ है।

इस docker-compose.ymlप्रकार है

version: "3.3"
services:

  service-A
    build:
      context: ./all-service
      dockerfile: ./service-A/Dockerfile

  service-B
    build:
      context: ./all-service
      dockerfile: ./service-B/Dockerfile

  service-C
    build:
      context: ./all-service
      dockerfile: ./service-C/Dockerfile

• all-serviceसंदर्भ के रूप में सेट किया गया है, साझा की गई फ़ाइल start.shको कॉपी किया गया है और साथ ही प्रत्येक द्वारा निर्दिष्ट डॉकरीफाइल भी dockerfile।
• प्रत्येक को शुरू फ़ाइल साझा करने, अपने तरीके से बनाया जा सकता है!

चीयर्स!

Comments

Dockerfile पर आपकी बात पूरी तरह से सही नहीं है, जैसा कि स्वीकृत उत्तर द्वारा बताया गया है, यदि आप एक फ़ोल्डर पदानुक्रम में हैं a/b/c, तो हाँ चल रहा docker build .है cआपको एक्सेस करने की अनुमति नहीं देगा ../file-in-b। लेकिन, मुझे लगता है कि इसमें (या कम से कम मेरा) सामान्य गलतफहमी है कि संदर्भ को बिल्ड कमांड के पहले तर्क द्वारा बताए गए स्थान से परिभाषित किया गया है, न कि डॉकरफाइल के स्थान से। तो जैसा कि स्वीकृत उत्तर में कहा गया है: से a: docker build -f a/b/c/Dockerfile . इसका मतलब है कि डॉकरफाइल .में अब फ़ोल्डर हैa

— τ.εηοι 21.εη

Dockerfile डॉक्स से उद्धरण: फ़ाइलों और निर्देशिकाओं के पथ का निर्माण के संदर्भ के स्रोत के सापेक्ष व्याख्या की जाएगी।

— निशांत जॉर्ज अग्रवाल

Answer 5

यदि आप इस मुद्दे पर चर्चा 2745 में पढ़ते हैं, तो न केवल docker कभी भी सहानुभूति का समर्थन नहीं कर सकते हैं वे आपके संदर्भ के बाहर फ़ाइलों को जोड़ने का समर्थन नहीं कर सकते हैं। ऐसा डिज़ाइन दर्शन प्रतीत होता है जो फ़ाइलें जो डॉक बिल्ड में जाती हैं, स्पष्ट रूप से उसके संदर्भ का हिस्सा होना चाहिए या एक URL से होना चाहिए, जहाँ यह निश्चित रूप से एक निश्चित संस्करण के साथ भी तैनात किया जाता है ताकि बिल्ड अच्छी तरह से ज्ञात URL या फ़ाइलों के साथ दोहराए जाने योग्य हो। डॉकटर कंटेनर।

मैं एक संस्करण नियंत्रित स्रोत से निर्माण करना पसंद करता हूं - यानी docker build -t stuff http://my.git.org/repo - अन्यथा मैं यादृच्छिक फ़ाइलों के साथ कुछ यादृच्छिक स्थान से निर्माण कर रहा हूं।

मूल रूप से, नहीं .... - स्वेनडॉइडिट, डॉकटर इंक

बस मेरी राय है लेकिन मुझे लगता है कि आपको कोड को अलग करने और रिपॉजिटरी करने के लिए पुनर्गठन करना चाहिए। इस तरह से कंटेनर सामान्य हो सकते हैं और कोड के किसी भी संस्करण में बिल्ड टाइम के बजाय रन टाइम पर खींच सकते हैं।

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

Comments

आखिर डॉकटर का उपयोग क्यों करें?

— lscoughlin

Answer 6

मेरा मानना ​​है कि सरल संदर्भ में 'संदर्भ' को ही बदलना होगा।

इसलिए, उदाहरण के लिए, देने के बजाय:

docker build -t hello-demo-app .

जो वर्तमान निर्देशिका को संदर्भ के रूप में सेट करता है, मान लें कि आप मूल निर्देशिका को संदर्भ के रूप में चाहते हैं, बस उपयोग करें:

docker build -t hello-demo-app ..

Comments

मुझे लगता है कि यह टूट जाता है। dockerignore: - \

— NullVoxPopuli

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

— सहजाहा

Answer 7

आप यह भी बता सकते हैं कि छवि के लिए सबसे पहले क्या जरूरत है और इसे अपने संदर्भ के रूप में उपयोग करें।

https://docs.docker.com/engine/reference/commandline/build/#/tarball-contexts

Comments

महान टिप! मुझे पता चला कि आप स्टड पर संदर्भ के रूप में टैकर का निर्माण कर सकते हैं tar zc /dir1 /dir2 |docker build -। यह मेरे मामले में बहुत मददगार था।

— टॉर ऑलसेन

Answer 8

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

इसे पूरा करने के लिए आपको docker-compose का उपयोग करने की आवश्यकता नहीं है, लेकिन यह जीवन को थोड़ा आसान बनाता है

# docker-compose.yml

version: '3'
  services:
    stage:
      image: alpine
      volumes:
        - /host/machine/path:/tmp/container/path
      command: bash -c "cp -r /tmp/container/path /final/container/path"
    setup:
      image: stage

# setup.sh

# Start "stage" service
docker-compose up stage

# Commit changes to an image named "stage"
docker commit $(docker-compose ps -q stage) stage

# Start setup service off of stage image
docker-compose up setup

Answer 9

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

Answer 10

जब आप इसे चलाते हैं और इस तरह से फ़ाइलों तक पहुँचते हैं, तो एक आसान समाधान कंटेनर (-v या --mount ध्वज का उपयोग करके) को माउंट करने के लिए हो सकता है।

उदाहरण:

docker run -v /path/to/file/on/host:/desired/path/to/file/in/container/ image_name

अधिक देखने के लिए: https://docs.docker.com/storage/volumes/

Comments

ध्यान दें कि यह केवल तभी काम करता है जब वॉल्यूम एक रनटाइम निर्भरता हो। बिल्ड समय निर्भरता के लिए, docker runबहुत देर हो चुकी है।

— user3735633

Answer 11

जैसा कि इस GitHub मुद्दे में वर्णित है कि निर्माण वास्तव में होता है /tmp/docker-12345, इसलिए जैसा कोई रिश्तेदार मार्ग है, उसी के ../relative-add/some-fileसापेक्ष है /tmp/docker-12345। इस प्रकार यह खोज करेगा/tmp/relative-add/some-file , जो त्रुटि संदेश में भी दिखाया गया है। *

बिल्ड डायरेक्टरी के बाहर से फ़ाइलों को शामिल करने की अनुमति नहीं है, इसलिए इसका परिणाम "निषिद्ध पथ" संदेश है।

Answer 12

एक त्वरित और गंदा तरीका बिल्ड संदर्भ को कई स्तरों तक सेट करना है जितना आपको ज़रूरत है - लेकिन इसके परिणाम हो सकते हैं। यदि आप एक ऐसी माइक्रोसॉफ़्ट आर्किटेक्चर में काम कर रहे हैं जो इस तरह दिखती है:

./Code/Repo1
./Code/Repo2
...

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

एक उदाहरण की स्थिति यह हो सकती है कि कोई अन्य टीम डेटाबेस स्कीमा Repo1और आपकी टीम का कोड बनाए रखती हैRepo2 इस पर निर्भर करता है। आप स्कीमा परिवर्तन या अन्य टीम की रिपॉजिटरी को प्रदूषित करने की चिंता किए बिना अपने स्वयं के कुछ बीज डेटा के साथ इस निर्भरता को कम करना चाहते हैं (इस पर निर्भर करता है कि आप अभी भी अपने बीज डेटा लिपियों को बदल सकते हैं) दूसरा दृष्टिकोण हैक है लेकिन लंबे बिल्ड के मुद्दे के आसपास हो जाता है:

./Code/Repo2उदाहरण के लिए, अपने द्वारा आवश्यक फ़ाइलों को कॉपी करने के लिए एक sh (या ps1) स्क्रिप्ट बनाएँ, उदाहरण के लिए:

#!/bin/bash
rm -r ./db/schema
mkdir ./db/schema

cp  -r ../Repo1/db/schema ./db/schema

docker-compose -f docker-compose.yml down
docker container prune -f
docker-compose -f docker-compose.yml up --build

Docker-compose फ़ाइल में, बस Repo2रूट के ./db/schemaबारे में चिंता किए बिना संदर्भ को रूट के रूप में सेट करें और अपने dockerfile में निर्देशिका की सामग्री का उपयोग करें । ध्यान रखें कि आप इस निर्देशिका को स्रोत नियंत्रण में गलती से करने का जोखिम चलाएंगे, लेकिन सफाई क्रियाओं को स्क्रिप्ट करना काफी आसान होना चाहिए।

Answer 13

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

इसलिए मैं इस फ़ाइल को सीधे निर्दिष्ट नहीं कर सका, लेकिन इसे इस तरह से डॉक करने वाले पाइप में डाल दिया:

sed "s/%email_address%/$EMAIL_ADDRESS/;" ./Dockerfile | docker build -t katzda/bookings:latest . -f -;

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

Answer 14

चाल को पहचानना है कि आप बिल्ड कमांड में संदर्भ निर्दिष्ट कर सकते हैं जिसमें मूल निर्देशिका से फाइलें शामिल करना यदि आप डॉकर पथ निर्दिष्ट करते हैं, तो मैं इस तरह दिखने के लिए अपने डॉकफाइल को बदलूंगा:

...
COPY ./ /dest/
...

फिर मेरी बिल्ड कमांड इस तरह दिख सकती है:

docker built -t TAG -f DOCKER_FILE_PATH CONTEXT

प्रोजेक्ट डायरेक्टरी से

docker built -t username/project[:tag] -f ./docker/Dockerfile .

प्रोजेक्ट / डॉकटर से

docker built -t username/project[:tag] -f ./docker/Dockerfile ..