मैं एक बड़े वादे के साथ शुरुआत करता हूं। आज का यह लेख आपको बिल्कुल पसंद आएगा। यह लंबा, विस्तृत और अत्यधिक उपयोगी होने वाला है। GRUB सोचो, GRUB2। यहाँ भी वही। केवल हम डॉकटर से निपटेंगे, एक अच्छा वितरण मंच जो लिनक्स कंटेनर (LXC) तकनीक को सरल, सुविधाजनक तरीके से लपेटता है।
मैं आपको दिखाऊंगा कि शुरुआत कैसे करें, और फिर हम SSH और Apache के साथ अपने खुद के कंटेनर बनाएंगे, Dockerfiles का उपयोग करना सीखेंगे, सर्विस पोर्ट्स को उजागर करेंगे, और बड़ी संख्या में छोटे बग और समस्याओं को हल करेंगे जो आम तौर पर सार्वजनिक मंचों पर कभी संबोधित नहीं होते हैं। . कृपया, आगे की हलचल के बिना, मुझे फॉलो करें।
सामग्री तालिका
- परिचय
- डॉकर कार्यान्वयन
- प्रारंभ करना
- डॉकर कमांड्स
- छवि खींचो
- डॉकटर कंटेनर शुरू करें
- अपाचे और एसएसएच स्थापित करें <ओल>
- सेवा प्रारंभ करें
- अपाचे सेवा
- SSH सेवा
- जांचें कि क्या वेब सर्वर काम कर रहा है <ओल>
- इनकमिंग पोर्ट्स को एक्सपोज़ करें
- आईपी पता जांचें
- नए कॉन्फ़िगरेशन का परीक्षण कर रहा है
- जांचें कि क्या SSH काम करता है <ओल>
- रुको, रूट पासवर्ड क्या है?
- कमिट इमेज
- डॉकरफाइल <ओल>
- इमेज बनाएं
- टेस्ट इमेज
- वैकल्पिक निर्माण <ओल>
- निर्देश कॉपी करें
- कंटेनरों के फायदे
- आपके सामने आने वाली समस्याएं और समस्या निवारण
- अतिरिक्त आदेश <ओल>
- निष्पादन और अनुलग्न के बीच अंतर
- स्टार्ट और रन के बीच अंतर
- बनाने और बनाने के बीच अंतर
- यह तो बस शुरुआत है...
- और पढ़ना
- निष्कर्ष
- -p 80 कंटेनर पोर्ट 80 को उजागर करेगा। यह स्वचालित रूप से होस्ट पर एक यादृच्छिक पोर्ट पर मैप किया जाएगा। हम बाद में सीखेंगे कि सही पोर्ट की पहचान कैसे करें।
- -p 80:80 कंटेनर पोर्ट को होस्ट पोर्ट 80 पर मैप करेगा। इसका मतलब है कि आपको कंटेनर के आंतरिक आईपी पते को जानने की आवश्यकता नहीं है। इसमें आंतरिक NAT का एक तत्व शामिल है, जो डॉकर वर्चुअल इंटरफ़ेस से होकर जाता है। हम जल्द ही इस पर चर्चा करेंगे। इसके अलावा, यदि आप इस विधि का उपयोग करते हैं, तो केवल एक ही कंटेनर पोर्ट 80 से जुड़ने में सक्षम होगा। यदि आप विभिन्न आईपी पतों के साथ कई वेब सर्वर का उपयोग करना चाहते हैं, तो आपको प्रत्येक को एक अलग पोर्ट पर सेट करना होगा।
- The FROM directory tells us what repo:tag to use as the baseline. In our case, it's one of the committed images that already contains the httpd and sshd binaries, SSH keys, and a bit more.
- EXPOSE 22 - This line exposes port 22 inside the container. We can map it further using the -p option at runtime. The same is true for EXPOSE 80, which is relevant for the Web server.
- CMD ["/usr/sbin/sshd", "-D"] - This instructions runs an executable, with optional arguments. It is as simple as that.
- RUN mkdir -p /run/httpd - This instruction runs a command in a new layer on top of the base image - and COMMITS the results. This is very important to remember, as we will soon discuss what happens if you don't use the RUN mkdir thingie with Apache.
- CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"] - We run the server, in the foreground. The last bit is optional, but for the time being, you can start Apache this way. काफी है।
परिचय
मैंने पिछले साल Gizmo के फ्रीवेयर लेख में तकनीक का एक संक्षिप्त विवरण दिया है। अब, हम डॉकर का उपयोग करने के बारे में गंभीर होने जा रहे हैं। सबसे पहले, यह याद रखना महत्वपूर्ण है कि यह ढांचा आपको सभी छोटे विवरणों के बारे में चिंता किए बिना सुविधाजनक तरीके से एलएक्ससी का उपयोग करने की अनुमति देता है। यह इस दुनिया में अगला कदम है, उसी तरह ओपनस्टैक वर्चुअलाइजेशन दुनिया में अगला विकासवादी कदम है। मैं आपको कुछ इतिहास और उपमाएँ देता हूँ।
वर्चुअलाइजेशन सॉफ्टवेयर के साथ शुरू हुआ जो आपको अपने हार्डवेयर को अमूर्त करने देता है। फिर, चीज़ों को तेज़ करने के लिए, वर्चुअलाइज़ेशन प्रोग्राम ने हार्डवेयर त्वरण का उपयोग करना शुरू किया, और फिर आपको पैरावर्चुअलाइज़ेशन भी मिला। अंत में, हाइपरवाइज़र बारिश के बाद मशरूम की तरह उभरने लगे, और उन सभी को व्यवस्थित और प्रबंधित करना थोड़ा मुश्किल हो गया। यह ओपनस्टैक जैसी अवधारणाओं का मुख्य कारण है, जो एकीकृत एपीआई के तहत विभिन्न प्लेटफार्मों को छिपाते हैं।
कंटेनरों ने इसी तरह अपना रास्ता शुरू किया। सबसे पहले, हमारे पास चेरोट था, लेकिन जेल में बंद वातावरण के अंदर चल रही प्रक्रियाओं ने समान नाम स्थान साझा किया और समान संसाधनों के लिए संघर्ष किया। फिर, हमें kexec सिस्टम कॉल मिला, जो हमें BIOS से गुजरे बिना दूसरे कर्नेल के संदर्भ में बूट करने देता है। फिर, नियंत्रण समूह आए, जिससे हमें सिस्टम संसाधनों जैसे सीपीयू, मेमोरी और अन्य को उपसमूहों में विभाजित करने की अनुमति मिली, इस प्रकार बेहतर नियंत्रण की अनुमति मिली, इसलिए सिस्टम पर चलने वाली प्रक्रियाओं का नाम।
बाद में, लिनक्स कर्नेल ने मूल विभाजन तंत्र के रूप में cgroups का उपयोग करते हुए संसाधनों के पूर्ण अलगाव की पेशकश शुरू कर दी। तकनीकी रूप से, यह एक सिस्टम-स्तरीय वर्चुअलाइजेशन तकनीक है, जो आपको बहुत कम प्रदर्शन पेनल्टी और ओवरहेड के अतिरिक्त बोनस के साथ स्व-निहित वातावरण के अंदर कंट्रोल होस्ट के शीर्ष पर चल रहे कर्नेल के कई उदाहरणों को चलाने की अनुमति देती है।
कई प्रतिस्पर्धी प्रौद्योगिकियों ने ओपनवीजेड जैसे समान समाधानों की पेशकश करने की कोशिश की, लेकिन समुदाय ने अंततः मेनलाइन कर्नेल के अंदर मूल सक्षमता पर अपना ध्यान केंद्रित किया, और यह भविष्य की दिशा प्रतीत होती है। फिर भी, LXC का उपयोग करना कुछ कठिन है, क्योंकि कंटेनरों को चलाने के लिए उचित मात्रा में तकनीकी ज्ञान और स्क्रिप्टिंग की आवश्यकता होती है।
यहीं पर डॉकर की जगह आती है। यह किरकिरा टुकड़ों को दूर करने की कोशिश करता है और बुनियादी ढांचे के बैकएंड के बारे में चिंता किए बिना नए कंटेनर उदाहरणों को पैदा करने का एक सरल तरीका पेश करता है। हां तकरीबन। लेकिन कठिनाई का स्तर काफी कम है।
डॉकर का एक और मजबूत लाभ व्यापक सामुदायिक स्वीकृति है, साथ ही क्लाउड सेवाओं के साथ एकीकरण पर जोर है। यहां हम पूरी चर्चा करते हैं, और इसका मतलब है कि AWS, Hadoop, Azure, Jenkins और अन्य जैसे कुछ बड़े खिलाड़ियों का नामकरण। फिर हम Platform as a Service (Paas) के बारे में भी बात कर सकते हैं, और आप कल्पना कर सकते हैं कि आने वाले वर्षों में इसे कितना पैसा और फोकस मिलने वाला है। तकनीकी परिदृश्य बहुत बड़ा और भ्रमित करने वाला है, और यह निश्चित रूप से बदलता और विकसित होता रहेगा, जिसमें अधिक से अधिक अवधारणाएं और आवरण प्रौद्योगिकियां जीवन में आ रही हैं और डॉकर के शीर्ष पर निर्माण कर रही हैं।
लेकिन हम तकनीकी पक्ष पर ध्यान देना चाहते हैं। एक बार जब हम बुनियादी में महारत हासिल कर लेते हैं, तो हम धीरे-धीरे विस्तार करेंगे और मजबूत एकीकरण क्षमताओं, समाधान के लचीलेपन का उपयोग करना शुरू कर देंगे, और अपने क्लाउड इकोसिस्टम विशेषज्ञता को विविध, स्वचालित और शुद्ध रेड बनाने पर काम करेंगे। यह अभी नहीं होगा, लेकिन मैं आपको पहले कुछ मील, या हमें कहना चाहिए कि मैला स्टार्टअप पानी के किलोमीटर को नेविगेट करने में मदद करना चाहता हूं, ताकि आप एक समझदार, कुशल तरीके से डॉकर का उपयोग शुरू कर सकें। चूंकि यह एक युवा तकनीक है, यह वाइल्ड वेस्ट है, और अधिकांश ऑनलाइन दस्तावेज, टिप्स, ट्यूटोरियल और क्या नहीं पुराने हैं, कॉपी और पेस्ट संस्करण हैं जो किसी की मदद नहीं करते हैं, और काफी हद तक अधूरे हैं। मैं आज इसे ठीक करना चाहता हूं।
डॉकर कार्यान्वयन
इससे पहले कि हम कुछ अच्छी चीजें करें, थोड़ा और उबाऊ सामान। किसी भी तरह, डॉकर ज्यादातर एलएक्ससी के बारे में है, लेकिन सिर्फ इतना ही नहीं। इसे एक्स्टेंसिबल होने के लिए डिज़ाइन किया गया है, और यह libvirt और systemd के साथ इंटरफेस भी कर सकता है। एक तरह से, यह इसे लगभग एक हाइपर-हाइपरवाइजर की तरह बनाता है, क्योंकि इसमें भविष्य के विकास की संभावना है, और जब अतिरिक्त मॉड्यूल जोड़े जाते हैं, तो यह प्रभावी रूप से क्लासिक हाइपरवाइजर जैसे Xen या KVM या कुछ भी libvirt और दोस्तों का उपयोग कर सकता है।
यदि आप सोच रहे हैं तो यह एक सार्वजनिक डोमेन छवि है।
प्रारंभ करना
हम CentOS 7 का उपयोग करके प्रदर्शित करेंगे। Ubuntu नहीं। अधिकांश ऑनलाइन सामग्री उबंटू पर केंद्रित है, लेकिन मैं आपको दिखाना चाहता हूं कि लिनक्स के जितना संभव हो उतना निकट-उद्यम स्वाद का उपयोग करके यह कैसे किया जाता है, क्योंकि यदि आप डॉकर का उपयोग करने जा रहे हैं, तो यह कहीं न कहीं व्यवसाय जैसा होगा। पहली बात डॉकर को स्थापित करना है:
yum install docker-io
एक बार सॉफ्टवेयर इंस्टॉल हो जाने के बाद, आप इसका उपयोग शुरू कर सकते हैं। हालाँकि, जब आप पहली बार डॉकर कमांड चलाने का प्रयास करते हैं तो आपको निम्नलिखित दो समस्याओं का सामना करना पड़ सकता है:
डॉकर <कोई एक कमांड>
फाटा [0000] https:///var/run/docker.sock/v1.18/images/json प्राप्त करें:डायल यूनिक्स /var/run/docker.sock:ऐसी कोई फ़ाइल या निर्देशिका नहीं। क्या आप टीएलएस के बिना टीएलएस-सक्षम डेमन से जुड़ने की कोशिश कर रहे हैं?
और दूसरी त्रुटि है:
डॉकर <कोई एक कमांड>
FATA [0000] https:///var/run/docker.sock/v1.18/containers/json प्राप्त करें:डायल यूनिक्स /var/run/docker.sock:अनुमति अस्वीकृत। क्या आप टीएलएस के बिना टीएलएस-सक्षम डेमन से जुड़ने की कोशिश कर रहे हैं?
इसका कारण यह है कि आपको पहले डॉकर सेवा प्रारंभ करने की आवश्यकता है। इसके अलावा, आपको तकनीक को रूट के रूप में चलाना चाहिए, क्योंकि डॉकर को सिस्टम के कुछ संवेदनशील हिस्सों तक पहुंच की आवश्यकता होती है, और कर्नेल के साथ इंटरैक्ट करता है। यह वैसे काम करता है।
systemctl start docker
अब हम पागल हो सकते हैं और डॉकर का उपयोग करना शुरू कर सकते हैं।
डॉकर कमांड
कमांड की उपलब्ध सूची प्राप्त करने के लिए डॉकर सहायता चलाने के लिए मूल बात है। मैं सभी विकल्पों से नहीं गुजरूंगा। जैसे-जैसे हम आगे बढ़ेंगे, हम उनके बारे में और जानेंगे। सामान्य तौर पर, यदि आप कभी संदेह में हों, तो आपको बहुत अच्छे ऑनलाइन दस्तावेज़ीकरण से परामर्श लेना चाहिए। पूरा सीएलआई संदर्भ भी गधे को मारता है। और फिर, GitHub पर एक उत्कृष्ट चीट शीट भी है। लेकिन हमारा पहला मिशन एक नई डॉकर इमेज डाउनलोड करना और फिर अपना पहला उदाहरण चलाना होगा।
छवि खींचो
कई उपलब्ध चित्र हैं। हम CentOS के साथ अभ्यास करना चाहते हैं। यह एक अच्छा शुरुआती बिंदु है। एक आधिकारिक भंडार उपलब्ध है, और यह सभी समर्थित छवियों और टैगों को सूचीबद्ध करता है। दरअसल, इस बिंदु पर, हमें यह समझने की जरूरत है कि डॉकर छवियों को कैसे लेबल किया जाता है।
नामकरण परिपाटी भंडार है:टैग, उदाहरण के लिए सेंटोस:नवीनतम। दूसरे शब्दों में, हम नवीनतम CentOS छवि चाहते हैं। लेकिन आवश्यक छवि सेंटोस भी हो सकती है:6.6। ठीक है, इसे करते हैं।
अब डॉकर इमेज कमांड चलाकर छवियों को सूचीबद्ध करते हैं:
डॉकटर कंटेनर शुरू करें
जैसा कि हमने अपने मूल ट्यूटोरियल में देखा है, सबसे सरल उदाहरण शेल चलाना है:
डॉकर रन -टी सेंटोस:सेंटोस 7 / बिन / बैश
तो हमें यहां क्या करना है? हम अपने स्वयं के TTY (-t) और STDIN (-i) के साथ CentOS 7 इमेज से BASH शेल के साथ एक नया कंटेनर इंस्टेंस चला रहे हैं। कुछ सेकंड के बाद, आपको कंटेनर के अंदर एक नया खोल मिलेगा। अब, यह एक बहुत ही बुनियादी, बहुत ही कमजोर ऑपरेटिंग सिस्टम है, लेकिन आप इसके अंदर चीजों का निर्माण शुरू कर सकते हैं।
Apache और SSH इंस्टॉल करें
चलिए एक वेब सर्वर सेटअप करते हैं, जिसमें एसएसएच एक्सेस भी होगा। यह अंत करने के लिए, हमें कुछ बल्कि बुनियादी संस्थापन करने की आवश्यकता होगी। अपाचे (httpd) और एसएसएचडी (ओपनश-सर्वर) को पकड़ो, और उन्हें कॉन्फ़िगर करें। इसका डॉकर से कोई लेना-देना नहीं है, लेकिन यह एक उपयोगी अभ्यास है।
कैसे, आप में से कुछ चिल्ला सकते हैं, प्रतीक्षा करें, आपको एक कंटेनर के अंदर SSH की आवश्यकता नहीं है, यह एक सुरक्षा जोखिम है और क्या नहीं। ठीक है, हो सकता है, हाँ और नहीं, आपको क्या चाहिए और आप कंटेनर का उपयोग करने का क्या इरादा रखते हैं। लेकिन आइए सुरक्षा के विचारों को एक तरफ छोड़ दें। अभ्यास का उद्देश्य यह सीखना है कि किसी भी सेवा को कैसे सेटअप और चलाना है।
सेवा शुरू करें
आप अपने अपाचे को init स्क्रिप्ट या सिस्टमड कमांड का उपयोग करके शुरू करना चाह सकते हैं। यह काफी काम नहीं करेगा। विशेष रूप से CentOS के लिए, यह सिस्टमड के साथ आता है, लेकिन इससे भी महत्वपूर्ण बात यह है कि कंटेनर का अपना सिस्टमड नहीं होता है। यदि आप प्रयास करते हैं, तो आदेश विफल हो जाएँगे।
systemctl httpd प्रारंभ करें
डी-बस कनेक्शन प्राप्त करने में विफल:सेवा प्रबंधक से कोई संबंध नहीं।
इस समस्या के समाधान हैं, और हम भविष्य के ट्यूटोरियल में इनमें से कुछ के बारे में सीखेंगे। लेकिन सामान्य तौर पर, कंटेनरों की हल्की और सरल प्रकृति को देखते हुए, आपको अपनी प्रक्रियाओं को चलाने के लिए पूरी तरह से स्टार्टअप सेवा की आवश्यकता नहीं होती है। यह कुछ जटिलता जोड़ता है।
अपाचे सेवा
Apache (HTTPD) को चलाने के लिए, बस अपने डिस्ट्रो में /usr/sbin/httpd - या इसके समकक्ष कमांड निष्पादित करें। सेवा शुरू होनी चाहिए, सबसे अधिक संभावना एक चेतावनी के साथ कि आपने httpd.conf में अपने ServerName निर्देश को कॉन्फ़िगर नहीं किया है। हमने सीखा है कि यह कैसे करना है मेरे व्यापक अपाचे गाइड में।
/usr/sbin/httpd
AH00558:httpd:172.17.0.4 का उपयोग करते हुए, सर्वर के पूरी तरह से योग्य डोमेन नाम का विश्वसनीय रूप से निर्धारण नहीं कर सका। इस संदेश को दबाने के लिए विश्व स्तर पर 'सर्वरनाम' निर्देश सेट करें
एसएसएच सेवा
SSHD के साथ, /usr/sbin/sshd चलाएँ।
/usr/sbin/sshd -f /etc/ssh/sshd_config
होस्ट कुंजी लोड नहीं कर सका:/etc/ssh/ssh_host_rsa_key
होस्ट कुंजी लोड नहीं कर सका:/etc/ssh/ssh_host_dsa_key
होस्ट कुंजी लोड नहीं कर सका:/etc/ssh/ssh_host_ecdsa_key
होस्ट कुंजी लोड नहीं कर सका:/etc/ssh/ssh_host_ed25519_key
तुम भी असफल हो जाओगे, क्योंकि तुम्हारे पास सारी चाबियां नहीं होंगी। आम तौर पर, स्टार्टअप स्क्रिप्ट इसे लेती है, इसलिए सेवा के सही ढंग से शुरू होने से पहले आपको एक बार ssh-keygen कमांड चलाने की आवश्यकता होगी। दोनों में से कोई एक कमांड काम करेगी:
/usr/bin/ssh-keygen -t rsa -f <फ़ाइल का पथ>
/usr/bin/ssh-keygen -A
ssh-keygen:नई होस्ट कुंजियाँ बनाना:RSA1 RSA DSA ECDSA ED25519
जांचें कि क्या वेब सर्वर चालू है
अब, कंटेनर के अंदर, हम देख सकते हैं कि अपाचे वास्तव में चल रहा है।
ps -ef|grep apache
अपाचे 87 86 0 10:47 ? 00:00:00 /usr/sbin/httpd
अपाचे 88 86 0 10:47 ? 00:00:00 /usr/sbin/httpd
अपाचे 89 86 0 10:47 ? 00:00:00 /usr/sbin/httpd
अपाचे 90 86 0 10:47 ? 00:00:00 /usr/sbin/httpd
अपाचे 91 86 0 10:47 ? 00:00:00 /usr/sbin/httpd
लेकिन क्या होगा अगर हम बाहरी कनेक्टिविटी की जांच करना चाहते हैं? इस बिंदु पर, हमारे हाथ में कुछ समस्याएं हैं। एक, हमने बोलने के लिए कोई खुला बंदरगाह स्थापित नहीं किया है। दो, हम नहीं जानते कि हमारे कंटेनर का आईपी पता क्या है। अब, यदि आप ifconfig को BASH शेल के अंदर चलाने का प्रयास करते हैं, तो आप कहीं नहीं पहुंचेंगे, क्योंकि बुनियादी नेटवर्किंग कमांड वाले आवश्यक पैकेज को स्थापित नहीं किया गया है। अच्छा है, क्योंकि यह हमारे कंटेनर को पतला और सुरक्षित बनाता है।
इनकमिंग पोर्ट्स को एक्सपोज़ करें
किसी भी वेब सर्वर की तरह, हमें इनकमिंग कनेक्शन की अनुमति देनी होगी। हम डिफ़ॉल्ट पोर्ट 80 का उपयोग करेंगे। यह आपके राउटर में पोर्ट फ़ॉरवर्डिंग से अलग नहीं है, फ़ायरवॉल नीतियों की अनुमति देता है और क्या नहीं। डॉकर के साथ, वांछित परिणाम प्राप्त करने के कई तरीके हैं।
रन कमांड के साथ एक नया कंटेनर शुरू करते समय, आप -p विकल्प का उपयोग यह निर्दिष्ट करने के लिए कर सकते हैं कि कौन से पोर्ट को खोलना है। आप एकल पोर्ट या पोर्ट की श्रेणी चुन सकते हैं, और आप होस्ट पोर्ट (होस्टपोर्ट) और कंटेनर पोर्ट (कंटेनरपोर्ट) दोनों को मैप कर सकते हैं। उदाहरण के लिए:
डॉकर रन -टी -पी 22:22 -पी 80:80 छवि -1:नवीनतम
FATA [0000] डेमन से त्रुटि प्रतिक्रिया:कंटेनर 64bd520e2d95a699156f5d40331d1aba972039c3c201a97268d61c6ed17e1619 शुरू नहीं कर सकता:0.0.0.0:80 के लिए बाइंड विफल:पोर्ट पहले से ही आवंटित है
कई अतिरिक्त विचार हैं। IP फ़ॉरवर्डिंग, ब्रिज किए गए नेटवर्क, सार्वजनिक और निजी नेटवर्क, सबनेट रेंज, फ़ायरवॉल नियम, लोड संतुलन, और बहुत कुछ। फिलहाल हमें इनके बारे में चिंता करने की जरूरत नहीं है।
हम पोर्ट को कैसे उजागर कर सकते हैं, इसका एक अतिरिक्त तरीका भी है, लेकिन हम उस पर बाद में चर्चा करेंगे, जब हम डॉकरफाइल्स के विषय पर बात करेंगे, जो नई छवियों के निर्माण के लिए टेम्प्लेट हैं। अभी के लिए, हमें अपनी छवियों को -p विकल्प के साथ चलाना याद रखना होगा।
आईपी पता जांचें
अगर आप अपने होस्ट पोर्ट्स को फ्री छोड़ना चाहते हैं, तो आप होस्टपोर्ट पीस को छोड़ सकते हैं। उस स्थिति में, आप इसके आईपी पते और वेब सर्वर पोर्ट का उपयोग करके सीधे कंटेनर से जुड़ सकते हैं। ऐसा करने के लिए, हमें अपने कंटेनर विवरण की गणना करने की आवश्यकता है:
डॉकर निरीक्षण <कंटेनर का नाम या आईडी>
यह विवरण की एक बहुत लंबी सूची देगा, बहुत कुछ KVM XML कॉन्फ़िगरेशन की तरह, सिवाय इसके कि एक JSON में लिखा गया है, जो डेटा के लिए एक और आधुनिक और बदसूरत प्रारूप है। पठनीय लेकिन बेहद बदसूरत।
डॉकर विचलित_यूक्लिड का निरीक्षण करता है
[{
"AppArmorProfile":"",
"आर्ग्स":[],
"विन्यास":{
"अटैच स्टेडर":सच,
"अटैचस्टडिन":सच,
"अटैचस्टडआउट":सच,
"सीएमडी":[
"/ बिन/बैश"
],
"सीपीयूशेयर":0,
"सीपीसेट":"",
"डोमेन नाम":"",
"एंट्रीपॉइंट":अशक्त,
"ईएनवी":[
...
"एक्सपोज्डपोर्ट्स":{
"80/टीसीपी":{}
},
"होस्टनाम":"43b179c5aec7",
"इमेज":"सेंटोस:सेंटोस7",
"लेबल":{},
"मैक पते":"",
...
हम इसे केवल IP पते तक सीमित कर सकते हैं।
डॉकर निरीक्षण <कंटेनर का नाम या आईडी> | ग्रेप -i "ipaddr"
"आईपीएड्रेस":"172.17.0.20",
नए कॉन्फिगरेशन का परीक्षण
चलिए नए सिरे से शुरू करते हैं। एक नया उदाहरण लॉन्च करें, अपाचे सेटअप करें, इसे शुरू करें। एक वेब ब्राउज़र खोलें और परीक्षण करें। यदि यह काम करता है, तो आपने अपने वेब सर्वर को ठीक से कॉन्फ़िगर किया है। ठीक वैसा ही जैसा हम चाहते थे।
डॉकर रन-इट-पी 80:80 सेंटोस:सेंटोस 7/बिन/बैश
यदि हम चल रहे कंटेनर की जांच करते हैं, तो हम पोर्ट मैपिंग देख सकते हैं - संक्षिप्तता के लिए आउटपुट कई पंक्तियों में विभाजित है, इसलिए कृपया क्षमा करें। आम तौर पर, सभी अपरकेस शीर्षक पंक्ति शीर्षलेख के रूप में दिखाई देंगे, और फिर, आपको बाकी सभी नीचे मुद्रित मिलेंगे, प्रति पंक्ति एक कंटेनर।
# डॉकटर पीएस
कंटेनर आईडी इमेज कमांड
43b179c5aec7 centos:centos7 "/bin/bash"
बनाया गया स्थिति बंदरगाह
2 घंटे पहले 2 घंटे तक 0.0.0.0:80->80/tcp
नाम विचलित_यूक्लिड
और ब्राउज़र में हमें मिलता है:
वैकल्पिक:अब, आंतरिक IP पता श्रेणी केवल होस्ट पर ही पहुंच योग्य होगी। यदि आप इसे अन्य मशीनों से एक्सेस करना चाहते हैं, तो आपको अपने NAT और IP अग्रेषण की आवश्यकता होगी। और यदि आप नामों का उपयोग करना चाहते हैं, तो आपको /etc/hosts के साथ-साथ DNS को ठीक से कॉन्फ़िगर करने की आवश्यकता होगी। कंटेनर के लिए, यह एक नया उदाहरण चलाते समय --add-host="host:IP" निर्देश का उपयोग करके किया जा सकता है।
एक और नोट:याद रखें कि डॉकर की अपनी आंतरिक नेटवर्किंग है, वर्चुअलबॉक्स और केवीएम की तरह, जैसा कि हमने अपने अन्य ट्यूटोरियल्स में देखा है। यह काफी व्यापक /16 नेटवर्क है, इसलिए आपके पास काफी स्वतंत्रता है। होस्ट पर:
# /sbin/ifconfig
docker0:झंडे =4163 <यूपी, ब्रॉडकास्ट, रनिंग, मल्टीकास्ट> एमटीयू 1500
आईनेट 172.17.42.1 नेटमास्क 255.255.0.0 प्रसारण 0.0.0.0
inet6 fe80::5484:7aff:fefe:9799 prefixlen 64 scopeid 0x20
ईथर 56:84:7a:fe:97:99 txqueuelen 0 (ईथरनेट)
RX पैकेट 6199 बाइट्स 333408 (325.5 KiB)
RX त्रुटियाँ 0 गिरा 0 ओवररन 0 फ़्रेम 0
TX पैकेट 11037 बाइट्स 32736299 (31.2 MiB)
TX त्रुटियां 0 गिरा 0 ओवररन 0 वाहक 0 टक्कर 0
जांचें कि क्या SSH काम करता है
हमें एसएसएच के साथ भी यही अभ्यास करने की जरूरत है। दोबारा, इसका मतलब पोर्ट 22 को उजागर करना है, और हमारे पास कई विकल्प उपलब्ध हैं। इसे और अधिक रोचक बनाने के लिए, आइए यादृच्छिक पोर्ट असाइनमेंट के साथ प्रयास करें:
डॉकर रन-टी-पी 20-पी 80 सेंटोस:सेंटोस 7/बिन/बैश
और अगर हम docker ps से जाँच करें, विशेष रूप से बंदरगाहों के लिए:
0.0.0.0:49176->22/tcp, 0.0.0.0:49177->80/tcp Boring_mcclintock
इसका मतलब है कि आप docker0 IP पते से कनेक्ट कर सकते हैं, जैसा कि docker ps कमांड आउटपुट में ऊपर निर्दिष्ट है, और यह वास्तव में कंटेनर IP से सीधे उनके सर्विस पोर्ट पर कनेक्ट करने के बराबर है। यह उपयोगी हो सकता है, क्योंकि आपको अपने कंटेनर द्वारा उपयोग किए जाने वाले आंतरिक आईपी पते के बारे में चिंता करने की आवश्यकता नहीं है, और यह अग्रेषण को आसान बना सकता है। अब, आइए कनेक्ट करने का प्रयास करें। हम होस्ट पोर्ट का उपयोग कर सकते हैं, या हम सीधे कंटेनर आईपी का उपयोग कर सकते हैं।
एसएसएच 172.17.42.1 -पी 49117
किसी भी तरह से, हमें वह मिलेगा जो हमें चाहिए, उदाहरण के लिए:
एसएसएच 172.17.0.5
होस्ट '172.17.0.5 (172.17.0.5)' की प्रामाणिकता स्थापित नहीं की जा सकती। ECDSA कुंजी फिंगरप्रिंट 00:4b:de:91:60:e5:22:cc:f7:89:01:19:3e:61:cb:ea है।
क्या आप वाकई कनेक्ट करना जारी रखना चाहते हैं (हां/नहीं)? हां
चेतावनी:ज्ञात मेजबानों की सूची में स्थायी रूप से '172.17.0.5' (ECDSA) जोड़ा गया।
root@172.17.0.5 का पासवर्ड:
रुको, रूट पासवर्ड क्या है?
हम असफल होंगे क्योंकि हमारे पास रूट पासवर्ड नहीं है। तो अब हम क्या करें? दोबारा, हमारे पास कई विकल्प हैं। सबसे पहले, पासवार्ड कमांड का उपयोग करके कंटेनर के अंदर रूट पासवर्ड बदलने का प्रयास करें। लेकिन यह काम नहीं करेगा, क्योंकि पासवार्ड यूटिलिटी स्थापित नहीं है। फिर हम आवश्यक RPM को पकड़ सकते हैं और इसे कंटेनर के अंदर सेट कर सकते हैं। होस्ट पर, निर्भरताओं की जाँच करें:
rpm -q --क्या प्रदान करता है /etc/passwd
सेटअप-2.8.71-5.el7.noarch
लेकिन यह एक सुरक्षा भेद्यता है। हम चाहते हैं कि हमारे कंटेनर दुबले हों। तो हम कंटेनर में होस्ट पर /etc/shadow से पासवर्ड हैश कॉपी कर सकते हैं। बाद में, हम इसे करने के अधिक सुव्यवस्थित तरीके के बारे में जानेंगे।
एक और बात जो बहुत स्पष्ट रूप से प्रहार करती है वह यह है कि हम अपने सभी कार्यों को दोहरा रहे हैं। यह कुशल नहीं है, और यही कारण है कि हम अपने कंटेनर में किए गए परिवर्तनों को सुरक्षित रखना चाहते हैं। अगला खंड इसे संभालता है।
कमिट इमेज
कंटेनर में बदलाव करने के बाद, हो सकता है कि आप इसे कमिट करना चाहें। दूसरे शब्दों में, बाद में एक नया कंटेनर शुरू करते समय, आपको स्क्रैच से सभी चरणों को दोहराने की आवश्यकता नहीं होगी, आप अपने मौजूदा काम का पुन:उपयोग कर सकेंगे और समय और बैंडविड्थ की बचत कर सकेंगे। आप इसकी आईडी या इसके उपनाम के आधार पर एक छवि बना सकते हैं:
डॉकर कमिट <कंटेनर का नाम या आईडी> <नई छवि>
उदाहरण के लिए, हमें निम्नलिखित मिलता है:
डॉकर कमिट 43b179c5aec7 myapache3
1ee373ea750434354faeb1cb70b0177b463c51c96c9816dcdf5562b4730dac54
छवियों की सूची दोबारा जांचें:
डॉकरफाइल
A more streamlined way of creating your images is to use Dockerfiles. In a way, it's like using Makefile for compilation, only in Docker format. Or an RPM specfile if you will. Basically, in any one "build" directory, create a Dockerfile. We will learn what things we can put inside one, and why we want it for our Apache + SSH exercise. Then, we will build a new image from it. We can combine it with our committed images to preserve changes already done inside the container, like the installation of software, to make it faster and save network utilization.
Before we go any further, let's take a look at a Dockerfile that we will be using for our exercise. At the moment, the commands may not make much sense, but they soon will.
FROM myhttptest2:latest
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
EXPOSE 80
RUN mkdir -p /run/httpd
CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]
What do we have here?
As you can see, Dockerfiles aren't that complex or difficult to write, but they are highly useful. You can pretty much add anything you want. Using these templates form a basis for automation, and with conditional logic, you can create all sorts of scenarios and spawn containers that match your requirements.
Build image
Once you have a Dockerfile in place, it's time to build a new image. Dockerfiles must follow a strict convention, just like Makefiles. It's best to keep different image builds in separate sub-directories. For example:
docker build -t test5 .
Sending build context to Docker daemon 41.47 kB
Sending build context to Docker daemon
Step 0 :FROM myapache4:latest
---> 7505c70235e6
Step 1 :EXPOSE 22 80
---> Using cache
---> 58f11217c3e3
Step 2 :CMD /usr/sbin/sshd -D
---> Using cache
---> 628c3d6b5399
Step 3 :RUN mkdir -p /run/httpd
---> Using cache
---> 5fc118f61a4d
Step 4 :CMD /usr/sbin/httpd -D FOREGROUND
---> Using cache
---> d892acd86198
Successfully built d892acd86198
The command tells us the following:-t repository name from a Dockerfile stored in the current directory (.). बस इतना ही। Very simple and elegant.
Test image
Run a new container from the created image. If everything went smoothly, you should have both SSH connectivity, as well as a running Web server in place. Again, all the usual network related rules apply.
Alternative build
Once you have the knowledge how do it on your own, you can try one of the official Apache builds. Indeed, the Docker repository contains a lot of good stuff, so you should definitely invest time checking available templates. For Apache, you only need the following in your Dockerfile - the second like is optional.
FROM httpd:2.4
COPY ./public-html/ /usr/local/apache2/htdocs/
COPY instruction
What do we have above? Basically, in the Dockerfile, we have the declaration what template to use. And then, we have a COPY instructions, which will look for a public-html directory in the current folder and copy it into the container during the build. In the same manner, you can also copy your httpd.conf file. Depending on your distribution, the paths and filenames might differ. Finally, after building the image and running the container:
docker run -ti -p 22 -p 80 image-1:latest
AH00558:httpd:Could not reliably determine the server's fully qualified domain name, using 172.17.0.17. Set the 'ServerName' directive globally to suppress this message
[Thu Apr 16 21:08:35.967670 2015] [mpm_event:notice] [pid 1:tid 140302870259584] AH00489:Apache/2.4.12 (Unix) configured -- resuming normal operations
[Thu Apr 16 21:08:35.976879 2015] [core:notice] [pid 1:tid 140302870259584] AH00094:Command line:'httpd -D FOREGROUND'
Advantages of containers
There are many good reasons why you want to use this technology. But let's just briefly focus on what we gain by running these tiny, isolated instances. Sure, there's a lot happening under the hood, in the kernel, but in general, the memory footprint of spawned containers is fairly small. In our case, the SSH + Apache containers use a tiny fraction of extra memory. Compare this to any virtualization technology.
Problems you may encounter &troubleshooting
Let's go back to the Apache example, and now you will also learn why so many online tutorials sin the sin of copy &pasting information without checking, and why most of the advice is not correct, unfortunately. It has to do with, what do you do if your Apache server seems to die within a second or two after launching the container? Indeed, if this happens, you want to step into the container and troubleshoot. To that end, you can use the docker exec command to attach a shell to the instance.
docker exec -ti boring_mcclintock /bin/bash
Then, it comes down to reading logs and trying to figure out what might have gone wrong. If your httpd.conf is configured correctly, you will have access and error logs under /var/log/httpd:
[auth_digest:error] [pid 25] (2)No such file or directory:AH01762:Failed to create shared memory segment on file /run/httpd/authdigest_shm.25
A typical problem is that you may be a missing /run/httpd directory. If this one does not exist in your container, httpd will start and die. Sounds so simple, but few if any reference mentions this.
While initially playing with containers, I did encounter this issue. Reading online, I found several suggestions, none of which really helped. But I do want to elaborate on them, and how you can make progress in your problem solving, even if intermediate steps aren't really useful.
Suggestion 1:You must use -D FOREGROUND to run Apache, and you must also use ENTRYPOINT rather than CMD. The difference between the two instructions is very subtle. And it does not solve our problem in any way.
ENTRYPOINT ["/usr/sbin/httpd"]
CMD ["-D", "FOREGROUND"]
Suggestion 2:Use a separate startup script, which could work around any issues with the starting or restarting of the httpd service. In other words, the Dockerfile becomes something like this:
...
EXPOSE 80
COPY ./run-httpd.sh /run-httpd.sh
RUN chmod -v +x /run-httpd.sh
CMD ["/run-httpd.sh"]
And the contents of the run-httpd.sh script are along the lines of:
#!/bin/bash
rm -rf /run/httpd/*
exec /usr/sbin/apachectl -D FOREGROUND
Almost there. Remove any old leftover PID files, but these are normally not stored under /run/httpd. Instead, you will find them under /var/run/httpd. Moreover, we are not certain that this directory exists.
Finally, the idea is to work around any problems with the execution of a separation shell inside which the httpd thread is spawned. While it does provide us with additional, useful lessons on how to manage the container, with COPY and RUN instructions, it's not what we need to fix the issue.
Step 3 :EXPOSE 80
---> Using cache
---> 108785c8e507
Step 4 :COPY ./run-httpd.sh /run-httpd.sh
---> 582d795d59d4
Removing intermediate container 7ff5b58b40bf
Step 5 :RUN chmod -v +x /run-httpd.sh
---> Running in 56fadf4dd2d4
mode of '/run-httpd.sh' changed from 0644 (rw-r--r--) to 0755 (rwxr-xr-x)
---> 928640f680cf
Removing intermediate container 56fadf4dd2d4
Step 6 :CMD /run-httpd.sh
---> Running in f9c6b30795e2
---> b2dcc2818a27
Removing intermediate container f9c6b30795e2
Successfully built b2dcc2818a27
This won't work, because apachectl is an unsupported command for managing httpd, plus we have seen problems using startup scripts and utilities earlier, and we will work on fixing this in a separate tutorial.
docker run -ti -p 80 image-2:latest
Passing arguments to httpd using apachectl is no longer supported. You can only start/stop/restart httpd using this script. If you want to pass extra arguments to httpd, edit the /etc/sysconfig/httpd config file.
But it is useful to try these different things, to get the hang of it. Unfortunately, it also highlights the lack of maturity and the somewhat inadequate documentation for this technology out there.
Additional commands
There are many ways you can interact with your container. If you do not want to attach a new shell to a running instance, you can use a subset of docker commands directly against the container ID or name:
docker
For instance, to get the top output from the container:
docker top boring_stallman
If you have too many images, some of which have just been used for testing, then you can remove them to free up some of your disk space. This can be done using the docker rmi command.
# docker rmi -f test7
Untagged:test7:latest
Deleted: d0505b88466a97b73d083434b2dd0e7b59b9a5e8d0438b1bf8c6c
Deleted:5fc118f61bf856f6f3d90e0e71076b737fa7cc58cd56785ea7904
Deleted:628c3d6b53992521c9c1fdda4148693347c3d10b1d130f7e091e7
Deleted:58f11217c3e31206b4e41d07100a797cd4d17e4569b0fdb8b7a18
Deleted:7505c70235e638c54028ea5b63eba2b691de6bee67c2cb5e2861a
...
Then, you can also run your containers in the background. Using the -d flag will do exactly that, and you will get the shell prompt back. This is also useful if you do not mask signals, so if you accidentally break in your shell, you might kill the container when it's running in the foreground.
docker run -d -ti -p 80 image-3:latest
You can also check events, examine changes inside a container's filesystem as well as check history, so you basically have a version control in place, export or import tarred images to and from remote locations, including over the Web, and more.
Differences between exec and attach
If you read through the documentation, you will notice you can connect to a running container using either exec or attach commands. So what's the difference, you may ask? If we look at the official documentation, then:
The docker exec command runs a new command in a running container. The command started using docker exec only runs while the container's primary process (PID 1) is running, and it is not restarted if the container is restarted.
On the other hand, attach gives you the following:
The docker attach command allows you to attach to a running container using the container's ID or name, either to view its ongoing output or to control it interactively. You can attach to the same contained process multiple times simultaneously, screen sharing style, or quickly view the progress of your daemonized process. You can detach from the container (and leave it running) with CTRL-p CTRL-q (for a quiet exit) or CTRL-c which will send a SIGKILL to the container. When you are attached to a container, and exit its main process, the process's exit code will be returned to the client.
In other words, with attach, you will get a shell, and be able to do whatever you need. With exec, you can issue commands that do not require any interaction, but with you use a shell in combination with exec, you will achieve the same result as if you used attach.
Differences between start and run
Start is used to resume the execution of a stopped container. It is not used to start a fresh instance. For that, you have the run command. The choice of words could have been better.
Differences between build and create
The first command is used to create a new image from a Dockerfile. On the other hand, the latter is used to create a new container using command line options and arguments. Create lets you specify container settings, too, like network configurations, resource limitations and other settings, which affect the container from the outside, whereas the changes implemented by the build command will be reflected inside it, once you start an instance. And by start, I mean run. उसे ले लो?
This is just a beginning ...
There are a million more things we can do: using systemd enabled containers, policies, security, resource constraints, proxying, signals, other networking and storage options including the super-critical question of how to mount data volumes inside containers so that data does not get destroyed when containers die, additional pure LXC commands, and more. We've barely scratched the surface. But now, we know what to do. And we'll get there. Slowly but surely.
More reading
I recommend you allocate a few hours and then spend some honest time reading all of the below, in detail. Then practice. This is the only way you will really fully understand and embrace the concepts.
My entire virtualization section
Dockerizing an SSH Deamon Service
Differences between save and export in Docker
Docker Explained:Using Dockerfiles to Automate Building of Images
निष्कर्ष
We're done with this tutorial for today. Hopefully, you've found it useful. In a nutshell, it does explain quite a few things, including how to get started with Docker, how to pull new images, run basic containers, add services like SSH and Apache, commit changes to a file, expose incoming ports, build new images with Dockerfiles, lots of troubleshooting of problems, additional commands, and more. Eventful and colorful, I'd dare say.
In the future, we will expand significantly on what we learned here, and focus on various helper technologies like supervisord for instance, we will learn how to mount filesystems, work on administration and orchestration, and many other cool things. Docker is a very nice concept, and if used correctly, it can make your virtual world easier and more elegant. The initial few steps are rough, but with some luck, this guide will have provided you with the right dose of karma to get happily and confidently underway. Ping me if you have any requests or desires. Technology related, of course. हो गया था। पी.एस. If you like this article, then you'd better give some love back to Dedoimedo!
प्रोत्साहित करना।