डॉकर की अद्भुत दुनिया का और अधिक अन्वेषण करने का समय आ गया है। अब तक हमारे दो ट्यूटोरियल हो चुके हैं - पहला एक विस्तृत परिचय था, जहां हमने तकनीक के बारे में सब कुछ सीखा, सेवाएं कैसे चलाएं और पोर्ट एक्सपोज़ करें, डॉकरफाइल के साथ इमेज कैसे कमिट और बिल्ड करें, और कुछ अन्य तरकीबें। फिर हमने इनिट स्क्रिप्ट और systemd के विकल्प के रूप में supervisord का उपयोग किया।
आज, हम नेटवर्किंग के बारे में सीखेंगे। हम अपने कंटेनरों से कैसे जुड़ सकते हैं, स्पॉन किए गए इंस्टेंस के भीतर से होस्ट को कैसे एक्सेस कर सकते हैं, और सबसे महत्वपूर्ण बात, टोपोलॉजी के बारे में पहले से कुछ भी जाने बिना एक कंटेनर से दूसरे कंटेनर से कैसे जुड़ सकते हैं। यह दिलचस्प होना चाहिए। पिछले दो गाइड की तरह, हम चरण-दर-चरण आगे बढ़ेंगे और हर चीज को विस्तार से समझाएंगे।
विषय सूची
- सेटअप
- होस्ट से कंटेनर नेटवर्किंग
- सारांश
- कंटेनर से होस्ट नेटवर्किंग
- कंटेनर से कंटेनर नेटवर्किंग
- कंटेनर लिंक्स!
- होस्ट्स फाइल
- इसके नाम का उपयोग करके सर्वर से कनेक्ट करें
- अधिक पठन
- निष्कर्ष
सेटअप
आइए पहले कई कंटेनर बनाते हैं। हमारे पास पिछले परीक्षण से पहले से ही इमेज हैं, इसलिए स्क्रैच से शुरू करने की कोई आवश्यकता नहीं है। हम तीन कंटेनर चलाएंगे, प्रत्येक अपने स्वयं के SSH और Apache सेवा के साथ। सुरक्षा पहलू को नज़रअंदाज़ करें, क्योंकि हम नेटवर्किंग भाग पर ध्यान केंद्रित करने की कोशिश कर रहे हैं।
एक चीज जो हम यहां करेंगे जो हमने पिछली बार नहीं की थी, वह है अपने कंटेनरों को नाम देना, आसान पहचान के लिए। यह --name विकल्प का उपयोग करके किया जाता है। उदाहरण के लिए:
docker run -d -ti -p 22 -p 80 --name net3 image-4:latest
आइए यह भी देखें कि हमारे तीन इंस्टेंस के कौन से IP पते हैं:
[root@localhost ~]# docker inspect net1 | grep -i ipaddr "IPAddress": "172.17.0.5", [root@localhost ~]# docker inspect net2 | grep -i ipaddr "IPAddress": "172.17.0.6", [root@localhost ~]# docker inspect net3 | grep -i ipaddr "IPAddress": "172.17.0.7",
यह हमारे परीक्षण के लिए प्रारंभिक कॉन्फ़िगरेशन है। हमारे पास एक ही होस्ट पर चल रहे तीन कंटेनर हैं, जिनकी अपनी सेवाएं और एक्सपोज़्ड सर्विस पोर्ट हैं। अब, हम कुछ दिलचस्प चीजें करना शुरू कर सकते हैं।
होस्ट से कंटेनर नेटवर्किंग
यह आसान हिस्सा है, और सच कहूं तो, हमने पिछले अभ्यास में यह पहले ही कर लिया है। हम SSH का उपयोग करके अपने कंटेनरों से जुड़े हैं, और हमने telnet का उपयोग करके पोर्ट का परीक्षण किया है। हां, netcat (nc) भी ठीक काम करता है, अपनी सुरक्षा चिंताओं को किनारे रखें। कनेक्ट करने के दो तरीके हैं। पहला, आप कंटेनरों को सीधे उनके IP पते का उपयोग करके एक्सेस कर सकते हैं, जैसा कि हमने पहले किया था।
ssh 172.17.0.5 The authenticity of host '172.17.0.5 (172.17.0.5)' can't be established. ECDSA key fingerprint is 00:4b:de:91:60:e5:22:cc:f7:89:01:19:3e:61:cb:ea. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '172.17.0.5' (ECDSA) to the list of known hosts. root@172.17.0.5's password:
दूसरा, आप होस्ट-मैप्ड पोर्ट को भी एक्सेस कर सकते हैं जो कंटेनरों के अंदर सर्विस पोर्ट से मेल खाते हैं। यदि हम docker ps आउटपुट में PORTS जानकारी देखें:
0.0.0.0:49162->22/tcp, 0.0.0.0:49161->80/tcp net1 0.0.0.0:49163->22/tcp, 0.0.0.0:49164->80/tcp net2 0.0.0.0:49165->22/tcp, 0.0.0.0:49166->80/tcp net3
उपरोक्त उदाहरण में, net1 नामक कंटेनर के लिए, पोर्ट 22 होस्ट पर पोर्ट 49162 पर मैप किया गया है, जिसका अर्थ है docker0 इंटरफ़ेस, जिसे डिफ़ॉल्ट रूप से 172.17.42.1/16 नेटवर्क असाइन किया गया है। वास्तव में, हम देखते हैं:
telnet 172.17.42.1 49163 Trying 172.17.42.1... Connected to 172.17.42.1. Escape character is '^]'. SSH-2.0-OpenSSH_6.6.1
अब, आप दूसरी विधि का उपयोग क्यों करना चाहेंगे, क्योंकि यह अधिक भ्रमित करने वाली और याद रखने में कठिन है? उत्तर है, यदि आप डायनामिक मैपिंग का उपयोग नहीं करते हैं, बल्कि इसके बजाय आप ज्ञात, दिए गए होस्ट पोर्ट निर्दिष्ट करते हैं, तो आपके पास आपके कंटेनर नेटवर्क की एक बहुत स्पष्ट टोपोलॉजी हो सकती है। इसके अलावा, यदि आप अपने कंटेनरों को होस्ट के बाहर से एक्सेस करने योग्य बनाना चाहते हैं, तो आपको IP फ़ॉरवर्डिंग और NAT की आवश्यकता होगी। यदि आप संचार के लिए docker0 इंटरफ़ेस का उपयोग करते हैं, तो आपको कम, सरल iptables नियमों की आवश्यकता होगी।
आप iptables -L कमांड चलाकर और DOCKER चेन की जांच करके इसे सत्यापित कर सकते हैं। जब भी आप -p विकल्प के साथ एक कंटेनर चलाते हैं तो नए नियम स्वचालित रूप से जोड़े जाएंगे।
Chain DOCKER (1 references) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.5 tcp dpt:http ACCEPT tcp -- anywhere 172.17.0.5 tcp dpt:ssh ACCEPT tcp -- anywhere 172.17.0.6 tcp dpt:ssh ACCEPT tcp -- anywhere 172.17.0.6 tcp dpt:http ACCEPT tcp -- anywhere 172.17.0.7 tcp dpt:ssh ACCEPT tcp -- anywhere 172.17.0.7 tcp dpt:http ACCEPT tcp -- anywhere 172.17.0.8 tcp dpt:ssh ACCEPT tcp -- anywhere 172.17.0.8 tcp dpt:http
हालांकि, यदि आपके पास कोई सुरक्षा प्रतिबंध नहीं हैं, तो डायनामिक विधि काफी उपयोगी हो सकती है, क्योंकि जब आप अपने कंटेनर शुरू करते हैं तो आपको पोर्ट के मैपिंग को जानने की आवश्यकता नहीं होती है। आप docker ps आउटपुट को पार्स करके रीयल-टाइम में जानकारी प्राप्त कर सकते हैं। हालांकि, सेवाओं के लिए, अक्सर स्टेटिक IP पते और ज्ञात पोर्ट सेट करना उपयोगी होता है।
सारांश
चूंकि यह थोड़ा भ्रमित करने वाला है, आइए संक्षेप में पुनर्कथन करते हैं। किसी भी डॉकर होस्ट में एक docker0 या इसी तरह नामित ब्रिज चल रहा होगा, आमतौर पर /16 सबनेट के साथ, हालांकि आप नाम, सबनेट या यहां तक कि नेटवर्क को बदल सकते हैं। इसके पीछे, आपके पास कंटेनरों की एक पूरी श्रृंखला हो सकती है, प्रत्येक अपने स्वयं के निजी IP पते और एक या अधिक एक्सपोज़्ड पोर्ट के साथ।
यदि आप इन कंटेनरों और उनके प्रासंगिक पोर्ट से जुड़ना चाहते हैं, तो आपके पास कई विकल्प हैं। आप सीधे कनेक्ट कर सकते हैं, लेकिन फिर आपको IP फ़ॉरवर्डिंग, NAT और प्रत्येक के लिए फ़ायरवॉल नियमों की आवश्यकता होती है, और आपको IP पते जानने की आवश्यकता होती है।
यदि आप होस्ट इंटरफ़ेस (docker0) और होस्ट पोर्ट विधि का उपयोग करके कनेक्ट करना चाहते हैं, तो आपको यह जानने की आवश्यकता नहीं है कि आपके कंटेनर कैसे चलते हैं। आपको केवल होस्ट पोर्ट से कंटेनर पोर्ट के मैपिंग को जानने की आवश्यकता है। दूसरे शब्दों में, यदि आप चाहते हैं कि आपके कंटेनर कई होस्ट नोड्स के बीच पहुंच योग्य हों, तो आपको केवल होस्ट इंटरफ़ेस (docker0) को अन्य होस्ट को दृश्यमान बनाने की आवश्यकता है। यह IP फ़ॉरवर्डिंग, NAT और फ़ायरवॉल नियमों को सरल बनाता है। उदाहरण के लिए:
0.0.0.0:30001->22/tcp net1 0.0.0.0:30007->22/tcp net4 0.0.0.0:30008->22/tcp net5
उपरोक्त उदाहरण आपको तीन अलग-अलग कंटेनरों के SSH से जुड़ने देता है। यदि आप वन-टू-वन मैपिंग का उपयोग करते हैं, यानी समान होस्ट पोर्ट और कंटेनर पोर्ट (उदाहरण के लिए 22:22), तो आप प्रभावी रूप से एक ही सेवा वाले एकल कंटेनर तक सीमित हैं। यह आपके होम राउटर की तरह है। आपको अपने कंटेनरों के लिए अलग-अलग पोर्ट का उपयोग करना होगा ताकि वे वन-टू-वन मैपिंग का उपयोग कर सकें। लेकिन यह भ्रमित करने वाला है, क्योंकि आप उम्मीद करते हैं कि आपकी सेवाएं पूर्वानुमानित पोर्ट पर चलेंगी।
उपरोक्त उदाहरण के साथ, हम देखते हैं कि हम तीन कंटेनरों को SSH का उपयोग करने दे सकते हैं। आंतरिक रूप से, कंटेनर के दृष्टिकोण से, यह हमेशा पोर्ट 22 है। बाहर से, पोर्ट नंबर कंटेनर के साथ-साथ सेवा दोनों की पहचान करते हैं। और यह एकमात्र टुकड़ा बन जाता है जिसे आपको जानने की आवश्यकता है, बिना पर्दे के पीछे क्या होता है उससे परेशान हुए।
इसका मतलब है कि आप कंटेनर बनाते समय स्क्रिप्ट तर्क या ऐसे किसी तरह का उपयोग करके डायनामिक रूप से होस्ट पोर्ट असाइन कर सकते हैं, और फिर उस जानकारी का उपयोग अपनी सर्विस पोर्ट की पहचान करने के लिए कर सकते हैं। इस प्रकार, होस्ट से कंटेनर नेटवर्किंग एक सरल और सुंदर मामला बन जाता है। और आप एक होस्ट से दूसरे होस्ट से भी जुड़ सकते हैं, फिर से, कंटेनर टोपोलॉजी को पहले से जाने बिना।
कंटेनर से होस्ट नेटवर्किंग
यह थोड़ा अधिक दिलचस्प टुकड़ा है। आपके कंटेनर एक लंबे समय तक चलने वाले उद्देश्य की सेवा कर सकते हैं, और इसलिए, उन्हें कुछ समय तक चालू और चलते रहने की आवश्यकता हो सकती है। बदले में, इसका मतलब है कि आपको कंटेनरों को बनाए रखना पड़ सकता है, जिसका अर्थ है अपग्रेड, पैचिंग, होस्ट्स फाइल अपडेट, और क्या नहीं। आप Chef, Puppet या Cfengine जैसे कॉन्फ़िगरेशन मैनेजमेंट टूल का भी उपयोग कर रहे होंगे, तो वह टुकड़ा भी है।
आपको जो पहला बड़ा प्रश्न पूछने की आवश्यकता है, वह है, क्या कंटेनर बाहरी दुनिया से संपर्क कर सकते हैं? खैर, हां। परिचय गाइड में, हमने आधिकारिक रिपॉजिटरी से सीधे CentOS अपडेट डाउनलोड किए, इसलिए हम जानते हैं कि यह टुकड़ा ठीक काम करता है। docker0 को पिंग करने के बारे में क्या:
दूसरा प्रश्न, क्या हम docker0 इंटरफ़ेस तक पहुंच सकते हैं, और फिर उसके होस्ट पोर्ट से कनेक्ट कर सकते हैं। मान लें कि किसी तरह हमें कंटेनर के अंदर आवश्यक जानकारी दी गई है।
telnet 172.17.42.1 49162 Trying 172.17.42.1... telnet: connect to address 172.17.42.1: No route to host
यह काम नहीं करेगा, क्योंकि हमने अपने होस्ट पर IP फ़ॉरवर्डिंग कॉन्फ़िगर नहीं की है। इसके अलावा, हमें आवश्यक ट्रैफ़िक की अनुमति देने के लिए फ़ायरवॉल नियमों की आवश्यकता होगी। यहां, यह थोड़ा जटिल हो जाता है, क्योंकि यदि आप iptables से परिचित नहीं हैं, तो आप कुछ हद तक संघर्ष करेंगे।
echo 1 > /proc/sys/net/ipv4/ip_forward
और iptables नियम - एक कुछ ढीला सेट, ध्यान दें (होस्ट पर):
iptables -t filter -A FORWARD -d 172.17.0.0/16 \ -o docker0 -j ACCEPT iptables -t filter -A FORWARD -s 172.17.0.0/16 \ -i docker0 -j ACCEPT iptables -t filter -A FORWARD -i docker0 -o docker0 -j ACCEPT iptables -t nat -A POSTROUTING -s 172.17.0.0/16 \ ! -d 172.17.0.0/16 -p tcp -j MASQUERADE --to-ports 1016-65535 \ iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -d 172.17.0.0/16 -p udp -j MASQUERADE --to-ports 1016-65535 \ iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -d 172.17.0.0/16 -j MASQUERADE
सबसे सरल विकल्प केवल फ़ायरवॉल को बंद करना है - या सभी को अनुमति देना। इसका अर्थ है आवश्यक कमांड चलाना, जो systemctl stop firewalld, iptables -F या समकक्ष हो सकता है। कुछ परिदृश्यों में, यह संभव नहीं हो सकता है, क्योंकि आपको अतिरिक्त सुरक्षा की आवश्यकता होती है। हालांकि, यह पहले उपयोग के मामले से भी जुड़ा हुआ है जिस पर हमने चर्चा की थी। अब, कल्पना करें कि आपको हर एक कंटेनर और उसकी संबंधित सेवाओं के लिए मैन्युअल नियम बनाने पड़ते।
सही नेटवर्किंग नियमों के साथ, आप होस्ट पोर्ट से कनेक्ट करने में सक्षम होंगे, जो प्रभावी रूप से अन्य कंटेनरों से बात करने का मतलब है, हालांकि विशिष्ट IP पते या पोर्ट में ऐसा कुछ भी नहीं है जिसके लिए लक्ष्य को दूसरा कंटेनर होना आवश्यक हो। इसके अलावा, आप होस्ट पर अन्य नेटवर्किंग उपकरणों से जुड़ने में भी सक्षम होंगे, या शायद दूरस्थ होस्ट भी।
कंटेनर से कंटेनर नेटवर्किंग
डेविड बॉवी के गीत की तरह, Ashes to Ashes, केवल उतना कूल नहीं। यह सबसे उपयोगी परिदृश्य लगता है। फिर से, हमारे पास दो विकल्प हैं। हम अन्य कंटेनरों से सीधे कनेक्ट करने का प्रयास कर सकते हैं, या हम docker0 डायनामिकली मैप्ड पोर्ट का उपयोग करने का प्रयास कर सकते हैं। हम धोखा देंगे। हम होस्ट और होस्ट पोर्ट को कंटेनरों में प्रवेश द्वार के रूप में उपयोग करेंगे। अब, पहली विधि काफी सीधी है। आइए net1 से net2 और net3 को पिंग करने का प्रयास करें।
यह बिना किसी समस्या के काम करता है। लेकिन मुद्दा यह है कि हम बाहरी दुनिया से IP पते जानते हैं! हमने इस जानकारी को कंटेनर के अंदर से प्राप्त नहीं किया है। वास्तव में, सुरक्षा कारणों के साथ-साथ इस तथ्य के कारण कि बेस कंटेनर एक अपेक्षाकृत छोटी इमेज है, डिफ़ॉल्ट रूप से आपके पास कोई बेहतरीन नेटवर्किंग टूल उपलब्ध नहीं हैं। आपके पास ifconfig यूटिलिटी भी उपलब्ध नहीं होगी। इसके अलावा, आप कंटेनरों के अंदर iptables में हेरफेर नहीं कर सकते:
iptables -L iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded.
इसलिए, docker0 तक पहुंचने और होस्ट पोर्ट से कनेक्ट करने की दूसरी विधि वास्तव में व्यवहार्य नहीं हो सकती है, क्योंकि हम कंटेनरों के भीतर से होस्ट फ़ायरवॉल नियमों में हेरफेर नहीं कर सकते। यही कारण है कि हम एक तीसरी विधि पर चर्चा करेंगे।
कंटेनर लिंक्स!
इसे करने का सही तरीका --link सुविधा का उपयोग करना है। इसका मतलब है, हम नए इंस्टेंस को स्पॉन करेंगे जबकि उन्हें अन्य, मौजूदा कंटेनरों से जोड़ेंगे। लिंक फ़ंक्शन लिंक किए गए कंटेनरों के होस्टनाम और IP पते को नए इंस्टेंस के वातावरण और /etc/hosts फाइल में डाल देगा। शायद यह थोड़ा भ्रमित करने वाला लगता है, तो आइए उदाहरण देते हैं:
docker run -d -ti -p 80 --name web image-4:latest 8e689d8ae3ef43eeab3bfa9cf523e1cc6658dae5fc665f8cbf889db17db46c26 docker inspect web | grep -i ipaddr "IPAddress": "172.17.0.9", nc -w1 -v 172.17.0.9 80 Ncat: Version 6.40 ( https://nmap.org/ncat ) Ncat: Connected to 172.17.0.9:80.
हमारे पास एक कंटेनर चल रहा है, और यह एक वेब सर्वर माना जाता है। अब, हम चाहते हैं कि क्लाइंट इसे एक्सेस कर सकें। हम IP पते के बजाय सर्वर नाम का उपयोग करना चाहते हैं, क्योंकि हमारे पास टोपोलॉजी का कोई पूर्व ज्ञान नहीं हो सकता है। इसके अलावा, नाम उपयोगी हैं क्योंकि वे हमें नेटवर्क लेआउट बदलने की अनुमति देते हैं। वास्तव में, आइए एक क्लाइंट कंटेनर बनाएं और इसे हमारे वेब सर्वर से लिंक करें:
docker run -ti --name client --link web:web image-4:latest /bin/bash
यहां हमारे पास निम्नलिखित है। हम source:target का लिंक बना रहे हैं। दूसरे शब्दों में, web नामक सर्वर (कंटेनर) हमारे नए कंटेनर के अंदर web के रूप में दृश्यमान होगा जिसे client नाम दिया गया है। यदि आप कंटेनर को स्पॉन करते हैं और फिर उससे अटैच करते हैं, तो आप BASH शेल में env कमांड चलाकर वातावरण की जांच कर सकते हैं:
WEB_PORT_80_TCP_PORT=80 WEB_PORT_80_TCP=tcp://172.17.0.9:80 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ WEB_PORT_22_TCP_ADDR=172.17.0.9 container_uuid=558a9db0-6d1e-d9d2-b62d-a8dbfbad0b2d WEB_PORT_22_TCP=tcp://172.17.0.9:22 SHLVL=1 HOME=/root WEB_NAME=/client/web WEB_PORT_80_TCP_PROTO=tcp WEB_PORT_80_TCP_ADDR=172.17.0.9 LESSOPEN=||/usr/bin/lesspipe.sh %s WEB_PORT=tcp://172.17.0.9:22 _=/usr/bin/env
चूंकि वही नाम मैपिंग भ्रमित करने वाली हो सकती है, आइए एक अलग मैपिंग आज़माएं:
docker run -ti --name client --link web:dedoimedo image-4:latest /bin/bash
और फिर हमें मिलता है:
वैकल्पिक रूप से, यदि आप ऐसे कंटेनर स्पॉन कर रहे हैं जिन्हें केवल त्वरित कार्यकर्ता होने की आवश्यकता है, तो आप run --rm विकल्प का उपयोग करके उन्हें बनाने पर विचार कर सकते हैं। छोटे कार्यों के लिए, कंटेनर फाइलों को डिस्क पर रखने का कोई कारण नहीं है, और आप डॉकर को कंटेनर के बाहर निकलने पर स्वचालित रूप से उन्हें साफ़ करने और फाइल सिस्टम को हटाने के लिए कह सकते हैं। आधिकारिक दस्तावेज पढ़ना:
डिफ़ॉल्ट रूप से एक कंटेनर का फाइल सिस्टम कंटेनर के बाहर निकलने के बाद भी बना रहता है। इससे डीबगिंग बहुत आसान हो जाती है (क्योंकि आप अंतिम स्थिति का निरीक्षण कर सकते हैं) और आप डिफ़ॉल्ट रूप से अपना सारा डेटा बरकरार रखते हैं। लेकिन अगर आप शॉर्ट-टर्म फोरग्राउंड प्रक्रियाएं चला रहे हैं, तो ये कंटेनर फाइल सिस्टम वास्तव में जमा हो सकते हैं। यदि आप चाहें कि डॉकर कंटेनर के बाहर निकलने पर कंटेनर को स्वचालित रूप से साफ़ करे और फाइल सिस्टम को हटा दे, तो आप --rm फ्लैग जोड़ सकते हैं।
docker run --rm -ti --name client --link web:dedoimedo image-4:latest /bin/bash
होस्ट्स फाइल
लिंक फ़ंक्शन के बारे में दूसरी अच्छी बात यह है कि नए कंटेनरों की /etc/hosts फाइल स्वचालित रूप से आवश्यक नामों से भर जाएगी, इसलिए आप एक ट्रीट के लिए तैयार हैं। यह नीचे दी गई तरह दिखेगी, IPv6 प्रविष्टियों को हटा दिया गया है:
[root@e1e92f6918dd /]# cat /etc/hosts 172.17.0.11 e1e92f6918dd 127.0.0.1 localhost 172.17.0.9 dedoimedo 8e689d8ae3ef web
इसके नाम का उपयोग करके सर्वर से कनेक्ट करें
और चूंकि हमारे पास होस्ट नाम रिज़ॉल्यूशन और वातावरण सेटिंग्स हैं, यह कहीं भी किसी भी नेटवर्किंग की तरह हो जाता है। वास्तव में सरल, यादगार और सबसे महत्वपूर्ण, स्क्रिप्टेबल।
अधिक पठन
यदि आपको नहीं लगता कि आपको पर्याप्त मज़ा आया है, तो:
डॉकर उन्नत नेटवर्किंग गाइड
