/ cc @aluzzardi @mrjana ने पूछा

@PanJ क्या आप कृपया कुछ विवरण साझा कर सकते हैं कि कैसे डिबगिंग-सरल-सर्वर ip निर्धारित करता है? इसके अलावा, यदि एक सेवा को कई मेजबानों (या वैश्विक मोड) में 1 से अधिक प्रतिकृति तक बढ़ाया जाता है, तो क्या उम्मीद है?

@mavenugo यह koa की अनुरोध वस्तु है जो net मॉड्यूल से नोड के remoteAddress का उपयोग करती है। परिणाम किसी भी अन्य पुस्तकालयों के लिए समान होना चाहिए जो दूरस्थ पते को पुनः प्राप्त कर सकते हैं।

उम्मीद यह है कि 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 होस्ट का आईपी है जिसमें मैं कर्ल चला रहा हूं। क्या यह अपेक्षित व्यवहार है?

@sanimej हां, यह अपेक्षित व्यवहार है जो झुंड मोड पर भी होना चाहिए।

@marech मैं अभी भी स्टैंडअलोन कंटेनर का उपयोग वर्कअराउंड के रूप में कर रहा हूं, जो ठीक काम करता है।

मेरे मामले में, 2 nginx इंटेंस, स्टैंडअलोन और झुंड उदाहरण हैं। SSL टर्मिनेशन और रिवर्स प्रॉक्सी स्टैंडअलोन nginx पर किया जाता है। झुंड उदाहरण का उपयोग अनुरोध होस्ट के आधार पर अन्य सेवाओं को रूट करने के लिए किया जाता है।

@PanJ एक कंटेनर के प्रकाशित पोर्ट को एक्सेस करने का तरीका झुंड मोड में अलग है। झुंड मोड में क्लस्टर में किसी भी नोड से सेवा तक पहुंचा जा सकता है। इसे सुविधाजनक बनाने के लिए हम ingress नेटवर्क के माध्यम से रूट करते हैं। 10.255.0.x क्लस्टर में होस्ट पर ingress नेटवर्क इंटरफ़ेस का पता है जिससे आप प्रकाशित पोर्ट तक पहुंचने का प्रयास करते हैं।

@sanimej मैंने देखा कि जब मैंने इस मुद्दे को खोला तो यह कैसे काम करता है। लेकिन उपयोग के मामले (उपयोगकर्ता के आईपी को पुनः प्राप्त करने की क्षमता) काफी सामान्य है।

मुझे इस बारे में सीमित ज्ञान है कि फिक्स को कैसे लागू किया जाना चाहिए। शायद एक विशेष प्रकार का नेटवर्क जो स्रोत आईपी पते को नहीं बदलता है?

Rancher डॉकर झुंड मोड के समान है और ऐसा लगता है कि व्यवहार अपेक्षित है। शायद यह शुरू करने के लिए एक अच्छी जगह है।

@sanimej अच्छा विचार सभी आईपी को एक्स-

@PanJ हम्म, और आपका निग्नेक्स स्टैंडअलोन कंटेनर सेवा नाम या आईपी के माध्यम से झुंड के उदाहरण से कैसे संवाद करता है? हो सकता है कि आप nginx config भाग साझा कर सकें जहां आप इसे झुंड उदाहरण में पास करते हैं।

@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;
  }
}

यदि आपको एसएसएल टर्मिनेशन करना है, तो एक और सर्वर ब्लॉक जोड़ें जो पोर्ट 443 को सुनता है, फिर एसएसएल टर्मिनेशन और प्रॉक्सी को localhost:8181 पर भी करें

झुंड मोड का nginx 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;
  }
}

हमारे मामले में, हमारी एपीआई दर सीमा और अन्य कार्य उपयोगकर्ता के आईपी पते पर निर्भर हैं। क्या झुंड मोड में समस्या को छोड़ने का कोई तरीका है?

झुंड मोड में लॉगस्टैश चलाने की कोशिश करते समय भी मैंने इस मुद्दे में भाग लिया है (विभिन्न मेजबानों से syslog संदेश एकत्र करने के लिए)। लॉगस्टैश "होस्ट" फ़ील्ड हमेशा कनेक्टिंग होस्ट के वास्तविक आईपी के बजाय 10.255.0.x के रूप में प्रकट होता है। यह इसे पूरी तरह से अनुपयोगी बनाता है, क्योंकि आप यह नहीं बता सकते कि लॉग संदेश किस होस्ट से आ रहे हैं। क्या कोई तरीका है जिससे हम स्रोत आईपी का अनुवाद करने से बच सकते हैं?

+1 इस समस्या के समाधान के लिए।

उपयोगकर्ता के आईपी को पुनः प्राप्त करने की क्षमता के बिना हमें प्रोमेथियस जैसे निगरानी समाधानों का उपयोग करने से रोकता है।

शायद लिनक्स कर्नेल आईपीवीएस क्षमताएं यहां कुछ काम की होंगी। मैं अनुमान लगा रहा हूं कि आईपी परिवर्तन हो रहा है क्योंकि उपयोगकर्ता स्थान में कनेक्शन प्रॉक्सी किए जा रहे हैं। दूसरी ओर, आईपीवीएस स्रोत आईपी पते को बदले बिना कर्नेल स्पेस में शेष राशि के अनुरोधों को पुनर्निर्देशित और लोड कर सकता है। आईपीवीएस अधिक उन्नत कार्यक्षमता में निर्माण के लिए सड़क के नीचे भी अच्छा हो सकता है, जैसे विभिन्न लोड बैलेंसिंग एल्गोरिदम, फ्लोटिंग आईपी एड्रेस और डायरेक्ट रूटिंग।

मेरे लिए, यह पर्याप्त होगा यदि मैं किसी तरह वर्चुअल आईपी और सर्वर के आईपी के बीच संबंध का पता लगा सकता हूं जो समापन बिंदु से संबंधित है। इस तरह, जब प्रोमेथियस कुछ वर्चुअल आईपी से संबंधित अलर्ट भेजता है, तो मैं पता लगा सकता हूं कि प्रभावित सर्वर क्या है। यह एक अच्छा समाधान नहीं होगा लेकिन यह कुछ भी नहीं से बेहतर होगा।

@vfarcic मुझे नहीं लगता कि यह अब जिस तरह से काम करता है उससे संभव है। सभी क्लाइंट कनेक्शन एक ही आईपी से आते हैं, इसलिए आप इसका वापस अनुवाद नहीं कर सकते। काम करने का एकमात्र तरीका यह है कि यदि कनेक्शन के प्रॉक्सी/नेट जो कुछ भी कर रहा है वह टाइमस्टैम्प, स्रोत आईपी और स्रोत पोर्ट के साथ कनेक्शन लॉग सहेजता है। फिर भी, अधिकांश उपयोग के मामलों में जहां स्रोत आईपी की आवश्यकता होती है, यह बहुत मददगार नहीं होगा।

मैंने शायद उपयोग के मामले को अच्छी तरह से नहीं समझाया।

मैं प्रोमेथियस का उपयोग करता हूं जो कि स्वार्म वैश्विक सेवाओं के रूप में चल रहे निर्यातकों को स्क्रैप करने के लिए कॉन्फ़िगर किया गया है। यह कार्यों का उपयोग करता है।सभी प्रतिकृतियों के आईपी प्राप्त करने के लिए। तो, यह सेवा का उपयोग नहीं कर रहा है लेकिन प्रतिकृति एंडपॉइंट्स (कोई लोड संतुलन नहीं)। मुझे जो चाहिए वह किसी भी तरह नोड के आईपी को समझना है जहां से प्रत्येक प्रतिकृति आईपी आते हैं।

मुझे बस "डॉकर नेटवर्क निरीक्षण" का एहसास हुआ"एक नोड के कंटेनर और 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 से सहमत आईपीवीएस का उपयोग कर रहा है, हमें

समाधान को आईपी स्तर पर काम करने की आवश्यकता है ताकि कोई भी सेवा जो HTTP पर आधारित नहीं है, वह अभी भी ठीक से काम कर सके (http शीर्षलेखों पर भरोसा नहीं कर सकता ...)

और मैं इस पर जोर नहीं दे सकता कि यह कितना महत्वपूर्ण है, इसके बिना, ऐसी कई सेवाएं हैं जो झुंड मोड में बिल्कुल भी काम नहीं कर सकती हैं।

इस प्रकार HaProxy इस समस्या का समाधान कर रहा है: http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-despite-reverse-proxies/

डॉकरकॉन में आईपीवीएस पर अपनी बात को देखते हुए @kobolog इस मामले पर कुछ प्रकाश डालने में सक्षम हो सकता है।

बस खुद को सूची में जोड़ रहा हूँ। मैं syslog संदेशों को स्वीकार करने के लिए लॉगस्टैश का उपयोग कर रहा हूं, और वे सभी होस्ट आईपी के साथ इलास्टिक्स खोज में धकेल दिए जा रहे हैं, जो 10.255.0.4 पर सेट है, जो इसे अनुपयोगी बनाता है, और मुझे अपने गैर-कंटेनरीकृत लॉगस्टैश परिनियोजन पर वापस जाना होगा अगर इसके लिए कोई फिक्स नहीं है।

@mrjana क्या आप इस समस्या को हल करने के लिए सुझाव जोड़ सकते हैं?

IPVS एक यूजरस्पेस रिवर्स प्रॉक्सी नहीं है जो HTTP लेयर में चीजों को ठीक कर सकता है। यह HAProxy और इस तरह के यूजरस्पेस प्रॉक्सी के बीच का अंतर है। यदि आप HAProxy का उपयोग करना चाहते हैं तो आप क्लस्टर में HAProxy डालकर ऐसा कर सकते हैं और उसी नेटवर्क में भाग लेने के लिए आपके सभी सेवा उदाहरण और HAProxy हैं। इस तरह HAProxy HTTP header.x-forwarded-for को ठीक कर सकता है। या यदि L7 लोड बैलेंसर क्लस्टर के बाहर है तो आप Host PublishMode नामक एक नई PublishMode लिए आगामी (1.13) सुविधा का उपयोग कर सकते हैं जो सेवा के प्रत्येक व्यक्तिगत उदाहरण को उजागर करेगा अपने स्वयं के व्यक्तिगत बंदरगाह में और आप अपने बाहरी लोड बैलेंसर को उस पर इंगित कर सकते हैं।

@mrjana आईपीवीएस का उपयोग करने का पूरा विचार (वर्तमान में जो कुछ भी डॉकर झुंड मोड में करता है) के बजाय स्रोत आईपी का अनुवाद शुरू करने से बचने के लिए होगा। एक्स-फॉरवर्ड-फॉर जोड़ने से कुछ HTTP अनुप्रयोगों में मदद मिल सकती है, लेकिन यह उन सभी अन्य अनुप्रयोगों के लिए किसी काम का नहीं है जो वर्तमान व्यवहार से टूट गए हैं।

@dack मेरी समझ यह है कि Docker

यदि आप HAProxy का उपयोग करना चाहते हैं तो आप क्लस्टर में HAProxy डालकर ऐसा कर सकते हैं और उसी नेटवर्क में भाग लेने के लिए आपके सभी सेवा उदाहरण और HAProxy हैं। इस तरह HAProxy HTTP शीर्षलेख को ठीक कर सकता है।x-forwarded-for

यह या तो @mrjana काम नहीं करेगा, क्लाइंट आईपी प्राप्त करने के लिए HAProxy के लिए एकमात्र तरीका डॉक रन का उपयोग करके या सीधे होस्ट पर इनग्रेड नेटवर्क के बाहर चलाना है, लेकिन फिर आप अपनी किसी भी सेवा का उपयोग नहीं कर सकते क्योंकि वे एक अलग नेटवर्क पर हैं और आप उन्हें एक्सेस नहीं कर सकते।

सीधे शब्दों में कहें, जहां तक ​​​​मुझे पता है कि इससे निपटने का कोई तरीका नहीं है, जैसे ही आप डॉकर सेवाओं और झुंड मोड का उपयोग करते हैं।

यह दिलचस्प होगा यदि docker ingress नेटवर्क के लेखक चर्चा में शामिल हो सकते हैं क्योंकि उन्हें शायद कुछ अंतर्दृष्टि होगी कि कैसे IPVS को हुड के तहत कॉन्फ़िगर / संचालित किया जाता है (IPVS के लिए कई तरीके हैं) और हम कैसे ठीक कर सकते हैं समस्या।

@tlvenn क्या आप जानते हैं कि यह स्रोत कोड में कहां है? मैं गलत हो सकता था, लेकिन मुझे विश्वास नहीं है कि यह मेरे द्वारा देखी गई कुछ चीजों के आधार पर आईपीवीएस का उपयोग कर रहा है:

• स्रोत पोर्ट का अनुवाद किया गया है (इस मुद्दे का पूरा कारण)। आईपीवीएस ऐसा नहीं करता है। NAT मोड में भी, यह केवल गंतव्य पते का अनुवाद करता है। IPVS होस्ट को रिटर्न पैकेट वापस भेजने के लिए आपको डिफ़ॉल्ट रूट या पॉलिसी रूटिंग का उपयोग करना होगा।
• जब एक पोर्ट झुंड मोड में प्रकाशित होता है, तो झुंड में सभी डॉकर्ड इंस्टेंस प्रकाशित पोर्ट पर सुनते हैं। यदि IPVS का उपयोग किया जाता है, तो यह कर्नेल स्थान में होगा और dockerd पोर्ट पर नहीं सुन रहा होगा।

हाय @ डैक ,

उनके ब्लॉग से:

आंतरिक रूप से, हम यह काम Linux IPVS, एक इन-कर्नेल लेयर 4 मल्टी-प्रोटोकॉल लोड बैलेंसर का उपयोग करके करते हैं जो कि Linux कर्नेल में 15 से अधिक वर्षों से है। कर्नेल के अंदर आईपीवीएस रूटिंग पैकेट के साथ, झुंड की रूटिंग जाल उच्च प्रदर्शन कंटेनर-जागरूक लोड-बैलेंसिंग प्रदान करती है।

अगर मैं गलत नहीं हूं तो कोड स्रोत स्वार्मकिट प्रोजेक्ट में रहना चाहिए।

मुझे आश्चर्य है कि क्या @stevvooe हमें यह समझने में मदद कर सकता है कि यहां अंतर्निहित समस्या क्या है।

ठीक है, मैंने कोड के माध्यम से एक संक्षिप्त रूप देखा है और मुझे लगता है कि अब मुझे इसकी थोड़ी बेहतर समझ है। ऐसा लगता है कि यह वास्तव में ब्लॉग में बताए गए आईपीवीएस का उपयोग कर रहा है। SNAT एक iptables नियम के माध्यम से किया जाता है जो service_linux.go में स्थापित होता है। अगर मैं सही ढंग से समझूं, तो इसके पीछे का तर्क कुछ इस तरह होगा (यह मानते हुए कि नोड ए को नोड बी पर चल रही सेवा के लिए क्लाइंट पैकेट प्राप्त होता है):

• झुंड नोड ए क्लाइंट पैकेट प्राप्त करता है। IPVS/iptables अनुवाद (src ip) ->(नोड a ip) और (dst ip) ->(नोड B ip)
• पैकेट को नोड B . को अग्रेषित किया जाता है
• नोड बी नोड ए को इसका जवाब भेजता है (जैसा कि यह src ip के रूप में देखता है)
• नोड ए src और dst को मूल मानों में वापस अनुवाद करता है और क्लाइंट को उत्तर अग्रेषित करता है

मुझे लगता है कि एसएनएटी के पीछे तर्क यह है कि उत्तर उसी नोड के माध्यम से जाना चाहिए जो मूल अनुरोध के माध्यम से आया था (जहां एनएटी/आईपीवीएस राज्य संग्रहीत है)। चूंकि अनुरोध किसी भी नोड के माध्यम से आ सकता है, एसएनएटी का उपयोग किया जाता है ताकि सेवा नोड को पता चल सके कि किस नोड से अनुरोध वापस करना है। सिंगल लोड बैलेंसिंग नोड वाले IPVS सेटअप में, यह कोई समस्या नहीं होगी।

तो, सवाल यह है कि एसएनएटी से कैसे बचें, जबकि अभी भी सभी नोड्स आने वाले क्लाइंट अनुरोधों को संभालने की इजाजत देते हैं। मुझे पूरा यकीन नहीं है कि सबसे अच्छा तरीका क्या है। हो सकता है कि सेवा नोड पर एक राज्य तालिका रखने का कोई तरीका हो ताकि वह एसएनएटी पर निर्भर होने के बजाय सीधे उत्तरों के लिए नीति रूटिंग का उपयोग कर सके। या हो सकता है कि किसी प्रकार का एनकैप्सुलेशन मदद कर सके (VXLAN?) या, आईपीवीएस की सीधी रूटिंग पद्धति का उपयोग किया जा सकता है। यह सेवा नोड को सीधे क्लाइंट को जवाब देने की अनुमति देगा (मूल अनुरोध प्राप्त करने वाले नोड के बजाय) और सेवाओं के लिए नए फ़्लोटिंग आईपी जोड़ने की अनुमति देगा। हालांकि, इसका मतलब यह भी होगा कि सेवा से केवल फ्लोटिंग आईपी के माध्यम से संपर्क किया जा सकता है, न कि व्यक्तिगत नोड आईपी (सुनिश्चित नहीं है कि यह किसी भी उपयोग के मामलों के लिए एक समस्या है)।

बहुत दिलचस्प खोज @dack !

उम्मीद है कि उस एसएनएटी को एक साथ छोड़ने के लिए एक समाधान मिल जाएगा।

इस बीच, हो सकता है कि एक वर्कअराउंड हो जो बहुत पहले नहीं किया गया हो, जो प्रभावी रूप से प्रवेश नेटवर्क को दरकिनार करते हुए PublishMode साथ एक होस्ट-स्तरीय पोर्ट प्रकाशन की शुरुआत करता है।

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

अरे, बड़ी मात्रा में प्रतिक्रिया के लिए धन्यवाद - हम सप्ताहांत के बाद इस मुद्दे पर गहराई से विचार करेंगे।

इस बीच कुछ जानकारी:

@tlvenn : @mrjana प्रवेश नेटवर्क सुविधा के पीछे मुख्य लेखक है। स्रोत ज्यादातर docker/libnetwork में रहता है, कुछ SwarmKit में

@dack : यह वास्तव में IPVS द्वारा समर्थित है

@tlvenn जहां तक ​​​​मुझे पता है, डॉकर झुंड मास्करेडिंग का उपयोग करता है, क्योंकि यह सबसे सरल तरीका है और अधिकांश कॉन्फ़िगरेशन में काम करने की गारंटी है। इसके अलावा यह एकमात्र तरीका है जो वास्तव में बंदरगाहों को भी छिपाने की अनुमति देता है [पुनः: @dack], जो आसान है। सिद्धांत रूप में, इस मुद्दे को IPIP एनकैप्सुलेशन मोड का उपयोग करके हल किया जा सकता है - पैकेट प्रवाह इस तरह होगा:

• गेटवे सर्वर पर एक पैकेट आता है - हमारे मामले में झुंड के किसी भी नोड - और उस नोड पर आईपीवीएस यह निर्धारित करता है कि यह वास्तव में अपने गंतव्य आईपी पते और पोर्ट के आधार पर वर्चुअल सेवा के लिए एक पैकेट है।
• पैकेट को दूसरे आईपी पैकेट में इनकैप्सुलेट किया जाता है और वास्तविक सर्वर पर भेजा जाता है जिसे लोड बैलेंसिंग एल्गोरिथम के आधार पर चुना गया था।
• वास्तविक सर्वर संलग्न पैकेट प्राप्त करता है, इसे डीकैप्सुलेट करता है और वास्तविक क्लाइंट आईपी को स्रोत और वर्चुअल सर्विस आईपी को गंतव्य के रूप में देखता है। सभी वास्तविक सर्वरों में वर्चुअल सेवा आईपी के साथ एक गैर-एआरपीएबल इंटरफ़ेस उपनाम होना चाहिए ताकि वे मान सकें कि यह पैकेट वास्तव में उनके लिए नियत है।
• वास्तविक सर्वर पैकेट को संसाधित करता है और सीधे क्लाइंट को प्रतिक्रिया भेजता है। इस मामले में स्रोत आईपी वर्चुअल सेवा आईपी होगा , इसलिए इसमें कोई मंगल ग्रह का जवाब शामिल नहीं है, जो अच्छा है।

बेशक, कई चेतावनी और चीजें हैं जो गलत हो सकती हैं, लेकिन आम तौर पर यह संभव है और उत्पादन में आईपीआईपी मोड का व्यापक रूप से उपयोग किया जाता है।

उम्मीद है कि इसके लिए जल्द ही एक समाधान मिल जाएगा, क्योंकि आईपी-निर्धारण और अन्य सुरक्षा जांचों को सही बाहरी आईपी प्राप्त करने में सक्षम होना चाहिए।

देख रहे। हमारा उत्पाद सुरक्षा और विश्लेषण के लिए स्रोत आईपी जानकारी का लाभ उठाता है।

@aluzzardi हमारे लिए कोई अपडेट?

टक्कर, हमें एक बहुत बड़ी परियोजना के लिए काम करने के लिए इसकी आवश्यकता है जिसे हम अगले साल की शुरुआत में शुरू कर रहे हैं।

प्रवाह की जांच, ऐसा लगता है कि वर्तमान में इस तरह काम करता है (इस उदाहरण में, नोड ए आने वाले ट्रैफ़िक को प्राप्त करता है और नोड बी सर्विस कंटेनर चला रहा है):

• नोड A पैकेट को ingress_sbox नेटवर्क नेमस्पेस (/var/run/docker/netns/ingress_sbox) में निर्देशित करने के लिए DNAT करता है।
• नोड ए पर ingress_sbox एनएटी मोड में आईपीवीएस चलाता है, जो डीएनएटी को नोड बी पर कंटेनर में पैकेट को निर्देशित करने के लिए करता है (इनग्रेड ओवरले नेटवर्क के माध्यम से) और एसएनएटी को स्रोत आईपी को नोड ए इनग्रेड ओवरले नेटवर्क आईपी में बदलने के लिए भी करता है।
• पैकेट को ओवरले के माध्यम से वास्तविक सर्वर पर रूट किया जाता है
• वापसी पैकेट रिवर्स में उसी पथ का अनुसरण करते हैं, स्रोत/गंतव्य पते को मूल मानों पर वापस लिखते हैं

मुझे लगता है कि एसएनएटी को इस तरह से टाला जा सकता है:

• नोड A बिना किसी NAT (iptables/नीति रूटिंग?)
• नोड A ingress_sbox सीधे रूटिंग मोड में IPVS चलाता है, जो इनग्रेड ओवरले नेटवर्क के माध्यम से नोड B को पैकेट भेजता है
• नोड बी पर कंटेनर को अपरिवर्तित पैकेट प्राप्त होता है (कंटेनर को सभी सार्वजनिक आईपी के लिए पैकेट स्वीकार करना चाहिए, लेकिन उनके लिए एआरपी नहीं भेजना चाहिए। ऐसा करने के कई तरीके हैं, आईपीवीएस दस्तावेज़ देखें)।
• रिटर्न पैकेट सीधे नोड बी से क्लाइंट को भेजते हैं (ओवरले नेटवर्क या नोड ए के माध्यम से वापस जाने की आवश्यकता नहीं है)

एक अतिरिक्त बोनस के रूप में, किसी भी NAT स्थिति को संग्रहीत करने की आवश्यकता नहीं है और ओवरले नेटवर्क ट्रैफ़िक कम हो जाता है।

@aluzzardi @mrjana कृपया इस पर कोई अपडेट दें? डॉकर से थोड़ी सी प्रतिक्रिया की बहुत सराहना की जाएगी।

देख रहे। स्रोत आईपी जानकारी के बिना, हमारी अधिकांश सेवाएं अपेक्षा के अनुरूप काम नहीं कर सकती हैं

यह कैसे हुआ ?

@tlvenn जीथब में एक बग की तरह लगता है?

@PanJ @tlvenn @vfarcic @dack और अन्य, PTAL #27917। हमने सेवा प्रकाशन मोड को सक्षम करने की क्षमता का परिचय दिया = host जो सेवा के लिए IPVS को बायपास करने और docker run -p जैसे व्यवहार को वापस लाने का एक तरीका प्रदान करेगा और यह उन मामलों के लिए स्रोत-आईपी को बनाए रखेगा जो जरूरत है।

कृपया 1.13.0-आरसी2 का प्रयास करें और प्रतिक्रिया दें।

हां बहुत अजीब @mavenugo ..

प्रकाशन मोड के बारे में, मैंने इसे पहले से ही ऊपर झुंड किट से जोड़ा था, यह एक समाधान हो सकता है लेकिन मुझे वास्तव में उम्मीद है कि इस मुद्दे को अच्छे के लिए संबोधित करने के लिए डॉकर 1.13 के साथ एक उचित समाधान आएगा।

इस मुद्दे को बग के रूप में वर्गीकृत किया जा सकता है क्योंकि स्रोत आईपी को संरक्षित करना वह व्यवहार है जो हम उपयोगकर्ताओं की अपेक्षा करते हैं और यह अभी डॉकर सेवाओं की एक बहुत ही गंभीर सीमा है।

मेरा मानना ​​​​है कि @kobolog और @dack दोनों इसे हल करने के तरीके के बारे में कुछ संभावित सुराग लेकर आए हैं और डॉकर की ओर से उन पर कोई अनुवर्ती कार्रवाई नहीं होने के लगभग 2 सप्ताह हो गए हैं।

क्या हम कृपया कुछ दृश्यता प्राप्त कर सकते हैं कि डॉकर में इस मुद्दे को कौन देख रहा है और एक स्थिति अद्यतन? अग्रिम में धन्यवाद।

#२७९१७ के अलावा १.१३ के लिए कोई दूसरा उपाय नहीं है। विभिन्न उपयोग-मामलों के लिए प्रत्यक्ष-वापसी कार्यक्षमता का विश्लेषण करने की आवश्यकता है और बग-फिक्स के रूप में विचार करने के लिए इसे हल्के में नहीं लिया जाना चाहिए। हम इसे 1.14 के लिए देख सकते हैं। लेकिन, यह भी विन्यास योग्य एलबी व्यवहार की श्रेणी में आता है, जिसमें एल्गोरिदम (आरआर बनाम 10 अन्य विधियां), डेटा-पथ (एलवीएस-डीआर, एलवीएस-एनएटी और एलवीएस-ट्यून) शामिल हैं। अगर कोई इसमें योगदान करने को तैयार है, तो कृपया एक पीआर को आगे बढ़ाएं और हम इसे आगे बढ़ा सकते हैं।

काफी हद तक मुझे लगता है कि @mavenugo को देखते हुए हमारे पास अब एक विकल्प है।

कम से कम, क्या हम 1.13 के लिए दस्तावेज़ में संशोधन कर सकते हैं ताकि यह स्पष्ट रूप से बताए कि डिफ़ॉल्ट प्रवेश प्रकाशन मोड के साथ डॉकर सेवाओं का उपयोग करते समय, स्रोत आईपी संरक्षित नहीं है और यदि यह सेवा चलाने के लिए एक आवश्यकता है तो होस्ट मोड का उपयोग करने पर संकेत दें ?

मुझे लगता है कि यह उन लोगों की मदद करेगा जो सेवाओं की ओर पलायन कर रहे हैं ताकि इस अप्रत्याशित व्यवहार से प्रभावित न हों।

निश्चित रूप से और हाँ इस व्यवहार को इंगित करने के लिए एक दस्तावेज़ अद्यतन और प्रकाशित mode=host का उपयोग करने का समाधान ऐसे उपयोग-मामलों के लिए उपयोगी होगा जो LVS-NAT मोड में विफल हो जाते हैं।

बस यह देखने के लिए वापस जाँच करें कि क्या इस वास्तविक चीज़ का पता लगाने में कोई नया विकास नहीं हुआ है? यह निश्चित रूप से हमारे लिए भी एक बड़ी सीमा है

क्या डॉकर 1.14 के रोडमैप पर कोई समाधान है? हम इस मुद्दे के कारण डॉकटर का उपयोग करके अपने समाधानों को तैनात करने में देरी कर रहे हैं।

http/https अनुरोध में जोड़ा गया एक कस्टम हेडर देखना पसंद करेंगे जो क्लाइंट-आईपी को सुरक्षित रखता है। यह संभव होना चाहिए, है ना? मुझे कोई आपत्ति नहीं है जब X_Forwarded_for को अधिलेखित कर दिया जाता है, मैं बस एक कस्टम फ़ील्ड रखना चाहता हूं जो केवल पहली बार अनुरोध झुंड में प्रवेश करता है।

http/https अनुरोध में जोड़ा गया एक कस्टम हेडर देखना पसंद करेंगे जो क्लाइंट-आईपी को सुरक्षित रखता है। यह संभव होना चाहिए, है ना? मुझे कोई आपत्ति नहीं है जब X_Forwarded_for को अधिलेखित कर दिया जाता है, मैं बस एक कस्टम फ़ील्ड रखना चाहता हूं जो केवल पहली बार अनुरोध झुंड में प्रवेश करता है।

भार संतुलन L3/4 पर किया जाता है। http शीर्षलेख जोड़ना संभव नहीं है।

एक सुधार में स्रोत पते के पुनर्लेखन को हटाना शामिल होगा।

@mavenugo मैंने आज डॉकर 1.13 में अपडेट किया और मेरी प्रॉक्सी सेवा पर mode=host किया। वर्तमान में यह काम करता है, क्लाइंट आईपी संरक्षित है, लेकिन मुझे बेहतर समाधान की उम्मीद है :) आपके काम के लिए धन्यवाद!

डबल पोस्ट के लिए खेद है...
मैं उसी व्यवहार को प्राप्त करने के लिए स्टैक फ़ाइल (yml v3) का उपयोग कैसे कर सकता हूं जब मैं docker service create के माध्यम से --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) का उपयोग कैसे कर सकता हूं जब मैं --publish मोड = होस्ट, लक्ष्य = 80, प्रकाशित = 80 docker service create के माध्यम से उपयोग करूंगा?

@hamburml - https://github.com/docker/docker/issues/30447 पर नज़र रखें, यह एक खुला मुद्दा/सुविधा है।

दुर्भाग्य से मैं वर्कअराउंड के रूप में mode=host उपयोग नहीं कर सकता क्योंकि मुझे झुंड नेटवर्क से संवाद करने के लिए मेरी सेवा की आवश्यकता है और सभी नोड्स पर भी सुनना चाहिए, न कि केवल होस्ट इंटरफ़ेस ...

@ 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 सुरंग यातायात को एन्क्रिप्ट करना है। डॉक्स से: "यदि आप एन्क्रिप्शन (--ऑप्ट एन्क्रिप्टेड) ​​के साथ एक ओवरले नेटवर्क बनाने की योजना बना रहे हैं, तो आपको प्रोटोकॉल 50 (ईएसपी) ट्रैफ़िक की अनुमति सुनिश्चित करने की भी आवश्यकता होगी।" क्या आप यह सुनिश्चित करने के लिए अपने कॉन्फ़िगरेशन की जांच कर सकते हैं कि ईएसपी की अनुमति है?
साथ ही, --opt encrypted विकल्प विशुद्ध रूप से डेटा-प्लेन एन्क्रिप्शन है। सभी कंट्रोल-प्लेन ट्रैफिक (रूटिंग एक्सचेंज, सर्विस डिस्कवरी डिस्ट्रीब्यूशन, आदि ...) सभी विकल्प के बिना भी डिफ़ॉल्ट रूप से एन्क्रिप्टेड हैं।

@mavenugo तुम सही हो। जब मैंने --opt encrypted साथ एक नया नेटवर्क बनाया तो इसने ठीक काम किया। जब मैंने नए बनाए गए नेटवर्क की तुलना अपने मौजूदा नेटवर्क से की तो मैंने देखा कि "Internal": true सेट किया गया था। यह संभवतः समस्या थी और प्रारंभिक नेटवर्क निर्माण के दौरान एक गलती थी... आपकी सहायता और स्पष्टीकरण के लिए धन्यवाद, यह एक लंबा दिन रहा है...

@dack @kobolog एलवीएस-टनल और एलवीएस-डीआर मोड की विशिष्ट तैनाती में आने वाले पैकेट में गंतव्य आईपी सेवा वीआईपी होगा जिसे वास्तविक सर्वर में गैर एआरपी आईपी के रूप में भी प्रोग्राम किया जाता है। रूटिंग मेश मौलिक रूप से अलग तरीके से काम करता है, आने वाला अनुरोध किसी भी मेजबान के लिए हो सकता है। वास्तविक सर्वर के लिए पैकेट को स्वीकार करने के लिए (किसी भी एलवीएस मोड में) गंतव्य आईपी को स्थानीय आईपी में बदलना होगा। बैकएंड कंटेनर से उत्तर पैकेट के लिए सही स्रोत पते के साथ वापस जाने का कोई तरीका नहीं है। सीधे वापसी के बजाय, हम उत्तर पैकेट को वापस प्रवेश करने वाले होस्ट को प्राप्त करने का प्रयास कर सकते हैं। लेकिन स्रोत आईपी को बदलने के अलावा इसे करने का कोई साफ तरीका नहीं है जो हमें एक वर्ग में वापस लाता है।

@thaJeztah मुझे लगता है कि हमें इसे दस्तावेज़ीकरण में स्पष्ट करना चाहिए, यदि क्लाइंट आईपी को संरक्षित करना है और इस मुद्दे को बंद करना है तो होस्ट मॉड का उपयोग करने का सुझाव दें।

@sanimej मैं अभी भी नहीं देखता कि एनएटी के बिना ऐसा करना असंभव क्यों है। क्या हमारे पास उपयोग करने का विकल्प नहीं हो सकता था, उदाहरण के लिए, नियमित LVS-DR प्रवाह? डॉकर गैर-एआरपी वीआईपी को उपयुक्त नोड्स में जोड़ता है, एलवीएस आने वाले पैकेट को नोड्स में निर्देशित करता है, और आउटगोइंग पैकेट सीधे वापस आ जाता है। यह क्यों मायने रखता है कि आने वाला पैकेट किसी भी होस्ट से टकरा सकता है? यह कई फ्रंटएंड और कई बैकएंड सर्वर के साथ मानक 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 होगा। तो एलबी बिना किसी आईपी परिवर्तन के पैकेट को बैकएंड पर भेज सकता है। रूटिंग मेश के मामले में ऐसा नहीं है क्योंकि आने वाले पैकेट का डेस्ट आईपी होस्ट के आईपी में से एक होगा।

@sanimej इस मुद्दे को हल करने के लिए आईपीआईपी एनकैप्सुलेशन मोड का उपयोग करने के लिए उपरोक्त प्रस्ताव पर कोई प्रतिक्रिया?

@tlvenn एलवीएस-आईपी सुरंग एलवीएस-डीआर के समान ही काम करती है, सिवाय इसके कि बैकएंड को मैक-रीराइट के बजाय आईपी सुरंग में आईपी के माध्यम से पैकेट मिलता है। तो रूटिंग मेष उपयोग के मामले में भी यही समस्या है।

आपके द्वारा संदर्भित प्रस्ताव से..
The real server receives the enclosing packet, decapsulates it and sees real client IP as source and virtual service IP as destination.

पैकेट का डेस्टिनेशन आईपी उस होस्ट का आईपी होगा जिसे क्लाइंट ने पैकेट भेजा था न कि वीआईपी। यदि इसे फिर से नहीं लिखा गया है, तो असली सर्वर बाहरी आईपी हेडर को हटाने के बाद इसे छोड़ देगा। यदि गंतव्य IP को फिर से लिखा जाता है, तो क्लाइंट को वास्तविक सर्वर के उत्तर में गलत स्रोत IP होगा जिसके परिणामस्वरूप कनेक्शन विफल हो जाएगा।

स्पष्टीकरण @sanimej के लिए धन्यवाद। क्या आप शायद प्रॉक्सी प्रोटोकॉल लागू कर सकते हैं? यह एक निर्बाध समाधान प्रदान नहीं करेगा लेकिन कम से कम यह सेवा को उपयोगकर्ता आईपी को हल करने के लिए एक समाधान प्रदान करेगा।

स्रोत पोर्ट श्रेणी को ब्लॉकों में विभाजित करके और क्लस्टर में प्रत्येक होस्ट के लिए एक ब्लॉक असाइन करके स्रोत आईपी संरक्षण प्राप्त करने का एक कठिन तरीका है। फिर एक हाइब्रिड एनएटी + डीआर दृष्टिकोण करना संभव है, जहां प्रवेश मेजबान सामान्य एसएनएटी करता है और पैकेट को वास्तविक सर्वर पर भेजता है। मेजबान पर जहां असली सर्वर चल रहा है, स्रोत आईपी के आधार पर एक एसएनएटी स्रोत पोर्ट को पोर्ट में बदलने के लिए इनग्रेड होस्ट के लिए निर्दिष्ट सीमा में है। फिर कंटेनर से रिटर्न पैकेट पर सोर्स पोर्ट रेंज (और टारगेट पोर्ट) के खिलाफ मैच होता है और सोर्स आईपी को इंग्रेस होस्ट में बदल देता है।

तकनीकी रूप से यह काम करेगा लेकिन वास्तविक तैनाती में अव्यावहारिक और नाजुक जहां क्लस्टर सदस्यों को जोड़ा जा रहा है और जल्दी से हटा दिया गया है। इससे पोर्ट स्पेस भी काफी कम हो जाता है।

मैंने जिस एनएटी + डीआर दृष्टिकोण का उल्लेख किया है वह काम नहीं करेगा क्योंकि स्रोत आईपी को प्रवेश मेजबान में नहीं बदला जा सकता है। उस विशेष होस्ट के लिए केवल स्रोत पोर्ट को सीमा में बदलकर और बैकएंड होस्ट से रूटिंग नीति का उपयोग करके पैकेट को वापस इनग्रेड होस्ट में लाने के लिए एक विकल्प हो सकता है। इसमें अभी भी अन्य मुद्दे हैं जिनका मैंने पहले उल्लेख किया था।

@thaJeztah
Nginx कंटेनर से वेब कंटेनर में वास्तविक IP पता अग्रेषित करने के लिए इस समय कोई समाधान है?
मैं में Nginx कंटेनर चल रहा है global मोड और करने के लिए प्रकाशित host तो Nginx कंटेनर एक सही आईपी पते हो जाता है,। दोनों कंटेनर एक दूसरे को ठीक देखते हैं, हालांकि, वेब कंटेनर को Nginx कंटेनर IP पता मिलता है, क्लाइंट को नहीं।
Nginx वेब के लिए एक रिवर्स प्रॉक्सी है, और वेब पोर्ट 8000 पर uwsgi चलाता है:

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 कॉन्फ़िगरेशन का उपयोग कर रहा हूं, लेकिन आईपी पता अभी भी गलत है, मेरे कॉन्फ़िगरेशन में कुछ गायब होना चाहिए

मेरे पास ओवरले नेटवर्क और दो सेवाओं के साथ एक डॉकर ( 17.03.0-सीई ) झुंड क्लस्टर है

    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/ का उपयोग करता है
वेब कंटेनर पोर्ट 8000 . पर uwsgi सर्वर चलाता है

मैं लिंक से वैश्विक 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 शीर्षलेख जोड़ देगा कि
वास्तविक आईपी पता शामिल करें। आपको अपनी पसंद के वेब सर्वर को कॉन्फ़िगर करना होगा
प्रॉक्सी पर भरोसा करने के लिए (स्रोत आईपी के बजाय हेडर का उपयोग करें)
शुक्र, मार्च १७, २५६० को शाम ७:३६ बजे लुकाज़ पाकुला नोटिफिकेशन @github.com
लिखा था:

@pi0 https://github.com/pi0 उत्तर के लिए धन्यवाद

मैं लिंक से nginx कॉन्फ़िगरेशन का उपयोग कर रहा हूं, लेकिन IP पता अभी भी है
गलत, मेरे कॉन्फ़िगरेशन में कुछ कमी होनी चाहिए

मेरे पास एक डोकर ( 17.03.0-सीई ) ओवरले नेटवर्क के साथ झुंड क्लस्टर है और दो
सेवाएं

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
वेब कंटेनर पोर्ट 8000 . पर uwsgi सर्वर चलाता है

मैं लिंक से वैश्विक 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 कंटेनर लॉग:

१९४.१६८.XX - - [१७/मार्च/२०१७:१२:२५:०८ +००००] "प्राप्त करें / एचटीटीपी/१.१" २००

वेब कंटेनर लॉग:

10.0.0.47 - - [17/मार्च/2017 12:25:08] "प्राप्त करें / एचटीटीपी/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 स्वचालित रूप से प्रेषक आईपी को नहीं बदलेगा, यह सिर्फ एक संकेत शीर्षलेख भेजता है।

@pi0 @PanJ
यह समझ में आता है, धन्यवाद दोस्तों!

होस्ट मोड का उपयोग करके पोर्ट को बाइंड करें।

nginx TPROXY कर्नेल मॉड्यूल का उपयोग करके IP पारदर्शिता का समर्थन करता है।

@stevvooe क्या डॉकर भी ऐसा कुछ कर सकता है?

nginx TPROXY कर्नेल मॉड्यूल का उपयोग करके IP पारदर्शिता का समर्थन करता है।
@stevvooe क्या डॉकर भी ऐसा कुछ कर सकता है?

संभावना नहीं है, क्योंकि प्रविष्टि को नोड्स में ट्रैक करने की आवश्यकता है। मैं @sanimej या @mavenugo दूंगा।

क्या झुंड क्लाइंट का IP पता प्राप्त करने के लिए REST API प्रदान कर सकता है?

@tonysongtl जो इस मुद्दे से संबंधित नहीं है

एक और बात पर विचार करना है कि अत्यधिक उपलब्ध सेटअप में आपका ट्रैफ़िक आपके नोड्स तक कैसे पहुँचाया जाता है। क्लाइंट के लिए त्रुटियाँ पैदा किए बिना एक नोड नीचे जाने में सक्षम होना चाहिए। वर्तमान अनुशंसा एक बाहरी लोड बैलेंसर (ईएलबी, एफ5, आदि) का उपयोग करना है और एक साधारण परत 4 स्वास्थ्य जांच के साथ प्रत्येक झुंड नोड के लिए परत 4 पर संतुलन लोड करना है। मेरा मानना ​​है कि F5 SNAT का उपयोग करता है, इसलिए इस कॉन्फ़िगरेशन में सबसे अच्छा मामला आपके F5 के एकल IP को कैप्चर करना है, न कि वास्तविक क्लाइंट 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

उपरोक्त टिप्पणी को प्रतिबिंबित करना - क्या प्रॉक्सी प्रोटोकॉल का उपयोग नहीं किया जा सकता है? सभी क्लाउड लोड बैलेंसर और हैप्रोक्सी इसका उपयोग स्रोत आईपी संरक्षण के लिए करते हैं।

केलिको में आईपीआईपी मोड भी है - https://docs.projectcalico.org/v2.2/usage/configuration/ip-in-ip - जो एक कारण है कि जीथब इसका उपयोग करता है। https://githubengineering.com/kubernetes-at-github/

नमस्ते।

समझने और पूर्णता के लिए, मुझे संक्षेप में बताएं और अगर मैं गलत हूं तो कृपया मुझे सुधारें:

मुख्य मुद्दा यह है कि कंटेनरों को मूल स्रोत-आईपी नहीं मिल रहा है, लेकिन वीआईपी झुंड है। मैंने इस मुद्दे को निम्नलिखित परिदृश्य के साथ दोहराया है:

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

ऐसा लगता है:

जब झुंड के भीतर सेवाएं (डिफ़ॉल्ट) जाल का उपयोग कर रही हैं, तो झुंड एनएटी को सुनिश्चित करने के लिए एक ही मूल से यातायात हमेशा एक ही होस्ट-रनिंग-सर्विस पर भेजा जाता है?
इसलिए, यह मूल 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 लेकिन, टीबीएच, उनके तर्क पूरी तरह से स्पष्ट नहीं हैं मुझे अभी तक, न ही मैं समझता हूं कि अगर यह निश्चित रूप से असंभव है तो धागा बंद क्यों नहीं किया गया है।

@sanimej यह काम नहीं करेगा ?:

1. झुंड src-IP=A और गंतव्य = "my-service-virtual-address" के साथ संदेश प्राप्त करता है
2. पैकेज उस सेवा को चलाने वाले झुंड नोड को भेजा जाता है, जो मूल संदेश को समाहित करता है।
3. कंटेनर-रनिंग-दैट-सर्विस-आईपी . में कार्य बदलने के लिए नोड आगे
   झुंड और नोड्स तालिकाओं को बनाए रख सकते हैं ताकि यह सुनिश्चित किया जा सके कि जब भी संभव हो उसी मूल से ट्रैफ़िक को उसी नोड पर अग्रेषित किया जाए।

क्या विशिष्ट सेवाओं के लिए "NAT के बजाय रिवर्स प्रॉक्सी" को सक्षम करने का विकल्प सभी को संतुष्ट करने वाले सभी मुद्दों को हल नहीं करेगा?

दूसरी ओर, IIUC, https://docs.docker.com/engine/swarm/services/#publish -a-services-ports-directly-on-the-swarm-node का उपयोग करने का एकमात्र विकल्प बचा है, जो -फिर से आईआईयूसी- ऐसा लगता है कि जाल का उपयोग बिल्कुल नहीं कर रहा है , इसलिए का उपयोग करने के लाभ नहीं दिख रहे हैं । वास्तव में, यह पूर्व-1.12 झुंड जैसा दिखता है, जिसे _Consul_ और इसी तरह की आवश्यकता होती है।

आपकी मदद और धैर्य के लिए धन्यवाद।
सादर

@sanimej
इससे भी अधिक ... क्यों डॉकर सिर्फ NAT को अग्रेषित करने वाला पोर्ट नहीं कर रहा है (केवल डेस्ट आईपी/पोर्ट बदल रहा है)?

1. झुंड संदेश प्राप्त करता है "ए से myservice के लिए"
2. उस सेवा को चलाने वाले होस्ट करने के लिए झुंड अग्रेषित संदेश, सेटिंग dest=node1
3. Node1 को "A से नोड1 तक" संदेश प्राप्त होता है, और आगे की सेटिंग dest=container1
4. कंटेनर 1 को "ए से कंटेनर 1 तक" संदेश प्राप्त होता है
5. उत्तर देने के लिए, कंटेनर डिफ़ॉल्ट गेटवे मार्ग का उपयोग करता है

मैं बस झंकार करना चाहूंगा; जबकि मैं समझता हूं कि ऐसा करने का कोई आसान तरीका नहीं है, मूल आईपी पते को किसी तरह से संरक्षित न करने से कई एप्लिकेशन उपयोग मामलों में गंभीर रूप से बाधा आती है। यहाँ कुछ है जो मैं अपने सिर के ऊपर से सोच सकता हूँ:

• नेटवर्क/सेवा इंजीनियरिंग के लिए आपके उपयोगकर्ताओं की उत्पत्ति कहां से हुई है, इसका विवरण देने में सक्षम होना नेटवर्क/सेवा इंजीनियरिंग के लिए महत्वपूर्ण है।

• सेवा दुरुपयोग के आधार पर गतिशील ब्लैकलिस्टिंग की अनुमति देने के लिए कई सुरक्षा अनुप्रयोगों में आपको मूल आईपी पते तक पहुंच की आवश्यकता होती है।

• अन्य तरीकों के विफल होने पर उपयोगकर्ता के सामान्य स्थान का पता लगाने के लिए स्थान जागरूकता सेवाओं को अक्सर आईपी पते तक पहुंचने में सक्षम होने की आवश्यकता होती है।

इस मुद्दे के धागे के मेरे पढ़ने से, ऐसा नहीं लगता है कि जब आप डॉकर झुंड के भीतर स्केलेबल सेवाएं चाहते हैं तो दिए गए वर्कअराउंड बहुत अच्छी तरह से काम करते हैं। अपने आप को प्रति कार्यकर्ता नोड के एक उदाहरण तक सीमित करने से पेशकश का लचीलापन बहुत कम हो जाता है। इसके अलावा, झुंड ऑर्केस्ट्रेटेड कंटेनरों में खिलाने से पहले एक गैर-झुंड ऑर्केस्ट्रेटेड कंटेनर के रूप में चलने वाले किनारे पर एक एलबी/प्रॉक्सी रखने का एक संकर दृष्टिकोण बनाए रखना समय पर वापस जाने जैसा लगता है। सर्विस ऑर्केस्ट्रेशन के लिए उपयोगकर्ता को 2 अलग-अलग प्रतिमानों को बनाए रखने की आवश्यकता क्यों है? किनारे पर एलबी/प्रॉक्सी को गतिशील रूप से स्केल करने में सक्षम होने के बारे में क्या? इसे मैन्युअल रूप से करना होगा, है ना?

क्या डॉकर टीम शायद इन टिप्पणियों पर विचार कर सकती है और देख सकती है कि क्या डॉकर पारिस्थितिकी तंत्र में मौजूद गुणवत्ता और लचीलेपन को बनाए रखते हुए इस कार्यक्षमता को पेश करने का कोई तरीका है?

इसके अलावा, मैं वर्तमान में इसकी चपेट में आ रहा हूं। मेरे पास एक वेब एप्लिकेशन है जो डाउनस्ट्रीम वेब सर्वर पर अधिकृत/प्रमाणीकृत अनुरोधों को अग्रेषित करता है। हमारे सेवा तकनीशियनों को यह सत्यापित करने में सक्षम होना चाहिए कि क्या लोग डाउनस्ट्रीम सर्वर तक पहुंच गए हैं, जिसके लिए वे वेब एक्सेस लॉग का उपयोग करना पसंद करते हैं। वर्तमान परिदृश्य में, मेरे पास वह कार्यक्षमता प्रदान करने का कोई तरीका नहीं है क्योंकि मेरा प्रॉक्सी सर्वर कभी भी मूल आईपी पता नहीं देखता है। मैं चाहता हूं कि मेरा आवेदन आसानी से स्केलेबल हो, और ऐसा नहीं लगता कि मैं इसे प्रस्तुत किए गए कार्य-आसपास के साथ कर सकता हूं, कम से कम प्रत्येक स्केल किए गए उदाहरण के लिए नए वीएम को फेंकने के बिना नहीं।

@ जित्सुमा क्या कुबेरनेट्स आपकी समस्या का समाधान कर सकता है?

@thaJeztah docker-compose का उपयोग करके काम करने का कोई तरीका है?

मैंने कोशिश की

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

लेकिन ऐसा लगता है कि स्रोत आईपी के रूप में 172.xx1 लेता है

@trajano , मुझे कोई सुराग नहीं है। क्या कुबेरनेट्स किसी तरह इस मुद्दे को हल करने का प्रबंधन करता है?

@जित्सुसामा
हां, उनके पास इस बात का दस्तावेज है कि वे स्रोत आईपी को कैसे संरक्षित करते हैं । यह कार्यात्मक है, लेकिन इतना सुंदर नहीं है यदि आप लोड बैलेंसर का उपयोग नहीं करते हैं क्योंकि पैकेट उन समापन बिंदुओं के बिना नोड्स पर गिर जाता है। यदि आप Rancher को अपने स्वयं-होस्ट किए गए लोड बैलेंसर के रूप में उपयोग करने की योजना बना रहे हैं, तो दुर्भाग्य से यह अभी तक इसका समर्थन नहीं करता है ।

@trajano

लेकिन ऐसा लगता है कि स्रोत आईपी के रूप में 172.xx1 लेता है

यदि आप अपने एप्लिकेशन को स्थानीय रूप से एक्सेस कर रहे हैं, तो वह आईपी सही होना चाहिए (यदि आप झुंड का उपयोग करते हैं) क्योंकि docker_gwbridge वह इंटरफ़ेस है जो आपके प्रॉक्सी कंटेनर के साथ इंटरैक्ट करता है। यह देखने के लिए कि क्या यह सही पता पकड़ता है, आप अपने आईपी नेटवर्क के भीतर किसी अन्य मशीन से ऐप तक पहुंचने का प्रयास कर सकते हैं।

कंपोज़ वर्कअराउंड के लिए, यह संभव है। यहां, मैं बैकएंड सेवा के रूप में nginx आधिकारिक बिल्ड छवि के साथ छवि jwilder/nginx-proxy को अपने फ्रंटएंड रिवर्स-प्रॉक्सी (अवधारणाओं को सरल बनाने के लिए) के रूप में उपयोग करता हूं। मैं डॉकर झुंड मोड में ढेर को तैनात करता हूं:

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 के हेडर के अंत में मूल आईपी ( 172.18.0.1 ) का संकेत है। X-Forwarded-For & X-Real-IP डिफ़ॉल्ट रूप से nginx.tmpl के jwilder/nginx-proxy में सेट होते हैं।

पोर्ट के लिए 443 , मैं docker-compose फ़ाइल में दोनों पोर्ट जोड़ने में सक्षम नहीं था, इसलिए मैं बस उपयोग करता हूं:

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 के दस्तावेज़ीकरण में अधिक बारीक विकल्प संभव हैं, या आप अपना स्वयं का सेटअप बना सकते हैं।

कुबेरनेट्स पर प्रवेश नियंत्रक अनिवार्य रूप से वही काम करते हैं, क्योंकि प्रवेश चार्ट (आमतौर पर) में X-Forwarded-For और X-Real-IP होता है, जिसमें पसंद और प्रकार के अंतर्ग्रहण और उनकी तैनाती प्रतिकृतियां भी अधिक लचीलेपन के साथ होती हैं।

तो कुबेरनेट्स प्रलेखन पूरा नहीं हुआ है। एक और तरीका जो किया जा रहा है
आमतौर पर वास्तव में प्रवेश + प्रॉक्सी प्रोटोकॉल होता है।

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

प्रॉक्सी प्रोटोकॉल एक व्यापक रूप से स्वीकृत प्रोटोकॉल है जो स्रोत को संरक्षित करता है
जानकारी। Haproxy प्रॉक्सी प्रोटोकॉल के लिए बिल्ट-इन सपोर्ट के साथ आता है। nginx
पढ़ सकते हैं लेकिन प्रॉक्सी प्रोटोकॉल इंजेक्ट नहीं कर सकते।

एक बार प्रॉक्सी प्रोटोकॉल सेटअप हो जाने के बाद, आप उस जानकारी को किसी से भी एक्सेस कर सकते हैं
डाउनस्ट्रीम सेवाएं जैसे
https://github.com/nginxinc/kubernetes-ingress/blob/master/examples/proxy-protocol/README.md

यहां तक ​​कि ओपनशिफ्ट भी स्रोत आईपी जानकारी के लिए इसका लाभ उठाता है
https://docs.openshift.org/latest/install_config/router/proxy_protocol.html

यह k8s के लिए नवीनतम हैप्रोक्सी प्रवेश है जो प्रॉक्सी प्रोटोकॉल को इंजेक्ट करता है।

आईएमएचओ झुंड में ऐसा करने का तरीका प्रवेश को प्रॉक्सी पढ़ने में सक्षम बनाना है
प्रोटोकॉल (यदि यह एक अपस्ट्रीम एलबी से ट्रैफ़िक प्राप्त कर रहा है जिसमें है
पहले से इंजेक्ट किया गया प्रॉक्सी प्रोटोकॉल) और साथ ही प्रॉक्सी प्रोटोकॉल को इंजेक्ट करें
जानकारी (यदि सभी ट्रैफ़िक वास्तव में पहले प्रवेश से टकराते हैं)।

मैं इसे किसी अन्य तरीके से करने के पक्ष में नहीं हूं, खासकर जब कोई हो
ऐसा करने के लिए आम तौर पर स्वीकृत मानक।

Traefik ने कुछ हफ़्ते पहले प्रॉक्सी_प्रोटोकॉल समर्थन जोड़ा था और यह v1.4.0-rc1 के बाद से उपलब्ध है।

इसे डॉकर झुंड प्रवेश स्तर पर करने की आवश्यकता है। अगर प्रवेश
प्रॉक्सी प्रोटोकॉल डेटा इंजेक्ट नहीं करता है, डाउनस्ट्रीम सेवाओं में से कोई भी नहीं
(traefix, nginx, आदि सहित) इसे पढ़ सकेंगे।

पर 10 सितम्बर 2017 21:42, "monotykamary" [email protected] लिखा है:

ट्रैफिक ने प्रॉक्सी_प्रोटोकॉल समर्थन जोड़ा
कुछ सप्ताह पहले https://github.com/containous/traefik/pull/2004 और is
v1.4.0-rc1 के बाद से उपलब्ध है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-328352805 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU3jj5dJcpMDysjIyGQK7SGx8GwWbks5shApqgaJpZM4Jf2WK
.

मैं भी इस बग के संबंध में infrakit के संबंध में उलझन में हूं। उदाहरण के लिए https://github.com/docker/infrakit/pull/601 क्या कोई इस दिशा में टिप्पणी कर सकता है कि डॉकर झुंड लेने जा रहा है?

झुंड रोलअप infrakit ? मैं इसके प्रवेश पक्ष के लिए विशेष रूप से उत्सुक हूं।

हम इस मामले में भी चल रहे हैं। हम क्लाइंट आईपी जानना चाहते हैं और इनबाउंड कनेक्शन के लिए आईपी का अनुरोध करना चाहते हैं। उदाहरण के लिए यदि उपयोगकर्ता हमारे सर्वर से एक कच्चा टीसीपी कनेक्शन करता है, तो हम जानना चाहते हैं कि उनका आईपी क्या है और वे हमारी मशीन पर किस आईपी से जुड़े हैं।

@blazedd जैसा कि पहले और अन्य थ्रेड्स में टिप्पणी की गई थी, यह वास्तव में publishMode का उपयोग करके संभव है। यानी: सेवाओं को जाल नेटवर्क द्वारा नियंत्रित नहीं किया जाता है।

आईआईयूसी, प्रवेश कैसे इसे संभालता है, इसे सुधारने की दिशा में कुछ प्रगति हो रही है, लेकिन वास्तव में यही एकमात्र समाधान है।

हमने बाहरी LB कॉन्फ़िगरेशन से बचने के लिए publishmode और mode:global का उपयोग करके अपनी nginx सेवा को तैनात किया है।

@mostolog आपके उत्तर के लिए धन्यवाद। बस कुछ नोट:

1. publishMode किसी भी तरह से समस्या का समाधान नहीं करता है। इनबाउंड सॉकेट कनेक्शन अभी भी स्थानीय नेटवर्क को हल करता है जो झुंड सेट करता है। कम से कम जब आप पोर्ट सूची का उपयोग करते हैं mode: host
2. nginx वास्तव में एक अच्छा समाधान नहीं है। हमारा एप्लिकेशन टीसीपी आधारित है, लेकिन वेब सर्वर नहीं है। ऐसा कोई हेडर नहीं है जिसे हम मैन्युअल रूप से कोडिंग किए बिना उपयोग करने में सक्षम हों।
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

और इसलिए, मैं शर्त लगा सकता हूं कि हमें अपने लॉग पर असली आईपी मिलेगा।

@mostolog यह कम से कम विंडोज़ पर काम नहीं करता है। मुझे अभी भी स्रोत के रूप में १७२.०.०.x पता मिल रहा है।

@mostolog mode: host आपके कंटेनर को होस्ट नेटवर्क पर प्रदर्शित नहीं करता है। यह कंटेनर को इनग्रेड नेटवर्क से हटा देता है, जो कि कंटेनर चलाते समय डॉकर सामान्य रूप से कैसे संचालित होता है। यह डॉक रन कमांड में प्रयुक्त --publish 8080:8080 दोहराएगा। यदि nginx को वास्तविक ips मिल रहा है, तो यह सॉकेट के सीधे उन ips से कनेक्ट होने का परिणाम नहीं है। इसका परीक्षण करने के लिए आपको बिना किसी ढांचे के कच्चे टीसीपी कार्यान्वयन या HTTP सर्वर का उपयोग करने पर गंभीरता से विचार करना चाहिए, और रिपोर्ट किए गए पते की जांच करनी चाहिए।

सीधे कंटेनर में आईपीवीएस रूट नेटवर्क का उपयोग क्यों न करें? सभी झुंड नोड के ओवरले इंटरफ़ेस के ips को वर्चुअल ips के रूप में बाँधें, मल्टी-गेटवे बनाने के लिए ip rule from xxx table xxx का उपयोग करें, फिर झुंड नोड्स क्लाइंट को सीधे कंटेनर (DNAT) में रूट कर सकते हैं, बिना किसी यूजरस्पेस नेटवर्क प्रॉक्सी डेमॉन (डॉकर्ड) के।

@blazedd क्या आपने कोशिश की है? @mostolog के उदाहरण का अनुसरण करते समय मुझे बाहरी आईपी पते मिल रहे हैं।

मैं फिर से इस मुद्दे के खिलाफ दौड़ रहा हूं।

मेरा सेटअप इस प्रकार है:

• DR मोड में ipvs लोड बैलेंसर (डॉकर झुंड के बाहर)
• 3 डॉक नोड, गंतव्य आईपी के साथ सभी नोड्स में जोड़ा गया और आईपीवीएस डीआर रूटिंग के लिए उचित रूप से कॉन्फ़िगर किया गया एआरपी

मैं झुंड के लिए एक ढेर तैनात करना चाहता हूं और पते को उलझाए बिना वर्चुअल आईपी पर पोर्ट 80 पर सुनता हूं।

मैं ऐसा करके लगभग वहां पहुंच सकता हूं:
बंदरगाह:
- लक्ष्य: 80
प्रकाशित: 80
प्रोटोकॉल: टीसीपी
मोड: होस्ट

यहां समस्या यह है कि यह आपको यह निर्दिष्ट करने की अनुमति नहीं देता है कि किस आईपी पते से जुड़ना है - यह सिर्फ सभी को बांधता है। यदि आप उस पोर्ट का उपयोग करके एक से अधिक सेवा चलाना चाहते हैं तो यह समस्याएँ पैदा करता है। इसे केवल एक आईपी से बांधने की जरूरत है। विभिन्न पोर्ट का उपयोग करना DR लोड संतुलन के साथ एक विकल्प नहीं है। ऐसा लगता है कि देवों ने यह धारणा बना ली है कि एक ही आईपी कई नोड्स पर मौजूद नहीं होगा, जो कि डीआर लोड बैलेंसर का उपयोग करते समय ऐसा नहीं है।

इसके अलावा, यदि आप छोटे सिंटैक्स का उपयोग करते हैं, तो यह बाइंड आईपी को अनदेखा कर देगा और फिर भी सभी पतों से जुड़ जाएगा। एक ही आईपी से जुड़ने का एकमात्र तरीका एक गैर-संकुल कंटेनर (सेवा या ढेर नहीं) चलाने के लिए है।

तो अब मैं स्टैंडअलोन कंटेनरों का उपयोग करने के लिए वापस आ गया हूं और ऐसा करने के लिए सेवा/स्टैक सुविधाओं पर भरोसा करने के बजाय उन्हें स्वयं प्रबंधित करना है।

हमारे पास एक ही मुद्दा है।
मैं डॉकर प्रवेश के भीतर एक पारदर्शी समाधान के लिए वोट दूंगा जो सभी अनुप्रयोगों (कुछ कच्चे यूडीपी/टीसीपी का उपयोग कर, विशेष रूप से HTTP नहीं) को अपेक्षित काम करने की अनुमति देगा।

मैं "मोड = होस्ट पोर्ट पब्लिशिंग" वर्कअराउंड का उपयोग कर सकता हूं क्योंकि मेरी सेवा विश्व स्तर पर तैनात है।
हालाँकि, ऐसा लगता है कि यह macvlan नेटवर्क ड्राइवर के उपयोग के साथ असंगत है, जिसकी मुझे कुछ अन्य कारणों से आवश्यकता है।
हमें "macvlan ड्राइवर पोर्ट मैपिंग का समर्थन नहीं करता" जैसे लॉग मिलते हैं।
मैंने कई नेटवर्क का उपयोग करने की कोशिश की, लेकिन यह मदद नहीं करता है।

मैंने यहां एक विशिष्ट टिकट बनाया है: https://github.com/docker/libnetwork/issues/2050
इससे मुझे अभी कोई समाधान नहीं मिलता है :'(

हाय दोस्तों
क्या अभी के लिए कोई उपाय है? इसे एक होस्ट पोर्ट के रूप में प्रकाशित किए बिना
बंदरगाह ?

11-जनवरी-2018 00:03 को, "ओलिवियर वोर्टमैन" नोटिफिकेशन @github.com ने लिखा:

हमारे पास एक ही मुद्दा है।
मैं डॉकर प्रवेश के भीतर एक पारदर्शी समाधान के लिए वोट दूंगा जो सभी को अनुमति देगा
अनुप्रयोगों (कुछ कच्चे यूडीपी/टीसीपी का उपयोग कर रहे हैं, विशेष रूप से एचटीटीपी नहीं) के रूप में काम करने के लिए
अपेक्षित होना।

मैं "मोड = होस्ट पोर्ट पब्लिशिंग" वर्कअराउंड का उपयोग कर सकता हूं क्योंकि मेरी सेवा है
विश्व स्तर पर तैनात।
हालाँकि, ऐसा लगता है कि यह 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
.

यह वास्तव में अफ़सोस की बात है कि क्लाइंट का आईपी प्राप्त करना संभव नहीं है। यह अधिकांश डॉकटर झुंड की अच्छी सुविधाओं को प्रयोग करने योग्य नहीं बनाता है।

मेरे सेटअप पर क्लाइंट का आईपी प्राप्त करने का एकमात्र तरीका network_mode:host का उपयोग करना है और झुंड का उपयोग बिल्कुल नहीं करना है।

mode=host port publishing या पारंपरिक docker run -p "80:80" ... काम नहीं चला

https://github.com/moby/moby/issues/15086 में कुछ समाधान सुझाए गए थे लेकिन मेरे लिए काम करने वाला एकमात्र समाधान "होस्ट" नेटवर्किंग था ...

सही आईपी नहीं होने के साथ एक और मुद्दा यह है कि nginx दर सीमित करना सही ढंग से काम नहीं करता है और इसलिए डॉकर झुंड लोड बैलेंसर के साथ उपयोग नहीं किया जा सकता है, क्योंकि अनुरोधों को सीमित किया जा रहा है और अस्वीकार कर दिया गया है क्योंकि nginx उन सभी की गणना करता है क्योंकि वे एकल उपयोगकर्ता/आईपी से आते हैं। तो मोड = होस्ट का उपयोग करने के लिए केवल कामकाज है, लेकिन इस तरह मैं लोड संतुलन क्षमताओं को खो देता हूं और विशिष्ट उदाहरणों के लिए DNS को इंगित करना पड़ता है।

शायद डॉकटर इस काम के लिए आदर्श उपकरण नहीं है, मैं सामने वाले HTTP सर्वर को स्थापित करने और क्लाइंट आईपी को HTTP अनुरोध हेडर के हिस्से के रूप में स्थापित करने के लिए योनि में देख रहा था।

जब तक डॉकर ओवरले नेटवर्क पर क्लाइंट की जानकारी पास करने में सक्षम नहीं हो जाता, तब तक कोई भी डॉकर फ्लो प्रॉक्सी या ट्रैफिक जैसे प्रॉक्सी का उपयोग कर सकता है, उस सेवा में होस्ट मोड में वांछित पोर्ट प्रकाशित कर सकता है और एप्लिकेशन सेवाओं को इससे कनेक्ट कर सकता है। एक पूर्ण समाधान नहीं है, लेकिन बहुत अच्छी तरह से काम करता है और एप्लिकेशन सेवाओं के लोड संतुलन/क्लाइंट आईपी की पुनर्प्राप्ति की अनुमति देता है।

@deeky666 Traefik और इसी तरह का काम केवल dockerized नहीं होने पर

मुझे traefik . पर udo समर्थन दिखाई नहीं दे रहा है

मेरे आईफोन से भेजा गया

अंत में हमने डॉकटर कंटेनर को छोड़ दिया। यह उत्पादन के लिए तैयार नहीं है!

बुध, पर 5:43 महिला 24 जनवरी, 2018, पर एफ़्रैन [email protected] लिखा है:

मुझे traefik . पर udo समर्थन दिखाई नहीं दे रहा है

मेरे आईफोन से भेजा गया

>

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे 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 में बिल्कुल भी काम नहीं कर रहा था, इसलिए मेरे लिए पहले से ही एक सुधार है!

अपडेट के दौरान डाउन टाइम से बचने के लिए उस वर्कअराउंड की बड़ी कमी संभव नहीं है।
वर्तमान में, हमें यह चुनना होगा कि क्या स्थिरता या स्रोत आईपी पता छोड़ना है।

मैं सहमत हूं। स्रोत आईपी को संरक्षित करने के लिए झुंड को उच्च उपलब्धता के तरीके की आवश्यकता होती है।

शायद प्रॉक्सी प्रोटोकॉल का उपयोग कर रहे हैं। मुझे नहीं लगता कि यह जोड़ने का एक बड़ा प्रयास है
डोकर झुंड के लिए प्रॉक्सी प्रोटोकॉल समर्थन।

क्या कोई इस पर गौर कर रहा है?

२८-जनवरी-२०१८ को २२:३९ को, "जेनकी ताकीउची" नोटिफिकेशन @github.com ने लिखा:

डाउन से बचने के लिए उस वर्कअराउंड की बड़ी कमी संभव नहीं है
अद्यतन के दौरान समय।
वर्तमान में, हमें छोड़ना होगा कि क्या स्थिरता या स्रोत आईपी
पता।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-361078416 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU-or7fnhKTg7fhjtZYjGYHBFRE7Dks5tPKnYgaJpZM4Jf2WK
.

@sandys मैं सहमत हूँ। प्रॉक्सी प्रोटोकॉल बहुत अच्छा विचार होगा।
@thaJeztah @aluzzardi @mrjana क्या इस मुद्दे पर कृपया कुछ ध्यान दिया जा सकता है? काफी समय से टीम की ओर से कोई प्रतिक्रिया नहीं आई है। धन्यवाद।

प्रॉक्सी प्रोटोकॉल मेरे लिए सबसे अच्छा समाधान लगता है। उम्मीद है कि टीम इस पर विचार करेगी।

@goetas इसने एक बिंदु पर काम किया, कम से कम मैंने इसे काम करते देखा लेकिन ऐसा लगता है कि यह 172.xxx व्यवहार में फिर से docker 1.12.6 में वापस आ गया है।

यह बहुत बुरा है, यह किसी भी दर को सीमित करने, धोखाधड़ी की रोकथाम, लॉगिंग, सुरक्षित लॉगिन, सत्र निगरानी आदि को कम करता है!
मोड के साथ सुनना

यह हमारे लिए एक बहुत ही महत्वपूर्ण और महत्वपूर्ण बग है और यह झुंड के साथ हमारे गो-लाइव को रोक रहा है। हम यह भी मानते हैं कि प्रॉक्सी प्रोटोकॉल इसके लिए सही समाधान है। डॉकर प्रवेश को प्रॉक्सी प्रोटोकॉल पर स्रोत आईपी पास करना होगा।

ट्विटर पर प्रस्तावित समाधानों में से एक है ट्रैफिक का उपयोग झुंड के बाहर प्रबंधित प्रवेश के रूप में करना। यह हमारे लिए अत्यधिक उप-इष्टतम है - और एक उपरि नहीं जिसे हम प्रबंधित करना चाहते हैं।

यदि झुंड देवता यह देखना चाहते हैं कि झुंड-प्रवेश में प्रॉक्सी प्रोटोकॉल को कैसे लागू किया जाए, तो उन्हें ट्रैफ़िक में चर्चा की जा रही सभी बगों की जाँच करनी चाहिए (जैसे https://github.com/containous/traefik/issues/2619)

मुझे यह झुंड मोड के बजाय "लिखें" का उपयोग करके लगातार काम कर रहा है। शायद सोचने के लिए कुछ।

प्रॉक्सी प्रोटोकॉल के साथ कुछ चिंताएँ:

क्या यह डॉकर द्वारा या एप्लिकेशन द्वारा डीकोड किया गया है? यदि हम प्रॉक्सी प्रोटोकॉल को लागू करने के लिए एप्लिकेशन पर निर्भर हैं, तो यह सभी एप्लिकेशन के लिए एक सामान्य समाधान नहीं है और केवल वेब सर्वर या अन्य एप्लिकेशन के लिए काम करता है जो प्रॉक्सी प्रोटोकॉल को लागू करते हैं। यदि डॉकटर प्रॉक्सी प्रोटोकॉल को खोल देता है और पते का अनुवाद करता है, तो उसे कनेक्शन स्थिति को भी ट्रैक करना होगा और आउटगोइंग पैकेट पर उलटा अनुवाद करना होगा। मैं वेब-विशिष्ट समाधान (एप्लिकेशन में प्रॉक्सी प्रोटोकॉल पर निर्भर) के पक्ष में नहीं हूं, क्योंकि डॉकर कई गैर-वेब अनुप्रयोगों के लिए भी उपयोगी है। किसी भी टीसीपी/यूडीपी एप्लिकेशन के सामान्य मामले के लिए इस मुद्दे को संबोधित किया जाना चाहिए - डॉकर में और कुछ भी वेब-विशिष्ट नहीं है।

किसी भी अन्य एनकैप्सुलेशन पद्धति की तरह, पैकेट आकार/एमटीयू मुद्दों की भी चिंता है। हालांकि, मुझे लगता है कि यह शायद इस मुद्दे के किसी भी समाधान के साथ एक चिंता का विषय होने जा रहा है। इसका उत्तर संभवतः यह सुनिश्चित करेगा कि आपका झुंड नेटवर्क ओवरहेड की अनुमति देने के लिए पर्याप्त एमटीयू का समर्थन करता है। मुझे लगता है कि अधिकांश झुंड स्थानीय नेटवर्क पर चलाए जाते हैं, इसलिए शायद यह कोई बड़ा मुद्दा नहीं है।

@trajano - हम जानते हैं कि यह होस्ट नेटवर्किंग के साथ काम करता है (जो संभवतः आपका रचना समाधान कर रहा है)। हालाँकि, यह झुंड के सभी क्लस्टर नेटवर्किंग लाभों (जैसे लोड संतुलन) को बाहर फेंक देता है।

@dack बैकएंड को प्रॉक्सी प्रोटोकॉल पता होना चाहिए।
मुझे लगता है कि यह ज्यादातर मामलों को हल करता है और कम से कम आप एक पतली पासथ्रू जैसी प्रॉक्सी रख सकते हैं जो प्रोटोकॉल हेडर को कंटेनरों के अंदर आपके बैकएंड के सामने संसाधित करती है।
जानकारी की कमी के कारण घातक मुद्दा है, मेरा मानना ​​​​है कि इसे अन्य स्वच्छ समाधान से पहले जितनी जल्दी हो सके हल करना आवश्यक है।

प्रॉक्सी प्रोटोकॉल की व्यापक स्वीकृति है। समर्थित टूल की संख्या देखें -
यह क्लाउड लोड बैलेंसर्स (ईएलबी, गूगल एलबी) और ट्रैफिक जैसे नए टूल को भी कवर नहीं करता है।

इसके अलावा - कुबेरनेट्स में यह काफी मानक है: https://github.com/kubernetes/ingress-nginx#proxy -protocol

इस बिंदु पर, प्रॉक्सी प्रोटोकॉल इस समस्या को हल करने में सबसे व्यापक रूप से स्वीकृत मानक है। मैं इसे फिर से आविष्कार करने और दुनिया के nginxes के साथ संगतता को तोड़ने में एक बड़ा मूल्य नहीं देखता।

ये L7 प्रोटोकॉल हैं। झुंड प्रवेश L4 है। यहां कुछ भी पुनर्निर्मित नहीं किया जा रहा है, यह डीएनएटी का उपयोग कर आईपीवीएस है।

@ cpuguy83 समझ नहीं पाया कि आपका क्या मतलब है।

प्रॉक्सी प्रोटोकॉल परत 4 है।
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

PROXY प्रोटोकॉल का लक्ष्य सर्वर की आंतरिक संरचनाओं को भरना है
प्रॉक्सी द्वारा एकत्र की गई जानकारी जो सर्वर प्राप्त करने में सक्षम होता
अपने आप से यदि क्लाइंट सीधे सर्वर से कनेक्ट हो रहा था बजाय a . के माध्यम से
प्रॉक्सी। प्रोटोकॉल द्वारा वहन की जाने वाली जानकारी वही होती है जो सर्वर करेगा
getockname() और getpeername() का उपयोग करें:

• पता परिवार (IPv4 के लिए AF_INET, IPv6 के लिए AF_INET6, AF_UNIX)
• सॉकेट प्रोटोकॉल (TCP के लिए SOCK_STREAM, UDP के लिए SOCK_DGRAM)
• परत 3 स्रोत और गंतव्य पते
• परत 4 स्रोत और गंतव्य बंदरगाह यदि कोई हो

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

स्वीकार-प्रॉक्सी

इनमें से किसी के द्वारा स्वीकार किए गए किसी भी कनेक्शन पर PROXY प्रोटोकॉल के उपयोग को लागू करता है
एक ही लाइन पर घोषित सॉकेट। प्रॉक्सी प्रोटोकॉल के संस्करण 1 और 2
समर्थित हैं और सही ढंग से पता लगाया गया है। PROXY प्रोटोकॉल परत को निर्देशित करता है
आने वाले कनेक्शन के 3/4 पते हर जगह उपयोग किए जाने वाले पते हैं
"टीसीपी-अनुरोध कनेक्शन" नियमों के एकमात्र अपवाद के साथ प्रयोग किया जाता है, जो
केवल वास्तविक कनेक्शन पता देखें। लॉग पतों को प्रतिबिंबित करेंगे
प्रोटोकॉल में इंगित किया गया है, जब तक कि इसका उल्लंघन नहीं किया जाता है, उस स्थिति में वास्तविक
पते का अभी भी उपयोग किया जाएगा। यह खोजशब्द बाहरी से समर्थन के साथ संयुक्त है
घटकों का उपयोग एक कुशल और विश्वसनीय विकल्प के रूप में किया जा सकता है
एक्स-फॉरवर्डेड-मैकेनिज्म के लिए जो हमेशा विश्वसनीय नहीं होता है और हमेशा भी नहीं होता है
प्रयोग करने योग्य बारीक-बारीक के लिए "tcp-request कनेक्शन अपेक्षा-प्रॉक्सी" भी देखें
किस क्लाइंट को प्रोटोकॉल का उपयोग करने की अनुमति है इसकी सेटिंग।

क्या आपका मतलब प्रॉक्सी प्रोटोकॉल से बेहतर तरीका था? यह पूरी तरह से संभव है और डॉकर झुंड में स्रोत आईपी संरक्षण के संदर्भ में और जानना अच्छा लगेगा। हालाँकि, प्रॉक्सी प्रोटोकॉल अन्य उपकरणों (जैसे nginx, आदि) द्वारा अधिक व्यापक रूप से समर्थित है, जो झुंड-प्रवेश के लिए डाउनस्ट्रीम होगा ... साथ ही साथ AWS ELB जैसे उपकरण जो झुंड-प्रवेश के लिए अपस्ट्रीम होंगे। वह मेरा केवल $0.02 . था

@sandys प्रॉक्सी प्रोटोकॉल

मैं इसे मूल रूप से समर्थन नहीं देना चाहता, लेकिन शायद प्रवेश को प्लग करने योग्य बनाना एक सार्थक दृष्टिकोण होगा।

@sandys https://github.com/sandys प्रॉक्सी प्रोटोकॉल जैसा दिखता है
एनकैप्सुलेशन (कम से कम कनेक्शन दीक्षा पर), जिसके लिए ज्ञान की आवश्यकता होती है
स्टैक के नीचे रिसीवर से इनकैप्सुलेशन का। वहां
इस दृष्टिकोण के लिए बहुत सारे ट्रेड-ऑफ हैं।

यह सच है। यही कारण है कि यह RFC के साथ एक मानक है। वहाँ है
हालांकि इसके पीछे गति - बहुत अधिक हर घटक महत्व
इसका समर्थन करता है। IMHO इसका समर्थन करने का कोई बुरा निर्णय नहीं है।

मैं मूल रूप से इसका समर्थन नहीं करना चाहता, लेकिन शायद प्रवेश कर रहा हूं
प्लग करने योग्य एक सार्थक दृष्टिकोण होगा।

यह एक बड़ी चर्चा है - हालांकि मैं इसे सबसे बड़ा जोड़ सकता हूं
दूसरों पर डॉकर झुंड का लाभ यह है कि इसमें सभी बैटरी हैं
अंतर्निर्मित।

मैं अब भी आपसे प्रॉक्सी प्रोटोकॉल को एक महान समाधान के रूप में मानने का अनुरोध करूंगा
यह समस्या जिसे उद्योग का समर्थन प्राप्त है।

क्या Linux और LxCs पर L3 राउटर का अनुकरण करना संभव नहीं है (विशेष रूप से docker नहीं)

@trajano सिमुलेशन की जरूरत नहीं है लेकिन इस मुद्दे को हल करने के लिए इनकैप्सुलेशन है।
उदाहरण के लिए, एक विकल्प (उदा: --use-proxy-protocol ) उन सेवाओं के लिए प्रदान किया जा सकता है जिन्हें क्लाइंट आईपी पते की आवश्यकता होती है और यह जानते हैं कि nginx जैसे एनकैप्सुलेटेड पैकेट का इलाज कैसे किया जाता है।

जैसा कि यह वर्तमान में काम करता है, पैकेट प्राप्त करने वाला डॉकटर नोड SNAT करता है और पैकेट को एप्लिकेशन कंटेनर के साथ नोड को अग्रेषित करता है। यदि एसएनएटी के बजाय किसी प्रकार के टनलिंग/एनकैप्सुलेशन का उपयोग किया गया था, तो आवेदन के लिए मूल अन-परिवर्तित पैकेट को पास करना संभव होना चाहिए।

यह अन्य परियोजनाओं में एक हल की गई समस्या है। उदाहरण के लिए, ओपनस्टैक के साथ आप GRE और VXLAN जैसी सुरंगों का उपयोग कर सकते हैं।

क्या इस धागे के हाल के हिस्से में कोई है जो डॉकर टीम का प्रतिनिधित्व करता है और कम से कम यह कहता है कि 'हम आपको सुनते हैं'? ऐसा लगता है कि एक ऐसी सुविधा जिसकी आप अपेक्षा करते हैं कि वह 'आउट ऑफ द बॉक्स' है और समुदाय के लिए इस तरह की रुचि का समाधान अभी भी लगभग 18 महीने पहले 9 अगस्त 2016 को पहली बार रिपोर्ट किए जाने के बाद भी हल नहीं हुआ है।

क्या इस धागे के हाल के हिस्से में कोई है जो डॉकर टीम का प्रतिनिधित्व करता है और कम से कम यह कहता है कि 'हम आपको सुनते हैं'?

/cc @GordonTheTurtle @thaJeztah @riyazdf @aluzzardi

@bluejaguar @ruudboon मैं डॉकर का हिस्सा हूं। यह एक जाना माना मुद्दा है। अभी नेटवर्क टीम ओवरले नेटवर्किंग स्थिरता के साथ लंबे समय से चली आ रही बग पर ध्यान केंद्रित कर रही है। यही कारण है कि पिछले कुछ रिलीज में वास्तव में नई नेटवर्किंग सुविधाएं नहीं हैं।

मेरा सुझाव एक ठोस प्रस्ताव के साथ आना होगा कि आप इस मुद्दे को हल करने के लिए काम करने के इच्छुक हैं या कम से कम एक अच्छा पर्याप्त प्रस्ताव है कि कोई भी इसे ले सकता है और इसके साथ चल सकता है।

@ cpuguy83 मैं https://github.com/kubernetes/kubernetes/issues/42616 (PS दिलचस्प रूप से यहां प्रॉक्सी प्रोटोकॉल Google Kubernetes Engine से प्रवाहित हो रहा है, जो HTTPS मोड में मूल रूप से प्रॉक्सी प्रोटोकॉल का समर्थन करता है)।

इसके अलावा, ईएलबी ने नवंबर 2017 में प्रॉक्सी प्रोटोकॉल v2 के लिए समर्थन जोड़ा है (https://docs.aws.amazon.com/elasticloadbalancing/latest/network/doc-history.html)

ओपनस्टैक ऑक्टेविया एलबी-एज़-ए-सर्विस (हमारे प्रवेश के समान) पिछले अप्रैल में मर्ज किए गए प्रॉक्सी प्रोटोकॉल - http://git.openstack.org/cgit/openstack/octavia/commit/?id=bf7693dfd884329f7d1169eec33eb03d2ae81ace

ओपनस्टैक में प्रॉक्सी प्रोटोकॉल के आसपास के कुछ दस्तावेज यहां दिए गए हैं - https://docs.openshift.com/container-platform/3.5/install_config/router/proxy_protocol.html
कुछ बारीकियां https के लिए प्रॉक्सी प्रोटोकॉल के आसपास हैं (दोनों मामलों में जब आप प्रमाणपत्रों को प्रवेश पर समाप्त कर रहे हैं या नहीं)।

इस मुद्दे के संबंध में कोई अपडेट/समाधान? हमें वास्तव में क्लाइंट आईपी को डॉकर झुंड मोड में जानने की जरूरत है।
कोई भी सहायताकाफी प्रशंसनीय होगी।

मेरा संस्करण:

ग्राहक:
संस्करण: १८.०२.०-सीई
एपीआई संस्करण: 1.36
गो संस्करण: go1.9.3
गिट प्रतिबद्ध: fc4de44
निर्मित: बुध फ़रवरी 7 21:16:33 2018
ओएस/आर्क: linux/amd64
प्रायोगिक: असत्य
ऑर्केस्ट्रेटर: झुंड

सर्वर:
यन्त्र:
संस्करण: १८.०२.०-सीई
एपीआई संस्करण: 1.36 (न्यूनतम संस्करण 1.12)
गो संस्करण: go1.9.3
गिट प्रतिबद्ध: fc4de44
निर्मित: बुध फ़रवरी 7 21:15:05 2018
ओएस/आर्क: linux/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 और हमेशा एक सटीक मेजबान में रहने, जिसका आईपी हमारे सार्वजनिक क्षेत्र के लिए बाध्य कर रहा है। यह इसे वास्तविक उपयोगकर्ता आईपी प्राप्त करने में सक्षम बनाता है। और क्योंकि यह default नेटवर्क से भी जुड़ा है, यह समर्थित सेवाओं से जुड़ने में सक्षम होगा।

आप frontend को भी स्केल कर सकते हैं, जब तक कि आप इसे केवल उसी होस्ट में लाइव रखते हैं। यह मेजबान को विफलता का एकल बिंदु बनाता है, लेकिन (मुझे लगता है) यह छोटी साइट के लिए ठीक है।

अधिक जानकारी जोड़ने के लिए संपादित किया गया:

मेरा nginx कंटेनर https://github.com/jwilder/nginx-proxy के पीछे है, मैं SSL को सक्षम करने के लिए https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion का भी उपयोग करता हूं। Nginx-proxy docker run कमांड के माध्यम से चलाया जाता है, न कि डॉकटर झुंड सेवा के माध्यम से। शायद इसीलिए मुझे क्लाइंट्स से असली आईपी मिला। मेरे nginx कंटेनरों को nginx-proxy के साथ संचार करने की अनुमति देने के लिए bridge नेटवर्क की आवश्यकता है।

एफडब्ल्यूआईडब्ल्यू, मैं उपयोग कर रहा हूँ:

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 मोड में चलाया जाता है तो यह काम नहीं करता है और फिर भी स्रोत आईपी खो देता है जबकि docker-compose up सही ढंग से काम करता है।

मैंने @goetas . के आधार पर निम्नलिखित की भी कोशिश की थी

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

अभी भी स्रोत आईपी प्राप्त करने में कोई भाग्य नहीं है यह Server Version: 17.12.0-ce

ऐसा लगता है कि हर कोई किसी न किसी बिंदु पर चाहेगा, और चूंकि ब्रिज/होस्ट नेटवर्किंग के साथ ओवरले नेटवर्क का उपयोग करना वास्तव में संभव नहीं है, यह उन मामलों में एक अवरोधक है जब आपको वास्तव में विभिन्न कारणों से क्लाइंट आईपी की आवश्यकता होती है।

ग्राहक:
संस्करण: १७.१२.०-सीई
एपीआई संस्करण: 1.35
गो संस्करण: go1.9.2
गिट प्रतिबद्ध: c97c6d6
निर्मित: बुध दिसम्बर 27 20:03:51 2017
ओएस/आर्क: डार्विन/amd64

सर्वर:
यन्त्र:
संस्करण: १७.१२.१-सीई
एपीआई संस्करण: 1.35 (न्यूनतम संस्करण 1.12)
गो संस्करण: go1.9.4
गिट प्रतिबद्ध: 7390fc6
निर्मित: मंगल फ़रवरी 27 22:17:54 2018
ओएस/आर्क: linux/amd64
प्रायोगिक: सत्य

यह 2018 है। इस मुद्दे के बारे में कुछ नया?
झुंड मोड में, मैं nginx req सीमा का उपयोग नहीं कर सकता। $remote_addr हमेशा 10.255.0.2 पकड़ा गया।
डॉकर झुंड के बारे में यह वास्तव में गंभीर समस्या है।
शायद मुझे आज से ही कुबेरनेट्स आजमाना चाहिए।

@ मास्लो मैंने पोस्ट किया जहां हम ऊपर कुछ टिप्पणियां हैं।

क्या हम चेक में ढील दे सकते हैं

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 बजे, ब्रायन गोफ नोटिफिकेशन @github.com ने लिखा:

@trajano आप पहले से ही झुंड के साथ गैर-झुंड स्कोप नेटवर्क का उपयोग कर सकते हैं ... उदाहरण के लिए यह काम करता है:

संस्करण: '3.4'

सेवाएं:
परीक्षण:
छवि: अल्पाइन
आदेश: शीर्ष
बंदरगाह:
- लक्ष्य: 32555
प्रकाशित: ३२५५५
प्रोटोकॉल: टीसीपी
मोड: होस्ट
नेटवर्क:
- पुल

नेटवर्क:
पुल:
बाहरी:
नाम: ब्रिज
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

हाँ, मैं इसे झुंड के माध्यम से कर रहा हूँ ...

सोम, मार्च 19, 2018 को सुबह 9:12 बजे, आर्किमिडीज ट्रैजानो <
सूचनाएं@github.com> ने लिखा:

क्या आपने डॉकर स्टैक के साथ एक से अधिक कार्यकर्ताओं के झुंड पर इसका परीक्षण किया था?
तैनात करना। मुझे पता है कि यह रचना के साथ काम करता है।

18 मार्च 2018 को रात 8:55 बजे, ब्रायन गोफ नोटिफिकेशन @github.com
लिखा था:

@trajano आप पहले से ही झुंड के साथ गैर-झुंड स्कोप नेटवर्क का उपयोग कर सकते हैं ...
उदाहरण के लिए यह काम करता है:

संस्करण: '3.4'

सेवाएं:
परीक्षण:
छवि: अल्पाइन
आदेश: शीर्ष
बंदरगाह:

• लक्ष्य: 32555
  प्रकाशित: ३२५५५
  प्रोटोकॉल: टीसीपी
  मोड: होस्ट
  नेटवर्क:
• पुल

नेटवर्क:
पुल:
बाहरी:
नाम: ब्रिज
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-374206587 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAwxZsm3OohKL0sqUWhlgUNjCrqR0OaVks5tf67YgaJpZM4Jf2WK
.

--

• ब्रायन गोफ्

+1

निम्नलिखित डॉकटर झुंड लोड संतुलन के साथ 3 नोड्स के साथ यह समस्या होना:

ओवरले नेटवर्क <-> nginx प्रॉक्सी jwilder docker <-> nginx वेब हेड डॉकर

मैंने सुझावों का पालन किया और लॉग वास्तविक क्लाइंट आईपी के बजाय डॉकर नेटवर्क आईपी 10.255.0.3 लौटाते रहे।

+1

@ cpuguy83 यह हमारे बड़े झुंड सेटअप के लिए अवरोधक बनना शुरू हो गया है। जैसे-जैसे हम क्लाउड का अधिक लाभ उठाना शुरू करते हैं (जहां लोड बैलेंसर्स द्वारा प्रॉक्सी प्रोटोकॉल का वास्तविक उपयोग किया जा रहा है), हम इस जानकारी को खो रहे हैं जो हमारे लिए बहुत महत्वपूर्ण है।

क्या आपके पास ईटीए का कोई विचार है? इससे हमें बहुत मदद मिलेगी।

@sandys एक ईटीए वास्तव में किस लिए?

@ cpuguy83 हाय, आपके उत्तर के लिए धन्यवाद। मुझे पता है कि आप इसे कैसे हल करना चाहते हैं, इस पर कोई व्यापक सहमति नहीं है। मैं इस पर टिप्पणी कर रहा हूं कि कैसे स्थिरता के मुद्दों पर टीम का कब्जा है और इस मुद्दे के लिए मुक्त नहीं है।
आप कब सोचेंगे कि इस मुद्दे को (यदि बिल्कुल भी) उठाया जाएगा?

ध्यान दें कि आप एक वैश्विक सेवा चलाकर और PublishMode=host का उपयोग करके पोर्ट प्रकाशित करके इस समस्या का समाधान कर सकते हैं। यदि आप जानते हैं कि लोग किस नोड से जुड़ रहे हैं, तो आपको इसकी आवश्यकता भी नहीं है, बस उस नोड को ठीक करने के लिए एक बाधा का उपयोग करें।

@kleptog आंशिक रूप से आप नहीं कर सकते। यह सेवा को अपडेट करते समय डाउनटाइम से नहीं बच सकता।

परीक्षण परिदृश्य - lvs/ipvs में करीब से देखें।

• छिपे हुए प्रवेश कंटेनर में nsenter और snat नियम को हटा दें
• प्रकाशित बंदरगाहों के साथ सेवा में nsenter, डिफ़ॉल्ट gw हटाएं और कंटेनर आईपी में प्रवेश करने के लिए डिफ़ॉल्ट मार्ग जोड़ें।

अब स्रोत आईपी संरक्षित किया जाएगा।

मैं अभी भी ओवरहेड के निहितार्थ को समझने की कोशिश कर रहा हूं, प्रत्येक सेवा कंटेनर के भीतर नीति आधारित रूटिंग को बनाए रखने के बजाय केवल प्रवेश कंटेनर में स्नैट नियम होने के बजाय।
हालांकि, यह काम करना वास्तव में राहत देने वाला होगा।

मेरे भोलेपन के लिए क्षमा करें, लेकिन क्या कोई ( @dack ?) मुझे इशारा कर सकता है, जहां यह किया जाता है?

आह, अब मैं समझ गया। एक मल्टीनोड झुंड में आईपी को एलवीएस निदेशक होना चाहिए, यह सही नोड पर वापस जाने के लिए अनुरोध आया ...

वैसे भी कोड को देखना दिलचस्प होगा। अगर किसी को पहले से पता होता तो यह मेरा कुछ समय बचा सकता था। शुक्रिया

इस पर कोई अपडेट, अलग-अलग देशों में तीन क्लस्टर होने और यहां तक ​​​​कि Azure ट्रैफिक मैनेजर को वास्तविक उपयोगकर्ता आईपी की आवश्यकता है, यदि नहीं, तो वह उपयोगकर्ता को अच्छे क्लस्टर आदि पर रीडायरेक्ट नहीं करेगा। कोई भी, जल्द ही या कभी भी इस पर जांच करेगा? धन्यवाद

इस पर एक अपडेट की भी आवश्यकता है - यह एक बहुत बड़ा गोचा है - इसके आस-पास एक ही तरीका है कि मैं सामने एक और प्रॉक्सी जोड़ूं और एक्स-फॉरवर्ड-फॉर को स्टैक पर भेजूं, इस तरह का मतलब है कि झुंड जनता के लिए एक गैर-विकल्प है कई परिदृश्यों के लिए यातायात का सामना करना पड़ रहा है।

@cpuguy83 @trajano
मैं पुष्टि कर सकता हूं कि निम्नलिखित काम नहीं करता है

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 यह वही है जिसका मैंने उपयोग किया था लेकिन मैं "पोर्टेनर" या लिनक्स मशीन से तैनात करता हूं। मैं इसे विंडोज़ से ठीक से तैनात नहीं कर सकता।

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 उपयोग करता हूं मेरे मामले में मैं अपने मेजबानों को वर्चुअलबॉक्स वीएम के रूप में भी चला रहा हूं और मैं राउटर का उपयोग करता हूं जो एनएटी रूटिंग करता है और जो आने वाले आईपी को सभी तरह से संरक्षित करता है बर्तन।

बेशक कोई भार संतुलन क्षमता नहीं है, मुझे लगता है कि यदि आप लोड संतुलन चाहते हैं तो आपको एल 3 राउटर की तरह कुछ सामने रखना

@trajano सही है, विंडोज क्लाइंट समस्या थी, लिनक्स क्लाइंट के साथ तैनाती ने काम किया।

लेकिन मुझे समझ में नहीं आता कि आपको host या bridge नेटवर्क की आवश्यकता क्यों है?
निम्नलिखित मेरे लिए ठीक काम करता है, अर्थात मुझे nginx में वास्तविक क्लाइंट IP पते मिलते हैं:

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

@ Mobe91 धन्यवाद मैं इसके लिए एक मुद्दा खोलने का मतलब था। मूल रूप से https://github.com/moby/moby/issues/32957 के साथ टाई

क्या किसी ने सिलियम का इस्तेमाल किया है? http://cilium.readthedocs.io/en/latest/gettingstarted/docker/ ।

ऐसा लगता है जैसे यह होस्ट करने के लिए सेवाओं को बांधे बिना इसे ठीक करने में सक्षम हो सकता है।

@sandys अच्छा खोज - मैं इसका परीक्षण शुरू करने जा रहा हूं, क्या यह आपके लिए काम करता है? अगर मैं इसे ठीक नहीं कर सकता तो मैं अपने झुंड से nginx को बाहर निकालने वाला हूं .....

हमने अलग-अलग मेजबानों के लिए प्रॉक्सी पिनिंग से बचने के लिए अपनी तैनाती को फिर से डिजाइन करने में इसे मारा (जो, उत्पादन में, अन्य कारणों से एक इंटरफ़ेस से जुड़ता है और इसलिए क्लाइंट आईपी को उप-उत्पाद के रूप में "पिक अप" करता है)।

हमारे परीक्षण के माहौल में हम केवल प्रबंधकों को बाध्य करके और mode = global सेट करके सुधार कर सकते हैं ताकि यह सुनिश्चित हो सके कि प्रत्येक प्रबंधक को एक रनिंग इंस्टेंस मिले। इसके बारे में जागरूक होने के लिए अभी भी अतिरिक्त ओवरहेड है, खासकर अगर हम एक प्रबंधक नोड खो देते हैं और कुछ हमारे यातायात को निर्देशित कर रहा है। हालाँकि, यह एकल होस्ट पर पिन किए जाने से बेहतर है।

@sandys क्या आपने सिलियम की कोशिश की? वीव के समान दिखता है, जो कम से कम k8s के साथ समान समस्या से ग्रस्त प्रतीत होता है: https://github.com/kubernetes/kubernetes/issues/51014

मैं सिलियम का उपयोग करने में सक्षम नहीं हूं, लेकिन मैं सिलियम तक पहुंच गया हूं
झुंड विन्यास में मदद करने के लिए देव। लेकिन मैं सिलियम को लेकर काफी उत्साहित हूं
क्योंकि प्रवेश एक घोषित समस्या है जिसे वह हल करना चाहता है (बुनाई के विपरीत)

गुरु १० मई, २०१८ को १७:२४ जेम्स ग्रीन, नोटिफिकेशन @github.com ने लिखा:

परदे के पीछे पिन करने से बचने के लिए हमने अपने परिनियोजन को फिर से डिज़ाइन करने में इसे हिट किया
अलग-अलग मेजबान (जो, उत्पादन में, दूसरे के लिए एक इंटरफ़ेस से जुड़ते हैं
कारण और इसलिए क्लाइंट आईपी को बायप्रोडक्ट के रूप में "पिक अप" करें)।

हमारे परीक्षण के माहौल में हम केवल प्रबंधकों को तैनात करके ही सुधार कर सकते हैं
बाधा और सेटिंग मोड = वैश्विक यह सुनिश्चित करने के लिए कि प्रत्येक प्रबंधक को एक मिल जाए
चल उदाहरण। इसके बारे में जागरूक होने के लिए अभी भी अतिरिक्त ओवरहेड है,
खासकर अगर हम एक प्रबंधक नोड खो देते हैं और कुछ हमारे को निर्देशित कर रहा है
इसके लिए यातायात। हालाँकि, यह एकल होस्ट पर पिन किए जाने से बेहतर है।

@sandys https://github.com/sandys क्या आपने सिलियम की कोशिश की? के समान दिखता है
बुनाई, जो कम से कम k8s के साथ एक ही समस्या से ग्रस्त प्रतीत होती है:
कुबेरनेट्स/कुबेरनेट्स#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 को, "जेम्स ग्रीन" नोटिफिकेशन @github.com ने लिखा:

परदे के पीछे पिन करने से बचने के लिए हमने अपने परिनियोजन को फिर से डिज़ाइन करने में इसे हिट किया
अलग-अलग मेजबान (जो, उत्पादन में, दूसरे के लिए एक इंटरफ़ेस से जुड़ते हैं
कारण और इसलिए क्लाइंट आईपी को बायप्रोडक्ट के रूप में "पिक अप" करें)।

हमारे परीक्षण के माहौल में हम केवल प्रबंधकों को तैनात करके ही सुधार कर सकते हैं
बाधा और सेटिंग मोड = वैश्विक यह सुनिश्चित करने के लिए कि प्रत्येक प्रबंधक को चल रहा हो
उदाहरण। इसके बारे में जागरूक होने के लिए अभी भी अतिरिक्त ओवरहेड है, खासकर यदि
हम एक प्रबंधक नोड खो देते हैं और कुछ हमारे ट्रैफ़िक को उस पर निर्देशित कर रहा है।
हालाँकि, यह एकल होस्ट पर पिन किए जाने से बेहतर है।

@sandys https://github.com/sandys क्या आपने सिलियम की कोशिश की? के समान दिखता है
बुनाई, जो कम से कम k8s के साथ एक ही समस्या से ग्रस्त प्रतीत होती है:
कुबेरनेट्स/कुबेरनेट्स#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

हाय दोस्तों,
यदि आप सिलियम में डॉकर झुंड का समर्थन चाहते हैं (विशेषकर प्रवेश के लिए और
इस विशेष समस्या के आसपास), कृपया इस बग पर टिप्पणी/पसंद करें -
https://github.com/cilium/cilium/issues/4159

शुक्र, 11 मई, 2018 को दोपहर 12:59 बजे, मैकबैकर नोटिफिकेशन @github.com ने लिखा:

>

• 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 बंद करके लोड करना बंद कर देता है और वास्तविक आईपी प्रकट होता है। उदाहरण के लिए, यहाँ मेरे 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

मैं पुष्टि करता हूं कि
होस्ट मोड का उपयोग क्लाइंट आईपी प्राप्त करने की अनुमति देता है।

डॉकर संस्करण 18.03.1-सीई, 9ee9f40 का निर्माण करें
उबंटू 16.04.4 एलटीएस

मैं पुष्टि कर सकता हूं कि यह काम कर रहा है।

डॉकर संस्करण 18.03.1-सीई, 9ee9f40 का निर्माण करें
उबंटू 16.04.4 एलटीएस

चेतावनी: यदि आपने IPTABLES=FALSE सेट किया है तो यह काम नहीं करेगा!
आपने यह किया होगा (या कम से कम मैंने किया) यदि आप बंदरगाहों को सुरक्षित करने के लिए यूएफडब्ल्यू का उपयोग कर रहे हैं और उन यूएफडब्ल्यू सेटिंग्स को ओवरराइड करने के लिए डॉकर झुंड पाया है।

आस-पास कुछ ट्यूटोरियल हैं जो iptables = false को कमांड के माध्यम से या /etc/docker/daemon.json में सेट करने का सुझाव देते हैं।

उम्मीद है कि यह किसी को उस निराशा से बचाता है जिससे मैं अभी-अभी गुज़रा हूँ!

लोगों को वास्तव में "मोड: होस्ट" = काम करना बंद कर देना चाहिए, क्योंकि वह इनग्रेड का उपयोग नहीं कर रहा है। इससे झुंड पर चलने वाली सेवा के साथ केवल एक कंटेनर होना असंभव हो जाता है लेकिन फिर भी इसे किसी भी होस्ट के माध्यम से एक्सेस करने में सक्षम होता है। आपको या तो सेवा को "ग्लोबल" बनाना होगा या आप इसे केवल उस होस्ट पर एक्सेस कर सकते हैं जो वह चला रहा है, जो कि झुंड के उद्देश्य को हरा देता है।

TLDR: "मोड: होस्ट" एक समाधान है, समाधान नहीं

@ r3pek जबकि मैं इनग्रेड खो देते हैं, मैं कहूंगा कि यह झुंड के पूरे उद्देश्य को शायद ही हरा देता है, जो इतना अधिक करता है कि एक सार्वजनिक सामना करने वाले नेटवर्क का सामना करना पड़ता है। हमारे उपयोग परिदृश्य में हमारे पास एक ही ओवरले झुंड है:
प्रबंधन ने कंटेनरों को दोहराया जिन्हें केवल इंट्रानेट पर एक्सेस किया जाना चाहिए -> उन्हें कॉलर के आईपी की आवश्यकता नहीं है, इसलिए वे "सामान्य रूप से" कॉन्फ़िगर किए गए हैं और प्रवेश का लाभ उठाते हैं।
गैर-उजागर कंटेनर -> इनके बारे में कहने के लिए कुछ भी नहीं (मुझे विश्वास है कि आप उनके सेवा नाम के माध्यम से उन्हें एक्सेस करने में सक्षम होने की शक्ति को कम करके आंक रहे हैं)।
पब्लिक फेसिंग सर्विस -> यह एक nginx प्रॉक्सी है जो https और url आधारित रूटिंग करती है। क्लाइंट के असली आईपी के लिए एक्स-फॉरवर्ड करने की आवश्यकता से पहले भी इसे वैश्विक परिभाषित किया गया था, इसलिए वहां कोई वास्तविक समस्या नहीं है।

nginx वैश्विक होने और प्रवेश न होने का मतलब है कि आप क्लस्टर के किसी भी आईपी के माध्यम से उस तक पहुंच सकते हैं, लेकिन यह संतुलित या दोष सहिष्णु लोड नहीं है, इसलिए हमने nginx के सामने L4 Azure लोड बैलेंसर स्थापित करने के लिए एक बहुत ही सस्ता और आसान जोड़ा। सेवा।

जैसा कि आप कहते हैं, होस्ट एक वर्कअराउंड है, लेकिन यह कहना कि इसे सक्षम करना पूरी तरह से डॉकर झुंड के उद्देश्य को हरा देता है, थोड़ा अतिरंजित आईएमओ है।

हाय रॉबर्टो
मुझे नहीं लगता कि यह अतिशयोक्तिपूर्ण है - क्योंकि होस्ट मोड एकल बिंदुओं को उजागर करता है
विफलता का। इसके अलावा, यह लोड के लिए प्रबंधन की अतिरिक्त परतों की अपेक्षा करता है
झुंड पारिस्थितिकी तंत्र के बाहर संतुलन।

यह कहकर कि आपने स्वयं azure lb का उपयोग किया है, आपने इस बात की पुष्टि कर दी है
तर्क।

यह कहने के समान है कि "क्लाइंट आईपी प्रसार के साथ झुंड चलाने के लिए,
सुनिश्चित करें कि आप एक बाहरी लोड बैलेंसर का उपयोग कर रहे हैं जिसे आपने सेट किया है...या उपयोग करें
क्लाउड सेवाओं में से एक"।

हम यह नहीं कह रहे हैं कि यह अस्थायी समाधान नहीं है...लेकिन यह होगा
झुंड के वादे की अनदेखी अगर हम सभी स्पष्ट रूप से नहीं पहचानते हैं
कमी

गुरु, ५ जुलाई, २०१८, १४:१६ रॉबर्टो फैब्रीज़ी पर, सूचनाएं @github.com
लिखा था:

@r3pek https://github.com/r3pek जबकि मैं आपसे सहमत हूं कि आप हार गए
यदि आप इस समस्या को हल करने के लिए होस्ट मोड का उपयोग करते हैं, तो मैं कहूंगा कि यह
झुंड के पूरे उद्देश्य को शायद ही हरा देता है, जो इतना अधिक करता है कि a
सार्वजनिक सामना करने वाला प्रवेश नेटवर्क। हमारे उपयोग परिदृश्य में हमारे पास एक ही है
ओवरले झुंड:
प्रबंधन ने कंटेनरों को दोहराया है जिन्हें केवल ऊपर तक पहुँचा जाना चाहिए
इंट्रानेट -> उन्हें कॉलर के आईपी की आवश्यकता नहीं है, इसलिए उन्हें कॉन्फ़िगर किया गया है
"सामान्य रूप से" और प्रवेश का लाभ उठाएं।
गैर-उजागर कंटेनर -> इनके बारे में कहने के लिए कुछ नहीं (मुझे विश्वास है कि आप हैं
उनकी सेवा के माध्यम से उन तक पहुँचने में सक्षम होने की शक्ति को कम करके आंकना
हालांकि नाम)।
सार्वजनिक सामना करने वाला कंटेनर -> यह एक nginx प्रॉक्सी है जो https और url करता है
आधारित रूटिंग। इसे एक्स-फॉरवर्ड-फॉर की आवश्यकता से पहले ही वैश्विक परिभाषित किया गया था
ग्राहक का असली आईपी, इसलिए वहां कोई वास्तविक समस्या नहीं है।

nginx वैश्विक होने और प्रवेश न करने का मतलब है कि आप इसके माध्यम से पहुंच सकते हैं
क्लस्टर के किसी भी आईपी, लेकिन यह संतुलित लोड नहीं है, इसलिए हमने एक बहुत जोड़ा
Nginx के सामने L4 Azure लोड बैलेंसर स्थापित करने के लिए सस्ता और आसान
सेवा।

जैसा कि आप कहते हैं, होस्ट एक समाधान है, लेकिन कह रहा है कि इसे पूरी तरह से सक्षम करना
डॉकर झुंड के उद्देश्य को हरा देता है थोड़ा अतिरंजित आईएमओ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-402650066 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU_ogRzwM6X0PMknXxsxmZLLTtfraks5uDdJlgaJpZM4Jf2WK
.

यह स्पष्ट है कि डॉकर झुंड के प्रवेश के लिए एक खराब लोड बैलेंसर (आईपीवीएस) को चुना गया था। यदि यह कम से कम L4 प्रॉक्सी प्रोटोकॉल का समर्थन कर रहा होता तो यह कोई समस्या नहीं होती। सिवाय इसके कि यह अभी भी सभी अतिरिक्त सुविधाओं के बिना L4 (TCP) लोड बैलेंसर होगा जो L7 lb दे सकता है।

Kubernetes में L4(TCP)-L7(HTTP) लोड बैलेंसर्स हैं जैसे nginx ingress , L4 प्रॉक्सी प्रोटोकॉल या L7 HTTP हेडर के उपयोग की अनुमति देते हैं ताकि यह सुनिश्चित किया जा सके कि X-Forwarded-For का उपयोग उपयोगकर्ता के वास्तविक को पास करने के लिए किया जाता है। बैकएंड के लिए आईपी।

मैं सोच रहा हूं कि डॉकर झुंड के डेवलपर्स क्या कहेंगे। शायद किसी को इस मामले को https://github.com/docker/swarmkit/issues पर ले जाना होगा?

Kubernetes में L4 (TCP) -L7 (HTTP) लोड बैलेंसर हैं जैसे nginx ingress, haproxy ingress जो दोनों L4 प्रॉक्सी प्रोटोकॉल या L7 HTTP हेडर के उपयोग की अनुमति देते हैं ताकि यह सुनिश्चित किया जा सके कि उपयोगकर्ता के वास्तविक आईपी को पास करने के लिए X-Forwarded-For का लाभ उठाया गया है। बैकएंड को।

AFAICS, उन LB सेवाओं को K8s में एम्बेड नहीं किया गया है, लेकिन ऐसी सेवाएँ जिन्हें स्पष्ट रूप से तैनात करने की आवश्यकता है। आप डॉकर झुंड के साथ भी ऐसा ही कर सकते हैं। मुझे यहां कोई अंतर नहीं दिख रहा है। (इसके अलावा nginx प्रवेश नियंत्रक "आधिकारिक" प्रतीत होता है।)

जहां तक ​​​​मुझे पता है, अंतर यह है कि यदि आप ऐसी लोडबैलेंसिंग सेवा को तैनात करते हैं तो भी इसे स्वार्मकिट लोडबैलेंसर से 'कॉल' किया जाएगा और इसलिए आप उपयोगकर्ताओं के आईपी को खो देंगे। तो यदि आप होस्टमोड का उपयोग नहीं कर रहे हैं तो आप स्वार्मकिट लोडबैलेंसर को अक्षम नहीं कर सकते हैं।

निष्पक्ष होना - k8s में, कस्टम प्रवेश करना संभव है। झुंड में यह
नहीं है।

झुंड स्टैंड लेता है कि सब कुछ "अंतर्निहित" है। ऐसा ही कुछ का भी है
नेटवर्क - k8s में, आपको इसके अंतर्निर्मित झुंड में बुनाई आदि सेट अप करने की आवश्यकता होती है।

तो एंड्री जो बिंदु बना रहा है (और मैं इससे सहमत हूं) वह है -
झुंड को इन सुविधाओं को प्रवेश के हिस्से के रूप में बनाना चाहिए, क्योंकि उपयोगकर्ता के पास है
उस पर कोई नियंत्रण नहीं।

शनिवार, 28 जुलाई, 2018 को शाम 5:07 बजे सेटी नोटिफिकेशन @github.com ने लिखा:

जहां तक ​​​​मुझे पता है, अंतर यह है कि यदि आप इस तरह की तैनाती करते हैं तो
लोडबैलेंसिंग सेवा इसे स्वार्मकिट लोडबैलेंसर से 'कहा जाएगा'
और इसलिए आप उपयोगकर्ता आईपी खो देते हैं। तो आप झुंडकिट को निष्क्रिय नहीं कर सकते
लोडबैलेंसर यदि होस्टमोड का उपयोग नहीं कर रहा है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-408601274 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU1-Ism_S1Awml8lO8N0Aq6rtrLH4ks5uLEzugaJpZM4Jf2WK
.

मैंने सोचा था कि हम अपने झुंड झुर्रियों को इस्त्री करना समाप्त कर चुके हैं, लेकिन फिर हम मंच पर पहुंचे और देखा कि वेब सर्वर कंटेनर में सभी बाहरी पहुंच प्रवेश नेटवर्क आईपी के रूप में दिखाई देती है।

मैं सिंगल-नोड झुंड पर अपना स्टैक चला रहा हूं और कम से कम अगले कुछ महीनों तक ऐसा करता रहूंगा। क्या आप हमारे वर्तमान (एकल-नोड झुंड) उपयोग के मामले के लिए कम से कम खराब समाधान सुझा सकते हैं? मैं क्लाइंट आईपी के बिना नहीं कर सकता - इस पर बहुत कुछ निर्भर करता है।

हमारा अस्थायी दृष्टिकोण "वैश्विक" मोड में एक साधारण प्रॉक्सी कंटेनर चलाने के लिए रहा है (जिसे आईआईआरसी वास्तविक एनआईसी का आईपी प्राप्त कर सकता है) और फिर इसे अतिरिक्त प्रॉक्सी हेडर के साथ झुंड ओवरले नेटवर्क पर चल रही आंतरिक सेवा के लिए सभी कनेक्शन अग्रेषित करें।

यदि आपके लिए एक्स-फ़ॉरवर्ड-हेडर प्राप्त करना पर्याप्त है, तो उस सेटअप को AFAICT काम करना चाहिए।

धन्यवाद, @maximelb। आप किसके साथ जा रहे थे (उदाहरण के लिए, nginx, haproxy)?

@jamiejackson वह जगह है जहाँ चीजें थोड़ी अलग होंगी। हमारे मामले में हम एक सर्वर चला रहे हैं जो लंबे समय से चलने वाले एसएसएल कनेक्शन और एक कस्टम बाइनरी प्रोटोकॉल को होस्ट करता है ताकि HTTP प्रॉक्सी संभव न हो। इसलिए हमने एक साधारण टीसीपी फारवर्डर बनाया और एक "msgpack" हेडर का उपयोग किया जिसे हम आंतरिक सर्वर पर मैन्युअल रूप से अनपैक कर सकते थे।

मैं HTTP प्रॉक्सी से बहुत परिचित नहीं हूं लेकिन मुझे संदेह है कि उनमें से अधिकतर आपके लिए चाल चलेंगे। :-/

हाय मैक्सिम,
यह हमारे लिए बहुत दिलचस्प है। क्या आप किसी के द्वारा docker-compose साझा कर सकते हैं
मोका ?

मैं यह समझने की कोशिश कर रहा हूं कि यह कैसे काम करता है। आज हमारे पास एक रिवर्स के रूप में nginx है
प्रॉक्सी (एक सेवा के रूप में) और इसके पीछे कई डॉकटर सेवाएं।

आपके मामले में - क्या nginx "ग्लोबल मोड" प्रॉक्सी बन जाता है? या यह एक है
विशेष टीसीपी फारवर्डर। इसलिए जैसे ही आप नोड्स की संख्या बढ़ाते हैं, प्रॉक्सी फारवर्डर
प्रत्येक नोड पर जाता है। मैंने किसी तरह इस स्थिति में सोचा कि एक्स-फॉरवर्ड किया गया
हेडर खो जाता है .. क्योंकि प्रवेश नेटवर्क बाहरी आईपी को मारता है
(चूंकि कोई प्रॉक्सी-प्रोटोकॉल नहीं है)।

यदि आप कुछ और विवरणों के साथ हमारी सहायता कर सकते हैं तो हम बहुत आभारी होंगे।

सादर
संदीप

बुध, अगस्त ८, २०१८ को सुबह ७:१८ बजे मैक्सिमे लैमोथे-ब्रासर्ड <
सूचनाएं@github.com> ने लिखा:

हमारा अस्थायी दृष्टिकोण एक साधारण प्रॉक्सी कंटेनर को चलाने के लिए रहा है
"वैश्विक" मोड (जिसे IIRC वास्तविक NIC का IP प्राप्त कर सकता है) और फिर इसे प्राप्त करें
झुंड पर चल रही आंतरिक सेवा के सभी कनेक्शन अग्रेषित करें
जोड़े गए प्रॉक्सी हेडर के साथ ओवरले नेटवर्क।

यदि आपके लिए x-फ़ॉरवर्ड-फ़ॉर हेडर प्राप्त करना पर्याप्त है, तो वह सेटअप होना चाहिए
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

रिवर्सप्रॉक्सी (बैकएंड साइड) का लक्ष्य tasks.backendservice (जिसमें प्रत्येक प्रतिकृति के लिए ए रिकॉर्ड है)। यदि बैकएंड सेवा डिफ़ॉल्ट झुंड ओवरले नेटवर्क पर है, तो आप networks भाग को छोड़ सकते हैं।

global बिट कहता है "इस कंटेनर को हर डॉकर झुंड नोड पर बिल्कुल-एक बार तैनात करें। पोर्ट mode: host वह है जो "नोड के मूल एनआईसी से बांधता है"।

आशा है कि इससे सहायता मिलेगी।

आप होस्ट मोड का उपयोग कर रहे हैं। बहुत अधिक आपके पास एक बाहरी लोड बैलेंसर है
पूरी बात के सामने।
आप अब झुंड पर निर्भर नहीं रह सकते क्योंकि आप होस्ट मोड में हैं।

वास्तव में यही वह समस्या है जिसके बारे में हम कुछ समय से बात कर रहे हैं :(

बुधवार को, 8 अगस्त, 2018, 20:47 मैक्सिमे लैमोथे-ब्रासार्ड, <
सूचनाएं@github.com> ने लिखा:

@sandys https://github.com/sandys निश्चित रूप से, यहाँ हमारे से एक अंश है
docker-compose संबंधित कंटेनरों के साथ।

यह रिवर्स प्रॉक्सी डॉकर-कंपोज़ एंट्री है:

रिवर्स प्रॉक्सी:
छवि: yourorg/repo- प्रॉक्सी: नवीनतम
नेटवर्क:
- network_with_backend_service
तैनाती:
मोड: वैश्विक
बंदरगाह:
- लक्ष्य: 443
प्रकाशित: 443
प्रोटोकॉल: टीसीपी
मोड: होस्ट

यह बैकएंड सेवा प्रविष्टि है:

बैकएंडसेवा:
छवि: yourorg/repo- बैकएंड: नवीनतम
नेटवर्क:
- network_with_backend_service
तैनाती:
प्रतिकृतियां: 2

रिवर्सप्रॉक्सी (बैकएंड साइड) का लक्ष्य होगा
task.backendservice (जिसमें प्रत्येक प्रतिकृति के लिए A रिकॉर्ड है)। आप ऐसा कर सकते हैं
यदि बैकएंड सेवा डिफ़ॉल्ट झुंड पर है तो नेटवर्क भाग को छोड़ दें
ओवरले नेटवर्क।

वैश्विक बिट कहता है "इस कंटेनर को हर डॉकटर पर एक बार तैनात करें
झुंड नोड। पोर्ट मोड: होस्ट वह है जो कह रहा है "देशी से जुड़ें"
नोड का एनआईसी"।

आशा है कि इससे सहायता मिलेगी।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-411442155 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU8N7KAFtOp_cPO8wpbBQqzDfpBWOks5uOwEkgaJpZM4Jf2WK
.

आपके मतलब के बारे में 100% निश्चित नहीं है, लेकिन बाहरी रूप से हम प्रति क्लस्टर नोड A रिकॉर्ड के साथ DNS का उपयोग करते हैं। यह बाहरी गतिमान भाग के बिना सस्ता "संतुलन" प्रदान करता है। जब कोई क्लाइंट अनुरोध करता है, तो उन्होंने एक यादृच्छिक ए रिकॉर्ड चुना, और क्लस्टर नोड्स में से एक पर 443 से कनेक्ट किया।

वहां, रिवर्स प्रॉक्सी जो उस विशिष्ट नोड पर चल रहा है और 443 पर सुन रहा है, वास्तविक क्लाइंट आईपी सहित एक मूल कनेक्शन प्राप्त करता है। वह रिवर्स प्रॉक्सी कंटेनर फिर एक हेडर जोड़ता है और झुंड ओवरले नेटवर्क (टास्क.बैकएंड) का उपयोग करके दूसरे आंतरिक कंटेनर से कनेक्शन को आगे बढ़ाता है। चूंकि यह कार्यों का उपयोग करता है। बैकएंड लक्ष्य, इसे आंतरिक सेवा के लिए एक यादृच्छिक ए रिकॉर्ड भी मिलेगा।

तो सख्त अर्थों में, यह ओवरले नेटवर्क के जादू को दरकिनार कर रहा है जो कनेक्शन को पुनर्निर्देशित करता है। इसके बजाय यह इस व्यवहार को रिवर्स प्रॉक्सी के साथ दोहराता है और एक हेडर जोड़ता है। अंतिम प्रभाव ओवरले नेटवर्क के जादू के समान (ढीले अर्थ में) है। यह झुंड को चलाने के समानांतर भी करता है, जिसका अर्थ है कि मैं अपनी सभी अन्य सेवाओं को चला सकता हूं, जिनके लिए क्लाइंट आईपी की आवश्यकता नहीं है, उनके लिए कुछ और किए बिना।

किसी भी तरह से एक सही समाधान नहीं है, लेकिन जब तक कोई फिक्स नहीं किया जाता है (यदि कभी भी) यह आपको बाहरी घटकों या प्रमुख डॉकर कॉन्फ़िगरेशन के बिना प्राप्त करता है।

@jamiejackson "कम से कम खराब" वर्कअराउंड हमने पाया है कि मेजबान मोड में वैश्विक सेवा के रूप में ट्रैफिक का उपयोग कर रहा है। उनके पास उनके दस्तावेज़ों में एक अच्छा
https://github.com/containous/traefik/issues/1880

उम्मीद है ये मदद करेगा। हम ऐसे समाधान का भी उपयोग नहीं कर सकते हैं जो हमें वास्तविक अनुरोधकर्ता आईपी की जांच करने की अनुमति नहीं देता है, इसलिए जब तक कुछ बदल नहीं जाता है तब तक हम इस क्लज फिक्स के साथ फंस गए हैं। कम से कम सुरक्षा कारणों से यह एक बहुत ही सामान्य आवश्यकता की तरह लगता है।

समझा (और इसका एक ढीला संस्करण हम उपयोग करते हैं)।

हालांकि - यह विशेष बग 'एजेंडा देवों से अनुरोध करने के बारे में जाना था
इसे जादुई ओवरले नेटवर्क में बनाने के लिए (शायद प्रॉक्सी का उपयोग करके)
प्रोटोकॉल या अन्य तंत्र)

बुध, 8 अगस्त, 2018, 21:22 मैक्सिम लैमोथे-ब्रासार्ड, < . पर
सूचनाएं@github.com> ने लिखा:

आपके मतलब के बारे में 100% निश्चित नहीं है, लेकिन बाहरी रूप से हम A . के साथ DNS का उपयोग करते हैं
प्रति क्लस्टर नोड रिकॉर्ड। यह बिना किसी नुकसान के सस्ता "संतुलन" प्रदान करता है
बाहरी गतिमान भाग। जब कोई ग्राहक अनुरोध करता है, तो उन्होंने एक यादृच्छिक A . चुना
रिकॉर्ड करें, और क्लस्टर नोड्स में से किसी एक पर 443 से कनेक्ट करें।

वहां, उस विशिष्ट नोड पर चल रहे रिवर्स प्रॉक्सी और
443 पर सुनने से वास्तविक क्लाइंट आईपी सहित एक मूल कनेक्शन मिलता है।
वह रिवर्स प्रॉक्सी कंटेनर फिर एक हेडर जोड़ता है और कनेक्शन को आगे बढ़ाता है
झुंड ओवरले नेटवर्क का उपयोग करके किसी अन्य आंतरिक कंटेनर के लिए
(कार्य। बैकएंड)। चूंकि यह कार्यों का उपयोग करता है। बैकएंड लक्ष्य, इसे भी मिलेगा
यादृच्छिक एक आंतरिक सेवा के लिए एक रिकॉर्ड।

तो सख्त अर्थों में, यह ओवरले नेटवर्क के जादू को दरकिनार कर रहा है कि
कनेक्शन को पुनर्निर्देशित करता है। यह इसके बजाय इस व्यवहार को दोहराता है
रिवर्स प्रॉक्सी और एक हेडर जोड़ता है। अंतिम प्रभाव वही है (में a
लूज सेंस) ओवरले नेटवर्क के जादू के रूप में। में भी करता है
झुंड को चलाने के समानांतर, जिसका अर्थ है कि मैं अपनी अन्य सभी सेवाएँ चला सकता हूँ जो
बिना कुछ किए एक ही क्लस्टर पर क्लाइंट आईपी की आवश्यकता नहीं है
और उन के लिए।

किसी भी तरह से एक सही समाधान नहीं है, लेकिन जब तक कोई फिक्स नहीं किया जाता है (यदि कभी हो) यह हो जाता है
आप बाहरी घटकों या प्रमुख डॉकटर कॉन्फ़िगरेशन के बिना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-411455384 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU5RKjGc3hEk6bk-doicDa1MbYGAyks5uOwlIgaJpZM4Jf2WK
.

टीबीएच मुझे यकीन नहीं है कि आईपी जोड़ने के लिए प्रवेश नेटवर्क को पैच क्यों नहीं किया जा रहा है
प्रॉक्सी प्रोटोकॉल में डेटा।

यह वृद्धिशील है, यह मौजूदा ढेर को नहीं तोड़ेगा, यह एक अच्छी तरह से परिभाषित है
मानक, यह व्यापक रूप से बड़े क्लाउड विक्रेताओं द्वारा भी समर्थित है, यह व्यापक रूप से है
अनुप्रयोग ढांचे द्वारा समर्थित।

क्या यह एक महत्वपूर्ण देव प्रयास है?

बुध, 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 ।
हमने कुछ बग देखे हैं जो इस सेटअप से संबंधित हो सकते हैं या नहीं भी हो सकते हैं, लेकिन
ट्रैफिक एक बेहतरीन प्रोजेक्ट है और यह झुंड पर काफी स्थिर लगता है। वहाँ है
उस पर उनके मुद्दों के पृष्ठ पर संपूर्ण सूत्र (जो यहां वापस लूप करता है :)), साथ
समान उपाय:
कंटेनस/ट्रैफिक#1880
https://github.com/containous/traefik/issues/1880

उम्मीद है ये मदद करेगा। हम ऐसे समाधान का भी उपयोग नहीं कर सकते जो हमें करने की अनुमति नहीं देता
वास्तविक अनुरोधकर्ता आईपी की जांच करें ताकि हम इस कीचड़ फिक्स के साथ तब तक फंसे रहें जब तक
कुछ बदलता है। सुरक्षा कारणों से यह एक बहुत ही सामान्य आवश्यकता की तरह लगता है
कम से कम।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-411458326 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU7NNbsW44L95VYCvlyL_Bje-h6L9ks5uOwsUgaJpZM4Jf2WK
.

खैर, डॉकर वर्तमान में प्रवेश यातायात को नहीं छूता है, इसलिए निश्चित रूप से कम से कम जोड़ने के लिए महत्वहीन नहीं है।
यह भी ध्यान रखें कि यह एक ओपन सोर्स प्रोजेक्ट है, अगर आप वास्तव में कुछ चाहते हैं तो इसे लागू करना आम तौर पर आपके ऊपर होगा।

+1, यह वास्तव में एक शोस्टॉपर है।
मेरा मानना ​​​​है कि अधिकांश अनुप्रयोगों को वास्तविक क्लाइंट आईपी की आवश्यकता होती है। मेलसर्वर स्टैक के बारे में सोचें - आप मनमाने मेजबानों से मेल स्वीकार नहीं कर सकते।

हमने 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_stream और . के लिए पूरे nginx कॉन्फिगर को पास करना संभव होगा?
nginx_proxy उनके झुंड विन्यास के साथ?

यह कमाल है अगर यह काम करता है!

मंगलवार, ११ सितंबर, २०१८ को १७:१४ रूबोट, नोटिफिकेशन @github.com ने लिखा:

हमने प्रॉक्सी_प्रोटोकॉल nginx ग्लोबल स्ट्रीम इंस्टेंस पर स्विच किया, जो है
प्रतिकृति एप्लिकेशन को अग्रेषित करना proxy_nginx. यह काफी अच्छा काम करता है
अभी के लिये।

सेवा वैश्विक nginx_stream

धारा {
रिज़ॉल्वर_टाइमआउट 5s;
# १२७.०.०.११ docker swarms dns सर्वर है
रिज़ॉल्वर 127.0.0.11 वैध = 30s;
# यहां मैप का उपयोग करके स्ट्रीम मॉड्यूल में सेट काम नहीं करता है
नक्शा '' $upstream_endpoint {
डिफ़ॉल्ट प्रॉक्सी_ nginx:443;
}

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

}

सेवा प्रतिकृति nginx_proxy

सर्वर {
443 एसएसएल http2 प्रॉक्सी_प्रोटोकॉल सुनें;
शामिल /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 मुझे प्रॉक्सी प्रोटोकॉल भाग के लिए एक

क्या उनके झुंड विन्यास के साथ nginx_stream और nginx_proxy के लिए पूरे nginx विन्यास को अतीत करना संभव होगा? यह कमाल है अगर यह काम करता है!

@sandys कुछ इस तरह:
https://gist.github.com/rubot/10c79ee0086a8a246eb43ab631f3581f

एक ही मुद्दे में चल रहा है, क्या इसे संबोधित किया जा रहा है? बुनियादी कार्यक्षमता की तरह लगता है जिसे रिलीज के लिए तैयार किया जाना चाहिए।

तैनाती:
मोड: वैश्विक
बंदरगाह:

• लक्ष्य: ४४३ प्रकाशित: ४४३ प्रोटोकॉल: टीसीपी मोड: होस्ट

इस सलाह का पालन करने से समस्या ठीक हो जाती है क्योंकि डॉकर झुंड बैलेंसर अब समीकरण से बाहर हो गया है।
मेरे लिए यह एक वैध समाधान है क्योंकि यह अभी भी हा है और मेरे पास पहले से ही हैप्रोक्सी (डॉकर फ्लो प्रॉक्सी कंटेनर के अंदर) था।
एकमात्र मुद्दा यह है कि हैप्रोक्सी आँकड़े सभी प्रतिकृतियों के बीच वितरित किए जाते हैं, इसलिए पूरे क्लस्टर के लिए ट्रैफ़िक की निगरानी करते समय मुझे उस जानकारी को एकत्र करने के लिए किसी तरह की आवश्यकता होती है। अतीत में मेरे पास सिर्फ एक हैप्रोक्सी उदाहरण है जो डॉकर झुंड बैलेंसर के पीछे था।
चीयर्स,
जैकी

ओपी के अनुरोध ( @PanJ ) को

1. अब हम एक झुंड सेवा बना सकते हैं जो मेजबान आईपी को एक बंदरगाह "प्रकाशित" करती है, प्रवेश रूटिंग परत को छोड़ देती है
2. वही सेवा एक ही समय में ओवरले जैसे अन्य नेटवर्क से जुड़ सकती है, इसलिए यह ओवरले बेनिफिट के साथ अन्य सेवाओं तक पहुंच सकती है

मेरे लिए १८.०९ इंजन के साथ, मुझे परीक्षण में दोनों दुनिया के सर्वश्रेष्ठ मिलते हैं। एक एकल सेवा बैकएंड ओवरले नेटवर्क से जुड़ सकती है और होस्ट एनआईसी पर पोर्ट भी प्रकाशित कर सकती है और होस्ट आईपी पर वास्तविक क्लाइंट आईपी के आने को देख सकती है। मैं ट्रैफिक रिवर्स प्रॉक्सी के साथ बैकएंड सेवाओं के लिए नियत है । मुझे लगता है कि यह "असली आईपी लॉगिंग" के लिए मैंने देखे गए अधिकांश अनुरोधों को हल कर सकता है।

@PanJ क्या यह आपके लिए इसे हल करता है?

कुंजी बंदरगाहों को mode: ingress (डिफ़ॉल्ट) के बजाय mode: host में प्रकाशित करना है।

इस मोड का समर्थक यह है कि आपको वास्तविक क्लाइंट आईपी और देशी होस्ट एनआईसी प्रदर्शन मिलता है (क्योंकि यह आईपीवीएस एनकैपुलेशन AFAIK के बाहर है)। विपक्ष यह है कि यह केवल प्रतिकृतियों को चलाने वाले नोड पर सुनेगा।

मेरे लिए, "मैं प्रवेश आईपीवीएस रूटिंग का उपयोग करना चाहता हूं और क्लाइंट आईपी भी देखना चाहता हूं" का अनुरोध libnetwork का एक अलग फीचर अनुरोध है।

यहाँ क्या बदल गया है? क्योंकि हम ऐसा करने के लिए होस्ट मोड का उपयोग कर रहे हैं
अब एक लंबा समय। वास्तव में यह इस सूत्र में सुझाया गया समाधान है:
कुंआ।

समस्या यह है कि निश्चित रूप से आपको इस सेवा को किसी विशेष पर लॉक करना होगा
होस्ट करें ताकि झुंड इसे कहीं और शेड्यूल न कर सके। क्या था मसला
पूरी तरह से - वह प्रॉक्सी प्रोटोकॉल/आईपीवीएस, आदि इस समस्या को हल करते हैं।

शुक्र, ४ जनवरी, २०१९, ०९:३४ को ब्रेट फिशर < नोटिफिकेशन @github.com ने लिखा:

ओपी के अनुरोध को पढ़ते समय ( @PanJ https://github.com/PanJ ), it
ऐसा लगता है कि वर्तमान सुविधाएँ अब इस समस्या को हल करती हैं, जैसा कि इसके लिए सुझाया गया है
महीने। ओपी ने प्रवेश रूटिंग + क्लाइंट आईपी AFAIK के लिए नहीं कहा, उन्होंने पूछा
प्रतिकृति/वैश्विक क्लाइंट आईपी प्राप्त करने में झुंड सेवा प्राप्त करने के तरीके के लिए,
जो अब साध्य है। सुधार के दो मुख्य क्षेत्र ऐसा होने देते हैं:

1. अब हम एक झुंड सेवा बना सकते हैं जो एक बंदरगाह को "प्रकाशित" करती है
   मेजबान आईपी, प्रवेश रूटिंग परत को छोड़कर
2. वही सेवा अन्य नेटवर्क जैसे ओवरले से अटैच हो सकती है
   उसी समय, इसलिए यह ओवरले बेनिफिट्स के साथ अन्य सेवाओं तक पहुंच सकता है

मेरे लिए १८.०९ इंजन के साथ, मुझे परीक्षण में दोनों दुनिया के सर्वश्रेष्ठ मिलते हैं। ए
एकल सेवा बैकएंड ओवरले नेटवर्क से जुड़ सकती है और प्रकाशित भी कर सकती है
होस्ट एनआईसी पर पोर्ट और होस्ट आईपी पर आने वाले वास्तविक क्लाइंट आईपी को देखें। मैं हूँ
ट्रैफ़िक में क्लाइंट IP ट्रैफ़िक लॉग करने के लिए ट्रैफ़िक रिवर्स प्रॉक्सी के साथ इसका उपयोग करना
जो बैकएंड सेवाओं के लिए नियत है
https://github.com/BretFisher/dogvscat/blob/7e9fe5b998f2cf86951df3f443714beb413d63fb/stack-proxy-global.yml#L75-L83 ।
मुझे लगता है कि यह "वास्तविक लॉगिंग" के लिए देखे गए अधिकांश अनुरोधों को हल कर सकता है
आईपी"।

@PanJ https://github.com/PanJ क्या यह आपके लिए इसे हल करता है?

कुंजी बंदरगाहों को मोड में प्रकाशित करना है: मोड के बजाय होस्ट: प्रवेश (the .)
चूक जाना)।

इस मोड का लाभ यह है कि आपको वास्तविक क्लाइंट आईपी और देशी होस्ट एनआईसी मिलता है
प्रदर्शन (चूंकि यह आईपीवीएस एनकैपुलेशन AFAIK के बाहर है)। कॉन यह है
केवल प्रतिकृतियां चलाने वाले नोड पर सुनेंगे।

मेरे लिए, "मैं प्रवेश आईपीवीएस रूटिंग का उपयोग करना चाहता हूं और यह भी देखना चाहता हूं" का अनुरोध
क्लाइंट आईपी" libnetwork का एक अलग फीचर अनुरोध है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-451348906 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsUzs15UVWOVl54FLwBJSZJKX-9D0jks5u_tLPgaJpZM4Jf2WK
.

@ ब्रेटफिशर mode: host केवल एक समाधान है लेकिन समाधान नहीं है। जैसा कि @sandys ने कहा था कि वर्कअराउंड में कुछ चेतावनी हैं, हमें इस मुद्दे को तय नहीं मानना ​​​​चाहिए।

मुझे यकीन नहीं है कि वर्कअराउंड की खोज के बाद से कोई सुधार हुआ है या नहीं। मैं काफी लंबे समय से कुबेरनेट्स में गया हूं और अभी भी आश्चर्यचकित हूं कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से मेरी
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी पर्याप्त नहीं है
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है। आप या तो
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें जो अवश्य है
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास वही है
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई कर सकता था
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करें, उस झुंड को होना चाहिए
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019, 09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट केवल एक है
समाधान लेकिन समाधान नहीं। @sandys के रूप में https://github.com/sandys
ने कहा कि समाधान में कुछ चेतावनी हैं, हमें इस मुद्दे पर विचार नहीं करना चाहिए
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड होने के बाद से कोई सुधार हुआ है
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और अभी भी हूं
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-451382365 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
.

आप dockerflow प्रोजेक्ट का विस्तार भी कर सकते हैं और शुरू करने के लिए एक nginx संस्करण जोड़ सकते हैं
कुबेरनेट्स-स्वर्ण के लिए प्रवेशप्रॉक्सी। निश्चित रूप से यह सब झुंड से भरा हुआ है
अतिरिक्त सिस्टम कंटेनर उठाएगा जैसा कि आप जानते हैं कि एक गुच्छा है
उन्हें कुबेरनेट्स के साथ। क्या यह स्लिम संसाधन के लिए झुंड की ताकत नहीं है
परियोजनाओं दुबला होना?

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019, 09:48:

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से मेरी
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी पर्याप्त नहीं है
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है। आप या तो
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें जो अवश्य है
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास वही है
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई कर सकता था
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करें, उस झुंड को होना चाहिए
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019, 09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट केवल एक है
समाधान लेकिन समाधान नहीं। @sandys के रूप में https://github.com/sandys
ने कहा कि समाधान में कुछ चेतावनी हैं, हमें इस मुद्दे पर विचार नहीं करना चाहिए
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड होने के बाद से कोई सुधार हुआ है
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और अभी भी हूं
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-451382365 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
.

वे जटिल समाधान हैं - प्रॉक्सी प्रोटोकॉल केवल अतिरिक्त शीर्षलेख जोड़ता है
सूचना और एक बहुत प्रसिद्ध मानक है - हैप्रोक्सी, नेग्नेक्स, एडब्ल्यूएस एल्ब,
आदि सभी इसका पालन करें। https://www.haproxy.com/blog/haproxy/proxy-protocol/

परिवर्तन का सतह क्षेत्र में निर्मित झुंड तक ही सीमित होगा
प्रवेश (जहां यह समर्थन जोड़ा जाएगा)। और सभी सेवाओं में यह होगा
उपलब्ध।

शुक्र, ४ जनवरी, २०१९, १४:३६ रूबोट पर < नोटिफिकेशन @github.com ने लिखा:

आप dockerflow प्रोजेक्ट का विस्तार भी कर सकते हैं और शुरू करने के लिए एक nginx संस्करण जोड़ सकते हैं
कुबेरनेट्स-स्वर्ण के लिए प्रवेशप्रॉक्सी। निश्चित रूप से यह सब झुंड से भरा हुआ है
अतिरिक्त सिस्टम कंटेनर उठाएगा जैसा कि आप जानते हैं कि एक गुच्छा है
उन्हें कुबेरनेट्स के साथ। क्या यह स्लिम संसाधन के लिए झुंड की ताकत नहीं है
परियोजनाओं दुबला होना?

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019, 09:48:

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से मेरी
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी पर्याप्त नहीं है
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है। आप
दोनों में से एक
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें जो अवश्य है
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास वही है
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई कर सकता था
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करें, उस झुंड को होना चाहिए
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019, 09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट केवल एक है
समाधान लेकिन समाधान नहीं। @sandys के रूप में https://github.com/sandys
ने कहा कि समाधान में कुछ चेतावनी हैं, हमें इस पर विचार नहीं करना चाहिए
मुद्दा
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड होने के बाद से कोई सुधार हुआ है
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और अभी भी
होना
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे 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.com schrieb am Fr., 4. जनवरी 2019,
11:37:

वे जटिल समाधान हैं - प्रॉक्सी प्रोटोकॉल केवल अतिरिक्त शीर्षलेख जोड़ता है
सूचना और एक बहुत प्रसिद्ध मानक है - हैप्रोक्सी, नेग्नेक्स, एडब्ल्यूएस एल्ब,
आदि सभी इसका पालन करें। https://www.haproxy.com/blog/haproxy/proxy-protocol/

परिवर्तन का सतह क्षेत्र में निर्मित झुंड तक ही सीमित होगा
प्रवेश (जहां यह समर्थन जोड़ा जाएगा)। और सभी सेवाओं में यह होगा
उपलब्ध।

शुक्र, ४ जनवरी, २०१९, १४:३६ रूबोट पर < नोटिफिकेशन @github.com ने लिखा:

आप dockerflow प्रोजेक्ट का विस्तार भी कर सकते हैं और एक nginx संस्करण जोड़ सकते हैं
प्रारंभ
कुबेरनेट्स-स्वर्ण के लिए प्रवेशप्रॉक्सी। निश्चित रूप से यह सब झुंड से भरा हुआ है
अतिरिक्त सिस्टम कंटेनर उठाएगा जैसा कि आप जानते हैं कि एक गुच्छा है
उन्हें कुबेरनेट्स के साथ। क्या यह स्लिम संसाधन के लिए झुंड की ताकत नहीं है
परियोजनाओं दुबला होना?

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019, 09:48:

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से मेरी
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी पर्याप्त नहीं है
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है। आप
दोनों में से एक
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें जो
अवश्य
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास वही है
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई कर सकता था
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करें, उस झुंड को चाहिए
होना
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019, 09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट केवल एक है
समाधान लेकिन समाधान नहीं। जैसा @sandys <
https://github.com/sandys>
ने कहा कि समाधान में कुछ चेतावनी हैं, हमें इस पर विचार नहीं करना चाहिए
मुद्दा
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड होने के बाद से कोई सुधार हुआ है
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और अभी भी
होना
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे 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.com पर लिखा है:

जैसा कि मैंने कहा, ऊपर टीसीपी स्ट्रीम समाधान की जांच करें, जो पहले से ही प्रॉक्सी का उपयोग करता है
मसविदा बनाना।
प्रॉक्सी प्रोटोकॉल जोड़ने के लिए कंटेनर के अंदर भी कॉन्फ़िगरेशन की आवश्यकता होगी यदि
ऊपर की ओर झुंड में जोड़ा गया। मुझे एक क्लीनर और शायद बेहतर के अलावा कोई मूल्य नहीं दिखता है
आपके अनुरोध में प्रलेखित लक्ष्य

संदीप श्रीनिवास नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019,
11:37:

वे जटिल समाधान हैं - प्रॉक्सी प्रोटोकॉल केवल अतिरिक्त शीर्षलेख जोड़ता है
सूचना और एक बहुत प्रसिद्ध मानक है - हैप्रोक्सी, नेग्नेक्स, एडब्ल्यूएस एल्ब,
आदि सभी इसका पालन करें। https://www.haproxy.com/blog/haproxy/proxy-protocol/

परिवर्तन का सतह क्षेत्र में निर्मित झुंड तक ही सीमित होगा
प्रवेश (जहां यह समर्थन जोड़ा जाएगा)। और सभी सेवाओं में होगा
यह
उपलब्ध।

शुक्र, ४ जनवरी, २०१९, १४:३६ रूबोट पर < नोटिफिकेशन @github.com ने लिखा:

आप dockerflow प्रोजेक्ट का विस्तार भी कर सकते हैं और एक nginx संस्करण जोड़ सकते हैं
प्रारंभ
कुबेरनेट्स-स्वर्ण के लिए प्रवेशप्रॉक्सी। निश्चित रूप से यह सब पैक
झुंड
अतिरिक्त सिस्टम कंटेनर उठाएगा जैसा कि आप जानते हैं कि एक गुच्छा है
का
उन्हें कुबेरनेट्स के साथ। क्या यह स्लिम संसाधन के लिए झुंड की ताकत नहीं है
परियोजनाओं दुबला होना?

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019, 09:48:

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से मेरी
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी नहीं है
पर्याप्त
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है। आप
दोनों में से एक
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें जो
अवश्य
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास है
वैसा ही
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई
सकता है
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करें, उस झुंड को चाहिए
होना
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019, 09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट केवल है
ए
समाधान लेकिन समाधान नहीं। जैसा @sandys <
https://github.com/sandys>
कहा कि वर्कअराउंड में कुछ चेतावनी हैं, हमें विचार नहीं करना चाहिए
यह
मुद्दा
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड के बाद से कोई सुधार हुआ है
गया
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और
फिर भी
होना
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे 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 को होस्ट मोड बाइंडिंग की भी आवश्यकता है, जिसे कहा जाता है
डेमोंसेट बाहरी एलबी नोडपोर्ट से जुड़ता है, जिसके लिए होस्ट मोड की भी आवश्यकता होती है
सेवा में, या सेवा में प्रॉक्सी प्रोटोकॉल को मैन्युअल रूप से कॉन्फ़िगर करें। कुबेरनेट्स
वही समस्याओं से निपटता है, फिर भी।
झुंड के लिए मेरे दृष्टिकोण से एक संभावित सुविधा अनुरोध होगा:
नेटवर्किंग प्रदाता को प्लग करने योग्य बनाएं। इसका उपयोग करना संभव होगा
lvs/iptables के अलावा अन्य तकनीकें

संदीप श्रीनिवास नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019,
13:05:

उपरोक्त समाधान के लिए होस्ट मोड बाइंडिंग की आवश्यकता है। यही बड़ा मुद्दा है। यह
कंटेनर आवंटित करने के लिए डोकर अनुसूचक का उपयोग करने की संभावना को समाप्त करता है
विभिन्न मेजबानों के लिए - मैं अब मेश नेटवर्क का हिस्सा नहीं हूं।

शुक्र, ४ जनवरी, २०१९, १७:२८ रबोट < सूचनाओं @github.com पर लिखा है:

जैसा कि मैंने कहा, ऊपर टीसीपी स्ट्रीम समाधान की जांच करें, जो पहले से ही प्रॉक्सी का उपयोग करता है
मसविदा बनाना।
प्रॉक्सी प्रोटोकॉल जोड़ने के लिए कंटेनर के अंदर भी कॉन्फ़िगरेशन की आवश्यकता होगी
अगर
ऊपर की ओर झुंड में जोड़ा गया। मुझे क्लीनर और शायद के अलावा कोई मूल्य नहीं दिखता
बेहतर
आपके अनुरोध में प्रलेखित लक्ष्य

संदीप श्रीनिवास नोटिफिकेशन @github.com schrieb am Fr., 4 जनवरी।
2019,
11:37:

वे जटिल समाधान हैं - प्रॉक्सी प्रोटोकॉल बस अतिरिक्त जोड़ता है
हैडर
सूचना और एक बहुत प्रसिद्ध मानक है - हैप्रोक्सी, nginx, AWS
एल्ब,
आदि सभी इसका पालन करें।
https://www.haproxy.com/blog/haproxy/proxy-protocol/

परिवर्तन का सतह क्षेत्र में निर्मित झुंड तक ही सीमित होगा
प्रवेश (जहां यह समर्थन जोड़ा जाएगा)। और सभी सेवाओं में होगा
यह
उपलब्ध।

शुक्र, ४ जनवरी, २०१९, १४:३६ रूबोट पर < नोटिफिकेशन @github.com ने लिखा:

आप dockerflow प्रोजेक्ट का विस्तार भी कर सकते हैं और एक nginx संस्करण जोड़ सकते हैं
प्रारंभ
कुबेरनेट्स-स्वर्ण के लिए प्रवेशप्रॉक्सी। निश्चित रूप से यह सब पैक
झुंड
अतिरिक्त सिस्टम कंटेनर उठाएगा जैसा कि आप जानते हैं कि एक गुच्छा है
का
उन्हें कुबेरनेट्स के साथ। क्या यह स्लिम के लिए झुंड की ताकत नहीं है
संसाधन
परियोजनाओं दुबला होना?

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019,
09:48:

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से
मेरे
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी नहीं है
पर्याप्त
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है।
आप
दोनों में से एक
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें
कौन
अवश्य
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास है
वैसा ही
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई
सकता है
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
पाना
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करें, उस झुंड की जरूरत है
प्रति
होना
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019,
09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट is
केवल
ए
समाधान लेकिन समाधान नहीं। जैसा @sandys <
https://github.com/sandys>
कहा कि वर्कअराउंड में कुछ चेतावनी हैं, हमें विचार नहीं करना चाहिए
यह
मुद्दा
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड के बाद से कोई सुधार हुआ है
गया
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और
फिर भी
होना
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे 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
.

और बस स्पष्ट करने के लिए, उपरोक्त समाधान में सेवा के सामने टीसीपी स्ट्रीम है
प्रॉक्सी। तो, आपका अनुरोध निश्चित रूप से एक बग नहीं है, बल्कि एक सुविधा अनुरोध है। और
यह सुविधा केवल झुंड में लागू की जा सकती है, यदि नेटवर्किंग मोड होगा
बदलें, क्योंकि मुख्य समस्या नेट/होस्ट स्तर पर आईपी खोने में बनी हुई है

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019, 13:11:

जैसा कि मैंने कहा, Kubernetes nginx ingress को होस्ट मोड बाइंडिंग की भी आवश्यकता है, जिसे कहा जाता है
डेमोंसेट बाहरी एलबी नोडपोर्ट से जुड़ता है, जिसके लिए होस्ट मोड की भी आवश्यकता होती है
सेवा में, या सेवा में प्रॉक्सी प्रोटोकॉल को मैन्युअल रूप से कॉन्फ़िगर करें। कुबेरनेट्स
वही समस्याओं से निपटता है, फिर भी।
झुंड के लिए मेरे दृष्टिकोण से एक संभावित सुविधा अनुरोध होगा:
नेटवर्किंग प्रदाता को प्लग करने योग्य बनाएं। इसका उपयोग करना संभव होगा
lvs/iptables के अलावा अन्य तकनीकें

संदीप श्रीनिवास नोटिफिकेशन @github.com schrieb am Fr., 4 जनवरी।
2019, 13:05:

उपरोक्त समाधान के लिए होस्ट मोड बाइंडिंग की आवश्यकता है। यही बड़ा मुद्दा है। यह
आवंटित करने के लिए डोकर अनुसूचक का उपयोग करने की संभावना को समाप्त करता है
कंटेनरों
विभिन्न मेजबानों के लिए - मैं अब मेश नेटवर्क का हिस्सा नहीं हूं।

शुक्र, ४ जनवरी, २०१९, १७:२८ रबोट < सूचनाओं @github.com पर लिखा है:

जैसा कि मैंने कहा, ऊपर टीसीपी स्ट्रीम समाधान की जांच करें, जो पहले से ही प्रॉक्सी का उपयोग करता है
मसविदा बनाना।
प्रॉक्सी प्रोटोकॉल जोड़ने के लिए कंटेनर के अंदर भी कॉन्फ़िगरेशन की आवश्यकता होगी
अगर
ऊपर की ओर झुंड में जोड़ा गया। मुझे क्लीनर और शायद के अलावा कोई मूल्य नहीं दिखता
बेहतर
आपके अनुरोध में प्रलेखित लक्ष्य

संदीप श्रीनिवास नोटिफिकेशन @github.com schrieb am Fr., 4 जनवरी।
2019,
11:37:

वे जटिल समाधान हैं - प्रॉक्सी प्रोटोकॉल बस अतिरिक्त जोड़ता है
हैडर
सूचना और एक बहुत प्रसिद्ध मानक है - हैप्रोक्सी, nginx, AWS
एल्ब,
आदि सभी इसका पालन करें।
https://www.haproxy.com/blog/haproxy/proxy-protocol/

परिवर्तन का सतह क्षेत्र में निर्मित झुंड तक ही सीमित होगा
प्रवेश (जहां यह समर्थन जोड़ा जाएगा)। और सभी सेवाएं
पास होना
यह
उपलब्ध।

शुक्र, ४ जनवरी, २०१९, १४:३६ रूबोट पर < नोटिफिकेशन @github.com ने लिखा:

आप dockerflow प्रोजेक्ट का विस्तार भी कर सकते हैं और एक nginx संस्करण जोड़ सकते हैं
प्रारंभ
कुबेरनेट्स-स्वर्ण के लिए प्रवेशप्रॉक्सी। निश्चित रूप से यह सब पैक
झुंड
अतिरिक्त सिस्टम कंटेनर उठाएगा जैसा कि आप जानते हैं कि वहाँ हैं a
झुंड
का
उन्हें कुबेरनेट्स के साथ। क्या यह स्लिम के लिए झुंड की ताकत नहीं है
संसाधन
परियोजनाओं दुबला होना?

रूबेन निकोलाइड्स [email protected] schrieb am Fr., 4. जनवरी 2019,
09:48:

मैं अभी भी हैरान हूं, लोग क्यों सोचते हैं कि यह एक बग है। से
मेरे
परिप्रेक्ष्य यहां तक ​​​​कि कुबेरनेट्स में जाने वाला बयान भी नहीं है
पर्याप्त
उत्तर। जैसा कि मैंने देखा कि कुबेरनेट्स में ठीक वैसी ही समस्या/व्यवहार है।
आप
दोनों में से एक
एक बाहरी LB है, या nginx प्रवेश प्रॉक्सी जैसी किसी चीज़ का उपयोग करें
कौन
अवश्य
डेमोंसेट के रूप में चलाएं। अगर मैं गलत हूं तो कृपया मुझे सुधारें, लेकिन हमारे पास है
वैसा ही
यहां सटीक स्थिति है, लेकिन यहां कोई तैयार ऑटोसॉल्यूशन नहीं है। कोई
सकता है
ऊपर वर्णित मेरे प्रस्तावित टीसीपी स्ट्रीम समाधान की जांच करें और पैक करें
पाना
nginx प्रॉक्सी व्यवहार जैसा कुछ। बस स्वीकार करो, वह झुंड
की आवश्यकता है
होना
अपने आप से अनुकूलित

पंज नोटिफिकेशन @github.com schrieb am Fr., 4. जनवरी 2019,
09:28:

@BretFisher https://github.com/BretFisher मोड: होस्ट is
केवल
ए
समाधान लेकिन समाधान नहीं। जैसा @sandys <
https://github.com/sandys>
कहा कि वर्कअराउंड में कुछ चेतावनी हैं, हमें विचार नहीं करना चाहिए
यह
मुद्दा
तय के रूप में।

मुझे यकीन नहीं है कि वर्कअराउंड के बाद से कोई सुधार हुआ है
गया
खोजा गया। मैं काफी लंबे समय के लिए कुबेरनेट्स चला गया हूं और
फिर भी
होना
आश्चर्य है कि यह मुद्दा अभी भी दो साल से अधिक समय से खुला है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे 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. मुझे ओपी के अनुरोध में आपकी विशिष्ट आवश्यकता नहीं दिख रही है। @PanJ ने क्लाइंट आईपी को बॉक्स से बाहर देखने के लिए कहा, जो कि 2018 के मध्य तक आप कर सकते हैं। मैं उन्हें यह आवश्यक नहीं देखता कि यह प्रवेश मार्ग जाल का भी उपयोग करे।

चाहे आप इसे बग कहें या फीचर अनुरोध, स्रोत नेट के बिना प्रवेश जाल (मेरी राय में) आवश्यक है। ऐसे कई एप्लिकेशन हैं जो तब टूट जाते हैं जब वास्तविक स्रोत आईपी नहीं देख सकता है। निश्चित रूप से, वेब सर्वर के मामले में आप होस्ट नोड का उपयोग करके प्रॉक्सी को उलट सकते हैं और क्लाइंट आईपी हेडर जोड़ सकते हैं। हालांकि, यह ओवरहेड जोड़ता है और संभवत: गैर-वेब-आधारित अनुप्रयोगों के लिए एक विकल्प नहीं है। एक ऐसे एप्लिकेशन के साथ जिसे वास्तव में पैकेट पर वास्तविक स्रोत आईपी की आवश्यकता होती है, एकमात्र विकल्प प्रवेश जाल का उपयोग नहीं करना है। यह पहली जगह में झुंड का उपयोग करने के लाभ का एक बड़ा हिस्सा फेंक देता है।

कृपया हमें बताएं कि यह समस्या कब ठीक हुई है या नहीं?
क्या हमें इसके बजाय कुबेरनेट्स का उपयोग करना चाहिए?

मैं एक ही मुद्दे में भागा... मुझे इस समय कोई समाधान नहीं मिला है।

जब किसी को इस व्यवहार का समाधान मिल जाए, तो कृपया इसकी रिपोर्ट यहां करें।

धन्यवाद!

मेरे साथ भी वही दिक्कत है। मेरे पास एक अपाचे httpd सर्वर है और मैं बाद में आंकड़े निकालने के लिए सभी एक्सेस लॉग करना चाहता हूं कि हम किन देशों से अनुरोध प्राप्त कर रहे हैं।

मैंने यह पता लगाने की कोशिश करते हुए स्वयं इस मुद्दे पर ठोकर खाई कि क्यों php: apache होस्ट हेडर फ़ील्ड को सही तरीके से लॉग नहीं कर रहा था। मैं हैरान और निराश हूं कि इतने वर्षों के बाद भी यह काम नहीं कर रहा है। जब होस्ट फील्ड यूजरलैंड प्रॉक्सी आईपी लॉगिंग करता रहता है तो हमें वेब होस्टिंग के लिए स्वार्म मोड का उपयोग कैसे करना चाहिए? मैं झुंड मोड के साथ इसके आसपास कोई रास्ता नहीं खोज पाया। मुझे लगता है कि मैं क्लासिक झुंड (कंटेनर आधारित) और कॉन्सल जैसे कुछ का उपयोग कर सकता हूं लेकिन मुझे लगता है कि यह पीछे की ओर जा रहा है।

मुझे अपने परिदृश्य के लिए एक स्वीकार्य समाधान मिला:

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

यह अपाचे को ओवरले नेटवर्क (उचित दूरस्थ आईपी पते को पढ़ने) के बजाय होस्ट कंप्यूटर पर सुनने का कारण बनेगा, जबकि अभी भी networks विकल्पों के माध्यम से अन्य सेवाओं के लिए अनुरोध कर रहा है और इसे प्राप्त करके "उच्च उपलब्धता" प्राप्त कर रहा है। हर जगह चल रहा है

@rafaelsierra - यहां मेरे पास यह समस्या है (और अगर मैं गलत हूं तो मुझे सही करें), लेकिन यह कॉन्फ़िगरेशन केवल एक अपाचे/PHP कंटेनर को चलाने और होस्ट नोड पर पोर्ट 80 पर बाध्यकारी होने की अनुमति देता है। मुझे 80/443 पोर्ट के लिए बाध्य एक Nginx कंटेनर के साथ बहुत सारे और बहुत सारे अपाचे कंटेनर चलाने की जरूरत है, और फिर उन्हें vhost करें।

@SysEngDan हाँ, यह सच है कि आपके पास केवल 80/443 पोर्ट के लिए एक ही कंटेनर बाइंडिंग हो सकता है, लेकिन मेरे मामले में यह कोई समस्या नहीं है क्योंकि कंटेनर जो इस पोर्ट से जुड़ता है, केवल अन्य कंटेनरों के लिए सभी अनुरोधों को प्रॉक्सी करने के लिए जिम्मेदार है। जो ओवरले नेटवर्क के पीछे चल रहे हैं।

आप शायद एक ही समाधान का उपयोग कर सकते हैं एक एकल nginx/apache कंटेनर सभी अनुरोध प्राप्त कर रहा है और vhost के आधार पर उचित कंटेनर के लिए प्रॉक्सी कर रहा है, और उन कंटेनरों को होस्ट से बंधने की आवश्यकता नहीं है

@rafaelsierra - समस्या यह है कि क्लाइंट आईपी केवल ओवरले नेटवर्क में सुनने वाले कंटेनरों को पास नहीं किया जाता है। अगर मैं सीधे मेजबान से जुड़ता हूं, कोई मुद्दा नहीं। यदि हम बाहरी (होस्ट) से आंतरिक (ओवरले) के लिए डॉकटर नेटवर्क प्रॉक्सी पर भरोसा करते हैं, तो गंतव्य अपाचे कंटेनर को मूल क्लाइंट आईपी पता नहीं मिलेगा बल्कि इसके बजाय प्रॉक्सी का आईपी (डॉकर नेटवर्किंग से) प्राप्त होगा।

@SysEngDan मैं इस मुद्दे को समझता हूं, और चूंकि पिछले 2 वर्षों से कोई समाधान नहीं है (और मुझे ईमानदारी से यकीन नहीं है कि यह "ठीक करने योग्य" है), मुझे एक वैकल्पिक समाधान के साथ आना पड़ा जो मेरी ज़रूरत के अनुरूप हो (पहुंच को प्रतिबंधित करें) दूरस्थ आईपी पते के आधार पर)।

होस्ट पर पोर्ट 80/443 पर एक एकल कंटेनर सुनने और फिर अन्य कंटेनरों के लिए समीप (उपयुक्त HTTP हेडर के साथ जिसका मैंने उल्लेख नहीं किया क्योंकि इस मुद्दे के दायरे से बाहर है) ने मेरी समस्या का समाधान किया, और मैं इस समाधान को साझा करना चाहता था उन लोगों के लिए जो इसी तरह की समस्या का सामना करते हैं क्योंकि ओवरले नेटवर्क दूरस्थ आईपी पते को पारित करने में सक्षम नहीं हैं

ओह, मैंने देखा कि आपने वहां क्या किया ..... क्षमा करें, मुझे वह याद आया। आपने ओवरले नेटवर्क को काट दिया और इसके बजाय अपने बाहरी फेसिंग कंटेनर को सीधे सर्विस नेटवर्क से जोड़ दिया (जो कि जब आप एक नेटवर्क निर्दिष्ट किए बिना एक नई सेवा शुरू करते हैं तो स्वचालित रूप से बनाया जाता है)। ठीक है, मुझे लगता है कि यह काम करता है। जोड़ा गया ओवरहेड सेवा नेटवर्क को docker-compose फ़ाइल में जोड़ने का कार्य है। मुझे आश्चर्य है कि क्या होता है जब होस्ट-कंटेनर शुरू होता है और उनमें से एक सेवा उपलब्ध नहीं होती है?

उस स्थिति में आपको 502 मिलेगा।

मेरे पास एक एकल docker-compose.yml नहीं है, मेरे पास कई सेवाओं के साथ कई स्टैक हैं जो एक दूसरे से ओवरले नेटवर्क के माध्यम से बात करते हैं, और फिर मेरे पास सार्वजनिक सामना करने वाली सेवा है जो होस्ट सर्वर के लिए बाध्यकारी है लेकिन फिर भी इसकी पहुंच है अन्य सभी ओवरले नेटवर्क ताकि यह सभी अनुरोधों को प्रॉक्सी कर सके।

इस मुद्दे पर होस्ट मोड वर्कअराउंड पर पहले ही कई बार चर्चा की जा चुकी है। हालांकि यह कुछ सीमित परिदृश्यों (जैसे कुछ रिवर्स प्रॉक्सी वेब ट्रैफ़िक सेटअप) के लिए ठीक हो सकता है, यह इस समस्या का सामान्य समाधान नहीं है। कृपया उसी "समाधान" को फिर से हैश करने के बजाय पिछली पोस्ट पढ़ें।

@darrelenns यहां 200 से अधिक टिप्पणियां हैं, मुझे लगता है कि इस मुद्दे को लॉक करना और साफ करना बेहतर होगा, मूल "बस होस्ट बाइंड का उपयोग करें यदि यह आप पर लागू होता है" समाधान प्रदान करता है, जबकि कोई आधिकारिक समाधान प्रदान नहीं किया जाता है, अन्यथा मेरे जैसे अधिक लोग चूक जाएंगे वह और बस एक ही सामान पर बार-बार टिप्पणी करते रहें

इसलिए, मेरा मानना ​​है कि यह बग 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 मुझे नहीं पता कि यह वास्तव में क्या प्रभावित करता है, लेकिन होस्ट मोड में मैं केवल ट्रैफिक सेवा की एक प्रतिकृति चला सकता हूं, और मुझे नहीं लगता कि यह सिर्फ मैं हूं। इस तरह मुझे सेवाओं के लिए झुंड मोड सुविधा पर भरोसा किए बिना पूरी तरह से यातायात स्थिरता पर भरोसा करना होगा।

साथ ही, जैसा कि पहले बताया गया है, इसका ट्रैफिक विशेष जरूरतों से कोई लेना-देना नहीं है, यह एक सामान्य http सेवा के साथ परीक्षण किया गया था जो मूल आईपी प्राप्त नहीं करता है, जिसका अर्थ है कि डॉकर झुंड मोड टूट गया है (यह महत्वपूर्ण विशेषता गायब है), और ऐसा लगता है कि किसी को इसकी परवाह नहीं है।

और मैं इस सामग्री पर टिप्पणी करना चाहता हूं, क्योंकि मुझे आशा है कि शोर किसी को परेशान कर रहा है जो इसे ठीक करना पसंद करेगा :) (क्षमा करें, यह मेरे उपयोगकर्ताओं से मेरे लिए भी लागू होता है)

होस्ट मोड में मैं केवल ट्रैफिक सेवा की एक प्रतिकृति चला सकता हूं, और मुझे नहीं लगता कि यह सिर्फ मैं हूं। इस तरह मुझे सेवाओं के लिए झुंड मोड सुविधा पर भरोसा किए बिना पूरी तरह से यातायात स्थिरता पर भरोसा करना होगा।

आप प्रति होस्ट एक उदाहरण चला सकते हैं

होस्ट मोड में मैं केवल ट्रैफिक सेवा की एक प्रतिकृति चला सकता हूं, और मुझे नहीं लगता कि यह सिर्फ मैं हूं। इस तरह मुझे सेवाओं के लिए झुंड मोड सुविधा पर भरोसा किए बिना पूरी तरह से यातायात स्थिरता पर भरोसा करना होगा।

आप प्रति होस्ट एक उदाहरण चला सकते हैं

हां, लेकिन ट्रैफिक को मैनेजर नोड पर काम करने के लिए मजबूर होना पड़ता है, क्योंकि इसे ठीक से काम करने के लिए इसकी आवश्यकता होती है। तो, एक प्रबंधक नोड, एक मेजबान, एक उदाहरण

ट्रैफ़िक प्रबंधक नोड्स को कई तरीकों से काम कर सकता है, जिसमें a . का उपयोग करना शामिल है
डॉकर सॉकेट प्रॉक्सी, रिमोट सॉकेट, या ट्रैफिक एंटरप्राइज। यहाँ एक है
यह कैसे करना है इसके लिए उदाहरण स्टैक फ़ाइल:
https://github.com/BretFisher/dogvscat/blob/master/stack-proxy-global.yml

शनिवार, 16 मार्च, 2019 को शाम 5:25 बजे डेनियल क्रूसियानी नोटिफिकेशन @github.com
लिखा था:

होस्ट मोड में मैं केवल ट्रैफिक सेवा की एक प्रतिकृति चला सकता हूं, और मैं नहीं करता
सोचो यह सिर्फ मैं हूँ। इस तरह मुझे यातायात स्थिरता पर पूरा भरोसा करना होगा
सेवाओं के लिए झुंड मोड सुविधा पर रिले किए बिना।

आप प्रति होस्ट एक उदाहरण चला सकते हैं

हां, लेकिन ट्रैफिक को प्रबंधक नोड पर काम करने के लिए मजबूर होना पड़ता है, क्योंकि इसे इसकी आवश्यकता है
ठीक से काम करने के लिए। तो, एक प्रबंधक नोड, एक मेजबान, एक उदाहरण

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-473593956 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAwW31DHIwEJE1EqN3-8qj44WopocuQTks5vXWE_gaJpZM4Jf2WK
.

यह जानना दिलचस्प है, लेकिन देखें, यह सुविधा कुबेरनेट्स पर उपलब्ध है, लेकिन डॉकर झुंड मोड में नहीं है, और आप जोर दे रहे हैं कि ट्रैफिक के कई उदाहरण चलाने के विकल्प हैं, लेकिन कई नोड्स में, अगर मैं कई उदाहरण चलाना चाहता हूं एक एकल नोड, यह संभव नहीं है, क्योंकि यह समर्थित नहीं है।
इसके अलावा, कोई भी अन्य सेवा, जो केवल प्रॉक्सी अनुरोधों को नहीं करती है, को किसी भी पोर्ट को मैप करने की अनुमति नहीं है, क्योंकि इसके लिए एक विशेष प्रकार के कॉन्फ़िगरेशन की आवश्यकता होती है, जिसे प्रत्येक होस्ट को मैप करने की आवश्यकता होती है, और वैसे भी इसे कई नोड की आवश्यकता होती है, प्रति उदाहरण कम से कम एक .

और आगे और आगे। आप इस चर्चा को ऊपर स्क्रॉल कर सकते हैं और इसके बारे में अन्य जानकारी प्राप्त कर सकते हैं। मुझे नहीं लगता कि इसे इस बात का प्रदर्शन करने के लिए कम किया जा सकता है कि आप वर्कअराउंड का उत्पादन करने के लिए कितने अच्छे हैं, क्योंकि वे वर्कअराउंड को बनाए रखने के लिए कठिन हैं और उनका पालन करना कठिन है। और विशेष केस वर्कअराउंड को बनाए रखने के लिए बिताया गया सारा समय समस्या को ठीक करने के लिए बेहतर तरीके से खर्च किया जाता है।

दूसरी ओर, यदि इस तरह की सुविधा डॉकर झुंड के मॉडल के लिए एक सुरक्षा समस्या है, तो बस इसे वॉन्टफिक्स के रूप में चिह्नित करें और मैं कुबेरनेट्स पर स्विच करने की योजना बनाऊंगा, अगर ऐसा है, तो मुझे नहीं लगता कि परियोजनाओं के बीच संघर्ष है, यह केवल स्पष्ट रूप से कह रहा है कि ऐसा कभी नहीं होगा, और इसलिए हर कोई कार्रवाई कर सकता है, यदि संभव हो तो किसी भी प्रकार की नोड झुंड चीज़ के लिए डॉकर झुंड मोड की पसंद से पहले

कुबेरनेट्स में बहुत सारी विशेषताएं हैं जो झुंड में नहीं हैं, और इसके विपरीत। सुविधाओं सहित कई कारकों के आधार पर हम सभी निर्णय लेते हैं कि किस ऑर्केस्ट्रेटर को विशिष्ट समाधान के लिए उपयोग करना है। कोई भी उपकरण सभी समस्याओं/आवश्यकताओं को हल नहीं करता है।

मैं सिर्फ एक समुदाय का सदस्य हूं जो मदद करने की कोशिश कर रहा है। यदि आपको इस समस्या का वर्तमान समाधान पसंद नहीं है, तो ऐसा लगता है कि आपको इसे हल करने के अन्य तरीकों को देखना चाहिए, संभवतः कुबेरनेट्स जैसी किसी चीज़ के साथ। यदि आपको लगता है कि कुबेरनेट्स को हल करने का तरीका आपकी पसंद के हिसाब से अधिक है, तो एक ऑर्केस्ट्रेटर को दूसरे पर चुनने का यह एक उचित कारण है।

ऐतिहासिक रूप से, भीड़ और झुंड अनुरक्षक इस तरह के मुद्दों को अभ्यस्त के रूप में बंद नहीं करते हैं क्योंकि कल समुदाय का कोई व्यक्ति इस समस्या के समाधान के साथ एक पीआर छोड़ सकता है। साथ ही, मुझे लगता है कि तब तक इसके आसपास काम करने के तरीकों पर चर्चा करना, इस मुद्दे के धागे का वैध उपयोग है। :)

झुंड मेंटेनर नहीं होने पर, मैं कह सकता हूं कि ऐतिहासिक रूप से टीम भविष्य की फीचर योजनाओं का खुलासा नहीं करती है, जो कि पीआर के वर्तमान में आप रेपो में कमिट करते हुए देख सकते हैं।

मैं यह कहना भूल गया कि निश्चित रूप से आपकी टिप्पणी का स्वागत है (या मैंने इसे अस्पष्ट तरीके से कहा, क्षमा करें)। लेकिन मैं मूल @PanJ रिपोर्ट को सुदृढ़ करना

इस बीच, मुझे लगता है कि मुझे एक वर्कअराउंड करना है जो झुंड मोड के बाहर प्रॉक्सी कंटेनर चला रहा है और इसे स्वार्म मोड में प्रकाशित बंदरगाह पर आगे बढ़ने देता है (एसएसएल समाप्ति इस कंटेनर पर भी की जानी चाहिए), जो झुंड के उद्देश्य को तोड़ देती है स्व-उपचार और आर्केस्ट्रा के लिए मोड।

मेरा मतलब है कि यह "झुंड मोड के उद्देश्य को तोड़ता है", निश्चित रूप से केवल इस विशिष्ट विषय पर, अधिक ध्यान देने योग्य है।

मैं अपनी टीम को एक पीआर बनाने की कोशिश कर रहा हूं जो प्रॉक्सी प्रोटोकॉल को जोड़ता है
प्रवेश नेटवर्क। हम गोलंग प्रोग्रामर नहीं हैं, इसलिए हम इसे थोड़ा पाते हैं
मुश्किल।

लेकिन मुझे उम्मीद है कि डॉकर टीम इस बात से सहमत होगी कि सबसे अच्छा और सबसे अच्छा
संगत (पारिस्थितिकी तंत्र में) समाधान प्रॉक्सी प्रोटोकॉल पर परत करना है
प्रवेश नेटवर्क के लिए समर्थन।

जटिलता इस तथ्य में आती है कि प्रवेश नेटवर्क को न केवल करना है
अपने स्वयं के शीर्षलेख इंजेक्ट करें, लेकिन इसे इस तथ्य का समर्थन करना होगा कि हो सकता है
अपस्ट्रीम प्रॉक्सी प्रोटोकॉल हेडर पहले ही डाले जा चुके हैं (उदाहरण के लिए Google LB या
एडब्ल्यूएस ईएलबी)।

सूर्य पर, 17 मार्च, 2019, 12:17 डेनियल क्रूसियानी, सूचनाएं @github.com
लिखा था:

मैं यह कहना भूल गया कि निश्चित रूप से आपकी टिप्पणी का स्वागत है (या मैंने इसे a . में कहा था)
अस्पष्ट तरीका, क्षमा करें)। लेकिन मैं मूल @PanJ . को मजबूत करना पसंद करता हूं
https://github.com/PanJ रिपोर्ट:

इस बीच, मुझे लगता है कि मुझे एक वर्कअराउंड करना है जो चल रहा है
झुंड मोड के बाहर प्रॉक्सी कंटेनर और इसे प्रकाशित पोर्ट पर अग्रेषित करें
झुंड मोड में (एसएसएल समाप्ति इस कंटेनर पर भी की जानी चाहिए), जो
स्व-उपचार और ऑर्केस्ट्रेशन के लिए झुंड मोड के उद्देश्य को तोड़ता है।

मेरा मतलब है कि यह "झुंड मोड के उद्देश्य को तोड़ता है", निश्चित रूप से केवल इस पर
विशिष्ट विषय, अधिक ध्यान देने योग्य है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे 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 के लिए कहा गया है, जहां यह स्तरित है, पूरी तरह से और विन्यास योग्य है

किसी के लिए भी docker झुंड के साथ digitalocean पर nginx चला रहा है और अपने nginx लॉग के भीतर केवल 10.255.0.2 के बजाय वास्तविक $remote_addr प्राप्त करने का प्रयास कर रहा है; आप @coltenkrauter से समाधान का उपयोग कर सकते हैं। पकड़ यह है कि आप इस समाधान के साथ होस्ट पर केवल एक nginx कंटेनर चला सकते हैं, जो कि अधिकांश लोगों के लिए ठीक होना चाहिए।

बस अपनी 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 ) एक समाधान नहीं है, जब समस्या बताती है कि समस्या नेटवर्किंग के साथ होती है।
कोई भी केवल एक होस्ट को रिवर्स-प्रॉक्सी के रूप में उपयोग नहीं करेगा। आप एक फ़्लोटिंग आईपी के साथ कई होस्ट चाहते हैं, और इस सेटअप को प्राप्त करने के लिए झुंड-जाल अनिवार्य है।

शायद यह संभव नहीं है, लेकिन मैंने सोचा, MASQUERADE करने के लिए iptables नियमों को संशोधित करना INGRESS श्रृंखलाओं में किसी स्तर पर एक समाधान होगा, इसलिए यह वास्तविक स्रोत आईपी को संरक्षित करता है। क्या कुछ 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            

एक विकल्प के रूप में, झुंड सिर्फ मूल स्रोत आईपी नहीं ले सकता है और X-Forwarded-For हैडर बना सकता है?

कोई भी केवल एक होस्ट को रिवर्स-प्रॉक्सी के रूप में उपयोग नहीं करेगा। आप एक फ़्लोटिंग आईपी के साथ कई होस्ट चाहते हैं, और इस सेटअप को प्राप्त करने के लिए झुंड-जाल अनिवार्य है।

झुंड में प्रत्येक नोड रिवर्स-प्रॉक्सी का एक उदाहरण चला सकता है, और ओवरले नेटवर्क पर अंतर्निहित सेवाओं के लिए ट्रैफ़िक को रूट कर सकता है (लेकिन केवल प्रॉक्सी को मूल आईपी-पते के बारे में पता होगा)।

पूरे धागे को पढ़ना सुनिश्चित करें (मुझे लगता है कि गिटहब कुछ उपयोगी टिप्पणियों को छुपाता है, इसलिए आपको उनको विस्तारित करना होगा: निराश:);

एक विकल्प के रूप में, झुंड सिर्फ मूल स्रोत आईपी नहीं ले सकता है और X-Forwarded-For हैडर बना सकता है?

देखें https://github.com/moby/moby/issues/25526#issuecomment -367642600; X-Forwarded-For L7 प्रोटोकॉल है; डीएनएटी के साथ आईपीवीएस का उपयोग करते हुए झुंड प्रवेश एल 4 है

@ port22 आम तौर पर हम सहमत हैं कि एक समाधान समाधान नहीं है, एक समाधान इसे परतदार बनाने के लिए है, देखें # 25526 टिप्पणी पर प्रस्ताव

एक विकल्प के रूप में, झुंड सिर्फ मूल स्रोत आईपी नहीं ले सकता और बना सकता है

एक एक्स-अग्रेषित-शीर्षलेख के लिए?
#25526 देखें (टिप्पणी)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ;
X-Forwarded-For is L7 प्रोटोकॉल; डीएनएटी के साथ आईपीवीएस का उपयोग करते हुए झुंड प्रवेश एल 4 है

यहाँ सही समाधान L4 पर इंजेक्ट किया गया प्रॉक्सी प्रोटोकॉल है। कुछ हैं
एक ही उपयोग के मामले में दूत में प्रासंगिक पक्ष और विपक्ष चर्चा
https://github.com/envoyproxy/envoy/issues/4128 और
https://github.com/envoyproxy/envoy/issues/1031

बुधवार को, अप्रैल १०, २०१ ९ को १:४० पूर्वाह्न सेबस्टियन वैन स्टिजन <
सूचनाएं@github.com> ने लिखा:

कोई भी केवल एक होस्ट को रिवर्स-प्रॉक्सी के रूप में उपयोग नहीं करेगा। आप एकाधिक चाहते हैं
एक अस्थायी आईपी के साथ मेजबान, और इसे प्राप्त करने के लिए झुंड-जाल अनिवार्य है
सेट अप।

झुंड में प्रत्येक नोड रिवर्स-प्रॉक्सी का एक उदाहरण चला सकता है, और मार्ग
ओवरले नेटवर्क पर अंतर्निहित सेवाओं के लिए ट्रैफ़िक (लेकिन केवल
प्रॉक्सी को मूल आईपी-पते के बारे में पता चल जाएगा)।

पूरे धागे को पढ़ना सुनिश्चित करें (मुझे लगता है कि गिटहब कुछ उपयोगी छुपाता है
टिप्पणियाँ, इसलिए आपको उन का विस्तार करना होगा);

एक विकल्प के रूप में, झुंड सिर्फ मूल स्रोत आईपी नहीं ले सकता और बना सकता है
एक एक्स-फ़ॉरवर्ड-हेडर के लिए?

#25526 देखें (टिप्पणी)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ;
X-Forwarded-For is L7 प्रोटोकॉल; डीएनएटी के साथ आईपीवीएस का उपयोग करते हुए झुंड प्रवेश एल 4 है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-481415217 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsU5KdnWQ21hJx_xzc-QROJiWbAlulks5vfPOigaJpZM4Jf2WK
.

झुंड में प्रत्येक नोड रिवर्स-प्रॉक्सी का एक उदाहरण चला सकता है

यह झुंड लोड बैलेंसर की सुविधा को समाप्त करता है, जो कि वास्तव में समस्या है।
और विशिष्ट होने के लिए मेरी समस्या यह है कि ट्रैफ़िक क्लस्टर-फुर्तीली नहीं है। इसे तब तक स्टैंडअलोन चलाया जाना चाहिए जब तक कि आप कॉन्सल को कॉन्फ़िगरेशन बैकएंड के रूप में उपयोग नहीं कर रहे हैं, जो तब अधिकतम प्रमाणपत्रों को ~ 100 तक सीमित कर देता है जो मेरे लिए लागू नहीं है। ज़रूर, आप कह सकते हैं कि यह झुंड की समस्या नहीं है, बल्कि ट्रैफ़िक की समस्या है। मजेदार तथ्य: ट्रैफिक कहता है कि यह एक कौंसल समस्या है। कौंसल कहता है: ट्रैफिक गलत करता है।

@ port22 आम तौर पर हम सहमत हैं कि समाधान समाधान नहीं है

मेरा मुद्दा यह है कि जब आप प्रवेश की आवश्यकता होती है तो प्रवेश का उपयोग नहीं करना एक कामकाज नहीं है। वर्कअराउंड कुछ ऐसा होगा जो स्रोत आईपी को बनाए रखते हुए अभी भी झुंड लोडबैलेंसर का उपयोग करना संभव बना देगा, भले ही उसे कुछ हैकिंग की आवश्यकता हो।

DNAT के साथ IPVS का उपयोग करना

इस प्रकार मैं सोच रहा था कि यह DNAT नियम/श्रृंखला के भीतर MASQUERADE के साथ किया जा सकता है। ?

@ पोर्ट 22 मुझे आपकी बात समझ में आ गई, लेकिन
हो सकता है कि ब्रिज नेटवर्क के लिए विकल्प हों जैसे https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
इसलिए इसे सेटअप करना आसान बनाने के लिए, लेकिन फिर भी मुख्य समस्या ओवरले नेटवर्क में अनुपलब्ध समर्थन है। तो विकल्प नहीं हैं, क्योंकि उन्हें अनदेखा कर दिया जाएगा, और अगर बाहर से संशोधित किया गया तो डॉकर्ड नियमों को फिर से लिख देगा।

मैंने इसे हल करने के लिए प्रॉक्सी प्रोटोकॉल समर्थन के लिए एक सुविधा अनुरोध दायर किया है
इस बग में मुद्दा।

बस अगर कोई अपनी टिप्पणी जोड़ना चाहता है।

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

बुधवार को, १० अप्रैल, २०१९, २१:३७ डेनियल क्रूसियानी, नोटिफिकेशन @github.com
लिखा था:

@port22 https://github.com/port22 मुझे आपकी बात समझ में आ गई, लेकिन docker प्रबंधन
इसके नेटवर्क अपने आप में, मैंने इसे शोरवेल के साथ काम करने की कोशिश की, लेकिन
डोकर नियमों/श्रृंखलाओं के लिए अपवाद बनाने का एकमात्र तरीका है, और मेरे पास नहीं था
डॉकर झुंड मोड के साथ सफलता (लेकिन झुंड मोड में डॉकर के लिए यह ठीक है, जैसे
अब तक मैं सभी सेवाओं को अक्षम कर देता हूं लेकिन झुंड में चलने वाले)
शायद वहाँ विकल्प होना चाहिए जैसे ब्रिज नेटवर्क के लिए हैं
https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
तो इसे सेटअप करना आसान बनाने के लिए, लेकिन फिर भी मुख्य समस्या है
ओवरले नेटवर्क में लापता समर्थन। तो विकल्प नहीं हैं, क्योंकि
उन पर ध्यान नहीं दिया जाएगा, और यदि संशोधित किया गया तो डॉकर्ड नियमों को फिर से लिख देगा
बाहर।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526#issuecomment-481754635 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAEsUxsVQ7m9uiYbHhNKMMtkhTZV6iTNks5vfgwygaJpZM4Jf2WK
.

3 साल बाद कोई फिक्स नहीं?

मुझे भी यही समस्या हो रही है लेकिन हैप्रोक्सी के साथ। यद्यपि होस्ट मोड में प्रॉक्सी सर्वर रखना ठीक है और एचए को बनाए रखने का उपयोग करके, केवल लापता हिस्सा लोड संतुलन होगा जो मुझे लगता है कि एक साधारण वेब प्रॉक्सी के लिए कोई समस्या नहीं है। जब तक जटिल लिपियों को शामिल नहीं किया जाता है या प्रॉक्सी और बैकएंड एक ही भौतिक मशीन पर नहीं होते हैं और एक एनआईसी के लिए नेटवर्क ट्रैफ़िक बहुत अधिक होता है और ...

तो क्या आंतरिक ओवरले नेटवर्क निजी पते के बजाय डॉकर झुंड के बाहर से अनुरोध के स्रोत आईपी पते को देखना वास्तव में संभव नहीं है? फिर भी?

@thaJeztah क्या डॉकर इंक टीम में कोई हमें इस मुद्दे की स्थिति पर अपडेट कर सकता है। क्या इस पर अभी भी विचार किया जा रहा है और/या इस पर काम किया जा रहा है? कोई ईटीए? या कुबेरनेट्स के साथ डॉकर एकीकरण के बाद से इसे पूरी तरह से नजरअंदाज कर दिया गया है? यह लगभग 3 साल पहले बताया गया है: /

@thaJeztah https://github.com/thaJeztah क्या डॉकर इंक पर कोई कर सकता है?
टीम हमें इस मुद्दे की स्थिति पर अपडेट करती है। क्या अभी भी इस पर विचार किया जा रहा है?
और/या पर काम किया? कोई ईटीए? या डॉकर के बाद से इसे पूरी तरह से नजरअंदाज कर दिया गया है
कुबेरनेट्स के साथ एकीकरण? यह लगभग 3 साल पहले बताया गया है: /

यह कथन प्राप्त करना वास्तव में अच्छा होगा ("ठीक नहीं होगा") ताकि मैं पूरी तरह से कर सकूं
कुबेरनेट्स में प्रवास का औचित्य। कितनी शर्म की बात है।

धन्यवाद।

>

शायद वे ट्विटर पर जवाब देंगे?

https://twitter.com/suretec/status/1160496779386904576?s=19

एक प्रस्तावित वृद्धि अनुरोध है जिसे इसे ठीक करना चाहिए - https://github.com/moby/moby/issues/39465

कृपया अपने विचार और टिप्पणियां वहां जोड़ें

मैं पहले से ही उस मुद्दे पर टिप्पणी कर रहा हूं :-)

यह मेरे लिए कुछ समय के लिए अवरोधक रहा है। मुझे आईपी पते से गुजरने की जरूरत है और बहुत खोज के बाद (वाह इस धागे में दूसरों के साथ लगभग 3 साल की खोज के बाद ...) अभी तक कोई समाधान नहीं मिला है जो झुंड के साथ काम करने योग्य है।

मैं इस मुद्दे के कारण उत्पादन में झुंड का उपयोग करने में असमर्थ रहा हूं और आधिकारिक उत्तर की प्रतीक्षा कर रहा हूं कि इसे जोड़ा जा सकता है या नहीं। यदि इसे जोड़ा नहीं जा रहा है तो वैकल्पिक प्रस्तावित समाधानों का स्वागत किया जाता है।

हम एक ही मुद्दे में haproxy के पीछे traefik का उपयोग कर रहे हैं। मुझे यह देखकर आश्चर्य हुआ कि 2016 से अब तक इसमें 254 टिप्पणियाँ हैं।

@Betriebsrat ट्रैफ़िक हैंडल अनुरोधों को तुरंत अनुमति क्यों नहीं दे रहे हैं? क्या हैप्रोक्सी वास्तव में जरूरी है, या सिर्फ एक आदत है? यदि आप होस्ट मोड में ट्रैफ़िक का पर्दाफाश करते हैं, तो आप क्लाइंट आईपी पते देखेंगे, और फिर सब कुछ ठीक है :)

मेरा मानना ​​​​है कि इस "समाधान" का कई बार उल्लेख किया गया था, लेकिन लोग इसे याद करते रहते हैं।

मैं यह भी जानता हूं कि कभी-कभी यह कोई विकल्प नहीं होता, लेकिन मेरा मानना ​​है कि ज्यादातर समय यह संभव होना चाहिए।

@ajardan उस समाधान की मैंने कोशिश की है और मेरे लिए व्यवहार्य नहीं है क्योंकि मैं एक से अधिक मेजबानों को फ्रंटएंड पर प्रतिक्रिया देने के लिए करता हूं। आदर्श रूप से मैं चाहता हूं कि पूरा झुंड अनुरोधों को रूट करने में सक्षम हो। मैं सहमत हूं कि छोटे पैमाने के संचालन के लिए केवल एक सेवा को host मोड में फ़्लिप करना और इसे निगलना सर्वर के रूप में उपयोग करना ठीक काम कर सकता है।

ट्रैफ़िक जैसी किसी चीज़ को होस्ट मोड में रखने से उन लाभों को नकार दिया जाता है जिन्हें हम झुंड का उपयोग करने से लाभ उठाने का प्रयास कर रहे हैं, हालांकि ज्यादातर मामलों में :(

@pattonwebz होस्ट मोड को कई होस्ट पर कई कंटेनर चलाने वाली सेवा के लिए सक्षम किया जा सकता है, आप इसे मोड = ग्लोबल के साथ भी कर सकते हैं। फिर ट्रैफ़िक आपके सभी झुंड नोड्स पर चलेगा और निर्दिष्ट पोर्ट से कनेक्शन स्वीकार करेगा, फिर इन कनेक्शनों को देखने के लिए आवश्यक सेवाओं के लिए आंतरिक रूप से अनुरोधों को रूट करेगा।

मैंने इस सेटअप का उपयोग वैश्विक मोड में एक सेवा के साथ किया लेकिन प्रबंधक नोड्स तक सीमित था, और यह हजारों अनुरोधों के लिए पूरी तरह से ठीक काम कर रहा था।

यदि अधिक विवरण की आवश्यकता है तो मुझे विस्तृत करने में खुशी होगी।

@pattonwebz @ajardan मैं इन सभी मामलों के लिए एक विन्यास योग्य हैप्रोक्सी सेवा का उपयोग कर रहा हूं। मेरे मामले में हैप्रोक्सी सिर्फ 2 एमबी रैम का उपयोग करता है। मुझे लगता है कि यह नगण्य है।

@pattonwebz ऊपर दिए गए @ajardan के समाधान के अलावा, आप https://hub.docker.com/r/decentralize/swarm-tcp-proxy को वैश्विक मोड में होस्ट नेटवर्किंग के साथ चला सकते हैं ताकि आने वाले ट्रैफ़िक में PROXY प्रोटोकॉल समर्थन जोड़ सकें, और फिर इसे प्रॉक्सी प्रोटोकॉल हेडर को डीकोड करने के लिए कॉन्फ़िगर किए गए Traefik पर अग्रेषित करें।

डॉकर झुंड के हिस्से के रूप में यह सिर्फ एक झंडा होना चाहिए, इन सभी को नहीं
जटिल समाधान IMHO।

हम सिर्फ सर्टिफिकेट और ऑफलोड एसएसएल को प्रबंधित करने के लिए हैप्रोक्सी का उपयोग करते हैं।
लोग याद करते रहते हैं कि "रनिंग इज होस्ट मोड" समाधान कोई समाधान नहीं है।
वे चाहते हैं कि यह डॉक लोड संतुलन का लाभ उठाने के लिए प्रवेश नेटवर्क के साथ काम करे।
पूरा धागा मूल रूप से एक 'यूज़ होस्टमोड' -> 'संभव नहीं है क्योंकि "कारण" सर्कल है जो अब 3 साल से चल रहा है।

मैं यहां फिर से एक व्यवहार्य विकल्प के रूप में swarm-tcp-proxy को देखूंगा, हालांकि अतीत में इसी तरह की चीजों को देखते हुए कुछ हमेशा इस तरह के विचारों के साथ मेरे लिए एक सौदा बीकर बन गया।

एक आदर्श दुनिया में मेरा मौजूदा (और वास्तविक क्लाइंट आईपी को पुनः प्राप्त करने की क्षमता के अपवाद के साथ अच्छी तरह से काम करना) झुंड सिर्फ काम कर रहा होगा और बिना किसी अतिरिक्त सेवा परतों या प्रॉक्सी पर अधिक प्रॉक्सी की आवश्यकता के बिना आईपी डेटा से गुजर रहा होगा।

लोग याद करते रहते हैं कि "रनिंग इज होस्ट मोड" समाधान कोई समाधान नहीं है।

यह अपने आप में कोई समाधान नहीं है , लेकिन इसका उपयोग (और उपयोग किया जा रहा है) बहुत सफलतापूर्वक एक समाधान के रूप में किया जा सकता है। आप अभी भी डॉकर के मूल लोड बैलेंसर का उपयोग कर सकते हैं - आप केवल डॉकर के सर्विस मेश को हिट करने से पहले होस्ट नेटवर्क स्टैक में एक परत जोड़ रहे हैं।

@Betriebsrat traefik सर्टिफिकेट और एसएसएल बहुत अच्छी तरह से कर सकता है, इसलिए मुझे अभी भी यकीन नहीं है कि इसकी आवश्यकता क्यों है।

जैसा कि पहले @matthanley द्वारा उल्लेख किया गया है, डॉकर लोड संतुलन दूर नहीं होता है। यदि आपको यह पसंद नहीं है कि ट्रैफ़िक बैकएंड में आपके अनुरोधों को कैसे संतुलित करता है, तो आप इसे झुंड के LB का उपयोग करने का निर्देश दे सकते हैं, और यह केवल सेवा VIP को अनुरोध भेजेगा, जहाँ झुंड बाद में इसका ध्यान रखेगा।

यह प्रति सेवा भी विन्यास योग्य है, इसलिए आप काफी लचीले हैं।

आप docker झुंड क्लस्टर के बाहर एक और Nginx सर्वर सेट करने का प्रयास कर सकते हैं, और झुंड सेवा के लिए अनुरोध अग्रेषित कर सकते हैं। इस Niginx conf में केवल फॉरवर्ड हेडर जोड़ें। उदाहरण के लिए
स्थान / {
प्रॉक्सी_पास 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;

ऐसा लगता है कि डोकर झुंड मोड में वास्तविक क्लाइंट आईपी प्राप्त करने का कोई समाधान नहीं है।

हमने एक ही समस्या देखी और इसे लागू करके इसके आसपास काम किया:
https://github.com/moby/moby/issues/25526#issuecomment -475083415

यह एक गैर-आदर्श समाधान है क्योंकि हम एक ही नोड पर एकाधिक प्रवेश कंटेनर नहीं चला सकते हैं (अनुमान है कि वे अब वैश्विक हैं)

कठिनाई टीसीपी/यूडीपी में डॉकर सौदों की है, जबकि यह एक HTTP प्रोटोकॉल समस्या है। कम से कम मेरी इच्छा है कि डॉकर रिमोट होस्ट के रूप में स्रोत आईपी को "नकली" करेगा, जो इसे झुंड मेष से अपना आंतरिक आईपी दे रहा है ...

प्रत्येक http अनुरोध के लिए मूल आईपी के लिए शीर्षलेख जोड़ने का सबसे आसान तरीका होगा।

सही। बस विशिष्ट होने के लिए - एक प्रॉक्सी प्रोटोकॉल हेडर के रूप में जो l4 पर काम करता है
और l7 और अधिकांश ज्ञात एप्लिकेशन सॉफ़्टवेयर (साथ ही साथ) द्वारा स्वीकार किया जाता है
बड़े क्लाउड प्रदाता)।

मैंने उसके लिए एक अलग बग दायर किया है, जो कुछ टिप्पणियों से जुड़ा हुआ है
ऊपर। यदि आप रुचि रखते हैं तो उस बग में जोड़ें

गुरु, 5 सितं,, 2019, 18:56 व्लादिमीर पर, [email protected] लिखा है:

प्रत्येक के लिए मूल आईपी के लिए शीर्षलेख जोड़ना सबसे आसान तरीका होगा
एचटीटीपी अनुरोध।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/25526?email_source=notifications&email_token=AAASYU7APUNJPLZ6AJ6XXMDQIECIJA5CNFSM4CL7MWFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVW83GOD61260 मुद्दा ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAASYU4VZGKUFLL5STZ44GDQIECIJANCNFSM4CL7MWFA
.

इसका 2019 और यह अभी भी एक मुद्दा है ?? यह ट्रैफिक पर आईपी व्हाइटलिस्टिंग को एक दर्द बना देता है। मुझे प्रत्येक नोड पर होस्ट पोर्ट की आवश्यकता नहीं होनी चाहिए।

@kaysond हमारी स्थिति झुंड को छोड़ने की रही है। हम AWS और ECS की ओर बढ़ रहे हैं। मुझे खेद है कि मैं कुछ और रचनात्मक पोस्ट नहीं कर सकता लेकिन अंततः हमें कुछ ऐसा चाहिए जो काम करे; यह एकमात्र प्रमुख झुंड बग (या सुविधा की कमी) नहीं है जो हमें प्रभावित कर रहा है और अन्य को हाल के वर्षों में कोई स्पष्ट सुधार/प्रतिक्रिया नहीं मिल रही है। सबसे निराशाजनक, लेकिन वहाँ।

@jmkgreen हम एक ही स्थिति में हैं और पिछले 6+ महीनों में डॉकर झुंड से अन्य चीजों में जाने में बिताया है क्योंकि यह समस्या अभी भी चल रही है। मैंने पहले ही दर्जनों घंटे खुद को और टीम के सदस्यों के सैकड़ों घंटों को इसमें बिना किसी स्वीकार्य समाधान के पहले ही लगा दिया है। सभी मेजबान बंदरगाहों से जुड़ना हमारे फ्लोटिंग एलबी के उद्देश्य को पूरी तरह से हरा देता है :(

वर्कअराउंड के साथ आपकी समस्या क्या है? आप होस्ट मोड + ग्लोबल पर अपनी सेवा घोषित करते हैं और सभी नोड्स को मारने के लिए अपना एलबी सेट करते हैं, यह काम करता है। क्योंकि प्रॉक्सी हल्का है (मैं nginx का उपयोग करता हूं क्योंकि मैं https ऑफलोडिंग और अन्य सामान करता हूं), तथ्य यह है कि यह प्रत्येक सर्वर पर तैनात है, यह कोई समस्या नहीं है जो सर्वर संसाधन के 1% से कम का उपयोग करता है। यदि आप प्रक्रिया के दौरान किसी त्रुटि का सामना करते हैं तो मैं आपकी मदद कर सकता हूं ([email protected])।

वर्कअराउंड के साथ आपकी समस्या क्या है? आप होस्ट मोड + ग्लोबल पर अपनी सेवा घोषित करते हैं और सभी नोड्स को मारने के लिए अपना एलबी सेट करते हैं, यह काम करता है।

@RemiBou जब प्रॉक्सी को खुद को अपडेट/पुनरारंभ करने की आवश्यकता होती है, तो बाहरी लोड बैलेंसर तुरंत आउटेज का पता नहीं लगाता है और नोड को अनुरोध भेजता रहता है जहां प्रॉक्सी अभी भी पुनरारंभ हो रहा है। तो बाहरी एलबी कॉन्फ़िगरेशन के आधार पर ~ 30-सेकंड का आउटेज है।

झुंड में बाहरी लोड बैलेंसर को कॉल करने और अद्यतन के दौरान सेवा से बाहर नोड लेने के लिए सेवा अद्यतन प्रक्रिया में एक हुक लगाने का कोई तरीका नहीं है। आप किसी स्क्रिप्ट को अपडेट होने से पहले कंटेनर के अंदर चलाने के लिए ट्रिगर नहीं कर सकते (उदाहरण के लिए, " i_am_healthy " ध्वज को हटाने के लिए और बाहरी एलबी को यह पता लगाने दें कि यह मतदान के माध्यम से सेवा से बाहर जा रहा है)।

वर्कअराउंड के साथ आपकी समस्या क्या है?

मेरी समस्या यह है कि उस समाधान के साथ मेरे लिए मेजबान पर एक ही सेवा (या कई सेवाएं जो एक ही बंदरगाह चाहते हैं) चलाने के लिए असंभव है। मैं जिन परियोजनाओं पर काम करता हूं, उनकी यही जरूरत है।

वास्तव में लेकिन क्या आप एक प्रॉक्सी सेवा को तैनात नहीं कर सकते जो केवल यही करेगी और फिर जब आईपी झुंड के अंदर होगा। आप इसे अपनी अन्य सेवाओं के लिए http शीर्षलेख के रूप में अग्रेषित कर सकते हैं?

वास्तव में लेकिन क्या आप एक प्रॉक्सी सेवा को तैनात नहीं कर सकते जो केवल यही करेगी और फिर जब आईपी झुंड के अंदर होगा। आप इसे अपनी अन्य सेवाओं के लिए http शीर्षलेख के रूप में अग्रेषित कर सकते हैं?

हां... और जब तक उस पतली प्रॉक्सी सेवा को कभी भी पुन: कॉन्फ़िगर या अद्यतन करने की आवश्यकता नहीं होती है, तब तक डाउनटाइम से बचने के लिए झुंड एलबी का उपयोग करके इसके पीछे के घटकों को अपडेट करना संभव है।

किसी ने https://hub.docker.com/r/decentralize/swarm-tcp-proxy पर इशारा किया जो इसे पूरा करने के लिए haproxy का उपयोग करता है।

हालांकि एक तरह का दर्द। और अगर आपको प्रॉक्सी को अपडेट करना है तो आपके पास अभी भी डाउनटाइम है।

@ ms1111 Nginx

वर्कअराउंड के साथ आपकी समस्या क्या है?

हमारे मामले में, यह इस वर्कअराउंड का संयोजन है जिसमें होस्ट-एक्सपोज़्ड पोर्ट को एक विशिष्ट आईपी पते से बाँधने में असमर्थता है। इसके बजाय, सभी आंतरिक सेवाओं के लिए जिन्हें वास्तविक आगंतुक के आईपी और समर्थन प्रॉक्सी प्रोटोकॉल की आवश्यकता होती है, उनके पोर्ट को होस्ट पर 0.0.0.0 पर उजागर किया जाता है जो कि इष्टतम से कम है।

एक और गैर-नगण्य प्रदर्शन हिट है जब आपके पास प्रति सेकंड सैकड़ों नए कनेक्शन होते हैं - सभी उजागर बंदरगाह वास्तव में iptables में डीएनएटी नियम होते हैं जिनके लिए conntrack आवश्यकता होती है और अन्य समस्याएं होती हैं (k8s भी हिट होती है, लेकिन झुंड में यह है NAT का अतिरिक्त स्तर जो इसे बदतर बनाता है)।

डोकर को,

उठो! इस मुद्दे में कितने लोग शामिल हैं, यह देखते हुए एक स्पष्ट समस्या है (इसी कारण से अन्य भी हैं)। हम केवल ऐसे लोग प्राप्त कर रहे हैं जो बार-बार दोहराते हैं कि एक समाधान है, भले ही इसे कई बार समझाया गया है कि यह समाधान समाधान क्यों नहीं है। "वर्कअराउंड" शब्द ही इंगित करता है कि यह एक अस्थायी बात है जिसे बाद में हल किया जाएगा। इस मुद्दे को बनाए हुए 3 साल से अधिक समय हो गया है और उस समय के लिए प्रतिक्रिया "एक समाधान है"।

सभी झुंड उपयोगकर्ताओं के लिए,

आइए यथार्थवादी बनें। दुखद सच्चाई यह है कि डॉकर सहित किसी को भी वास्तव में झुंड की परवाह नहीं है। हर कोई k8s में चला गया और झुंड में कोई "वास्तविक" निवेश नहीं है। परियोजना जीवन-समर्थन पर है और मरने की प्रतीक्षा कर रही है, इसलिए इस समस्या के ठीक होने की अपेक्षा न करें। स्मार्ट बनें और k8s की ओर बढ़ें।

ऐसा लगता है कि इस मुद्दे को बहुत लंबे समय तक नजरअंदाज किया गया है। यह कभी लागू होता नहीं दिख रहा है। बस पीछा करने के लिए काटें और k8s का उपयोग करें।

@leojonathanoh क्या आप कृपया विस्तार से

सरल: प्रॉक्सी प्रोटोकॉल

@ajatkj जैसा कहा गया है। या, यदि यह संभव नहीं है, तो एक बाहरी लोड बैलेंसर और externalTrafficPolicy: Local Service संसाधन पर

लोग क्यों उम्मीद करते हैं कि दूसरे लोग उनके लिए काम करेंगे?

मुझे हीरो बनना और इसका ख्याल रखना अच्छा लगेगा, लेकिन वास्तविकता यह है कि मैं कई अन्य चीजों पर काम कर रहा हूं और इसका मेरे दिन-प्रतिदिन कोई प्रभाव नहीं पड़ता है। क्या यह आपके दिन-प्रतिदिन को प्रभावित करता है? हमें इसे हल करने में कुछ मदद करना अच्छा लगेगा!

मैंने इसे कई बार देखा है और वास्तव में ऐसा नहीं लगता है कि आईपीवीएस एनएटी के साथ यह काम करने का कोई तरीका है, जो कि जादुई झुंड रूटिंग का उपयोग कर रहा है।

मैं मानता हूँ कि k8s यहाँ अधिक लचीला है। अगर यह आपकी आवश्यकताओं के अनुरूप बेहतर है तो इसका इस्तेमाल करें।
शिकायत करना कि यह ठीक नहीं है और फिर k8s पर स्विच करने की धमकी वास्तव में हमारे इश्यू ट्रैकर में कोई जगह नहीं है और यह आम तौर पर अनुपयोगी है।

लोग अपने पास मौजूद ज्ञान से मदद करते हैं। सभी के पास कोड को स्वयं बदलने का कौशल सेट नहीं होता है, इसलिए वे आवश्यक परिवर्तन के बारे में आम सहमति प्राप्त करने में मदद करने के लिए इस तरह के मुद्दे बनाते हैं।

यहां कोई यह तर्क नहीं दे रहा है कि आपको विशेष रूप से परिवर्तन करना है, लेकिन प्रॉक्सी प्रोटोकॉल के बारे में @sandys द्वारा खोले गए मुद्दों पर भी कोर टीम परिवर्तनों पर सहमत नहीं हुई। तो कोई इस पर कैसे काम कर सकता है यदि वे नहीं जानते कि परिवर्तन स्वीकार किया जाएगा या नहीं?

सबसे अच्छा तरीका है एक प्रस्ताव के साथ आना, अर्थात। आप क्या उम्मीद करते हैं कि काम पूरा होने के बाद आर्किटेक्चर कैसा दिखेगा। यह क्या लाता है? हमारे बाप का क्या जाता है?

होस्ट-मोड-नेटवर्किंग का प्रयास

सबसे अच्छा तरीका है एक प्रस्ताव के साथ आना, अर्थात। आप क्या उम्मीद करते हैं कि काम पूरा होने के बाद आर्किटेक्चर कैसा दिखेगा। यह क्या लाता है? हमारे बाप का क्या जाता है?

यहां पहले ही किया जा चुका है: #39465

होस्ट-मोड-नेटवर्किंग का प्रयास करें

कृपया कमेंट करने से पहले पूरा सूत्र पढ़ें

"प्रॉक्सी प्रोटोकॉल का उपयोग करें", जबकि वास्तव में दिलचस्प यह नहीं बताता है कि क्या
कोड बेस में बदलाव करने होंगे।

शायद यह एक भोला सवाल है, लेकिन शुरू करने के लिए स्रोत आईपी को फिर से लिखना क्यों आवश्यक है? क्या इंटरफ़ेस के डिफ़ॉल्ट गेटवे के माध्यम से वैसे भी ट्रैफ़िक वापस नहीं किया जाएगा? भले ही यह झुंड लोड बैलेंसर के माध्यम से आया हो, गेटवे इसे लोड बैलेंसर के माध्यम से वापस कर सकता है जो पहले से ही जानता है कि ट्रैफिक कहां से आया है ...

शायद यह एक भोला सवाल है, लेकिन शुरू करने के लिए स्रोत आईपी को फिर से लिखना क्यों आवश्यक है? क्या इंटरफ़ेस के डिफ़ॉल्ट गेटवे के माध्यम से वैसे भी ट्रैफ़िक वापस नहीं किया जाएगा? भले ही यह झुंड लोड बैलेंसर के माध्यम से आया हो, गेटवे इसे लोड बैलेंसर के माध्यम से वापस कर सकता है जो पहले से ही जानता है कि ट्रैफिक कहां से आया है ...

यह जानना जरूरी है कि किस आईपी से रिक्वेस्ट आ रही है। हो सकता है कि कोई विशिष्ट उपयोगकर्ता आईपी को सीमित करना चाहता हो, और आप इसे चल रही सेवा के बाहर नहीं कर सकते, अर्थात ट्रैफ़िक अनुरोध की सामग्री को नहीं जानता है जो निर्दिष्ट कर सकता है कि कौन सा उपयोगकर्ता इसे बना रहा है, इसलिए यह कुछ उपयोगकर्ता को बाहर नहीं कर सकता है और स्वीकार करता है अन्य केवल आईपी पर आधारित है (क्योंकि इस उदाहरण में नीति आईपी + अनुरोध-सामग्री => अनुमति/अस्वीकार है)।

या, अधिक बार, केवल लॉगिंग कनेक्शन के लिए। मुझे अपने सेवा उपयोग के लिए ग्राहक को बिल करने की आवश्यकता है, और मुझे सारणीबद्ध रूप में प्रदान करने की आवश्यकता है: अनुरोध का समय, संसाधन की मात्रा, अनुरोध का स्रोत आईपी। लगभग हर सेवा का बिल इस तरह की रिपोर्ट प्रदान करता है।

मुझे लगता है कि आपने मेरे प्रश्न को गलत समझा। मैं समझता हूं कि सेवाएं सही स्रोत आईपी क्यों देखना चाहेंगी। मैं जानना चाहता हूं कि कंटेनर में जाने से पहले डॉकर इसे क्यों बदलता है?

1 नवंबर, 2019, 1:47 पूर्वाह्न, 1:47 बजे, डेनियल क्रूसियानी नोटिफिकेशन @github.com ने लिखा:

शायद यह एक भोला सवाल है, लेकिन फिर से लिखना क्यों जरूरी है?
स्रोत आईपी के साथ शुरू करने के लिए? क्या यातायात के माध्यम से वापस नहीं किया जाएगा
इंटरफ़ेस का डिफ़ॉल्ट गेटवे वैसे भी? भले ही यह झुंड भार के माध्यम से आया हो
बैलेंसर, गेटवे इसे लोड बैलेंसर के माध्यम से वापस कर सकता है जो
पहले से ही जानता है कि यातायात कहाँ से आया था ...

यह जानना जरूरी है कि किस आईपी से रिक्वेस्ट आ रही है। शायद एक
विशिष्ट उपयोगकर्ता आईपी को सीमित करना चाहते हैं, और आप इसे बाहरी नहीं कर सकते
सेवा चल रही है, यानी ट्रैफ़िक अनुरोध की सामग्री को नहीं जानता है
यह निर्दिष्ट कर सकता है कि कौन सा उपयोगकर्ता इसे बना रहा है, इसलिए यह कुछ को बाहर नहीं कर सकता है
उपयोगकर्ता और केवल आईपी पर आधारित अन्य स्वीकार करता है (क्योंकि इसमें नीति
उदाहरण आईपी + अनुरोध-सामग्री => अनुमति/अस्वीकार है)।

या, अधिक बार, केवल लॉगिंग कनेक्शन के लिए। मुझे ग्राहक को बिल देना है
मेरे सेवा उपयोग के लिए, और मुझे सारणीबद्ध रूप में प्रदान करने की आवश्यकता है: का समय
अनुरोध, संसाधन की मात्रा, अनुरोध का स्रोत आईपी। लगभग हर सेवा
बिल इस प्रकार की रिपोर्ट प्रदान करते हैं।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/moby/moby/issues/25526#issuecomment -548711563

@kaysond पूछने के लिए अच्छी जगह नहीं है।

आप अनिवार्य रूप से दो प्रश्न पूछ रहे हैं,

1. आईपीवीएस तकनीकी रूप से कैसे काम करता है, और
2. शुरू करने के लिए libnetwork IPVS क्यों चुनें

दोनों का अलग-अलग तरीकों से जवाब देना मुश्किल है।

मुझे आश्चर्य है कि इन प्रश्नों को पूछने के लिए सबसे अच्छी जगह कहाँ है क्योंकि अब मैं उन विकल्पों के इतिहास को पढ़ने के लिए बहुत उत्सुक हूँ और यह सब कैसे काम करता है इसलिए मुझे यहाँ कुछ और संदर्भ मिल सकते हैं।

@kaysond पूछने के लिए अच्छी जगह नहीं है।

आप अनिवार्य रूप से दो प्रश्न पूछ रहे हैं,

1. आईपीवीएस तकनीकी रूप से कैसे काम करता है, और
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

तो नहीं। यह अभी भी काम नहीं करता है

वास्तविक आईपी प्राप्त करने के लिए आप होस्ट मोड द्वारा ट्रैफिक का उपयोग कर सकते हैं

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

अभी भी खुला?
2020-05-08

अभी भी खुला?
2020-05-08

हाँ, अभी भी खुला है। धागे में उल्लिखित वास्तु संबंधी मुद्दे हैं जो इस बात पर प्रकाश डालते हैं कि इसे इतनी आसानी से हल क्यों नहीं किया जा सकता क्योंकि ऐसा लगता है कि यह सतह पर होना चाहिए। इस बिंदु पर यह संभावना है कि उन मुद्दों को दूर नहीं किया जा सकता है।

यदि आपको वास्तविक उपयोगकर्ता आईपी प्राप्त करने की आवश्यकता है तो कुछ विकल्प यहां थ्रेड में पोस्ट किए गए हैं जो उपयुक्त हो सकते हैं। सेवाओं के लिए HOST मोड सबसे सरल तरीका लगता है, लेकिन यह उन लोगों के लिए उपयुक्त नहीं है जिन्हें व्यक्तिगत नोड्स पर मापनीयता की आवश्यकता होती है।

हमें DigitalOcean LB -> Traefik -> Apache कंटेनर के साथ PROXY प्रोटोकॉल का उपयोग करने में सफलता मिली है। अपाचे कंटेनर सेवा को हिट करने वाले उपयोगकर्ताओं के वास्तविक आईपी को लॉग करने में सक्षम था। सैद्धांतिक रूप से तब तक काम करना चाहिए जब तक सभी प्रॉक्सी परतें PROXY प्रोटोकॉल का समर्थन करती हैं।

https://docs.traefik.io/v1.7/configuration/entrypoints/#proxyprotocol

ट्रैफिक सेवा 'इनग्रेड' नाम के एक डॉकर नेटवर्क पर है, अपाचे सेवा का अपना स्टैक नेटवर्क है, लेकिन बाहरी के रूप में 'इनग्रेड' नेटवर्क का भी हिस्सा है।

https://autoize.com/logging-client-ip-addresses-behind-a-proxy-with-docker/

2020 और अभी भी तय नहीं है, क्या खींचतान है। एक बहुत ही महत्वपूर्ण विशेषता की तरह लगता है

यह बहुत जरूरी है। कुछ होस्ट मोड रखो बस एक पैच है, कभी-कभी नेटवर्क के पीछे एनजीआईएनएक्स चलाने के लिए आवश्यक है (उपयोग और सेटअप के आधार पर)। कृपया इसे ठीक करें।

मुझे लगता है कि इसके लिए वर्कअराउंड और होस्ट सेट किए बिना डॉक झुंड चलाना क्लाइंट-साइड पर आईपी प्राप्त करना है। भूतपूर्व। वेब और मोबाइल क्लाइंट के लिए js का उपयोग करना और केवल विश्वसनीय स्रोतों से स्वीकार करना। भूतपूर्व। जेएस -> आईपी प्राप्त करें, बैकएंड केवल आईपी स्वीकार करता है जिसमें उपयोगकर्ता-टोकन या आदि शामिल हैं। आईपी को हेडर में सेट किया जा सकता है और https के माध्यम से एन्क्रिप्ट किया जा सकता है। हालांकि, मैं प्रदर्शन के बारे में नहीं जानता

@ दामिदारा16 ठीक यही हम नहीं करना चाहते हैं। ऐसा करना वास्तव में असुरक्षित है। आप जैसे चाहें इसे बायपास कर सकते हैं।

बुरा के लिए यह अभी भी एक खुला मुद्दा है, दुख की बात है ... ऐसा नहीं लगता कि यह जल्द ही ठीक होने वाला है

बुरा के लिए यह अभी भी एक खुला मुद्दा है, दुख की बात है ... ऐसा नहीं लगता कि यह जल्द ही ठीक होने वाला है

मुझे लगता है कि इसे जल्द ही बॉट द्वारा बंद कर दिया जाएगा। चूंकि जीथब ने इस सुविधा को लॉन्च किया है, इसलिए कई बगों को नजरअंदाज किया जा सकता है।

बुरा के लिए यह अभी भी एक खुला मुद्दा है, दुख की बात है ... ऐसा नहीं लगता कि यह जल्द ही ठीक होने वाला है

मुझे लगता है कि इसे जल्द ही बॉट द्वारा बंद कर दिया जाएगा। चूंकि जीथब ने इस सुविधा को लॉन्च किया है, इसलिए कई बगों को नजरअंदाज किया जा सकता है।

यह उद्यमों की फूली हुई टीमों के लिए समुदाय का नियंत्रण हासिल करने के लिए सबसे अच्छी सुविधा है।

इसके कभी भी ठीक होने की संभावना बहुत कम है। AFAIK हर कोई मानता है कि k8s ने "दौड़" जीती है और झुंड की जरूरत नहीं है, लेकिन मैं कहूंगा कि दोनों सह-अस्तित्व में हो सकते हैं और इनका उपयोग करने वाली टीम की आवश्यकताओं और कौशल के आधार पर ठीक से उपयोग किया जा सकता है। आरआईपी झुंड :)

मैं एक प्रबंधित HAIP का उपयोग करता हूं, लेकिन आप झुंड के सामने कुछ और इस्तेमाल कर सकते हैं, एक स्टैंडअलोन nginx लोड बैलेंसर जो आपके झुंड के आईपी को इंगित करता है।
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', या एक के साथ झुंडों का एक सेट जिसमें प्रत्येक एक नोड होता है।

समस्या

अंतर्निहित समस्या iptables nat तालिका में ingress_sbox नामस्थान में SNAT नियम के कारण होती है, जिसके कारण कंटेनर द्वारा आने वाले सभी अनुरोधों को इनग्रेड नेटवर्क में नोड का 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

हालांकि, इस एसएनएटी नियम को हटाने का मतलब है कि कंटेनर अभी भी आने वाले पैकेट प्राप्त करते हैं - अब मूल स्रोत आईपी से उत्पन्न हो रहे हैं - मूल स्रोत आईपी पर वापस भेजे जाने वाले आउटगोइंग पैकेट कंटेनर के डिफ़ॉल्ट गेटवे के माध्यम से भेजे जाते हैं, जो एक ही प्रवेश नेटवर्क पर नहीं है बल्कि चालू है docker_gwbridge नेटवर्क (जैसे 172.31.0.1), और फिर वे पैकेट खो जाते हैं।

समाधान

तो वर्कअराउंड में शामिल हैं: 1. ingress_sbox नेमस्पेस में इस SNAT नियम को हटाना (वास्तव में, रोकना); और 2. झुंड सेवा कंटेनरों के लिए एक नीति रूटिंग नियम बनाना, जो उन आउटगोइंग पैकेटों को नोड के प्रवेश नेटवर्क आईपी पते पर वापस जाने के लिए मजबूर करता है (उदाहरण के लिए 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

(हम इसे इस तरह से करते हैं, मौजूदा एसएनएटी नियम को हटाने के बजाय, क्योंकि डॉकर सेवा बनाने के दौरान कई बार एसएनएटी नियम को फिर से बनाता है। यह दृष्टिकोण उस नियम को हटा देता है, जो इसे और अधिक लचीला बनाता है)।

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

अब, जब एकल नोड के लिए प्रकाशित पोर्ट पर अनुरोध आते हैं, तो इसके कंटेनर अनुरोध करने वाली मशीन का मूल आईपी पता देखेंगे।

प्रयोग

इसके बाद के संस्करण चलाने के लिए ingress-routing-daemon _each पर रूट _before_ अपने झुंड नोड्स के हर one_ के रूप में। (यदि आपकी सेवा पहले से ही बनाई गई है, तो सुनिश्चित करें कि आप इसे प्रतिकृतियों की एक सकारात्मक संख्या में वापस स्केल करने से पहले इसे 0 पर स्केल करें।) डेमॉन iptables को प्रारंभ करेगा, यह पता लगाएगा कि docker कब नए कंटेनर बनाता है, और प्रत्येक नए कंटेनर पर नए रूटिंग नियम लागू करता है।

परीक्षण, उपयोग के मामले और सीमाएं

एक बहु-नोड झुंड पर चल रही सेवा पर एकल नोड के लिए विवश कई प्रतिकृतियों का उपयोग करके उपरोक्त का परीक्षण किया गया है।

यह कई नोड्स का उपयोग करके भी परीक्षण किया गया है, प्रत्येक एक अलग प्रति-नोड सेवा के साथ उस नोड के लिए विवश है, लेकिन यह इस सीमा के साथ आता है कि प्रत्येक प्रति-नोड सेवा के लिए अलग-अलग प्रकाशित पोर्ट का उपयोग किया जाना चाहिए। फिर भी यह कुछ उपयोग-मामलों के लिए काम कर सकता है।

विधि को कई नोड्स का उपयोग करके भी काम करना चाहिए, यदि प्रत्येक को अपने स्वयं के झुंड में एकल नोड के रूप में कॉन्फ़िगर किया गया हो। यह इस सीमा को वहन करता है कि डॉकटर स्वार का उपयोग अब कंटेनरों को नोड्स में वितरित करने के लिए नहीं किया जा सकता है, हालांकि डॉकटर सेवाओं का उपयोग करने के अन्य प्रशासनिक लाभ भी हो सकते हैं, जैसे कंटेनर प्रतिकृति और जीवनचक्र प्रबंधन।

आगे के उपयोग के मामलों को संबोधित करने के लिए समाधान में सुधार

आगे के विकास के साथ, यह विधि अलग-अलग प्रति-नोड सेवाओं की आवश्यकता के बिना या झुंड को विभाजित किए बिना कई नोड्स तक स्केल करने में सक्षम होनी चाहिए। मैं दो संभावित दृष्टिकोणों के बारे में सोच सकता हूं: 1. प्रत्येक नोड की ipvsadm तालिका से सभी गैर-स्थानीय आईपी को हटाने के लिए डॉकर, या एक बीस्पोक डेमॉन की व्यवस्था करना। 2. रूटिंग आउटपुट पैकेज को सही नोड पर वापस समायोजित करने के लिए नीति रूटिंग नियमों का विस्तार करना।

1 के लिए, हम किसी भी सेवा में जोड़े गए नए IP देखने के लिए ipvsadm -S -n मतदान कर सकते हैं, जांच सकते हैं कि प्रत्येक स्थानीय है या नहीं, और जो नहीं हैं उन्हें हटा दें। यह प्रत्येक नोड को समग्र सेवा के भीतर अपने स्वयं के कंटेनरों के लिए लोड बैलेंसर के रूप में कार्य करने की अनुमति देगा, लेकिन एक नोड तक पहुंचने के अनुरोध के बिना दूसरे को अग्रेषित किया जा सकता है। यह निश्चित रूप से मेरे अपने उपयोग-मामले को संतुष्ट करेगा, जहां हमारे पास सर्वरों के एक सेट के सामने अपना स्वयं का आईपीवीएस लोड बैलेंसर बैठा है, प्रत्येक एक वेब एप्लिकेशन चला रहा है, जिसे हम एक ही एप्लिकेशन के कई लोड-संतुलित कंटेनरीकृत उदाहरणों के साथ बदलना चाहते हैं। , हमें संपूर्ण सर्वर खोए बिना अपडेट रोल आउट करने की अनुमति देने के लिए।

2 के लिए, हम प्रत्येक नोड के ingress_sbox iptable में प्रति-नोड TOS असाइन करने के लिए iptables का उपयोग कर सकते हैं (उदाहरण के लिए नोड प्रवेश नेटवर्क IP के अंतिम बाइट के लिए); फिर कंटेनर में, टीओएस मान को कनेक्शन चिह्न पर मैप करने की व्यवस्था करें, और फिर कनेक्शन चिह्न से आउटगोइंग पैकेट के लिए फ़ायरवॉल चिह्न पर, और प्रत्येक फ़ायरवॉल चिह्न के लिए एक अलग रूटिंग तालिका चुनें जो पैकेट को मूल नोड पर वापस ले जाती है। इसके लिए नियम थोड़े भद्दे होंगे, लेकिन मुझे लगता है कि 2-16 नोड्स को ठीक करना चाहिए।

मुझे आशा है कि उपरोक्त उपयोगी होगा। मुझे (2) पर भी जाना होगा, और अगर मैं प्रगति करता हूं तो एक और अपडेट पोस्ट करूंगा।

नीचे प्रवेश रूटिंग डेमॉन का एक उन्नत संस्करण है, ingress-routing-daemon-v2 , जो नीति रूटिंग नियम मॉडल का विस्तार करता है ताकि प्रत्येक कंटेनर एसएनएटी की आवश्यकता के बिना अपने आउटपुट पैकेट को सही नोड पर वापस भेज सके।

बेहतर मॉडल

पिछले मॉडल के अनुसार SNAT नियम को बाधित करने के अलावा, नए मॉडल को प्रत्येक नोड पर ingress_sbox नेमस्पेस में एक iptables नियम की आवश्यकता होती है जिसे आप IPVS लोड-बैलेंसर एंडपॉइंट के रूप में उपयोग करना चाहते हैं (इसलिए आमतौर पर आपके प्रबंधक नोड्स, या उनमें से एक सबसेट) प्रबंधक नोड्स), जो प्रवेश नेटवर्क में किसी भी नोड के लिए नियत सभी पैकेटों को प्रति-नोड टीओएस मान प्रदान करता है। (हम नोड के प्रवेश नेटवर्क आईपी के अंतिम बाइट का उपयोग करते हैं।)

चूंकि टीओएस मान पैकेट के भीतर संग्रहीत किया जाता है, इसे गंतव्य नोड द्वारा पढ़ा जा सकता है जिस पर आने वाले अनुरोध को निर्देशित किया गया है, और पैकेट भेजा गया है।

फिर गंतव्य नोड पर कंटेनर में, हम किसी भी आने वाले पैकेट पर TOS मान को समान मान का उपयोग करके कनेक्शन चिह्न पर मैप करने की व्यवस्था करते हैं।

अब, चूंकि एक ही कनेक्शन पर आउटगोइंग पैकेट में एक ही कनेक्शन चिह्न होगा, हम किसी भी आउटगोइंग पैकेट पर कनेक्शन चिह्न को फ़ायरवॉल चिह्न पर मैप करते हैं, फिर से उसी मान का उपयोग करते हुए।

अंत में, नीति रूटिंग नियमों का एक सेट एक अलग रूटिंग टेबल का चयन करता है, जिसे आउटगोइंग पैकेट्स को फ़ायरवॉल मार्क वैल्यू के अनुसार आवश्यक लोड-बैलेंसर एंडपॉइंट नोड पर वापस रूट करने के लिए डिज़ाइन किया गया है।

अब, जब क्लाइंट अनुरोध झुंड में किसी भी नोड के लिए प्रकाशित पोर्ट पर पहुंचते हैं, तो कंटेनर (चाहे उसी और/या अन्य नोड्स पर) जिस पर अनुरोध निर्देशित किया जाता है, क्लाइंट का मूल आईपी पता अनुरोध करने वाला दिखाई देगा, और प्रतिक्रिया को मूल लोड-बैलेंसर नोड पर वापस भेजने में सक्षम हो; जो बदले में, ग्राहक को प्रतिक्रिया वापस भेजने में सक्षम होगा।

प्रयोग

की स्थापना

अपने झुंड के प्रत्येक नोड पर ingress-routing-daemon-v2 को रूट के रूप में चलाकर, अपने झुंड के लिए विशिष्ट INGRESS_NODE_GATEWAY_IPS लिए एक मान उत्पन्न करें _जिसे आप लोड-बैलेंसर एंडपॉइंट के रूप में उपयोग करना चाहते हैं_ (आमतौर पर केवल आपका प्रबंधक नोड्स, या आपके प्रबंधक नोड्स का एक सबसेट), 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 _each पर रूट _before_ अपने झुंड के नोड्स (प्रबंधकों और श्रमिकों) के हर one_ के रूप में। (यदि आपकी सेवा पहले से ही बनाई गई है, तो सुनिश्चित करें कि आप इसे प्रतिकृतियों की एक सकारात्मक संख्या में वापस स्केल करने से पहले इसे 0 पर स्केल करें।) डेमॉन iptables को प्रारंभ करेगा, यह पता लगाएगा कि docker कब नए कंटेनर बनाता है, और प्रत्येक नए कंटेनर पर नए रूटिंग नियम लागू करता है।

यदि आपको डेमॉन की गतिविधियों को किसी विशेष सेवा तक सीमित करने की आवश्यकता है, तो [ -n "$SERVICE" ] को [ "$SERVICE" = "myservice" ] संशोधित करें।

iptables नियमों को अनइंस्टॉल करना

प्रत्येक नोड पर ingress-routing-daemon-v2 --uninstall चलाएँ।

परिक्षण

ingress-routing-daemon-v2 स्क्रिप्ट का परीक्षण चार-नोड झुंड में तैनात वेब सेवा की 8 प्रतिकृतियों के साथ किया गया है।

सेवा के लिए कर्ल अनुरोध, किसी भी निर्दिष्ट लोड-संतुलित समापन बिंदु नोड आईपी के लिए निर्देशित, सफल प्रतिक्रियाएं लौटाता है, और कंटेनर लॉग की जांच से पता चलता है कि एप्लिकेशन ने आने वाले अनुरोधों को कर्ल क्लाइंट के आईपी से उत्पन्न होने के रूप में देखा।

सीमाओं

चूंकि टीओएस मान 8-बिट संख्या को स्टोर कर सकता है, यह मॉडल सिद्धांत रूप में 256 लोड-बैलेंसर एंडपॉइंट नोड्स तक का समर्थन कर सकता है।

हालाँकि, जैसा कि मॉडल के लिए आवश्यक है कि प्रत्येक कंटेनर को एक iptables मैंगल नियम + एक नीति रूटिंग नियम + एक नीति रूटिंग तालिका प्रति प्रबंधक समापन बिंदु नोड के साथ स्थापित किया जाए, संभवतः कुछ प्रदर्शन में गिरावट हो सकती है क्योंकि ऐसे समापन बिंदु नोड्स की संख्या बढ़ जाती है (हालांकि अनुभव से पता चलता है कि यह है आधुनिक हार्डवेयर पर <= 16 लोड-बैलेंसर एंडपॉइंट नोड्स के साथ ध्यान देने योग्य होने की संभावना नहीं है)।

यदि आप अपने झुंड में लोड-बैलेंसर एंडपॉइंट नोड्स जोड़ते हैं - या मौजूदा मैनेजर नोड्स को लोड-बैलेंसर एंडपॉइंट के रूप में उपयोग करना शुरू करना चाहते हैं - तो आपको सावधानी से चलने की आवश्यकता होगी क्योंकि मौजूदा कंटेनर नए एंडपॉइंट नोड्स पर ट्रैफ़िक को वापस रूट करने में सक्षम नहीं होंगे। INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 को INGRESS_NODE_GATEWAY_IPS के अद्यतन मूल्य के साथ पुनः आरंभ करने का प्रयास करें, फिर नए लोड-बैलेंसर समापन बिंदु का उपयोग करने से पहले सभी कंटेनरों का रोलिंग अपडेट करें।

देशी डॉकर एकीकरण की गुंजाइश

मैं डॉकर कोडबेस से परिचित नहीं हूं, लेकिन मैं ऐसा कुछ भी नहीं देख सकता जो ingress-routing-daemon-v2 करता है, जो सिद्धांत रूप में, डॉकर द्वारा मूल रूप से लागू नहीं किया जा सकता है, लेकिन मैं इसे डॉकर टीम के लिए छोड़ दूंगा डॉकर कोड से परिचित किसी व्यक्ति के लिए विचार करें, या अभ्यास के रूप में।

प्रवेश मार्ग डेमॉन 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 ।

जैसे, जब स्क्रिप्ट को --अनइंस्टॉल के साथ कॉल किया जाता है, तब तक स्क्रिप्ट बाहर निकल जाती है, उन नियमों को हटा दिया गया होगा, और नए नियम अभी तक जोड़े नहीं गए हैं।

उम्मीद है कि यह आपके प्रश्न का उत्तर देगा।

हाय सब, मैं आपको बताना चाहता हूं कि मैंने एनजीआईएनएक्स कॉन्फ़िगरेशन को अच्छी तरह से परिभाषित करने के अलावा और कुछ भी स्थापित और कॉन्फ़िगर किए बिना इस समस्या का समाधान खोजा है। मुझे पता है कि हम सभी ने अलग-अलग तरीकों की कोशिश की है। यह गलती से खोजा गया था। सच कहूं तो मैंने इसे बहुत पहले छोड़ दिया था। खैर, आज तक। जब मैं एक निगरानी प्रणाली लागू कर रहा था, मैं एनजीआईएनएक्स लॉग का उपयोग करके स्रोत आईपी, वास्तविक स्रोत आईपी प्राप्त करने में सक्षम था, इसलिए मैंने डीबग करना शुरू कर दिया कि यह कैसे संभव था।

यहाँ उस तरह के लॉग का एक उदाहरण है

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

नोट: यदि आप प्रॉक्सी (यानी क्लाउडफेयर और अन्य) का उपयोग कर रहे हैं तो कई स्रोत आईपी हैं।

जानकारी थी, मेरा असली आईपी था। फिर, मैंने यह जानने के लिए लॉगिंग एनजीआईएनएक्स प्रारूप की समीक्षा की कि जादू कैसे संभव था, और मुझे यह मिला:

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; जैसे प्रॉक्सी हेडर बदल दिए।

और अंत में, अंतिम परीक्षण, एक नोडजेएस परियोजना पर उस जानकारी का उपयोग करते हुए, सिस्टम जैसे उत्पादन के अंदर, एक ओवरले नेटवर्क के साथ डॉकर झुंड का उपयोग करके, लगभग 4 वीएम के साथ, और अनुमान लगाएं कि यह क्या काम करता है! मैं अंत में असली आईपी पता प्राप्त कर सका।

मैं बहुत खुश हूं क्योंकि यह मुद्दा लंबे समय से खुला है लेकिन मुझे लगता है कि यही जवाब है। मेरे द्वारा उपयोग किए जाने वाले संस्करण हैं:

Docker version: 19.03.8
NGINX version: nginx/1.14.2

मुझे आपकी प्रतिक्रिया का इंतजार रहेगा। मुझे आशा है कि आप मेरे जैसे ही परिणाम प्राप्त कर सकते हैं।

चीयर्स!
सेबस्टियन।

पीएस: इसे किसी अन्य नेटवर्क इंटरफ़ेस का उपयोग करके आज़माएं, जिसका अर्थ है, स्थानीयहोस्ट के बाहर, क्योंकि आपको अपने वास्तविक आईपी पते के बजाय लॉग में "-" मिलेगा। इंटरनेट पर इसका परीक्षण करने का प्रयास करें, पूरी तरह से अपने घरेलू नेटवर्क के बाहर।

बोनस: मैं एक लुकअप टेबल का उपयोग करके आईपी पते को भौगोलिक स्थान पर मैप कर सकता हूं, उन्हें गिन सकता हूं और इसे मानचित्र पर रख सकता हूं, इसलिए इसका उत्तर हां है, यही वह है जिसे हम लोगों की तलाश में थे :)

@sebastianfelipe इन सभी वर्षों के बाद यह एक बड़ा दावा है। आप सुनिश्चित हैं कि आप इस थ्रेड में होस्ट मोड या अन्य समाधान का उपयोग नहीं कर रहे हैं?

@sebastianfelipe इन सभी वर्षों के बाद यह एक बड़ा दावा है। आप सुनिश्चित हैं कि आप इस थ्रेड में होस्ट मोड या अन्य समाधान का उपयोग नहीं कर रहे हैं?

मुझे यकीन है। मैं उन सभी कनेक्टेड सेवाओं पर नेटवर्क होस्ट का उपयोग नहीं कर रहा हूं। मैंने एक डिजिटल ओशन लोड बैलेंसर सहित उत्पादन जैसे वातावरण में एक ओवरले नेटवर्क के साथ एक स्टैक को तैनात किया और यह काम कर गया। मेरा मतलब है, मैं इससे बेहतर इसका परीक्षण नहीं कर सकता। १००% वास्तविक है।

@sebastianfelipe मैं अनुमान लगा रहा हूं कि डिजिटल महासागर लोड बैलेंसर उपयोगकर्ता के आईपी पते को एक्स-फॉरवर्डेड-हेडर के लिए

@beornf मैं सोने की कोशिश कर रहा था और फिर मैंने आपकी अधिसूचना पढ़ी इसलिए मुझे जागना पड़ा और बिना डिजिटल ओशन लोड बैलेंसर के एक दृष्टिकोण का प्रयास करना पड़ा और यह विफल रहा। आप सही कह रहे हैं, जब एक लोड बैलेंसर जोड़ा जाता है तो डिजिटल महासागर वहां एक जादू जोड़ता है। यह $http_x_forwarded_for चर के साथ होता है। डिजिटल ओशन लोड बैलेंसर एक अन्य एनजीआईएनएक्स चर में जानकारी जोड़ता है, वह जानकारी जो सीधे डॉकर झुंड द्वारा नहीं जोड़ी जाती है। संभवत: यह हर मामले के लिए वास्तविक समाधान के लिए "डमी-जैसी" दृष्टिकोण का कारण बन सकता है। कम से कम डिजिटल ओशन ग्राहक यह जानकर खुश हो सकते हैं कि इस समय इससे कैसे निपटा जाए।

@beornf @sebastianfelipe संदर्भ में जोड़ने पर, CloudFlare X-Forwarded-For भी जोड़ता है और काफी हद तक मुफ़्त है।

@beornf @sebastianfelipe संदर्भ में जोड़ने पर, CloudFlare X-Forwarded-For भी जोड़ता है और काफी हद तक मुफ़्त है।

मुझे लगता है कि यह हम में से बहुत से लोगों के लिए काम कर सकता है जिन्हें वास्तविक आईपी प्राप्त करने के लिए एक रास्ता चाहिए। Cloudfare को केवल प्रॉक्सी या केवल DNS के रूप में समायोजित किया जा सकता है। यह बिना डिजिटल ओशन ग्राहकों के लिए पूरी तरह से फिट बैठता है। यह अब तक का क्लीनर वर्कअराउंड है। लेकिन मैं @beornf से सहमत

धन्यवाद!