Compose: عامل ميناء-يؤلف بطيئًا على عامل الإرساء لنظام التشغيل Mac OS بيتا

ping @ frenchben : ابتسم:

+1

حصلت على نفس المشكلة: د

مشكلة @ smith64fx تختفي أيضًا إذا قمت بإيقاف تشغيل WiFi؟

stijn نعم ، عندما أقوم بإيقاف تشغيل wifi ، يعمل كل شيء مثل السحر

فون مينيم iPhone gesendet

صباحا 05.05.2016 أم 00:26 سكريب سيباستيان فان ستيجن [email protected] :

مشكلة @ smith64fx تختفي أيضًا إذا قمت بإيقاف تشغيل WiFi؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

@ smith64fx أرى من توقيعك أنك على الأرجح من ألمانيا (أو النمسا / سويسرا). هل تمانع في أن أسأل ما هو مزود الإنترنت الخاص بك؟ أتساءل عما إذا كان لدينا نفس الشيء ، وما إذا كان من الممكن أن يأتي من الصندوق الذي لا يبدو وكأنه قطعة جيدة جدًا من الأجهزة / البرامج ولن يعمل كما يعتقد عامل الميناء.

(أنا مع فودافون ولدي صندوق سهل خاص بهم - مهما يكن)

نفس المشكلة على شبكة سلكية (شبكة شركة) ، بمجرد أن أقوم بفك توصيلها ، يصبح كل شيء سريعًا جدًا. لذلك أنا متأكد من أنه لا يتعلق بمزود معين لك.

لقد نظرت في الإخراج المطول ، لا يوجد خطأ واضح (ولا في أي مكان في سجلات النظام). هل لاحظت هذا على الرغم من:

مع عدم وجود شبكة ، يتم تجميع هذه الخطوط معًا:

docker attach <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e', stderr=True, stream=True, stdout=True)
docker attach -> <generator object _multiplexed_response_stream_helper at 0x1045f20a0>
docker start <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e')

بدون الربط الشبكي ، أحصل على 100-200 سطر تقريبًا من "compose.parallel.feed_queue: Pending: set ([])" بين المرفق <- والمكان الذي يعود فيه مع attach -> ...

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

لقد أرفقت ناتج الإنشاء - وضع الإطناب في مواقف البوت. ملف الإنشاء عبارة عن حاويتين فقط مباشرة من المحور.

مع-network.txt
بدون network.txt

holstvoogd أوه ، حسنًا للمزود. شكرا على المعلومات ، كنت قلقة بعض الشيء :)

Erwyn @ smith64fx للتأكيد ، أنت متصل دائمًا (متصل بشبكة سلكية) وفي نفس الوقت تستخدم نفس الشبكة مع wifi؟

FrenchBen لا ، إنه

FrenchBen مثل @ smith64fx. إنها شبكة wifi في المنزل فقط ، لذا لا يوجد اتصال سلكي. وكما أرى ، يبدو أن holstvoogd لديه نفس المشكلة مع اتصال سلكي.

ألاحظ نفس المشكلة مع Docker for Mac Beta. docker-compose up يكون بطيئًا عند تمكين Wifi ، وسريع عند تعطيل Wifi.

• إصدار Docker Compose: إصدار docker-compose 1.7.1 ، بناء 0a9ab35
• إصدار Docker: إصدار Docker 1.11.1 ، بناء 5604cbe
• إصدار نظام التشغيل: OS X El Capitan 10.11.4

مرحبا هل هناك اخبار عن هذا؟

لدي نفس المشكلة. إصدارات Compose / Docker / OSX هي نفس إصدارات
أستخدم شبكة WiFi في المنزل وفي المكتب وفي منزلي ، فهي تعمل ببطء شديد. في المكتب يعمل كما هو متوقع (سريع).

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

إذا قمت بإيقاف تشغيل WiFi ، فإن docker-compose سيعمل بسرعة كبيرة

KryDos يجب

لدي نفس المشكلة ، بعد التحديث إلى docker لنظام التشغيل mac 1.11.1-beta13 ، استمرت المشكلة. الحل البديل عن طريق إيقاف تشغيل الشبكة (الشبكات) وتشغيلها مرة أخرى لا يعمل بعد الآن ، حيث تبدأ الخدمات بسرعة عند إيقاف تشغيل الشبكة ، ولكن عند إعادة تشغيل الشبكة مرة أخرى ، لم يعد الوصول إلى الخدمات متاحًا ولا يستجيب برنامج Docker daemon

docker ps
Error response from daemon: Bad response from Docker engine

• إصدار Docker Compose: إصدار docker-compose 1.7.1 ، بناء 0a9ab35
• إصدار Docker: إصدار Docker 1.11.1-beta13 ، بناء 7975
• إصدار نظام التشغيل: OS X El Capitan 10.11.5

لقد واجهت نفس المشكلات ، ووجدت منشورًا (آسف ، فقدت المرجع) يشير إلى أن عامل التركيب يحاول حل مشكلة localunixsocket.local . يمكنك الحصول على نظرة ثاقبة في بحث نظام أسماء النطاقات عن طريق تشغيل sudo tcpdump -A -s0 -nni en0 port 53

في الوقت الحالي ، قمت بتوجيه localunixsocket.local إلى المضيف المحلي في /etc/hosts . الآن كل شيء سريع مرة أخرى.

127.0.0.1 localunixsocket.local

شكرًا @ jewilmeer ، يبدو ذلك مفيدًا

عدت إلى الوراء باستخدام Virtualbox مع جهاز الإرساء. المشكلة غير موجودة وهي أسرع بـ 10 مرات من Docker Mac Beta!

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

تعليق رائع للغاية ، @ jewilmeer! بالنسبة لي ، كان علي إضافة بعض العناوين إلى / etc / hosts التي اكتشفتها باستخدام الأمر tcpdump :

# (yours)
127.0.0.1 localunixsocket.local
# additional ones -- be sure to replace bracketed thing with the output of `hostname`
127.0.0.1 localunixsocket.home <my hostname>.home

بعد تلك الإضافات - بسرعة! في الواقع ، سريع بشكل مثير للدهشة ، يبدو أنه مجموعة جيدة أسرع من استخدام Docker Toolbox! woop woop :) (على الرغم من أن ذلك قد يكون ملاحظة ذاتية للغاية!)

هذا غريب جدًا ، لكن يبدو أنه يشير إلى ماهية المشكلة الأساسية ...

أواجه حاليًا نفس المشكلة ولا يمكنني حل المشكلة.
لقد جربت الاقتراحات السابقة لتحرير /etc/hosts . على شبكة مكتبنا ، عامل الإرساء بطيء للغاية. على الشبكات المنزلية أو استخدام الربط بالهاتف الخلوي يزيل جميع حالات البطء ويكون كل شيء سريعًا.

نحن نستخدم عامل إنشاء مع حاوية ويب مرتبطة بأربع حاويات خدمة (postgres و redis و rabbitmq و elasticsearch). الاتصال بأي من حاويات الخدمة الأربع مباشرة من OSX جيد. إنه بطيء فقط عند محاولة الاتصال من حاوية الويب بأي من حاويات الخدمة.

يعطي تشغيل tcpdump -vvv -s 0 -l -n port 53 الناتج التالي عند التوصيل بهاتف خليوي

tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
16:54:34.236026 IP (tos 0x0, ttl 64, id 25341, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.56662 > 172.20.10.1.53: [udp sum ok] 5785+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.239617 IP (tos 0x0, ttl 64, id 29137, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.56662: [udp sum ok] 5785 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:34.303325 IP (tos 0x0, ttl 64, id 46188, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.58590 > 172.20.10.1.53: [udp sum ok] 52066+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.309241 IP (tos 0x0, ttl 64, id 7329, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.58590: [udp sum ok] 52066 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.309028 IP (tos 0x0, ttl 64, id 52570, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.63544 > 172.20.10.1.53: [udp sum ok] 12851+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.320135 IP (tos 0x0, ttl 64, id 32359, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.63544: [udp sum ok] 12851 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.392915 IP (tos 0x0, ttl 64, id 8082, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.59994 > 172.20.10.1.53: [udp sum ok] 22334+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.416821 IP (tos 0x0, ttl 64, id 51863, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.59994: [udp sum ok] 22334 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)

وهذا هو الناتج عند الاتصال بشبكة wifi لمكتبنا:

16:54:13.870062 IP (tos 0x0, ttl 64, id 17811, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56316 > 192.168.0.1.53: [udp sum ok] 21469+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.870723 IP (tos 0x0, ttl 64, id 53920, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.52082 > 192.168.0.1.53: [udp sum ok] 50601+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.872706 IP (tos 0x0, ttl 64, id 50395, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56176 > 192.168.0.1.53: [udp sum ok] 45180+ PTR? 1.0.19.172.in-addr.arpa. (41)

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

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

هل يمكن أن يكون هذا متعلقًا بمشكلة "امتلاك" Bonjour .local وخطأ IPV6؟
التفاصيل: https://news.ycombinator.com/item؟id=11567442

إذا كان هذا يساعد ولكني اعتدت أن أواجه هذه المشكلة وقمت بإصلاحها عن طريق تغيير خوادم DNS الخاصة بي إلى 8.8.8.8 و 8.8.4.4 .

حدثت هذه المشكلة أيضًا على شبكتي المنزلية فقط. في العمل لم يكن لدي هذه المشكلة.

أواجه نفس المشكلة أيضًا حتى بعد محاولة إصلاح jewilmeer .
يعمل عامل الإرساء بشكل جيد في شبكة مكتبي ولكنه يستغرق حوالي 7 دقائق تقريبًا في شبكتي المنزلية.
نفس السلوك مع أوامر docker-compose الأخرى مثل stop ، pull ، ps ، إلخ.

عامل ميناء - الإصدار
إصدار Docker 1.12.0-rc2 ، بناء 906eacd ، تجريبي

عامل ميناء يؤلف - نسخة
إصدار docker-compose 1.8.0-rc1 ، بناء 9bf6bc6

آلة عامل ميناء - الإصدار
إصدار آلة الإرساء 0.8.0-rc1 ، بناء fffa6c9

لست متأكدًا من السبب ولكن اضطررت إلى إزالة أي عنصر مجال محلي لجعله يعمل.

/ etc / hosts:
127.0.0.1 localunixsocket

لدي مشكلة مشابهة جدًا ، لكنني أعتقد أنها قد تكون مرتبطة باستخدامي لـ DNSCrypt ؟

Erwyn لقد واجهت نفس المشكلة مع Vodafone Easybox أيضًا ...
اتضح أن Vodafone Easybox تربط البحث عن نطاقات .local بالموجه (لتقييم اسم المضيف الديناميكي لجهاز التوجيه الخاص بك ، أي easy.box )
وأعتقد أن هذا الربط تسبب في انتظار docker-compose لاستجابة جهاز التوجيه (قد أكون مخطئًا تمامًا في هذا الأمر) ...
لكن مضيفا
127.0.0.1 localunixsocket.local إلى etc/hosts حل المشكلة بالنسبة لي

اهلا ياجماعة،
127.0.0.1 localunixsocket to etc / hosts حلوا المشكلة بالنسبة لي

davidino Thx Bro ، يعمل بشكل مثالي! أنا مهتم لماذا نحتاج إلى هذا الحل؟

مرحبا يا شباب! نفس المشكلة هنا. في البرازيل ، يستغرق استخدام wifi في المكتب وقتًا طويلاً للبدء. بعد تغيير ملفات /etc/hosts ، سارت الأمور على ما يرام.

نفس المشكلة هنا. العمل من مكتب واحد (على WIFI) ليس لدي مشاكل أو تأخير. العمل خارج مكتب مختلف (أيضًا على WIFI) سأحصل على تأخير لمدة 10 دقائق تقريبًا.

إضافة 127.0.0.1 localunixsocket إلى /etc/hosts لم _لا _ يحل المشكلة بالنسبة لي. حاولت القيام بذلك مع إعادة التشغيل ، لكن لم يحالفني الحظ.

أدت إضافة 8.8.8.8 و 8.8.4.4 كخوادم DNS إلى حل المشكلة.

شكراTypositoire!

مرحبًا ، dadarek ، حاول إضافة 127.0.0.1 localunixsocket.home <hostname>.home في ملف hosts. لقد نجحت فقط عندما أضفت كلا اسمي المضيف. لذلك لا يزال بإمكانك استخدام DNS المحلي الخاص بك ، إذا كنت بحاجة إلى ...

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

إل كابيتان 10.11.4
إصدار Docker 1.12.0 ، بناء 8eab29e ، تجريبي
إصدار docker-compose 1.8.0، build f3628c7
إصدار آلة الإرساء 0.8.0 ، بناء b85aac1

لقد جربت كلاً من اسم المضيف وفصل الإنترنت على أمر إنشاء ولا شيء يساعد ... جربت تغيير نظام أسماء النطاقات أيضًا ... إنه يجلس هناك لمدة 5-10 دقائق ثم يبدأ عملية الإنشاء ... حتى 100٪ في عملية تكوين عامل الإرساء

http://i.imgur.com/fmlhjCo.png

محبط للغاية

http://i.imgur.com/C1P6zHi.png

راجع للشغل كان الإعداد يعمل بشكل جيد مع مربع الأدوات وعمل بسرعة كبيرة ...

مع تصحيح الأخطاء المطول يمكنني رؤيته معلقًا هنا

[home / docker] - $ docker-compose - verbose build app

compose.config.config.find: استخدام ملفات التكوين: ./docker-compose.yml
docker.auth.auth.load_config: الملف غير موجود
compose.cli.command.get_client: إصدار docker-compose 1.8.0 ، بناء f3628c7
إصدار docker-py: 1.9.0
إصدار CPython: 2.7.9
إصدار OpenSSL: OpenSSL 1.0.2h 3 مايو 2016
compose.cli.command.get_client: Docker base_url: http + عامل ميناء: // localunixsocket
compose.cli.command.get_client: إصدار Docker: KernelVersion = 4.4.15-moby ، Os = linux ، BuildTime = 2016-07-28T21: 15: 28.963402499 + 00: 00 ، ApiVersion = 1.24 ، الإصدار = 1.12.0 ، GitCommit = 8eab29e ، القوس = amd64 ، GoVersion = go1.6.3
compose.service.build: إنشاء التطبيق
compose.cli.verbose_proxy.proxy_callable: بناء عامل الإرساء <- (pull = False، stream = True، nocache = False، tag = u'docker_app '، buildargs = None، rm = True، forcerm = False، path =' / Users / bartdabek / Sites / docker '، dockerfile =' Dockerfile-app ')

بعد بضع دقائق يذهب إلى

docker.api.build._set_auth_headers: البحث عن تهيئة المصادقة
docker.api.build._set_auth_headers: لا يوجد تكوين مصادقة في الذاكرة - يتم التحميل من نظام الملفات
docker.auth.auth.load_config: الملف غير موجود
docker.api.build._set_auth_headers: لم يتم العثور على تكوين مصادقة

ثم توقف مرة أخرى ...

سرعة الإنترنت لدي جيدة فقط تم اختبارها بسرعة 60 ميجابايت / ثانية

عمل تمكين Exclude simple hostnames من إعدادات الوكيل بشكل مثالي بالنسبة لي.

NO_PROXY=* docker-compose up

تم إرسال الحل بواسطةjewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 يعمل بالنسبة لي.

سيكون من الجيد الحصول على نصيحة من jibingeo في Docker لـ Mac README.md أو في مكان ما في البرنامج التعليمي.

مرحبا شبابthaJeztah.

بعد الاطلاع على الكود المصدري ، وجدت أن تنفيذ socket.gethostbyname("localunixsocket") يستغرق أكثر من 30 ثانية (في حالتي).

لذلك استفسرت عن DNS المحلي و Google DNS

$ time nslookup localunixsocket 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

** server can't find localunixsocket: NXDOMAIN

real    0m30.295s
user    0m0.004s
sys     0m0.005s

$ time nslookup localunixsocket 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

** server can't find localunixsocket: NXDOMAIN

real    0m0.685s
user    0m0.005s
sys     0m0.013s

يعمل DNS المحلي بشكل مثالي مع اسم مضيف FQDN

time nslookup google.com 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.196.110


real    0m0.028s
user    0m0.005s
sys 0m0.006s

هذا يعني أن المشكلة الفعلية تتعلق بجهاز التوجيه DNS.

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

على أي حال ، فإن الاختلاف في الأوقات بين DNS المحلي و DNS الخاص بـ Google مثير للاهتمام ... سأكون فضوليًا ما الذي يجعله يفعل ذلك. (للأسف ، أعتقد أنه يجب أن يكون لديك تفريغ TCP آخر على خادم DNS يشير إليه جهاز التوجيه من أجل معرفة ذلك ، ما لم يكن هناك ما tracert لعمليات بحث DNS التي يمكن أن تحافظ على الخوادم الوسيطة التي تعرضت لضربة متكررة الاستعلام)

قد يكون هذا مفيدًا أيضًا (موجود في man nslookup على Mac OS X):

إشعار Mac OS X

لا يستخدم الأمر nslookup اسم المضيف وتحليل العنوان
أو آليات توجيه استعلام DNS التي تستخدمها العمليات الأخرى التي تعمل على
Mac OS X. نتائج استعلامات الاسم أو العنوان المطبوعة بواسطة nslookup
قد تختلف عن تلك الموجودة في العمليات الأخرى التي تستخدم نظام التشغيل Mac OS X.
الاسم الأصلي وآليات تحليل العنوان. نتائج DNS
قد تختلف الاستعلامات أيضًا عن الاستعلامات التي تستخدم توجيه Mac OS X DNS
مكتبة.

نظرًا لأنهم لا يقدمون حقًا أي توضيح بشأن الآلية المحددة التي تستخدمها nslookup _ التي تستخدمها مقابل ما يوفره Mac OS X ، فمن الصعب تحديد ما إذا كان من المتوقع أن يشارك Docker سلوك nslookup ، أو تطبيقات Mac OS X الأخرى ... (أعتقد أنه يستخدم نفس الأساليب التي يستخدمها nslookup ، لكن ربما يتعين علينا البحث في الكود لكليهما لمعرفة ذلك بشكل نهائي)

يا @ whitelynx

هنا هو تفريغ TCP المأخوذ مع Local DNS و Google DNS. الأمر الذي اعتدت أن أتناوله هو التفريغ

sudo killall -HUP mDNSResponder && docker-compose ps

مع DNS المحلي:

15:49:30.025038 IP (tos 0x0, ttl 255, id 18504, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:30.291508 IP (tos 0x0, ttl 255, id 36848, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:31.097658 IP (tos 0x0, ttl 255, id 32568, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:31.368098 IP (tos 0x0, ttl 255, id 54970, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:33.596367 IP (tos 0x0, ttl 30, id 20508, offset 0, flags [none], proto UDP (17), length 133)
    10.0.0.1.53 > 10.0.0.3.60707: [udp sum ok] 54235 NXDomain* q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. [1d] SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (105)
15:49:33.597103 IP (tos 0x0, ttl 30, id 20510, offset 0, flags [none], proto UDP (17), length 136)
    10.0.0.1.53 > 10.0.0.3.52331: [udp sum ok] 10799 NXDomain q: A? localunixsocket. 0/1/0 ns: . [2h8m4s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

مع Google DNS:

15:45:25.301293 IP (tos 0x0, ttl 255, id 37492, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 8.8.8.8.53: [udp sum ok] 14029+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:45:25.371167 IP (tos 0x0, ttl 56, id 10269, offset 0, flags [none], proto UDP (17), length 83)
    8.8.8.8.53 > 10.0.0.3.60707: [udp sum ok] 14029 NXDomain q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/0/0 (55)
15:45:25.599570 IP (tos 0x0, ttl 255, id 7256, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.59912 > 8.8.8.8.53: [udp sum ok] 3154+ A? localunixsocket. (33)
15:45:25.702374 IP (tos 0x0, ttl 56, id 39895, offset 0, flags [none], proto UDP (17), length 136)
    8.8.8.8.53 > 10.0.0.3.59912: [udp sum ok] 3154 NXDomain q: A? localunixsocket. 0/1/0 ns: . [29m58s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

يمكنني هنا رؤية تأخير 3 ثوانٍ تقريبًا مع DNS المحلي.

ملاحظة: جهاز التوجيه الذي استخدمته هنا يختلف عن الموجه الذي استخدمته للتعليق السابق

تحية للجميع،
بعد الترقية إلى docker لنظام التشغيل mac Version 1.12.1 (build: 12133) اضطررت إلى إضافة ملف
127.0.0.1 localunixsocket مرة أخرى في /etc/hosts

كان علي أن أفعل ما فعله دافيدنو أيضًا.

لا تقديري لحل هذا الخطأ المزعج للغاية ؟

كان علي أيضًا إضافة 127.0.0.1 localunixsocket.lan لجعله يعمل. أنا أستخدم macOS Sierra.

لا أعرف حقًا ما إذا كانت هذه هي نفس المشكلة ، لكن رد jibingeo ساعدني.
_docker-compose_ بطيء جدًا في بيئة شركتي باستخدام Docker Toolbox لنظام التشغيل Windows. ساعدني تكوين NO_PROXY=* أيضًا ولكن هذا يتعارض مع وكيل شركتي. لذلك حاولت قليلاً ووجدت حلاً أكثر تحديدًا (بافتراض أنك تستخدم نطاق IP الافتراضي لـ docker VirtualBox 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 تسريع كل شيء ، لذا لا يحتاج الإنشاء إلى تجربة وكيل شركتي لعناوين IP الداخلية.

ذات صلة؟ https://github.com/SeleniumHQ/docker-selenium/issues/227

حل davidino بوضع 127.0.0.1 localunixsocket في /etc/hosts المشكلة بالنسبة لي.

أسرع بكثير الآن

أواجه نفس المشكلات. لقد حاولت إيقاف تشغيل wifi الخاص بي ، وإضافة إدخالات متعددة إلى ملف المضيف الخاص بي دون نجاح. لقد جربت نفس الإعداد على جهاز linux box الخاص بي وكانت النتائج أسرع بكثير.

يبدو أن البناء يعمل بسرعة مناسبة ولكن بمجرد تقديم أي طلبات في الحاويات قيد التشغيل ، تكون النتيجة مروعة. حوالي 30 ثانية لأي طلب ، بغض النظر عما إذا كان استجابة نصية بسيطة.

أنا أقوم بتشغيل Mac OS Sierra (10.12.1) و Docker for Mac (1.12.1) مع مكدس ريلز.

أنا على الإصدار 10.11.6 (15G31)

هذا ما يوجد في ملف /etc/hosts :

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
255.255.255.255 broadcasthost
::1             localhost 
127.0.0.1 localhost
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

أنا على وحدة إرساء القناة التجريبية 1.12.3-beta29.2 (13499)

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

gardner نفس المشكلة. يعمل الآن Docker 1.12.3-beta29.3 (13640). لا يزال إعداد Linux الخاص بي يعمل بشكل أسرع مع 1/4 من ذاكرة الوصول العشوائي.

أفضل ما يمكنني قوله هو أنها مشكلة IO بين عامل الإرساء والجهاز المضيف. قمت بتشغيل جهاز Flamegraph عند الطلب وهو يقضي معظم الوقت في قراءة الملفات.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot٪202016-11-02٪2014.39.22.png؟dl=0

هذا هو نفس التطبيق ، نفس الطلب ، يعمل محليًا.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot٪202016-11-02٪2014.44.37.png؟dl=0

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

لست متأكدًا مما إذا كان هذا معروفًا بالفعل أم لا ، ولكن نأمل أن يساعد أي شخص آخر يأتي إلى هذا الموضوع في محاولة لمعرفة ذلك.

تحرير: يبدو أن هذه هي المشكلة الحقيقية التي أواجهها. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

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

أرى هذا في إصدار عامل التشغيل الثابت التالي الذي يعمل بنظام OSX 10.11.6 مع إصدار عامل الإرساء التالي:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

أرى هذا على اتصال سحابي بطيء (السحابة في مقهى في لندن) ، عندما أقوم بإيقاف تشغيل WiFi ، يكون الإنشاء سريعًا للغاية ، وإلا فإن كل شيء يعمل ببطء شديد ...

هل يبدو أن الإصدار الأخير (1.9.0) قد غير أي شيء للأشخاص الذين يواجهون المشكلة؟

@ shin- لا يزال لدي 1.8.1 في docker-compose --version باستخدام أحدث Docker لنظام التشغيل Mac. متى نتوقع التحديث؟

متى نتوقع حلًا لهذه المشكلة؟

1.9 في القناة التجريبية ، ولست متأكدًا من موعد الشحن المستقر ، على الأرجح
في غضون أسبوع أو نحو ذلك.

في 18 نوفمبر 2016 ، الساعة 8:07 صباحًا ، كتب "David Richards" [email protected] :

@ shin- https://github.com/shin- لا يزال لدي 1.8.1 في تكوين عامل الإرساء الخاص بي
- نسخة مع أحدث Docker لنظام التشغيل Mac. متى نتوقع التحديث؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

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

بالنسبة لي ، فإن إزالة مجال البحث .local أحدثت الفارق.

@ shin- في 1.9.0-rc4 ما زلت أواجه المشكلة. لا أعرف ، ما الذي فعلته ، لكن منذ بضعة أيام لم يكن لدي مشكلة ، باستخدام docker-compose لأكثر من عام.
docker-compose --version سريع حقًا
docker-compose ps بطيء جدًا
تعطيل Wifi - ps سريع أيضًا

gsong للأسف لم يساعدني ذلك

لقد بدأت أيضًا فجأة في مواجهة هذه المشكلة. تمامًا مثل timsuchanek ، كنت docker-compose up معلق إلى أجل غير مسمى تقريبًا. مثل أي شخص آخر ، عندما أقوم بإيقاف تشغيل wifi ، فإنه يعمل.

أنا على docker-compose version 1.9.0, build 2585387

تحرير: إضافة 127.0.0.1 localunixsocket إلى /etc/hosts إصلاحه في الوقت الحالي. أنا على macOS 10.11.6

ما هي فرص هذا بسبب التغييرات .local التي أدخلت في yosemite؟

https://support.apple.com/en-us/HT203136
https://news.ycombinator.com/item؟id=9026192

رأيت أن afxjzs ذكرها سابقًا لكن لم أر أي متابعة.

عثرت على شيء يناسبني أثناء محاولتي تشغيل xdebug:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

على الجهاز المضيف.

بفضل جيمس كوي .

تحرير: يبدو أن xdebug كان أصل مشكلتي. مع إيقاف تشغيل xdebug ، تكون آلة عامل الإرساء الخاصة بي فائقة السرعة ، حتى مع وجود / etc / hosts في حالته الافتراضية. مع تشغيله ، وضبط xdebug.remote_host الخاص بي على 10.254.254.254 ، فإنه يبطئ إلى زحف. لا تساعد التعديلات المقترحة على / etc / hosts ، لكن تعيين الاسم المستعار للمضيف المحلي على en0 على النحو الوارد أعلاه يعمل على إصلاح المشكلة.

هذا يحدث لي مع Docker الأحدث لنظام التشغيل Mac (1.13.1 ، docker-compose 1.11.1)

القيام بأعمال NO_PROXY=* .

حدث هذا لي مع التحديث الأخير أيضًا (1.13.1 ، docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 حل مشكلتي.

لدي نفس الخطأ. إضافة localunixsocket إلى /etc/hosts . لم تعمل. إصلاح مؤقت بمناسبة علامة التبويب الوكلاء Exclude simple hostnames .

macOS Sierra 10.12.3 (16D32)
Docker version 1.13.1, build 092cba3
docker-compose version 1.11.1, build 7c5d5e4

لقد لاحظت أن أي مجالات بحث غير مستجيبة تؤدي إلى إنشاء عامل إرساء بطيء جدًا. ليس فقط .local كنت أستخدم .dev .

لقد واجهت نفس المشكلة اليوم مع تعليق إنشاء عامل الميناء إلى الأبد حتى لعرض المساعدة أو الإصدار. لقد اتبعت نصيحة jewilmeer حول استخدام tcpdump وفي حالتي تم حل المشكلة عن طريق إضافة 127.0.0.1 prod.python.map.fastly.net إلى / etc hosts

غريب جدا ، على ما أعتقد؟

نفس المشكلة هنا. يبدو أنه معلق مرتين ، كل منهما لمدة 25 ثانية تقريبًا. هذا هو الناتج --verbose مع تدخل كل HANG

compose.config.config.find: Using configuration files: ./config/docker-compose-dev.yml
docker.auth.find_config_file: Trying paths: ['/Users/dorkusprime/.docker/config.json', '/Users/dorkusprime/.dockercfg']
docker.auth.find_config_file: Found file at path: /Users/dorkusprime/.docker/config.json
docker.auth.load_config: Found 'auths' section
docker.auth.parse_auth: Found entry (registry=u'https://index.docker.io/v1/', username=u'dorkusprime')

[HANGS FOR ~25S]

compose.cli.command.get_client: docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.9.13-moby, Arch=amd64, BuildTime=2017-03-15T20:28:18.193664702+00:00, ApiVersion=1.27, Version=17.03.1-ce-rc1, MinAPIVersion=1.12, GitCommit=3476dbf, Os=linux, Experimental=True, GoVersion=go1.7.5
compose.project.build: mongodb uses an image, skipping
compose.project.build: redis uses an image, skipping
compose.service.build: Building web
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag='dorkusprime/dashboard-test', buildargs=None, rm=True, forcerm=False, path='/Users/dorkusprime/repository/Dashboard-test', dockerfile=None)
docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: Sending auth config (u'https://index.docker.io/v1/')

[HANGS FOR ~25S]

compose.cli.verbose_proxy.proxy_callable: docker build -> <generator object _stream_helper at 0x105cc4910>

لقد جربت الحلول البديلة / etc / hosts دون أي تحسن ملحوظ.

نفس المشكلة هنا ولا يوجد حل من الموضوع بأكمله يساعدني (لا /etc/hosts ولا NO_PROXY متغير ولا Exclude simple hostnames ولا تغيير DNS إلى 8.8.8.8 ).

هناك شيء واحد يجب ملاحظته: إذا قمت بتشغيل docker باستخدام sudo ، فإنه يحل مشكلة السرعة.

أحدث إصدار عامل ميناء (Docker version 17.03.1-ce-rc1، build 3476dbf). لقد جربت كلاً من الإصدارات التجريبية والمستقرة.

يستغرق docker --version 32 ثانية لإخراج النسخة الموجودة في حالتي.

هذه المشكلة موجودة منذ ما يقرب من عام الآن ...

mobileka هل تتحدث عن docker أو docker-compose ؟

@ shin- في حالتي ، كل أمر cli واحد (سواء كان docker أو docker-compose ) المرتبط بعمال الإرساء لديه وقت استجابة قدره 30 ثانية أو نحو ذلك قبل إعطاء النتائج فعليًا أو قبل البدء في أداء وظيفته.

mobileka حسنًا - هذا بالتأكيد لا علاقة له بالمشكلة الموضحة هنا. ضع في اعتبارك إنشاء مشكلة على Docker for Mac repo بدلاً من ذلك.

@ shin- آسف ، لم أكن أدرك أنني في إعادة شراء خاطئة لأن "الأعراض" كانت متشابهة جدًا: إنها بطيئة عندما يكون الاتصال بالإنترنت نشطًا وسريعًا عندما لا يكون هناك اتصال بالإنترنت.

شكرًا لك ، سأقوم بإنشاء مشكلة في Docker for Mac repo.

إذا كان هذا يضرب أي شخص آخر ، فأنا متأكد من أن اللعب (ثم الشد اللاحق) مع Consul أضاف ملف تكوين في / etc / resolvers. تسبب هذا في حدوث مشكلات مشابهة لـ seeekr تم الإبلاغ عنها مع رؤية localunixsocket.، مثل ذلك:

A.D.*.5.>t.d............localunixsocket.foo.bar.example.com.....
14:36:13.357925 IP 10.23.45.67.65066 > 10.98.76.54.53: 25754+ A? localunixsocket.foo.bar.example.com. (54)
E..R.......P
...

أدت إزالة الملف من / etc / resolvers إلى حل المشكلة على الفور.

امل ان يساعد!

نفس المشكلة هنا ولا يوجد حل من الخيط بأكمله يساعدني (لا / etc / hosts ولا متغير NO_PROXY ولا يستبعد أسماء المضيف البسيطة ولا تغيير DNS إلى 8.8.8.8).

أنا أكتب موقع ويب للألعاب (المنطق بسيط حقًا ولا يجب أن يكون لديه مشاكل في الأداء) وأقوم بتشغيله محليًا باستخدام docker-compose. اتضح أن كل صفحة تقريبًا تستغرق دقائق للتحميل. أي تعليمات؟

يبدو أن أوقات تحميل صفحة

ماك أو إس سييرا 10.12.5.
طبعة مجتمع Docker
الإصدار 17.06.0-ce-mac18 (18433)
القناة: مستقرة
d9b66511e0

لدي بالفعل DNS كـ 8.8.8.8. هناك حاجة لإضافة كل من localunixsocket.local و localunixsocket إلى / etc / hosts. في اللحظة التي تمت فيها إضافة هذا ، انبثقت الحياة في تكوين عامل الإرساء.

لست متأكدًا مما إذا كان هذا يساعد أي شخص - ولكن لدي dnscrypt مثبتًا وبعد التبديل إلى docker beta ، كان تكوين عامل الإرساء بطيئًا بشكل لا يصدق. أدت إعادة تثبيت dnscrypt (عبر البراميل المشروب) إلى إصلاح المشكلة بالنسبة لي.

أنا أحبك @ jewilmeer

أردت فقط ترك هذا هنا. كانت مشاكلي هي ملفات الجلسة داخل سياق البناء الخاص بي. كانت الملفات مملوكة لمستخدم apache وستعلق بنية docker-compose بعد هذا السطر:

docker.api.build._set_auth_headers: No auth config found 

المحزن هو أنني توقفت عن استخدام الجلسات القائمة على الملفات منذ فترة طويلة. ربما ينبغي تنظيف مساحة العمل الخاصة بي بين الحين والآخر.

سبب التعليق: سيكون من الرائع حقًا ألا يتوقف التأليف فقط. لقد اكتشفت فقط الجاني باستخدام بناء عامل البناء مباشرة والذي أبلغني جيدًا بمشاكلي.

paali هل يمكنك توضيح ما فعلته بالضبط؟

@ Vad1mo الإعداد الكامل الخاص بي معقد للغاية (وفوضوي وجاري العمل عليه) ولكن الأجزاء الأساسية هي مشروع Symfony2. كانت بها ملفات جلسة قديمة في مجلد ./app/sessions التي كانت مملوكة لمستخدم apache (قبل أوقات عامل الإرساء).

في الأساس كان لدي
COPY app app/
على Dockerfiles و docker-compose.yml لبناء ملف Dockerfile.
الأمر المستخدم:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

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

> docker build -f thefile --no-cache --force-rm
error checking context: 'no permission to read from '/path/to/my/project/app/sessions/sess_n8turtujft1bipv745khqsqbi1''.

في المرة القادمة سأعرف تجربة عامل الإرساء مباشرةً على الفور ولكن لا يبدو أن هناك شيئًا يشير إلى المشكلة الحقيقية. أنا على Docker لنظام التشغيل Mac 7.06.1-ce-mac24.

أي كلمة عن حل حقيقي لهذا بخلاف الاضطرار إلى إخبار الجميع بإضافة قاعدة مضيفة أو إيقاف تشغيل الوكلاء؟

+1

+1

+1

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

docker نفسه متجاوبًا طوال الوقت.

لا أعرف ، لكني أعتقد أنه ربما يكون docker يعثر بشكل صحيح على مورد على النظام باستخدام عنوان IP أو اسم محلي ثابت ، بينما docker-compose يعتمد بشكل غير آمن على localdomain يتم تعريف

كنت أقوم بتشغيل الخط لمراقبة نظام أسماء النطاقات الذي كان في المنشور الأصلي على الإصلاح:

sudo tcpdump -A -s0 -nni en0 المنفذ 53

أظهر لي ذلك أن ما كنت بحاجة لإضافته إلى معادي هو:

127.0.0.1 localunixsocket.localdomain

يبدو أن شيئًا ما تغير من .local إلى .localdomain؟

لقد أجريت منذ ذلك الحين تثبيتًا جديدًا لـ 10.12 Sierra. أعدت تثبيت عامل الإرساء ولم أتمكن من إعادة إظهار المشكلة.

واجهت هذه المشكلة اليوم ، أول يوم لي على Mac.
تم إيقاف إنشاء Docker للتو ، حرفياً بعد إدخال السطر في /etc/hosts بدأ العمل كما هو متوقع.
كنت أستخدم شبكة WiFi ، فكل شخص في المكتب لديه نفس الإصدار على Ethernet لم يسمع بهذه المشكلة مطلقًا.
عامل ميناء: Version 17.09.0-ce-mac35 (19611)
ماك 10.13.1 (17B48)

نفس الخطأ هنا. يجب أن أضيف الأسطر الثلاثة إلى / etc / hosts لحل هذه المشكلة.
127.0.0.1 مقبس محلي
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

نفس الخطأ. هذا عمل معي.

$ sudo tcpdump -vvv -s 0 -l -n port 53
...
13:46:10.203734 IP (tos 0x0, ttl 255, id 7224, offset 0, flags [none], proto UDP (17), length 81, bad cksum 0 (->7b21)!)
    10.64.14.244.54683 > 10.0.0.10.53: [bad udp cksum 0x2491 -> 0xf39b!] 30038+ A? localunixsocket.*.svc.cluster.local. (53)

$ sudo vim /etc/hosts

# hacks for docker
127.0.0.1 localunixsocket.*.svc.cluster.local

أضفت 127.0.0.1 localunixsocket في /etc/hosts وقد نجحت معي ، شكرًا!
(لكنها لا تزال علة wtf)

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

تم التأكيد على أن 127.0.0.1 localunixsocket in /etc/hosts يسرع الأمور بشكل كبير ، يرجى الإصلاح!

إضافة 127.0.0.1 localunixsocket في /etc/hosts يساعد. أنا أستخدم docker-compose version 1.18.0, build 8dd22a9

الحل الذي أوصت به norbertsienkiewicz يعمل بشكل مثالي بالنسبة لي. لقد خفضت وقتي docker-compose up من أكثر من 10 دقائق إلى أقل من دقيقة (الإصدار 1.18.0).

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

هنا هو backtrace الذي يسبب البحث الزائف DNS:

  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/daemon.py", line 88, in info
    return self._result(self._get(self._url("/info")), True)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/utils/decorators.py", line 46, in inner
    return f(self, *args, **kwargs)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/client.py", line 193, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 521, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 499, in request
    prep.url, proxies, stream, verify, cert
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 672, in merge_environment_settings
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 692, in get_environ_proxies
    if should_bypass_proxies(url, no_proxy=no_proxy):
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 676, in should_bypass_proxies
    bypass = proxy_bypass(netloc)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1487, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1453, in proxy_bypass_macosx_sysconf
    hostIP = socket.gethostbyname(hostonly)

لقد واجهت هذه المشكلة للتو بعد التحول من اللاسلكي إلى السلكي. العودة إلى اللاسلكي وكل شيء على ما يرام مع العالم.

هل التغييرات / etc / host على الجهاز المضيف أو حاوية عامل الإرساء ؟؟

أي ملف مضيف لتعديل؟

1. ملف مضيف macOS؟
2. هل يعمل Linux VM كمضيف عامل ميناء؟
3. الحاوية نفسها؟

لست متأكدًا من السبب ولكن اضطررت إلى إزالة أي عنصر مجال محلي لجعله يعمل.

/ etc / hosts:
127.0.0.1 localunixsocket

العبقري!!!