Moby: docker swarm मोड: 127.0.0.1 पर पोर्ट 0.0.0.0 के संपर्क में हैं

हाँ, यह एक त्रुटि आउटपुट होना चाहिए; सेवाएं (डिफ़ॉल्ट रूप से) "इंग्रेस" नेटवर्क का उपयोग करके "प्रकाशित करें", और आईपी-पते को निर्दिष्ट करने का समर्थन नहीं करते हैं, क्योंकि यह अनुमान लगाना संभव नहीं है कि कौन सा _node_ वे समाप्त होते हैं (इस प्रकार ज्ञात नहीं है कि आईपी-पते उपलब्ध हैं - हालांकि 127.0 .0.1 संभव हो सकता है)। यह समस्या उस सुविधा को ट्रैक कर रही है जो https://github.com/docker/docker/issues/26696 (और यह "महाकाव्य" अन्य विकल्पों को ट्रैक करती है जो अभी तक सेवाओं द्वारा समर्थित नहीं हैं https://github.com/docker/docker/issues / 25303)

यहाँ बग यह है कि डॉकटर को विकल्प को अनदेखा करने के बजाय एक त्रुटि उत्पन्न करनी चाहिए; इस न्यूनतम डॉक-कम्पोज़ फ़ाइल का उपयोग करके प्रतिलिपि प्रस्तुत करने योग्य;

version: "3.2"
services:
  mongodb:
    image: nginx:alpine
    ports:
      - "127.0.0.1:27017:80"

ping @dnephin @vdemeester

@ fer2d2 झुंड मोड पर, यदि आप कुछ ( ports stack deploy ) प्रकाशित करते हैं, तो इसे ingress नेटवर्क पर प्रकाशित किया जाता है, और इस प्रकार यह सार्वजनिक है। आस-पास जाने के कुछ तरीके हैं, लेकिन kind/bug को उस पर डाल दिया जाता है क्योंकि हमें कम से कम लोगों को इस बारे में चेतावनी देनी चाहिए कि बंदरगाहों के साथ stack deploy जिसमें यह संकेतन है (अर्थात host:port:port )।

इसके आसपास काम करने के लिए, कुछ तरीके हैं:

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

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

यह docker run -p 80:9005 … के समान ही करेगा, इसलिए यह 0.0.0.0 लिए बाध्य होगा, लेकिन होस्ट तक सीमित होगा।

लेकिन जैसा @thaJeztah ने कहा, "यहाँ बग यह है कि डॉकटर को एक त्रुटि उत्पन्न करनी चाहिए, बजाय चुपचाप विकल्प को अनदेखा करने के लिए"

/ cc @mavenugo @aboch यह देखने के लिए कि क्या वास्तव में एक विशिष्ट आईपी के साथ इसे बाँधने में सक्षम होने का कोई तरीका होगा? (वास्तव में प्राप्त करने के लिए मुश्किल है क्योंकि नोड का आईपी अलग होगा ..)

@vdemeester क्या मैं इस नोटेशन का उपयोग कर स्थानीय लक्ष्य के रूप में निर्दिष्ट कर सकता हूं?

    ports:
      - mode: host
        target: 127.0.0.1:80
        published: 9005

चूंकि यह पोर्ट कॉन्फ़िगरेशन के लिए एक विस्तारित प्रारूप

अग्रिम में धन्यवाद

ऐसा लगता है कि लक्ष्य और प्रकाशित दोनों को लंबे वाक्य रचना में पूर्णांक प्रकार के रूप में लागू किया गया है

मुझे लगता है कि यह वांछित व्यवहार नहीं है यदि आप SSH सुरंगों के माध्यम से कुछ सेवाओं से जुड़ रहे हैं। उदाहरण के लिए, यदि आप 127.0.0.1 पर अपना MySQL या MongoDB सर्वर चाहते हैं और SSH टनल के माध्यम से कनेक्ट होते हैं, तो डॉकर झुंड के साथ आपको डेटाबेस पोर्ट को 0.0.0.0 पर एक्सपोज़ करना होगा या SSH के साथ कस्टम डेटाबेस कंटेनर बनाना होगा (और दोनों विकल्प) बहुत असुरक्षित हैं)।

SSH सुरंगों का उपयोग करने वाले कई डेटाबेस क्लाइंट हैं, जैसे SQL कार्यक्षेत्र या Robomongo जिनका उपयोग इस सीमा (विशिष्ट इंटरफ़ेस बाइंडिंग) के कारण नहीं किया जा सकता है।

हमारी कंपनी में @ fer2d2 के समान ही समस्या है,

कोई खबर?

+1

+1

IP_ पते की अनुमति देने के लिए एक और उपयोग मामला

जब आप निर्दिष्ट करते हैं तो क्या यह संभवतः एक विकल्प हो सकता है:

placement:
        constraints:
          - node.id ==

चियर्स

+1

+1

+1

अपने लिए मैंने इस समस्या को हल किया:

iptables -I DOCKER-USER -i eth0 -j DROP
iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT

कर्ता इन नियमों को नहीं छूता है। बस अपना खुद का जोड़ता है
-A DOCKER-USER -j RETURN
परिणामस्वरूप, हालांकि पोर्ट 0.0.0.0 पर सुनता है, लेकिन बाहरी इंटरफ़ेस eth0 से सुलभ नहीं है

यह व्यवहार "डिफ़ॉल्ट रूप से सुरक्षित" के उल्लंघन में है, और डॉक्स में नोट डालना काफी अच्छा नहीं होगा। अभी के लिए यह एक त्रुटि का कारण होना चाहिए।

यह मोड से भी संबंधित है: इंग्रेस / होस्ट (ये दो मुद्दे चर्चा में उलझे हुए लगते हैं)। इंग्रेस मोड के बारे में कुछ भी नहीं है जो सभी नोड्स पर स्थानीय पते के लिए बाध्य होने वाली सेवा को रोकना चाहिए, लेकिन बाहरी पते पर नहीं। इसलिए 127.xxx की अनुमति दी जानी चाहिए। (गैर-झुंड मोड में (docker run का उपयोग करके) मैं 127.0.0.2:80 और 127.0.0.3:80 आदि को स्थानीय रूप से विकास में कई सर्वरों का परीक्षण करने के लिए बाध्य करता हूं।)

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

बक्सों का इस्तेमाल करें

• उन मामलों का उपयोग करें जिन्होंने मुझे प्रभावित किया है (निश्चित रूप से वास्तविक)
  
  
  
  • 1 विशिष्ट नोड के पोर्ट से बांधें, क्योंकि पोर्ट अन्य नोड्स पर उपयोग में है। आप इसके लिए होस्ट मोड का उपयोग कर सकते हैं, लेकिन डिफ़ॉल्ट एक आश्चर्य है।
  
  
  • 2 विशिष्ट नोड के पोर्ट से बांधें, क्योंकि अन्य नोड्स में सार्वजनिक इंटरफेस है। आप इसके लिए होस्ट मोड का उपयोग कर सकते हैं, लेकिन डिफ़ॉल्ट "डिफ़ॉल्ट रूप से सुरक्षित" के उल्लंघन में है ।
  
  
  • 3 स्थानीय रूप से बाँधें, क्योंकि आप इसे अन्य होस्ट के लिए दृश्यमान नहीं चाहते हैं, डिफ़ॉल्ट रूप से "डिफ़ॉल्ट रूप से सुरक्षित" के उल्लंघन में है
  
  
  • 4 बाइंड 127.0.0.3, क्योंकि आपकी विकास मशीन पर बहुत सारा सामान है, और 127.0.0.1 इस पोर्ट द्वारा उपयोग में है। और /etc/hosts , ताकि प्रत्येक डोमेन-नाम को एक अलग कंटेनर में भेजा जाए। यह docker run साथ काम करता है, लेकिन रचना के साथ नहीं।
  
  
• अन्य usecases
  
  
  
  • विशिष्ट इंटरफ़ेस जैसे 192.168.0.x पर बाइंड करें, क्योंकि यह एक आंतरिक नेटवर्क है। डिफ़ॉल्ट "डिफ़ॉल्ट रूप से सुरक्षित" के उल्लंघन में है
  
  
  • विशिष्ट विशिष्ट नोड से बांधें, लेकिन इस नोड पर चलने के लिए सेवा को बाध्य न करें। यह 1 या 2 के समान उपयोग मामला है, लेकिन बाधाओं के उपयोग के साथ। यातायात झुंड के माध्यम से किया जाएगा।
  
  

तो संक्षेप में

• IP पते को अनदेखा करना और 0.0.0.0, और डिफ़ॉल्ट इंग्रेस मोड से बाइंड करना, दोनों ही "डिफ़ॉल्ट रूप से सुरक्षित" के उल्लंघन में हैं। यदि IP- पता निर्दिष्ट किया गया है, और डॉक्स अपडेट किए गए हैं तो त्रुटियां जारी की जानी चाहिए। यदि मोड निर्दिष्ट नहीं है (कोई डिफ़ॉल्ट नहीं), और डॉक्स अपडेट किए जाने पर त्रुटि जारी की जानी चाहिए। (यह मोड समस्या को ठीक करता है, और आश्चर्यजनक सुरक्षा समस्याओं को रोकता है।)
• तब होस्ट मोड में आईपी पते के लिए समर्थन जोड़ा जा सकता है।
• इंग्रेस मोड में IP पतों के लिए समर्थन, जो स्थानीय पते 127.xxx तक सीमित है, जोड़ा जा सकता है। (विभिन्न स्थानीय पते जैसे 127.0.0.2 और 127.0.0.3 को अलग-अलग माना जाना चाहिए (बस ओएस पर पारित किया गया))।

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

@ richard-delorenzi Moby एक होस्ट आईपी को वर्तमान में स्वीकार नहीं करता है। सुविधा अनुरोध के बाहर, यह एक ग्राहक पक्ष के मुद्दे की तरह लगता है ... विशेष रूप से कैसे डॉक सीएलआई में यमल का अनुवाद किया गया है।

जिस तरह से काम करता है वह बहुत अच्छी तरह से प्रलेखित है, लेकिन सहमत हैं कि यह सीएलआई पर खराब व्यवहार है।

+1

+1

+1

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

मैं यह नहीं देख सकता कि यह एक कम्पोज़ फ़ाइल में कैसे किया जाए, इसलिए हम बस स्टैंडअलोन कंटेनर को ऐसे ही चला रहे हैं:

docker run --name kibana --rm -d -v /var/lib/kibana:/usr/share/kibana/config -p 127.0.0.1:5601:5601 --network core docker.elastic.co/kibana/kibana:6.1.2

docker run --name chronograf --rm -d -v /var/lib/chronograf:/var/lib/chronograf -p 127.0.0.1:8888:8888 --network core chronograf:1.4 chronograf --influxdb-url=http://influxdb:8086

इन्हें शुरू करने के बाद, docker ps नए कंटेनरों को 127.0.0.1 से बाउंड होने के रूप में दिखाता है। तथास्तु। मैं तब सुरक्षित पहुँच के लिए अपने स्थानीय कार्य केंद्र से होस्ट करने वाले को सुरंग दे सकता हूँ, जैसे:

ssh -i my_ssh_key.pem [email protected]  -L 8888:localhost:8888  -L 5601:localhost:5601 -N

अपने ब्राउज़र से, मैं तब http: // localhost : 8888 या http: // localhost : 5601 से कनेक्ट कर सकता हूं

मेरे लिये कार्य करता है।

इस घटना में कि एक UNIX सॉकेट 127.0.0.1 टीसीपी / आईपी सॉकेट की जगह ले सकता है, एक संभव समाधान जो मैंने धाराप्रवाह के लिए लागू किया है, वह यहां उपलब्ध

शायद mode एक और विकल्प जोड़ने से मदद मिल सकती है। local host और ingress ।

कृपया शब्दों को हटा दें "प्रयोग करने योग्य सुरक्षा: Moby प्रयोज्य से समझौता किए बिना सुरक्षित चूक प्रदान करता है।" moby readme फ़ाइल पर । यह निश्चित रूप से गलत विज्ञापन है, @ richard-delorenzi की टिप्पणी देखें।

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

IP- पते के लिए बाइंडिंग के लिए समर्थन जोड़ना https://github.com/moby/moby/issues/26696 में चर्चा की गई है, लेकिन लागू करने के लिए तुच्छ नहीं है (गैर-स्थानीय "आईपी-पते को ध्यान में रखते हुए)

एक स्टैक तैनात करते समय एक चेतावनी जोड़ी गई थी;

docker stack deploy -c- test <<'EOF'
version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
EOF

WARN[0000] ignoring IP-address (127.0.0.1:8080:80/tcp) service will listen on '0.0.0.0' 
Creating network test_default
Creating service test_web

और जब निर्दिष्ट आईपी-पते के साथ एक सेवा को तैनात करने का प्रयास किया जाता है, तो यह एक त्रुटि के साथ तैनात करने में विफल होगा;

docker service create -p 127.0.0.1:9090:80 nginx:alpine
invalid argument "127.0.0.1:9090:80" for "-p, --publish" flag: hostip is not supported
See 'docker service create --help'.

@dalu यदि आपका सिस्टम इंटरनेट के संपर्क में है और आपने डॉकर को क्लस्टर पर एक सेवा का खुलासा करने के लिए कहा है, तो मुझे यकीन नहीं है कि उम्मीद कुछ और होगी।

निश्चित रूप से यह रचना प्रारूप देव और वास्तविक तैनाती के कुछ जटिल समझौते हैं।

@ cpuguy83

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

नहीं। यदि कोई व्यक्ति इसे गैर सार्वजनिक आईपी जैसे 127.0.0.1 या 10.0.0.0 से बाँधता है, तो इसे सार्वजनिक क्यों होना चाहिए? वास्तव में, यह सही उत्तर है:

वर्तमान में किसी विशिष्ट IP- पते पर बाइंडिंग समर्थित नहीं है

@ लालू

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

मैं झुंड से कुबेरनेट्स में संक्रमण कर रहा हूं क्योंकि झुंड प्रयोग करने योग्य नहीं है। मैं इस निर्णय से पूरी तरह से खुश हूँ यहाँ तक कि यह संक्रमण बहुत महंगा है।

@Bessonv यह आपको बताता है "मैं इसे अनदेखा कर रहा हूं"

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

@ cpuguy83
मुझे यकीन नहीं है कि मैं इस विवरण के साथ सहज हूं। अंतिम रचना प्रारूप में वांछित राज्य का वर्णन है। एक-मशीन (रचना) और क्लस्टर (झुंड) के बीच कुछ अंतर रखने के लिए पूरी तरह से ठीक है। मेरे दृष्टिकोण से, समर्थन रचना का कोई मतलब नहीं है। विशेष रूप से क्योंकि सक्रिय झुंड मोड इतना आसान है। लेकिन इसके लिए झुंड को ठीक करने की आवश्यकता होती है।

समस्या सब पर झुंड में नहीं है और कम्पोज़ प्रारूप में 100% है + docker cli में कार्यान्वयन।
ध्यान दें कि स्टैक वर्तमान में 100% एक ग्राहक पक्ष कार्यान्वयन है।

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

ढेर के अंदर उदाहरण DB सेवा

services:
  db:
    image: postgres:11-alpine
  networks:
    - backend

... इस तरह से डिफ़ॉल्ट पोर्ट द्वारा Django app सेवा द्वारा सेवन किया जा सकता है:

DATABASES = {
    'default': env.db(default='postgres://user:pass<strong i="13">@db</strong>:5432/catalog'),
}

इसलिए इस मामले में जब आप केवल सार्वजनिक सेवाओं को स्पष्ट रूप से उजागर करते हैं तो यह सुरक्षित-बाय-डिफ़ॉल्ट जैसा दिखता है

समस्या सब पर झुंड में नहीं है और कम्पोज़ प्रारूप में 100% है + docker cli में कार्यान्वयन।
ध्यान दें कि स्टैक वर्तमान में 100% एक ग्राहक पक्ष कार्यान्वयन है।

जो भी: मैंने स्टैक का उपयोग करना बंद कर दिया (इस समस्या के कारण), और अब देखभाल नहीं करता है। पुस्तकालय को दोष दो, दोष को दोष दो, मेरी बिल्ली को दोष दो।

मैंने इस समस्या को सीधे docker का उपयोग करते समय, या कंपोज़ का उपयोग करते समय नहीं देखा है।

ऐसा लगता है कि यह दृष्टिकोण मदद कर सकता है (झुंड में प्रत्येक नोड पर निष्पादित किया जाना चाहिए):

1. झुंड छोड़ो
2. नेटवर्क docker_gwbridge निकालें
3. अतिरिक्त विकल्प com.docker.network.bridge.host_binding_ipv4 = IP के साथ नेटवर्क docker_gwbridge फिर से बनाएँ
4. वापस झुंड में शामिल हों
   "होस्ट" मोड में प्रकाशित बंदरगाहों के लिए काम करता है। बिना मोड "होस्ट" इनग्रेस नेटवर्क का उपयोग अन्य ड्राइवर और स्कोप "झुंड" के साथ किया जाता है।

भयानक समाधान:

$ mv /usr/bin/docker-proxy /usr/bin/docker-proxy-original
$ cat << 'EOF' > /usr/bin/docker-proxy
#!/bin/sh
exec /usr/bin/docker-proxy-original `echo $* | sed s/0.0.0.0/127.0.0.1/g`
EOF
$ chmod 755 /usr/bin/docker-proxy
$ service docker restart

@jsmouret मुझे नवीनतम docker रिलीज़ पर

ऐसा लगता है कि यह निर्भर करता है ...

$ apt-file search docker-proxy
docker-ce: /usr/bin/docker-proxy
docker.io: /usr/sbin/docker-proxy

यह व्यवहार में किसी भी तरह प्रलेखित किया जाना चाहिए प्रलेखन ।
वर्तमान में, यह केवल शॉर्ट पोर्ट मैपिंग से होस्ट को अनदेखा करता है। और चुपचाप काम नहीं करता है।

एक और अजीब बात यह है कि आप मेजबान को लंबे वाक्यविन्यास स्कीमा में सेट नहीं कर सकते।

इस व्यवहार को प्रलेखन में किसी भी तरह से प्रलेखित किया जाना चाहिए।

मैं सहमत हूँ; मैंने सोचा था कि यह उस पृष्ठ पर कहीं उल्लेख किया गया था, लेकिन यह नहीं मिल सकता है; डॉक्स रिपॉजिटरी में किसी मुद्दे को खोलने के लिए स्वतंत्र महसूस करें; https://github.com/docker/docker.github.io/issues

वर्तमान में, यह केवल शॉर्ट पोर्ट मैपिंग से होस्ट को अनदेखा करता है। और चुपचाप काम नहीं करता है।

आप किस संस्करण का उपयोग कर रहे हैं? इसे एक चेतावनी मुद्रित करना चाहिए (जब docker stack deploy का उपयोग कर), या एक _error_ ( docker service create का उपयोग करते समय); https://github.com/moby/moby/issues/32299#issuecomment -472793444 देखें

आप किस संस्करण का उपयोग कर रहे हैं? इसे एक चेतावनी प्रिंट करना चाहिए (जब डॉक स्टैक की तैनाती का उपयोग करते हुए), या एक त्रुटि (जब docker सेवा बनाएं का उपयोग करके);

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

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

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

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

यह शायद अन्य असंबंधित दुष्प्रभाव हैं लेकिन "iptables": false /etc/docker/daemon.json सेटिंग के रूप में अच्छी तरह से वर्कअराउंड के रूप में ट्रिक करता है। एक कम कठोर समाधान

किसी भी तरह मैं 3 साल बाद इसके लिए कुछ और समर्थन देखना पसंद करूंगा।

ऐसा लगता है कि यह दृष्टिकोण मदद कर सकता है (झुंड में प्रत्येक नोड पर निष्पादित किया जाना चाहिए):

1. leave swarm

2. remove network docker_gwbridge

3. recreate network docker_gwbridge with additional option com.docker.network.bridge.host_binding_ipv4=IP

4. join swarm back
   Works for ports published in mode "host". Without mode "host" ingress network is used with other driver and scope "swarm".

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

मैं अपने वर्कअराउंड की रिपोर्ट करना चाहूंगा।

उदाहरण:
झुंड में कुछ सेवाओं को सभी इंटरफेस पर, या कम से कम सार्वजनिक इंटरफ़ेस पर सुनने की आवश्यकता है - मेरे उदाहरण में यह कंटेनर एक रिवर्स प्रॉक्सी है
उन झुंड नोड्स में, प्रत्येक नोड पर एक डेटाबेस उदाहरण भी है, जो एक झुंड नेटवर्क को परिभाषित करते हैं:

docker network create --scope swarm NETWORK_NAME --attachable -d overlay

वेब सेवाओं के लिए जो डेटाबेस कनेक्शन की आवश्यकता होती है, उसे NETWORK_NAME जरूर शामिल होना चाहिए

व्यवस्थापक उद्देश्यों के लिए, कभी-कभी, डेटाबेस से सीधे जुड़ना आवश्यक है

उपाय:
केवल वे सेवाएँ जिन्हें सभी नेटवर्कों पर उजागर किया जाना चाहिए (मेरी मिसाल में उल्टी समीपता) उनकी सेवाओं की परिभाषा में ports: ['SOMEPORT:ANOTHERPORT'] हो सकती हैं।

अन्य सभी सेवाओं के लिए, मेजबान पर गैर-झुंड कंटेनर रखने की आवश्यकता है।
यह गैर-झुंड कंटेनर NETWORK_NAME/nodeXYZ:port से localhost पर मौजूद पोर्ट को ब्रिज करेगा

मंगोल के साथ उदाहरण:

docker run --rm -it --net=NETWORK_NAME -d --name expose-mongo -p 127.0.0.1:27017:47017 alpine/socat tcp-listen:47017,fork,reuseaddr tcp-connect:mongo01:27017

नकारात्मक पक्ष: प्रत्येक झुंड नोड के लिए एक गैर-झुंड कंटेनर होना चाहिए, इसलिए कई नोड्स वास्तव में उबाऊ हैं जब तक कि ansible / भारी स्क्रिप्टिंग को अपनाना नहीं है।

"यदि आप SSH सुरंगों के माध्यम से कुछ सेवाओं से जुड़ रहे हैं" के लिए मेरा समस्या है कि @ fer2d2 का उल्लेख एक Dsherfile के साथ ssh सेवा को जोड़ने के लिए किया गया था:

FROM alpine

RUN apk add --no-cache openssh
RUN mkdir ~/.ssh
RUN ssh-keygen -A
RUN echo "root:root" | chpasswd
RUN echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config
RUN echo 'Port 22' >> /etc/ssh/sshd_config
RUN echo -e " \
Match User root \n\
  AllowTcpForwarding yes\n\
  X11Forwarding no\n\
  AllowAgentForwarding no\n\
  ForceCommand /bin/false\n\
" >> /etc/ssh/sshd_config

EXPOSE 22
CMD /usr/sbin/sshd -D -e "$@"

फिर docker-compose.yml में:

...
  db:
    image: mysql:5.6
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?err}
      MYSQL_ROOT_HOST: '%'
    volumes:
      - "./mysql:/var/lib/mysql"
    deploy:
      placement:
        constraints: [node.role == manager]

  sshd:
    image: maxisme/sshd:latest
    volumes:
      - "~/.ssh:/root/.ssh"
    ports:
      - "2223:22"
    deploy:
      placement:
        constraints: [node.role == manager]

जो मुझे ~/.ssh लिए अपने अधिकृत_कीप्स को जोड़ने की अनुमति देता है और फिर पोर्ट 2223 से अपने डेटाबेस में db होस्टनाम का उपयोग करके ssh छलांग लगाता है।

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

वैध

एक और उदाहरण कि यह विशेषता क्यों महत्वपूर्ण है।
मेरे पास एक सर्वर है जिसमें plesk स्थापित है, plesk के पास पहले से ही इसके विन्यास हैं लेकिन मैं एक और विन्यास जोड़ सकता हूं बस एक docker कर्म सेवा को इंगित करने के लिए। यह plesk सर्वर एक झुंड नोड है।
मैं एक पोर्ट से प्रॉक्सी_पास के लिए प्लिस्कोप का उपयोग करना चाहूंगा। इस पोर्ट को प्रकाशित किया जाना चाहिए क्योंकि कंटेनर ओवरले नेटवर्क में है, लेकिन इसे दुनिया के साथ संवाद करने के लिए बाहरी पोर्ट की आवश्यकता है।

तो समीपस्थ को 127.0.0.1 जैसे स्थानीय इंटरफ़ेस की ओर संकेत करना चाहिए: someport
और झुंड में कंटेनर को केवल लोकलहोस्ट को पोर्ट प्रकाशित करना चाहिए।

इस तरह कंटेनर पोर्ट केवल समीपस्थ द्वारा पहुँचा जा सकता है और सीधे दुनिया से नहीं

मुझे आपका वर्कअम @maxisme पसंद है, लेकिन आप authorized_keys स्वामित्व का प्रबंधन कैसे करते हैं? ओएस एक्स पर यह मेरे लिए काम करता है (माउंट root ), लेकिन एक उत्पादन लिनक्स मशीन पर मुझे मिल रहा है:

Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
Connection closed by authenticating user root 85.145.195.174 port 60535 [preauth]

वॉल्यूम होस्ट उपयोगकर्ता के यूआईडी से संबंधित है, जो root और SSHD इसके साथ काम करने से इनकार करता है। आपके वर्कअराउंड use के शीर्ष पर वर्कअराउंड का उपयोग configs इस तरह करना है:

services:
  sshd:
    image: [...]/sshd:${version}
    configs:
      # FIXME: It would be much better to use a bind volume for this, as it
      # would always be in sync with the host configuration. So revoking a key
      # in the host machine would automatically revoke it in the container. But
      # I can't figure out how to give the volume right ownership. It keeps UID
      # from the host which doesn't align with the container user.
      - source: authorized_keys
        target: /root/.ssh/authorized_keys
        mode: 0600

configs:
  authorized_keys:
    file: ~/.ssh/authorized_keys

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

हालाँकि अक्सर मेजबान के पास उत्तर और दक्षिण के बीच का अंतर होता है। आप झुंड के बंदरगाहों को केवल सभी झुंड मेजबानों पर उत्तरपूर्वी इंटरफेस में बाँधना चाह सकते हैं।

यदि आप चाहते हैं कि किसी सेवा को बाँधने के लिए सभी इंटरफेस के इंटरफ़ेस नाम समान हों (जैसे कि eth0), तो यह एक विचार हो सकता है कि स्वॉर्म पोर्ट को (सर्विस पोर्ट्स सेक्शन में) बाइंड करने के लिए एक इंटरफेनेसम को निर्दिष्ट करने का विकल्प प्रदान किया जाए।

    nginx:
      image: nvbeta/swarm_nginx
      networks:
        - demonet1
      ports:
        - "eth0:8088:80"

जब eth0 एक झुंड नोड पर उपलब्ध नहीं है, तो निर्दिष्ट पोर्ट किसी भी इंटरफ़ेस के लिए बाध्य नहीं होगा।

@ tad-lispy आपको कंटेनर उपयोगकर्ता के यूआईडी और जीआईडी ​​को बदलने में सक्षम होना चाहिए जो होस्ट पर वॉल्यूम स्वामी के समान हो।
Linuxserver की छवि पर्यावरण चर स्थापित करके इसका समर्थन करती है (देखें https://hub.docker.com/r/linuxserver/openssh-server, User / Group Identifiers ),