Windows कॉन्फ़िगरेशन को प्रबंधित करने के लिए आसान है। सफलता की कहानी

SpbDotNet सामुदायिक डेवलपर्स के सेंट पीटर्सबर्ग .Net समुदाय की बैठकों में से एक पर, हमने एक प्रयोग किया और इस बारे में बात करने का फैसला किया कि आप विंडोज इन्फ्रास्ट्रक्चर को स्वचालित करने के लिए लिनक्स दुनिया में मानक बन चुके दृष्टिकोणों को कैसे लागू कर सकते हैं। लेकिन एंसिबल झंडा फहराने के मुद्दे पर सब कुछ नहीं लाने के लिए, एएसपी.नेट एप्लिकेशन को तैनात करने के उदाहरण से यह दिखाने का निर्णय लिया गया था।

अलेक्सी चेरनोव, हमारी परियोजनाओं के लिए यूआई घटकों के पुस्तकालय को विकसित करने वाली टीम के वरिष्ठ डेवलपर, एक वक्ता के रूप में स्वेच्छा से। और हाँ, यह आपको प्रतीत नहीं हुआ: एक जावास्क्रिप्ट डेवलपर एक .Net दर्शकों के सामने गया।

जो कोई भी इस तरह के एक प्रयोग के परिणाम में रुचि रखता है, डिकोडिंग के लिए कटौती के तहत स्वागत करता है।

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

जेएस के अलावा, हाल ही में मैं बहुत सारे ऑटोटेस्ट (एक ही जेएस पर) को लिख रहा हूं, और इसलिए मुझे परीक्षण बेंचों की तैनाती और उनके लिए बुनियादी ढांचे के स्वचालन से निपटना होगा।

प्रागितिहास

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

हम, जो लिनक्स के लिए विकसित हो रहे हैं, लंबे समय से इस तथ्य के आदी हैं कि सब कुछ डॉकटर में होना चाहिए, कुबेरनेट्स हैं, और सब कुछ एक क्लिक के साथ सामने आता है। और जब मैं एक ऐसे वातावरण में समाप्त हुआ, जहां यह सब नहीं है, तो वह चौंक गया। और जब मैंने ऑटो परीक्षण करना शुरू किया, तो मुझे एहसास हुआ कि यह केवल 20% सफलता थी, और बाकी सब उनके लिए बुनियादी ढांचा तैयार कर रहा था।

शुरुआत में मेरी भावनाएँ

वर्तमान स्थिति

मैं आपको थोड़ा बताऊंगा कि हमारे साथ सब कुछ कैसे व्यवस्थित है, हमें क्या करना है और हम क्या करते हैं।

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

समस्याओं

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

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

लेकिन कुछ बिंदु पर उन्होंने इसे दूर करने और चारों ओर देखने के लिए आंतरिक शक्ति पाई। शायद किसी तरह आप इसे संभाल सकते हैं।

समस्या को हल करने की दिशा में पहला कदम इसे स्वीकार करना है।

समाधान का चयन

जब आप नहीं जानते कि क्या करना है, तो देखें कि दूसरे क्या कर रहे हैं।

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

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

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

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

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

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

• इसलिए, मुझे परीक्षणों के लिए एक आभासी मशीन की आवश्यकता है
• हाँ, यहाँ हमारे पास एक मेजबान पूल है
• और यहाँ वह स्क्रिप्ट है जिसकी मुझे आवश्यकता है, अब मैं इसे चलाऊंगा, और सब कुछ होगा

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

एक कोड के रूप में बुनियादी ढाँचा

यह ठीक है कि हमारे पूरे बुनियादी ढांचे को कोड में वर्णित किया जाना चाहिए और भंडार में रखना चाहिए। सभी वर्चुअल मशीनें, उनके सभी पैरामीटर, सब कुछ जो वहां स्थापित है - सब कुछ कोड में वर्णित किया जाना चाहिए।

एक वैध सवाल उठता है - क्यों?

हम उत्तर देते हैं: यह दृष्टिकोण हमें विकास की दुनिया से सर्वोत्तम प्रथाओं को लागू करने का अवसर देगा, जिसके लिए हम सभी आदी हैं:

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

उपकरण चयन

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

इसलिए, हमारे लिए प्रमुख विशेषता है बेकारता। पहले क्या हुआ था, इससे कोई फर्क नहीं पड़ता वांछित प्लेबुक शुरू करने के बाद, हम हमेशा एक ही परिणाम प्राप्त करते हैं। जब आप "IIS स्थापित नहीं" कहते हैं, तो यह बहुत महत्वपूर्ण है, लेकिन "IIS होना चाहिए", और आपको यह नहीं सोचना चाहिए कि क्या वह पहले था या नहीं। लिपियों के साथ इसे हासिल करना बहुत मुश्किल है, और Ansible playbooks ऐसा अवसर प्रदान करता है।

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

PowerShell:

$url = "http://buildserver/build.msi" $output = "$PSSscriptRoot\build.msi" Invoke-WebRequest -Uri $url -OutFile $output 

Ansible:

 name: Download build hosts: all tasks: name: Download installer win_get_url: url: "http://buildserver/build.msi" dest: "build.msi" force: no 

यहाँ हम देखते हैं कि मूल उदाहरण में, आंसर-की प्लेबुक की तुलना में पीएस-स्क्रिप्ट और भी अधिक संक्षिप्त होगी। किसी फ़ाइल को डाउनलोड करने के लिए स्क्रिप्ट की 7 पंक्तियों की प्लेबुक की 3 लाइनें।

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

और यह एक बहुत ही सरल कार्य का सिर्फ एक उदाहरण है।

और अगर आप इसके बारे में सोचते हैं, तो हमें हर जगह पर बेवकूफी की जरूरत है:

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

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

अन्य बातों के अलावा, जो हमारे लिए महत्वपूर्ण हैं, Ansible अपने मेजबानों और मशीनों का प्रबंधन करने के लिए एजेंटों का उपयोग नहीं करता है। लिनक्स पर, निश्चित रूप से, यह ssh पर चलता है, जबकि विंडोज के लिए, WinRM का उपयोग किया जाता है। अत: स्पष्ट परिणाम: अन्सिबल क्रॉस-प्लेटफॉर्म है। यह नेटवर्क उपकरणों तक प्लेटफार्मों की कुछ शानदार संख्या का समर्थन करता है।

और आखिरी, लेकिन कोई कम महत्वपूर्ण नहीं है, YAML कॉन्फ़िगरेशन रिकॉर्डिंग प्रारूप है। हर किसी को इसका उपयोग किया जाता है, यह पढ़ना आसान है, और यह पता लगाना आसान है कि वहां क्या हो रहा है।

लेकिन सब कुछ इतना मीठा नहीं है, समस्याएं हैं:

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

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

इस मशीन पर हमें आवश्यकता होगी:

• अजगर और अजगर पैकेज मैनेजर पाइप। कई वितरण बॉक्स से बाहर हैं, इसलिए यहां कोई आश्चर्य नहीं है।
• पाइप के माध्यम से Ansible स्थापित करें, सबसे सार्वभौमिक तरीके के रूप में: पाइप स्थापित करें ansible
• विंडोज मशीनों पर जाने के लिए एक winrm मॉड्यूल जोड़ें: पाइप स्थापित करें pywinrm [क्रेडिट]
• और जिन मशीनों को हम नियंत्रित करना चाहते हैं, उन पर हमें winrm को सक्षम करना होगा, क्योंकि यह डिफ़ॉल्ट रूप से बंद है। ऐसा करने के कई तरीके हैं, और वे सभी Ansible प्रलेखन में वर्णित हैं। लेकिन सबसे सरल है कि तैयार स्क्रिप्ट को आंसिबल रिपॉजिटरी से लिया जाए और इसे आवश्यक प्राधिकरण विकल्प के साथ चलाया जाए: ConfigureRemotingForAnsible.ps1 -EnableCredSSP

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

 all: children: webservers: hosts: spbdotnet-test-host.dev.local: dbservers: hosts: spbdotnet-test-host.dev.local: vars: ansible_connection: winrm ansible_winrm_transport: credssp ansible_winrm_server_cert_validation: ignore ansible_user: administrator ansible_password: 123qweASD 

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

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

मॉड्यूल

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

सामान्य स्थिति में, हम प्रपत्रों की ansible होस्ट समूह इन्वेंट्री फ़ाइल सूची के निर्माण को चलाएंगे:

Pleybuki

एक नाटकपुस्तिका इस बात का विवरण है कि हम कैसे और कहाँ अंसिबल मॉड्यूल को निष्पादित करेंगे।

 - name: Install AWS CLI hosts: all vars: aws_cli_download_dir: c:\downloads aws_cli_msi_url: https://s3.amazonaws.com/aws-cli/AWSCLI32PY3.msi tasks: - name: Ensure target directory exists win_file: path: "{{ aws_cli_download_dir }}" state: directory - name: Download installer win_get_url: url: "{{ aws_cli_msi_url }}" dest: "{{ aws_cli_download_dir }}\\awscli.msi" force: no - name: Install AWS CLI win_package: path: "{{ aws_cli_download_dir }}\\awscli.msi" state: present 

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

इस playbook को चलाने से हमें यह परिणाम मिलता है।

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

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

यह वह मूर्खता है जिसे हम पावरशेल के साथ हासिल नहीं कर सकते।

अभ्यास

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

 - name: Setup App hosts: webservers tasks: - name: Install IIS win_feature: name: - Web-Server - Web-Common-Http include_sub_features: True include_management_tools: True state: present register: win_feature - name: reboot if installing Web-Server feature requires it win_reboot: when: win_feature.reboot_required 

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

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

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

अगला कदम SQL स्थापित करना है। ऐसा करने के लिए पहले से ही एक मिलियन तरीके का आविष्कार किया गया है। मैं यहाँ win_chineryy मॉड्यूल का उपयोग कर रहा हूँ। यह विंडोज के लिए एक पैकेज मैनेजर है। हां, ठीक यही हम लिनक्स पर उपयोग करते हैं। मॉड्यूल समुदाय द्वारा समर्थित हैं, और अब पहले से ही उनमें से छह हजार से अधिक हैं। मैं दृढ़ता से आपको कोशिश करने की सलाह देता हूं।

 - name: SQL Server hosts: dbservers tasks: - name: Install MS SQL Server 2014 win_chocolatey: name: mssqlserver2014express state: present 

इसलिए, हमने एप्लिकेशन को लॉन्च करने के लिए मेजबान तैयार किया, चलो इसे तैनात करें!

 - name: Deploy binaries hosts: webservers vars: myapp_artifacts: files/MyAppService.zip myapp_workdir: C:\myapp tasks: - name: Remove Service if exists win_service: name: MyAppService state: absent path: "{{ myapp_workdir }}\\MyAppService.exe" 

बस के मामले में, पहली बात हम मौजूदा सेवा को हटाते हैं।

 - name: Delete old files win_file: path: "{{ myapp_workdir }}\\" state: absent - name: Copy artifacts to remote machine win_copy: src: "{{ myapp_artifacts }}" dest: "{{ myapp_workdir }}\\" - name: Unzip build artifacts win_unzip: src: "{{ myapp_workdir }}\\MyAppService.zip" dest: "{{ myapp_workdir }}" 

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

  - name: Register and start the service win_service: name: ReporterService start_mode: auto state: started path: "{{ myapp_workdir }}\\MyAppService.exe" 

हो गया?

ऐसा लगता है कि हमारी सेवा कार्य और रक्षा के लिए तैयार है, हालांकि, एक "लेकिन" है - हमने निष्क्रियता के सिद्धांत का पालन नहीं किया। हम हमेशा मौजूदा कोड को हटाते हैं और फिर नए को तैनात करते हैं।

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

क्या किया जा सकता है? वैकल्पिक रूप से, आप हमारी कलाकृतियों के चेकसम को देख सकते हैं और सर्वर पर उन लोगों के साथ तुलना कर सकते हैं।

  - name: Get arifacts checksum stat: path: "{{ myapp_artifacts }}" delegate_to: localhost register: myapp_artifacts_stat - name: Get remote artifacts checksum win_stat: path: "{{ myapp_workdir }}\\MyAppService.zip" register: myapp_remote_artifacts_stat 

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

  - name: Stop play if checksums match meta: end_play when: - myapp_artifacts_stat.stat.checksum is defined - myapp_remote_artifacts_stat.stat.checksum is defined - myapp_artifacts_stat.stat.checksum == myapp_remote_artifacts_stat.stat.checksum 

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

  - name: Ensure that the WebApp application exists win_iis_webapplication: name: WebApp physical_path: c:\webapp site: Default Web Site state: present 

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

कोड का पुन: उपयोग

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

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

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

 - name: Run App hosts: webservers tasks: - name: "Install IIS" include_role: name: IIS - name: Run My App include_role: name: MyAppService vars: myapp_artifacts: ./buld.zip 

इस उदाहरण में, रन माई ऐप भूमिका कुछ कलाकृतियों को स्थानांतरित करने की क्षमता रखती है।

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

अधिक लचीलापन

लेकिन क्या होगा अगर कोई अंतर्निहित मॉड्यूल या गैलेक्सी में उपयुक्त भूमिका नहीं है? दो विकल्प हैं: या तो हम कुछ गलत कर रहे हैं, या हमारे पास वास्तव में एक अनूठा कार्य है।

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

सीआई
हमारे विभाग में, हम वास्तव में TeamCity से प्यार करते हैं, लेकिन आपकी पसंद का कोई अन्य CI सर्वर हो सकता है। हमें उन्हें साझा करने की आवश्यकता क्यों है?

सबसे पहले, हम हमेशा अपनी प्लेबुक की वाक्य रचना की जाँच कर सकते हैं। जबकि YAML एक सिंटैक्स त्रुटि मानता है, यह एक बहुत ही उपयोगी विशेषता है।

CI सर्वर पर भी हम ansible-lint चलाते हैं। यह ansible configs का एक स्थिर विश्लेषक है, जो सिफारिशों की एक सूची देता है।

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

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

और CI सर्वर का उपयोग करने का दूसरा मुख्य कारण playbooks लॉन्च करना है। यह वही मैजिक बटन "डू वेल" है, जो हमें टीमसिटी देता है। हम अलग-अलग उत्पादों के लिए कुछ सरल कॉन्फ़िगरेशन बनाते हैं, जहाँ हम कहते हैं: ansible-playbook रिपोर्टर_vm.yml -i इन्वेंट्री .yml -vvv और डिप्लॉय बटन प्राप्त करें।

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

कुल मिलाकर

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

पुनश्च लेख से सभी उदाहरण github पर लिए जा सकते हैं।