हाँ, यह मुझे वापस डाल रहा है!

क्या यह आपके fig kill और fig rm बाद काम करता है? मुझे संदेह है कि यह VolumesFrom डॉकिंग बग है: https://github.com/docker/fig/issues/328#issuecomment -50926263

क्या यह आपके fig kill और fig rm बाद काम करता है? मुझे संदेह है कि यह VolumesFrom डॉकिंग बग है: https://github.com/docker/fig/issues/328#issuecomment -50926263

नहीं वास्तव में नहीं,

फ़ाइल के साथ वॉल्यूम का उपयोग करने की कोशिश करते समय यहां एक ही त्रुटि ...

यहां VFS पर काम नहीं करता है:

Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.10.42-xenU-12-e888729-x86_64
Operating System: Ubuntu 14.04 LTS

लेकिन काम करता है यह मेरे व्यक्तिगत कंप्यूटर पर ठीक काम करता है:

$ docker info
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
Execution Driver: native-0.2
Kernel Version: 3.13.0-35-generic
Operating System: Ubuntu 14.04.1 LTS

रिकॉर्ड के लिए, डॉक वर्जन आउटपुट समान है, लेकिन मुझे पूरा यकीन है कि यह इतना महत्वपूर्ण नहीं है क्योंकि मुझे याद है कि यह पूरी तरह से 1.2 में भी काम कर रहा था ...

Client version: 1.3.0
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): c78088f
OS/Arch (client): linux/amd64
Server version: 1.3.0
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): c78088f

इतना ही अंतर है कि मैं हाजिर कर सकते हैं कर्नेल संस्करण है। पहला (जो काम नहीं करता है) एक VFS है, दूसरा मेरा कंप्यूटर है। क्या यह समझने में मदद करता है कि क्या हो रहा है?

हुम, प्रदूषण के लिए खेद है। सरल टाइपो। ऐसा नहीं लगता कि मैं ऐसा करने वाला पहला व्यक्ति हूं।

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

मुझे नहीं लगता कि मेजबान पक्ष पर निर्देशिका बनाने के लिए डॉकटर को अनुमति दी जानी चाहिए। क्या मुझे इस थ्रेड को प्रदूषित करने से बचने के लिए अपनी पिछली टिप्पणी (और यह एक?) हटा देनी चाहिए।

मैं अपने दो सेंट जोड़ूंगा / इस धागे को बांधूंगा। यह docker-compose में एकल फ़ाइलों को जोड़ने में सक्षम होने के लिए सुपर सहायक होगा। अभी मेरे पास मेरे प्रत्येक कंटेनर के लिए एक अलग निर्देशिका होनी चाहिए, लेकिन उनमें से ज्यादातर में केवल 1 या 2 फाइलें हैं। उन सभी को एक ही फ़ोल्डर में रखना बहुत अच्छा होगा और फिर उन्हें व्यक्तिगत रूप से संदर्भित करें।

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

यह एक आवर्ती मुद्दा प्रतीत होता है।

@ Md5 के संदर्भ और अन्य टिप्पणियों के अनुसार, मैं निम्नलिखित परिस्थितियों में इस व्यवहार को ईमानदारी से पुन: पेश कर सकता हूं:

• सेंटोस 7
• डॉकर 1.5.0 (यम पैकेज docker-1.5.0-28.el7.centos)
• डॉकटर-रचना 1.1.0

यह व्यवहार यम पैकेज docker-1.5.0-1.el7 में मौजूद नहीं था।

उदाहरण:

एक साधारण सेवा घोषणा का उपयोग करना:

test:
  image: nginx
  ports:
    - "80:80"
  volumes:
    - sites/test.conf:/etc/nginx/conf.d/default.conf

एक निर्देशिका के बजाय एक फ़ाइल को बांधने के प्रयास में, docker-compose निम्नलिखित का उत्पादन करता है:

docker create_container <- (name=u'webcluster_test_1', image=u'nginx:latest', environment={}, volumes={u'/etc/nginx/conf.d/default.conf': {}}, detach=True, ports=[u'80'])
file exists at %!s(MISSING), can't create volume there

फिर भी, बराबर docker run आदेश सफल होंगे:

docker run --name test -d -p "80:80" \
  -v ${PWD}/sites/test.conf:/etc/nginx/conf.d/default.conf \
  nginx

@dayglojesus आप डॉकर के विकास संस्करण का उपयोग कर रहे हैं।
क्या आप docker version का आउटपुट प्रदान कर सकते हैं?
आपके द्वारा यहां दिया गया त्रुटि संदेश इस प्रतिबद्ध से है: https://github.com/docker/docker/commit/b0ed2da4418d62d2d7b940b49e0e89bdcd264569

यह प्रतिबद्ध डॉकटर के जारी किए गए संस्करण में नहीं है और मास्टर में एक सुधार है, और 1.6 आरसी श्रृंखला का हिस्सा है।

@ cpuguy83 यह रिपोर्ट करता है कि यह संस्करण 1.5.0 है, 1.6 RC नहीं:

Docker version 1.5.0-dev, build fc0329b/1.5.0

यह "आधिकारिक" बिल्ड है जिसे CentOS 7 यम रेपो में उपलब्ध कराया गया है, देव रेपोस के लिए कोई ट्वीक नहीं है।

ऐसा क्यों है कि docker-compose इस व्यवहार को प्रदर्शित करता है और docker run नहीं करता है? क्या यह डॉकर या docker-compose में एक बग है?

मुझे बताएं यदि आपको अधिक जानकारी की जरूरत है।

@dayglojesus हाँ, यह 1.5.0-dev का रिलीज़ किया गया संस्करण नहीं है, कुछ समय बाद docker 1.5.0 के कट जाने के बाद बनाया गया था।
जारीकर्ता के बग में बग मौजूद नहीं है।

@ cpuguy83 मैं देख रहा हूं। अजीब, मुझे आश्चर्य है कि इस पैकेज ने इसे रेपो में कैसे बनाया? क्या आपको पता है कि सेंटम 7 के लिए वास्तविक डोकर 1.5.0 रिलीज के लिए कौन सा यम पैकेज परस्पर संबंधित है?

मुझे यकीन नहीं है ... पिंग @ lsm5

@dayglojesus इसलिए जिसे आपने स्थापित किया है वह RHEL-recompiled docker है जिसमें अपस्ट्रीम docker के शीर्ष पर कुछ redhat पैच हैं। अगर ऐसा कुछ है जिसकी आप परवाह नहीं करते हैं और केवल अपस्ट्रीम डॉकटर के साथ एक आरपीएम चाहते हैं, तो कृपया देखें: http://wiki.centos.org/Cloud/Docker । इसमें एक अतिरिक्त रेपो का उल्लेख किया गया है जिसमें एक आरपीएम है जिसे मैं सेंटोस पुण्य एसआईजी के हिस्से के रूप में अलग से बनाता हूं।

यदि आप वहां rhel सामान की परवाह करते हैं, तो कृपया https://bugzilla.redhat.com पर एक बग दर्ज

इस मुद्दे के लिए एक आरएचईएल टिकट दायर किया। https://bugzilla.redhat.com/show_bug.cgi?id=1209625
धन्यवाद, @ lsm5

Mmm, ubuntu 14.04lts पर docker 1.5 के साथ एक ही चीज मिली

लिनक्स टकसाल / ubuntu पर मेरे लिए होता है, फाइलें बिल्कुल भी मुहिम नहीं की जाती हैं (वे कंटेनर को अधिलेखित करने वाले होते हैं लेकिन न ही)

मेरे पास etc-localtime साथ एक ही मुद्दा है

• लिनक्स अतिथि। Mm 3.13.0-49- जेनेरिक # 81-उबंटू
• x86_64 x86_64 x86_64 GNU / Linux
• विवरण: Ubuntu 14.04.2 LTS
• रिलीज़: 14.04
• कोडनाम: भरोसेमंद
• docker संस्करण 1.5

यदि आपको कोई समस्या हो रही है, तो + 1 मदद नहीं करेगा, खासकर जब से वे ओपी के मुद्दे से संबंधित नहीं हैं।

कृपया शामिल करें कि आप क्या कर रहे हैं, और आप वास्तव में क्या देख रहे हैं, आप क्या देखने की उम्मीद कर रहे हैं।
इसके अलावा docker info और docker version आउटपुट शामिल करें।
धन्यवाद।

@ cpuguy83 ठीक है, यहाँ मेरे मामले के बारे में है:

आदेश:

docker run -d --name webserver -p 80:80 -v ~/www/:/home/site/www/ -v ~/docker/share/apache_logs/:/home/site/logs -v ~/.gitconfig:/home/site/.gitconfig ...

स्थिति: ~ / .gitconfig उस आदेश को निष्पादित करने से पहले मेजबान पर मौजूद नहीं है

क्या होता है: ~ / .itconfig एक dir के रूप में बनता है, जो रूट (वर्तमान उपयोगकर्ता के बजाय) के स्वामित्व में है, और कंटेनर नहीं चलता है, एक संदेश के साथ रुककर ~ / .gitconfig को माउंट करने में सक्षम नहीं है (इसके पूर्ण पथ का उपयोग करके)। पाठ, टिल्ड शॉर्टहैंड नहीं)

मैं क्या देखने की उम्मीद करता हूं: या तो डॉकटर को एक खाली फाइल के रूप में ~ / .conconfig बनाना चाहिए, जो वर्तमान उपयोगकर्ता के स्वामित्व में है, और कंटेनर को सफलतापूर्वक शुरू करें, या बेहतर त्रुटि संदेश के साथ शुरू करने से इनकार करें और बिना ~ / .conconig को बनाए बिना।

docker जानकारी:

user<strong i="14">@ubuntu14server</strong>:~$ docker info
Containers: 5
Images: 153
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 163
Execution Driver: native-0.2
Kernel Version: 3.16.0-30-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 1
Total Memory: 3.847 GiB
Name: ubuntu14server
ID: D52N:QLNG:UE33:N7F3:LZJP:NCF4:6OUS:COOJ:ISL3:2CRK:ZX3U:L3DW
WARNING: No swap limit support
user<strong i="15">@ubuntu14server</strong>:~$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.1
Git commit (client): a8a31ef
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.1
Git commit (server): a8a31ef

@gggeek यहां मुद्दा यह है कि हमारे लिए यह पता लगाने का कोई तरीका नहीं है कि आप एक फ़ाइल चाहते हैं (यह पहले चर्चा की जा चुकी है)।
आपकी स्टार्ट स्क्रिप्ट में मैं आपके docker run कमांड से पहले touch ~/.gitconfig जोड़ने की सलाह दूंगा।

: -D कि मैं क्या कर समाप्त हो गया।
मार्ग 2 के बारे में क्या और फिर फ़ोल्डर बनाने के बारे में नहीं?

@gggeek यह जहाज रवाना हो गया है और दुर्भाग्य से यह एक परिवर्तन होगा।

;-( ओह अच्छा

मेरे पास यह बग Docker version 1.6.0, build 4749651

संबंधित मुद्दा: https://github.com/docker/docker-py/issues/546

मुझे लगता है कि मुझे इस मुद्दे को हल करने से संबंधित एक बात मिली। मैं AWS पर नवीनतम docker-compose (1.20) / docker (1.6.0) का उपयोग करता हूं। और यह त्रुटि हर बार हो रही थी जब मैंने nginx शुरू करने की कोशिश की:

Cannot start container e9586e9e936c9b3991283c676bd071abb92a7b6b3bc0b667cf77a68fa4cc9222: [8] System error: mounting into / is prohibited

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

इसलिए डॉक-कंपोज़ और डॉक सीम के बीच अंतर यह होना चाहिए कि वॉल्यूम के लिए डिफ़ॉल्ट मूल्य क्या है।

मुद्दा बंद कर दिया गया है लेकिन समाधान क्या है?
हमें एक ही समस्या है कि हम फाइल को डॉकटर कंटेनर में माउंट नहीं कर सकते हैं।
विंडोज पर नवीनतम डॉकर टूलबॉक्स संस्करण (docker 1.9)
कंटेनर शुरू होने से अंदर खत्म हो जाता है

Cannot start container XXX: [8] System error: not a directory

एक समाधान के रूप में साशा-एगरिया?

आप जिस समस्या की रिपोर्ट कर रहे हैं वह इस समस्या के समान नहीं है। यह समस्या डॉकटर के पुराने संस्करण में एक बग थी, जिसे बहुत पहले तय किया गया था।

आपकी समस्या # 2268 से संबंधित है? यदि आप docker-compose version , docker info के पूर्ण आउटपुट के साथ उस अंक में पोस्ट कर सकते हैं, तो आपके docker-compose.yml , और आपके द्वारा चलाए गए आदेश, हम आगे डीबग करने में सक्षम हो सकते हैं। समस्या।

मैं आखिरकार डॉकर के साथ काम करने के लिए Git Bash और कमांड "docker- मशीन ssh [MACHINE]" का उपयोग करके अपनी समस्या का समाधान करता हूं।
विंडोज पर डॉकर क्विकस्टार्ट टर्मिनल (1.9d) का नया शेल वास्तव में खराब काम करता है।

मैं एक ही मुद्दा रहा हूँ।
डॉकर-रचना: 1.5.1
डॉकटर: 1.9.1

nginx:
  image: nginx
  links:
   - web
  volumes:
   - .:/code
   - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf <------
  ports:
   - "80:80"

@ jordi12100 यदि आपको कोई निर्देशिका मिल रही है, तो वह फ़ाइल नहीं ढूंढ सकती है।

डॉकटर 1.9.1 में प्रस्तुत server.conf:/etc/server.conf साथ माउंट करने की कोशिश कर रहा है जहां फ़ाइल /etc/server.conf एक छवि में मौजूद है।

एक सापेक्ष पथ का उपयोग कर लगता है कि docker होस्ट फ़ाइल को एक फ़ोल्डर के नाम के रूप में मानता है। चूंकि यह कंटेनर में एक फ़ाइल है और हम मौजूदा फ़ाइल /etc/server.conf लिए एक फ़ोल्डर माउंट नहीं कर सकते, यह विफल रहता है।

server.conf लिए एक निरपेक्ष पथ का उपयोग करना मेरे लिए docker run -v /absolute/path/to/server.conf:/etc/server.conf ... की समस्या को हल करता है और docker सामान्य फ़ाइल के रूप में server.conf व्यवहार करता है।

सापेक्ष पथ . शुरू होने चाहिए, इसलिए ./server.config ।

इसके बिना, इसे एक नामांकित मात्रा माना जाता है।

मेरे पास एक ही मुद्दा है और . साथ भी फ़ाइल माउंट नहीं कर सकता। डॉकर (या docker- रचना?) फ़ाइल को फ़ोल्डर के रूप में मानता है जब तक कि मैं एक पूर्ण फ़ाइल पथ प्रदान नहीं करता।

डॉकटर: 1.9.1
डॉकर-रचना: 1.5.2

डॉकटर-कंपोज़ कार्यों के साथ ./server.conf:/etc/server.conf उपयोग करें। लेकिन डॉकटर CLI का -v विकल्प अवैध पथ के बारे में शिकायत करता है, फ़ाइल के केवल पूर्ण पथ को माउंट किया जाना स्वीकार करता है।

@kirisetsz सही; docker-compose सापेक्ष रास्तों को स्वीकार करता है (जो docker-compose.yml फ़ाइल के सापेक्ष हैं); कम्पोज़ एक रिश्तेदार पथ के निरपेक्ष पथ में रूपांतरण का ख्याल रखेगा। Docker का उपयोग करते समय (रचना नहीं), आपको एक पूर्ण पथ निर्दिष्ट करना होगा। यदि आप संपूर्ण पथ लिखना नहीं चाहते हैं तो आप -v $(pwd)/server.conf:/etc/server.conf उपयोग कर सकते हैं

मैं पुष्टि करता हूं, मेरे पास एक ही मुद्दा है:
Mac OS X.10.11.3
Docker version 1.9.1, build a34a1d5
docker-compose version 1.5.2, build 7240ff3
यहां तक ​​कि अगर मैं एक पूर्ण या रिश्तेदार होस्ट पथ निर्दिष्ट करता हूं, तो मेरे पास एक ही प्रतिक्रिया है:
ERROR: Cannot start container a9ed08a3ee639f61ff2720745011c940a5fff5b9b98bda6a45156a80381c5328: [8] System error: not a directory
जानकारी के लिए:

nginx:
  image: nginx
  ports:
    - 8080:80
    - 8443:443
  volumes_from:
    - application
  volumes:
    - ./SCM/Data/Etc/Configuration/nginx.conf:/etc/nginx/conf.d/default.conf:ro
    - ./LOGS/nginx:/var/log/nginx:rw
  links:
    - fpm

मैं भी इस मुद्दे पर चल रहा हूं

composer:
    image: php7-composer:latest
    working_dir: /data/application
    volumes:
      - ./.composer/cache:/var/composer/cache:rw
      - ./.composer/auth.json:/var/composer/auth.json:rw

इस उदाहरण में Cort.json होस्ट मशीन पर एक निर्देशिका के रूप में बनाया गया है और यह एक फ़ाइल होना चाहिए। अगर मैंने पहली बार host.json पर host.json लगाया है तो यह शिकायत करता है कि यह निर्देशिका नहीं है।

मेरे लिए भी जब मैं कोशिश करता हूं:

मात्रा:
- ./docker/default.conf:/etc/nginx/conf.d/default.nf

मुझे त्रुटि मिलती है: त्रुटि: कंटेनर शुरू नहीं कर सकता 9f ...... f1e: [9] सिस्टम त्रुटि: निर्देशिका नहीं

अगर मैं कुछ और काम करता है, लेकिन यह फ़ाइल के बजाय डिफ़ॉल्ट

विंडोज 10
डॉक वर्जन: 1.10.1
docker-compose संस्करण 1.6.0, cdb920a का निर्माण करें

क्या इस बग को फिर से खोला जा सकता है, कृपया, क्योंकि यह बिना किसी संकल्प के बंद हो गया था? अभी भी हो रहा है। मेरा मामला कई अन्य लोगों के समान है, nginx.conf फ़ाइल को /etc/nginx/nginx.conf के तहत nginx छवि में माउंट करने का प्रयास कर रहा है।

Docker-compose.yml में:

nginx:
  image: "nginx:1.9.7"
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - "./config/nginx.conf:/etc/nginx/nginx.conf:ro"
    - "./config/development-cert.pem:/etc/nginx/cert.pem:ro"
    - "./config/development-key.pem:/etc/nginx/key.pem:ro"

आउटपुट:

$ docker-compose up -d nginx
Starting example_nginx_1
ERROR: Cannot start container 81f4237f3f0e962d8861ca30744bfd78c3b61b4ea5891a19c712c682ecc5142c: [9] System error: not a directory

मैं VMware फ्यूजन प्लगइन (VMware फ्यूजन 8.1.0) और एक कोर होस्ट के साथ एक Vagrant VM का उपयोग करके OS X (10.11.3) पर डॉकर चला रहा हूं। प्रासंगिक संस्करण जानकारी:

$ vagrant -v
Vagrant 1.8.1

$ vagrant plugin list
vagrant-vmware-fusion (4.0.8)

$ docker-compose -v
docker-compose version 1.6.0, build unknown

$ docker info
Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 6
Server Version: 1.10.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.1-coreos
Operating System: CoreOS 970.1.0 (Coeur Rouge)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 2.391 GiB
Name: localhost
ID: 73NW:JIK2:PTGX:3JVG:JZM4:NON4:DXOD:NAUU:UN7Q:T3F5:ZMZG:UWGR
Username: redacted
Registry: https://index.docker.io/v1/

$ docker version
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Fri Feb 12 22:11:40 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   88b8b3a
 Built:
 OS/Arch:      linux/amd64

कृपया मेरी टिप्पणी यहाँ देखें: https://github.com/docker/compose/issues/424#issuecomment -157751229

त्रुटि एक ही दिखाई दे सकती है, लेकिन यह एक अलग मुद्दे के कारण सबसे अधिक संभावना है।

इसके अलावा https://github.com/docker/docker/issues/13670 और https://github.com/docker/docker/issues/19304 देखें।

मैंने ऐसी रिपोर्टें भी सुनी हैं जो आप प्राप्त कर सकते हैं यदि आपके द्वारा निर्धारित कार्यदिवस एक निर्देशिका के रूप में मौजूद नहीं है। मेरा मानना ​​है कि आप इन मुद्दों में से एक को मार रहे हैं।

Https://github.com/brikis98/docker-osx-dev का उपयोग करके

मुझे इस समस्या का सामना करना पड़ा और अपने सभी बालों को बाहर निकालने के बाद पता चला कि फ़ोल्डर रूट-स्वामित्व वाले फ़ोल्डर के लिए एक सहिष्णु था।

(मेरे) उपयोगकर्ता के स्वामित्व वाले फ़ोल्डर में सभी सामग्री ले जाया गया और ठीक काम करता है।

डोकर-1.12.0-rc2
डॉकर-मशीन 0.8.0-आरसी 1
डॉकर-रचना 1.8.0-rc1

यह धागा Google के माध्यम से मिला। मैं इस मुद्दे को भी कर रहा हूँ। मैं सिंगल फाइल, OSX से नहीं बंध सकता।

Docker version 1.12.0-rc4, build e4a0dbc, experimental
docker-compose version 1.8.0-rc2, build c72c966

Docker को आज ही अपडेट किया गया था।

अद्यतन: स्क्रीनशॉट यह निर्देशिका के रूप में माउंट करने का प्रयास दिखा रहा है, फ़ाइल नहीं।

मेरे पास एक ही मुद्दा है :-( एकल फ़ाइल माउंट नहीं कर सकते हैं

Client:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc4
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   e4a0dbc
 Built:        Wed Jul 13 03:28:51 2016
 OS/Arch:      linux/amd64
 Experimental: true

इस मुद्दे की पुष्टि भी

OSX पर आज के अपडेट ने इसे ठीक कर दिया है। मैं डॉकटर-कम्पोज़ का उपयोग करके एक एकल फ़ाइल को सफलतापूर्वक माउंट करने में सक्षम था।

Docker version 1.12.0, build 8eab29e, experimental
docker-compose version 1.8.0, build f3628c7

डॉकटर-कम्पोज़ के साथ फाइल माउंट करने की कोशिश की गई

// docker-compose.yml
version: '2'
services:
  web:
    build: .
    privileged: true
    volumes:
      - "/usr/src/app/app.conf:/etc/app.conf"
    entrypoint: /run.sh

मेजबान मशीन पर

ls /usr/src/app/ -la
total 12
drwxr-xr-x   3 root root 4096 Aug  9 11:08 .
drwxr-xr-x 101 root root 4096 Aug  8 14:16 ..
drwxr-xr-x   2 root root 4096 Aug  9 11:08 app.conf

डॉकर-रचना ने एक डायर बनाया: drwxr-xr-x app.conf
एक फ़ाइल के बजाय।

क्या यह एक सामान्य व्यवहार है? मैं फ़ाइल बनाना और माउंट करना चाहता था।

अगर कोई मुझे स्पष्टीकरण देता है तो मैं बहुत आभारी रहूंगा।

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

@bogulean यदि आप जिस फ़ाइल या निर्देशिका को बाइंड-माउंट करने की कोशिश कर रहे हैं, वह मौजूद नहीं है, तो डॉकटर के पास यह निर्धारित करने का कोई तरीका नहीं है कि आप उस मामले में एक _file_ या _directory_ की उम्मीद कर रहे हैं (यदि /usr/src/app/app.conf नहीं है मौजूद), डॉकमैन डेमन उस स्थान पर एक निर्देशिका बनाता है, और इसे कंटेनर में बांधता है।

ध्यान दें कि हमने पथ के स्वत: निर्माण को हटाने / निकालने (और इसके बजाय एक त्रुटि उत्पन्न करने) का प्रयास किया था, लेकिन यह एक बहुत पिछड़े असंगत परिवर्तन था (कुछ लोग इस व्यवहार पर भरोसा करते हैं), इसलिए हमें इस व्यवहार को बनाए रखना था।

@thaJeztah त्वरित उत्तर के लिए धन्यवाद!
मैंने डॉकटर-कंपोज़ शुरू करने से पहले मैन्युअल रूप से एक फ़ाइल "/usr/src/app/app.conf" बनाने की कोशिश की और परिणाम नीचे है:

ERROR: for web  Cannot start service web: oci runtime error: rootfs_linux.go:53: mounting "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe/etc/app.conf" to rootfs "/var/lib/docker/aufs/mnt/dc65b60b56bae344412f8c23a35f6a19d897b0cad0673bcb9316267ed02a44fe" caused "not a directory"
ERROR: Encountered errors while bringing up the project.

@bogulean आपका सेटअप क्या है? क्या डेमॉन और क्लाइंट दोनों एक ही कंप्यूटर पर चल रहे हैं, या आप एक रिमोट डेमॉन (या वर्चुअल मशीन में चल रहे डेमन) के साथ काम कर रहे हैं?

@thaJeztah मैं DO होस्ट का उपयोग कर रहा हूं, Ubuntu 16.04 LTS,
docker-compose और docker इस पर स्थापित हैं, कृपया नीचे दिए गए संस्करण खोजें:

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Docker version 1.12.0, build 8eab29e
docker-compose version 1.8.0, build f3628c7

सब कुछ इस मशीन पर चल रहा है वहां मैं ssh का उपयोग करके जुड़ा हुआ हूं

Docker को समीकरण से बाहर निकालने की कोशिश करना, क्या आप के साथ पुन: पेश करने की कोशिश कर सकते हैं;

docker run --rm -v /usr/src/app/app.conf:/test/app.conf alpine cat /test/app.conf

जिसे कॉन्फ़िगरेशन फ़ाइल को बांधना चाहिए और उसकी सामग्री को प्रिंट करना चाहिए

docker run -it --rm -v /usr/src/app/app.conf:/test/app.conf alpine sh -c 'cat /test/app.conf'
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
e110a4a17941: Pull complete
Digest: sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a
Status: Downloaded newer image for alpine:latest
Hello from /usr/src/app/app.conf

@thaJeztah मैं कुछ डॉक-कम्पोज़ भी चला सकता हूं। यदि आप इसे परीक्षण के उद्देश्य से मुझे देंगे

@bogulean सही है, इसलिए

version: '2'
services:
  web:
    image: "alpine:latest"
    volumes:
      - "/usr/src/app/app.conf:/test/app.conf"
    command: "cat /test/app.conf"

और अगर यह काम करने की कोशिश करने के लिए;

docker-compose run web

(जिसमें Hello from /usr/src/app/app.conf भी प्रिंट होना चाहिए)

@thaJeztah , बहुत बहुत धन्यवाद! आपका docker-compose.yml Hello from /usr/src/app/app.conf लौटा
जिससे मुझे एहसास हुआ कि मैं दूसरी जगह कुछ गलत कर रहा हूं और मैंने पाया कि मेरे डॉकरीफाइल में एक लाइन थी:
VOLUME ["/usr/src/app.conf"]
इसे हटा दिया और फ़ाइल को उम्मीद के मुताबिक बांधना शुरू कर दिया।

आपके समय के लिए धन्यवाद।

सुनने में अच्छा लगता है, और मदद करने में खुशी होती है!

आपके मामले में समस्या यह है कि VOLUME भी एक निर्देशिका की उम्मीद करती है, इसलिए एक वॉल्यूम बनाया, और /usr/src/app.conf पर माउंट करने का प्रयास किया। मेजबान से एकल फ़ाइलों के साथ काम करने का सबसे अच्छा तरीका आमतौर पर इस स्थिति को ध्यान में रखना है, उदाहरण के लिए, /usr/src/config/ निर्देशिका होने से; फिर आप फ़ाइल के बजाय उस निर्देशिका के लिए बाइंड-माउंट (या वॉल्यूम का उपयोग करें) करेंगे। जाहिर है, हमेशा संभव नहीं

@thaJeztah ,

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 cat filebeat.yml
cat: filebeat.yml: Is a directory

/ निश्चित रूप से छवि / कंटेनर में मौजूद है:

docker run -v $(pwd)/filebeat.yml:/filebeat.yml prima/filebeat:1.2 ls -al
drwxr-xr-x   2 root root   40 Aug  9 20:46 filebeat.yml

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

कोई विचार? आपका बहुत बहुत धन्यवाद!

मैंने अल्पाइन छवि के साथ आपके उदाहरण की भी कोशिश की है। वही। cat: read error: Is a directory

@thasmo आपको यह त्रुटि मिल रही है क्योंकि filebeat.yml एक निर्देशिका है, न कि फ़ाइल।
आपको यह सुनिश्चित करना होगा कि फ़ाइल को कंटेनर में माउंट करने की कोशिश करने से पहले होस्ट पर मौजूद है, अन्यथा docker आपके लिए एक निर्देशिका बनाएगा।

@ cpuguy83 , मुझे लगता है कि मुझे सिर्फ समस्या मिली। मैं डॉकर मशीन और वर्चुअलबॉक्स के माध्यम से विंडोज पर डॉकटर का उपयोग कर रहा हूं और यह संभवत: वर्चुअलबॉक्स के माध्यम से कंटेनर में स्थानीय फाइल को माउंट नहीं कर सकता।
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem- साझा करना

मैंने पाया है कि विंडोज 10 एनिवर्सरी अपडेट पर क्लीन इंस्टाल डॉक पर समस्या।
वास्तव में, यह समस्या बहुत ही सरल उपाय है

डॉकर विकल्पों में ड्राइव शेयर की जरूरत है http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
लगता है और समस्या हल करती है।

Ubuntu 16.10 पर अभी भी समस्या है

➜  gi_proxy git:(master) ✗ docker -v
Docker version 1.12.3, build 6b644ec

docker run --name hap ... -v /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf:/etc/resolv.conf

docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:359: container init caused \\\"rootfs_linux.go:53: mounting \\\\\\\"/home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf\\\\\\\" to rootfs \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713\\\\\\\" at \\\\\\\"/mnt/sda1/var/lib/docker/aufs/mnt/34ee49dcff906310df08b5a0bdf02ebafd302c1c7bf8b81ecd2778757fdb5713/etc/resolv.conf\\\\\\\" caused \\\\\\\"not a directory\\\\\\\"\\\"\"\n".

अगर मैंने docker को एक फाइल पर माउंट करने के लिए चलाया जो कि doesn't / tmp / foo की तरह मौजूद है, लेकिन यह एक डायरेक्टरी को mounts करता है।

@djpate क्या आपका होस्ट एक ही होस्ट पर काम कर रहा है (और वर्चुअल मशीन में नहीं?)। यदि /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf उस मशीन पर मौजूद नहीं है जिस पर docker डेमन चल रहा है, तो डेमन उस नाम के साथ एक _directory_ बनाएगा, और कंटेनर के अंदर /etc/resolv.conf पर इसे बांधने का प्रयास करेगा। चूँकि /etc/resolv.conf एक _file_ है, किसी फ़ाइल के शीर्ष पर बाइंड-माउंटिंग निर्देशिका विफल हो जाएगी।

यह कहने के बाद कि, मैं एक स्थानीय फ़ाइल के साथ /etc/resolv.conf को ओवरराइड दृढ़ता से हतोत्साहित करूँगा; /etc/resolv.conf का उपयोग करने के लिए सही DNS सर्वर सेट करने के लिए docker द्वारा प्रबंधित किया जाता है। डॉकर में सेवा की खोज के लिए एक एम्बेडेड डीएनएस सर्वर है, इसलिए उस फाइल को ओवरराइड करने से सेवा की खोज काम नहीं करेगी।

यदि आप DNS विकल्प सेट करना चाहते हैं, तो --dns , --dns-opt और --dns-search docker run --dns-search विकल्पों का उपयोग करें;

--dns value                   Set custom DNS servers (default [])
--dns-opt value               Set DNS options (default [])
--dns-search value            Set custom DNS search domains (default [])

यह अप्रत्याशित परिणाम पैदा किए बिना उन विकल्पों को निर्धारित करेगा। ध्यान दें कि कंटेनर के अंदर DNS हमेशा 127.0.0.11 (एम्बेडेड DNS सर्वर) होगा, लेकिन वह सर्वर स्वचालित रूप से DNS सर्वर के लिए अनुरोध करता है जिसे आप --dns साथ निर्दिष्ट करते हैं।

@thaJeztah मैं नया करने वाला हूं लेकिन मुझे लगता है कि यह मेरी मशीन पर चल रहा है। मैंने मूल रूप से नियमित ubuntu स्थानीय मशीन पर डॉक-इंजन और डॉक-मशीन स्थापित किया है। यह मेरी कंपनी का देव एनवी है और मैक डॉकटर पर सभी के लिए काम करता है।

मैं इसे डीएनएस विकल्प में बदल दूंगा जैसे आपने उल्लेख किया था, मैं इससे अनजान था। धन्यवाद! लेकिन बग अभी भी मुझे लगता है कि वहाँ है।

यह मेरे लिए docker-compose v1.6.2 और docker v1.10.2 पर काम नहीं कर रहा है :(

निरपेक्ष पथ काम करता है, लेकिन दुर्भाग्य से मेरे उपयोग के मामले के लिए पूर्ण पथ बिल्कुल काम नहीं करेगा :(। मैंने ./ और ../ प्रत्येक संयोजन की कोशिश की है जिसके बारे में मैं सोच सकता हूं।

संपादित करें: इसके अलावा मैं लिनक्स पर बिना वीएम के चल रहा हूं, इसलिए @thaJeztah समाधान मेरे लिए काम नहीं करता है

OS उबंटू 14.04 है

डॉकर अब 1.13.1 तक है। कृपया अपने डॉकर को अपग्रेड करें। 1.12.x के बाद से यह काम कर रहा है।

आह आपका धन्यवाद। Docker को अपग्रेड करेगा और अगर / तय होने पर अपडेट करेगा :)

संपादित करें: काम किया! साभार @guice

@thaJeztah

यदि आप जिस फ़ाइल या निर्देशिका को बाइंड-माउंट करने का प्रयास कर रहे हैं, वह मौजूद नहीं है, तो डॉकटर के पास यह निर्धारित करने का कोई तरीका नहीं है कि आप किसी फ़ाइल या निर्देशिका की अपेक्षा कर रहे हैं, यदि उस स्थिति में (/usr/src/app/app.conf doesn 'टी अस्तित्व), डॉकमैन डेमन उस स्थान पर एक निर्देशिका बनाता है, और इसे कंटेनर में बांधता है।
ध्यान दें कि हमने पथ के स्वत: निर्माण को हटाने / निकालने (और इसके बजाय एक त्रुटि उत्पन्न करने) का प्रयास किया था, लेकिन यह एक बहुत पिछड़े असंगत परिवर्तन था (कुछ लोग इस व्यवहार पर भरोसा करते हैं), इसलिए हमें इस व्यवहार को बनाए रखना था।

मैं वास्तव में इस उपयोग-मामले की कोशिश करने के छह घंटे के बाद काफी निराश हूं और अब यह पता लगाना असंभव है।
वॉल्यूम डिक्लेरेशन में "फाइल फ़्लैग" जैसा कुछ क्यों नहीं जोड़ा गया है, इस पर विचार करते हुए हम :ro और :rw जैसे अतिरिक्त बढ़ते विकल्प निर्दिष्ट कर सकते हैं?

volumes:
  - "./config.json:/app/config.json:rwf"

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

@malyzeli आप इस तरह से कॉन्फ़िगर करने के लिए एक रहस्य के रूप में या स्टार्टअप पर
वॉल्यूम वास्तव में दृढ़ता के लिए डिज़ाइन किए गए हैं, न कि कॉन्फ़िगरेशन के लिए।
वास्तव में डॉकटर को ऑटो-होस्ट होस्ट पथ नहीं बनाना चाहिए, और नए APIs पर यह व्यवहार हटा दिया गया है।

@ cpuguy83

मुझे आपकी बात समझ में नहीं आ रही है, इसलिए कृपया मेरी मान्यताओं को स्पष्ट करें या सही करें, क्योंकि मैं डॉकर पारिस्थितिकी तंत्र के लिए काफी नया हूं।

आप रहस्यों को इस तरह से इंजेक्ट करने के तरीके के रूप में देख सकते हैं, या स्टार्टअप पर अस्थायी कर सकते हैं।

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

वॉल्यूम वास्तव में दृढ़ता के लिए डिज़ाइन किए गए हैं, न कि कॉन्फ़िगरेशन के लिए।

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

वास्तव में डॉकटर को ऑटो-होस्ट होस्ट पथ नहीं बनाना चाहिए, और नए APIs पर यह व्यवहार हटा दिया गया है।

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

डॉक रन कमांड किसी भी डेटा के साथ नए बनाए गए वॉल्यूम को आरंभ करता है जो आधार छवि के भीतर निर्दिष्ट स्थान पर मौजूद है।

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

इसे बनाने दें, छवि / कंटेनर से निकालें, इसका एक रहस्य बनाएं

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

रहस्यों का उपयोग करें। हम एक समर्पित config ऑब्जेक्ट को भी देख रहे हैं जो रहस्यों के समान है, बस इतना प्रतिबंधित नहीं है ... लेकिन आज रहस्य वही हैं जो उपलब्ध हैं।

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

बाइंड माउंट्स वॉल्यूम नहीं हैं। Dockerfile संदर्भ संस्करणों के बारे में बात कर रहा है। यह दुर्भाग्यपूर्ण है कि दोनों के लिए docker run -v का उपयोग किया जाता है।

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

होस्ट बाइंड्स किसी भी चीज़ के लिए एक बुरा समाधान है जो होस्ट पर पहले से मौजूद कुछ चीज़ों को लेने और इसे कंटेनर में लाने के लिए है ... और तब भी आम तौर पर काम नहीं किया जाता है जब आप गुच्छेदार वातावरण के बारे में बात कर रहे होते हैं।

@ cpuguy83

इसे बनाने दें, छवि / कंटेनर से निकालें, इसका एक रहस्य बनाएं

हाँ, यह वही है जो मैं करता हूँ, लेकिन यह कष्टप्रद जटिल लगता है वैसे भी .. :-)

रहस्यों का उपयोग करें। हम एक समर्पित config ऑब्जेक्ट को भी देख रहे हैं जो रहस्यों के समान है, बस इतना प्रतिबंधित नहीं है ... लेकिन आज रहस्य वही हैं जो उपलब्ध हैं।

मैं इस पर गौर करूंगा, रहस्यों के बारे में नहीं जानता, धन्यवाद!

बाइंड माउंट्स वॉल्यूम नहीं हैं। Dockerfile संदर्भ संस्करणों के बारे में बात कर रहा है। यह दुर्भाग्यपूर्ण है कि दोनों के लिए docker run -v का उपयोग किया जाता है।

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

विंडोज में इस बग को देखने वालों के लिए ... भले ही आपके पास ड्राइव्स शेयर्ड हों ...

एक मुद्दा है जहाँ अगर आप डॉक विंडोज (डॉकटर-कम्पोज़ के साथ) का उपयोग करते हैं और कुछ साख का उपयोग करते हैं तो "शेयर ड्राइव" जैसे कि सी: \ या डी: \ आदि का उपयोग करें, आपको अनशेयर करना पड़ सकता है, ड्राइव को फिर से साझा करें, फिर से दर्ज करें क्रेडेंशियल्स, अन्यथा यह आपको एक त्रुटि संबंधित देता है जैसे:

"त्रुटि: के लिए ... सेवा आपकी सेवा शुरू नहीं कर सकती: oci रनटाइम त्रुटि: कंटेनर_लिनक्स.गो: 262: कंटेनर प्रक्रिया शुरू करने का कारण" प्रक्रिया_लिनक्स.गो: 339: कंटेनर "के कारण \" rootfs_linux.go .go: 57: बढ़ते \ "है

"\" का कारण \\ "नहीं एक निर्देशिका \" "
: क्या आप एक फ़ाइल (या इसके विपरीत) पर एक निर्देशिका को माउंट करने की कोशिश कर रहे हैं? जांचें कि क्या निर्दिष्ट होस्ट पथ मौजूद है और अपेक्षित प्रकार है "

BaranOrnarli वह कैसे हो सकता है जिसके पास DockerToolbox है?

यहाँ पर अधिकांश लोगों के समान ही मुद्दा। लेकिन मुझे वीएम को पुनः आरंभ करके फिर से काम करना पड़ा।

विंडोज 10 शिक्षा
डॉकर टूलबॉक्स, 17.10.0-सी.ई.
वर्चुअलबॉक्स 5.2.2

Docker CLI के माध्यम से इसे चलाना काम करता है:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf ट्यूटोरियल / nginx

Docker- रचना के माध्यम से ही चल रहा है, नहीं:
धज्जी
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
यही है, जब तक कि मैं VMBox को VirtualBox GUI के माध्यम से बंद कर दूं और डॉकर क्विकार्टार्ट टर्मिनल को फिर से शुरू कर दूं।

तब से, बार-बार कंटेनरों को नष्ट करने और डॉक-कंपोज करने में त्रुटि नहीं हुई।

आशा है कि यह किसी की मदद करता है।

मेरी भी यही समस्या है। इस बीच में मैं वास्तविक संस्करणों docker फ़ोल्डर का उपयोग कर रहा हूँ docker-compose.yml। यह अस्थायी वर्कअराउंड के रूप में /var/lib/docker/volumes…/file.ext है
(डॉकर संस्करण 17.12.0-सीइ, बिल्ड c97c6d6)

यदि आपके पास ऐसा कोई मुद्दा है, तो यह भी जांचें कि क्या आपने अपनी निर्देशिका विंडोज पर साझा की है।

Ubuntu 14.04 पर Im। जब मैं docker-compose up -d कमांड चलाता हूं, तो मैं निम्नलिखित त्रुटि करता हूं:

ERROR: for frontend Cannot start service frontend: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"rootfs_linux.go:58: mounting \\\"/home/curso-docker/email-worker-compose/nginx/default.conf\\\" to rootfs \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6\\\" at \\\"/var/lib/docker/aufs/mnt/ffc214cd493c376554125473ba95e8cd918cd3ad73b6aa8292f51ce84beca8a6/etc/nginx/conf.d/default.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

मैं अपने मेजबान से वॉल्यूम /home/curso-docker/email-worker-compose/nginx/default.conf के नक्शे के लिए निरपेक्ष पथ का उपयोग कर रहा हूं।

किसी को इस समस्या के बारे में पता है?

@AzeredoGabriel मेरे लिए, @BaranOrnarli ने एक आकर्षण की तरह काम करने से पहले जो उल्लेख किया था। अपने साझा किए गए ड्राइव के लिए क्रेडेंशियल्स रीसेट करें, इसे फिर से साझा करें, और इसे काम करना चाहिए। पता नहीं क्यों यह अचानक पहली जगह में काम करना बंद कर देता है, लेकिन अब यह फिर से है।

इस पर कोई भी समाचार? यह अभी भी एक फ़ाइल को माउंट करने के लिए असंभव लगता है

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

इस पर कोई भी समाचार? यह अभी भी एक फ़ाइल को माउंट करने के लिए असंभव लगता है

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

@ cpuguy83 बेशक यह एक समस्या है। हम एक निर्देशिका में फाइल माउंट करने की कोशिश नहीं कर रहे हैं। हम कंटेनर द्वारा होस्ट की गई एक फ़ाइल को फ़ाइल के रूप में माउंट करने का प्रयास कर रहे हैं।

क्या हम इस मुद्दे को फिर से खोल सकते हैं? अभी भी 2019 के रूप में काम नहीं कर रहा है। नवीनतम डेकर और नवीनतम डेबियन पर नवीनतम डॉकटर-कम्पोज चल रहा है।

आप कंटेनर से मेजबान तक नहीं जा सकते, केवल दूसरे तरीके से।
यह निर्देशिका और फ़ाइलों दोनों के लिए समान व्यवहार है।

एक ही मुद्दा, docker 19.03.1 और docker-compose 1.24.1 का उपयोग करते हुए, डॉक-कंपोज़.माइल में वॉल्यूम बाइंडिंग के साथ store/elastic/filebeat:7.3.0 छवि में एक कॉन्फिगर फाइल को ओवरराइड करने की कोशिश करते हुए:

    volumes:
      - ${PWD}/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro

ERROR: for docker_filebeat_1 Cannot start service filebeat: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/filebeat.yml\\\" to rootfs \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged\\\" at \\\"/var/lib/docker/overlay2/f49a0ae0ec6646c818dcf05dbcbbdd79fc7c42561f3684fbb1fc5d2b9d3ad192/merged/usr/share/filebeat/filebeat.yml\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

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

वही मुद्दा

$ ls -l logstash.conf
-rw-r--r--  1 lubumbax  staff  164 Apr 30 18:01 logstash.conf
$ pwd
/Users/lubumbax/Src/Java/elk

$ docker run -it --name logstash -p 5000:5000 \
             -v "$(pwd)/logstash.conf:/usr/share/logstash/pipeline/logstash.conf" \
             docker.elastic.co/logstash/logstash:7.6.2

परिणाम:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/Users/lubumbax/Src/Java/elk/logstash.conf\\\" to rootfs \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged\\\" at \\\"/var/lib/docker/overlay2/bad85f1a2984bed23619fdf401cc9655573bb1799a8b681d371f5964201b9a82/merged/usr/share/logstash/pipeline/logstash.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.14
 Git commit:        afacb8b
 Built:             Thu Mar 12 02:45:41 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 01:30:32 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

यह तय करने का कोई मौका?

कष्टप्रद मुद्दा।

सहकर्मी, डॉकटर-रचना में माउंट दिशा की जाँच करें।
मुझे वही समस्याएं मिलीं जब तक मुझे एहसास नहीं हुआ कि मैं गलत था, ऐसा होना चाहिए:

...
    volumes:
      - /host/file:/docker/file:ro
...