نعم ، هذا يعيدني!

هل تعمل بعد fig kill و fig rm ؟ لدي شك في أنه خطأ في Docker VolumesFrom : https://github.com/docker/fig/issues/328#issuecomment -50926263

هل تعمل بعد fig kill و fig rm ؟ لدي شك في أنه خطأ في Docker 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 بإنشاء أدلة على الجانب المضيف. هل يجب حذف تعليقي السابق (وهذا التعليق؟) لتجنب تلويث هذا الموضوع؟

سأضيف سنتي / نتوء هذا الموضوع. سيكون من المفيد جدًا أن تكون قادرًا على إضافة ملفات فردية في docker-compose . في الوقت الحالي ، يجب أن يكون لدي دليل منفصل لكل حاوية من حاوياتي ولكن معظمها يحتوي على ملف واحد أو ملفين فقط. سيكون من الرائع وضعهم جميعًا في نفس المجلد ثم الرجوع إليهم كل على حدة.

أعتقد أنه كان هناك خطأ في مرحلة ما حول عمل وحدات التخزين - والتي تضمنت ملفات مثبتة.
لا أعتقد أن هذه مشكلة اليوم.

يبدو أن هذه مشكلة متكررة.

وفقًا لمرجع @ md5 وتعليقات أخرى ، يمكنني إعادة إنتاج هذا السلوك بأمانة في ظل الظروف التالية:

• CentOS 7
• Docker 1.5.0 (yum package docker-1.5.0-28.el7.centos)
• عامل تركيب 1.1.0

لم يكن هذا السلوك موجودًا في حزمة yum 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

هذا الالتزام ليس في إصدار تم إصداره من Docker وله إصلاح رئيسي ، وهو جزء من سلسلة 1.6 RC.

@ cpuguy83 تفيد بأن هذا هو الإصدار 1.5.0 وليس 1.6 RC:

Docker version 1.5.0-dev, build fc0329b/1.5.0

هذا هو الإصدار "الرسمي" المتوفر في CentOS 7 yum repos ، ولا توجد تعديلات على repos dev.

لماذا يظهر هذا docker-compose هذا السلوك و docker run لا؟ هل هذا خطأ في Docker أو docker-compose ؟

اسمحوا لي أن أعرف إذا كنت بحاجة إلى مزيد من المعلومات.

dayglojesus نعم ، هذه ليست نسخة تم إصدارها من عامل التحميل 1.5.0-dev تم بناؤه في وقت ما بعد قطع عامل التحميل 1.5.0.
الخطأ غير موجود في إصدار تم إصداره من عامل الإرساء.

@ cpuguy83 فهمت. غريب ، أتساءل كيف وصلت هذه الحزمة إلى الريبو؟ هل تعرف أي حزمة yum ترتبط بإصدار Docker 1.5.0 الفعلي لـ CentOS 7؟

لست متأكدًا ... ping @ lsm5

dayglojesus ، لذا فإن الذي قمت بتثبيته هو عامل http://wiki.centos.org/Cloud/Docker . يذكر هذا الريبو الإضافي الذي يحتوي على عدد دورات في الدقيقة أقوم ببنائه بشكل منفصل كجزء من CentOS Virt SIG.

إذا كنت تهتم بالأشياء الموجودة هناك ، فيرجى الإبلاغ عن الخطأ على https://bugzilla.redhat.com . HTH

قدم بطاقة RHEL لهذه المشكلة. https://bugzilla.redhat.com/show_bug.cgi؟id=1209625
شكرا @ lsm5.

Mmm ، حصلت على نفس الشيء على Ubuntu 14.04lts مع Docker 1.5

يحدث لي على linux mint / ubuntu ، لم يتم تثبيت الملفات على الإطلاق (من المفترض أن تكتب فوق الحاوية ولكنها لا تفعل ذلك)

لدي نفس المشكلة مع etc-localtime

• Linux guest.vm 3.13.0-49-generic # 81-Ubuntu
• x86_64 x86_64 x86_64 جنو / لينكس
• الوصف: Ubuntu 14.04.2 LTS
• الإصدار: 14.04.2019
• الاسم الرمزي: مضمون
• إصدار عامل ميناء 1.5

إذا كنت تواجه مشكلة ، فلن تساعدك إجراءات 1+ ، خاصةً لأنها على الأرجح غير مرتبطة على الإطلاق بمشكلة OP.

يرجى تضمين قائد عامل الإرساء الذي تقوم بتشغيله ، وما تتوقع رؤيته ، وما تراه بالفعل.
قم أيضًا بتضمين ناتج 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 غير موجود على المضيف قبل تنفيذ هذا الأمر

ماذا يحدث: يتم إنشاء ~ / .gitconfig على هيئة dir ، مملوكة لجذر (بدلاً من المستخدم الحالي) ، ولا تعمل الحاوية ، وتتوقف برسالة حول عدم القدرة على تحميل ~ / .gitconfig (باستخدام المسار الكامل في النص ، وليس اختصار التلدة)

ما أتوقع رؤيته: يجب على عامل الإرساء إنشاء ~ / .gitconfig كملف فارغ ، مملوك للمستخدم الحالي ، وبدء تشغيل الحاوية بنجاح ، أو رفض البدء برسالة خطأ أفضل وبدون إنشاء الملف ~ / .gitconfig على الإطلاق

معلومات عامل الميناء:

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 المشكلة هنا أنه لا توجد طريقة لنا لاكتشاف أنك تريد ملفًا (تمت مناقشة هذا من قبل).
في البرنامج النصي للبدء ، أوصي بإضافة touch ~/.gitconfig قبل الأمر docker run .

:-D هذا ما انتهى بي الأمر.
ماذا عن اتخاذ الطريق 2 ثم عدم إنشاء المجلد؟

gggeek لقد أبحرت تلك السفينة وستكون بمثابة تغيير كبير ، لسوء الحظ.

؛-( اوه حسنا

لدي هذا الخطأ مع Docker version 1.6.0, build 4749651

المشكلة ذات الصلة: https://github.com/docker/docker-py/issues/546

أعتقد أنني وجدت شيئًا واحدًا يتعلق بحل هذه المشكلة. أستخدم أحدث عامل إنشاء (1.20) / عامل ميناء (1.6.0) على AWS. وكنت أتلقى هذا الخطأ في كل مرة حاولت فيها بدء nginx:

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

بدافع اليأس ، نظرت إلى ملف nginx Dockerfile ورأيت أنه يعرض مجلدًا واحدًا. لذلك أضفت هذا المجلد إلى القائمة التي قمت بتثبيتها وفجأة نجح كل شيء!

لذا فإن الاختلاف بين طبقات عامل الإرساء والتركيب والرسو هو القيمة الافتراضية للأحجام.

تم إغلاق القضية ولكن ما الحل؟
لدينا نفس المشكلة التي لا يمكننا تحميل الملفات إلى حاوية عامل إرساء.
أحدث إصدار Docker Toolbox (docker 1.9) على Windows
بدء تشغيل الحاوية ينتهي

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

مثل Sascha-Egeria ، حل؟

المشكلة التي تبلغ عنها ليست هي نفسها هذه المشكلة. كانت هذه المشكلة عبارة عن خطأ في الإصدار السابق من Docker ، والذي تم إصلاحه منذ وقت طويل.

ربما تبدو مشكلتك متعلقة بـ # 2268؟ إذا كان بإمكانك النشر في هذه المشكلة بإخراج كامل docker-compose version ، docker info ، ومحتويات docker-compose.yml ، والأوامر التي نفذتها ، فقد نتمكن من إجراء المزيد من التصحيح المشكلة.

أخيرًا قمت بحل مشكلتي باستخدام Git Bash والأمر "docker-machine ssh [MACHINE]" للعمل مع Docker.
إن الغلاف الجديد لـ Docker Quickstart Terminal (1.9d) على Windows يعمل بشكل سيء حقًا.

لدي نفس المشكلة.
تركيب عامل السفن: 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 إذا كنت تحصل على دليل ، فلن يتمكن من العثور على الملف.

تم إعادة إنتاجه في Docker 1.9.1 في محاولة للتركيب مع server.conf:/etc/server.conf حيث يوجد الملف /etc/server.conf في الصورة.

يبدو أن استخدام مسار نسبي يجعل عامل التحميل يعتبر ملف المضيف اسمًا لمجلد. نظرًا لأنه ملف في حاوية ولا يمكننا تحميل مجلد إلى ملف موجود /etc/server.conf ، فإنه يفشل.

يؤدي استخدام المسار المطلق إلى server.conf إصلاح المشكلة بالنسبة لي docker run -v /absolute/path/to/server.conf:/etc/server.conf ... ويعامل عامل الإرساء server.conf كملف عادي.

يجب أن تبدأ المسارات النسبية بـ . ، لذا جرب ./server.config .

بدونه ، يعتبر مجلدًا مسمىًا.

لدي نفس المشكلة ولا يمكنني تحميل الملف حتى مع . . يعتبر Docker (أو docker-compose؟) الملف كمجلد إلا إذا قمت بتوفير مسار ملف مطلق.

عامل ميناء: 1.9.1
تركيب عامل السفن: 1.5.2

استخدم ./server.conf:/etc/server.conf مع أعمال إنشاء عامل الإرساء. لكن خيار docker CLI -v يشكو من المسار غير القانوني ، ولا يقبل سوى المسار المطلق للملف المراد تحميله.

kirisetsz صحيح ؛ يقبل docker-compose المسارات النسبية (المتعلقة بالملف docker-compose.yml ) ؛ ستهتم عملية الإنشاء بتحويل المسار النسبي إلى مسار مطلق. عند استخدام عامل الإرساء (لا يؤلف) ، يجب عليك تحديد مسار مطلق. يمكنك استخدام -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

في هذا المثال ، يتم إنشاء auth.json كدليل على الجهاز المضيف ويجب أن يكون ملفًا. إذا وضعت auth.json لأول مرة على الجهاز المضيف ، فإنه يشتكي من أنه ليس دليلًا.

بالنسبة لي أيضًا عندما أحاول:

أحجام:
- ./docker/default.conf:/etc/nginx/conf.d/default.conf

لقد تلقيت خطأ: خطأ: لا يمكن بدء الحاوية 9f ...... f1e: [9] خطأ في النظام: ليس دليل

إذا قمت بتغيير conf.d إلى شيء آخر ، فإنه يعمل ولكن يتم تحميله كمجلد بدلاً من ملف

نظام التشغيل Windows 10
إصدار عامل ميناء: 1.10.1
إصدار docker-compose 1.6.0 ، بناء cdb920a

هل يمكن إعادة فتح هذا الخطأ ، من فضلك ، لأنه تم إغلاقه بدون حل؟ ما زال يحدث. حالتي مماثلة للعديد من الحالات الأخرى ، أحاول تحميل ملف nginx.conf في صورة nginx ضمن /etc/nginx/nginx.conf.

في 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

أقوم بتشغيل Docker على OS X (10.11.3) باستخدام Vagrant VM مع المكون الإضافي VMware Fusion (VMware Fusion 8.1.0) ومضيف CoreOS. معلومات الإصدار ذات الصلة:

$ 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.

لقد سمعت أيضًا تقارير تفيد أنه يمكنك الحصول على هذا إذا كان Workdir الذي قمت بتعيينه غير موجود كدليل. أعتقد أنك تتعامل مع إحدى هذه القضايا.

جرب استخدام https://github.com/brikis98/docker-osx-dev

لقد واجهت هذه المشكلة وبعد سحب كل شعري اكتشفت أن المجلد كان رابطًا رمزيًا لمجلد مملوك للجذر.

تم نقل جميع المحتويات إلى المجلد المملوك للمستخدم (الخاص بي) ويعمل بشكل جيد.

دوكر 1.12.0-rc2
آلة دوكر 0.8.0-rc1
عامل تركيب 1.8.0-rc1

وجدت هذا الموضوع عبر جوجل. أواجه هذه المشكلة أيضًا. لا يمكنني الارتباط بملفات مفردة ، 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-compose.

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

قام Docker-compose بإنشاء dir: 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 إذا كان الملف أو الدليل الذي تحاول /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 host ، Ubuntu 16.04 LTS ،
docker-compose and 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 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 يمكنني أيضًا تشغيل بعض docker-compose.yml إذا كنت ستعطيها لي لأغراض الاختبار

bogulean right ، لذا يبدو أن هناك مشكلة في ببنائها / تشغيلها. سيكون هذا مكافئًا للاختبار السابق ، ولكن بعد ذلك من خلال عامل البناء ؛

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 ، شكرا جزيلا! أعاد عامل التحميل compose.yml Hello from /usr/src/app/app.conf
جعلني ذلك أدرك أنني أفعل شيئًا خاطئًا في مكان آخر ووجدت أن هناك سطرًا في Dockerfile الخاص بي:
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

يبدو أنه خطأ Docker بشكل عام ، ولا علاقة له بـ Docker Compose.
لست متأكدًا من سبب قيام Docker بإنشاء دليل في هذه الحالة.

أيه أفكار؟ شكرا جزيلا!

لقد جربت أيضًا مثالك مع صورة جبال الألب. نفسه. cat: read error: Is a directory

thasmo يظهر لك هذا الخطأ لأن filebeat.yml هو دليل وليس ملف.
يجب عليك التأكد من وجود الملف على المضيف قبل محاولة تحميله في الحاوية ، وإلا فسيقوم عامل الإرساء بإنشاء دليل لك.

@ cpuguy83 ، أعتقد أنني وجدت المشكلة للتو. أنا أستخدم Docker على Windows عبر Docker Machine و VirtualBox ومن المحتمل ألا يتمكن من تحميل الملف المحلي عبر VirtualBox في الحاوية.
https://docs.docker.com/docker-for-windows/troubleshoot/#/host -filesystem-sharing

لقد وجدت هذه المشكلة في عامل التثبيت النظيف على تحديث الذكرى السنوية لنظام التشغيل Windows 10.
في الواقع ، هذه المشكلة هي حل بسيط للغاية

يحتاج إلى مشاركة محركات الأقراص في خيارات عامل الإرساء http://www.awesomescreenshot.com/image/1510321/0f1a81d7a8883df5a61bcdf04b3994cf
يبدو يجد ويحل المشكلة.

لا تزال تواجه المشكلة في ubuntu 16.10

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

تشغيل عامل الإرساء --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 run للتركيب على ملف غير موجود مثل / tmp / foo فإنه يعمل ولكنه يقوم بتحميل دليل.

djpate هل /home/cverbinnen/src/unisporkal/gi_proxy/dev-resolv.conf موجودًا على الجهاز الذي يعمل عليه برنامج Docker daemon ، فسيقوم البرنامج الخفي بإنشاء _directory_ بهذا الاسم ومحاولة ربطه عند /etc/resolv.conf داخل الحاوية. نظرًا لأن /etc/resolv.conf هو ملف _file_ ، فإن ربط دليل أعلى الملف سيفشل.

بعد قولي هذا ، لا أنصح بشدة بتجاوز /etc/resolv.conf بملف محلي ؛ /etc/resolv.conf بواسطة عامل الإرساء لتعيين خادم DNS الصحيح للاستخدام. يحتوي Docker على خادم DNS مضمن لاكتشاف الخدمة ، لذا فإن تجاوز هذا الملف سيؤدي إلى عدم عمل اكتشاف الخدمة.

إذا كنت تريد تعيين خيارات DNS ، فاستخدم الخيارات --dns و --dns-opt و --dns-search على docker run ؛

--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 أنا جديد في عامل

سوف أقوم بتغييره إلى خيار DNS كما ذكرت ، لم أكن على علم بذلك. شكرا لك! لكن الخطأ لا يزال موجودًا على ما أعتقد.

هذا لا يعمل بالنسبة لي سواء على docker-compose v1.6.2 و docker v1.10.2 :(

يعمل استخدام المسارات المطلقة ، ولكن لسوء الحظ لن تعمل المسارات المطلقة لحالة الاستخدام الخاصة بي على الإطلاق :(. لقد جربت كل مجموعة من ./ و ../ يمكنني التفكير فيها.

تحرير: أنا أيضًا أعمل على Linux بدون أجهزة افتراضية ، لذا فإن حل

نظام التشغيل هو Ubuntu 14.04

Docker يصل إلى 1.13.1 الآن. يرجى ترقية Docker الخاص بك. كانت تعمل منذ 1.12.x.

اه شكرا لك. سيتم ترقية Docker والتحديث إذا / عند الإصلاح :)

تحرير: عملت! شكرا يا إلهي

تضمين التغريدة

إذا كان الملف أو الدليل الذي تحاول ربطه غير موجود ، فلن يكون لدى عامل التحميل طريقة لتحديد ما إذا كنت تتوقع ملفًا أو دليلًا ، في هذه الحالة (إذا لم يكن /usr/src/app/app.conf إذا لم يكن موجودًا) ، يقوم برنامج عامل الإرساء بإنشاء دليل على هذا الموقع ، ويقوم بتركيبه في الحاوية.
لاحظ أننا حاولنا إهمال / إزالة الإنشاء التلقائي للمسار (وإنتاج خطأ بدلاً من ذلك) ، لكن هذا كان كثيرًا من التغيير غير المتوافق مع الإصدارات السابقة (يعتمد بعض الأشخاص على هذا السلوك) ، لذلك كان علينا الاحتفاظ بهذا السلوك.

لقد أصبت بالإحباط بعد ست ساعات من تجربة حالة الاستخدام هذه بالضبط واكتشفت الآن أنه مستحيل.
لماذا لا تضيف شيئًا مثل "علم الملف" إلى إعلان وحدة التخزين ، مع الأخذ في الاعتبار أنه يمكننا تحديد خيارات تثبيت إضافية مثل :ro و :rw ؟

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

عندما أقوم بتعيين ملف الحاوية إلى ملف المضيف ، أتوقع أن يتم إنشاء ملف المضيف (نسخ من الحاوية) عند تهيئة الحاوية.
لسوء الحظ ، من الشائع جدًا العثور على حاويات تحتوي على ملفات تكوين تم وضعها مباشرةً في الدليل الجذر للتطبيق ، ومن الواضح أنك لا تريد "زيادة حجم" الجذر بالكامل. في هذه الحالة سيكون مفيدًا بشكل خاص إذا كان هذا يعمل.

malyzeli ، قد ترغب في النظر إلى الأسرار كطريقة لإدخال إعدادات مثل هذه ، أو إنشاء قوالب عند بدء التشغيل.
تم تصميم الأحجام حقًا من أجل الثبات وليس التكوين.
لا ينبغي أن يقوم عامل الإرساء بالفعل بإنشاء مسارات مضيف تلقائيًا على الإطلاق ، وقد تمت إزالة هذا السلوك من واجهات برمجة التطبيقات الأحدث.

يارب

لا أفهم وجهة نظرك ، لذا يرجى شرح أو تصحيح افتراضاتي ، لأنني جديد تمامًا على نظام Docker البيئي.

قد ترغب في النظر إلى الأسرار كطريقة لإدخال إعدادات مثل هذه ، أو إنشاء قالب عند بدء التشغيل.

ماذا لو لم أكن أعرف كيف سيبدو ملف التكوين ، لأنه تم إنشاؤه بواسطة معالج التثبيت مباشرةً من التطبيق (والذي يتغير في النهاية من إصدار إلى إصدار)؟
تحتوي العديد من التطبيقات على هذا النوع من الإعداد لأول مرة ، على سبيل المثال Limesurvey و NodeBB.

تم تصميم الأحجام حقًا من أجل الثبات وليس التكوين.

هل تشير إلى أن تكوين الحاوية الحالية يجب ألا يكون ثابتًا؟
ثم ماذا لو كنت أرغب في إجراء نسخ احتياطي لجزء من البنية التحتية متعددة الحاويات الخاصة بي؟
أرغب في الحصول على كل من البيانات والتكوين في وحدات تخزين حتى أتمكن من استعادتها بسرعة إذا حدث خطأ ما.

لا ينبغي أن يقوم عامل الإرساء بالفعل بإنشاء مسارات مضيف تلقائيًا على الإطلاق ، وقد تمت إزالة هذا السلوك من واجهات برمجة التطبيقات الأحدث.

في الواقع ، لست بحاجة إليه لإنشاء مسارات مضيف ، ولكن لتهيئة وحدة تخزين معينة ببيانات الصورة الحالية (على سبيل المثال "إضفاء الطابع الخارجي" على بعض قوالب html ، والتي أريد أن تكون قابلة للتعديل من نظام مضيف و / أو حاوية أخرى) ، ولا يزال يعمل تمامًا كما هو مذكور في مرجع Dockerfile :

يقوم أمر docker run بتهيئة وحدة التخزين التي تم إنشاؤها حديثًا بأي بيانات موجودة في الموقع المحدد داخل الصورة الأساسية.

ماذا لو لم أكن أعرف كيف سيبدو ملف التكوين ، لأنه تم إنشاؤه بواسطة معالج التثبيت مباشرةً من التطبيق (والذي يتغير في النهاية من إصدار إلى إصدار)؟

دعه يتم إنشاؤه ، واستخرجه من الصورة / الحاوية ، واخرج منه سرًا

أرغب في الحصول على كل من البيانات والتكوين في وحدات تخزين حتى أتمكن من استعادتها بسرعة إذا حدث خطأ ما.

استخدم الأسرار. نحن نبحث أيضًا عن كائن config مخصص مشابه للأسرار ، ولكن ليس مقيدًا جدًا ... لكن الأسرار اليوم متوفرة.

في الواقع ، لست بحاجة إليه لإنشاء مسارات مضيف ، ولكن لتهيئة وحدة تخزين معينة ببيانات الصورة الحالية (على سبيل المثال ، "إضفاء الطابع الخارجي" على بعض قوالب html ، التي أريد تعديلها من نظام مضيف و / أو حاوية أخرى) ، ولا يزال يعمل تمامًا كما هو مذكور في مرجع Dockerfile:

حوامل الربط ليست وحدات تخزين. يتحدث مرجع Dockerfile عن وحدات التخزين. من المؤسف أن يتم استخدام docker run -v لكليهما.

أنا بالتأكيد لا أقول عدم استخدام وحدات التخزين لتخزين التكوين ، فأنا أقول إنه يجب عليك تقييم ما إذا كان هناك حل أفضل (وأسرار IMO أفضل بكثير لهذا).

تعد روابط المضيف حلاً سيئًا لأي شيء بخلاف أخذ شيء موجود مسبقًا على المضيف وإدخاله في الحاوية ... وحتى ذلك الحين لا يكون عمليًا بشكل عام عندما تتحدث عن بيئات مجمعة.

يارب

دعه يتم إنشاؤه ، واستخرجه من الصورة / الحاوية ، واخرج منه سرًا

نعم ، هذا ما أفعله ، لكن يبدو أنه معقد بشكل مزعج على أي حال .. :-)

استخدم الأسرار. نحن نبحث أيضًا عن كائن config مخصص مشابه للأسرار ، ولكن ليس مقيدًا جدًا ... لكن الأسرار اليوم متوفرة.

سأبحث في الأمر ، لم أكن أعرف عن الأسرار ، شكرًا!

حوامل الربط ليست وحدات تخزين. يتحدث مرجع Dockerfile عن وحدات التخزين. من المؤسف أن يتم استخدام docker run -v لكليهما.

حسنًا ، يبدو أن هذا تفسير لسبب عدم نجاحها كما توقعت. اعتقدت أن الروابط والأحجام هي مجرد تسمية مختلفة لنفس الشيء ، مع الأخذ في الاعتبار أنها تتم من خلال المعلمة -v .

بالنسبة لأولئك الذين يرون هذا الخطأ في Windows ... حتى إذا كان لديك محركات أقراص مشتركة ...

هناك مشكلة حيث إذا كنت تستخدم Docker Windows (مع docker-compose) واستخدمت بيانات اعتماد معينة لـ "مشاركة Drive" مثل C: \ أو D: \ وما إلى ذلك ، فقد تضطر إلى إلغاء المشاركة ومشاركة محرك الأقراص مرة أخرى وإعادة الدخول بيانات الاعتماد ، وإلا فإنها تمنحك خطأً مرتبطًا مثل:

"خطأ: من أجل ... لا يمكن بدء الخدمة الخاصة بك: خطأ وقت تشغيل oci: container_linux.go: 262: تسبب بدء عملية الحاوية" process_linux.go: 339: container "في \" rootfs_linux.go: 57: mounting \

"\\" تسبب في \\ "عدم وجود دليل \\" ""
: هل تحاول تحميل دليل على ملف (أو العكس)؟ تحقق مما إذا كان مسار المضيف المحدد موجودًا ومن النوع المتوقع "

BaranOrnarli كيف تكون الشخص الذي لديه DockerToolbox؟

نفس المشكلة هنا مثل معظم الناس هنا. لكنني عملت مرة أخرى ببساطة عن طريق إعادة تشغيل VM.

Windows 10 Education
صندوق أدوات Docker ، 17.10.0 م
برنامج VirtualBox 5.2.2

يعمل تشغيل هذا عبر docker CLI:
docker run -d -p 8080:80 -v $(pwd)/src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf تعليمي / nginx

تشغيل نفس الشيء عبر عامل ميناء إنشاء ، لم:
قص
volumes: - ./src/vhost.conf:/etc/nginx/sites-enabled/vhost.conf
أي حتى أقوم بإيقاف تشغيل الجهاز الظاهري عبر VirtualBox GUI وبدأت تشغيل Docker Quickstart Terminal مرة أخرى.

منذ ذلك الحين ، لم يتسبب تدمير الحاويات وتكوين عامل الإرساء بشكل متكرر في عودة الخطأ.

أمل أن هذا يساعد شخصاما.

لدي نفس المشكلة. في هذه الأثناء ، أستخدم مجلد docker ذي الأحجام الحقيقية في docker-compose.yml. هذا /var/lib/docker/volumes..../file.ext كحل مؤقت
(إصدار Docker 17.12.0-ce ، الإصدار c97c6d6)

إذا كانت لديك مثل هذه المشكلة ، فتحقق أيضًا مما إذا كنت قد قمت بمشاركة دليلك على Windows.

أنا على أوبونتو 14.04. عندما أقوم بتشغيل الأمر 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 من قبل مثل السحر. أعد تعيين بيانات الاعتماد لمساحة Drive المشتركة ، وشاركها مرة أخرى ، ويجب أن تعمل. لا توجد فكرة عن سبب توقفها فجأة عن العمل في المقام الأول ، لكنها الآن مرة أخرى.

أي أخبار عن هذا؟ لا يزال يبدو من المستحيل تحميل ملف واحد

Karlheinzniebuhr لم تكن هذه مشكلة. يسمح Docker بتركيب الملفات في حاوية ، ولكن لا يمكنك تحميل ملف إلى دليل أو العكس.

أي أخبار عن هذا؟ لا يزال يبدو من المستحيل تحميل ملف واحد

حاول تعيين الملف بالدليل الموجود. يحاول Docker إنشاء دليل دائمًا إذا لم يكن موجودًا.

@ cpuguy83 بالطبع إنها مشكلة. نحن لا نحاول تحميل الملفات إلى دليل. نحاول تحميل ملف واحد تم إنشاؤه بواسطة الحاوية إلى المضيف كملف.

هل يمكننا إعادة فتح هذه المشكلة؟ لا يزال لا يعمل اعتبارًا من عام 2019. في أحدث إصدار من Docker وأحدث إنشاء عامل عامل تشغيل يعمل على أحدث إصدار من دبيان.

لا يمكنك التحميل من الحاوية إلى المضيف ، فقط بالطريقة الأخرى.
هذا هو نفس السلوك لكل من الدلائل والملفات.

نفس المشكلة ، باستخدام docker 19.03.1 و docker-compose 1.24.1 ، أثناء محاولة تجاوز ملف التكوين في صورة store/elastic/filebeat:7.3.0 مع ربط وحدة التخزين في docker-compose.yml:

    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
...