डॉकर: हर .Net डेवलपर को क्या जानना चाहिए

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



एक डेवलपर को क्या करने में सक्षम होना चाहिए? "कार्यक्रम," आप जवाब और ... लगता है। लेकिन अगर पहले आवश्यक ज्ञान की सूची इस पर समाप्त हो गई, तो अब देवओप्स युग में यह केवल शुरुआत है। जब हम कोड लिखते हैं, तो हमें निश्चित रूप से नेटवर्क संरचना को जानने की आवश्यकता होती है: क्या के साथ इंटरैक्ट करता है। एक साथ कई प्रोग्रामिंग भाषाओं के लिए समर्थन की आवश्यकता होती है, और किसी परियोजना में कोड के विभिन्न टुकड़े किसी भी चीज़ पर लिखे जा सकते हैं।



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

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

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

हम कंटेनरों को समझते हैं

डॉकटर कंटेनर क्या है? यह एक संरचना है जिसमें कई परतें होती हैं। शीर्ष परत आपके आवेदन की द्विआधारी परत है। दूसरी और तीसरी परत अब .Net कोर में एकीकृत हो जाती है, कंटेनर पहले से ही एसडीके-शनी है। अगली परत ऑपरेटिंग सिस्टम पर निर्भर करती है जिस पर कंटेनर तैनात है। और नीचे की परत ऑपरेटिंग सिस्टम ही है।



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

यदि हम भौतिक और आभासी सर्वर और कंटेनरों की तुलना करते हैं, तो बाद के लाभ स्पष्ट हैं।



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

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



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

आइए देखें कि लिनक्स कंटेनर सिस्टम पर कैसे स्थित हैं।



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

विंडोज कंटेनर लिनक्स से थोड़े अलग हैं।



बुनियादी परतें समान हैं: बुनियादी ढांचा, मेजबान ओएस (लेकिन अब विंडोज)। लेकिन फिर कंटेनर सीधे ओएस के साथ काम कर सकते हैं या हाइपरविजर के शीर्ष पर तैनात किए जा सकते हैं। पहले मामले में, प्रक्रियाओं और रिक्त स्थान का अलगाव होता है, लेकिन वे अन्य कंटेनरों के साथ उसी कोर का उपयोग करते हैं, जो सुरक्षा के दृष्टिकोण से बर्फ नहीं है। यदि आप हाइपर-वी के माध्यम से कंटेनरों का उपयोग करते हैं, तो सब कुछ अलग हो जाएगा।

लर्निंग डॉकटर फॉर वी.एस.

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



स्लाइड सरलतम कमांड दिखाती है: डॉकर कंटेनर खींचो, इसे लॉन्च करो, इकट्ठा करो, प्रतिबद्ध करो, वापस भेजो।

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



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

कंटेनर कैसे इकट्ठे होते हैं? यहां मुख्य तत्व डॉकफाइल है, जिसमें छवि के निर्माण के निर्देश हैं। प्रत्येक प्रोजेक्ट के लिए प्रत्येक डॉकफाइल बनाया जाता है। यह इंगित करता है: हमें मूल छवि कहां से मिलती है, हम किस तर्क से गुजरते हैं, फाइलों, बंदरगाहों के साथ काम करने वाली निर्देशिका का नाम क्या है।



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

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

अब डिबगिंग कंटेनर के बारे में। यहां सब कुछ एक नियमित नेट की तरह है, आप शायद ही अंतर को देखेंगे। सबसे अधिक बार, मैं .net Core को dotnet.exe के तहत स्व-होस्ट के रूप में चलाता हूं। यह CLRDBG डीबगर, Nuet पैकेट कैश और स्रोत कोड का उपयोग करता है।

ASP.Net 4.5+ को IIS या IIS एक्सप्रेस द्वारा होस्ट किया जाता है, Microsoft Visual Studio डीबगर और IIS में साइट रूट के स्रोत का उपयोग करता है।



डिबगिंग के लिए दो वातावरण हैं: डीबग और रिलीज़। डिबगिंग छवि टैग को देव और नवीनतम रिलीज़ के रूप में चिह्नित किया गया है। डिबगिंग करते समय, स्रोत तर्क को ओब्जर्व / डोकर / खाली करने के लिए बेहतर सेट किया जाता है, ताकि भ्रमित न हों, लेकिन जब आप ओब्ज / डोकर / प्रकाशित करते हैं। यहां आप सभी समान बायनेरिज़, विचार, wwwroot फ़ोल्डर और मौजूद सभी निर्भरता का उपयोग कर सकते हैं।

माहिर डॉकटर रचना

चलिए मज़ेदार हिस्से पर चलते हैं: डोकर-कंपो ऑर्केस्ट्रेशन टूल। आइए एक उदाहरण देखें: आपके पास कुछ प्रकार की व्यवसाय सेवा है जो 5-6 कंटेनरों को प्रभावित करती है। और आपको किसी तरह ठीक करने की आवश्यकता है कि उन्हें किस क्रम में इकट्ठा किया जाना चाहिए। यह वह जगह है जहां डॉकटर-कम्पोज काम में आता है, जो कंटेनरों के सभी विधानसभा, लॉन्च और स्केलिंग प्रदान करेगा। यह बस प्रबंधित किया जाता है, सब कुछ एक टीम द्वारा एकत्र किया जाता है।



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

एक YAML फ़ाइल की संरचना पर विचार करें। इमेज एक डॉकर इमेज है। एक छवि एक आवेदन परत के बिना एक कंटेनर है, यह अपरिवर्तनीय है।



बिल्ड इंगित करता है कि कैसे निर्माण करना है, कहां निर्माण करना है और कहां तैनात करना है।
Depends_on - निर्भरता कि यह किन सेवाओं पर निर्भर है।
पर्यावरण - यहाँ हम पर्यावरण निर्धारित करते हैं।
पोर्ट - पोर्ट की मैपिंग जिस पर आपका कंटेनर उपलब्ध होगा।

एक उदाहरण पर विचार करें। हमारे पास बस एक सेवा के बिना एक एपीआई है, अनिवार्य रूप से 3 कंटेनर: लिनक्स पर SQL.data है, स्वयं एक एप्लिकेशन है, यह वेबैपी पर निर्भर करता है, और वेबपीआई SQL.data पर निर्भर करता है।



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

एक प्रकार का "कंटेनर कंटेनर" होता है, एक विशेष कंटेनर docker-compose.ci.build.yml, जिसमें पूरी रचना इकट्ठी होती है। आप इस विशेष कंटेनर को Visual Studio कमांड लाइन से चला सकते हैं, और यह असेंबली को एक बिल्ड सर्वर पर पूरा करने में सक्षम होगा, उदाहरण के लिए, जेनकिंस में।



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

और क्या ध्यान देने योग्य है। प्रत्येक वातावरण के लिए डॉकटर-कंपोज प्रतिमा को इकट्ठा करता है, प्रत्येक विन्यास के लिए एक अलग फाइल। विजुअल स्टूडियो में प्रत्येक कॉन्फ़िगरेशन के लिए सेटिंग्स है जो आपको पर्यावरण के लिए आवश्यक है।



सीधे वीएस से, आप पूरी रचना को दूरस्थ रूप से डीबग करना शुरू कर सकते हैं।

क्लस्टर ऑर्केस्ट्रेटर

अंत में, हम क्लस्टर ऑर्केस्ट्रेटर जैसे विषयों पर स्पर्श करते हैं। हमें यह नहीं सोचना चाहिए कि कंटेनरों का अस्तित्व कैसे बना रहता है, जिन्हें लोग या सिस्टम प्रबंधित करते हैं। इसके लिए, सबसे लोकप्रिय कंटेनर प्रबंधन प्रणाली में से 4 हैं: Google कुबेरनेट्स, मेसोस डीसी / ओएस, डॉकर झुंड, और एज़ुर सर्विस फैब्रिक। वे आपको कंटेनरों के क्लस्टरिंग और संरचना का प्रबंधन करने की अनुमति देते हैं।



ये प्रणालियां माइक्रोसिस्टम की एक बड़ी परत के साथ सामना करने में सक्षम हैं, उन्हें आवश्यक सब कुछ प्रदान करती हैं। डेवलपर को केवल एक बार इस परत को कॉन्फ़िगर करने की आवश्यकता होगी।

पांडा मीटअप में प्रदर्शन का पूरा संस्करण नीचे उपलब्ध है।


उन लोगों के लिए जो विषय में गहराई से उतरना चाहते हैं, मैं आपको निम्नलिखित सामग्रियों का अध्ययन करने की सलाह देता हूं:

Http://dot.net
Http://docs.docker.com
Http://hub.docker.com/microsoft
Http://docs.microsoft.com
Http://visualstudio.com

और अंत में, अभ्यास से सलाह का एक महत्वपूर्ण टुकड़ा: सबसे कठिन बात यह याद रखना है कि क्या झूठ है।

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