Moby: وثق كيفية الاتصال بمضيف Docker من الحاوية

تم إنشاؤها على ٥ يوليو ٢٠١٣  ·  263تعليقات  ·  مصدر: moby/moby

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

سيكون من الرائع توثيق هذا السلوك وكيفية ارتباطه بـ docker0 .

التعليق الأكثر فائدة

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

ال 263 كومينتر

عندما تنظر داخل network.go تجد أن عامل الإرساء يحقق للشبكات الداخلية التي لم يتم توجيهها.

تم تخمين أول 172.16.42.1 كعنوان جسر ثم عناوين أخرى.

لذا فإن توثيق هذا لن يساعد كثيرا. إنه مخطط ديناميكي لا يمكنك الاعتماد عليه.

أعتقد أن ما تحتاجه هو أكثر طريقة لتحديد العناوين المستخدمة للجسر والعميل.
هل يمكن أن يكون ذلك؟

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

+1 سيكون من الرائع حقًا أن يكون لديك طريقة جيدة للاتصال بالنظام المضيف

+1 ، سيحدد الفرع 1.0 واجهة برمجة تطبيقات الاستبطان بحيث يمكن لكل حاوية أن تتفاعل مع المضيف بطريقة محددة ومنضبطة.

هذا مخطط حاليًا لـ 0.8.

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

يوم الخميس ، 8 أغسطس 2013 الساعة 1:10 مساءً ، EJ Bensing [email protected]
كتب:

+1 سيكون من الرائع حقًا أن يكون لديك طريقة جيدة للاتصال بالنظام المضيف

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/dotcloud/docker/issues/1143#issuecomment -22351792

فكيف يمكنني الاتصال بمضيف عامل الإرساء من داخل الحاوية؟ أحاول الاتصال بحاوية عامل إرساء عبر منفذ المضيف بدلاً من عنوان IP الخاص بالحاوية.

gerhard : تم التخطيط لواجهة برمجة تطبيقات الاستبطان 0.8. وفي الوقت نفسه ، إذا كنت ترغب في الوصول إلى Docker API من الحاويات ، فيمكنك إعداد Docker للاستماع إلى عنوان IP الخاص بجسر Docker.

للقيام بذلك ، سوف تقوم بما يلي:

  • إنشاء جسر

ip link add docker0 type bridge

  • قم بتعيين عنوان IP لها

ip link set docker0 up
ip addr add 172.17.0.1/16 dev docker0

  • بدء عامل الإرساء وربط API بالجسر

docker -d -H 172.17.0.1:4242

يمكنك الآن الوصول إلى Docker API من حاوياتك.

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

لمناقشة الاختراقات والحلول للميزات المفقودة ، أوصي إما بالقائمة البريدية _docker-user_ أو القناة _ # docker_ irc على Freenode.

قرصنة سعيدة

shykes هل هناك مشكلة أخرى تتعقب إنشاء مثل هذه الميزة ، في هذه الحالة؟

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

لقد بعت بالفعل على قيمة هذه الميزة :)

يوم الاثنين 2 ديسمبر 2013 الساعة 9:09 صباحًا ، Caleb Spare [email protected]
كتب:

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

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/dotcloud/docker/issues/1143#issuecomment -29636528

أنا على Fedora 20 مع Docker 0.7.2 ، حيث أقوم بإعداد Docker UI . اضطررت إلى فتح المنفذ الذي يستمع إليه Docker daemon حتى لا يحظره جدار الحماية:

  • جدار الحماية - cmd - دائم - المنطقة = موثوق - واجهة إضافة = عامل إرساء 0
  • جدار الحماية - cmd - دائم - المنطقة = موثوق - منفذ إضافة = 4243 / tcp

بعد ذلك ، تمكن _docker-ui_ من الاتصال بمقبس التحكم في برنامج Docker daemon.

HTH
هذه حاجة واضحة وشرعية لمثل هذه الميزة.

أنا آسف ، إذا كنت أحتفظ بخيط صلب متين على قيد الحياة.

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

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

باستخدام البوابة مقابل 0.0.0.0 من netstat -nr بالتأكيد لم أواجه أي مشاكل في الوصول إلى خادم يعمل على الجهاز المضيف. أظن أن بوابة IP ثابتة (بمجرد بدء تشغيل عامل الإرساء) ، هل يمكن لأي شخص تأكيد ذلك؟

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

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

بالنسبة لأولئك الذين يتطلعون إلى العثور على بوابة IP من الحاوية ، ربما يكون /proc/net/route هو المكان المناسب لقراءته.

يتضمن الدافع لهذه الميزة خدمات البيانات الوصفية المتنوعة. الكشف عن الأشياء من خدمة البيانات الوصفية ec2 سيكون أمرًا رائعًا. توزيع بيانات الاعتماد والبيانات المنظمة الأكثر تعقيدًا التي لا تتناسب مع متغيرات البيئة.

jonasfj : هناك بالفعل طريقة أسهل ، والآن بعد أن أصبح Docker يدعم ربط الملفات من مضيف إلى حاوية. يمكنك ربط مقبس تحكم Docker ، على سبيل المثال: docker run -v /var/run/docker.sock:/var/run/docker.sock … ؛ هذا أسهل من العبث بقواعد التواصل.

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

1) على "المضيف" ، يتم تشغيل خدمة على المنفذ 8080 (قل "etcd")
2) من هذا المضيف ، يتم تشغيل حاوية عامل ميناء
3) كيف يمكن الوصول إلى الخدمة على المنفذ 8080 على المضيف من حاوية عامل التحميل؟ ماذا سيكون عنوان URL / IP؟

jpetazzo كيف يأتي إعداد docker.sock للعب لحل المشكلة المذكورة أعلاه؟

vrvolle ، كشف docker.sock لا يحل المشكلة الأصلية التي وصفهاbkad.
ولكن قد يعرض المرء مقبسًا مختلفًا لمجال يونكس للاتصال بين المضيف وحاوية عامل الإرساء.

على سبيل المثال ، إذا كنت تريد كشف mysql من المضيف ، فستكشف عن مقبس mysql: /tmp/mysql.sock .

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

كان علينا فقط قراءة "مآخذ مجال unix".
لكن:

http://stackoverflow.com/questions/14771172/http-over-af-unix-http-connection-to-unix-socket

يدعي عدم وجود عنوان URL ، وبالتالي لا يمكن لأي عميل عادي استخدام هذه الآلية خارج الصندوق.

من ناحية أخرى:

http://stackoverflow.com/questions/14771172/http-over-af-unix-http-connection-to-unix-socket

يوضح أنه من الممكن بطريقة ما استخدام مثل هذا المقبس.

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

 netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'

هل يجب إنشاء عدد جديد أو يمكن لشخص ما إعادة فتح هذه المشكلة.

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

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

هناك طرق متعددة لمعالجة ذلك ، اعتمادًا على ما تريد تحقيقه بالضبط.

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

تتمثل إحدى الطرق في الاعتماد على حقيقة أن مضيف Docker يمكن الوصول إليه من خلال عنوان جسر Docker ، والذي يعد البوابة الافتراضية للحاوية. بمعنى آخر ، قد يكون كل ما تحتاجه في هذه الحالة هو التحليل الذكي لـ ip route ls | grep ^default . بالطبع ، يعتمد على تفاصيل التنفيذ (تصادف أن تكون البوابة الافتراضية هي عنوان IP لمضيف Docker) والتي قد تتغير في المستقبل.

هناك طريقة أخرى وهي استخدام Docker API لاسترداد تلك المعلومات. بعد ذلك ، تصبح المشكلة "كيف يمكنني الاتصال بـ Docker API من حاوية؟" ، والحل المحتمل (الذي تستخدمه العديد والعديد من الحاويات هناك!) هو ربط التركيب /var/run/docker.sock من المضيف إلى الحاوية. هذا له جانب سلبي كبير: تصبح واجهة برمجة التطبيقات متاحة بالكامل للحاوية ، مما قد يؤدي إلى حدوث أشياء سيئة بها.

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

TL ، DR: على المدى القصير ، تحقق من المسار الافتراضي للحاوية. على المدى الطويل ، ستكون هناك واجهة برمجة تطبيقات استبطان رائعة.

لدي أيضا مشكلة بسبب مغرور. لا يمكنني العثور على أي شيء في /var/run/docker.sock. واستخدمت الأمر "-v /etc/run/docker.sock:/etc/run/docker.sock" ولكن لم يحدث شيء.
أعتقد أن هذه مشكلة بسبب بعض التحديثات الجديدة حول قدرات kernel. من فضلك أعطني ملاحظة موجزة حول هذه المسألة. والأمر الكامل لحل هذا. شكرا

use -v /var/run/docker.sock - not / etc (والذي عادة ما يكون محجوزًا لملفات conf).

أي تحديث حول هذا في الإصدار 1.0.0 الجديد؟

يوجد nsenter - لكنني أعتقد أن الطريقة المشجعة هي تشغيل sshd عند هذا الحد
المسرح.

في يوم الجمعة ، 13 يونيو 2014 ، كتب Camilo Aguilar [email protected] :

هل من أخبار عن هذا في الإصدار 1.0.0 الجديد؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/dotcloud/docker/issues/1143#issuecomment -45958769.

مايكل دي نيل
المنزل: www.michaelneale.net
المدونة: michaelneale.blogspot.com

vrvolle ، شكرًا على ذلك. يبحث الكثير من الأشخاص مثلنا عن شيء من هذا القبيل

netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'

التحديث التلقائي لـ Docker /etc/hosts على كل حاوية مع IP المضيف ، على سبيل المثال 172.17.42.1 واستدعاءها على سبيل المثال dockerhost سيكون إصلاحًا مناسبًا.
أعتقد أننا عالقون الآن مع netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'

+1 لـ dockerhost بـ /etc/hosts

+1 لـ dockerhost in / etc / hosts ، تبدو فكرة جيدة

يجب ألا يتم تحرير ملف في صورة أبدًا ما لم يتم تقديم وسيطة أو علامة على وجه التحديد للقيام بذلك. أيضًا ، ليس من الضروري أن تتبع 100٪ من الصور LSB ، لذلك قد لا يكون هناك دليل /etc . يجب أيضًا تحديد اسم الملف المراد استخدامه لاحتواء عنوان IP للمضيف بواسطة وسيطة الأمر.

docker --host /etc/hosts

+1 لـ dockerhost in / etc / hosts

+1 لدخول / ec / hosts

Sepero docker يقوم بالفعل بملء / etc / hosts بالحاويات المرتبطة ، لذا فإن وسيطاتك لا تصمد بالفعل.

matleh هذا صحيح ، لكنني أعتقد أن الطريقة الصحيحة ليست تعبئة / etc / hosts مباشرةً ، أو على الأقل اترك لنا تحديد الموقع في حالة عدم توفره.

على أي حال ، دخول dockerhost في المضيفين.

أرغب أيضًا في الحصول على IP لمضيف عامل الإرساء بـ /etc/hosts .

+1 على IP مضيف عامل الإرساء في / etc / hosts

ربما تكون أفضل طريقة لتسهيل الوصول إلى خدمات الشبكة على المضيف هي تسهيل إعداد إدخالات iptables التي تعيد توجيه المنافذ في الاتجاه المعاكس ، أي من الحاوية إلى المضيف. أعتقد أن الخيار -p أو --publish سيتم استكماله بشكل جيد بخيار -s أو --subscribe الذي له تأثير عكسي. أعتقد أنني كنت سأدعوهم - للأمام والعكس ، رغم ذلك. أيا كان ما تسميه ، يبدو لي أن هذا نهج أكثر اتساقًا من الاقتراحات الأخرى هنا.

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

#!/bin/bash
HOSTNAME=$(hostname)
HOST_IP=$(ip route | awk '/docker/ { print $NF }')
docker run -e HOST=$HOSTNAME -e HOST_PORT=tcp://$HOST_IP:8000 mycontainer

سيكون هذا موازيًا بشكل أساسي للطريقة التي يعمل بها --link . لا يزال يعتمد على الجسر الذي له اسم يطابق /docker/ وهناك جسر واحد فقط ، ولكن يتم تعيين الجسر عند بدء تشغيل Docker daemon. سيكون من الرائع لو أعطانا docker info اسم الجسر المستخدم و / أو عنوان IP للمضيف. هناك فكرة أخرى تتمثل في إضافة خيار --link-host PORT إلى docker run والذي من شأنه أن يؤدي بشكل أساسي إلى ما سبق.

IMO هذا هو الخيار الأفضل. باستخدام --link-host ، لن تحتاج الحاوية إلى معرفة ما إذا كانت الخدمة التي تصل إليها موجودة على المضيف أو في حاوية أخرى.

لست متأكدًا من كيفية استدعاء الآخرين لحاوياتهم ولكن عندما أقوم بتشغيلها باستخدام --net=host ، فأنا قادر على رؤية نفس إعداد الشبكة مثل مضيف عامل الإرساء. بدون هذا المحول ، أحصل على مكدس شبكة مستقل ، كما هو موضح في صفحات الرجل docker-run .

$ docker run -i --net=host fedora ip route ls
default via 10.0.2.2 dev eth0  metric 1
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
127.0.0.1 dev lo  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1
192.168.59.0/24 dev eth1  proto kernel  scope link  src 192.168.59.103

يؤدي التشغيل بدون المفتاح إلى ما يلي:

$ docker run -i fedora ip route ls
default via 172.17.42.1 dev eth0
172.17.0.0/16 dev eth0  proto kernel  scope link  src 172.17.0.4

ما نبحث عنه هو طريقة للحصول على عنوان IP إما 10.0.2.15 (IP الخاص بمضيف عامل الإرساء eth0 i / f) أو 172.17.42.1 (عنوان IP الخاص بجسر docker0 الخاص بي في docker0 i / f).

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

+1 مقابل --link-host أو بطريقة بديهية أخرى

+1 لإدخال / etc / hosts
يبدو مناسبًا جدًا ويتبع اتفاقيات الاتصال الحالية.

فقط لتوضيح تعليقاتي السابقة: الشيء الرائع في --link <container>:<alias> هو أنه يعرض _خدمة_ من خلال _alias_. وبالمثل ، يجب أن توفر آلية تعريض المضيف للحاوية الوصول إلى خدمة معينة ، وليس فقط عنوان IP. يمكن للحاوية الوصول إلى هذه الخدمة عبر اسم مستعار ؛ لا يحتاج إلى معرفة مكان الخدمة حقًا. يجب أن يحتوي الخيار على دلالات عكسية لـ -p ويتصرف مثل --link . بمعنى آخر ، سيقوم --link-host <ip address>:<port>:<alias> بإعداد متغيرات env وإدخال /etc/hosts ، وسيقوم بإعداد مدخلات iptables حسب الضرورة ، أي إذا كانت الخدمة على المضيف تستمع على عنوان IP الذي لا يمكن الوصول إليه بطريقة أخرى في الحاوية.

altaurog ماذا عن شيء مثل هذا؟

docker run --name someservice -d host-exposing-image --expose 8000

سيكون someservice أي اسم يمكنك بعد ذلك --link له ، و host-exposing-image سيكون صورة خاصة تعيد توجيه منافذ المضيف على المنافذ المكشوفة. من المحتمل أن تكون الفكرة قابلة للتنفيذ من خلال مشاركة /var/run/docker.sock للمضيف مع الصورة.

ربما شيء مثل هذا موجود بالفعل ، dunno.

يحرر:

docker run --name someservice -d --expose 8000 host-exposing-image

ننسى ما ورد أعلاه ، لم تقرأ جميع التعليقات هنا (ما زلت لم تقرأ). هذا ما يناسبني على docker-osx (وآسف لعدم الإرسال إلى القائمة البريدية بدلاً من ذلك):

docker run --rm -ti -e HOST_IP="$(docker-osx ssh -c 'route -n' 2> /dev/null |
  awk '/^0.0/ { print $2 }')" debian:jessie

+1. --link-host فكرة جيدة بالإضافة إلى وجود إدخال dockerhost في /etc/hosts

لقد أنشأت مشكلة جديدة نظرًا لإغلاق هذه المشكلة (ولكن لم يتم حلها): # 8395

+1 مقابل dockerhost أو بأي طريقة ملائمة أخرى.

+1 لأي ​​طريقة مريحة

نظرًا لأن الأسلوب dockerhost حصل على بعض الأصوات هنا ، فإن أسهل طريقة وجدت (من التعليقات على المشكلات الثلاثة ذات الصلة # 8395 # 10023) للحصول على إدخال المضيفين هي إضافة الوسيطة --add-host=dockerhost:$(ip route | awk '/docker0/ { print $NF }') عند تشغيل الصورة ، على سبيل المثال:

run --add-host=dockerhost:$(ip route | awk '/docker0/ { print $NF }')  ubuntu ping -c2 dockerhost

بينما يضيف هذا الإدخال المطلوب / etc / hosts ، فإنه لا يزال من العار ألا يكون dockerhost موجودًا بشكل افتراضي. عند توزيع صورة لدي خيار إما

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

أنا شخصياً لا أفهم سبب عدم وجود dockerhost بشكل افتراضي ، فهذا سيجعل إنشاء وتوزيع الصور التي تصل إلى الخدمات عادةً على المضيف (XServer ، CUPS ، Puleaudio) أكثر ملاءمة.

+1 لـ Dockerhost. أود في الواقع أن أعرض هذا كإدخال env var ، / etc / hosts و cli flag. لا بد من استخدامه بعدة طرق.

: +1: لـ Dockerhost

داخل الحاوية الخاصة بك:

cat << EOF > /etc/profile.d/dockerhost.sh
 grep dockerhost /etc/hosts || echo $(ip r ls | grep ^default | cut -d" " -f3) dockerhost >> /etc/hosts
EOF

يعمل من أجلي كلما قمت بتسجيل الدخول (مع حساب الجذر)

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost: yum:

+1 لـ Dockerhost

+1 لـ Dockerhost: +1:

انتهى الأمر بكتابة هذا النص ، قد يجده أحدهم مفيدًا:

#!/bin/bash

SED="$(which sed)"
NETSTAT="$(which netstat)"
GREP="$(which grep)"
AWK="$(which awk)"
CAT="$(which cat)"


$SED '/dockerhost$/d' /etc/hosts > /etc/hosts.tmp
DOCKERHOST="$($NETSTAT -nr | $GREP '^0\.0\.0\.0' | $AWK '{print $2}')"

echo "$DOCKERHOST dockerhost" >> /etc/hosts.tmp

$CAT /etc/hosts.tmp > /etc/hosts

rm -rf /etc/hosts.tmp

+1 dockerhost

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

فتحت https://github.com/docker/docker/issues/8395 منذ بعض الوقت - مغلق أيضًا. لا يوجد حتى الآن حل موثق

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

نظرًا لوجود ميزة روابط عامل الإرساء ، فمن المنطقي أن أكون قادرًا على توفير رابط للمضيف.

أهلا!

لمعلوماتك هذا موثق الآن:

ملاحظة: تحتاج أحيانًا إلى الاتصال بمضيف Docker ، مما يعني الحصول على عنوان IP الخاص بالمضيف. يمكنك استخدام أوامر shell التالية لتبسيط هذه العملية:

$ alias hostip="ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print \$2 }'"
$ docker run --add-host=docker:$(hostip) --rm -it debian

شكرا ، icecrime.

هل يمكن لشخص عامل ميناء رجاء قفل هذه المشكلة حتى يتوقف الناس عن تحديثها؟

+1 لـ Dockerhost

+1 لـ dockerhost - الاضطرار إلى تشغيل اسم مستعار للأمر المحلي لا يتوافق مع مثال docker-compose و docker-swarm وما إلى ذلك.

+1 لـ Dockerhost

icecrime ، الذي يعطي بوابة المضيف وليس عنوان IP للمضيف على ubuntu الخاص بي. ألا يجب أن يكون الأمر أدناه فقط؟

$ ip address show

+1 ، شيء يمكن استخدامه دون الحاجة إلى تشغيل الأوامر سيكون مثاليًا

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

+1 لأي ​​شيء بسيط
راجع للشغل ، الحل البديل مع ip يعمل على Ubuntu الخاص بي ، لكنه لا يعمل على OS X ، أليس كذلك؟

+1 هذه مشكلة عمرها سنتان وميزة مفيدة. أريد طريقة سهلة للاتصال بـ docker remote api من داخل الحاوية.

ianchildress إذا كان لديك البرنامج الخفي مهيأ لقبول اتصالات المقبس ، فما عليك سوى ربط المقبس في الحاوية الخاصة بك ، على سبيل المثال docker run -d -v /var/run/docker.sock:/var/run/docker.sock myimage

+1 لـ Dockerhost
وجدت هذه المشكلة عند تصفح الحلول لاستخدام الحالة: xdebug.remote_host=dockerhost

+1 لـ Dockerhost

thaJeztah وكيف أحصل على اسم المضيف أو عنوان IP من هناك؟

mbonaci كنت أستجيب لـ ianchildress ، الذي أراد الاتصال بواجهة برمجة تطبيقات Docker داخل حاوية (والتي يعد استخدام اتصال مقبس هو الأسلوب العام لها)

انا مرتبك. icecrime أعلاه قال أعلاه أن هذا موثق الآن ، لكن الرابط الذي قدمه مات. لا يمكنني العثور بسرعة على الجزء المقتبس من الوثائق. ألاحظ أن مثال apt-cache-ng يستخدم dockerhost ، لكنه لا يحدد ما هو (# 11556). كان المرجع الوحيد الذي يمكن أن أجده بسهولة هو هذا الموضوع. لقد بحثت في كل مصدر ووثائق عامل الرصيف ولا يبدو أنه مذكور في هذا السياق .

pwaller منذ مارس ، قمنا بتقسيم هذا المستند الطويل الضخم إلى مراجع منفصلة. الموقع الجديد لهذه المادة هو:

http://docs.docker.com/reference/commandline/run/#adding -entries-to-a-container-hosts-file

+1 لـ Dockerhost

moxiegirl أعتقد أن المعلمة --add-host مرضية. شكرا

وكيف تتصل بالمضيف من حاوية عامل الميناء؟ على سبيل المثال ، لجعل git pull؟ بدون استخدام وحدات التخزين؟

@ a93ushakov كل هذا موضح في الرابط الذي قدمهmoxiegirl .
عندما تقوم بعمل docker run ، أضف المعلمة التالية: --add-host=dockerhost:replace_with_docker_host_ip ، والتي تنشئ إدخالاً في ملف /etc/hosts بالحاوية.
مما يعني بالطبع أنه يمكنك الرجوع إلى مضيف عامل الإرساء من داخل تلك الحاوية باستخدام اسمه dockerhost .

mbonaci > وهو ما يعني بالطبع أنه يمكنك الرجوع إلى مضيف عامل الإرساء من داخل تلك الحاوية باستخدام اسمه ، dockerhost.

من خلال ssh؟

thaJeztah > إذا كان لديك برنامج خفي مهيأ لقبول اتصالات المقبس ، ...
كيف نفعل ذلك؟

@ a93ushakov SSH: إذا قمت بتثبيته وتشغيله على المضيف (ولم يتم حظر منفذه) ، نعم.

@ a93ushakovhaJeztah يشير إلى اتصال مقبس يونكس. أعتقد أن هذا هو الإعداد الافتراضي - تحقق مما إذا كان لديك ملف /var/run/docker.sock على مضيفك.

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost
سيكون من الجيد الحصول على اسم المضيف هذا دون أي خطوات إضافية.

1 ل Dockerhost

+1 لـ dockerhost

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

$ hostip=$(ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print $2 }')
$ nc -l -p 1234 &
[1] 17361
$ docker run --add-host=docker:$(hostip) --rm -it hiromasaono/curl curl docker:1234
curl: (7) Failed to connect to docker port 1234: Connection refused

+1 لـ Dockerhost

عندما أقوم بإضافة IP لجسر Docker ، فإنه يعمل.

استمع أولاً على المنفذ 1234 باستخدام netcat

$ nc -l -p 1234

احصل على IP الخاص بالجسر

$ ifconfig docker0 | grep 'inet addr'
          inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0

ثم اتصل

$ docker run --add-host=docker:172.17.42.1 --rm -it hiromasaono/curl curl 172.17.42.1:1234

ثم أرى الرد

GET / HTTP/1.1
User-Agent: curl/7.35.0
Host: 172.17.42.1:1234
Accept: */*

+1 لـ Dockerhost
الجحيم متى؟

+1 لـ dockerhost الذي يعمل على Mac أيضًا ، أي التعامل مع VM بشفافية

هل يمكن لشخص ما أن يخبرني كيف سأتصل بـ Docker API من داخل الحاوية؟ أنا لست رجل لينوكس. لقد بدأت بالفعل الحاوية مع -v /var/run/docker.sock:/var/run/docker.sock.
كل شخص يتحدث عن كيفية القيام بالحمل ، لكن لم يذكر أحد كيفية استدعاء api بالداخل.

حاولت الاتصال باستخدام curl لم ينجح. لقد استخدمت IP المضيف على سبيل المثال

curl -XGET http: // hostip : 2375 / images / json

هذه هي الطريقة التي بدأت بها شيطاني. ie docker -H unix: ///var/run/docker.sock -H tcp: //0.0.0.0 : 2375

أي مساعدة سوف تكون محل تقدير كبير.

jprogn لا يُقصد بتتبع مشكلة github لأسئلة الدعم العامة ؛ من الأفضل طرح هذه الأسئلة في قناة #docker IRC ، أو مجموعة مستخدمي Docker على Google ، أو forums.docker.com

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

هل يمكن لشخص ما الرد على كيفية استدعاء docker api بالداخل من الحاوية ؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟

jprogn يرجى اتباع تعليقي أعلاه ؛ هذا هو أداة تعقب المشكلات ، وتستخدم لتتبع الأخطاء وطلبات الميزات ؛ ليس منتدى دعم لاستخدام عامل الإرساء ؛ استخدم الطرق الأخرى التي ذكرتها أعلاه https://github.com/docker/docker/issues/1143#issuecomment -146924892

+1 لـ Dockerhost

في مضيف عامل الإرساء CentOS7 الخاص بي ، لا يمكنني الحصول على مسار من الحاوية إلى المضيف:

[root@docker-host-fkb slehmann]# ifconfig docker0 | grep 'inet'

inet 172.17.42.1  netmask 255.255.0.0  broadcast 0.0.0.0
inet6 fe80::42:a7ff:fe4d:4cb2  prefixlen 64  scopeid 0x20<link>


[root@docker-host-fkb slehmann]# docker run --add-host=docker:172.17.42.1 --rm -it hiromasaono/curl curl 172.17.42.1:1234

curl: (7) Failed to connect to 172.17.42.1 port 1234: No route to host

أيه أفكار؟

+1 ، قد يكون هناك متغير بيئة لهذا الغرض.

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

+1 لمتغير بيئة dockerhost

من الصعب حقًا الجمع بين إدخال DNS مفصل للوصول إلى المضيف دون تشفير 172.17.42.1. على سبيل المثال

extra_hosts:
     - "docker:172.17.42.1"

+1 لـ Dockerhost أينما كان (/ etc / host of ENV)

+1 هذا لا يزال مطلوبًا!

+1 الخاصة بي أيضًا لأن إضافة ip route list dev eth0 | grep -Eo 'via \S+' | awk '{ print \$2 }' لكل مشروع (لأنه في المطورين ، جميع المشاريع في نفس المضيف وتحتاج إلى القدرة على الاتصال ببعضها البعض) بدأت تبدو وكأنها اختراق سيء

كيف يمكننا حل هذه المشكلة في مجموعة ، على سبيل المثال Docker Swarm ، حيث لا نعرف أي آلة سيتم تخصيص حاوية لها عند تشغيلها؟ يمكن أن يختلف عنوان IP لبوابة docker0 من مضيف إلى آخر داخل كتلة السرب ، لذلك لا يمكننا تشغيل الأمر ip route على مضيف واحد ثم نفترض أن عنوان IP هو نفسه لجميع المضيفين.

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

eval $(docker-machine env --swarm swarm-master-node)
docker run -d -p "$HOST_GATEWAY_IP:80:80" my-image

يتم استبدال $HOST_GATEWAY_IP بنفس عنوان IP الذي ستحصل عليه من تشغيل الأمر ip route على المضيف الذي يتم نشر الحاوية إليه في النهاية في المجموعة.

سيحتاج هذا إلى دعم لأية أوامر أخرى تتضمن IP ، على سبيل المثال الخيار --dns في docker run .

لقد وجدت أن هذا الأمر أسهل:

ip ro | grep docker | sed 's|.* \(\([0-9]\+\(.[0-9]\+\)\{3\}\)\)\s*|\1|'

+1 لـ dockerhost in / etc / hosts

+1 dockerhost

+1 لوجود مضيف في / etc / hosts

+1000 لـ Dockerhost

+1 dockerhost

+1

+1 أو أكثر.

أنا أقوم بتشغيل خادم ويب في حاوية وأحتاج إلى توصيله بـ mysql الخاص بي الذي يعمل على المضيف.
يتغير عنوان IP الخاص بالمضيف مع dhcp ، لذا فإن شيئًا ديناميكيًا أمر لا بد منه.

wederbrand من الأساليب البديلة (وربما الأفضل أداءً) الاتصال بمقبس mysql ، على سبيل المثال ؛

docker run -v /var/lib/mysql/mysql.sock:/mysql.sock mywebapp

سيؤدي ذلك إلى إتاحة مقبس MySQL كـ /mysql.sock داخل الحاوية

thaJeztah يمكن أن يكون هذا خيارًا. ومع ذلك ، فإن صورة عامل الإرساء التي أستخدمها تُستخدم أيضًا للبيئات الأخرى حيث يكون خادم mysql على خادم بعيد وتكون الصورة بها تكوين للمضيف: منفذ لقاعدة البيانات.

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

+1

+1

+1

+1

peterbollen @ radek1st برادرودرمان aldarundwederbrandpataiadamjlladogeniousphpcoreylenertz dgtlmoonxlight ( الكل +1 في ديسمبر 2015 وحده)
_ تم إغلاق هذا العدد وكذلك # 8395
لا أعتقد أن إضافة +1 إلى مشكلة قديمة ستساعد. أنشئ مسارًا جديدًا (فعلت مع # 8395) أو جرب طريقًا آخر لمعالجة هذا الأمر.

شكرا!

+1

+1 dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost ، هيا ...

+1 لـ Dockerhost

لا يوفر استخدام docker-compose وقياس حاويات n-ary في سرب بشكل طبيعي وسيلة لإجراء عمليات بحث عن عنوان IP للعقدة أثناء التنقل عبر جميع الأجهزة.

هذا ، كما هو مذكور أعلاه وتعديله على البوابة ، ليس خيارًا:

extra_hosts:
     - "docker:172.18.0.1"

👍 لـ Dockerhost أيضًا ...

+1 لـ Dockerhost

+1

+1

+1

+1 dockerhost

+1 dockerhost

+1 dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost.
منذ أن تم إغلاق هذه القضية فتح تذكرة جديدة.

+1

+1

للحصول على المضيف في إعداد docker-machine ، يمكنك استخدام هذا الأمر:

docker-machine ssh "${DOCKER_MACHINE_NAME}" 'echo ${SSH_CONNECTION%% *}'

يُبلغ عن الجهاز الذي تتصل به عبر ssh ، لذلك يجب أن يعمل بشكل جيد لكل من الأجهزة المحلية والآلات البعيدة ، طالما لا يوجد NAT على طول الطريق. سيكون من الجيد أن docker-machine inspect عن هذه القيمة في مكان ما أيضًا ، إذا كان ذلك ممكنًا من الناحية الفنية.

+1

+1 لـ Dockerhost. تبدو ميزة قيّمة بدون أي جهد عمليًا للتنفيذ.

في الوقت الحالي ، إذا كنت بحاجة إلى الوصول إلى dockerhost داخل الحاويات التي تم إنشاؤها من الصور التي تتحكم فيها ، فيمكنك إضافة هذا المحتوى إلى البرنامج النصي Entrypoint.sh لصورتك: https://gist.github.com/dimitrovs/493678fd86c7cdf0c88312d9ddb4906b

أو أعتقد أنه يمكنك إضافته إلى /etc/rc.local إذا كانت صورتك لا تستخدم برنامج شل النصي كنقطة دخول لها. ما يفعله هذا الجوهر هو أنه يتحقق من dockerhost in / etc / hosts ويضيفه إن لم يكن موجودًا. يجب أن يحدث ذلك في كل مرة تبدأ فيها الحاوية.

احصل على عنوان IP للبوابة من / proc / net / route:

export ipaddr=$(printf "%d." $(
  echo $(awk '$2 == "00000000" {print $3}' /proc/net/route) | sed 's/../0x& /g' | tr ' ' '\n' | tac
  ) | sed 's/\.$/\n/')

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

ما هي النتائج التي حصلت عليها @ amcdnl ؟ يمكنك إما وضع المضمون الذي ربطته في ملف entrypoint.sh بحيث يتم تشغيله في كل مرة تبدأ فيها الحاوية أو في /etc/rc.local داخل الحاوية. سيتعين عليك القيام بذلك عند إنشاء الصورة ، ولكن سيتم تنفيذ البرنامج النصي نفسه عند بدء تشغيل الحاوية.

+1 لمضيف عامل ميناء

dimitrovs انتهى بي الأمر بكتابة نص من شأنه أن يولد مؤلفًا في وقت التشغيل.

StartDocker.sh

#!/bin/bash
built_docker_file="docker-compose.dev.built.yml"

rm -rf docker-compose.dev.built.yml
localhost_ip="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"
sed -e "s/\${localhost}/$localhost_ip/" docker-compose.dev.template.yml > $built_docker_file

docker-compose -f $built_docker_file build
docker-compose -f $built_docker_file up

docker-compose.dev.template.yml

version: '2'

services:
  nginx:
    container_name: sw_nginx
    image: nginx:latest
    ports:
      - 80:80
    links:
     - search
    volumes:
      - ./Web/wwwroot:/var/www/public
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    extra_hosts:
      - "dockerhost:${localhost}"

@ amcdnl حل جيد. لاحظ أن docker-compose يدعم استبدال متغير (البيئة).

على سبيل المثال (باش):

$ export localhost=$(...)
$ docker-compose (...)

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

+1 لـ Dockerhost.

لكن في الوقت الحالي ، أقوم باختراق مشابه لما تم نشره أعلاه ، والذي يسمح لك بالحصول على عنوان IP للمضيف ديناميكيًا باستخدام برنامج نصي بسيط يعمل في كل من Linux و OSX : http://stackoverflow.com/questions/24319662/from-inside -من-أ-عامل-حاوية-كيف-دو-توصيل-مضيف محلي-من-الماك # 38753971

+1 لـ Dockerhost.

+1 لـ Dockerhost

+ 1 + 1 مرسى

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

لا يمكنني الاتصال بخادم netcat المضيف الأساسي من داخل حاوية عامل إرساء عند --net=bridge (الافتراضي) عبر التقنيات المختلفة التي تمت مناقشتها في هذه المشكلة.

frankscholten أنا غير قادر على إعادة إنتاج اختبار netcat الخاص بك

لقد قمت بعمل مشكلة في stackoverflow تصف المشكلة بالضبط: http://stackoverflow.com/questions/38936738/communicate-to-docker-host-from-docker-container
وأردت النشر هنا في حال كان ذلك مفيدًا لشخص ما في المستقبل

بينما يتحدث كل هذا عن الاتصال من حاوية إلى مضيف باستخدام docker0 ip في وضع الجسر ، أريد أن أعرف ما إذا كان بإمكان الحاوية أيضًا التحدث إلى عنوان IP العام للمضيف (على سبيل المثال ، eth0 ip الأصلي). نقدر ردك. أنا لم أنجح في هذا.

sburnwal لا أرى سبب عدم قدرتك على التواصل مع eth0 ip الخاص بالمضيف. سترسل الحاوية طلبًا إلى البوابة الافتراضية (docker0) ويجب على المضيف الرد دون إعادة توجيه إضافية لأنه يعلم أنه يحتوي على عنوان IP. هل انتهت مهلة الأصوات الخاصة بك إلى eth0 ip من الحاوية أم أنك لن تجد طريقًا إلى المضيف أو ما الذي يحدث؟ هل الحاوية قادرة على الاتصال بالإنترنت؟

للأسف هذا لا يعمل بالنسبة لي. بينما يمكنني إجراء اختبار ping لعنوان IP للحاوية من المضيف ، لا يمكنني إجراء اختبار ping للمضيف (LAN / eth0 الخاص بالمضيف) ip من الحاوية. أنا أستخدم Docker 1.9.1. أنا عالق هنا لأنني بحاجة إلى حاويتي للاتصال بخادم الويب الذي يستمع فقط على eth0 ip الخاص بالمضيف.

لقد قمت بتخصيص docker0 باستخدام الخيار:
/ bin / docker daemon --bip = 169.254.0.254 / 24 --fixed-cidr = 169.254.0.0 / 24

لذلك لدي هذه الواجهات على مضيفي (لا يتم سرد واجهات veth * هنا):

[root@pxgrid-106 irf]# ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtg 1500
        inet 169.254.0.254  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::42:84ff:fe87:d510  prefixlen 64  scopeid 0x20<link>
        ether 02:42:84:87:d5:10  txqueuelen 0  (Ethernet)
        RX packets 512  bytes 150727 (147.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 653  bytes 281686 (275.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtg 1500
        inet 172.23.166.176  netmask 255.255.255.128  broadcast 172.23.166.255
        inet6 fe80::20c:29ff:fecc:7d0f  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:cc:7d:0f  txqueuelen 1000  (Ethernet)
        RX packets 58462  bytes 12056152 (11.4 MiB)
        RX errors 0  dropped 69  overruns 0  frame 0
        TX packets 30877  bytes 18335042 (17.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

تحتوي الحاوية الخاصة بي على عنوان IP 169.254.0.2 ويمكنني اختبار اتصال IP للحاوية من المضيف. بالطبع ، يمكنني تنفيذ الأمر ping من الحاوية على بوابته 169.254.0.254 (docker0 ip) لكنني غير قادر على اختبار ping host eth0 ip 172.23.166.176.

لقد حاولت إيقاف جدار الحماية تمامًا وأضفت هذه القواعد الصريحة أيضًا إلى جدار الحماية إلى سلسلة INPUT ولكن لم يحالفني الحظ حتى الآن. من يمكنه مساعدتي في هذا؟ أم أن هذا الخلل ؟

ACCEPT     all  --  172.23.166.176       169.254.0.0/24      
ACCEPT     all  --  169.254.0.0/24       172.23.166.176   

بالإضافة إلى ذلك ، اسمح لي أيضًا بإعطاء إخراج "ip route" على مضيفي:

[root@pxgrid-106 bin]# ip route
default via 172.23.166.129 dev eth0 
169.254.0.0/24 dev docker0  proto kernel  scope link  src 169.254.0.254 
172.23.166.128/25 dev eth0  proto kernel  scope link  src 172.23.166.176 

@ tn-osimis شكرًا على الاقتراح ، لقد قمت بتحديث وأعمل بشكل جيد ، ها هي الكود الخاص بي للآخرين:

عامل ميناء compose.yml

version: '2'

services:
  nginx:
    image: nginx:latest
    ports:
      - 80:80
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    extra_hosts:
      - "dockerhost:${localhost_ip}"

StartDocker.sh

#!/bin/bash
dev_docker_file="docker-compose.yml"

export localhost_ip="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"

docker-compose -f $dev_docker_file build
docker-compose -f $dev_docker_file up

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

حل magicalbob ساحر بالفعل 🎉

+1 لـ Dockerhost

+1 ، بالمناسبة ، لماذا تم إغلاق هذا؟ لم يتم حل طلب المشكلة / الميزة حتى الآن

أي تحديثات على هذا؟ ما هي الطريقة الصحيحة ؟

+1

هل لدى أي شخص تحديث حول كيفية الاتصال بالمضيف (عنوان IP العام للمضيف مثل eth0 ip وليس docker0 واجهة IP) من الحاوية؟

sburnwal docker run --add-host=publicip:$(hostname --ip) ubuntu ping -c2 publicip

انظر إجابة retog

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

تركه هنا لأنه ربما سيساعد البعض منكم على الأقل:

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

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

لقد قمت بتكوين إعدادات شبكة عامل الإرساء في ملف إنشاء عامل الإرساء مثل هذا:

الشبكات:
إفتراضي:
سائق: جسر
ipam:
التكوين:
- الشبكة الفرعية: 10.10.0.0/24
البوابة: 10.10.0.1

if you are only running one container, you could first create a network (`docker network create`) and connect to it with `docker run --network=<network-name>|<network-id> <image name>`

BUT if you don't want to do this (i.e. force the docker network) and really want to get the default gateway IP, you could get it more cleanly than using `docker0` network interface, for example by parsing the `docker network inspect <network name>`, which outputs the gateway IP (among other things):

...
"IPAM": {
"برنامج التشغيل": "افتراضي"،
"التكوين": [
{
"الشبكة الفرعية": "172.17.0.1/16"،
"البوابة": "172.17.0.1"
}
]
}
...

you could also use the `--format` option of `docker network inspect` to get only the fields that are of interest, like this:

$ docker network inspect bridge --format = '{{range .IPAM.Config}} {{. Gateway}} {{end}}'
172.17.0.1 دولارًا
""

ملاحظة: إذا كان هناك المزيد من الإدخالات .IPAM.Config ، فستحصل عليها جميعًا في المخرجات ، لذلك ستكون هناك حاجة إلى منطق إضافي لاختيار المدخل الصحيح

+1 لـ Dockerhost

ملاحظة ، سيكون هذا مفيدًا جدًا عندما تريد ببساطة استخدام xdebug داخل حاوية php-fpm للاتصال بـ IDE الخاص بك لتصحيح الأخطاء نظرًا لأنه من الواضح أنه لا يمكنك تشغيل IDE في حاوية.

+1 لـ Dockerhost

تلخيصي للقرصنة أعلاه:

في docker-compose.yml :

nginx:
  restart: always
  build: ./nginx/
  ports:
    - "80:80"
  extra_hosts:
    # requires `export DOCKERHOST="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"` in ~/.bash_profile
    - "dockerhost:$DOCKERHOST"

~/.bash_profile :

# see https://github.com/docker/docker/issues/1143
export DOCKERHOST="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"

nginx-conf :

location / {
        proxy_pass http://dockerhost:3000;
        proxy_set_header host $host;
        proxy_set_header x-real-ip $remote_addr;
        proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
}

أميل إلى استخدام صورة عامل ميناء svendowideit / am Ambassador للتغلب على هذه المشكلة.

على سبيل المثال ، إذا كنت أرغب في الارتباط بعقدة بحث مطاطي تعمل على مضيف Docker:

docker run --restart always -d --name elasticsearch --expose 9200 -e ELASTICSEARCH_PORT_9200_TCP=tcp://<host>:9200 svendowideit/ambassador

الآن ، يمكن لحاويات عامل الإرساء الأخرى العثور فقط على البحث المرن باستخدام --link elasticsearch ، بينما تظل غير واعية فيما إذا كان البحث المطاطي يعمل في حاوية عامل إرساء أو على المضيف أو في أي مكان.

+1 لـ Dockerhost

... في الوقت الحالي على الرغم من أنه يمكنك القيام بذلك:

$ docker build --build-arg HTTP_PROXY=172.16.42.1 .

... أو في حالتي المماثلة مع docker-compose - أفعل هذا:

client:
        build: ./client
        extra_hosts:
            - "foobar:${HTTP_PROXY}"

اضبط مضيفك في وقت الإنشاء:

export HTTP_PROXY=172.16.42.1 && docker-compose build

rattrayalex على نظام Mac ، وجدت أن هذا يطبع عنوان IP مباشرةً: ipconfig getifaddr en0

+1 لـ Dockerhost

هل يمكن لمن منكم إجراء 1+ لمضيف dockerhost ، فقط إضافة إبهام (رد فعل) إلى تعليق موجود من نفس الطبيعة؟ قم بإجراء 1+ للتعليقات فقط لتوسيع / ​​ملء سلسلة رسائل هذه المشكلة دون داع. هناك الكثير بالفعل ، ولا داعي لإضافة المزيد ، ولكن يمكننا دائمًا استخدام علامة الإعجاب! 👍

أعتقد أن المعلقين يكتبون +1 شاملة لتسليط الضوء على أن هذه حالة استخدام شائعة ، مع حلول معروفة ، ويجب أن تتطلب وقتًا يمكن تقديره بالساعات ليتم تشفيرها بواسطة فريق عامل الشحن
لا يزال مفتوحًا منذ 3 سنوات 👍

لذا ، يبدو لي أن الأمر أكثر "هل ما زلنا هنا حتى الآن"؟ بدلا من ذلك مجرد رمز تعبيري

يعمل حل magicalbob في https://github.com/docker/docker/issues/1143#issuecomment -233152700 بشكل لا تشوبه شائبة في كل إعداد حاوية وجسر جربته حتى الآن!

الحل من https://github.com/docker/docker/issues/1143#issuecomment -70052272 لا يعمل عند استخدام عامل ميناء إنشاء extra_hosts

+1 لـ Dockerhost

لا يزال لا يوجد dockerhost؟

+1 لـ Dockerhost

+1 لـ Dockerhost

لن يحدث ذلك ، فقد تم إغلاقه منذ 3 سنوات ، ولا يخططون لتنفيذ ذلك على الإطلاق. نفس السبب في أن docker.sock هو مسدس للأمان ، كما أن dockerhost هو كذلك. يعد الحصول على اسم مجال قابل للحل من داخل التطبيق الخاص بك مشكلة أمنية رئيسية IMHO. إذا كان يجب عليك ، فقط استخدام الحلول ، بشكل انتقائي فقط حيث لا يؤدي الوصول إلى خدمات المضيف عن طريق IP إلى زيادة سطح الهجوم.

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

مرسل من BlueMail

في 16 ديسمبر 2016 ، الساعة 17:58 ، الساعة 17:58 ، كتب باولو سيزار [email protected] :

لن يحدث ذلك ، فقد تم إغلاقه منذ 3 سنوات ، ولا يخططون لذلك أبدًا
تنفيذ هذا. نفس السبب في أن docker.sock هو مسدس قدم للأمان ،
dockerhost كذلك. الحصول على اسم مجال قابل للحل من داخل الخاص بك
التطبيق هو مشكلة أمنية كبيرة IMHO. إذا كان لا بد من ذلك ، فما عليك سوى استخدام ملف
الحلول ، بشكل انتقائي فقط حيث لا يمكن الوصول إلى الخدمات المضيفة عن طريق IP
يكون سطح هجوم متزايد.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/docker/docker/issues/1143#issuecomment -267655915

+1 لـ Dockerhost

+1 لـ Dockerhost

IP للجهاز المضيف هو 192.168.0.208 .

ملف docker-compose كالتالي:

version: '2'
 services:
   zl-tigervnc:
     image: zl/dl-tigervnc:1.5
     container_name: zl_dl_tigervnc
     restart: always
     tty: true
     ports:
       - "8001:8888"
       - "6001:6006"
       - "8901:5900"
       - "10001:22"
     devices:
       - /dev/nvidia0
     volumes:
       - ~/data:/root/data
       - /var/run/docker.sock:/var/run/docker.sock
     extra_hosts:
       - "dockerhost:192.168.0.208"

تم إطلاق حاوية بواسطة هذا البرنامج النصي. تريد الحاوية الوصول إلى المنفذ 8080 على الجهاز المضيف (على سبيل المثال ، 192.168.0.208:8080 ). لكنها لا تعمل.

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

لقد جربت العديد من الحلول من هذه الصفحة ، لكنها ما زالت لا تعمل.

ملاحظة ، سيكون هذا مفيدًا جدًا عندما تريد ببساطة استخدام xdebug داخل حاوية php-fpm من أجل
الاتصال بـ IDE الخاص بك لتصحيح الأخطاء لأنه من الواضح أنه لا يمكنك تشغيل IDE في حاوية.

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

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

(الاختبار باستخدام netcat على المضيف و telnet في حاوية عامل الإرساء ، لذلك تم تجريدي جيدًا).

bitwombat تحقق من جدار حماية مضيفك بحثًا عن قاعدة منفذ 9000

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

من تموز (يوليو) 2013 إلى 2017. ما يقرب من 4 سنوات ، كيف لم تعد هذه ميزة حتى الآن؟ من الواضح أن هذه ليست حالة استخدام منعزلة.

إنها ليست ميزة لأنها لا تتوافق مع إستراتيجية Docker لتكون حلاً لإدارة النشر متعدد المضيفات.

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

ip route | awk '/^default via /{print $3}'

+1 لـ dockerhost

مطلوب جدا. +1 لـ dockerhost

+1 لـ dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لأي ​​حل لا يمثل حلاً بديلاً عن الاختراق. لا شيء يعمل هنا.

متفق. +1 لحل. في حاجة إليها للقيام بأعمال التطوير والاختبار في المشاريع التي تستخدم عامل الإرساء.

+1 لـ Dockerhost

+1 لـ Dockerhost

+1 لـ Dockerhost

نجاح باهر .. 4 سنوات وقوية. +1 لـ Dockerhost؟

+1 dockerhost !!

+1 dockerhost !!!

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

: +1: لـ Dockerhost ... الآن أقوم بإعداده بواسطة env:

export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)

يجعل الأشياء مرهقة.

حتى أن شيئًا بسيطًا مثل استخدام docker-compose في حاوية مع سجل خاص متصل بنفق ssh لا يعمل لأن Docker معدوم جدًا على عدم الرغبة في Dockerhost.

ملاحظة: تم إغلاق هذه المشكلة ، لذا لا فائدة من إضافة المزيد من التعليقات إليها :-)

إذا كنت بحاجة إلى هذه الميزة ، فيمكنك بسهولة إضافة اسم DNS المستعار dockerhost باستخدام --add-host والخيارات المكافئة.

لماذا هذا غير متوفر بشكل افتراضي؟ لأنه يعمل فقط في حالات تافهة. بمعنى آخر:

  • ماذا عن الحاويات التي لا تملك إمكانية الوصول إلى الشبكة؟
  • ماذا عن الحاويات التي بها شبكات _متعددة_؟
  • ماذا عن الحاويات التي تعمل على كتلة سرب؟

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

شكرا لك.

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

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

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

ثم لن يعمل dockerhost.

ماذا عن الحاويات التي لها شبكات متعددة؟

ثم لن يعمل dockerhost.

ماذا عن الحاويات التي تعمل على كتلة سرب؟

من يهتم؟

إذا كنت تقوم بتطوير بعض البرامج التي تتضمن مكونات خارج النظام البيئي لرسو السفن (مثل بعض البرامج التي تعمل داخل Windows VM على المضيف) ، فمن الصعب توصيلها بـ docker. لماذا يجب أن يكون الألم؟

جميع الحالات التي قمت بإدراجها ليست ما يتحدث 226 تعليقًا في هذا الموضوع ، إنها تتحدث عن الحالة الأساسية.

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

jpetazzo أحيانًا تكون الحالات "التافهة" 80٪ من حالات الاستخدام. سيكون Dockerhost مفيدًا جدًا للأشخاص الذين يستخدمون Docker في بيئات التطوير أو التدريج ، أو في الحقيقة أي بيئات لا تعتمد على شبكات سرب / متعددة المضيف. فيما يلي بعض الأمثلة حيث أود استخدام Dockerhost:

1) Docker-Compose على Windows مع التسجيل الخاص. لدينا سجل Docker خاص مستضاف ذاتيًا. يمكن للمطورين الوصول إلى السجل من خلال نفق SSH مع إعادة توجيه المنفذ (أي على المضيف المحلي: 5000). ولكن عند تشغيل Docker-Compose في حاوية Docker الخاصة به ، لا توجد طريقة لتحديد مضيف التسجيل الخاص. إذا كان لدينا dockerhost ، فيمكننا استخدام d ockerhost: 5000 في ملف docker-compose.yml الخاص بنا مما يتيح له الوصول إلى المنفذ المعاد توجيهه على المضيف.

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

3) عكس ميناء الشحن. يمكننا تشغيل خادم SSH أو OpenVPN في حاوية Docker ويمكن أن يمنح العملاء إمكانية الوصول إلى الخدمات التي تعمل على المضيف إذا كان هناك dockerhost . يمكنك إعداد ميناء الشحن من الحاوية إلى dockerhost.

أود أن أسمع أي تبرير تقني لرفض مطوري Moby سماع المجتمع عندما يتعلق الأمر بـ dockerhost. أسمع حتى الآن أسباب سياسية / تجارية فقط.

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

أنا جديد نسبيًا على Docker. كل ما قرأته من المستندات الرسمية منطقي. _Docker هي في الواقع أداة سهلة الاستخدام.

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

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

في 19 يونيو 2017 01:08 ، كتب "Josh Wedekind" [email protected] :

أنا جديد نسبيًا على Docker. كل ما قرأته من المستندات الرسمية
من المنطقي. Docker هي في الواقع أداة سهلة الاستخدام.

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/1143#issuecomment-309311997 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AA-shyjglsJXawxHHWGhQH0d1LlZeJqxks5sFbwXgaJpZM4Ayw00
.

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

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

لذا ، مرة أخرى ، أنا متأكد من أن المشكلة صامتة ، ولكن إذا نظرت مرة أخرى إلى هذا الموضوع ، Docker devs ، فإن هذا يسبب ألمًا حقيقيًا ويتسبب في توقف عملاء Docker الحقيقيين عن استخدام Docker. أوصي بإعادة النظر في رفضك العنيد لمعالجة المشكلة ؛ لمجرد أنها لا تتناسب مع رؤيتك لكيفية استخدام Docker "المفترض" لا يعني أنها ميزة غير مجدية أو غير ضرورية.

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

الطريقة التي أجعلها تعمل الآن هي إنشاء شبكة. إليك كيف يبدو ملف Docker-Compose الخاص بي:

version: '2'
services:
  <container_name>:
    image: <image_name>
    networks:
      - dockernet

networks:
  dockernet:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1

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

deltabweb هل ستظهر الطلبات الواردة إلى التطبيقات على الجهاز المضيف كحركة مرور "مضيف محلي" ، أم سأضطر إلى تعديل التطبيقات للاستجابة إلى 192.168.0.1؟

شكرا لمساعدتك.

تضمين التغريدة
لم ألق نظرة على وثائق networks بالتفصيل لكن ما أفهمه هو أنه يتم إنشاء شبكة جديدة على جهازك المضيف حيث:

  • عنوان IP لـ "Dockerhost" هو 192.168.0.1
  • IP للحاوية الأولى هو 192.168.0.2
  • IP للحاوية الثانية هو 192.168.0.3
  • وما إلى ذلك وهلم جرا ...

بدءًا من هناك ، يجب أن يعمل كل شيء كما لو كان لديك أجهزة فعلية متصلة ببعضها البعض على شبكة محلية:

  • يمكن للآلات الاتصال ببعضها البعض
  • ويجب أن تكون قادرًا على استخدام ping 192.168.0.2 من المضيف - لن يعمل هذا إلا إذا استجابت الحاوية الخاصة بك للأصوات.

للإجابة على سؤالك ، أعتقد أن تطبيقاتك على الجهاز المضيف ستحتاج إلى الاستجابة لـ 192.168.0.X (اعتمادًا على الحاوية التي تحاول الاتصال).

deltabweb كيف يمكنني الوصول إلى السحابة إلى منفذ الخادم المضيف؟ >>> رفض الاتصال

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

nooperpudd إذا كنت تستخدم Docker for mac ، فلا يمكنك استخدام وضع host ، كما أن حل deltabweb لا يعمل معي أيضًا (تستمع جميع خوادمي إلى 0.0.0.0 وجدران حماية الجهاز المضيف تم إيقاف تشغيلها ولكني أحصل على Connection refused في كل مرة). بعد حوالي يومين من المحاولة والخطأ ، الطريقة الوحيدة التي وجدتها لإصلاح هذه المشكلة هي النص التالي:

#!/bin/bash
export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)

# You should use DOCKERHOST env variable in your `docker-compose.yml` 
# and put it everywhere you want to connect to `localhost` of the host machine
docker-compose $@

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

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

لقد قدمت هذه الملاحظة عند محاولة كشف نقاط النهاية لمثيلات مجموعة قاعدة بيانات NoSql للعملاء خارج مجموعة السرب. بعد كل شيء ، يجب تكوين نقاط النهاية هذه باستخدام عناوين IP خاصة أو عامة لجهاز VM حتى يتمكن العميل الخارجي من الوصول إليها. تم تصميم Cassandra بطريقة تجعلها تحاول الاتصال فورًا بعنوان IP للمضيف (تم تعيينه على أنه CASSANDRA_BROADCAST_ADDRESS متغير البيئة - انظر أدناه) وبالتالي يفشل. من ناحية أخرى ، تبدأ عُقد مجموعات Mongodb المتماثلة أولاً في حالة نظيفة ، ثم يتم تنفيذ أمر بدء منفصل بحيث يمكن للعقد الأساسية والثانوية تشكيل مجموعة متماثلة.

أدناه ، ترى حسابًا مفصلاً لهذه الملاحظة لكاساندرا (أقوم بإنشاء هذه باستخدام سرب عامل الإرساء ولكن نفس المشكلة تظهر في docker run -d (في وضع NAT ، وبالتالي بدون --net = خيار المضيف)

1) من ناحية ، الحاوية التي أنشأتها

docker service create  --name cassandra-service
--publish mode=host,target=7000,published=7000,protocol=tcp 
-e CASSANDRA_SEEDS=host IP address  -e CASSANDRA_BROADCAST_ADDRESS=host IP address

فشل مع رسالة مفادها أنه لا يمكنه الاتصال بعنوان الاستماع: <host IP address>:7000

2) من ناحية أخرى ، حاوية متصلة بشبكة تراكب ، تم إنشاؤها بواسطة

docker service create  --network cassandra-net --name cassandra-service
-e CASSANDRA_SEEDS=cassandra-service  -e CASSANDRA_BROADCAST_ADDRESS=cassandra-service

يبدأ بشكل صحيح وفي نفس الوقت يمكنني الاتصال بعنوان IP للمضيف على أي منفذ يتم عرضه في Dockerfile الخاص بكاساندرا : 2.0 صورة:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                                         NAMES
07603a75a379        cassandra:2.0       "/docker-entrypoin..."   About a minute ago   Up About a minute   7000-7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp   cassandra-service-1.1.m243u97zku15w08m6puytdngs

$ docker exec -it 1e61ec16f8d0 bash
root<strong i="5">@1e61ec16f8d0</strong>:/# cqlsh 172.17.13.151
Connected to Test Cluster at 172.17.13.151:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]

وبالمثل ، يمكن ملاحظة الشيء نفسه أثناء إنشاء عقدة كاساندرا ثانية

1) إذا قمت بإنشاء حاوية كاساندرا ثانية على عقدة أخرى

docker service create  --network cassandra-net --name cassandra-service-2
-e CASSANDRA_SEEDS=172.17.13.151  -e CASSANDRA_BROADCAST_ADDRESS=cassandra-service-2

فشلت الحاوية مع استثناء وقت التشغيل الذي لا يمكنها النميمة بالبذرة:

java.lang.RuntimeException: Unable to gossip with any seeds
        at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1322)
        at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:457)

2) من ناحية أخرى ، إذا قمت بإنشاء حاوية كاساندرا عبر docker run -d ، يمكنني الوصول إلى العقدة الأولية عبر عنوان IP الخاص بها:

$ docker run -d cassandra:2.0
d87a79cc3de8cd7e4cf40284d1eca91ceb660581cc71082fe64a6b84a09fbd77
$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                         NAMES
d87a79cc3de8        cassandra:2.0       "/docker-entrypoin..."   3 seconds ago       Up 2 seconds        7000-7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp   trusting_ardinghelli
$ docker exec -it d87a79cc3de8 bash
root<strong i="17">@d87a79cc3de8</strong>:/# cqlsh 172.17.13.151
Connected to Test Cluster at 172.17.13.151:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh>

على وجه التحديد بالنسبة لـ Cassandra ، يمكنك حل هذه المشكلة عن طريق إيقاف تشغيل التمهيد التلقائي لعقد كاساندرا. يمكنك القيام بذلك عن طريق تعيين auto_bootstrap إلى false في /etc/cassandra/cassandra.yaml باستخدام أمر إدخال في Compose V3:

version: '3'
services:
  cassandra-1:
    image: cassandra:2.0
    entrypoint:
    - "sh"
    - "-c"
    - "echo auto_bootstrap: false >> /etc/cassandra/cassandra.yaml; /docker-entrypoint.sh cassandra -f"
    environment:
      CASSANDRA_BROADCAST_ADDRESS: 172.17.13.151
    volumes:
    - volume1:/var/lib/cassandra
    ports:
    - "7000:7000"
    - "7001"
    - "7199"
    - "9042:9042"
    - "9160:9160"

ثم ابدأ يدويًا عقد كاساندرا بتنفيذ docker exec -it <container id> nodetool rebuild .

يمكنني استخدام هذه الميزة في التطوير ، حسنًا ...

jpetazzo نطور حلول PHP في فرق على مزيج من المنصات. يحتاج مصحح الأخطاء (xdebug) إلى الاتصال مرة أخرى بـ IDE على المضيف. في نظامي التشغيل Windows و Linux ، يعمل هذا "خارج الصندوق" ولكن في نظام التشغيل Mac ، يتعين على المطورين تغيير ملف xdebug.ini ليذكر عنوان IP المحلي الخاص بهم على وجه التحديد. لكن Dockerfile تحت التحكم بالمصادر ... صف النزاعات المستمرة والشتائم بينما يتعارض المطورون حول تحرير هذا الملف. نعم ، هناك حلول قابلة للنصوص البرمجية ، ولكن لماذا يحتوي Docker for windows و mac docker.for.win.localhost و docker.for.mac.localhost؟ إنه مفيد جزئيًا لكننا ما زلنا بحاجة إلى نصوص برمجية لاكتشاف النظام الأساسي الذي نستخدمه لإعداد هذا بشكل صحيح. يبدو الأمر أكثر تعقيدًا بكثير مما يجب أن يكون. يرجى إعادة النظر في هذه الميزة. يمكن أن يكون Docker منحنى تعليمي حاد ، لكن مثل هذه المشكلات تجعل المستخدمين يبحثون في حالة عدم تصديق على Google لساعات متتالية.

التحقق من https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds page ساعدنا ، باستخدام docker.for.mac.localhost عمل لنا :)

للأفضل أو للأسوأ ، لا يزال docker-compose أسهل طريقة أعرفها لتدوير Selenium Hub وعقد شبكة Firefox / Chrome بدون رأس لاختبار خادم ويب يعمل على جهاز مطور محلي أو في CI (إطلاق خادم الويب في حاوية عامل الإرساء بطيء جدًا بحيث لا يكون مناسبًا للتطوير). لم يكن Docker مخصصًا على الإطلاق ، ولكن Docker هو أفضل أداة لهذه الوظيفة ، وهو خطأ Docker الخاص باستثناء المشكلة الوحيدة هي بسهولة اكتشاف عنوان IP المضيف بطريقة تعمل على أي نظام تشغيل.

rskuipers ، هل يمكنك شرح ما فعلته بالضبط بـ docker.for.mac.localhost ؟ أحاول تقديم طلبات من داخل حاوياتي لحلها إلى الجهاز المضيف. تعمل الحاويات الخاصة بي على traefik مما يعني أنه يمكنني الوصول إليها من خلال domain.docker.localhost ، ولكن إذا حاولت الوصول إلى عنوان URL يبدأ بذلك من داخل الحاوية الخاصة بي ، فلن يتم حله.

ما فعلته حاليًا هو أنني أضفت هذا إلى docker-compose.yml الخاص بي ، والذي يضيف سطرًا إلى /etc/hosts حتى يتم حل المجال بشكل جيد:

extra_hosts: - "domain.docker.localhost:172.18.0.1"

IP هو عنوان IP للمضيف من داخل الحاوية الخاصة بي ، والذي يمكنني الحصول عليه باستخدام ip route | awk '/^default via /{print $3}' . لكني لا أرغب في ترميز أنه إذا أمكن ...

jzavrl كل ما فعلته هو استخدام docker.for.mac.localhost لجعل طلبات HTTP تمر عبر وكيل يعمل على المضيف. لا أستخدم أي طبقات أخرى بخلاف docker-compose .

هذا بالضبط ما أنا مهتم به. ما نوع التغييرات التي كان عليك إجراؤها تحديدًا؟

jzavrl بلا : ف عملت للتو.

لم أفهم ، ماذا فعلت بـ docker.for.mac.localhost إذن؟

jzavrl لقد استخدمت ذلك بدلاً من IP للاتصال به. لذلك عامل في ماك. المضيف المحلي: 8888

Ahhhhhh ، الآن بدأ هذا الأمر منطقيًا الآن. سأحاول هذا بعد ذلك. هتافrskuipers.

فقط استخدم عنوان IP الخاص بـ "en0" على جهاز الكمبيوتر الخاص بك.

علي سبيل المثال

ssh [email protected]

ربما يكون "192.168.1.100" من خدمة DHCP لجهاز التوجيه الخاص بك.

acuthbert ، شكرًا على اقتراحك.
docker.for.win.localhost يعمل معي في Docker لـ Windows. لا يزال هناك أمل لـ Docker و Windows. 😣

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

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

NdubisiOnuora ، ما نوع التطبيق الخاص بك؟ تطبيق ويب؟

لدي تطبيقان لوحدة التحكم (خادم TCP في المضيف و tcp-client في الحاوية).
لأنهم يستخدمون برنامج التعاون الفني ، فأنا بحاجة إلى IP بالضبط ( docker.for.win.localhost غير مناسب ، لأنه مجال).

على سبيل المثال ، ما هو ip:port الذي يجب تعيينه في عميل tcp ، إذا قمت بتعيين ip:port 127.0.0.1:9595 في خادم tcp؟

فقط حل المجال إلى عنوان IP؟

orf ،
أريد استخدام هذا الرمز في C #:
IPAddress hostAddr = Dns.Resolve("docker.for.win.localhost").AddressList[0];
ولكن قبل ذلك أحاول تنفيذ الأمر ping إلى docker.for.win.localhost ، لكن لا أرى ذلك ، الخطأ: Ping request could not find host docker.for.win.localhost. Please check the name and try again.
ملف Docker الخاص بي:
FROM microsoft/windowsservercore
ADD . /
ENTRYPOINT powershell ping docker.for.win.localhost

في حالة إغفال أي شخص ، أعتقد أن الحل اعتبارًا من 18.03 هو host.docker.internal على الرغم من أن هذا لا يعمل إلا لسبب ما على Docker لنظام التشغيل Windows !؟ لماذا لا؟

تحرير: لم أر أن التعليقات تم تصغيرها بواسطة Github ... 🤦‍♂️

تناسبني:
docker run --rm -it --add-host "docker.for.localhost:$(ip -4 addr show docker0 | grep -Po 'inet \K[\d.]+')" alpine:latest ping docker.for.localhost

lukasmrtvy هذا يعمل مع shell ، لكن ماذا عن docker-compose.yml ؟

لقد أنشأت حاوية لحل هذه المشكلة بطريقة عامة تعمل على جميع المنصات https://github.com/qoomon/docker-host

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات