/ سم مكعبaluzzardimrjana طلب

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

mavenugo إنه كائن طلب koa الذي يستخدم وحدة العقدة remoteAddress من net الوحدة النمطية. يجب أن تكون النتيجة مماثلة لأي مكتبات أخرى يمكنها استرداد العنوان البعيد.

من المتوقع أن يكون الحقل ip دائمًا عنوانًا بعيدًا بغض النظر عن أي تكوين.

PanJ هل ما زلت تستخدم الحل البديل الخاص بك أو وجدت بعض الحلول الأفضل؟

PanJ عندما أقوم بتشغيل تطبيقك كحاوية مستقلة ..

docker run -it --rm -p 80:3000 --name test panj/debugging-simple-server

والوصول إلى المنفذ المنشور من مضيف آخر أحصل عليه

vagrant@net-1:~$ curl 192.168.33.12
{"method":"GET","url":"/","header":{"user-agent":"curl/7.38.0","host":"192.168.33.12","accept":"*/*"},"ip":"::ffff:192.168.33.11","ips":[]}
vagrant@net-1:~$

192.168.33.11 هو عنوان IP الخاص بالمضيف الذي أقوم بتشغيل curl فيه. هل هذا التصرف المتوقع ؟

sanimej نعم ، إنه السلوك المتوقع الذي يجب أن يكون في وضع السرب أيضًا.

marech ما زلت أستخدم الحاوية المستقلة كحل بديل ، والذي يعمل بشكل جيد.

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

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

sanimej لقد رأيت كيندا كيف يعمل عندما

لدي معرفة محدودة بكيفية تنفيذ الإصلاح. ربما نوع خاص من الشبكات لا يغير عنوان IP المصدر؟

يشبه Rancher وضع Docker swarm ويبدو أنه كان لديه سلوك متوقع. ربما هو مكان جيد للبدء.

sanimej فكرة جيدة يمكن أن تضيف جميع عناوين IP إلى رأس X-Forwarded-For إذا كان ذلك ممكنًا ، ثم يمكننا رؤية كل السلسلة.

PanJ hmm ، وكيف تتواصل حاوية nignx المستقلة الخاصة بك مع مثيل السرب ، عبر اسم الخدمة أو عنوان IP؟ ربما يمكنك مشاركة جزء التكوين nginx حيث تقوم بتمريره إلى مثيل سرب.

تستمع حاوية marech المستقلة إلى المنفذ 80 ثم الوكلاء إلى localhost:8181

server {
  listen 80 default_server;
  location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_pass          http://localhost:8181;
    proxy_read_timeout  90;
  }
}

إذا كان عليك القيام بإنهاء SSL ، فأضف كتلة خادم أخرى تستمع إلى المنفذ 443 ، ثم قم بإنهاء SSL والوكلاء إلى localhost:8181 أيضًا

ينشر nginx في وضع Swarm 8181:80 ويوجه إلى خدمة أخرى بناءً على مضيف الطلب.

server {
  listen 80;
  server_name your.domain.com;
  location / {
    proxy_pass          http://your-service:80;
    proxy_set_header Host $host;
    proxy_read_timeout  90;
  }
}

server {
  listen 80;
  server_name another.domain.com;
  location / {
    proxy_pass          http://another-service:80;
    proxy_set_header Host $host;
    proxy_read_timeout  90;
  }
}

في حالتنا ، تعتمد API RateLimit الخاصة بنا والوظائف الأخرى على عنوان IP الخاص بالمستخدم. هل هناك أي طريقة لتخطي المشكلة في وضع السرب؟

لقد واجهت أيضًا المشكلة عند محاولة تشغيل logstash في وضع السرب (لتجميع رسائل سجل النظام من مضيفين مختلفين). يظهر حقل logstash "host" دائمًا بالشكل 10.255.0.x ، بدلاً من عنوان IP الفعلي للمضيف المتصل. هذا يجعله غير قابل للاستخدام تمامًا ، حيث لا يمكنك معرفة المضيف الذي تأتي منه رسائل السجل. هل هناك طريقة ما يمكننا من خلالها تجنب ترجمة عنوان IP المصدر؟

+1 لحل هذه المشكلة.

بدون القدرة على استرداد عنوان IP الخاص بالمستخدم يمنعنا من استخدام حلول المراقبة مثل Prometheus.

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

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

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

ربما لم أشرح بشكل جيد حالة الاستخدام.

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

لقد أدركت للتو "فحص شبكة عامل ميناء"معلومات حول الحاويات وعناوين IPv4 لعقدة واحدة. هل يمكن توسيعها بحيث توجد معلومات على مستوى الكتلة لشبكة ما مع العقد؟

شيء مثل:

       "Containers": {
            "57bc4f3d826d4955deb32c3b71550473e55139a86bef7d5e584786a3a5fa6f37": {
                "Name": "cadvisor.0.8d1s6qb63xdir22xyhrcjhgsa",
                "EndpointID": "084a032fcd404ae1b51f33f07ffb2df9c1f9ec18276d2f414c2b453fc8e85576",
                "MacAddress": "02:42:0a:00:00:1e",
                "IPv4Address": "10.0.0.30/24",
                "IPv6Address": "",
                "Node": "swarm-4"
            },
...

لاحظ إضافة "العقدة".

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

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

يجب أن يعمل الحل على مستوى IP بحيث تظل أي خدمة لا تعتمد على HTTP تعمل بشكل صحيح أيضًا (لا يمكن الاعتماد على رؤوس http ...).

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

هكذا تحل HaProxy هذه المشكلة: http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-despite-reverse-proxies/

قد يكون kobolog قادرًا على إلقاء بعض الضوء على هذه المسألة في ضوء حديثه على IPVS في DockerCon.

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

mrjana ، هل يمكنك الثابتة والمتنقلة إضافة الاقتراح الذي كان عليك حل هذه المشكلة؟

IPVS ليس وكيلًا عكسيًا لمساحة المستخدمين يمكنه إصلاح الأشياء في طبقة HTTP. هذا هو الفرق بين وكيل مساحة المستخدمين مثل HAProxy وهذا. إذا كنت ترغب في استخدام HAProxy ، فيمكنك القيام بذلك عن طريق وضع HAProxy في الكتلة والحصول على جميع مثيلات الخدمة و HAProxy للمشاركة في نفس الشبكة. بهذه الطريقة يمكن لـ HAProxy إصلاح HTTP header.x-forwarded-for . أو إذا كان موازن تحميل L7 خارجيًا عن الكتلة ، فيمكنك استخدام الميزة القادمة (في 1.13) لميزة PublishMode تسمى Host PublishMode والتي ستكشف عن كل حالة من المثيلات الفردية للخدمة في المنفذ الفردي الخاص به ويمكنك توجيه موازن التحميل الخارجي إلى ذلك.

mrjana الفكرة الكاملة لاستخدام IPVS (بدلاً من أي عامل يعمل حاليًا في وضع السرب) هو تجنب ترجمة عنوان IP المصدر للبدء به. قد تساعد إضافة X-Forwarded-For في بعض تطبيقات HTTP ، ولكنها لا تفيد على الإطلاق لجميع التطبيقات الأخرى التي تعطلها السلوك الحالي.

dack ما أفهمه هو أن شبكة دخول Docker تستخدم IPVS بالفعل.

إذا كنت ترغب في استخدام HAProxy ، فيمكنك القيام بذلك عن طريق وضع HAProxy في الكتلة والحصول على جميع مثيلات الخدمة و HAProxy للمشاركة في نفس الشبكة. بهذه الطريقة يمكن لـ HAProxy إصلاح HTTP header.x-forwarded-for

لن يعمل ذلك أيضًا mrjana ،

ببساطة ، لا توجد طريقة على الإطلاق للتعامل مع هذا بمجرد استخدام خدمات عامل الإرساء ووضع السرب.

سيكون من المثير للاهتمام أن ينضم مؤلفو (مؤلفو) شبكة دخول عامل الإرساء إلى المناقشة حيث من المحتمل أن يكون لديهم بعض الأفكار حول كيفية تكوين / تشغيل IPVS تحت غطاء المحرك (هناك العديد من أوضاع IPVS) وكيف يمكننا الإصلاح المشكلة.

tlvenn هل تعرف مكان هذا في الكود المصدري؟ قد أكون مخطئًا ، لكنني لا أعتقد أنه يستخدم IPVS بناءً على بعض الأشياء التي لاحظتها:

• المنفذ المصدر مترجم (السبب كله لهذه المشكلة). IPVS لا يفعل هذا. حتى في وضع NAT ، فإنه يترجم عنوان الوجهة فقط. تحتاج إلى استخدام المسار الافتراضي أو توجيه السياسة لإرسال حزم الإرجاع مرة أخرى إلى مضيف IPVS.
• عندما يتم نشر منفذ في وضع السرب ، فإن جميع حالات dockerd في السرب تستمع إلى المنفذ المنشور. إذا تم استخدام IPVS ، فسيحدث ذلك في مساحة kernel ولن يستمع dockerd على المنفذ.

مرحبًا dack ،

من مدونتهم:

داخليًا ، نقوم بهذا العمل باستخدام Linux IPVS ، وهو موازن تحميل متعدد البروتوكولات داخل kernel Layer 4 والذي كان موجودًا في Linux kernel لأكثر من 15 عامًا. مع حزم توجيه IPVS داخل النواة ، توفر شبكة توجيه السرب أداءً عاليًا في موازنة الحمل مع مراعاة الإدراك.

يجب أن يعيش مصدر الكود في مشروع swarmkit إذا لم أكن مخطئًا.

أتساءل عما إذا كان بإمكان stevvooe مساعدتنا في فهم المشكلة الأساسية هنا.

حسنًا ، لقد ألقيت نظرة سريعة على الكود وأعتقد أن لدي فهمًا أفضل قليلاً الآن. يبدو بالفعل أنه يستخدم IPVS كما هو مذكور في المدونة. يتم إجراء SNAT عبر قاعدة iptables التي تم إعدادها في service_linux.go. إذا فهمت بشكل صحيح ، فسيكون المنطق الكامن وراء ذلك شيئًا من هذا القبيل (بافتراض أن العقدة A تتلقى حزمة عميل للخدمة التي تعمل على العقدة B):

• تستقبل عقدة Swarm A حزمة العميل. يترجم IPVS / iptables (src ip) -> (العقدة a ip) و (dst ip) -> (العقدة B ip)
• يتم إعادة توجيه الحزمة إلى العقدة B
• ترسل العقدة B ردها على العقدة A (هذا ما تراه كـ src ip)
• تقوم العقدة A بترجمة src و dst إلى القيم الأصلية وتعيد توجيه الرد إلى العميل

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

لذا ، فإن السؤال هو كيفية تجنب SNAT مع الاستمرار في السماح لجميع العقد بمعالجة طلبات العملاء الواردة. لست متأكدًا تمامًا من أفضل طريقة. ربما توجد طريقة للحصول على جدول حالة على عقدة الخدمة بحيث يمكنها استخدام توجيه السياسة لتوجيه الردود بدلاً من الاعتماد على SNAT. أو ربما يمكن أن يساعد نوع من التغليف (VXLAN؟). أو يمكن استخدام طريقة التوجيه المباشر لـ IPVS. سيسمح هذا لعقدة الخدمة بالرد مباشرة على العميل (بدلاً من العقدة التي تلقت الطلب الأصلي) وسيسمح بإضافة عناوين IP جديدة عائمة للخدمات. ومع ذلك ، قد يعني ذلك أيضًا أنه لا يمكن الاتصال بالخدمة إلا عبر IP العائم وليس عناوين IP للعقدة الفردية (لست متأكدًا مما إذا كانت هذه مشكلة في أي حالات استخدام).

اكتشاف مثير للاهتمام dack !

نأمل أن يتم العثور على حل لتخطي SNAT معًا.

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

https://github.com/docker/swarmkit/pull/1645

مرحبًا ، شكرًا على كمية التعليقات الكبيرة - سنلقي نظرة عميقة على هذه المشكلة بعد عطلة نهاية الأسبوع.

بعض المعلومات في هذه الأثناء:

tlvenn : mrjana هو المؤلف الرئيسي وراء ميزة شبكة

dack : إنه بالفعل مدعوم من IPVS

tlvenn بقدر ما أعرف ، يستخدم Docker Swarm التنكر ، لأنه الطريقة الأكثر مباشرة ومضمونة للعمل في معظم التكوينات. بالإضافة إلى أن هذا هو الوضع الوحيد الذي يسمح في الواقع بتنكر المنافذ أيضًا [re:dack] ، وهو سهل الاستخدام. من الناحية النظرية ، يمكن حل هذه المشكلة باستخدام وضع تغليف IPIP - سيكون تدفق الحزمة كما يلي:

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

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

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

مشاهدة. يستفيد منتجنا من معلومات IP المصدر للأمان والتحليلات.

@ aluzzardi أي تحديث لنا؟

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

عند فحص التدفق ، يبدو أنه يعمل حاليًا على هذا النحو (في هذا المثال ، تتلقى العقدة A حركة المرور الواردة والعقدة B تشغل حاوية الخدمة):

• العقدة A تنفذ DNAT لتوجيه الحزمة إلى مساحة اسم شبكة ingress_sbox (/ var / run / docker / netns / ingress_sbox)
• يقوم ingress_sbox على العقدة A بتشغيل IPVS في وضع NAT ، والذي يقوم بتنفيذ DNAT لتوجيه الحزمة إلى الحاوية الموجودة على العقدة B (عبر شبكة تراكب الدخول) وأيضًا SNAT لتغيير عنوان IP المصدر إلى العقدة A دخول شبكة تراكب IP
• يتم توجيه الحزمة من خلال التراكب إلى الخادم الحقيقي
• تتبع حزم الإرجاع نفس المسار في الاتجاه المعاكس ، مع إعادة كتابة عناوين المصدر / الوجهة إلى القيم الأصلية

أعتقد أنه يمكن تجنب SNAT بشيء مثل هذا:

• العقدة A تمرر الحزمة إلى ingress_sbox بدون أي NAT (iptables / policy routing؟)
• العقدة A ingress_sbox تقوم بتشغيل IPVS في وضع التوجيه المباشر ، والذي يرسل الحزمة إلى العقدة B عبر شبكة التراكب الداخلة
• تستقبل الحاوية على العقدة B الحزمة غير المعدلة (يجب أن تقبل الحاوية الحزم لجميع عناوين IP العامة ، ولكن لا ترسل لها ARP. هناك عدة طرق للقيام بذلك ، راجع مستندات IPVS).
• ترسل حزم الإرجاع مباشرة من العقدة B إلى العميل (لا تحتاج إلى العودة عبر شبكة التراكب أو العقدة A)

كمكافأة إضافية ، لا يلزم تخزين أي حالة NAT ويتم تقليل حركة مرور الشبكة المتراكبة.

aluzzardimrjana هل من تحديث لهذا من فضلك؟ سيكون القليل من التعليقات من Docker موضع تقدير كبير.

مشاهدة. بدون معلومات IP المصدر ، لا يمكن أن تعمل معظم خدماتنا كما هو متوقع

كيف حدث هذا ؟

tlvenn يبدو وكأنه خطأ في جيثب؟

PanJtlvennvfarcicdack وغيرها، PTAL # 27917. قدمنا ​​القدرة على تمكين وضع نشر الخدمة = host والذي سيوفر طريقة للخدمة لتجاوز IPVS وإعادة السلوك المماثل docker run -p وسيحتفظ بمصدر IP للحالات التي في حاجة إليها.

الرجاء محاولة 1.13.0-rc2 وتقديم ملاحظات.

يا جميلة غريبة mavenugo ..

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

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

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

هل يمكننا الاطلاع على من يبحث في هذه المشكلة في Docker وتحديث الحالة؟ شكرا لك مقدما.

بخلاف # 27917 ، لا يوجد حل آخر لـ 1.13. يجب تحليل وظيفة الإرجاع المباشر للعديد من حالات الاستخدام ولا ينبغي الاستخفاف بها لاعتبارها إصلاحًا للأخطاء. يمكننا النظر في هذا من أجل 1.14. ولكن هذا يندرج أيضًا ضمن فئة سلوك LB القابل للتكوين ، والذي يتضمن الخوارزمية (rr مقابل 10 طرق أخرى) ، مسار البيانات (LVS-DR ، LVS-NAT & LVS-TUN). إذا كان شخص ما على استعداد للمساهمة في هذا ، فالرجاء دفع العلاقات العامة ويمكننا تحريك ذلك.

عادل بما فيه الكفاية أعتقد mavenugo بالنظر إلى أن لدينا بديل الآن.

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

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

بالتأكيد ونعم تحديث مستند للإشارة إلى هذا السلوك والحل البديل لاستخدام النشر mode=host سيكون مفيدًا لحالات الاستخدام التي تفشل في وضع LVS-NAT.

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

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

أرغب في رؤية رأس مخصص مضاف إلى طلب http / https والذي يحافظ على عنوان IP الخاص بالعميل. يجب أن يكون هذا ممكنًا ، أليس كذلك؟ لا أمانع عند الكتابة فوق X_Forwarded_for ، أريد فقط أن يكون لدي حقل مخصص يتم تعيينه فقط في المرة الأولى التي يدخل فيها الطلب إلى السرب.

أرغب في رؤية رأس مخصص مضاف إلى طلب http / https والذي يحافظ على عنوان IP الخاص بالعميل. يجب أن يكون هذا ممكنًا ، أليس كذلك؟ لا أمانع عند الكتابة فوق X_Forwarded_for ، أريد فقط أن يكون لدي حقل مخصص يتم تعيينه فقط في المرة الأولى التي يدخل فيها الطلب إلى السرب.

تتم موازنة التحميل عند L3 / 4. لا يمكن إضافة رأس http.

سيشمل الإصلاح إزالة إعادة كتابة عنوان المصدر.

mavenugo لقد قمت بالتحديث إلى عامل mode=host في خدمة الوكيل الخاصة بي. إنه يعمل حاليًا ، ويتم الاحتفاظ بعنوان IP الخاص بالعميل ، لكنني آمل في حل أفضل :) شكرًا على عملك!

آسف على المشاركة المزدوجة ...
كيف يمكنني استخدام ملف مكدس (yml v3) للحصول على نفس السلوك كما لو كنت سأستخدم --publish mode=host,target=80,published=80 عبر إنشاء خدمة عامل الإرساء؟

حاولت

...
services:
  proxy:
    image: vfarcic/docker-flow-proxy:1.166
    ports:
      - "80:80/host"
      - "443:443/host" 
...

لكن هذا لا يعمل (استخدم نفس النمط كما في https://docs.docker.com/docker-cloud/apps/stack-yaml-reference/#/ports)

كيف يمكنني استخدام ملف مكدس (yml v3) للحصول على نفس السلوك كما لو كنت سأستخدم - وضع النشر = المضيف ، الهدف = 80 ، المنشور = 80 عبر إنشاء خدمة عامل الإرساء؟

hamburml - راقب https://github.com/docker/docker/issues/30447 إنها مشكلة / ميزة مفتوحة.

لسوء الحظ ، لا يمكنني استخدام mode=host كحل بديل لأنني أحتاج إلى خدمتي للتواصل مع شبكة swarm وأيضًا الاستماع إلى جميع العقد ، وليس فقط واجهة المضيف ...

@ tkeeler33 أعتقد أنه يجب أن تكون قادرًا على نشر الخدمة كخدمة global (التي تنشر مثيلًا على كل عقدة في السرب) ، وتوصيلها بشبكة سرب للتواصل مع الخدمات الأخرى في السرب

thaJeztah - نعم ، لكن لا يمكنني توصيل حاوية بشبكة تراكب / سرب واستضافة mode=host في نفس الوقت. هذا هو أكبر قيد لدي في الوقت الحالي.

يبدو أن @ tkeeler33 يعمل بالنسبة لي ؛

$ docker network create -d overlay swarm-net

$ docker service create \
  --name web \
  --publish mode=host,published=80,target=80 \
  --network swarm-net \
  --mode=global \
  nginx:alpine

$ docker service create --name something --network swarm-net nginx:alpine

اختبر ما إذا كانت الخدمة web قادرة على الاتصال بخدمة something على نفس الشبكة ؛

docker exec -it web.xczrerg6yca1f8ruext0br2ow.kv8iqp0wdzj3bw7325j9lw8qe sh -c 'ping -c3 -w1 something'
PING something (10.0.0.4): 56 data bytes
64 bytes from 10.0.0.4: seq=0 ttl=64 time=0.251 ms

--- something ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.251/0.251/0.251 ms

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

نقدر المعلومات كثيرا!

@ tkeeler33 --opt encrypted يجب ألا يؤثر على تعيين منفذ المضيف. الغرض الوحيد من الخيار المشفر هو تشفير حركة مرور نفق vxlan بين العقد. من المستندات: "إذا كنت تخطط لإنشاء شبكة تراكب مع تشفير (--opt مشفر) ، فستحتاج أيضًا إلى التأكد من السماح بحركة مرور البروتوكول 50 (ESP)." هل يمكنك التحقق من التكوينات الخاصة بك للتأكد من السماح بـ ESP؟
كذلك ، فإن الخيار --opt encrypted هو مجرد تشفير لمستوى البيانات. يتم تشفير كل حركة مرور مستوى التحكم (تبادلات التوجيه وتوزيع اكتشاف الخدمة وما إلى ذلك ...) افتراضيًا حتى بدون الخيار.

mavenugo أنت على حق. عندما أنشأت شبكة جديدة بـ --opt encrypted عملت بشكل جيد. عندما قارنت الشبكة التي تم إنشاؤها حديثًا مع الشبكة الحالية ، لاحظت أنه تم تعيين "Internal": true . من المحتمل أن تكون هذه هي المشكلة وكان خطأ أثناء الإنشاء الأولي للشبكة ... شكرًا لمساعدتك وتوضيحك ، لقد مر يومًا طويلاً ...

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

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

sanimej ما زلت لا أرى سبب استحالة القيام بذلك بدون NAT. ألا يمكن أن يكون لدينا خيار استخدام ، على سبيل المثال ، تدفق LVS-DR العادي؟ يضيف Docker vip non-arp إلى العقد المناسبة ، ويوجه LVS الحزم الواردة إلى العقد ، وتعود الحزم الصادرة مباشرة. لماذا يهم أن الحزمة الواردة يمكن أن تصطدم بأي مضيف؟ هذا لا يختلف عن LVS القياسي مع عدة خوادم أمامية وخلفية متعددة.

thaJeztah شكرا على الحل :)
إذا كنت تنشر الوكيل الخاص بك مع إنشاء الإصدار 3 ، فإن بناء جملة النشر الجديد غير مدعوم حتى نتمكن من تصحيح الخدمة المنشورة باستخدام هذا الأمر (استبدل nginx_proxy باسم الخدمة)

docker service update nginx_proxy \
    --publish-rm 80 \
    --publish-add "mode=host,published=80,target=80" \
    --publish-rm 443 \
    --publish-add "mode=host,published=443,target=443"

dack في تدفق LVS-DR العادي ، سيكون عنوان IP الوجهة هو خدمة VIP. لذلك يمكن لـ LB إرسال الحزمة إلى الواجهة الخلفية دون تغيير عنوان IP. هذا ليس هو الحال مع شبكة التوجيه لأن عنوان IP الخاص بالحزمة الواردة سيكون أحد IP الخاص بالمضيف.

sanimej هل من تعليق على الاقتراح أعلاه لاستخدام وضع تغليف IPIP لحل هذه المشكلة؟

يعمل نفق tlvenn LVS-IP بشكل مشابه جدًا لـ LVS-DR ، باستثناء أن الواجهة الخلفية تحصل على الحزمة من خلال IP في نفق IP بدلاً من إعادة كتابة mac. لذلك فإن لديها نفس المشكلة بالنسبة لحالة استخدام شبكة التوجيه.

من الاقتراح الذي أشرت إليه ..
The real server receives the enclosing packet, decapsulates it and sees real client IP as source and virtual service IP as destination.

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

شكرا على التوضيح sanimej. هل يمكنك ربما تنفيذ بروتوكول PROXY ؟ لن يوفر حلاً سلسًا ولكنه على الأقل سيقدم للخدمة حلاً لحل عنوان IP الخاص بالمستخدم.

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

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

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

تضمين التغريدة
هل هناك أي حل بديل في الوقت الحالي لإعادة توجيه عنوان IP الحقيقي من حاوية Nginx إلى حاوية الويب؟
لدي حاوية Nginx تعمل في الوضع global وتم نشرها في host ، لذلك تحصل حاوية Nginx على عنوان IP الصحيح. ترى كلتا الحاوية بعضهما البعض بشكل جيد ، ومع ذلك ، تحصل حاوية الويب على عنوان IP لحاوية Nginx ، وليس عنوان عميل.
Nginx هو وكيل عكسي للويب ، ويقوم الويب بتشغيل uwsgi على المنفذ 8000:

server {
    resolver 127.0.0.11;
    set $web_upstream http://web:8000;

    listen 80;
    server_name domain.com;
    location / {
        proxy_pass $web_upstream;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

lpakula الرجاء التحقق من إجابتي أعلاه + تكوين nginx هذا

@ pi0 شكرا على الرد

أنا أستخدم تكوين nginx من الرابط ، لكن عنوان IP لا يزال خاطئًا ، يجب أن يكون لدي شيء مفقود في التكوين الخاص بي

لدي مجموعة سرب ( وخدمتين

    docker service create --name nginx --network overlay_network --mode=global \
        --publish mode=host,published=80,target=80 \
        --publish mode=host,published=443,target=443 \
        nginx:1.11.10

    docker service create --name web --network overlay_network \
        --replicas 1 \
        web:newest

تستخدم حاوية Nginx أحدث حاوية رسمية https://hub.docker.com/_/nginx/
تقوم حاوية الويب بتشغيل خادم uwsgi على المنفذ 8000

أنا أستخدم nginx.conf عالميًا من الرابط ويبدو conf.d/default.conf النحو التالي:

   server {
       resolver 127.0.0.11;
       set $web_upstream http://web:8000;

       listen 80;
       server_name domain.com;
       location / {
        proxy_pass $web_upstream;
      }
  }

ثم سجلات حاوية nginx:

  194.168.X.X - - [17/Mar/2017:12:25:08 +0000] "GET / HTTP/1.1" 200

سجلات حاوية الويب:

  10.0.0.47 - - [17/Mar/2017 12:25:08] "GET / HTTP/1.1" 200 -

ما هو مفقود هناك؟

سيظل عنوان IP خاطئًا. لكنها ستضيف رؤوس HTTP أن
تحتوي على عنوان IP حقيقي. يجب عليك تكوين خادم الويب الخاص بك من اختيارك
للثقة بالوكيل (استخدم العنوان بدلاً من IP المصدر)
يوم الجمعة ، 17 مارس ، 2560 الساعة 7:36 مساءً Lukasz Pakula [email protected]
كتب:

@ pi0 https://github.com/pi0 شكرا على الرد

أنا أستخدم تكوين nginx من الرابط ، لكن عنوان IP لا يزال
خطأ ، يجب أن يكون لدي شيء مفقود في التكوين الخاص بي

لدي مجموعة سرب (
خدمات

docker service create --name nginx --network overlay_network --mode=global \
    --publish mode=host,published=80,target=80 \
    --publish mode=host,published=443,target=443 \
    nginx:1.11.10

docker service create --name web --network overlay_network \
    --replicas 1 \
    web:newest

تستخدم حاوية Nginx أحدث حاوية رسمية
https://hub.docker.com/_/nginx/ http: // url
تقوم حاوية الويب بتشغيل خادم uwsgi على المنفذ 8000

أنا أستخدم nginx.conf العمومي من الرابط ويبدو أن conf.d / default.conf
على النحو التالي:

الخادم {
محلل 127.0.0.11 ؛
تعيين $ web_upstream http: // web : 8000 ؛

   listen 80;
   server_name domain.com;
   location / {
    proxy_pass $web_upstream;
  }

}

ثم سجلات حاوية nginx:

194.168.XX - - [17 / Mar / 2017: 12: 25: 08 +0000] "GET / HTTP / 1.1" 200

سجلات حاوية الويب:

10.0.0.47 - - [17 / مارس / 2017 12:25:08] "GET / HTTP / 1.1" 200 -

ما هو مفقود هناك؟

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

>

بانج ،
بانجامابونج سيرمسواتسري
هاتف. (+66) 869761168

lpakula آه هناك شيء آخر لديك web:newest صورة يجب أن تحترم X-Real-IP رأس أيضا. لن يقوم nginx تلقائيًا بتغيير عنوان IP للمرسلين ، بل يرسل فقط رأس تلميح.

تضمين التغريدة
لا معنى له ، شكرا يا شباب!

اربط المنفذ باستخدام وضع المضيف.

يدعم nginx شفافية IP باستخدام وحدة TPROXY kernel .

stevvooe هل يستطيع Docker فعل شيء

يدعم nginx شفافية IP باستخدام وحدة TPROXY kernel.
stevvooe هل يستطيع Docker فعل شيء

من غير المحتمل ، لأن الإدخال يحتاج إلى تتبع عبر العقد. سأدعsanimej أوmavenugo.

هل يمكن أن توفر السرب واجهة برمجة تطبيقات REST للحصول على عنوان IP الخاص بالعميل؟

ttonysongtl لا علاقة له بهذه المشكلة

هناك شيء آخر يجب مراعاته وهو كيفية توصيل حركة المرور الخاصة بك إلى العقد الخاصة بك في إعداد متاح للغاية. يجب أن تكون العقدة قادرة على النزول دون حدوث أخطاء للعملاء. التوصية الحالية هي استخدام موازن تحميل خارجي (ELB ، F5 ، إلخ) وتوازن الحمل في الطبقة 4 لكل عقدة Swarm ، مع فحص صحي بسيط للطبقة 4. أعتقد أن F5 يستخدم SNAT ، لذا فإن أفضل حالة في هذا التكوين هي التقاط IP الفردي الخاص بـ F5 ، وليس عنوان IP الحقيقي للعميل.

مراجع:
https://docs.docker.com/engine/swarm/ingress/#configure -an-external-load-balancer
https://success.docker.com/Architecture/Docker_Reference_Architecture٪3A_Docker_EE_Best_Practices_and_Design_Considerations
https://success.docker.com/Architecture/Docker_Reference_Architecture٪3A_Universal_Control_Plane_2.0_Service_Discovery_and_Load_Balancing

يعكس التعليق أعلاه - هل يمكن عدم استخدام بروتوكول الوكيل؟ تستخدم جميع موازنات التحميل السحابي و haproxy هذا للحفاظ على عنوان IP المصدر.

يحتوي Calico أيضًا على وضع ipip - https://docs.projectcalico.org/v2.2/usage/configuration/ip-in-ip - وهو أحد أسباب استخدام جيثب له. https://githubengineering.com/kubernetes-at-github/

أهلا.

من أجل التفاهم والاكتمال ، اسمحوا لي أن ألخصني وأرجو تصحيح ما إذا كنت مخطئًا:

المشكلة الرئيسية هي أن الحاويات لا تتلقى src-IP الأصلية ولكن سرب VIP. لقد قمت بتكرار هذه المشكلة مع السيناريو التالي:

create docker swarm
docker service create --name web --publish 80:80 nginx
access.log source IP is 10.255.0.7 instead of client's browser IP

يبدو:

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

يبدو kobolog https://github.com/moby/moby/issues/25526#issuecomment -258660348 و dack https://github.com/moby/moby/issues/25526#issuecomment -260813865 تم دحض مقترحات sanimej https://github.com/moby/moby/issues/25526#issuecomment -280722179 https://github.com/moby/moby/issues/25526#issuecomment -281289906 ولكن ، TBH ، حججه ليست واضحة تمامًا أنا حتى الآن ، ولا أفهم لماذا لم يتم إغلاق الموضوع إذا كان هذا مستحيلًا بشكل قاطع.

sanimej أليس هذا العمل ؟:

1. يتلقى Swarm رسالة مع src-IP = A والوجهة = "my-service-virtual-address"
2. يتم إرسال الحزمة إلى عقدة سرب تقوم بتشغيل تلك الخدمة ، وتغليف الرسالة الأصلية.
3. تعيد العقدة توجيه مهمة تغيير الوجهة إلى عنوان IP لتشغيل الحاوية
   يمكن أن تحتفظ السرب والعقد بالجداول لضمان إعادة توجيه حركة المرور من نفس الأصل إلى نفس العقدة كلما أمكن ذلك.

ألن يحل خيار تمكين "الوكيل العكسي بدلاً من NAT" لخدمات معينة كل هذه المشكلات التي ترضي الجميع؟

من ناحية أخرى ، IIUC ، الخيار الوحيد المتبقي هو استخدام https://docs.docker.com/engine/swarm/services/#publish -a-services-ports-direct-on-the-swarm-node ، والتي -مرة أخرى IIUC- يبدو أنه لا يستخدم شبكة على الإطلاق ، وبالتالي لا أرى فوائد استخدام وضع السرب (مقابل تكوين). في الواقع ، يبدو أنه سرب ما قبل 1.12 ، يحتاج إلى القنصل وهكذا.

شكرا لمساعدتك و صبرك.
يعتبر

تضمين التغريدة
أكثر من ذلك ... لماذا لا يقوم Docker فقط بإعادة توجيه المنفذ NAT (تغيير عنوان IP / المنفذ فقط)؟

1. يتلقى السرب رسالة "من A إلى myservice"
2. يقوم Swarm بإعادة توجيه الرسالة إلى المضيف الذي يقوم بتشغيل تلك الخدمة ، مع تعيين dest = node1
3. يتلقى Node1 الرسالة "من A إلى node1" ، ويقوم بإعادة توجيه الإعداد dest = container1
4. تتلقى الحاوية 1 الرسالة "من أ إلى الحاوية 1"
5. للرد ، استخدم الحاوية مسار البوابة الافتراضية

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

• تعد القدرة على الحصول على مقاييس تفصيلية من أين يأتي المستخدمون أمرًا حيويًا لهندسة الشبكة / الخدمة.

• في العديد من تطبيقات الأمان ، تحتاج إلى الوصول إلى عنوان IP الأصلي للسماح بالقائمة السوداء الديناميكية بناءً على إساءة استخدام الخدمة.

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

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

هل يمكن لفريق Docker النظر في هذه التعليقات ومعرفة ما إذا كانت هناك طريقة ما لتقديم هذه الوظيفة ، مع الحفاظ على الجودة والمرونة الموجودة في نظام Docker البيئي؟

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

Jitsusama هل تستطيع Kubernetes حل مشكلتك؟

thaJeztah هل هناك طريقة للقيام بهذا العمل باستخدام عامل البناء؟

حاولت

`services:
  math:
    build: ./math
    restart: always
    ports:
    - target: 12555
      published: 12555
      mode: host

ولكن يبدو أنه يأخذ 172.xx1 باعتباره IP المصدر

trajano ، ليس لدي أدنى فكرة. هل تمكنت Kubernetes بطريقة ما من التغلب على هذه المشكلة؟

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

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

ولكن يبدو أنه يأخذ 172.xx1 باعتباره IP المصدر

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

أما بالنسبة إلى حل الإنشاء ، فمن الممكن. هنا ، أستخدم الصورة jwilder/nginx-proxy كخادم وكيل عكسي للواجهة الأمامية (لتبسيط المفاهيم) جنبًا إلى جنب مع صورة إنشاء رسمية nginx كخدمة خلفية. أقوم بنشر المكدس في وضع Docker Swarm:

version: '3.3'

services:

  nginx-proxy:
    image: 'jwilder/nginx-proxy:alpine'
    deploy:
      mode: global
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

  nginx:
    image: 'nginx:1.13.5-alpine'
    deploy:
      replicas: 3
    ports:
      - 80
      - 443
    environment:
      - VIRTUAL_HOST=website.local

$ echo '127.0.0.1 website.local' | sudo tee -a /etc/hosts

$ docker stack deploy --compose-file docker-compose.yml website

سيؤدي هذا إلى إنشاء شبكة website_default للمكدس. تم تحديد نقطة النهاية الخاصة بي في متغير البيئة VIRTUAL_HOST والوصول إلى http://website.local يعطيني:

website_nginx-proxy.0.ny152x5l9sh7<strong i="30">@Sherry</strong>    | nginx.1    | website.local 172.18.0.1 - - [08/Sep/2017:21:33:36 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36"

website_nginx.1.vskh5941kgkb<strong i="33">@Sherry</strong>    | 10.0.1.3 - - [08/Sep/2017:21:33:36 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36" "172.18.0.1"

لاحظ أن نهاية رأس website_nginx.1.vskh5941kgkb بها تلميح لعنوان IP الأصلي ( 172.18.0.1 ). يتم تعيين X-Forwarded-For & X-Real-IP في nginx.tmpl من jwilder/nginx-proxy افتراضيًا.

بالنسبة إلى المنفذ 443 ، لم أتمكن من إضافة كلا المنفذين في ملف إنشاء عامل الإرساء ، لذلك أستخدم فقط:

docker service update website_nginx-proxy \
    --publish-rm 80 \
    --publish-add "mode=host,published=80,target=80" \
    --publish-rm 443 \
    --publish-add "mode=host,published=443,target=443" \
    --network-add "<network>"

أثناء إضافة الشبكات التي أرغب في عكسها مع التطبيقات التي تحتوي على متغير البيئة VIRTUAL_HOST . من الممكن وجود المزيد من الخيارات الدقيقة في الوثائق مقابل jwilder/nginx-proxy ، أو يمكنك إنشاء الإعداد الخاص بك.

تقوم وحدات التحكم في الدخول على Kubernetes بشكل أساسي بنفس الشيء ، حيث تدعم مخططات الدخول (عادةً) X-Forwarded-For و X-Real-IP مع مرونة أكبر قليلاً في اختيار ونوع المدخلات وكذلك النسخ المتماثلة للنشر.

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

https://www.haproxy.com/blog/haproxy/proxy-protocol/

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

بمجرد إعداد بروتوكول الوكيل ، يمكنك الوصول إلى هذه المعلومات من أي ملف
خدمات المصب مثل
https://github.com/nginxinc/kubernetes-ingress/blob/master/examples/proxy-protocol/README.md

حتى الفتحة المفتوحة تستفيد من هذا للحصول على معلومات IP المصدر
https://docs.openshift.org/latest/install_config/router/proxy_protocol.html

هذا هو أحدث إدخال haproxy لـ k8s يقوم بحقن بروتوكول الوكيل.

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

أنا لا أؤيد القيام بذلك بأي طريقة أخرى خاصة عندما يكون هناك ملف
المعيار المقبول عمومًا للقيام بذلك.

قام Traefik بإضافة دعم proxy_protocol قبل بضعة أسابيع وهو متاح من v1.4.0-rc1 وما بعده.

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

في 10 سبتمبر 2017 الساعة 21:42 ، كتب "monotykamary" [email protected] :

قام Traefik بإضافة دعم proxy_protocol
https://github.com/containous/traefik/pull/2004 قبل بضعة أسابيع وهو
متوفر بدءًا من الإصدار 1.4.0-rc1 وما بعده.

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

أنا مرتبك أيضًا بشأن علاقة هذا الخطأ بالبنية التحتية. على سبيل المثال https://github.com/docker/infrakit/pull/601 ، هل يمكن لشخص ما التعليق على الاتجاه الذي سيتخذه سرب الرصيف؟

سوف تتراكم سرب في البنية التحتية؟ أنا حريص بشكل خاص على جانب الدخول منه.

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

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

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

لقد قمنا بنشر خدمة nginx الخاصة بنا باستخدام وضع النشر

mostolog شكرا

1. publishMode لم يحل المشكلة على الإطلاق. لا يزال اتصال المقبس الداخلي يحل إلى الشبكة المحلية التي يتم إعدادها. على الأقل عند استخدام قائمة المنافذ mode: host
2. nginx ليس حلاً جيدًا حقًا. تطبيقنا يعتمد على بروتوكول TCP ، ولكنه ليس خادم ويب. لا توجد أي رؤوس يمكننا استخدامها بدون تشفيرها يدويًا.
3. إذا استخدمت docker run --net=host ... ، فكل شيء يعمل بشكل جيد.
4. الحل الوحيد الذي رأيته يعمل حتى الآن هو استخدام: https://github.com/moby/moby/issues/25873#issuecomment -319109840

blazedd في كومة لدينا:

    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host

ولذا ، أراهن أننا نحصل على عناوين IP حقيقية في سجلاتنا.

mostolog لا يعمل على Windows على الأقل. ما زلت أحصل على العنوان 172.0.0.x كمصدر.

mostolog mode: host لا يعرض حاويتك للشبكة المضيفة. إنه يزيل الحاوية من شبكة الدخول ، وهي الطريقة التي يعمل بها Docker عادةً عند تشغيل الحاوية. من شأنه أن يكرر --publish 8080:8080 المستخدم في أمر تشغيل عامل الإرساء. إذا كان nginx يحصل على ips حقيقية ، فهذا ليس نتيجة توصيل المقبس بهذه الـ IPS مباشرة. لاختبار ذلك ، يجب أن تفكر بجدية في استخدام تطبيق TCP خام أو خادم HTTP ، بدون إطار عمل ، والتحقق من العنوان المبلغ عنه.

لماذا لا تستخدم شبكة توجيه IPVS للحاوية مباشرة؟ قم بربط جميع ips لواجهة تراكب عقدة السرب كـ ips افتراضية ، استخدم ip rule from xxx table xxx لإنشاء بوابة متعددة ، ثم يمكن لعقد السرب توجيه العميل إلى الحاوية مباشرة (DNAT) ، بدون أي برنامج خادم وكيل لشبكة مساحة المستخدمين (dockerd)

@ blazedd هل جربته؟ أحصل على عناوين IP خارجية عند اتباع مثالmostolog .

أنا أواجه هذه المشكلة مرة أخرى.

الإعداد الخاص بي على النحو التالي:

• موازن تحميل ipvs في وضع DR (خارجي لسرب الرصيف)
• 3 عُقد عامل إرساء ، مع عنوان IP للوجهة مُضاف إلى جميع العقد و ARP مهيأ بشكل مناسب لتوجيه IPVS DR

أرغب في نشر مكدس على السرب وجعله يستمع على المنفذ 80 على IP الظاهري دون تشويه العناوين.

يمكنني الوصول إلى هناك تقريبًا عن طريق القيام بذلك:
الموانئ:
- الهدف: 80
تاريخ النشر: 80
البروتوكول: برنامج التعاون الفني
الوضع: المضيف

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

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

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

لدينا نفس القضية.
سأصوت لصالح حل شفاف داخل عامل ميناء يسمح لجميع التطبيقات (بعضها يستخدم UDP / TCP الخام ، وليس HTTP على وجه الخصوص) للعمل كما هو متوقع.

يمكنني استخدام الحل البديل "mode = host port publishing" أثناء نشر خدمتي عالميًا.
ومع ذلك ، يبدو أن هذا غير متوافق مع استخدام برنامج تشغيل شبكة macvlan ، والذي أحتاجه لبعض الأسباب الأخرى.
نحصل على سجلات مثل "برنامج تشغيل macvlan لا يدعم تعيينات المنافذ".
حاولت استخدام شبكات متعددة ، لكنها لا تساعد.

لقد أنشأت تذكرة محددة هنا: https://github.com/docker/libnetwork/issues/2050
هذا لا يترك لي حلًا في الوقت الحالي: "(

اهلا ياجماعة
هل يوجد حل بديل الآن؟ دون الحصول عليه كمنفذ مضيف تم نشره
ميناء ؟

بتاريخ 11 كانون الثاني (يناير) 2018 الساعة 00:03 ، كتب "Olivier Voortman" [email protected] :

لدينا نفس القضية.
كنت سأصوت لصالح حل شفاف داخل عامل ميناء يسمح للجميع
تطبيقات (بعضها يستخدم UDP / TCP الخام ، وليس HTTP بشكل خاص) للعمل كملف
متوقع.

يمكنني استخدام الحل البديل "mode = host port publishing" كما هي خدمتي
منتشرة عالميا.
ومع ذلك ، يبدو أن هذا لا يتوافق مع استخدام macvlan
برنامج تشغيل الشبكة ، والذي أحتاجه لبعض الأسباب الأخرى.
نحصل على سجلات مثل "برنامج تشغيل macvlan لا يدعم تعيينات المنافذ".
حاولت استخدام شبكات متعددة ، لكنها لا تساعد.

لقد أنشأت تذكرة محددة هنا: docker / libnetwork # 2050
https://github.com/docker/libnetwork/issues/2050
هذا لا يترك لي حلًا في الوقت الحالي: "(

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

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

في الإعداد الخاص بي ، الطريقة الوحيدة للحصول على عنوان IP الخاص بالعميل هي استخدام network_mode:host وعدم استخدام السرب على الإطلاق.

استخدام mode=host port publishing أو docker run -p "80:80" ... التقليدي لم يعمل

تم اقتراح بعض الحلول في https://github.com/moby/moby/issues/15086 لكن الحل الوحيد الذي نجح معي هو شبكات "المضيف" ...

هناك مشكلة أخرى تتعلق بعدم امتلاك عنوان IP الصحيح وهي أن الحد من معدل nginx لا يعمل بشكل صحيح وبالتالي لا يمكن استخدامه مع موازن تحميل سرب الرصيف ، نظرًا لأن الطلبات محدودة ويتم رفضها نظرًا لأن nginx يحسبها جميعًا لأنها تأتي من مستخدم واحد / IP. لذا فإن الحل الوحيد هو استخدام الوضع = مضيف ، ولكن بهذه الطريقة أفقد إمكانات موازنة التحميل ويجب أن أشير DNS إلى حالات محددة.

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

حتى يتمكن Docker من تمرير معلومات العميل عبر شبكات التراكب ، يمكن للمرء استخدام وكيل مثل Docker Flow Proxy أو Traefik ، ونشر المنافذ المطلوبة في وضع المضيف في تلك الخدمة وتوصيل خدمات التطبيق بها. ليس حلاً كاملاً ولكنه يعمل بشكل جيد ويسمح بموازنة تحميل خدمات التطبيق / استرداد عنوان IP للعميل.

@ deeky666 Traefik وأعمال مماثلة فقط إذا لم يتم ترسيخها

لا أرى دعم udo على traefik

مرسل من الايفون الخاص بي

أخيرًا تخلينا عن حاوية الرصيف. إنه ليس جاهزًا للإنتاج!

في الأربعاء 24 يناير 2018 الساعة 5:43 صباحًا ، كتب Efrain [email protected] :

لا أرى دعم udo على traefik

مرسل من الايفون الخاص بي

>

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

يبدو أن المشكلة قد تم حلها جزئيًا في 17.12.0-ce باستخدام mode=host .

docker service create --publish mode=host,target=80,published=80 --name=nginx nginx

لديها بعض القيود (لا يوجد شبكة توجيه) ولكنها تعمل!

عملتgoetas mode=host لفترة من الوقت كحل بديل ، لذلك لن أقول إن المشكلة قد تم حلها بطريقة ما. استخدام الوضع = يحتوي المضيف على الكثير من القيود ، ويتم كشف المنفذ ، ولا يمكنه استخدام موازنة حمل السرب ، وما إلى ذلك.

darklow أعرف القيود ، لكن بالنسبة لحالة الاستخدام الخاصة بي فهي جيدة (إن لم تكن أفضل!). في 17.09.1-ce لم يكن يعمل على الإطلاق ، لذلك بالنسبة لي هو بالفعل تحسن!

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

أنا موافق. يحتاج Swarm إلى طريقة توفر عالية للحفاظ على IP المصدر.

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

هل هناك من ينظر في هذا؟

في 28-يناير -2018 22:39 ، كتب "Genki Takiuchi" [email protected] :

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

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

sandys أوافق. سيكون بروتوكول الوكيل فكرة رائعة.
thaJeztahaluzzardimrjana هل يمكن أن تحظى هذه المشكلة ببعض الاهتمام من فضلك؟ لم يكن هناك أي رد من الفريق لفترة من الوقت. شكرا لك.

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

goetas ، لقد

هذا أمر سيء للغاية ، فهو يخفف من أي قيود على الأسعار ، ومنع الاحتيال ، وتسجيل الدخول ، وتسجيل الدخول الآمن ، ومراقبة الجلسة ، وما إلى ذلك!
الاستماع مع الوضع: يعمل

هذا خطأ حرج ومهم للغاية بالنسبة لنا وهذا يمنعنا من بدء البث المباشر مع Swarm. نعتقد أيضًا أن بروتوكول الوكيل هو الحل الصحيح لذلك. يجب أن يمر دخول Docker IP المصدر على بروتوكول الوكيل.

أحد الحلول التي تم اقتراحها على موقع تويتر هو استخدام Traefik باعتباره دخولًا مُدارًا خارج Swarm . هذا هو دون المستوى الأمثل بالنسبة لنا - وليس النفقات العامة التي نرغب في إدارتها.

إذا أراد مطورو Swarm التحقق من كيفية تنفيذ بروتوكول الوكيل في Swarm-ingress ، فيجب عليهم التحقق من جميع الأخطاء التي تتم مناقشتها في Traefik (على سبيل المثال https://github.com/containous/traefik/issues/2619)

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

بعض المخاوف بشأن بروتوكول الوكيل:

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

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

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

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

بروتوكول الوكيل له قبول واسع. تحقق من عدد الأدوات المدعومة - https://www.haproxy.com/blog/haproxy/proxy-protocol/
حتى أنه لا يغطي موازنات التحميل السحابي (ELB و Google LB) والأدوات الأحدث مثل Traefik.

أيضًا - هذا هو المعيار إلى حد كبير في kubernetes: https://github.com/kubernetes/ingress-nginx#proxy -protocol

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

هذه هي بروتوكولات L7. دخول السرب هو L4. لا يوجد شيء يتم إعادة اختراعه هنا ، كل IPVS يستخدم DNAT.

@ cpuguy83 لم أستطع فهم ما قصدته للتو.

بروتوكول الوكيل هو الطبقة 4.
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

هدف بروتوكول PROXY هو ملء الهياكل الداخلية للخادم بامتداد
المعلومات التي تم جمعها بواسطة الوكيل والتي كان يمكن للخادم الحصول عليها
بمفرده إذا كان العميل يتصل مباشرة بالخادم بدلاً من الاتصال عبر a
الوكيل. المعلومات التي يحملها البروتوكول هي المعلومات التي يحملها الخادم
الحصول على استخدام getpename () و getpeername ():

• عائلة العنوان (AF_INET لـ IPv4 ، AF_INET6 لـ IPv6 ، AF_UNIX)
• بروتوكول مأخذ التوصيل (SOCK_STREAM لـ TCP ، SOCK_DGRAM لـ UDP)
• الطبقة 3 عناوين المصدر والوجهة
• منافذ المصدر والوجهة من الطبقة 4 إن وجدت

http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#5.1 -ccept-proxy

قبول الوكيل

يفرض استخدام بروتوكول PROXY عبر أي اتصال يقبله أي من
أعلن مآخذ على نفس الخط. الإصداران 1 و 2 من بروتوكول PROXY
مدعومة واكتشافها بشكل صحيح. يفرض بروتوكول PROXY الطبقة
3/4 عناوين الاتصال الوارد لاستخدامها في كل مكان يوجد فيه العنوان
مستخدمة ، مع الاستثناء الوحيد لقواعد "اتصال طلب TCP" التي سوف
انظر فقط عنوان الاتصال الحقيقي. سوف تعكس السجلات العناوين
المشار إليها في البروتوكول ، ما لم يتم انتهاكها ، في هذه الحالة الحقيقي
سيظل العنوان مستخدمًا. هذه الكلمة الرئيسية مدمجة مع دعم خارجي
يمكن استخدام المكونات كبديل فعال وموثوق لـ
آلية X-Forwarded-For التي لا يمكن الاعتماد عليها دائمًا ولا حتى دائمًا
صالحة للاستعمال. راجع أيضًا "tcp-request connect connection-proxy" للحصول على دقة أفضل
تحديد العميل الذي يُسمح له باستخدام البروتوكول.

هل تقصد أن هناك طريقة أفضل من بروتوكول الوكيل؟ هذا ممكن تمامًا وأرغب في معرفة المزيد في سياق الحفاظ على بروتوكول الإنترنت المصدر في سرب الرصيف. ومع ذلك ، فإن Proxy Protocol مدعوم على نطاق واسع من خلال أدوات أخرى (مثل nginx ، إلخ) والتي ستكون في اتجاه المصب لدخول الحشود ... بالإضافة إلى أدوات مثل AWS ELB التي ستنتقل إلى سرب الدخول. كان هذا هو 0.02 دولار فقط

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

لا أرغب في دعم هذا في جوهره ، ولكن ربما يكون جعل الدخول قابلاً للتوصيل نهجًا جديرًا بالاهتمام.

sandys https://github.com/sandys بروتوكول الوكيل يشبه
التغليف (على الأقل عند بدء الاتصال) ، والذي يتطلب المعرفة
للتغليف من جهاز الاستقبال على طول الطريق إلى أسفل المكدس. هناك
هناك الكثير من المقايضات في هذا النهج.

هذا صحيح. هذا إلى حد كبير سبب كونه معيارًا مع RFC. هناك
على الرغم من الزخم وراء هذا - إلى حد كبير أهمية كل عنصر
يدعمها. IMHO ليس قرارًا سيئًا لدعمه.

لا أريد أن أؤيد هذا في جوهره ، لكن ربما أقوم بالدخول
التوصيل سيكون نهجا مفيدا.

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

ما زلت أطلب منك اعتبار بروتوكول الوكيل حلاً رائعًا لـ
هذه المشكلة التي تحظى بدعم الصناعة.

هل من غير الممكن محاكاة جهاز توجيه L3 على Linux و LxCs (ليس عامل ميناء على وجه التحديد)

trajano المحاكاة ليست ضرورية ولكن التغليف لحل هذه المشكلة.
على سبيل المثال ، يمكن توفير خيار (على سبيل المثال: --use-proxy-protocol ) للخدمات التي تحتاج إلى عنوان IP للعميل ويعرف كيف يتعامل مع الحزم المغلفة مثل nginx.

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

هذه مشكلة تم حلها في مشاريع أخرى. على سبيل المثال ، مع OpenStack ، يمكنك استخدام أنفاق مثل GRE و VXLAN.

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

هل يوجد أي شخص في الجزء الأخير من هذا الموضوع هنا ليمثل فريق عامل الميناء ويقول على الأقل "نسمعك"؟

/ سم مكعبGordonTheTurtlethaJeztahriyazdfaluzzardi

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

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

@ cpuguy83 لقد كنت https://github.com/kubernetes/kubernetes/issues/42616 (ملاحظة: من المثير للاهتمام أن بروتوكول الوكيل هنا يتدفق من Google Kubernetes Engine ، والذي يدعم بروتوكول الوكيل محليًا في وضع HTTPS).

بالإضافة إلى ذلك ، أضاف ELB دعمًا لبروتوكول Proxy Protocol v2 في نوفمبر 2017 (https://docs.aws.amazon.com/elasticloadbalancing/latest/network/doc-history.html)

Openstack Octavia LB-as-a-service (على غرار ingress) بروتوكول الوكيل المدمج في أبريل الماضي - http://git.openstack.org/cgit/openstack/octavia/commit/؟id=bf7693dfd884329f7d1169eec33eb03d2ae81ace

إليك بعض الوثائق حول بروتوكول الوكيل في Openstack - https://docs.openshift.com/container-platform/3.5/install_config/router/proxy_protocol.html
تدور بعض الفروق الدقيقة حول بروتوكول الوكيل لـ https (سواء في الحالات التي تقوم فيها بإنهاء الشهادات عند الدخول أم لا).

هل هناك أي تحديثات / حلول بديلة بخصوص هذه المشكلة؟ نحتاج حقًا إلى معرفة عنوان IP الخاص بالعميل في وضع docker swarm.
أي مساعدة سيكون محل تقدير كبير.

نسختي:

عميل:
الإصدار: 18.02.0-ce
إصدار API: 1.36
إصدار Go: go1.9.3
Git الالتزام: fc4de44
تاريخ البناء: الأربعاء 7 فبراير 21:16:33 2018
OS / Arch: لينكس / amd64
التجريبية: خطأ
المنسق: سرب

الخادم:
محرك:
الإصدار: 18.02.0-ce
إصدار API: 1.36 (الحد الأدنى للإصدار 1.12)
إصدار Go: go1.9.3
Git الالتزام: fc4de44
تاريخ البناء: الأربعاء 7 فبراير 21:15:05 2018
OS / Arch: لينكس / amd64
التجريبية: خطأ

adijes والمستخدمين الآخرين الذين يواجهون هذه المشكلة. يمكنك ربط الحاويات بشبكة bridge (كما ذكر البعض في هذا الموضوع).

version: "3.4"

services:
  frontend:
    image: nginx
    deploy:
      placement:
        constraints:
          - node.hostname == "prod1"
    networks:
      - default
      - bridge
  # backed services...
  # ...

networks:
  bridge:
    external:
      name: bridge

يرتبط frontend بـ bridge ويبقى دائمًا في مضيف محدد ، عنوان IP الخاص به مرتبط بمجالنا العام. هذا يمكّنه من تلقي IP للمستخدم الحقيقي. ولأنه يرتبط أيضًا بشبكة default ، فإنه سيكون قادرًا على الاتصال بالخدمات المدعومة.

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

تم التعديل لإضافة المزيد من المعلومات:

توجد حاويات nginx الخاصة بي خلف https://github.com/jwilder/nginx-proxy ، كما أنني أستخدم https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion لتمكين SSL. يتم تشغيل nginx-proxy عبر الأمر docker run ، وليس خدمة سرب الرصيف. ربما لهذا السبب حصلت على IP حقيقي من العملاء. مطلوب شبكة bridge للسماح لحاويات nginx بالاتصال مع وكيل nginx.

FWIW ، أنا أستخدم:

Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:25:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

يعمل الإعداد أعلاه أيضًا على إعداد آخر يعمل:

Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:25:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

@ letientai299 الذي لا يعمل بالنسبة لي أحصل عليه

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

لدي عقدة رئيسية وثلاث عمال

trajano ، راجع التحديث الخاص بي.

@ letientai299 في الواقع كنت أتساءل كيف حصلت على bridge للعمل في وضع السرب . أي أنك لم تحصل على الخطأ لدي.

dack عندما تقول مضيف الشبكات أفترض أنك تعني وجود

ports:
- target: 12555
  published: 12555
  protocol: tcp
  mode: host

لسوء الحظ ، عند تشغيله في وضع docker stack deploy فإنه لا يعمل ولا يزال يفقد عنوان IP المصدر بينما يعمل عامل الإرساء بشكل صحيح.

لقد جربت أيضًا ما يلي استنادًا إلى goetas

docker service create --constraint node.hostname==exposedhost \
  --publish published=12555,target=12555,mode=host \
  trajano.net/myimage

لا يوجد حتى الآن حظ في الحصول على IP المصدر هذا على Server Version: 17.12.0-ce

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

عميل:
الإصدار: 17.12.0-ce
إصدار API: 1.35
نسخة Go: go1.9.2
Git الالتزام: c97c6d6
تاريخ البناء: الأربعاء 27 ديسمبر 20:03:51 2017
نظام التشغيل / القوس: darwin / amd64

الخادم:
محرك:
الإصدار: 17.12.1-ce
إصدار API: 1.35 (الحد الأدنى للإصدار 1.12)
نسخة Go: go1.9.4
Git الالتزام: 7390fc6
تاريخ البناء: الثلاثاء 27 فبراير 22:17:54 2018
OS / Arch: لينكس / amd64
التجريبية: صحيح

إنه 2018. هل من جديد بخصوص هذا الموضوع؟
في وضع السرب ، لا يمكنني استخدام حد طلب nginx. اشتعلت $ remote_addr دائمًا 10.255.0.2.
هذه مشكلة خطيرة حقًا بخصوص سرب عمال الرصيف.
ربما يجب أن أحاول kubernetes منذ اليوم.

Maslow لقد نشرت حيث يوجد لدينا فقط بعض التعليقات أعلاه.

هل يمكننا الاسترخاء في الشيك

networks:
  bridge:
    external:
      name: bridge

أو تمديده مثل

networks:
  bridge:
    external:
      name: bridge
      scope: local

ولا يُسمح بالشبكات scope: local إلا إذا كان وضع الشبكة هو host

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

أو السماح

networks:
  bridge:
    driver: bridge

لا تفشل مع

فشل في إنشاء خدمة trajano_serv: استجابة خطأ من البرنامج الخفي: لا يمكن استخدام جسر trajano_bridge للشبكة مع الخدمات. يمكن فقط استخدام الشبكات المخصصة للسرب ، مثل تلك التي تم إنشاؤها باستخدام برنامج تشغيل التراكب.

عند وجود mode: host على المنافذ المنشورة.

ports:
- target: 32555
  published: 32555
  protocol: tcp
  mode: host

trajano يمكنك استخدام شبكات نطاق غير سرب مع سرب بالفعل ... على سبيل المثال هذا يعمل:

version: '3.4'

services:
  test:
    image: alpine
    command: top
    ports:
      - target: 32555
        published: 32555
        protocol: tcp
        mode: host
    networks:
      - bridge

networks:
  bridge:
    external:
      name: bridge

هل اختبرت هذا على سرب مع أكثر من عامل واحد مع نشر مكدس الرصيف. أعلم أنه يعمل مع التأليف.

في 18 مارس 2018 الساعة 8:55 مساءً ، كتب Brian Goff [email protected] :

trajano يمكنك استخدام شبكات نطاق غير سرب مع سرب بالفعل ... على سبيل المثال هذا يعمل:

الإصدار: '3.4'

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

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

نعم ، أفعل هذا من خلال سرب ...

يوم الإثنين ، 19 آذار (مارس) 2018 الساعة 9:12 صباحًا ، أرخميدس تراجانو <
[email protected]> كتب:

هل قمت باختبار هذا على سرب مع أكثر من عامل واحد بمكدس الرصيف
نشر. أعلم أنه يعمل مع التأليف.

في 18 آذار (مارس) 2018 الساعة 8:55 مساءً ، أرسل بريان جوف [email protected]
كتب:

trajano يمكنك استخدام شبكات نطاق غير سرب مع سرب بالفعل ...
على سبيل المثال هذا يعمل:

الإصدار: '3.4'

خدمات:
اختبار:
الصورة: جبال الألب
الأمر: أعلى
الموانئ:

• الهدف: 32555
  تاريخ النشر: 32555
  البروتوكول: برنامج التعاون الفني
  الوضع: المضيف
  الشبكات:
• كوبري

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

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

-

• بريان جوف

+1

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

شبكة التراكب <-> nginx proxy jwilder docker <-> nginx web head docker

لقد اتبعت الاقتراحات واستمرت السجلات في إرجاع عنوان IP لشبكة docker ip 10.255.0.3 بدلاً من Real Client IP.

+1

@ cpuguy83 بدأ هذا في أن يصبح

هل لديك أي فكرة عن ETA؟ هذا من شأنه أن يساعدنا كثيرًا.

sandys و ETA لماذا بالضبط؟

@ cpuguy83 مرحبًا ، شكرًا على ردك. أعلم أنه لا يوجد اتفاق واسع حول كيفية حلها. أنا أعلق نوعًا على كيف انشغال الفريق بقضايا الاستقرار ولم يتم تحريره من هذه المشكلة.
متى تعتقد أنه سيتم تناول هذه المشكلة (إن وجدت)؟

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

kleptog جزئيًا لا يمكنك ذلك. لا يمكن تجنب التوقف أثناء تحديث الخدمة.

سيناريو الاختبار - نظرة فاحصة على lvs / ipvs.

• nsenter إلى حاوية الإدخال المخفية وحذف قاعدة snat
• أدخل إلى الخدمة ذات المنافذ المنشورة ، واحذف gw الافتراضي وأضف المسار الافتراضي لدخول عنوان IP للحاويات.

الآن سيتم الحفاظ على عنوان IP المصدر.

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

آسف على العبث الساذج ، لكن هل يمكن لأي شخص ( dack ؟) أن

آه ، فهمت الآن. في سرب متعدد العقدة ، يجب أن يكون IP هو مدراء lvs ، للعثور على طريق العودة إلى العقدة اليمنى التي جاء فيها الطلب ...

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

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

أحتاج أيضًا إلى تحديث حول هذا - هذا مسكت كبير - الطريقة الوحيدة التي وجدتها حول هذا هي إضافة وكيل آخر في المقدمة وإرسال x-forward-for إلى المكدس ، نوع من الوسائل أن Swarm ليس خيارًا للجمهور تواجه حركة المرور للعديد من السيناريوهات.

تضمين التغريدة
أستطيع أن أؤكد أن ما يلي لا يعمل

version: '3.4'
services:
  nginx:
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80
      - mode: host
        protocol: tcp
        published: 443
        target: 81
networks:
  bridge:
    external:
      name: bridge

فشل مع network "bridge" is declared as external, but it is not in the right scope: "local" instead of "swarm" .

نسخة عامل ميناء

Client:
 Version:       18.03.0-ce-rc4
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    fbedb97
 Built: Thu Mar 15 07:33:59 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:        Wed Mar 21 23:08:31 2018
  OS/Arch:      linux/amd64
  Experimental: false

@ Mobe91
حاول إعادة تكوين السرب. أنا أيضا كان عندي خطأ. بعد إعادة السرب ، نجح كل شيء بالنسبة لي.
ملفي docker-compose.yml :

version: "3.6"

services:
    nginx:
        image: nginx:latest
        depends_on:
            - my-app
            - my-admin
        ports: 
            - target: 80
              published: 80
              protocol: tcp
              mode: host
            - target: 443
              published: 443
              protocol: tcp
              mode: host
            - target: 9080
              published: 9080
              protocol: tcp
              mode: host
        volumes:
            - /etc/letsencrypt:/etc/letsencrypt:ro
            - /home/project/data/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
            - /home/project/data/nginx/conf.d:/etc/nginx/conf.d
            - /home/project/public:/var/public
        networks:
            - my-network
            - bridge
        deploy:
            placement:
                constraints: [node.role == manager]

    my-app:
        image: my-app
        ports:
            - 8080:8080
        volumes:
            - /usr/src/app/node_modules
            - /home/project/public:/usr/src/app/public
        networks:
            - my-network

    my-admin:
        image: my-admin
        ports:
            - 9000:9000
        networks:
            - my-network

networks:
    my-network:
    bridge:
        external: true
        name: bridge

بلدي docker version :

Client:
 Version:   18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24
 Built: Wed Mar 21 23:10:01 2018
 OS/Arch:   linux/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:  18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:    Wed Mar 21 23:08:31 2018
  OS/Arch:  linux/amd64
  Experimental: false

اسف للغتى الانجليزيه.

@ Mobe91 هذا ما استخدمته لكنني أنشره من "portainer" أو على جهاز Linux. لا يمكنني الحصول عليه للنشر بشكل صحيح من Windows.

version: '3.4'
services:
  hath:
    image: trajano.net/hath
    deploy:
      placement:
        constraints:
        - node.hostname==docker-engine
    networks:
    - host
    ports:
    - target: 12555
      published: 12555
      protocol: tcp
      mode: host
    secrets:
    - hath_client_login
    volumes:
    - hath:/var/lib/hath
volumes:
  hath:
    name: 'noriko/s/hath'
    driver: cifs
networks:
  host:
    external:
      name: host
secrets:
  hath_client_login:
    external:
      name: hath_client_login

الفرق الرئيسي هو أنني أستخدم host بدلاً من bridge في حالتي ، أقوم أيضًا بتشغيل مضيفي كـ VirtualBox VMs وأستخدم جهاز التوجيه الذي يقوم بتوجيه NAT ويحافظ على عنوان IP الوارد طوال الطريق إلى الحاوية.

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

trajano على حق ، كان عميل Windows هو المشكلة ، وقد

لكني لا أفهم لماذا تحتاج حتى إلى شبكة host أو bridge ؟
ما يلي يعمل بشكل جيد بالنسبة لي ، على سبيل المثال ، أحصل على عناوين IP حقيقية للعميل في nginx:

version: '3.4'
services:
  nginx:
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80

@ Mobe91 شكرًا كنت أقصد فتح مشكلة لذلك. اربط أساسًا بـ https://github.com/moby/moby/issues/32957 نظرًا لأنه لا يزال يحدث مع عميل 18.03-ce لنظام التشغيل Windows.

هل استخدم أي شخص كيليوم؟ http://cilium.readthedocs.io/en/latest/gettingstarted/docker/ .

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

sandys good find - أنا على وشك البدء في اختباره ، هل نجح ذلك من أجلك؟ أنا على وشك سحب nginx من سربتي إذا لم أستطع إصلاح هذا .....

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

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

sandys هل جربت كيليوم؟ يشبه Weave ، الذي يبدو أنه يعاني من نفس المشكلة على الأقل مع k8s: https://github.com/kubernetes/kubernetes/issues/51014

لم أتمكن من استخدام Cilium ، لكنني تواصلت مع Cilium
devs للمساعدة في تكوين السرب. لكنني متحمس جدًا بشأن Cilium
لأن ingress هي مشكلة معلنة تريد حلها (على عكس النسج)

في الخميس 10 مايو 2018 ، الساعة 17:24 ، كتب جيمس جرين ، [email protected] :

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

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

sandys https://github.com/sandys هل جربت Cilium؟ يبدو مشابهًا لـ
Weave الذي يبدو أنه يعاني من نفس المشكلة على الأقل مع k8s:
kubernetes / kubernetes # 51014
https://github.com/kubernetes/kubernetes/issues/51014

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

في 10 مايو 2018 الساعة 17:24 ، كتب "James Green" [email protected] :

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

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

sandys https://github.com/sandys هل جربت Cilium؟ يبدو مشابهًا لـ
Weave الذي يبدو أنه يعاني من نفس المشكلة على الأقل مع k8s:
kubernetes / kubernetes # 51014
https://github.com/kubernetes/kubernetes/issues/51014

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

• 1

اهلا ياجماعة،
إذا كنت تريد دعم Docker Swarm في Cilium (خاصة للدخول و
حول هذه المشكلة تحديدًا) ، يرجى التعليق / الإعجاب بهذا الخطأ -
https://github.com/cilium/cilium/issues/4159

في الجمعة 11 مايو 2018 الساعة 12:59 صباحًا ، كتب McBacker [email protected] :

>

• 1

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

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

  web-server:
    image: blabla:7000/something/nginx:latest
    #ports:
    #  - "80:80"
    #  - "443:443"
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host        
    deploy:
      mode: global
      restart_policy:
        condition: any
      update_config:
        parallelism: 1
        delay: 30s

أستطيع أن أؤكد أن المفتاح هو استخدام ports.mode: host . من الوثائق (https://docs.docker.com/compose/compose-file/#long-syntax-1):

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

ثم ، باستخدام mode: host توقف عن موازنة التحميل عن طريق الدخول ويظهر عنوان IP الحقيقي. على سبيل المثال ، ها هي سجلات nginx الخاصة بي:

• بـ mode: host
metrics-agents_nginx.1.pip12ztq3y1h<strong i="14">@xxxxxxxx</strong> | 62.4.X.X - - [12/Jun/2018:08:46:04 +0000] "GET /metrics HTTP/1.1" 200 173979 "-" "Prometheus/2.2.1" "-" [CUSTOM] "request_time: 0.227" remote_addr: 62.4.X.X proxy_add_x_forwarded_for: 62.4.X.X

• بدون mode: host
metrics-agents_nginx.1.q1eosiklkgac<strong i="20">@xxxxxxxx</strong> | 10.255.0.2 - - [12/Jun/2018:08:50:04 +0000] "GET /metrics HTTP/1.1" 403 162 "-" "Prometheus/2.2.1" "-" [CUSTOM] "request_time: 0.000" remote_addr: 10.255.0.2 proxy_add_x_forwarded_for: 10.255.0.2

وإذا كنت تتساءل عن سبب كون السجل الأخير عبارة عن استجابة 403 محظورة ، فهذا بسبب استخدام قائمة بيضاء على nginx ( allow 62.4.X.X و deny all ).

مفهوم:
Description: Debian GNU/Linux 9.4 (stretch)
Docker version 18.03.0-ce, build 0520e24

أؤكد ما قاله nperron .
يسمح استخدام وضع المضيف بالحصول على عنوان IP للعميل.

إصدار Docker 18.03.1-ce ، الإصدار 9ee9f40
نظام التشغيل Ubuntu 16.04.4 LTS

أستطيع أن أؤكد أنها تعمل.

إصدار Docker 18.03.1-ce ، الإصدار 9ee9f40
نظام التشغيل Ubuntu 16.04.4 LTS

الكهف: لن يعمل هذا إذا كان لديك IPTABLES = خطأ!
ربما تكون قد فعلت ذلك (أو على الأقل فعلت ذلك) إذا كنت تستخدم UFW لتأمين المنافذ ووجدت أن سرب عامل الإرساء يتخطى إعدادات UFW.

هناك بعض الدروس حول ذلك تقترح ضبط iptables = false on via command أو في /etc/docker/daemon.json

آمل أن ينقذ هذا الشخص الإحباط الذي مررت به للتو!

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

TLDR: "الوضع: المضيف" هو حل بديل وليس حلاً

@ r3pek بينما أتفق معك على أنك تخسر Ingress إذا كنت تستخدم وضع المضيف لحل هذا المأزق ، فأنا أقول إنه بالكاد يهزم الغرض الكامل من Swarm ، والذي يفعل أكثر بكثير من شبكة الدخول العامة التي تواجهها. في سيناريو الاستخدام لدينا في نفس سرب التراكب:
إدارة الحاويات المنسوخة التي يجب الوصول إليها فقط عبر الإنترانت -> لا تحتاج إلى عنوان IP الخاص بالمتصل ، لذلك يتم تكوينها "بشكل طبيعي" وتستفيد من الدخول.
حاويات غير مكشوفة -> لا شيء لتقوله عن هذه (أعتقد أنك تقلل من أهمية القدرة على الوصول إليها عبر اسم خدمتهم).
خدمة عامة -> هذا وكيل nginx يقوم بالتوجيه المستند إلى https و url. تم تعريفه عالميًا حتى قبل الحاجة إلى إعادة توجيه IP للعميل الحقيقي ، لذلك لا توجد مشكلة حقيقية هناك.

إن وجود nginx عالمي وعدم وجود دخول يعني أنه يمكنك الوصول إليه عبر أي عنوان IP للمجموعة ، ولكنه ليس متوازنًا أو متسامحًا مع الأخطاء ، لذلك أضفنا أداة L4 Azure Load Balancer رخيصة جدًا وسهلة الإعداد أمام nginx الخدمات.

كما تقول ، المضيف هو حل بديل ، لكن القول بأن تمكينه يهزم تمامًا الغرض من Docker Swarm هو أمر مبالغ فيه بعض الشيء.

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

بقولك أنك استخدمت azure lb بنفسك ، فقد تحققت من صحة ذلك نوعًا ما
جدال.

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

نحن لا نقول إنه ليس حلاً مؤقتًا ... ولكنه سيكون كذلك
تجاهل وعد Swarm إذا لم نتعرف جميعًا بشكل قاطع على
عيب.

في الخميس ، 5 يوليو ، 2018 ، الساعة 14:16 ، روبرتو فابريزي ، [email protected]
كتب:

@ r3pek https://github.com/r3pek بينما أتفق معك على أنك تخسر
تدخل إذا كنت تستخدم وضع المضيف لحل هذا المأزق ، فأنا أقول ذلك
بالكاد يهزم الغرض الكامل من Swarm ، والذي يفعل أكثر من ذلك بكثير من أن أ
شبكة دخول تواجه الجمهور. في سيناريو الاستخدام لدينا لدينا في نفس
سرب تراكب:
إدارة الحاويات المنسوخة التي يجب الوصول إليها فقط عبر
إنترانت -> لا يحتاجون إلى عنوان IP الخاص بالمتصل ، لذلك تم تكوينهم
"بشكل طبيعي" والاستفادة من الدخول.
حاويات غير مكشوفة -> لا شيء يقوله عن هذه (أعتقد أنك كذلك
التقليل من أهمية القدرة على الوصول إليهم عبر خدمتهم
على الرغم من الاسم).
الحاوية العامة المواجهة -> هذا وكيل nginx يستخدم https و url
التوجيه القائم. تم تعريفه عالميًا حتى قبل الحاجة إلى x-forward-for
IP الحقيقي للعميل ، لذلك لا توجد مشكلة حقيقية هناك.

إن وجود nginx عالميًا وعدم وجود دخول يعني أنه يمكنك الوصول إليه عبر
أي IP للكتلة ، لكنها ليست متوازنة التحميل ، لذلك أضفنا جدًا جدًا
رخيص وسهل إعداد L4 Azure Load Balancer أمام nginx
الخدمات.

كما تقول ، المضيف هو حل بديل ، ولكن يقول أنه تمكينه تمامًا
هزيمة الغرض من Docker Swarm هو القليل من imo المبالغ فيه.

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

من الواضح أنه تم اختيار موازن تحميل ضعيف (IPVS) لدخول Docker Swarm. إذا كان يدعم بروتوكول الوكيل L4 على الأقل ، فلن تكون هذه مشكلة. باستثناء أنه سيظل موازن تحميل L4 (TCP) بدون جميع الميزات الإضافية التي يمكن أن يوفرها L7 lb.

في Kubernetes ، توجد موازن تحميل L4 (TCP) -L7 (HTTP) مثل إدخال nginx ، إدخال haproxy والتي تسمح كلاهما باستخدام بروتوكول الوكيل L4 أو رؤوس L7 HTTP لضمان الاستفادة من X-Forwarded-For لتمرير المستخدم الحقيقي IP إلى الواجهة الخلفية.

أتساءل ماذا سيقول مطورو Docker Swarm ingress. ربما يتعين على شخص ما نقل هذه الحالة إلى https://github.com/docker/swarmkit/issues ؟

في Kubernetes ، توجد موازن تحميل L4 (TCP) -L7 (HTTP) مثل إدخال nginx ، إدخال haproxy والتي تسمح كلاهما باستخدام بروتوكول الوكيل L4 أو رؤوس L7 HTTP لضمان الاستفادة من X-Forwarded-For لتمرير IP الحقيقي للمستخدم إلى الخلفية.

AFAICS ، لا يتم تضمين خدمات LB هذه في K8s ولكن الخدمات التي تحتاج إلى نشرها بشكل صريح. يمكنك أن تفعل الشيء نفسه مع Docker swarm أيضًا. لا أرى فرقا هنا. (بصرف النظر عن ذلك ، يبدو أن وحدة تحكم إدخال nginx "رسمية".)

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

لكي نكون منصفين - في k8s ، من الممكن أن يكون لديك إدخال مخصص. في سرب ذلك
ليس.

تتخذ سرب موقفًا مفاده أن كل شيء "مدمج". نفس الحال مع
الشبكات - في k8s ، تحتاج إلى إعداد نسج ، إلخ ... في سرب مدمج فيه.

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

في يوم السبت ، 28 يوليو ، 2018 الساعة 5:07 مساءً ، كتب Seti [email protected] :

وبقدر ما أعلم ، فإن الاختلاف هو أنه إذا قمت بنشر ملف
سيتم "استدعاء" خدمة موازنة التحميل من swarmkit loadbalancer
وهكذا تفقد IP للمستخدمين. لذلك لا يمكنك تعطيل swarmkit
loadbalancer في حالة عدم استخدام وضع المضيف.

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

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

أنا أقوم بتشغيل مجموعتي على سرب من عقدة واحدة وسأفعل ذلك للأشهر القليلة القادمة على الأقل. هل يمكنك أن توصي بأقل حل بديل لحالة الاستخدام الحالية (سرب العقدة الواحدة)؟ لا يمكنني الاستغناء عن عنوان IP الخاص بالعميل - فالكثير يعتمد عليه.

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

إذا كان الحصول على رأس x-forwarded-for كافيًا لك ، فيجب أن يعمل هذا الإعداد AFAICT.

شكرا ، maximelb. ما الذي انتهيت إليه (على سبيل المثال ، nginx ، haproxy)؟

jamiejackson حيث ستكون الأمور مختلفة بعض الشيء. في حالتنا ، نحن نشغل خادمًا يستضيف اتصالات SSL طويلة المدى وبروتوكولًا ثنائيًا مخصصًا تحته لذا لم تكن وكلاء HTTP ممكنة. لذلك أنشأنا معيد توجيه TCP بسيط واستخدمنا رأس "msgpack" يمكننا فك حزمه يدويًا على الخادم الداخلي.

لست على دراية تامة بوكلاء HTTP ولكني أشك في أن معظمهم سيفعلون الحيلة نيابة عنك. : - /

مرحبا ماكسيم ،
هذا مثير جدا للاهتمام بالنسبة لنا. هل يمكنك مشاركة عامل البناء الذي يؤلفه أي
صدفة ؟

أحاول أن أفهم كيف يعمل هذا. اليوم لدينا nginx كعكس
الوكيل (كخدمة) وخدمات رصيف متعددة خلفه.

في حالتك - هل يصبح nginx وكيل "الوضع العام"؟ أم أنها أ
معيد TCP خاص. لذلك كلما قمت بتوسيع عدد العقد ، وكيل التوجيه
يذهب في كل عقدة. فكرت بطريقة ما في هذه الحالة في x-forwarded لـ
header يضيع .. لأن شبكة الدخول تقتل IP الخارجي
(نظرًا لعدم وجود بروتوكول وكيل).

سنكون ممتنين للغاية إذا كنت تستطيع مساعدتنا ببعض التفاصيل.

مع تحياتي
سانديب

يوم الأربعاء 8 أغسطس 2018 الساعة 7:18 صباحًا Maxime Lamothe-Brassard <
[email protected]> كتب:

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

إذا كان الحصول على رأس x-forwarded-for كافيًا لك ، فيجب أن يكون هذا الإعداد
عمل AFAICT.

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

sandys بالتأكيد ، إليك مقتطف من عامل

هذا هو إدخال تكوين عامل الإرساء بالوكيل العكسي:

reverseproxy:
    image: yourorg/repo-proxy:latest
    networks:
      - network_with_backend_service
    deploy:
      mode: global
    ports:
      - target: 443
        published: 443
        protocol: tcp
        mode: host

هذا هو إدخال خدمة الواجهة الخلفية:

backendservice:
    image: yourorg/repo-backend:latest
    networks:
      - network_with_backend_service
    deploy:
      replicas: 2

سيكون الهدف من reverseeproxy (الجانب الخلفي) هو tasks.backendservice (الذي يحتوي على سجلات A لكل نسخة متماثلة). يمكنك تخطي الجزء networks إذا كانت خدمة الواجهة الخلفية على شبكة سرب التراكب الافتراضية.

يقول global bit "انشر هذه الحاوية مرة واحدة بالضبط على كل عقدة سرب Docker. المنافذ mode: host هي التي تقول" ربط NIC الأصلي للعقدة ".

آمل أن يساعد.

أنت تستخدم وضع المضيف. إلى حد كبير لديك موازن تحميل خارجي
أمام كل شيء.
لا يمكنك الاعتماد على Swarm بعد الآن لأنك في وضع المضيف.

هذه في الواقع هي المشكلة التي كنا نتحدث عنها منذ فترة :(

في الأربعاء 8 أغسطس 2018 الساعة 20:47 مكسيم لاموث براسارد <
[email protected]> كتب:

sandys https://github.com/sandys بالتأكيد ، هنا مقتطف من موقعنا
عامل ميناء - يؤلف مع الحاويات ذات الصلة.

هذا هو إدخال تكوين عامل الإرساء بالوكيل العكسي:

عكس:
image: yourorg / repo- proxy: latest
الشبكات:
- network_with_backend_service
نشر:
الوضع: عالمي
الموانئ:
- الهدف: 443
تاريخ النشر: 443
البروتوكول: برنامج التعاون الفني
الوضع: المضيف

هذا هو إدخال خدمة الواجهة الخلفية:

الخلفية:
الصورة: yourorg / repo- backend: الأحدث
الشبكات:
- network_with_backend_service
نشر:
النسخ المتماثلة: 2

سيكون الهدف من reverseeproxy (الجانب الخلفي)
Task.backendservice (الذي يحتوي على سجلات A لكل نسخة متماثلة). تستطيع
تخطي جزء الشبكات إذا كانت خدمة الواجهة الخلفية على السرب الافتراضي
شبكة تراكب.

تقول البتة العامة "انشر هذه الحاوية مرة واحدة بالضبط على كل Docker
عقدة سرب. وضع المنافذ: المضيف هو الذي يقول "ربط بالأصل
NIC للعقدة ".

آمل أن يساعد.

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

لست متأكدًا بنسبة 100٪ مما تقصده ، ولكن خارجيًا نستخدم DNS مع سجل A لكل عقدة كتلة. يوفر هذا "توازنًا" رخيصًا دون وجود جزء متحرك خارجي. عندما يقدم العميل طلبًا ، يختار سجل A عشوائيًا ، ويتصل بـ 443 على إحدى عقد المجموعة.

هناك ، يحصل الوكيل العكسي الذي يعمل على تلك العقدة المحددة ويستمع على 443 على اتصال أصلي ، بما في ذلك عنوان IP الفعلي للعميل. ثم تضيف حاوية الوكيل العكسي هذه رأسًا وتعيد توجيه الاتصال إلى حاوية داخلية أخرى باستخدام شبكة تراكب السرب (المهام الخلفية). نظرًا لأنه يستخدم الهدف task.backend ، فإنه سيحصل أيضًا على سجل A عشوائي لخدمة داخلية.

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

ليس بأي حال من الأحوال حلاً مثاليًا ولكن حتى يتم إجراء إصلاح (إن وجد) ، فإنه يمكّنك من المرور بدون مكونات خارجية أو تكوين عامل إرساء رئيسي.

jamiejackson الحل البديل "الأقل سوءًا" الذي اكتشفناه هو استخدام Traefik كخدمة عالمية في وضع المضيف. لديهم مثال عام جيد
https://github.com/containous/traefik/issues/1880

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

مفهوم (والنسخة الفضفاضة من هذا هو ما نستخدمه).

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

في الأربعاء ، 8 أغسطس ، 2018 ، 21:22 ماكسيم لاموث براسارد ، <
[email protected]> كتب:

لست متأكدًا بنسبة 100٪ مما تقصده ، ولكننا خارجيًا نستخدم DNS مع A
سجل لكل عقدة عنقودية. يوفر هذا "توازنًا" رخيصًا دون وجود ملف
جزء متحرك خارجي. عندما يقدم العميل طلبًا ، يختار A عشوائيًا
سجل واتصل بـ 443 على إحدى العقد العنقودية.

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

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

لا يوجد حل مثالي بأي حال من الأحوال ولكن حتى يتم إصلاحه (إن وجد) يحصل
أنت بدون مكونات خارجية أو تكوين عامل إرساء رئيسي.

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

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

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

هل هو جهد مطوَّر مهم؟

في الأربعاء ، 8 أغسطس ، 2018 ، الساعة 21:30 ، كتب مات جلاسر ، [email protected] :

jamiejackson https://github.com/jamiejackson "الأقل سوءًا"
الحل البديل الذي اكتشفناه هو استخدام Traefik كخدمة عالمية في وضع المضيف.
لديهم مثال عام جيد في مستنداتهم
https://docs.traefik.io/user-guide/cluster-docker-consul/#full-docker-compose-file_1 .
لقد رأينا بعض الأخطاء التي قد تكون أو لا تكون مرتبطة بهذا الإعداد ، ولكن
Traefik هو مشروع رائع ويبدو مستقرًا جدًا على Swarm. هناك
موضوع كامل على صفحة مشكلاتهم (التي تعود هنا :)) ، مع
حلول مماثلة:
المحتوي / traefik # 1880
https://github.com/containous/traefik/issues/1880

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

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

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

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

لقد انتقلنا إلى وضع مضيف مثيل الدفق العالمي proxy_protocol nginx ، والذي يقوم بإعادة التوجيه إلى التطبيق المنسوخ proxy_nginx. هذا يعمل بشكل جيد بما فيه الكفاية في الوقت الحالي.

خدمة nginx_stream العالمية

stream {
    resolver_timeout 5s;
    # 127.0.0.11 is docker swarms dns server
    resolver 127.0.0.11 valid=30s;
    # set does not work in stream module, using map here
    map '' $upstream_endpoint {
        default proxy_nginx:443;
    }

    server {
        listen 443;
        proxy_pass $upstream_endpoint;
        proxy_protocol on;
    }
}

خدمة مكررة nginx_proxy

server {
    listen 443 ssl http2 proxy_protocol;
    include /ssl.conf.include;

    ssl_certificate /etc/nginx/certs/main.crt;
    ssl_certificate_key /etc/nginx/certs/main.key;

    server_name example.org;

    auth_basic           "closed site";
    auth_basic_user_file /run/secrets/default.htpasswd;

    # resolver info in nginx.conf
    set $upstream_endpoint app;
    location / {
        # relevant proxy_set_header in nginx.conf
        proxy_pass http://$upstream_endpoint;
    }
}

هل سيكون من الممكن تجاوز تهيئة nginx بالكامل لـ nginx_stream و
nginx_proxy مع تكوينات Swarm الخاصة بهم؟

هذا رائع إذا كان يعمل!

في الثلاثاء ، 11 سبتمبر 2018 ، الساعة 17:14 ، كتب rubot ، [email protected] :

لقد انتقلنا إلى مثيل الدفق العالمي proxy_protocol nginx ، وهو
إعادة التوجيه إلى التطبيق المنسوخ proxy_nginx. هذا يعمل بشكل جيد بما فيه الكفاية
في الوقت الحالي.

خدمة nginx_stream العالمية

مجرى {
حل_ مهلة 5 ثانية ؛
# 127.0.0.11 هو خادم نظام أسماء النطاقات لأسراب الرصيف
محلل 127.0.0.11 صالح = 30 ثانية ؛
# set لا تعمل في وحدة البث ، باستخدام الخريطة هنا
الخريطة '' $ upstream_endpoint {
افتراضي proxy_ nginx: 443 ؛
}

server {
    listen 443;
    proxy_pass $upstream_endpoint;
    proxy_protocol on;
}

}

خدمة مكررة nginx_proxy

الخادم {
استمع 443 ssl http2 proxy_protocol ؛
تشمل /ssl.conf.include ؛

ssl_certificate /etc/nginx/certs/main.crt;
ssl_certificate_key /etc/nginx/certs/main.key;

server_name example.org;

auth_basic           "closed site";
auth_basic_user_file /run/secrets/default.htpasswd;

# resolver info in nginx.conf
set $upstream_endpoint app;
location / {
    # relevant proxy_set_header in nginx.conf
    proxy_pass http://$upstream_endpoint;
}

}

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

sandys لدي حل قائم على haproxy لجزء بروتوكول الوكيل الذي تم تكوينه عبر متغيرات البيئة.

هل سيكون من الممكن تجاوز تهيئة nginx بالكامل لـ nginx_stream و nginx_proxy باستخدام تكوينات Swarm الخاصة بهم؟ هذا رائع إذا كان يعمل!

sandys شيء من هذا القبيل:
https://gist.github.com/rubot/10c79ee0086a8a246eb43ab631f3581f

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

نشر:
الوضع: عالمي
الموانئ:

• الهدف: 443 تاريخ النشر: 443 البروتوكول: وضع برنامج التعاون الفني: المضيف

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

عند قراءة طلب OP ( PanJ ) ، يبدو أن الميزات الحالية تحل هذه المشكلة الآن ، كما تم اقتراحه منذ شهور. لم يطلب OP إدخال التوجيه + العميل IP AFAIK ، لقد طلبوا طريقة للحصول على خدمة سرب في نسخة متماثلة / عالمية للحصول على IP للعميل ، وهو أمر ممكن الآن. هناك مجالان رئيسيان للتحسين يسمحان بحدوث ذلك:

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

بالنسبة لي مع محرك 18.09 ، أحصل على أفضل ما في العالمين في الاختبار. يمكن لخدمة واحدة الاتصال بشبكات تراكب الواجهة الخلفية وأيضًا نشر المنافذ على NIC المضيف ورؤية عنوان IP الحقيقي للعميل الوارد على IP المضيف. أنا أستخدم ذلك مع الوكيل العكسي traefik لتسجيل حركة مرور IP للعميل في traefik المخصص لخدمات الواجهة الخلفية . أشعر أن هذا يمكن أن يحل معظم الطلبات التي رأيتها من أجل "تسجيل IP الحقيقي".

PanJ هل هذا يحلها لك؟

المفتاح هو نشر المنافذ في mode: host بدلاً من mode: ingress (الافتراضي).

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

بالنسبة لي ، فإن طلب "أريد استخدام توجيه IPVS للدخول وكذلك رؤية IP للعميل" هو طلب ميزة مختلف لشبكة libnetwork.

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

تكمن المشكلة بالطبع في أنه يجب عليك قفل هذه الخدمة لخدمة معينة
مضيف حتى لا يتمكن Swarm من جدولته في مكان آخر. وهو ما كانت القضية
تمامًا - هذا البروتوكول الوكيل / IPVS ، إلخ ، يحل هذه المشكلة.

في الجمعة ، 4 يناير ، 2019 ، 09:34 كتب Bret Fisher < [email protected] :

عند قراءة طلب OP ( PanJ https://github.com/PanJ ) ، فإنه
يبدو أن الميزات الحالية تحل هذه المشكلة الآن ، كما تم اقتراحه
الشهور. طلبوا OP لم يطلب إدخال التوجيه + العميل IP AFAIK ، سألوا
للحصول على طريقة للحصول على خدمة سرب في نسخة طبق الأصل / الحصول على عناوين IP للعميل ،
وهو أمر ممكن الآن. هناك مجالان رئيسيان للتحسين يسمحان بحدوث ذلك:

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

بالنسبة لي مع محرك 18.09 ، أحصل على أفضل ما في العالمين في الاختبار. أ
يمكن لخدمة واحدة الاتصال بشبكات تراكب الخلفية ونشرها أيضًا
المنافذ على NIC المضيف وشاهد عنوان IP الحقيقي للعميل الوارد على IP المضيف. انا
باستخدام ذلك مع الوكيل العكسي traefik لتسجيل حركة مرور IP للعميل في traefik
المخصصة للخدمات الخلفية
https://github.com/BretFisher/dogvscat/blob/7e9fe5b998f2cf86951df3f443714beb413d63fb/stack-proxy-global.yml#L75-L83 .
أشعر أن هذا يمكن أن يحل معظم الطلبات التي رأيتها من أجل "تسجيل الحقيقة
IP ".

PanJ https://github.com/PanJ هل هذا يحلها لك؟

المفتاح هو نشر المنافذ في الوضع: مضيف بدلاً من الوضع: دخول (ملف
إفتراضي).

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

بالنسبة لي ، طلب "أريد استخدام توجيه IPVS للدخول ونرى أيضًا
client IP "هو طلب ميزة مختلف لـ libnetwork.

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

BretFisher mode: host هو مجرد حل ولكن ليس الحل. كما قال sandys أن الحل البديل به بعض المحاذير ، يجب ألا نعتبر هذه المشكلة تم إصلاحها.

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

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من وجهة نظري
منظور حتى العبارة التي تنتقل إلى kubernetes ليست كافية
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط. انت ايضا
لديك LB خارجي ، أو استخدم شيئًا مثل nginx ingress proxy الذي يجب أن يكون
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا نفس الشيء
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. يمكن لشخص ما
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه للحصول عليه
شيء مثل سلوك وكيل nginx. فقط اقبل ، يجب أن يكون هذا السرب
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 كانون الثاني (يناير) 2019 ، 09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف ليس سوى ملف
الحل ولكن ليس الحل. مثل sandys https://github.com/sandys
قال أن للمشكلة بعض التنبيهات ، لا ينبغي أن ننظر في هذه المشكلة
كما تم إصلاحه.

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

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

يمكنك حتى تمديد مشروع dockerflow وإضافة متغير nginx للبدء
kubernetes-ingressproxy ل swarn. بالتأكيد كل هذا مليء بالسرب
سترفع حاوية نظام إضافية كما تعلم أن هناك مجموعة من ملفات
لهم مع kubernetes. أليست هي قوة السرب لمورد ضئيل
أن تكون المشاريع العجاف؟

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ، 09:48:

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من وجهة نظري
منظور حتى العبارة التي تنتقل إلى kubernetes ليست كافية
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط. انت ايضا
لديك LB خارجي ، أو استخدم شيئًا مثل nginx ingress proxy الذي يجب أن يكون
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا نفس الشيء
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. يمكن لشخص ما
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه للحصول عليه
شيء مثل سلوك وكيل nginx. فقط اقبل ، يجب أن يكون هذا السرب
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 كانون الثاني (يناير) 2019 ، 09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف ليس سوى ملف
الحل ولكن ليس الحل. مثل sandys https://github.com/sandys
قال أن للمشكلة بعض التنبيهات ، لا ينبغي أن ننظر في هذه المشكلة
كما تم إصلاحه.

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

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

هذه حلول معقدة - بروتوكول الوكيل يضيف فقط رأسًا إضافيًا
معلومات وهي معيار معروف جدًا - haproxy و nginx و AWS elb و
الخ كل متابعة ذلك. https://www.haproxy.com/blog/haproxy/proxy-protocol/

ستقتصر مساحة سطح التغيير على Swarm المدمج فيها
دخول (حيث سيتم إضافة هذا الدعم). وستتوفر في جميع الخدمات
متوفرة.

في الجمعة ، 4 يناير ، 2019 ، 14:36 ​​كتب rubot < [email protected] :

يمكنك حتى تمديد مشروع dockerflow وإضافة متغير nginx للبدء
kubernetes-ingressproxy ل swarn. بالتأكيد كل هذا مليء بالسرب
سترفع حاوية نظام إضافية كما تعلم أن هناك مجموعة من ملفات
لهم مع kubernetes. أليست هي قوة السرب لمورد ضئيل
أن تكون المشاريع العجاف؟

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ، 09:48:

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من وجهة نظري
منظور حتى العبارة التي تنتقل إلى kubernetes ليست كافية
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط. أنت
إما
لديك LB خارجي ، أو استخدم شيئًا مثل nginx ingress proxy الذي يجب أن يكون
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا نفس الشيء
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. يمكن لشخص ما
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه للحصول عليه
شيء مثل سلوك وكيل nginx. فقط اقبل ، يجب أن يكون هذا السرب
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 كانون الثاني (يناير) 2019 ، 09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف ليس سوى ملف
الحل ولكن ليس الحل. مثل sandys https://github.com/sandys
قال أن للمشكلة بعض التنبيهات ، لا ينبغي أن نعتبر ذلك
مشكلة
كما تم إصلاحه.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ، أو
كتم الصوت
الخيط
<
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

.

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

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

Sandeep Srinivasa [email protected] schrieb am Fr. ، 4 يناير 2019 ،
11:37:

هذه حلول معقدة - بروتوكول الوكيل يضيف فقط رأسًا إضافيًا
معلومات وهي معيار معروف جدًا - haproxy و nginx و AWS elb و
الخ كل متابعة ذلك. https://www.haproxy.com/blog/haproxy/proxy-protocol/

ستقتصر مساحة سطح التغيير على Swarm المدمج فيها
دخول (حيث سيتم إضافة هذا الدعم). وستتوفر في جميع الخدمات
متوفرة.

في الجمعة ، 4 يناير ، 2019 ، 14:36 ​​كتب rubot < [email protected] :

يمكنك حتى تمديد مشروع dockerflow وإضافة متغير nginx إلى
بداية
kubernetes-ingressproxy ل swarn. بالتأكيد كل هذا مليء بالسرب
سترفع حاوية نظام إضافية كما تعلم أن هناك مجموعة من ملفات
لهم مع kubernetes. أليست هي قوة السرب لمورد ضئيل
أن تكون المشاريع العجاف؟

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ، 09:48:

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من وجهة نظري
منظور حتى العبارة التي تنتقل إلى kubernetes ليست كافية
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط. أنت
إما
لديك LB خارجي ، أو تستخدم شيئًا مثل nginx ingress proxy الذي
يجب
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا نفس الشيء
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. يمكن لشخص ما
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه للحصول عليه
شيء مثل سلوك وكيل nginx. فقط تقبل ، هذا السرب يحتاج إلى
يكون
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 كانون الثاني (يناير) 2019 ، 09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف ليس سوى ملف
الحل ولكن ليس الحل. كـ sandys <
https://github.com/sandys>
قال أن للمشكلة بعض التنبيهات ، لا ينبغي أن نعتبر ذلك
مشكلة
كما تم إصلاحه.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ،
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
>

.

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

.

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

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

في الجمعة ، 4 يناير ، 2019 ، 17:28 كتب rubot < [email protected] :

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

Sandeep Srinivasa [email protected] schrieb am Fr. ، 4 يناير 2019 ،
11:37:

هذه حلول معقدة - بروتوكول الوكيل يضيف فقط رأسًا إضافيًا
معلومات وهي معيار معروف جدًا - haproxy و nginx و AWS elb و
الخ كل متابعة ذلك. https://www.haproxy.com/blog/haproxy/proxy-protocol/

ستقتصر مساحة سطح التغيير على Swarm المدمج فيها
دخول (حيث سيتم إضافة هذا الدعم). وستكون جميع الخدمات
هو - هي
متوفرة.

في الجمعة ، 4 يناير ، 2019 ، 14:36 ​​كتب rubot < [email protected] :

يمكنك حتى تمديد مشروع dockerflow وإضافة متغير nginx إلى
بداية
kubernetes-ingressproxy ل swarn. بالتأكيد كل هذا مليء
سرب
سترفع حاوية نظام إضافية كما تعلم أن هناك مجموعة
من
لهم مع kubernetes. أليست هي قوة السرب لمورد ضئيل
أن تكون المشاريع العجاف؟

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ، 09:48:

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من وجهة نظري
المنظور حتى العبارة التي تنتقل إلى kubernetes ليست ملف
مناسب
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط. أنت
إما
لديك LB خارجي ، أو تستخدم شيئًا مثل nginx ingress proxy الذي
يجب
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا
نفس
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. شخص ما
استطاع
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه للحصول عليه
شيء مثل سلوك وكيل nginx. فقط تقبل ، هذا السرب يحتاج إلى
يكون
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 كانون الثاني (يناير) 2019 ، 09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف فقط
أ
الحل ولكن ليس الحل. كـ sandys <
https://github.com/sandys>
قال أن للمشكلة بعض التحذيرات ، لا ينبغي أن نأخذ في الاعتبار
هذه
مشكلة
كما تم إصلاحه.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ،
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ، أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK
>

.

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

.

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

كما قلت ، يحتاج kubernetes nginx ingress إلى ربط وضع المضيف أيضًا ، يسمى
الشيطان. يتصل LB الخارجي بـ nodeports ، والذي يتطلب أيضًا وضع المضيف
في الخدمة ، أو تكوين بروتوكول الوكيل يدويًا في الخدمة. كوبرنيتيس
يتعامل مع نفس المشاكل ، لا يزال.
أحد طلبات الميزات الممكنة من وجهة نظري للسرب سيكون
جعل مزود الشبكة قابل للتوصيل. هذا من شأنه أن يجعل من الممكن استخدامها
تقنيات أخرى غير lvs / iptables

Sandeep Srinivasa [email protected] schrieb am Fr. ، 4 يناير 2019 ،
13:05:

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

في الجمعة ، 4 يناير ، 2019 ، 17:28 كتب rubot < [email protected] :

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

Sandeep Srinivasa [email protected] schrieb am الأب ، 4 يناير.
2019،
11:37:

هذه حلول معقدة - بروتوكول الوكيل يضيف فقط المزيد
رأس
المعلومات وهي معيار معروف جدًا - haproxy و nginx و AWS
إلب
الخ كل متابعة ذلك.
https://www.haproxy.com/blog/haproxy/proxy-protocol/

ستقتصر مساحة سطح التغيير على Swarm المدمج فيها
دخول (حيث سيتم إضافة هذا الدعم). وستكون جميع الخدمات
هو - هي
متوفرة.

في الجمعة ، 4 يناير ، 2019 ، 14:36 ​​كتب rubot < [email protected] :

يمكنك حتى تمديد مشروع dockerflow وإضافة متغير nginx إلى
بداية
kubernetes-ingressproxy ل swarn. بالتأكيد كل هذا مليء
سرب
سترفع حاوية نظام إضافية كما تعلم أن هناك مجموعة
من
لهم مع kubernetes. أليست هي قوة السرب للنحيف
الموارد
أن تكون المشاريع العجاف؟

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ،
09:48:

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من عند
لي
المنظور حتى العبارة التي تنتقل إلى kubernetes ليست ملف
مناسب
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط.
أنت
إما
لديك LB خارجي ، أو تستخدم شيئًا مثل nginx ingress proxy
أي
يجب
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا
نفس
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. شخص ما
استطاع
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه إلى
احصل على
شيء مثل سلوك وكيل nginx. فقط تقبل ، هذا السرب يحتاج
إلى
يكون
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 يناير 2019 ،
09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف هو
فقط
أ
الحل ولكن ليس الحل. كـ sandys <
https://github.com/sandys>
قال أن للمشكلة بعض التحذيرات ، لا ينبغي أن نأخذ في الاعتبار
هذه
مشكلة
كما تم إصلاحه.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
< https://github.com/moby/moby/issues/25526#issuecomment -451382365
و
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ،
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

>

.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 ، أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
>

.

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

.

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

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

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ، 13:11:

كما قلت ، يحتاج kubernetes nginx ingress إلى ربط وضع المضيف أيضًا ، يسمى
الشيطان. يتصل LB الخارجي بـ nodeports ، والذي يتطلب أيضًا وضع المضيف
في الخدمة ، أو تكوين بروتوكول الوكيل يدويًا في الخدمة. كوبرنيتيس
يتعامل مع نفس المشاكل ، لا يزال.
أحد طلبات الميزات الممكنة من وجهة نظري للسرب سيكون
جعل مزود الشبكة قابل للتوصيل. هذا من شأنه أن يجعل من الممكن استخدامها
تقنيات أخرى غير lvs / iptables

Sandeep Srinivasa [email protected] schrieb am الأب ، 4 يناير.
2019، 13:05:

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

في الجمعة ، 4 يناير ، 2019 ، 17:28 كتب rubot < [email protected] :

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

Sandeep Srinivasa [email protected] schrieb am الأب ، 4 يناير.
2019،
11:37:

هذه حلول معقدة - بروتوكول الوكيل يضيف فقط المزيد
رأس
المعلومات وهي معيار معروف جدًا - haproxy و nginx و AWS
إلب
الخ كل متابعة ذلك.
https://www.haproxy.com/blog/haproxy/proxy-protocol/

ستقتصر مساحة سطح التغيير على Swarm المدمج فيها
دخول (حيث سيتم إضافة هذا الدعم). وستكون جميع الخدمات
لديك
هو - هي
متوفرة.

في الجمعة ، 4 يناير ، 2019 ، 14:36 ​​كتب rubot < [email protected] :

يمكنك حتى تمديد مشروع dockerflow وإضافة متغير nginx إلى
بداية
kubernetes-ingressproxy ل swarn. بالتأكيد كل هذا مليء
سرب
سيرفع حاوية نظام إضافية كما تعلم أن هناك ملف
حزمة
من
لهم مع kubernetes. أليست هي قوة السرب للنحيف
الموارد
أن تكون المشاريع العجاف؟

Ruben Nicolaides [email protected] schrieb am Fr. ، 4 يناير 2019 ،
09:48:

ما زلت مندهشًا نوعًا ما ، لماذا يعتقد الناس أن هذا خطأ. من عند
لي
المنظور حتى العبارة التي تنتقل إلى kubernetes ليست ملف
مناسب
إجابه. كما أرى ، فإن kubernetes لديه نفس المشكلة / السلوك بالضبط.
أنت
إما
لديك LB خارجي ، أو تستخدم شيئًا مثل nginx ingress proxy
أي
يجب
تشغيل كـ daemonset. الرجاء تصحيح لي إذا كنت مخطئا ، ولكن لدينا
نفس
الوضع الدقيق هنا ، ولكن لا يوجد حل تلقائي مُجهز هنا. شخص ما
استطاع
تحقق من حل تيار tcp المقترح الموضح أعلاه وحزمه إلى
احصل على
شيء مثل سلوك وكيل nginx. فقط اقبل ، هذا السرب
يحتاج الى
يكون
حسب الطلب بنفسك

PanJ [email protected] schrieb am Fr. ، 4 يناير 2019 ،
09:28:

BretFisher https://github.com/BretFisher الوضع: المضيف هو
فقط
أ
الحل ولكن ليس الحل. كـ sandys <
https://github.com/sandys>
قال أن للمشكلة بعض التحذيرات ، لا ينبغي أن نأخذ في الاعتبار
هذه
مشكلة
كما تم إصلاحه.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
<
https://github.com/moby/moby/issues/25526#issuecomment-451382365> ،
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ،
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

>

.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 ،
أو
كتم الصوت
الخيط
<

https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
>

.

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

.

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

1. بعد هذا الخيط الطويل ، كنت أحاول توثيق مجموعة الميزات الحالية بمثال كامل.
2. لا أرى حاجتك المحددة في طلب OP. طلب PanJ رؤية عنوان IP الخاص بالعميل خارج الصندوق ، والذي يمكنك القيام به اعتبارًا من منتصف عام 2018. لا أراهم يطلبون أن يستخدموا أيضًا شبكة توجيه الدخول.

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

يرجى إعلامنا عندما يتم إصلاح هذه المشكلة أم لا ؟!
هل يجب أن نستخدم kuberneties بدلاً من ذلك؟

جريت في نفس المشكلة ... لم أجد حلًا في الوقت الحالي.

عندما يجد شخص ما حلاً لهذا السلوك ، يرجى الإبلاغ عنه هنا.

شكرا!

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

لقد عثرت على هذه المشكلة بنفسي أثناء محاولتي معرفة سبب عدم قيام php: apache بتسجيل حقل رأس المضيف بشكل صحيح. أشعر بصدمة وخيبة أمل لأن هذا لم ينجح بعد بعد كل هذه السنوات. كيف من المفترض أن نستخدم وضع Swarm لاستضافة الويب عندما يستمر حقل المضيف في تسجيل عنوان IP الوكيل الخاص بـ userland؟ لم أتمكن من إيجاد طريقة للتغلب على هذا مع وضع Swarm. أفترض أنه يمكنني استخدام Classic Swarm (على أساس الحاوية) وشيء مثل القنصل ، لكنني أشعر أن هذا يتراجع.

لقد وجدت حلاً مقبولاً للسيناريو الخاص بي:

services:
  server:
    image: httpd:2
    deploy:
      mode: global
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host
    networks:
      - my_second_service
      - another_great_software

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

rafaelsierra - هذه هي المشكلة التي لدي مع هذا ( وربطها بالمنفذ 80 على العقدة المضيفة. أحتاج إلى تشغيل الكثير والكثير من حاويات Apache مع حاوية Nginx مرتبطة بالمنفذ 80/443 ، ثم قم باستضافتها.

SysEngDan نعم ، صحيح أنه يمكنك فقط ربط حاوية واحدة بمنافذ 80/443 ، لكن في حالتي هذه ليست مشكلة لأن الحاوية التي ترتبط بهذا المنفذ هي المسؤولة فقط عن إنشاء وكلاء لجميع الطلبات للحاويات الأخرى التي تعمل خلف شبكة التراكب.

يمكنك على الأرجح استخدام نفس الحل من خلال وجود حاوية nginx / apache واحدة تستقبل جميع الطلبات وتوصيلها إلى الحاوية المناسبة بناءً على مضيف vhost ، ولا يتعين على هذه الحاويات الارتباط بالمضيف

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

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

أدى وجود حاوية واحدة تستمع على المنفذ 80/443 على المضيف ثم إنشاء وكيل للحاويات الأخرى (برؤوس HTTP مناسبة لم أذكرها لأنها خارج نطاق هذه المشكلة) إلى حل مشكلتي ، وأردت مشاركة هذا الحل للأشخاص الذين يواجهون مشكلة مماثلة بسبب عدم تمكن الشبكات المتراكبة من تمرير عنوان IP البعيد

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

في هذه الحالة سوف تحصل على 502.

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

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

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

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

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

docker service create \
--name traefik \
--constraint=node.role==manager \
--publish mode=host,target=80,published=80 \
--publish mode=host,target=443,published=443 \
--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
--mount type=bind,source=/home/$USER/dev-ops/logs,target=/dev-ops/logs \
--mount type=bind,source=/opt/data/traefik/traefik.toml,target=/traefik.toml \
--mount type=bind,source=/opt/data/traefik/acme.json,target=/acme.json \
--network traefik \
--label traefik.frontend.rule=Host:traefik.example.com \
--label traefik.port=8080 \
traefik \
--docker \
--docker.swarmMode \
--docker.watch \
--docker.exposedByDefault

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

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

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

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

يمكنك تشغيل مثيل واحد لكل مضيف

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

يمكنك تشغيل مثيل واحد لكل مضيف

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

يمكن لـ traefik العمل خارج عُقد المدير بعدة طرق ، بما في ذلك استخدام ملف
وكيل مأخذ توصيل عامل ميناء ، مقبس بعيد ، أو شركة traefik. ها هي
مثال ملف مكدس لكيفية القيام بذلك:
https://github.com/BretFisher/dogvscat/blob/master/stack-proxy-global.yml

السبت، 16 مارس 2019 في 17:25 دانييلي Cruciani [email protected]
كتب:

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

يمكنك تشغيل مثيل واحد لكل مضيف

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

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

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

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

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

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

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

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

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

نسيت أن أقول إن تعليقك مرحب به بالطبع (أو قلته بطريقة غامضة ، آسف). لكني أحب تعزيز تقرير PanJ الأصلي:

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

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

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

لكنني آمل بشدة أن يوافق فريق Docker على ذلك الأفضل والأكثر
الحل المتوافق (عبر النظام البيئي) هو وضع طبقة على بروتوكول الوكيل
دعم لشبكة دخول.

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

يوم الأحد 17 مارس 2019 الساعة 12:17 دانييل كروشياني ، [email protected]
كتب:

نسيت أن أقول إن تعليقك مرحب به بالطبع (أو قلته في ملف
طريقة غامضة ، آسف). لكني أحب تعزيزPanJ الأصلي
تقرير https://github.com/PanJ :

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

أعني أن هذا "يكسر الغرض من وضع السرب" ، بالطبع فقط على هذا
موضوع محدد ، يكفي ليستحق المزيد من الاهتمام.

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

https://stackoverflow.com/questions/50585616/kubernetes-metallb-traefik-how-to-get-real-client-ip
كما طلب لـ k8s حيث يتم وضعه على شكل طبقات ، بشكل كامل وقابل للتكوين

لأي شخص يقوم بتشغيل nginx على digitalocean مع سرب عامل الإرساء ويحاول الحصول على $remote_addr الحقيقي بدلاً من 10.255.0.2 ضمن سجلات nginx الخاصة بك ؛ يمكنك استخدام الحل منcoltenkrauter. الصيد هو أنه يمكنك فقط تشغيل الحاويات إنجن إكس واحد على المضيف مع هذا الحل، الذي يجب أن تكون على ما يرام بالنسبة لمعظم الناس.

فقط قم بتغيير ملف docker-compose.yml الخاص بك:

غير صحيح

services:
  nginx:
    ports:
      - "80:80"
      - "443:443"

صيح

services:
  nginx:
    ports:
      - target: 80
        published: 80
        mode: host
      - target: 443
        published: 443
        mode: host

_تعديل: نحن الآن نضمن الحصول على الإجابة الصحيحة_

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

ربما لا يكون ذلك ممكنًا ، لكنني اعتقدت أن تعديل قواعد iptables لتنفيذ MASQUERADE في مرحلة ما في سلاسل INGRESS سيكون حلاً بديلاً لذلك فهو يحافظ على IP المصدر الحقيقي. أليس بعض خبراء iptables / netfilter موجودون؟

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-INGRESS  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         

Chain DOCKER-INGRESS (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

كبديل ، لا يمكن للسرب فقط أخذ عنوان IP الأصلي وإنشاء رأس X-Forwarded-For ؟

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

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

تأكد من قراءة الموضوع بالكامل (أرى أن GitHub تخفي بعض التعليقات المفيدة ، لذلك سيتعين عليك توسيعها: خيبة الأمل :) ؛

كبديل ، لا يمكن للسرب فقط أخذ عنوان IP الأصلي وإنشاء رأس X-Forwarded-For ؟

راجع https://github.com/moby/moby/issues/25526#issuecomment -367642600 ؛ X-Forwarded-For هو بروتوكول L7 ؛ دخول السرب هو L4 ، باستخدام IPVS مع DNAT

@ port22 بشكل عام نوافق على أن الحل ليس حلاً ، الحل هو جعله قابل للطبقة ، راجع sandys اقترح على # 25526 تعليق

كبديل ، لا يمكن السرب فقط أخذ مصدر IP الأصلي وإنشاءه

رأس X-Forwarded-For؟
انظر # 25526 (تعليق)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ؛
X-Forwarded-For هو بروتوكول L7 ؛ دخول السرب هو L4 ، باستخدام IPVS مع DNAT

الحل الصحيح هنا هو بروتوكول الوكيل الذي تم حقنه في L4. هناك بعض
المناقشات المؤيدة والمعارضة ذات الصلة في Envoy لنفس حالة الاستخدام
https://github.com/envoyproxy/envoy/issues/4128 و
https://github.com/envoyproxy/envoy/issues/1031

يوم الأربعاء 10 أبريل 2019 الساعة 1:40 صباحًا Sebastiaan van Stijn <
[email protected]> كتب:

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

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

تأكد من قراءة الموضوع بالكامل (أرى أن GitHub يخفي بعضًا مفيدًا جدًا
التعليقات ، لذلك يجب عليك توسيعها 😞) ؛

كبديل ، لا يمكن السرب فقط أخذ مصدر IP الأصلي وإنشاءه
رأس X-Forwarded-For؟

انظر # 25526 (تعليق)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ؛
X-Forwarded-For هو بروتوكول L7 ؛ دخول السرب هو L4 ، باستخدام IPVS مع DNAT

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

يمكن لكل عقدة في السرب تشغيل مثيل للوكيل العكسي

هذا يلغي ميزة موازن تحميل السرب ، والتي تدور حولها هذه المشكلة في الواقع.
ومشكلتي بالتحديد هي أن traefik ليست رشيقة العنقودية. يجب تشغيله بشكل مستقل إلا إذا كنت تستخدم القنصل كخلفية للتهيئة ، مما يحد من الحد الأقصى للشهادات إلى ~ 100 وهو أمر غير قابل للتطبيق بالنسبة لي. بالتأكيد ، يمكنك القول أن هذه ليست مشكلة سرب ولكن مشكلة traefik. حقيقة ممتعة: يقول ترافيك أن هذه مشكلة قنصلية. القنصل يقول: traefik يخطئ.

@ port22 بشكل عام نوافق على أن الحل ليس حلاً

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

باستخدام IPVS مع DNAT

لذلك كنت أفكر في أنه يمكن القيام بذلك باستخدام MASQUERADE ضمن قاعدة / سلسلة DNAT. ؟

@ port22 حصلت على وجهة نظرك ، لكن عامل
ربما يجب أن تكون هناك خيارات مثل وجود شبكة الجسر https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
لتسهيل الإعداد ، ولكن لا تزال المشكلة الرئيسية هي الدعم المفقود في شبكة التراكب. لذا لا توجد خيارات ، لأنه سيتم تجاهلها ، وسيقوم dockerd بإعادة كتابة القواعد إذا تم تعديلها من الخارج.

لقد قمت بتقديم طلب ميزة للحصول على دعم بروتوكول الوكيل لحل
قضية في هذا الخطأ.

فقط في حالة رغبة أي شخص في إضافة تعليقاتهم.

https://github.com/moby/moby/issues/39465

يوم الأربعاء 10 أبريل 2019 الساعة 21:37 دانييل كروشياني ، [email protected]
كتب:

@ port22 https://github.com/port22 حصلت على وجهة نظرك ، لكن عامل الميناء يديرها
شبكاتها بمفردها ، حاولت أن أجعلها تعمل مع جدار الشاطئ ، لكن
الطريقة الوحيدة هي إنشاء استثناءات لقواعد / سلاسل عامل الإرساء ، ولم يكن لدي
النجاح مع وضع سرب عامل الإرساء (ولكن لا بأس في وضع عامل الإرساء في وضع السرب ، مثل
حتى الآن أقوم بتعطيل جميع الخدمات باستثناء تلك التي تدخل في السرب)
ربما يجب أن تكون هناك خيارات مثل شبكة الجسر
https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
لتسهيل الإعداد ، ولكن لا تزال المشكلة الرئيسية هي
دعم مفقود في شبكة التراكب. حتى الخيارات ليست هناك ، لأن
سيتم تجاهلها ، وسيعيد dockerd كتابة القواعد إذا تم تعديلها من
في الخارج.

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

بعد 3 سنوات ، لا يوجد حل؟

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

فهل من غير الممكن حقًا رؤية عنوان IP المصدر لطلب من خارج Docker Swarm بدلاً من العنوان الخاص لشبكة التراكب الداخلية؟ ما يزال؟

thaJeztah هل يمكن لأحد أعضاء فريق Docker Inc إطلاعنا على حالة هذه المشكلة. هل لا يزال قيد الدراسة و / أو العمل عليه؟ أي ETA؟ أم أن هذا تم تجاهله تمامًا منذ تكامل Docker مع Kubernetes؟ تم الإبلاغ عنه منذ ما يقرب من 3 سنوات: /

thaJeztah https://github.com/thaJeztah هل يمكن لشخص ما على Docker Inc
يقوم فريقنا بإطلاعنا على حالة هذه المشكلة. هل لا يزال قيد النظر
و / أو العمل؟ أي ETA؟ أم أن هذا تم تجاهله تمامًا منذ Docker
التكامل مع Kubernetes؟ تم الإبلاغ عنه منذ ما يقرب من 3 سنوات: /

سيكون من الجيد حقًا الحصول على هذا البيان ("لن يتم إصلاحه") حتى أتمكن من ذلك بشكل كامل
تبرير الهجرة إلى kubernetes. ياله من عار.

شكرا.

>

ربما سيردون على تويتر؟

https://twitter.com/suretec/status/1160496779386904576؟s=19

هناك طلب تحسين مقترح يجب إصلاحه - https://github.com/moby/moby/issues/39465

الرجاء إضافة أفكارك وتعليقاتك هناك

لقد كنت أعلق بالفعل على هذه المسألة :-)

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

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

نحن نواجه نفس المشكلة باستخدام traefik وراء haproxy. كنت متفاجئًا برؤية هذا يحتوي على 254 تعليقًا منذ عام 2016.

Betriebsrat لماذا لا نسمح لـ traefik بمعالجة الطلبات على الفور؟ هل الهبروكسي ضروري حقًا أم مجرد عادة؟ إذا قمت بتعريض traefik في وضع المضيف ، فسترى عناوين IP للعميل ، وبعد ذلك كل شيء على ما يرام :)

أعتقد أن هذا "الحل" قد ورد عدة مرات ، لكن الناس ما زالوا يفتقدونه.

أعلم أيضًا أنه ليس خيارًا في بعض الأحيان ، لكنني أعتقد أن هذا ممكن في معظم الأوقات.

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

يؤدي وضع شيء مثل traefik في وضع المضيف إلى إبطال الفوائد التي نحاول الاستفادة منها من استخدام السرب بالرغم من ذلك في معظم الحالات :(

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

لقد استخدمت هذا الإعداد مع خدمة في الوضع العام ولكنها اقتصرت على عقد المدير ، وكانت تعمل بشكل جيد لعشرات الآلاف من الطلبات / الطلبات

سأكون سعيدًا للتوضيح إذا كانت هناك حاجة لمزيد من التفاصيل.

pattonwebzajardan أنا باستخدام خدمة haproxy شكلي لجميع هذه الحالات. يستخدم haproxy 2 ميغابايت فقط من ذاكرة الوصول العشوائي في حالتي. أعتقد أن هذا لا يكاد يذكر.

pattonwebz بالإضافة إلى حل ajardan أعلاه ، يمكنك تشغيل https://hub.docker.com/r/decentralize/swarm-tcp-proxy في الوضع العام مع الشبكة المضيفة لإضافة دعم بروتوكول PROXY لحركة المرور الواردة ، ثم قم بإعادة توجيهه إلى Traefik المهيأ لفك تشفير رؤوس بروتوكول الوكيل.

يجب أن يكون مجرد علم كجزء من Docker Swarm ، وليس كل هؤلاء
حلول معقدة IMHO.

نحن فقط نستخدم haproxy لإدارة الشهادات وتفريغ SSL.
يفقد الناس أن الحل "التشغيل هو وضع المضيف" ليس حلاً.
إنهم يريدون العمل مع شبكة الدخول للاستفادة من موازنة تحميل عامل الإرساء.
الخيط بأكمله هو في الأساس "استخدام وضع المضيف" -> "غير ممكن لأن دائرة" الأسباب "" التي تستمر لمدة 3 سنوات الآن.

سوف أنظر إلى swarm-tcp-proxy كبديل قابل للتطبيق هنا مرة أخرى ، لكن بالنظر إلى أشياء مماثلة في الماضي ، انتهى الأمر دائمًا إلى أن يكون دورًا للصفقة بالنسبة لي بمثل هذه الأفكار.

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

يفقد الناس أن الحل "التشغيل هو وضع المضيف" ليس حلاً.

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

Betriebsrat traefik يمكنه عمل الشهادات و SSL جيدًا ، لذلك ما زلت غير متأكد من سبب ذلك.

كما ذكر matthanley من قبل ، فإن موازنة تحميل عامل التحميل لا تختفي. إذا لم تعجبك الطريقة التي يوازن بها traefik طلباتك في الواجهة الخلفية ، فيمكنك توجيهها لاستخدام LB الخاص بالسرب ، وسوف ترسل الطلبات فقط إلى خدمة VIP ، حيث سيتولى السرب العناية بها لاحقًا.

هذا قابل للتكوين لكل خدمة حتى ، لذا فأنت مرن تمامًا.

يمكنك محاولة تعيين خادم Nginx آخر خارج مجموعة سرب الرصيف ، وإعادة توجيه الطلب إلى خدمة السرب. في Niginx conf هذا فقط أضف الرؤوس الأمامية. على سبيل المثال
موقعك / {
proxy_pass http: // phpestate؛

    #Proxy Settings
    proxy_redirect     off;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

يبدو أنه لا يوجد حل للحصول على عنوان IP حقيقي للعميل في وضع Docker swarm.

لقد رأينا نفس المشكلة وعملنا على حلها من خلال تنفيذ:
https://github.com/moby/moby/issues/25526#issuecomment -475083415

إنه حل غير مثالي نظرًا لأنه لا يمكننا تشغيل عدة حاويات دخول على عقدة واحدة (أعتقد أنها عالمية الآن)

تكمن الصعوبة في صفقات Docker في TCP / UDP ، بينما هذه مشكلة بروتوكول HTTP. على الأقل ، أتمنى أن يقوم عامل الإرساء "بتزييف" عنوان IP المصدر باعتباره المضيف البعيد مقابل منح عنوان IP الداخلي الخاص به من Swarm Mesh ... ولكن من المحتمل أن يؤدي ذلك إلى كسر الأشياء نظرًا لأن حركة المرور المرتدة ستذهب إلى المكان الخطأ.

أسهل طريقة هي إضافة رأس عنوان IP الأصلي لكل طلب http.

صيح. فقط لكي أكون محددًا - كرأس بروتوكول وكيل يعمل على l4
و l7 ومقبول من قبل معظم برامج التطبيقات المعروفة (بالإضافة إلى
مزودي خدمات السحابة الكبيرة).

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

في الخميس ، 5 سبتمبر ، 2019 ، الساعة 18:56 ، كتب فلاديمير ، [email protected] :

أسهل طريقة هي إضافة عنوان IP الأصلي لكل ملف
طلب HTTP.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/25526؟email_source=notifications&email_token=AAASYU7APUNJPLZ6AJ6XXMDQIECIJA5CNFSM4CL7MWFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAASYU4VZGKUFLL5STZ44GDQIECIJANCNFSM4CL7MWFA
.

في 2019 ومازالت هذه مشكلة ؟؟ إنه يجعل إدراج IP في القائمة البيضاء على traefik أمرًا مزعجًا. لا يجب أن أحتاج إلى منافذ مضيفة على كل عقدة.

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

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

ما هي مشكلتك مع الحل؟ أنت تعلن عن خدمتك في وضع المضيف + الوضع العام وتقوم بإعداد LB الخاص بك لضرب جميع العقد ، فهي تعمل. نظرًا لأن الخادم الوكيل خفيف الوزن (أستخدم nginx لأنني أقوم بإلغاء تحميل https وأشياء أخرى) ، فإن حقيقة أنه يتم نشره على كل خادم لا يمثل مشكلة لأنه يستخدم أقل من 1٪ من مورد الخادم. يمكنني مساعدتك إذا واجهت أي خطأ أثناء العملية ([email protected]).

ما هي مشكلتك مع الحل؟ أنت تعلن عن خدمتك في وضع المضيف + الوضع العام وتقوم بإعداد LB الخاص بك لضرب جميع العقد ، فهي تعمل.

RemiBou عندما يحتاج الوكيل نفسه إلى التحديث / إعادة التشغيل ، لا يكتشف موازن التحميل الخارجي على الفور الانقطاع ويستمر في إرسال الطلبات إلى العقدة (العقدة) حيث لا يزال الوكيل قيد التشغيل. لذلك هناك انقطاع لمدة 30 ثانية تقريبًا اعتمادًا على تكوين LB الخارجي.

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

ما هي مشكلتك مع الحل؟

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

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

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

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

أشار شخص ما إلى https://hub.docker.com/r/decentralize/swarm-tcp-proxy الذي يستخدم haproxy لإنجازه.

نوع من الألم بالرغم من ذلك. وإذا كان عليك تحديث الوكيل ، فلا يزال لديك وقت تعطل.

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

ما هي مشكلتك مع الحل؟

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

واحد آخر هو الأداء غير المهم عندما يكون لديك مئات الاتصالات الجديدة في الثانية - جميع المنافذ المكشوفة هي في الواقع قواعد DNAT في iptables التي تتطلب conntrack ولديها مشاكل أخرى (يضرب k8s أيضًا ، لكن Swarm لديه هذا المستوى الإضافي من NATs الذي يجعل الأمر أسوأ).

إلى Docker ،

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

لجميع مستخدمي Swarm ،

لنكن واقعيين. الحقيقة المحزنة هي أنه لا أحد ، بما في ذلك Docker ، يهتم حقًا بـ Swarm. انتقل الجميع إلى k8s ولا توجد استثمارات "حقيقية" في Swarm. المشروع على أجهزة دعم الحياة في انتظار الموت ، لذا لا تتوقع إصلاح هذه المشكلة. كن ذكيا وانتقل إلى k8s.

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

leojonathanoh هل يمكنك من فضلك توضيح كيف تحل k8s بالضبط هذه المشكلة بالذات :)؟

بسيط: بروتوكول الوكيل

ajatkj كما قال. أو ، إذا لم يكن ذلك ممكنًا ، فسيتم استخدام موازن تحميل خارجي و externalTrafficPolicy: Local على المورد Service . هذا كل ما سأقوله هنا. وأنا ألغي الاشتراك من الموضوع.

لماذا يتوقع الناس أن يقوم الآخرون بالعمل نيابة عنهم؟

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

لقد نظرت أيضًا إلى هذا عدة مرات ولا يبدو حقًا أن هناك طريقة لجعل هذا العمل مع IPVS NAT ، وهو ما يستخدمه توجيه السرب السحري.

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

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

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

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

جرب وضع الشبكة المضيفة

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

تم القيام به هنا بالفعل: # 39465

جرب وضع الشبكة المضيفة

يرجى قراءة الموضوع بأكمله قبل التعليق

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

ربما يكون هذا سؤالًا ساذجًا ، ولكن لماذا من الضروري إعادة كتابة عنوان IP المصدر للبدء به؟ ألن يتم إرجاع حركة المرور عبر البوابة الافتراضية للواجهة على أي حال؟ حتى لو جاء عبر موازن تحميل السرب ، يمكن للبوابة إعادته عبر موازن التحميل الذي يعرف بالفعل من أين أتت حركة المرور ...

ربما يكون هذا سؤالًا ساذجًا ، ولكن لماذا من الضروري إعادة كتابة عنوان IP المصدر للبدء به؟ ألن يتم إرجاع حركة المرور عبر البوابة الافتراضية للواجهة على أي حال؟ حتى لو جاء عبر موازن تحميل السرب ، يمكن للبوابة إعادته عبر موازن التحميل الذي يعرف بالفعل من أين أتت حركة المرور ...

من الضروري معرفة عنوان IP الذي يأتي منه الطلب. ربما يرغب مستخدم معين في تقييد IP ، ولا يمكنك القيام بذلك خارج الخدمة قيد التشغيل ، أي أن traefik لا يعرف محتوى الطلب الذي قد يحدد المستخدم الذي يقوم به ، لذلك لا يمكن استبعاد بعض المستخدمين ويقبل أخرى تعتمد فقط على ip (لأن السياسة في هذا المثال هي ip + request-content => allow / disallow).

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

أظن أنك أسأت فهم سؤالي. أفهم سبب رغبة الخدمات في رؤية مصدر IP الحقيقي. أريد أن أعرف لماذا يغيره Docker قبل أن يصل إلى الحاوية

في 1 تشرين الثاني (نوفمبر) 2019 ، الساعة 1:47 صباحًا ، الساعة 1:47 صباحًا ، كتب دانييل كروشياني [email protected] :

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

من الضروري معرفة عنوان IP الذي يأتي منه الطلب. ربما
مستخدم معين يريد أن يحد من الملكية الفكرية ، ولا يمكنك فعل ذلك خارج نطاق
تشغيل الخدمة ، أي traefik لا تعرف محتوى الطلب
التي قد تحدد المستخدم الذي يقوم بعمله ، لذلك لا يمكن استبعاد البعض
المستخدم ويقبل الآخر على أساس الملكية الفكرية فقط (لأن السياسة في هذا
المثال هو ip + request-content => allow / disallow).

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

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

@ kaysond ليس مكانًا جيدًا

إنك تطرح سؤالين أساسيين ،

1. كيف يعمل IPVS تقنيًا ، و
2. لماذا تختار libnetwork IPVS لتبدأ به

كلاهما يصعب الإجابة عليهما بطرق مختلفة.

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

@ kaysond ليس مكانًا جيدًا

إنك تطرح سؤالين أساسيين ،

1. كيف يعمل IPVS تقنيًا ، و
2. لماذا تختار libnetwork IPVS لتبدأ به

كلاهما يصعب الإجابة عليهما بطرق مختلفة.

أي تحديث؟

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

لقد حاولت هذا مرة أخرى باستخدام:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

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

version: "3.3"

services:

  traefik:
    image: "traefik:v2.0.0-rc3"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=HostRegexp(`{any:.*}`)"
        - "traefik.http.routers.whoami.entrypoints=web"
        - "traefik.http.services.whoami.loadbalancer.server.port=80"

كان إخراج whoami:

Hostname: 085c373eb06d
IP: 127.0.0.1
IP: 10.0.1.10
IP: 172.19.0.4
RemoteAddr: 10.0.1.11:51888
GET / HTTP/1.1
Host: testserver.nub.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.0.0.2
X-Forwarded-Host: testserver.nub.local
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ad14e372f6e9
X-Real-Ip: 10.0.0.2

لذا لا. لا يزال لا يعمل

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

https://github.com/docker/libnetwork

لقد حاولت هذا مرة أخرى باستخدام:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

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

version: "3.3"

services:

  traefik:
    image: "traefik:v2.0.0-rc3"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=HostRegexp(`{any:.*}`)"
        - "traefik.http.routers.whoami.entrypoints=web"
        - "traefik.http.services.whoami.loadbalancer.server.port=80"

كان إخراج whoami:

Hostname: 085c373eb06d
IP: 127.0.0.1
IP: 10.0.1.10
IP: 172.19.0.4
RemoteAddr: 10.0.1.11:51888
GET / HTTP/1.1
Host: testserver.nub.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.0.0.2
X-Forwarded-Host: testserver.nub.local
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ad14e372f6e9
X-Real-Ip: 10.0.0.2

لذا لا. لا يزال لا يعمل

يمكنك استخدام traefik بواسطة وضع المضيف للحصول على IP حقيقي

ports:
      - target: 80
        published: 80
        mode: host
      - target: 443
        published: 443
        mode: host

لا يزال مفتوحا؟
2020-05-08

لا يزال مفتوحا؟
2020-05-08

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

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

لقد نجحنا في استخدام بروتوكول PROXY مع DigitalOcean LB -> Traefik -> Apache container. كانت حاوية Apache قادرة على تسجيل عناوين IP الحقيقية للمستخدمين الذين يصلون إلى الخدمة. يجب أن تعمل نظريًا طالما أن جميع طبقات البروكسي تدعم بروتوكول PROXY.

https://docs.traefik.io/v1.7/configuration/entrypoints/#proxyprotocol

خدمة Traefik موجودة على شبكة Docker واحدة تسمى "ingress" ، ولخدمة Apache شبكة مكدس خاصة بها ولكنها أيضًا جزء من شبكة "ingress" كشبكة خارجية.

https://autoize.com/logging-client-ip-addresses-behind-a-proxy-with-docker/

2020 وما زال غير ثابت ، يا له من عسر. يبدو وكأنه ميزة مهمة للغاية

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

أعتقد أن الحل البديل لذلك وتشغيل سرب عامل ميناء دون ضبط المضيف هو الحصول على IP من جانب العميل. السابق. باستخدام js لعملاء الويب والجوال والقبول فقط من مصادر موثوقة. السابق. js -> get ip ، لا تقبل الواجهة الخلفية سوى ips التي تتضمن رمز مستخدم أو ما إلى ذلك. يمكن تعيين ip في الرأس وتشفيرها من خلال https. ومع ذلك ، لا أعرف عن الأداء

@ Damidara16 هذا بالضبط ما لا نريد القيام به. هو حقا غير آمن للقيام بذلك. يمكنك تجاوزها كما تريد.

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

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

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

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

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

هذه هي أفضل ميزة لفرق الشركات المتضخمة للسيطرة على المجتمع.

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

أنا أستخدم HAIP مُدار ، ولكن يمكنك استخدام شيء آخر أمام السرب ، وهو موازن تحميل nginx مستقل يشير إلى عناوين IP الخاصة بسربك.
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

في سربك ، يحتاج الوكيل العكسي إلى هذا:

server {
        listen 443 ssl proxy_protocol;
        location / {
        proxy_set_header   X-Real-IP $proxy_protocol_addr;  # this is the real IP address 

إذا كنت تقوم بتشغيل سرب ، فستحتاج إلى موازن أحمال لتقريب الطلبات إلى سربك (أو اللزج ، إلخ).

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

أعتقد أنني قد وجدت حلاً لهذه المشكلة ، مع القيد _current_ بأنه يجب نشر جميع النسخ المتماثلة لحاوية الخدمة في عقدة واحدة ، على سبيل المثال مع --constraint-add = 'node.hostname == mynode' ، أو باستخدام مجموعة من الأسراب تتكون كل منها من عقدة واحدة.

المشكلة

سبب المشكلة الأساسية هو قاعدة SNAT في جدول iptables nat في مساحة الاسم ingress_sbox ، مما يتسبب في أن ترى الحاويات عنوان IP الخاص بالعقدة في جميع الطلبات الواردة (على سبيل المثال 10.0.0.2 ، 10.0.0.3 ،. .. ، في التكوين الافتراضي لشبكة الدخول) ، على سبيل المثال:

iptables -t nat -A POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j SNAT --to-source 10.0.0.2

ومع ذلك ، فإن إزالة قاعدة SNAT هذه تعني أنه بينما لا تزال الحاويات تتلقى الحزم الواردة - التي تنشأ الآن من IP المصدر الأصلي - يتم إرسال الحزم الصادرة التي يتم إرسالها مرة أخرى إلى IP المصدر الأصلي عبر البوابة الافتراضية للحاوية ، والتي ليست على نفس شبكة الدخول ولكن على شبكة docker_gwbridge (مثل 172.31.0.1) ، ثم تُفقد هذه الحزم.

الحل

لذا فإن الحل يشتمل على: 1. إزالة (في الواقع ، منع) قاعدة SNAT هذه في مساحة الاسم ingress_sbox ؛ 2. إنشاء قاعدة توجيه سياسة لحاويات خدمة السرب ، والتي تجبر تلك الحزم الصادرة على العودة إلى عنوان IP لشبكة دخول العقدة التي كانت ستعود إليها (على سبيل المثال 10.0.0.2) ؛ 3. أتمتة إضافة قواعد توجيه السياسة ، بحيث يتم تثبيتها فور إنشائها في كل حاوية خدمة جديدة.

1. لمنع قاعدة SNAT ، قمنا بإنشاء قاعدة في الجدول مسبقًا تمنع الوصول إلى SNAT المعتاد:

nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

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

1. لإنشاء قاعدة توجيه سياسة الحاوية:

docker inspect -f '{{.State.Pid}}' <container-id>
nsenter -n -t $NID bash -c "ip route add table 1 default via 10.0.0.2 && ip rule add from 10.0.0.0/24 lookup 1 priority 32761"

1. أخيرًا ، بوضع ما سبق مع docker event نقوم بأتمتة عملية تعديل قواعد SNAT ، ومراقبة الحاويات التي تم تشغيلها حديثًا ، وإضافة قواعد توجيه السياسة ، عبر هذا البرنامج النصي ingress-routing-daemon :

#!/bin/bash

# Ingress Routing Daemon
# Copyright © 2020 Struan Bartlett
# --------------------------------------------------------------------
# Permission is hereby granted, free of charge, to any person 
# obtaining a copy of this software and associated documentation files 
# (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, 
# publish, distribute, sublicense, and/or sell copies of the Software, 
# and to permit persons to whom the Software is furnished to do so, 
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be 
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
# SOFTWARE.
# --------------------------------------------------------------------
# Workaround for https://github.com/moby/moby/issues/25526

echo "Ingress Routing Daemon starting ..."

read INGRESS_SUBNET INGRESS_DEFAULT_GATEWAY \
  < <(docker inspect ingress --format '{{(index .IPAM.Config 0).Subnet}} {{index (split (index .Containers "ingress-sbox").IPv4Address "/") 0}}')

echo INGRESS_SUBNET=$INGRESS_SUBNET
echo INGRESS_DEFAULT_GATEWAY=$INGRESS_DEFAULT_GATEWAY

# Add a rule ahead of the ingress network SNAT rule, that will cause the SNAT rule to be skipped.
echo "Adding ingress_sbox iptables nat rule: iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -D POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j ACCEPT; do true; done 2>/dev/null
nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

# Watch for container start events, and configure policy routing rules on each container
# to ensure return path traffic from incoming connections is routed back via the correct interface.
docker events \
  --format '{{.ID}} {{index .Actor.Attributes "com.docker.swarm.service.name"}}' \
  --filter 'event=start' \
  --filter 'type=container' | \
  while read ID SERVICE
  do
    if [ -n "$SERVICE" ]; then

      NID=$(docker inspect -f '{{.State.Pid}}' $ID)
      echo "Container ID=$ID, NID=$NID, SERVICE=$SERVICE started: applying policy route."
      nsenter -n -t $NID bash -c "ip route add table 1 default via $INGRESS_DEFAULT_GATEWAY && ip rule add from $INGRESS_SUBNET lookup 1 priority 32761"
    fi
  done

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

إستعمال

قم بتشغيل ما ورد أعلاه ingress-routing-daemon كجذر على كل _ كل واحد_ من العقد _ قبل إنشاء خدمتك. (إذا تم إنشاء خدمتك بالفعل ، فتأكد من تغيير حجمها إلى 0 قبل إعادة تحجيمها إلى عدد موجب من النسخ المتماثلة.) سيهيئ البرنامج الخفي iptables ويكتشف متى ينشئ عامل الإرساء حاويات جديدة ويطبق قواعد توجيه جديدة على كل حاوية جديدة.

الاختبار وحالات الاستخدام والقيود

تم اختبار ما سبق باستخدام نسخ متماثلة متعددة مقيدة بعقدة واحدة على خدمة تعمل على سرب متعدد العقد.

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

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

تحسين الحل لمعالجة حالات الاستخدام الأخرى

مع مزيد من التطوير ، يجب أن تكون هذه الطريقة قادرة على التوسع إلى عقد متعددة دون الحاجة إلى خدمات منفصلة لكل عقدة أو تقسيم السرب. يمكنني التفكير في طريقتين محتملتين: 1. الترتيب لـ Docker ، أو برنامج خفي مفصل ، لإزالة جميع عناوين IP غير المحلية من جدول ipvsadm الخاص بكل عقدة. 2. توسيع قواعد توجيه السياسة لاستيعاب حزم إخراج التوجيه إلى العقدة الصحيحة.

بالنسبة إلى 1 ، يمكننا استقصاء ipvsadm -S -n للبحث عن عناوين IP الجديدة المضافة إلى أي خدمة ، والتحقق مما إذا كانت كل منها محلية ، وإزالة أي منها ليس كذلك. سيسمح هذا لكل عقدة بالعمل كموازن تحميل للحاويات الخاصة بها داخل الخدمة الإجمالية ، ولكن بدون وصول الطلبات إلى عقدة واحدة يمكن إعادة توجيهها إلى عقدة أخرى. من المؤكد أن هذا من شأنه أن يرضي حالة الاستخدام الخاصة بي ، حيث لدينا موازن تحميل IPVS الخاص بنا الموجود أمام مجموعة من الخوادم ، كل منها يقوم بتشغيل تطبيق ويب ، والذي نرغب في استبداله بالعديد من مثيلات حاوية متوازنة التحميل لنفس التطبيق ، للسماح لنا بطرح التحديثات دون فقدان خادم كامل.

بالنسبة إلى 2 ، يمكننا استخدام iptables لتعيين TOS لكل عقدة في ingress_sbox iptable لكل عقدة (على سبيل المثال للبايت النهائي لعقد دخول شبكة IP) ؛ ثم في الحاوية ، قم بالترتيب لتعيين قيمة TOS إلى علامة الاتصال ، ثم من علامة الاتصال إلى علامة جدار الحماية للحزم الصادرة ، ولكل علامة جدار حماية ، حدد جدول توجيه مختلفًا يوجه الحزم إلى العقدة الأصلية. ستكون القواعد الخاصة بهذا الأمر صعبة بعض الشيء ، لكني أتخيل أنه يجب أن يتسع نطاقها إلى 2-16 عقدة.

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

يوجد أدناه نسخة محسّنة من برنامج Ingress التوجيه الخفي ، ingress-routing-daemon-v2 ، والذي يوسع نموذج قاعدة توجيه السياسة للسماح لكل حاوية بتوجيه حزم الإخراج الخاصة بها إلى العقدة الصحيحة ، دون الحاجة إلى SNAT.

النموذج المحسن

بالإضافة إلى منع قاعدة SNAT وفقًا للنموذج السابق ، يتطلب النموذج الجديد قاعدة iptables في مساحة الاسم ingress_sbox على كل عقدة تنوي استخدامها كنقطة نهاية موازن تحميل IPVS (عادةً ما تكون عُقد المدير أو مجموعة فرعية منها مدير العقد) ، التي تعين قيمة TOS لكل عقدة لجميع الحزم الموجهة لأي عقدة في شبكة الدخول. (نستخدم البايت النهائي لعنوان IP لشبكة دخول العقدة).

نظرًا لأنه يتم تخزين قيمة TOS داخل الحزمة ، يمكن قراءتها بواسطة العقدة الوجهة التي تم توجيه الطلب الوارد إليها ، وتم إرسال الحزمة.

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

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

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

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

إستعمال

اعداد

قم بإنشاء قيمة INGRESS_NODE_GATEWAY_IPS خاصة بالسرب الخاص بك ، عن طريق تشغيل ingress-routing-daemon-v2 كجذر على كل عقد من عُقد سربك _ التي ترغب في استخدامها كنقطة نهاية موازن التحميل_ (عادةً فقط مديرك العقد ، أو مجموعة فرعية من عُقد المدير) ، مع ملاحظة القيم المعروضة لـ INGRESS_DEFAULT_GATEWAY . ما عليك سوى القيام بذلك مرة واحدة ، أو كلما قمت بإضافة أو إزالة العقد. يجب أن يبدو INGRESS_NODE_GATEWAY_IPS مثل 10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5 (وفقًا للشبكة الفرعية المحددة لشبكة الإدخال وعدد العقد).

تشغيل البرنامج الخفي

قم بتشغيل INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 --install كجذر على كل _ كل واحد_ من عقد _ إنشاء خدمتك. (إذا تم إنشاء خدمتك بالفعل ، فتأكد من تغيير حجمها إلى 0 قبل إعادة تحجيمها إلى عدد موجب من النسخ المتماثلة.) سيهيئ البرنامج الخفي iptables ويكتشف متى ينشئ عامل الإرساء حاويات جديدة ويطبق قواعد توجيه جديدة على كل حاوية جديدة.

إذا كنت بحاجة إلى تقييد أنشطة البرنامج الخفي لخدمة معينة ، فقم بتعديل [ -n "$SERVICE" ] إلى [ "$SERVICE" = "myservice" ] .

إلغاء تثبيت قواعد iptables

قم بتشغيل ingress-routing-daemon-v2 --uninstall على كل عقدة.

اختبارات

تم اختبار البرنامج النصي ingress-routing-daemon-v2 مع 8 نسخ طبق الأصل من خدمة ويب تم نشرها على سرب من أربع عقد.

طلبات Curl للخدمة ، الموجهة إلى أي من عناوين IP لعقدة نقطة نهاية متوازنة التحميل المحددة ، وأرجعت استجابات ناجحة ، وأظهر فحص سجلات الحاوية أن التطبيق رأى الطلبات الواردة على أنها صادرة من عنوان IP الخاص بعميل Curl.

محددات

نظرًا لأن قيمة TOS يمكنها تخزين رقم 8 بت ، يمكن لهذا النموذج من حيث المبدأ دعم ما يصل إلى 256 نقطة نهاية لنقطة نهاية موازن التحميل.

ومع ذلك ، نظرًا لأن النموذج يتطلب تثبيت كل حاوية بقاعدة iptables mangle واحدة + قاعدة توجيه سياسة واحدة + جدول توجيه سياسة واحد لكل عقدة نقطة نهاية للمدير ، فقد يكون هناك بعض التدهور في الأداء مع زيادة عدد عقد نقطة النهاية هذه (على الرغم من أن التجربة تشير إلى أن هذا هو من غير المحتمل أن تكون ملحوظة مع <= 16 عقدة نقطة نهاية موازن التحميل على الأجهزة الحديثة).

إذا أضفت عُقد نقاط نهاية موازن التحميل إلى سربك - أو أردت البدء في استخدام عقد المدير الحالية كنقاط نهاية موازن التحميل - فستحتاج إلى السير بحذر لأن الحاويات الحالية لن تكون قادرة على توجيه حركة المرور إلى نقاط النهاية الجديدة. حاول إعادة تشغيل INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 بالقيمة المحدّثة لـ INGRESS_NODE_GATEWAY_IPS ، ثم قم بإجراء تحديث متجدد لجميع الحاويات ، قبل استخدام نقطة نهاية موازن التحميل الجديدة.

نطاق لتكامل Docker الأصلي

لست على دراية بقاعدة بيانات Docker ، لكن لا يمكنني رؤية أي شيء يفعله ingress-routing-daemon-v2 ولا يمكن ، من حيث المبدأ ، تنفيذه بواسطة Docker محليًا ، لكنني سأترك ذلك لفريق Docker النظر ، أو كتمرين لشخص على دراية برمز Docker.

البرنامج النصي الخفي لتوجيه الإدخال v2

هذا هو البرنامج النصي الجديد ingress-routing-daemon-v2 .

#!/bin/bash

# Ingress Routing Daemon v2
# Copyright © 2020 Struan Bartlett
# ----------------------------------------------------------------------
# Permission is hereby granted, free of charge, to any person 
# obtaining a copy of this software and associated documentation files 
# (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, 
# publish, distribute, sublicense, and/or sell copies of the Software, 
# and to permit persons to whom the Software is furnished to do so, 
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be 
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
# SOFTWARE.
# ----------------------------------------------------------------------
# Workaround for https://github.com/moby/moby/issues/25526

if [ "$1" = "--install" ]; then
  INSTALL=1
elif [ "$1" = "--uninstall" ]; then
  INSTALL=0
else
  echo "Usage: $0 [--install|--uninstall]"
fi

echo
echo "  Dumping key variables..."

if [ "$INSTALL" = "1" ] && [ -z "$INGRESS_NODE_GATEWAY_IPS" ]; then
  echo "!!! ----------------------------------------------------------------------"
  echo "!!! WARNING: Using default INGRESS_NODE_GATEWAY_IPS"
  echo "!!! Please generate a list by noting the values shown"
  echo "!!! for INGRESS_DEFAULT_GATEWAY on each of your swarm nodes."
  echo "!!!"
  echo "!!! You only have to do this once, or whenever you add or remove nodes."
  echo "!!!"
  echo "!!! Then relaunch using:"
  echo "!!! INGRESS_NODE_GATEWAY_IPS=\"<Node Ingress IP List>\" $0 -x"
  echo "!!! ----------------------------------------------------------------------"
fi

read INGRESS_SUBNET INGRESS_DEFAULT_GATEWAY \
  < <(docker inspect ingress --format '{{(index .IPAM.Config 0).Subnet}} {{index (split (index .Containers "ingress-sbox").IPv4Address "/") 0}}')

echo "  - INGRESS_SUBNET=$INGRESS_SUBNET"
echo "  - INGRESS_DEFAULT_GATEWAY=$INGRESS_DEFAULT_GATEWAY"

# We need the final bytes of the IP addresses on the ingress network of every node
# i.e. We need the final byte of $INGRESS_DEFAULT_GATEWAY for every node in the swarm
# This shouldn't change except when nodes are added or removed from the swarm, so should be reasonably stable.
# You should configure this yourself, but for now let's assume we have 8 nodes with IPs in the INGRESS_SUBNET numbered x.x.x.2 ... x.x.x.9
if [ -z "$INGRESS_NODE_GATEWAY_IPS" ]; then
  INGRESS_NET=$(echo $INGRESS_DEFAULT_GATEWAY | cut -d'.' -f1,2,3)
  INGRESS_NODE_GATEWAY_IPS="$INGRESS_NET.2 $INGRESS_NET.3 $INGRESS_NET.4 $INGRESS_NET.5 $INGRESS_NET.6 $INGRESS_NET.7 $INGRESS_NET.8 $INGRESS_NET.9"
fi

echo "  - INGRESS_NODE_GATEWAY_IPS=\"$INGRESS_NODE_GATEWAY_IPS\""

# Create node ID from INGRESS_DEFAULT_GATEWAY final byte
NODE_ID=$(echo $INGRESS_DEFAULT_GATEWAY | cut -d'.' -f4)
echo "  - NODE_ID=$NODE_ID"

if [ -z "$INSTALL" ]; then
  echo
  echo "Ingress Routing Daemon v2 exiting."
  exit 0
fi

# Add a rule ahead of the ingress network SNAT rule, that will cause the SNAT rule to be skipped.
[ "$INSTALL" = "1" ] && echo "Adding ingress_sbox iptables nat rule: iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -D POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j ACCEPT; do true; done 2>/dev/null
[ "$INSTALL" = "1" ] && nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

# 1. Set TOS to NODE_ID in all outgoing packets to INGRESS_SUBNET
[ "$INSTALL" = "1" ] && echo "Adding ingress_sbox iptables mangle rule: iptables -t mangle -A POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t mangle -D POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff; do true; done 2>/dev/null
[ "$INSTALL" = "1" ] && nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t mangle -A POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff

if [ "$INSTALL" = "0" ]; then
  echo
  echo "Ingress Routing Daemon v2 iptables rules uninstalled, exiting."
  exit 0
fi

echo "Ingress Routing Daemon v2 starting ..."

# Watch for container start events, and configure policy routing rules on each container
# to ensure return path traffic for incoming connections is routed back via the correct interface
# and to the correct node from which the incoming connection was received.
docker events \
  --format '{{.ID}} {{index .Actor.Attributes "com.docker.swarm.service.name"}}' \
  --filter 'event=start' \
  --filter 'type=container' | \
  while read ID SERVICE
  do
    if [ -n "$SERVICE" ]; then

      NID=$(docker inspect -f '{{.State.Pid}}' $ID)
      echo "Container ID=$ID, NID=$NID, SERVICE=$SERVICE started: applying policy routes."

      # 3. Map any connection mark on outgoing traffic to a firewall mark on the individual packets.
      nsenter -n -t $NID iptables -t mangle -A OUTPUT -p tcp -j CONNMARK --restore-mark

      for NODE_IP in $INGRESS_NODE_GATEWAY_IPS
      do
        NODE_ID=$(echo $NODE_IP | cut -d'.' -f4)

    # 2. Map the TOS value on any incoming packets to a connection mark, using the same value.
        nsenter -n -t $NID iptables -t mangle -A PREROUTING -m tos --tos $NODE_ID/0xff -j CONNMARK --set-xmark $NODE_ID/0xffffffff

    # 4. Select the correct routing table to use, according to the firewall mark on the outgoing packet.
        nsenter -n -t $NID ip rule add from $INGRESS_SUBNET fwmark $NODE_ID lookup $NODE_ID prio 32700

    # 5. Route outgoing traffic to the correct node's ingress network IP, according to its firewall mark
    #    (which in turn came from its connection mark, its TOS value, and ultimately its IP).
        nsenter -n -t $NID ip route add table $NODE_ID default via $NODE_IP dev eth0

      done

    fi
  done

مرحبًا struanb ، لا أفهم كيف يعمل قسم إلغاء التثبيت في البرنامج النصي v2 الخاص بك ، هل هناك شيء مفقود؟

مرحباjrbecart. لا اتمنى. قبل تثبيت قواعد iptables ، سترى وجود حلقتين أثناء حذف أي قواعد موجودة مسبقًا ، باستخدام iptables -D . هذا إجراء أمان ، في حالة تشغيل البرنامج النصي بـ --install عدة مرات متتالية ، دون أي مكالمة متداخلة مع --uninstall .

على هذا النحو ، عندما يتم استدعاء البرنامج النصي مع --uninstall ، بحلول الوقت الذي يخرج فيه البرنامج النصي ، ستتم إزالة هذه القواعد ، ولم تتم إضافة القواعد الجديدة بعد.

أتمنى أن هذا يجيب على سؤالك.

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

هنا مثال على هذا النوع من السجل

10.0.0.2 - - [19/Nov/2020:04:56:31 +0000] "GET / HTTP/1.1" 200 58 "-" req_t=0.003 upstream_t=0.004 "<browser-info>" "<source-ip-1,source-ip2,....>"

ملاحظة: هناك عدة عناوين IP للمصدر إذا كنت تستخدم بروكسيات (مثل Cloudfare وغيرها).

كانت المعلومات موجودة ، وكان عنوان IP الحقيقي الخاص بي هناك. بعد ذلك ، قمت بمراجعة تنسيق NGINX للتسجيل لمعرفة كيف كان السحر ممكنًا ، ووجدت هذا:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      'req_t=$request_time upstream_t=$upstream_response_time '
                      '"$http_user_agent" "$http_x_forwarded_for"';

هذا يعني أن السحر موجود هنا -> $http_x_forwarded_for

بعد ذلك ، قمت بتغيير رؤوس البروكسي مثل proxy_set_header X-Real-IP $http_x_forwarded_for; .

وأخيرًا ، الاختبار الأخير ، باستخدام تلك المعلومات في مشروع NodeJS ، داخل نظام مثل الإنتاج ، باستخدام Docker Swarm مع شبكة تراكب ، مع حوالي 4 أجهزة افتراضية ، وخمن ما نجح! يمكنني أخيرًا الحصول على عنوان IP الحقيقي.

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

Docker version: 19.03.8
NGINX version: nginx/1.14.2

سأنتظر ردود الفعل الخاصة بك. أتمنى أن تحصل على نفس النتائج مثلي.

هتافات!
سيباستيان.

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

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

sebastianfelipe هذه مطالبة كبيرة بعد كل هذه السنوات. هل أنت متأكد من أنك لا تستخدم وضع المضيف أو الحلول البديلة الأخرى في هذا الموضوع؟

sebastianfelipe هذه مطالبة كبيرة بعد كل هذه السنوات. هل أنت متأكد من أنك لا تستخدم وضع المضيف أو الحلول البديلة الأخرى في هذا الموضوع؟

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

sebastianfelipe أعتقد أن موازن تحميل Digital Ocean يقوم بإلحاق عنوان IP الخاص بالمستخدم برأس X-Forwarded-For. هذا حل بديل معروف لا يحل مشكلة استرداد عنوان IP الخاص بالمستخدم في وضع Docker Swarm المستقل.

beornf كنت أحاول النوم ثم قرأت $http_x_forwarded_for . يضيف موازن تحميل المحيط الرقمي معلومات إلى متغير NGINX آخر ، معلومات لم تتم إضافتها بواسطة Docker Swarm مباشرة. من المحتمل أن يؤدي هذا إلى نهج "شبيه بالدمية" للحصول على حل حقيقي لكل حالة. يمكن لعملاء Digital Ocean على الأقل أن يسعدوا بمعرفة كيفية التعامل مع هذا في هذه اللحظة.

beornfsebastianfelipe إضافة إلى السياق، يضيف أيضا كلودفلاري X-Forwarded-For و مجانية إلى حد كبير.

beornfsebastianfelipe إضافة إلى السياق، يضيف أيضا كلودفلاري X-Forwarded-For و مجانية إلى حد كبير.

أعتقد أن هذا يمكن أن يعمل مع الكثير منا الذين يحتاجون إلى مخرج للحصول على IP الحقيقي. يمكن تعديل Cloudfare كوكيل أو DNS فقط. إنه مناسب تمامًا لعدم وجود عملاء للمحيط الرقمي. إنه الحل الأنظف حتى الآن. لكنني أتفق مع beornf ، نحن بحاجة إلى حل حقيقي ، دون الاعتماد على Digital Ocean أو Cloudfare لإنجاز ذلك.

شكرا!