هل وجدت IP في Virtualbox أو على المضيف؟

أعتقد أن docker0 كان على Virtualbox VM.

أنا أتحدث عن docker for mac الذي هو في مرحلة تجريبية ولا يقوم بعمله عبر جهاز افتراضي

أنا أيضا أواجه نفس المشكلة بالضبط. تم العثور على عنوان IP للمضيف على جهاز عامل الإرساء باستخدام الأمر أدناه. بافتراض أن 0.0.0.0 تمثل المضيف ، صححني إذا كنت مخطئًا هنا.
netstat -nr | grep '^ 0.0.0.0' | awk "{print $ 2}"
172.17.0.1

ولكن عندما تفعل curl على هذا IP مع منفذ حيث أقوم بتشغيل خادم ويب ، فإنه يعطي اتصالاً مرفوضًا.
حليقة 172.17.0.1:9000
curl: (7) فشل الاتصال بمنفذ 172.17.0.1 9000: تم رفض الاتصال

لست متأكدا من كيفية الحصول على الإصلاح المناسب. يبدو أن هذا يسبب مشكلة عند الحاجة للاتصال بالخدمة التي ستعمل على الجهاز المضيف.
تم العثور أيضًا على طريقة لإصلاح عنوان IP الخاص بالجهاز المضيف عن طريق تعيينه في DOCKER_OPTS.
DOCKER_OPTS = "- H tcp: //0.0.0.0 : 5000 -H unix: ///var/run/docker.sock --bip = 172.17.42.1 / 16"

ولكن أين يمكنني وضع هذه الخيارات على نظام Mac؟ على ubuntu يمكن وضعه في / etc / default / docker.

يرجى تقديم توجيهات إذا كان من الممكن إصلاح ذلك على نظام Mac.

pingjustincormack ربما لديك بعض التلميحات هنا.

MiteshSharma بالضبط ، هذا من أول الأشياء التي

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

لقد استخدمت هذا
https://docs.docker.com/engine/installation/mac/

لست متأكدا ما إذا كان بيتا الخاص بك أي خاص

HackToday هذا مختلف ، هذا هو تثبيت Mac المستند إلى VirtualBox ؛ يتوفر Docker لنظام التشغيل Mac على beta.docker.com

شكرًا thaJeztah هل من رابط مستند جيد ممكن

HackToday https://blog.docker.com/2016/03/docker-for-mac-windows-beta/ يعطي المزيد ، وهناك وثائق ، لكنني أعتقد أنه فقط إذا كنت في الإصدار التجريبي ؛ https://beta.docker.com/docs/. إذا قمت بالتسجيل في الإصدار التجريبي ، فأعطيني "ping" ؛ يمكنني محاولة إدراجك في قائمة الأولويات كمساهم: ابتسم:

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

HackToday إنه مجاني تمامًا ، فقط لعدم إرباك الفريق ، تقرر إصداره

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

حسنًا ، ليس مرضيًا حقًا لأن أجهزة Mac عادةً ليست خوادم إنتاج ولكن
آلات التطوير.

على آلات الإنتاج الخاصة بي ، لا أمانع مشكلة عدم القدرة على ذلك
الاتصال بالمضيف.

ولكن على جهاز مطور ، يتم الاتصال بالخدمات على نفس المضيف من داخل ملف
الحاوية هو بالضبط السيناريو الذي ترغب فيه هذه الوظيفة
معظم.

أحتاج إلى واجهة docker0 هذه أيضًا لاستخدام بيئة تشغيل التطبيقات "docker + on host (من IDE) المختلطة".

أفضل حل حالي هو الاتصال بحاوياتك من حاوية أخرى. في الوقت الحالي ، لا توجد طريقة يمكننا من خلالها توفير التوجيه لهذه الحاويات نظرًا لوجود مشكلات مع OSX لم تحلها Apple بعد. نحن نتتبع هذا المطلب ، لكن لا يمكننا فعل أي شيء حياله في الوقت الحالي.

هل التعليق أعلاه دقيق؟

لقد وجدت أنه من داخل حاويات docker-for-mac-beta ، يمكن العثور على مضيف عامل الإرساء والاتصال به على العنوان المعتاد 172.17.0.1 (بافتراض أن الخدمة مرتبطة بـ 0.0.0.0 ).

igrayson هذا لأن الحاويات موجودة في الجهاز الظاهري مع Docker daemon ويمكنها بالتأكيد الوصول إليها.
المشكلة هي التوجيه من OSX إلى VM net.

المشكلة هي التوجيه من OSX إلى VM net.

هذا ليس فهمي لقضية OP:

أود أن أكون قادرًا على الاتصال بخدمات redis المحلية وغيرها من الخدمات دون الحاجة إلى إرساء هذه ...

أنا أقوم بتشغيل docker-for-mac-beta ، وليس لدي مشكلة في الاتصال بـ redis والخدمات المحلية الأخرى - التي تعمل على OSX - من خلال جعلهم يستمعون على 0.0.0.0 ، وجعل تطبيقاتي المرسومة تتصل بـ 172.17.0.1 .

نظرة عامة

لدي نفس المشكلة. باستخدام إصدار Docker 1.11.1-beta14 (build: 8670) 984649fbd63d53a62b34f08b59694d4d569b74d5 . يقول pinata doctor أن كل شيء على ما يرام.

لا يمكنني تجعيد خدمة تعمل في المضيف ، على سبيل المثال تطبيق ExpressJS يستمع في المنفذ 3001 ، من داخل الحاوية:

root<strong i="11">@e19fc8e02595</strong>:/# curl localhost:3001
curl: (7) Failed to connect to localhost port 3001: Connection refused

root<strong i="12">@e19fc8e02595</strong>:/# curl 0.0.0.0:3001
curl: (7) Failed to connect to 0.0.0.0 port 3001: Connection refused

root<strong i="13">@e19fc8e02595</strong>:/# curl 172.25.8.25:3001
{"status":200} 
root<strong i="14">@e19fc8e02595</strong>:/#

_ ملاحظة: 172.25.8.25 هو عنوان IP لشبكة WiFi الخاصة بي.

بينياتا

$pinata list
These are advanced configuration settings to customize Docker.app on MacOSX.
You can set them via pinata set <key> <value> <options>.

🐳  hostname = docker
   Hostname of the virtual machine endpoint, where container ports will be
   exposed if using nat networking. Access it via 'docker.local'.

🐳  hypervisor = native (memory=4, ncpu=6)
   The Docker.app includes embedded hypervisors that run the virtual machines
   that power the containers. This setting allows you to control which the
   default one used for Linux is.

 ▸  native: a version of the xhyve hypervisor that uses the MacOSX
              Hypervisor.framework to run container VMs. Parameters:
              memory (VM memory in gigabytes), ncpu (vCPUs)


🐳  network = hostnet (docker-ipv4=192.168.65.2, host-ipv4=192.168.65.1)
   Controls how local containers can access the external network via the
   MacOS X host. This includes outbound traffic as well as publishing ports
   for external access to the local containers.

 ▸ hostnet: a mode that helps if you are using a VPN that restricts
              connectivity. Activating this mode will proxy container network
              packets via the Docker.app process as host socket traffic.
              Parameters: docker-ipv4 (docker node), host-ipv4 (host node)
 ▸     nat: a mode that uses the MacOS X vmnet.framework to route container
              traffic to the host network via a NAT.

🐳  filesystem = osxfs
   Controls the mode by which files from the MacOS X host and the container
   filesystem are shared with each other.

 ▸   osxfs: a FUSE-based filesystem that bidirectionally forwards OSX
              filesystem events into the container.


🐳  native/port-forwarding = true
   Expose container ports on the Mac, rather than the VM

 ▸    true: Container ports will be exposed on the Mac
 ▸   false: Container ports will be exposed on the VM

🐳  daemon = run 'pinata get daemon' or 'pinata set daemon [@file|-]>
   JSON configuration of the local Docker daemon. Configure any custom
   options you need as documented in:
   https://docs.docker.com/engine/reference/commandline/daemon/. Set it
   directly, or a <strong i="20">@file</strong> or - for stdin.

التكرارات المحتملة والمراجع والمساعدة وما إلى ذلك

• https://github.com/docker/docker/issues/23388
• https://forums.docker.com/t/beta-9-and-localhost-connection-via-net-host/10471
• https://forums.docker.com/t/docker-for-mac-beta-9-and-daemon-options/10449/9
• http://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach
• http://stackoverflow.com/questions/29598504/how-to-connect-to-service-in-the-host-machine-from-inside-a-docker-container
• http://blog.michaelhamrah.com/2014/06/accessing-the-docker-host-server-within-a-container/

كانت لدي مشكلات مشابهة ووجدت 172. * ips لن تسمح لي بالاتصال بمثيل mysql محلي مرتبط بـ 0.0.0.0.

يمكنني الاتصال به بأي عنوان IP قابل للتوجيه من الجهاز المضيف. ifconfig وابحث عن واحد من ملكك.

الآن كيف يمكنني إدخال هذا ديناميكيًا في الحاوية؟

تواجه نفس المشكلة مثل

بينغ londoncalling ^^

أي أخبار عن هذا؟ لأنه في Ubuntu (host) ، يمكن الاتصال بالتطبيق الموجود داخل الحاوية والذي يستمع على 0.0.0.0 بواسطة المضيف باستخدام IP 172.17.*.*. . لذلك لا داعي لفضح المنفذ عند تشغيل الحاوية.

على Docker for Mac Beta لا يمكنني فعل ذلك بسبب غياب docker0. آمل أن يتم إصلاحه في الإصدار النهائي :)

thaJeztahastasoft سأبحث فيه اليوم ، شكرًا @

ما أفهمه هو أن مشكلتك هي الوصول إلى الخدمات التي تعمل على جهاز Mac الخاص بك من حاوية.
إذا كانت هذه هي الحالة ، فيمكنك القيام بذلك باستخدام عنوان IP الذي تعرضه واجهة en0.
ifconfig en0 | grep "إنت" | قطع -d "" -f2

على سبيل المثال ، إذا كان لدي خادم ويب يعمل على جهاز Mac الخاص بي على المنفذ 80:
تشغيل عامل الإرساء - توتوم / حليقة الضفيرة ifconfig en0 | grep "inet " | cut -d " " -f2

إنها تعمل!

يمكنك تعيين عنوان IP هذا في متغير بيئة وتمريره إلى الحاوية الخاصة بك ، كما أفعل لخادم X11 في https://github.com/chanezon/docker-tips/blob/master/x11/README.md

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

londoncalling شكرا ،

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

الحل الحالي الخاص بي هو العودة إلى Docker Toolbox لنظام التشغيل Mac والقيام بإعادة توجيه المنفذ على مثيل Boot2Docker في Virtualbox.

sudo iptables -t nat -A PREROUTING -d 192.168.99.100/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.2:80

ثم يمكنني الاتصال بالخدمة في الحاوية باستخدام boot2docker IP 192.168.99.100:80.

curl -i http://192.168.99.100

لذا أواجه المشكلة التالية التي قد تكون مرتبطة بهذا.
فقط من أجل أن أكون واضحًا ، أدير Docker Beta for Mac 1.12.0-beta21 (build: 10868) .

بشكل أساسي لا يمكنني الاتصال من المضيف إلى الحاوية باستخدام عنوان IP 172.17.0.2 ، لأنه لا توجد واجهة docker0 مع عنوان 172.17.0.1 المعين.

الحاوية عبارة عن صورة ubuntu وهنا المعلومات ذات الصلة بالشبكة

root<strong i="12">@app</strong>:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:524 errors:0 dropped:0 overruns:0 frame:0
          TX packets:370 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:217502 (217.5 KB)  TX bytes:40451 (40.4 KB)

root<strong i="13">@app</strong>:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 eth0

المضيف هو MacbookPro وكما ترى في المقتطف التالي أنه لا يحتوي على docker0 (أو أي واجهة لهذه المسألة) بعنوان IP 172.17.0.1 ، والذي تم تعيينه في الحاوية كـ البوابة.

robert<strong i="19">@localhost</strong> $ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 ::1 prefixlen 128
    inet 127.0.0.1 netmask 0xff000000
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
    ether f4:5c:89:c9:be:0d
    nd6 options=1<PERFORMNUD>
    media: autoselect (<unknown type>)
    status: inactive
en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
    options=60<TSO4,TSO6>
    ether 6a:00:02:06:b7:f0
    media: autoselect <full-duplex>
    status: inactive
en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
    options=60<TSO4,TSO6>
    ether 6a:00:02:06:b7:f1
    media: autoselect <full-duplex>
    status: inactive
p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304
    ether 06:5c:89:c9:be:0d
    media: autoselect
    status: inactive
awdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1484
    ether 0e:f1:f1:4d:46:88
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether f6:5c:89:9c:e6:00
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x2
    member: en1 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 5 priority 0 path cost 0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 6 priority 0 path cost 0
    nd6 options=1<PERFORMNUD>
    media: <unknown type>
    status: inactive
en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
    ether 39:c9:87:45:22:ee
    inet6 fe80::3ac9:86ff:fe40:22de%en4 prefixlen 64 scopeid 0x9
    inet 192.168.1.123 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=1<PERFORMNUD>
    media: autoselect (1000baseT <full-duplex,flow-control>)
    status: active

يعمل بعض الزملاء بشكل صحيح على مضيفي Ubuntus ، لذلك أعتقد أن هذا إما مشكلة في Mac أو بيئة محلية.
اي فكرة؟

robertoestivill غير متأكد من حالة الاستخدام بالضبط ، ولكن إذا نشرت الحاوية منفذًا ، فيمكنك الوصول إليها من خلال localhost:port

nikdavis إذا كنت تريد عنوان IP ثابتًا ، فيمكنك إضافة عنوان IP (أي عنوان لن تقوم lo0 لنظام التشغيل Mac واستخدام ذلك.

مرحبًا ، imho ، هذا فرق كبير في عامل الإرساء على نظام Linux. هناك الكثير من الوثائق التي لا تنطبق ببساطة. أنا أيضًا لست على دراية بالشبكة بما يكفي لمعرفة كيفية إرفاق عنوان IP آخر بـ lo0 ثم ماذا. سيكون من المفيد حقًا إذا كان هناك وصف للحلول البديلة (التي لا تتضمن boot2docker) لهذه المشكلة مع ذكرها في المستندات.

justincormackchanezon هل يمكننا العمل معًا على هذا للحصول على بعض المستندات الجيدة حول هذه المشكلة؟

@ pourquoi42
يمكنك إضافة عنوان IP آخر إلى واجهة lo0 كما يلي:
CONTAINER_IP = $ (Docker inspect --format '{{.NetworkSettings.IPAddress}}' اسم الحاوية)
ifconfig lo0 الاسم المستعار $ CONTAINER_IP

لإزالته:
ifconfig lo0 -alias $ CONTAINER_IP

itilk لا يبدو أنه يعمل على MacOs. تمت المحاولة مع names و container id .

robert<strong i="9">@work</strong>:~ $ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
d047790e196a        group/name              "/bin/bash"         About a minute ago   Up About a minute                       jovial_goodall

robert<strong i="10">@work</strong>:~ $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' jovial_goodall

robert<strong i="11">@work</strong>:~ $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' d047790e196a

robert<strong i="12">@work</strong>:~ $

كان لدي Docker 1.12.0 (بناء 10871) يعمل على داروين ،
1) كل حاوية عامل الميناء تعمل بشكل جيد ؛
2) يمكن للحاوية التواصل مع المضيف ؛
3) الاتصال بين الحاويات يعمل بشكل جيد ؛

أين هي الواجهة الافتراضية docker0 ؟ أو هل هناك أي طريقة تسمح للمضيف بالاتصال بالحاويات؟

من المحزن قراءة هذا: القيود المعروفة على OSX

Known Limitations
There is no docker0 bridge on OSX
Because of the way networking is implemented in Docker for Mac, you cannot see a docker0 interface in OSX. This interface is actually within HyperKit.

I can’t ping my containers
Unfortunately, due to limtations in OSX, we’re unable to route traffic to containers, and from containers back to the host.

حتى الآن ، لدينا طريقة واحدة فقط لتوصيل المضيف بالحاوية : Port Mapping

Version 1.12.0-beta21 (build: 11019)
1) كل حاوية عامل الميناء تعمل بشكل جيد.
2) لا يمكن للحاوية التواصل مع المضيف.
3) الاتصال بين الحاويات يعمل بشكل جيد.
4) docker0 غير متوفر.

Ad.2)

لدي مثيل hugo يرتبط بـ 0.0.0.0 على المنفذ 1313 . إرجاع curl من داخل الحاوية قيد التشغيل: curl: (7) Failed to connect to 172.19.0.1 port 1313: Connection refused .
استخدام عنوان IP الذي تم إرجاعه بواسطة ifconfig en0 | grep "inet " | cut -d " " -f2 لا يعمل أيضًا:
curl: (7) Failed to connect to 172.19.27.228 port 1313: No route to host .

تحية للجميع،

لقد عثرت على مقال من منتج حاوية آخر ( وليس عامل إرساء ): https://www.flockport.com/using-flockbox-with-xhyve/ ، ولم أختبره أيضًا إذا كان يعمل بالفعل.

في النهاية يذكر:

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

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

إذا كان عنوان VM IP الخاص بك هو 192.168.64.3 والشبكة الفرعية للحاوية 10.0.3.0/24 ، فيمكنك إنشاء مسار بأمر مثل أدناه

sudo route -n add 10.0.3.0/24 192.168.64.3

يقوم Xyhve بإنشاء واجهة bridge100 تلقائيًا لشبكات الأجهزة الظاهرية. قم بتشغيل ifconfig سريعًا للتحقق من تشغيل واجهة bridge100 ، على سبيل المثال en4 ، ثم قم بتشغيل الأمر أدناه.

sudo ifconfig bridge100 -hostfilter en4

الآن يجب أن تكون قادرًا على اختبار اتصال أي حاوية داخل الجهاز الظاهري مباشرةً من المضيف

ping 10.0.3.175

للوصول إلى التطبيق على متصفح Hosts ، قم بتحرير ملف / etc / hosts على المضيف كما هو موضح أعلاه مع إعادة توجيه المنفذ ولكن هذه المرة اربط عنوان IP للحاوية بعنوان URL للتطبيق.

آسف لأن لديّ معرفة دقيقة بمواد شبكات لينكس ، لكن هل هذا حل بديل؟

لا أعرف كيفية الحصول على عنوان IP الخاص بـ vm (alpine with docker) يعمل داخل xhyve ، أي أفكار؟

مرحبًا Kaijun ، لم

junjiemars لا ، المقالة التي نشرتها ليست متعلقة

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

Kaijun ، أعلم أنه قد تكون هناك طريقة لاختراق xhyve لإنجاز المهام ، إذا قمت بذلك ، فيرجى مشاركة القرصنة الخاصة بك.

nikdavis @ إذا كنت تريد عنوان IP ثابتًا ، فيمكنك إضافة عنوان IP (أي عنوان لن تقوم

justincormack هل تمانع في أن تكون أكثر دقة في كيفية تحقيق ذلك؟ :)
جربت ما نشرته itilk ، لكنها لم تنجح معي.

بشكل عام: هل هناك وقت محدد لوقت لإعادة تقديم شبكة docker0 في docker لنظام التشغيل mac beta؟

شكرا

georgehrke يمكنك عمل sudo ifconfig lo0 alias 10.200.10.1/24 - من الواضح أن اختيار عنوان لن تجده محليًا. ثم يمكنك استخدام هذا العنوان للتحدث مع المضيف بغض النظر عما إذا كان لديك اتصال بالشبكة أم لا.

آسف لعدم ذكر مشكلتي بشكل أكثر دقة.

لا أحاول الاتصال من الحاوية بالمضيف ، ولكن العكس.
لا يمكنني الاتصال من مضيفي إلى حاوية مباشرة.

كنت أستخدم docker inspect container_name للحصول على IP.
لكن لا يمكنني اختبار اتصاله أو فتحه في متصفح على الرغم من أن ملف Dockerfile يحتوي على خادم ويب و EXPOSE 80 فيه

نعم ، هناك قضيتان منفصلتان مرتبطتان إلى حد ما.

1. أريد الاتصال من حاوية إلى خدمة على المضيف. يحتوي جهاز Mac على عنوان IP متغير أو لا شيء إذا لم يكن لديك وصول إلى الشبكة.

التوصية الحالية هي إرفاق عنوان IP غير مستخدم بواجهة lo0 على جهاز Mac ، على سبيل المثال sudo ifconfig lo0 alias 10.200.10.1/24 ، تأكد من أن خدمتك تستمع إلى هذا العنوان أو 0.0.0.0 (أي ليس 127.0.0.1 ). ثم يمكن للحاويات الاتصال بهذا العنوان.

1. أريد الاتصال بحاوية من جهاز Mac.

التوصية الحالية هي نشر منفذ ، أو الاتصال من حاوية أخرى. لاحظ أن هذا ما عليك فعله حتى على Linux إذا كانت الحاوية على شبكة تراكب وليست شبكة جسر حيث لا يتم توجيهها.

نحن نتفهم أن هذه ليست مثالية ولكن هناك العديد من المشكلات ، على وجه الخصوص خطأ في OSX تم إصلاحه فقط في الإصدار 10.12 والذي لا يتم نقله إلى الخلف بقدر ما يمكننا معرفة ما يعني أنه لا يمكننا دعم هذا في جميع OSX المدعومة الإصدارات. بالإضافة إلى ذلك ، سيتطلب إعداد الشبكة هذا الوصول إلى الجذر الذي نحاول تجنبه تمامًا في Docker for Mac (لدينا حاليًا مساعد جذر صغير جدًا نحاول إزالته).

( @ londoncalling هل تريد إضافة هذا الملخص إلى المستندات؟)

@ justincormack تقصد أن كل --net=host على macOS Docker عديم الفائدة؟

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

@ justincormack هل هنا بعض الحلول لهذه المشكلة على الأقل في الوقت الحالي؟ إذا كان Docker يمتلكه ، أعتقد أنه سيكون من المفيد جدًا كتابته في الوثائق.

justincormack يمكنني إضافة

londoncalling بالتأكيد سوف نرسل لك بعض.

في 30 أغسطس 2016 ، 6:28 مساءً ، كتب "Victoria" [email protected] :

justincormack https://github.com/justincormack يمكنني إضافة الكتابة الخاصة بك
إلى المستندات ، ولكن أعتقد أنه يجب علينا تضمين بعض الأمثلة المحددة. سوف احاول
من نفسي ، ولكن ربما سأحتاج إلى مساعدتك أو مساعدة شخص آخر. سوف
أعود إليك فيما أعمل عليه.

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

@ justincormack شكرًا - بالنظر إلى هذا الموضوع ، أعتقد أننا بحاجة إلى مثالين على الأقل ، وربما حتى ثلاثة ، كما هو موضح أدناه. ما رأيك؟

1. مثال على كيفية الوصول إلى خدمة على مضيف Mac من حاوية (على سبيل المثال ، هل من الممكن أن يكون التطبيق خادم ويب مثل nginx متصل بقاعدة بيانات redis على المضيف؟)
2. مثال على الاتصال بحاوية من جهاز Mac. هل يغطي المثال الحالي run ؛ على سبيل المثال ، docker run -d -p 80:80 --name webserver nginx ؟ justincormack ولكن يجب أن نظهر ذلك مع تعيين المنفذ وبدونه حسب تعليق
3. مثال على كيفية تشغيل تطبيق في حاوية واحدة تستخدم خدمة في أخرى (على سبيل المثال ، كرر المثال nginx plus redis ولكن هذه المرة قم بتشغيل redis في حاوية؟

An example of connecting to a container from the Mac. Does our current nginx example cover the second case, since we expose a port in the run command; i.e., docker run -d -p 80:80 --name webserver nginx?

سأكون ممتنًا حقًا كمثال على الاتصال من Mac إلى الحاوية التي لا تتضمن Portmapping. تقوم حالة الاستخدام الخاصة بي بتشغيل مجموعة ميسوس للتنمية المحلية. إذا كان portmapping هو الطريقة الوحيدة لإنجاز اتصال مباشر من Mac إلى حاوية (تابع) ، فإنه يتطلب عملاً إضافيًا للتأكد من أن كل عملية mesos التابعة تعمل على منفذ فريد بحيث يمكن لأي وصول من Mac (عرض السجلات لتصحيح الأخطاء ، لـ مثال) يتوافق مع المنافذ التي يستخدمها mesos داخليًا (وإلا فإن أطر عمل mesos تقدم عناوين URL إلى لوحات المعلومات بأرقام منافذ داخلية لا تعمل من المضيف).

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

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

justincormack لقد قرأت كل الخيوط التي تحاول معرفة كيفية الاتصال من جهاز mac الخاص بي إلى الحاوية ، تمامًا كما أفعل في Linux: container-ip: 8080 على سبيل المثال. بقدر ما أفهم أن هذا يجب أن يكون ممكنًا في MacOS (10.12) ، أليس كذلك؟

matiasserrano يمكنك القيام بذلك باستخدام portmapping على سبيل المثال docker run -p 8080:8080

@ m1ome نعم ، أعرف ذلك. لكنها ليست قابلة للتطوير بالنسبة لي. أنا مطور وعادة ما أقوم بتشغيل عدة حاويات مع apache / Nginx ، لذلك 80 قيد الاستخدام دائمًا. إذا فعلت ما تقترحه ، فأنا بحاجة أولاً إلى تعطيل apache في جهاز mac الخاص بي ، وثانيًا أحتاج إلى تشغيل حاوية واحدة في كل مرة لأنهما يشتركان في نفس المنفذ. استخدام منافذ مختلفة ليس خيارًا.
من ناحية أخرى ، نعطي الحاويات للمطورين لبدء العمل ، ومرة ​​أخرى يمكنهم العمل في أكثر من مشروع واحد في نفس الوقت.
لذا فإن إمكانية الاتصال من Mac إلى الحاويات باستخدام IP الخاص بها أمر لا بد منه بالنسبة لنا.

matiasserrano لماذا لا تستخدم -P لإعادة توجيه المنافذ المكشوفة إلى منفذ عالي تعسفي تلقائيًا؟ إذا كنت تبحث عن عنوان IP للحاوية عبر شيء مثل docker inspect فمن الممكن أيضًا القيام بعملية مشابهة جدًا للمنفذ المكشوف.

nathanleclaire المشكلة لا تتعلق بمعرفة المنفذ أو عنوان IP الخاص بالحاوية ، إنها في الأساس نفس حل

بالنسبة لما يستحق ، لدي حالة استخدام مماثلة مثل weaver (أي الوصول المباشر إلى شبكة الحاويات من المضيف). أقوم بتشغيل مجموعة Spark عبر Docker ، على شبكتها الخاصة. أستخدم جهاز الإرساء وأضف مسارًا ثابتًا عبر واجهة docker0 للشبكة الفرعية التي يستخدمها الكتلة.

يتوفر Spark UI على العقدة الرئيسية ، ويتضمن روابط HTML إلى جميع العقد العنقودية الأخرى (عبر عنوان IP الخاص بهم). من خلال إضافة المسار الثابت ، يمكنني الوصول إلى Spark UI على الجهاز الرئيسي مباشرةً من جهاز التطوير الخاص بي ، والروابط التي تنشئها من خلالها إلى العقد الأخرى في الكتلة تعمل جميعها فقط. تعني هذه الروابط أيضًا أنها ليست مجرد حالة إعادة توجيه المنفذ 7080 لكي يعمل السيد بدون docker0 - أحتاج إلى أن أكون قادرًا على الوصول إلى الشبكة بالكامل بطريقة ما.

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

nathanleclaire المشكلة لا تتعلق بمعرفة المنفذ أو عنوان IP الخاص بالحاوية ، إنها في الأساس نفس حل

أنا لا أفهم.

قول انت:

لذا فإن إمكانية الاتصال من Mac إلى الحاويات باستخدام IP الخاص بها أمر لا بد منه بالنسبة لنا.

لماذا عناوين IP مختلفة على وجه التحديد؟ أنت تصف تعارضات الموانئ بأنها المشكلة هنا:

أنا مطور وعادة ما أقوم بتشغيل عدة حاويات مع apache / Nginx ، لذلك 80 قيد الاستخدام دائمًا. إذا فعلت ما تقترحه ، فأنا بحاجة أولاً إلى تعطيل apache في جهاز mac الخاص بي ، وثانيًا أحتاج إلى تشغيل حاوية واحدة في كل مرة لأنهما يشتركان في نفس المنفذ.

مع -P لن تعرض حاويتان نفس المنفذ ، حتى لو كانوا جميعًا يستمعون إلى 80 داخليًا. فلماذا لا تزال بحاجة إلى تعطيل Apache وما إلى ذلك؟

حل آخر هو إنشاء VM متشرد لكل مشروع وتشغيل عامل ميناء داخل أو استخدام جهاز عامل ميناء ، وهذا في الأساس هو نفسه. كلا الحلين غير مقبول بالنسبة لنا. نحن نفضل استخدام Vagrant بدلاً من ذلك.

إذا كنت مصرًا على استخدام Vagrant ولن تستخدم Docker Machine أو Docker لنظام التشغيل Mac ، فلماذا الملف / المناقشة هنا؟

nathanleclaire في Linux ، باستخدام الحاويات التي أنشأتها ، إذا أردت ، يمكنني تشغيل 4 حاويات في نفس الوقت ، على سبيل المثال ، هذا المنفذ 80. IE: واحد لـ Magento ، وواحد لـ Drupal ، وواحد لـ Larabel وآخر نظيف اباتشي.

سيكون لكل حاوية عنوان IP ، على سبيل المثال ، 192.100.200.1 و 192.100.200.2 و 192.100.200.3 و 192.100.200.4.

باستخدام عناوين IP هذه ، أقوم بإضافة مضيف إلى ملف / etc / hosts الخاص بي ، مع اسم مستعار لكل منها ، على سبيل المثال:

192.100.200.1 magento.local
192.100.200.2 drupal.local
192.100.200.3 لارابيل محلي
192.100.200.4 اباتشي محلي

ثم الدخول إلى الخوادم مباشرة من المتصفح.

في Mac ، لا يمكنني فعل ذلك ، لأنني لا أستطيع الحصول على IP لكل حاوية. استخدام -P ليس خيارًا ، لأنه بدلاً من وجود اسم مستعار لكل حاوية ، سأحتاج إلى استخدام شيء مثل localhost: 8012 ، لـ Magento ، localhost: 9823 لـ drupal وما إلى ذلك.

حل آخر هو استخدام المتشرد مع Linux VM لكل حاوية تقوم بتشغيل الحاوية بداخلها واستخدام تعيين المنفذ 80:80. مع هذا الحل ، لا معنى لـ Docker ، لأنني إذا قمت بإنشاء آلة Vagrant ، بنفس الأشياء الموجودة في حاوية عامل الإرساء ، فهي نفسها. (أعرف الفروق بين Docker و Vagrant ، وأنا أفضل Docker بدلاً من Vagrant 100 مرة ...)

آمل أن تساعدك حالة الاستخدام هذه في فهم سبب أهمية حصولنا على عنوان IP للحاوية.

المثال مع المنفذ 80 ولكنه ينطبق على أي منفذ تريده.

matiasserrano حسنًا ، أظن أنه قد يكون مرتبطًا

كانت تواجه نفس المشكلة (الاتصال بالمضيف من الحاوية). استخدام 192.168.65.1 يعمل معي. لست متأكدًا تمامًا ما هذا ولكني أعتقد أنه يظهر لفترة وجيزة في سجل pinatathalesfsp :

🐳  network = hostnet (docker-ipv4=192.168.65.2, host-ipv4=192.168.65.1)
   Controls how local containers can access the external network via the
   MacOS X host. This includes outbound traffic as well as publishing ports
   for external access to the local containers.

(شكرًا feedthefire على إظهار هذا لي!)

إذا كنت مصرًا على استخدام Vagrant ولن تستخدم Docker Machine أو Docker لنظام التشغيل Mac ، فلماذا الملف / المناقشة هنا؟

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

شكرًا cpoonolly ، إجابتك مفيدة جدًا ، لكنني أعتقد أن الحل الذي تقدمه يعمل في الاتجاه المعاكس: تحاول الحاوية الاتصال بـ Mac Host. ما أحتاجه هو العكس تمامًا: يحاول Mac Host الاتصال بالحاويات باستخدام IP الخاص بهم.

مرحبا يا اصدقاء. لقد انتشرت هذه المشكلة في مجموعة متنوعة من الاتجاهات وأنا أقترح على مسئولي الرصيف / عامل الميناء إغلاقها وتقسيمها إلى عدة مشكلات فرعية. على سبيل المثال ، واحد للوصول إلى IP الخاص بجهاز Mac من داخل D4M VM ، والآخر لقابلية العنونة IP لكل حاوية (على الرغم من أنني سأجادل في أن هذا قد يكون أفضل لأنه يدعم ببساطة تعيين DNS / اسم المضيف للحاوية في D4M). على الأرجح في Docker for Mac repo لأن هذا هو مستودع "المحرك" ، ومن الناحية المثالية يجب أن يكون لديه تذاكر حول مخاوف Engine على Linux / Windows في المتعقب.

لما يستحق ، هناك جسر _definitely_ docker0 في Docker for Mac VM. يمكنك رؤيتها بنفسك إذا قمت بتشغيل حاوية بـ --net host وتشغيل ifconfig . لا تتعلق المشكلات المختلفة هنا بما يوحي به العنوان الأصلي ، على الرغم من ذلك: إنها تدور حول شبكة الحاويات وأجهزة VM والرؤية.

icecrimejustincormack ما رأيك. شكرا لكم جميعا.

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

أنا موافق!!!! لا مشكلة إذا فعلت ذلك!

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

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

لذلك إذا قمت بإضافة

192.100.200.1 magento.local
192.100.200.2 drupal.local
192.100.200.3 larabel.local
192.100.200.4 apache.local

إلى /etc/hosts ثم يمكنك القيام بما يلي:

sudo ifconfig lo0 alias 192.100.200.1/24
sudo ifconfig lo0 alias 192.100.200.2/24
sudo ifconfig lo0 alias 192.100.200.3/24
sudo ifconfig lo0 alias 192.100.200.4/24

ثم

docker run -p 192.100.200.1:80:80 magento
docker run -p 192.100.200.2:80:80 drupal
...

ثم يجب أن تكون قادرًا على الاتصال مباشرة بـ drupal.local إلخ.

londoncalling يجب علينا توثيق هذا لمستندات بيتا التالية.

@ justincormack nitpick : هل هذه الكتلة صحيحة؟

$ ifconfig lo0 alias 192.100.200.1/24
$ ifconfig lo0 alias 192.100.200.2/24
$ ifconfig lo0 alias 192.100.200.2/24
$ ifconfig lo0 alias 192.100.200.2/24

يجب أن يكون الأخيران 192.100.200.3 و 192.100.200.4 ؟ ولماذا الاسم المستعار سيدر بالكامل ( 192.100.200.1/24 هو النطاق الكامل 192.100.200.0 عبر 192.100.200.255 أليس كذلك؟)؟ هل يجب أن يكون عنوان IP واحدًا فقط؟

الخطأ المطبعي آسف. نعم ، /32 جيد أيضًا.

justincormack هل سيكون DNS في واجهة GUI في أي وقت قريبًا؟ نظرًا لأن beta25 لا يزال يتعذر عليه حل أسماء DNS عبر Split-tunnel vpn ، كنت أتمنى تشغيل dnsmasq على مضيف mac الخاص بي. يمكن الوصول إلى جميع المنافذ الأخرى على جهاز Mac الخاص بي عبر 192.168.65.1 من داخل الحاويات ولكن ليس نظام أسماء النطاقات.

لماذا أيضًا يقوم عامل الإرساء بتعيين 10 ip's [192.168.65.1 إلى 10] في /etc/resolv.conf؟
ملاحظة: لا تستخدم 192.100.xx لأن هذا نطاق عام. استخدم 192.168.xx

نحاول تجنب إضافة DNS إلى الواجهة ، ولكن فقط اقرأ ملف
الإعدادات من جهاز Mac. نقرأ ملف المضيفين لكننا سنقرأ جميع ملفات
الإعدادات قريبا.

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

في 11 سبتمبر 2016 ، الساعة 7:09 مساءً ، كتب "Jijo Varghese" [email protected] :

justincormack https://github.com/justincormack هل سيكون DNS في واجهة المستخدم الرسومية
واجهة في أي وقت قريب؟ منذ beta25 لا يزال يتعذر حل أسماء DNS
عبر Split-tunnel vpn كنت أتمنى تشغيل dnsmasq على مضيف mac الخاص بي. كل الآخرين
يمكن الوصول إلى المنافذ الموجودة على جهاز Mac الخاص بي عبر 192.168.65.1 من داخل الحاويات ولكن
لا نظام أسماء النطاقات.

لماذا أيضًا يقوم عامل الإرساء بتعيين 10 ip's [192.168.65.1 إلى 10] في /etc/resolv.conf؟
ملاحظة: لا تستخدم 192.100.xx لأن هذا نطاق عام. استخدم 192.168.xx

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

أريد فقط أن أشكر justincormack على هذا:

نعم ، هناك قضيتان منفصلتان مرتبطتان إلى حد ما.

1. أريد الاتصال من حاوية إلى خدمة على المضيف. يحتوي جهاز Mac على عنوان IP متغير أو لا شيء إذا لم يكن لديك وصول إلى الشبكة.
   التوصية الحالية هي إرفاق عنوان IP غير مستخدم بواجهة lo0 على جهاز Mac ، على سبيل المثال sudo ifconfig lo0 alias 10.200.10.1/24 ، تأكد من أن خدمتك تستمع إلى هذا العنوان أو 0.0.0.0 (أي ليس 127.0.0.1). ثم يمكن للحاويات الاتصال بهذا العنوان.

في حين أنه ليس مثاليًا ، يجب أن يعمل هذا بالنسبة لنا في الوقت الحالي (تم اختباره وعمله)

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

نحاول تجنب إضافة DNS إلى الواجهة ، ولكن فقط اقرأ الإعدادات من جهاز Mac.
مجموعات VPN متنوعة ومعقدة ، لذا سيكون من قصر النظر افتراض أنه يمكنك دائمًا قراءة الإعدادات الصحيحة. https://github.com/docker/for-mac/issues/19 (مغلق) لا يزال معطلاً بالنسبة لنا على شبكة VPN ذات النفق المقسم. من المحتمل أنها ليست مشكلة عامل ميناء ولكن فقط كيف يقوم خادم vpn الخاص بنا بتقسيم DNS.

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

نحن نعمل على دعم خادم الأسماء المقسم لـ VPN.

في 13 سبتمبر 2016 6:48 مساءً ، كتب "Jijo Varghese" [email protected] :

justincormack https://github.com/justincormack

نحاول تجنب إضافة DNS إلى الواجهة ، ولكن فقط اقرأ ملف
الإعدادات من جهاز Mac.
مجموعات VPN متنوعة ومعقدة ، لذا ستكون قصيرة النظر
افترض أنه يمكنك دائمًا قراءة الإعدادات الصحيحة. عامل ميناء / for-mac # 19
https://github.com/docker/for-mac/issues/19 (مغلق) لا يزال مكسورًا
بالنسبة لنا على Split-tunnel vpn. ربما لا تكون مشكلة عامل ميناء ولكن كيف
يقوم خادم vpn الخاص بنا بتقسيم DNS.

مرة أخرى ، على سبيل المثال في مكاني السابق ، كنا نقول لأفراد QA و Dev أن يشيروا
إلى خوادم أسماء مختلفة اعتمادًا على الحسد الذي يريدون ضربه. لو كان ذلك
نوع الاختبار مطلوب فقط داخل Docker ثم هذا استخدام آخر
حالة للنظر. شكر.

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

شكرًا جزيلاً justincormack ، يمكنني استخدام الحل البديل الخاص بك للوصول إلى جميع lo0 ، مما يجعلني أعمل مع Docker لنظام التشغيل Mac: +1:

أنا أستخدم docker-compose لتشغيل حاوياتي ، لذا فإن التجاعيد الأخيرة تحتاج إلى تكوين إعادة توجيه المنفذ للربط بعنوان IP الصحيح على المضيف ، لكل حاوية. (سيؤدي الربط بـ 0.0.0.0 إلى تعارضات المنافذ عندما يكون لدي أكثر من حاوية واحدة).

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

(نقدر أننا نبتعد عن الإصدار الأصلي هنا).

NoOrdInaryGuy يجب أن يعمل هذا على أحدث الإصدارات (المستقرة lo0 .

@ justincormack نعم ، يمكنني أن أؤكد أن هذا يعمل بنجاح. المشكلة الوحيدة هي عند استخدام docker-compose (خاصة مع القياس ، أو أعتقد أنه يمكنك فقط تكوين العناوين الثابتة). لا يمكن إضافة port-forward بعد بدء الحاوية ، ولست على دراية بأي طريقة للإشارة إلى عنوان IP الفعلي للحاوية إلى ملف الإنشاء / Dockerfile في "وقت التشغيل" ، وهو ما أعتقد أنني سأحتاجه بالترتيب لتكوين المنفذ إلى الأمام للاستماع على IP الصحيح.

أنا أعمل على حل هذه المشكلة في الوقت الحالي من خلال عدم استخدام docker-compose في هذا السيناريو ، وامتلاك برنامج نصي مخصص bash لاستدعاء عامل الإرساء ، لكني تساءلت إذا كان أي شخص آخر قد فكر في حل أفضل.

يبدو هذا واعدًا.

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

لذلك عادة ، نحن فقط "نكشف" المنافذ ، ثم نستخدم "فحص عامل الإرساء" لاكتشاف عنوان IP للحاوية والاتصال بمنافذ الخدمة على عنوان IP هذا. عندما يريد المطورون تجربة الاختبارات على Mac ، كنا نستخدم خدعة boot2docker لإضافة مسار ثابت للحاويات من خلال VirtualBox VM.

كنت أشاهد Mac Beta على أمل أن نتمكن من الوصول إلى المنافذ المكشوفة باستخدام طريقة مماثلة ، وتبدو خدعة الاسم المستعار lo0 هذه مثل التذكرة.

ربما لا يكون هذا هو المكان المناسب لطلب ميزة ، لكنني كنت أتساءل عما إذا كان من الممكن إضافة عنوان IP كمدخل إلى خيار Docker run publish-all. سيبدو مثل هذا أنا:

sudo ifconfig lo0 المستعار 10.200.10.1/32
Docker run --publish-all 10.200.10.1 -d --name webserver my_test_image

ثم إذا كان هناك العديد من المنافذ EXPOSED في my_test_image ، يمكنني الوصول إليها من خلال الاسم المستعار IP.

يمكنني تأكيد docker0 المفقود في أحدث docker-mac

MacBook $ docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.7.1
 Git commit:   6f9534c
 Built:        Thu Sep  8 10:31:18 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 17:52:38 2016
 OS/Arch:      linux/amd64
MacBook$ docker info
Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 107
Server Version: 1.12.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 133
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.20-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.953 GiB
Name: moby
ID: W53J:DFZB:4SCO:CS34:6CRF:FCDR:74RZ:TBJC:WZ35:QUVW:NZQU:7ANZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 17
 Goroutines: 29
 System Time: 2016-09-26T00:20:31.292958501Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

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

يُرى docker0 إذا كان مضيفي Linux ؛ إنه مفقود فقط مع docker-mac. كما أنني لا أرغب في استخدام virtualbox لتشغيل عامل ميناء على ماك.

كما هو موضح في المستند: تم إصلاح بعض أنواع الأخطاء في الإصدار 10.12.2

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

لذا أود أن أسأل ، هل قام Docker بالفعل بإصلاح هذه المشكلة في الإصدار 10.12؟ أو لم يحدث ذلك بعد ، لتوافق جميع الإصدارات.

Kaijun لا ، نحتاج إلى دعم العديد من إصدارات OSX ، والطريقة التي كنا نقوم بها من قبل لها إصدارات أخرى ، لذلك من غير المرجح أن نعود إليها.

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

لقد رأيت تعليقات حول كيفية وجود مشكلة مع OS X (هنا وفي سلاسل رسائل أخرى). لا يمكنني العثور على وصف قوي لما هي المشكلة بالفعل ، ولماذا تم إصلاح 10.12 ، وما إلى ذلك.

(1) لماذا يعمل هذا لشيء مثل Virtualbox / Docker-machine ولكن ليس مع xhyve؟

(2 أ) حتى إذا كان عامل الإرساء لا يدعم هذه الميزة فقط لـ 10.12 ، فهل هناك شيء يمكنني القيام به إذا قمت بتشغيل 10.12 لاختراقه وجعله يعمل؟

(2 ب) ما هي "المشاكل الأخرى" مع "الطريقة التي كنا نقوم بها من قبل"؟

أنا آسف حقًا إذا كانت هذه أسئلة غبية (أو إذا كانت الإجابة موجودة بالفعل في هذا الموضوع وقد فاتني).

شكر.

weaver كنا vmnet على https://github.com/docker/hyperkit والذي يقوم بإنشاء جسر لـ VM ، والذي يسمح بالتوجيه من الحاويات إلى المضيف على IP على الجسر. على الرغم من أنه لا يسمح بالتوجيه إلى الحاويات بشكل مفيد. كان هناك CVE مرتبط بهذا الأمر الذي يعرض خادم DNS مفتوحًا عند التمكين ، والذي تم إصلاحه في Sierra.

هناك العديد من العيوب الأخرى لوضع vmnet: لا يوجد دعم IPv6 ، القليل من التحكم ، علينا أن نعمل كجذر ، لا يعمل مع العديد من إعدادات VPN ، وأكثر من ذلك. بدأنا في استخدام "وضع VPN" كخيار ، والذي أصبح الخيار الافتراضي الحالي ، ثم تمت إزالة الخيار الآخر بعد مشكلة الأمان.

لم يتم تطبيق خيار أن جسر docker0 يبدو سحريًا على جهاز Mac وليس على Linux VM ، كما أنه غير ممكن حقًا ، بنفس الطريقة التي لا يتوفر بها إذا كنت تستخدم مضيفًا بعيدًا أيضًا . ومع ذلك ، فقد أصبح الأشخاص يعتمدون على طرق مختلفة يمكنهم من خلالها استخدام إعدادات توجيه مختلفة ، ونود أن نحاول استيعاب بعض حالات الاستخدام هذه ، ولكن ليس من السهل جدًا القيام بذلك. يقوم برنامج Virtualbox بتثبيت وحدات kernel في نظام التشغيل Mac للقيام بذلك ، وهو ما لن نقوم به.

مرحبا،

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

لذلك لكل من يريد ذلك فقط: قم بإزالة docker for mac ، قم بتثبيت docker toolbox وتشغيل شيء مثل:
sudo route -n إضافة 172.17.0.0/24 192.168.99.100
حيث إن 172.xxx هي شبكة عامل الإرساء المكونة في مضيف VirtualBox و 192.xxx هي عنوان IP الفعلي من هذا المضيف القابل للتوجيه على نظام التشغيل mac (عبر واجهة شبكة VirtualBox).
إنه ببساطة يوجه حركة المرور بشكل صحيح.

هل يمكن إضافة ذلك إلى وثائق عامل الميناء؟

منذ أن أعطاني ما ورد أعلاه ما أريد ، لم أقم بمزيد من البحث في xhyve.
ألن يكون الحل هو إدخال أمر مشابه لما سبق ، يعمل مع إعداد الشبكة من ذلك؟ لم أتمكن من اختبار اتصال العنوان 192.168.65.x ، لذلك لن تعمل إضافة المسار. إذا قام شخص ما بنشر الأمر لتمكين ذلك ، فيجب أن يعمل أمر التوجيه أيضًا.

تم حل المشكلة؟ سيكون من الرائع أن يتم توثيقها حيث تصف قيود mac.
شكرا لك

justincormack @ dmp42 @ jeanlaurent ، هل يمكنك إلقاء نظرة على تعليق VGerris أعلاه مباشرةً ، واسمحوا لي أن أعرف كيف / أين تريد هذا التوثيق: Toolbox و d4mac؟

هل من الممكن أن يتم إصلاح ذلك لـ 10.12 وإلقاء خطأ / تحذير إذا لم يكن الإصلاح المطلوب 10.12 موجودًا على النظام؟ يمكنك بعد ذلك توثيق الحل البديل / etc / host أو الأدوات للأشخاص الذين يشغلون الإصدار 10.11.

تعد قدرة Imho على الوصول إلى شبكة الحاويات من المضيف دون إعادة توجيه المنفذ أو التكوين اليدوي للشبكة ميزة أساسية لـ docker. حقيقة أن هذا لا يعمل كما هو متوقع هو بالفعل مشكلة كبيرة.

justincormack - لا يزال لا يعمل

مكرر من فوق.

نحاول تجنب إضافة DNS إلى الواجهة ، ولكن فقط اقرأ ملف
الإعدادات من جهاز Mac.

مجموعات VPN متنوعة ومعقدة ، لذا سيكون من قصر النظر افتراض أنه يمكنك دائمًا قراءة الإعدادات الصحيحة.

justincormack ، لم تقدم أي حل لمستخدمي Docker لنظام التشغيل mac ، فإن الوصول إلى عنوان IP

أيضا libvmnet ليس جيدًا ، لكنه حل ، sudo مقبول من لا شيء !!!

لا يحتاج حل جهاز الصنبور إلى إذن سودو. على الأقل ، يجب أن يوفر docker for mac طريقة اختراق للسماح للمطور بشق طريقه. على سبيل المثال ، يمكن تخصيص وسيطة الأمر hyperkit بواسطة المستخدمين.

في الوقت الحالي ، يعد عامل الإرساء لنظام التشغيل mac عديم الفائدة تقريبًا للناس.

القرف !

هل هناك أي مشهد حول ما إذا كان سيتم إصلاح هذا أو متى سيتم ذلك؟

justincormack : بالإضافة إلى ذلك ، سيتطلب إعداد الشبكة هذا الوصول إلى الجذر الذي نحاول تجنبه تمامًا في Docker for Mac (لدينا حاليًا مساعد جذر صغير جدًا نحاول إزالته).

لماذا ا؟ على نظام Linux لا يمكن تشغيل عامل ميناء بدون امتيازات الجذر وكل شيء على ما يرام ، على OSX تريد تجنب ذلك. ما هو سبب ذلك؟ لذا من الآن فصاعدًا ، يجب أن يكون docker for OSX مثل تطبيق facebook ، ولا يهم أن الميزة الأساسية لا تعمل ، لكنها لا تتطلب امتيازات الجذر؟

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

هل حل وسط مقبول هو اعتبار هذه ميزة متقدمة. وعندما يتم تمكين الميزات المتقدمة فإنها تتطلب امتيازات إضافية؟

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

الآن ، عندما يريد أحد المطورين الاتصال بـ MySQL على أجهزتهم المحلية ، يتعين عليهم إلقاء نظرة على مخطط لمعرفة المنفذ الفريد للمشروع. المشروع A هو 3307 ، المشروع B هو 3308 ماذا كان Project Q مرة أخرى؟ يعتبر منفذ التوزيع العشوائي قذرًا أيضًا لأنه لا يسمح لك بحفظ إعدادات الاتصال وما شابه. ما زلت بحاجة إلى البحث عنها طوال الوقت.

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

+1 ، بأمس الحاجة: - /

لقد اكتشفت للتو الوثائق الموجودة على https://docs.docker.com/docker-for-mac/networking/ لذلك فهمت التحديات التي ينطوي عليها الأمر.

لسوء الحظ ، يعد هذا عائقًا كبيرًا لاستخدام عامل ميناء محلي في بيئة التنمية المحلية لدينا. كنت أتمنى الهجرة بعيدًا عن Virtualbox / Vagrant.

مشكلتنا هي أننا نستخدم القنصل لاكتشاف الخدمة. بالنسبة للتنمية المحلية ، نريد تشغيل مزيج من الخدمات من Docker-compose ومباشرة من IDEs للمطور على Mac. نظرًا لأن الخدمات التي تعمل في الحاويات تسجل لدى القنصل باستخدام docker ip: port ، فلا يمكن دمج الخدمات التي تعمل خارج عامل الإرساء.

بالطبع هذه أيضًا مشكلة في مجموعة متعددة المضيفين ، ولكن يتم حلها إما عن طريق الشبكات المتراكبة (أو في حالتنا ، نص برمجي لنقطة دخول الاستبطان بشكل بغيض يحدد عنوان IP المضيف: تعيينات المنفذ).

يبدو أنه يتم العمل أخيرًا على واجهة برمجة تطبيقات الاستبطان للمساعدة في حل هذا النوع من المشكلات (https://github.com/docker/docker/issues/7472). نأمل أن تعمل واجهة برمجة تطبيقات الاستبطان مع عامل التحميل لنظام التشغيل mac / windows أيضًا).

مرحبًا يا رفاق ، أعتقد أن هناك شيئًا يستحق المشاركة فيما يتعلق بهذا الموضوع ، فنحن قادرون على التحدث إلى الجهاز host من داخل الحاويات باستخدام default IP تم إنشاؤه بواسطة Docker for Mac/Windows .

IP هو 192.168.65.1

يمكنك اختباره باتباع الخطوات التالية:

rogaha@MacBook-Pro:~/development/rogaha$ docker run --name docker-nginx -p 80:80 -d nginx                                
4bc4818c49cffd7b4186294c71e6d4608c0482fd74521b3e9d03a14d499b3e6b
rogaha@MacBook-Pro:~/development/rogaha$

rogaha@MacBook-Pro:~/development/rogaha$ docker run -it --rm tutum/curl curl 192.168.65.1                                                                                   5:52:22
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
rogaha@MacBook-Pro:~/development/rogaha$

اتمني ان يكون مفيدا!

rogaha هذه معلومات مثيرة للاهتمام. هل هذا موثق في مكان ما؟ كيف تعرف ذلك؟

لقد أكدت محليًا على جهاز Mac الخاص بي أنها تصل بالفعل إلى المضيف (وليس مجرد حاوية Docker أخرى) عبر 192.168.65.1 .

لست متأكدا. thaJeztahjustincormack هل يحدث أن تعرف؟

نعم ، تمت إضافة هذا المسار لدعم الاتصال بالمضيف.

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

في 27 فبراير 2017 ، الساعة 08:49 ، "Roberto Gandolfo Hashioka" [email protected]
كتب:

لست متأكدا. thajeztah https://github.com/thaJeztah justincormack
https://github.com/justincormack هل تعرف؟

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

rogaha 192.168.65.1 لا يعمل على نهايتي. كيف عرفت عن عنوان IP هذا؟

أردت فقط إضافة + 1 / اشتراك مع أي شخص آخر في هذا الموضوع ، وإضافة صوت آخر إلى طلب الميزة المتمثل في القدرة على الوصول بسهولة إلى حاويات عامل التحميل من خلال واجهة الجسر على عناوين IP الفريدة / المخصصة.

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

في الوقت الحالي ، يبدو أن الحل الذي ذكره justincormack (https://github.com/moby/moby/issues/22753#issuecomment-246054946) يعمل بشكل جيد. أقوم بإضافة دعم Docker التجريبي إلى Drupal VM باستخدام الإرشادات:

1. أضف مضيفًا إلى /etc/hosts مع sudo /etc/hosts (مثل 192.168.1.100 mysite.dev )
2. أنشئ اسمًا مستعارًا على واجهة الاسترجاع: sudo sudo ifconfig lo0 alias 192.168.1.100/24

3. أحضر وعاءًا يحتوي على الغرض الكاذب التالي:

     version: "3"
   
     services:
       app:
         image: image-name
         ports:
           - 192.168.1.100:80:80
           - 192.168.1.100:443:443
         [...]
   

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

لذا نشكرك على الحل البديل ، وآمل أن تتمكن من العثور على طريقة لتشغيل شبكة الجسر قريبًا (أو التخلي عن macOS <10.12 😏)

rogaha شكرًا جزيلاً لك ، 192.168.65.1 قد حل

TheAntonioReyes أنا سعيد لأنه عمل من أجلك. شكرا على ملاحظاتك!

مرحبا،

أقرأ المستندات هنا: https://docs.docker.com/docker-for-mac/networking/#use -cases-and-workarounds ، وأحاول استخدام _the اسم DNS الخاص بنظام Mac فقط _ المذكور هناك : docker.for.mac.localhost .

إذا قمت بإجراء اختبار ping على محطة طرفية داخل حاوية عامل الإرساء ، فسيتم حلها إلى 192.168.65.1 ، ويقوم إجراء تجعيد لتطبيق يعمل على جهاز Mac الخاص بي باسترداد النتيجة المتوقعة.

أنا أستخدم هذه الصورة: https://github.com/elgalu/docker-selenium ، ويمكنني فتح متصفح Chrome هناك. لذلك أردت الذهاب إلى http: //docker.for.mac.localhost : 80 ، وتم رفض الاتصال. ومع ذلك ، القيام http://192.168.65.1 : 80 عمل.

هل فاتني شيء؟ أردت أن أبدأ في استخدام docker.for.mac.localhost .

أنا أستخدم هذا: الإصدار 17.06.0-ce-mac18 (18433)

تحرير : يبدو أن هذا يحدث فقط على Chrome وهذه المشكلة تشرح ذلك. https://github.com/docker/for-mac/issues/1837

أعتقد أن استخدام docker.for.mac.localhost كان قرارًا سيئًا. بيت القصيد من الحاويات هو أنها محمولة و _يجب_ ألا تعتمد على نوع المضيف الذي تقيم فيه. إذا كان فريقي من نصف مستخدمي Windows ونصف Mac ، فسيتعين تكوين الكود الموجود داخل حاوياتنا بشكل مختلف.

أنا سعيد لوجود نهج اسم المضيف ، أعتقد فقط أن الاجتماع الذي تقرر فيه هذا النهج كان ينبغي أن يستمر 5 دقائق أخرى.

docker.for.mac.localhost . مضحك جدا. https://docs.docker.com/docker-for-mac/networking/#use -cases-and-workarounds

لقد عملت على حل هذه المشكلة من خلال العودة إلى آلة الإرساء لنظام التشغيل Mac. آلة عامل الإرساء VM هي توزيعة Linux مما يعني أنها تنشئ واجهة docker0 التي يمكنها الوصول إلى نطاق الشبكة الخاصة لحاويات عامل التحميل. بعد ذلك ، على جهاز mac المضيف الخاص بي ، قمت بإنشاء مسار لنطاق عناوين 172.18.xx للحاويات الذي يشير إلى عنوان IP لمثيل جهاز عامل الإرساء (192.168.99.100 في حالتي).

يسمح ذلك بإعادة توجيه الحزم المخصصة لشبكة الحاويات الخاصة بواسطة نظام التشغيل Mac الخاص بي إلى عنوان IP الخاص بجهاز التشغيل linux VM الخاص بجهاز الإرساء ، والذي يعرف كيفية الوصول إلى الحاويات الخاصة وإعادة توجيه الحزم إليها مباشرةً.

إنشاء المسار إلى جهاز الإرساء vm لشبكة الحاويات الخاصة

sudo route -n add -net 172.18.0.0/16 192.168.99.100

يمكنك الحصول على عنوان شبكة الحاويات باستخدام docker network inspect أو docker inspect <container_name> .

يمكنك العثور على ip الخاص بالمضيف في docker for mac عن طريق تشغيل هذا الأمر:

docker run busybox ping -c 1 docker.for.mac.localhost | awk 'FNR==2 {print $4}' | sed s'/.$//'

قم بتشغيل هذا الأمر

docker run -i -d --expose=80 <container_name> bash

ثم احصل على عنوان IP من

docker ps

إذا كان يشير إلى 0.0.0.0 ، فسيعمل بشكل جيد بمجرد كشف المنفذ أو كتابة أي عنوان IP آخر هناك.

الحل في الواقع بسيط نسبيًا ؛ IDK لماذا لا يصلح Docker ذلك.

راجع https://github.com/AlmirKadric-Published/docker-tuntap-osx للحصول على حل بديل يحرك ثنائي hyperkit.

نسخة جزئية من # 155 (و # 171 ، # 515 ، # 3484).

أنا أغلق. هذا حسب التصميم ولا علاقة له على أي حال بهذا الريبو.

ما يلي يعمل بشكل رائع بالنسبة لي. لا توجد حاويات وسيطة ، ولا يوجد حل بديل لنظام أسماء النطاقات.

من https://github.com/AlmirKadric-Published/docker-tuntap-osx#how -it-works:

بمجرد الانتهاء من ذلك ، يمكن استخدام عنوان IP 10.0.75.2 كبوابة توجيه شبكة للوصول إلى أي حاويات داخل الجهاز الظاهري المضيف:
route add -net <IP RANGE> -netmask <IP MASK> 10.0.75.2

شكرا لك pauldraper (!).

pauldraper علق في 14 يوليو 2019

الحل في الواقع بسيط نسبيًا ؛ IDK لماذا لا يصلح Docker ذلك.

راجع https://github.com/AlmirKadric-Published/docker-tuntap-osx للحصول على حل بديل يحرك ثنائي hyperkit.

إصدار macOS الخاص بي:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.6
BuildVersion:   18G3020
$