कैसे अपने आईटी बुनियादी ढांचे को उबाऊ बनाने के लिए

माइकल डीहैन वह शख्स हैं, जिन्होंने अंसिबल बनाया। सिस्टम प्रशासक, रिलीज़ और DevOps इंजीनियरों की कई चीजें नियमित आधार पर होती हैं, इसे हल्का, निर्बाध रूप से लागू करने के लिए। DeHaan चाहता है कि ये लोग अधिक दिलचस्प चीज़ों (काम पर या कार्यालय के दरवाजे के बाहर) के लिए अपना समय खाली करें, और एक उत्पाद कोड लिखें जो व्यवस्थापक समय को मुक्त करता है।
अधिक समय, व्यापार के घंटों के दौरान कम एड्रेनालाईन, कम स्क्रिप्ट और कम त्रुटियां।
वैसे, आप 6 जून को यहां लाइवस्ट्रीम से कनेक्ट करके इस पैराग्राफ पर पढ़ना समाप्त कर सकते हैं ।



यदि आप अभी भी पढ़ना जारी रखते हैं ...

उत्तर: निरंतर एकीकरण और वितरण

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

सतत एकीकरण और अनुप्रयोग वितरण (CI / CD)

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

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

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

और यहां, उदाहरण के लिए, आधुनिक सॉफ्टवेयर विकास प्रक्रियाओं के हिस्से के रूप में आईटी सिस्टम को ऑर्केस्ट्रेट करने के लिए Red Hat's Ansible and Ansible Tower।

शून्य डाउनटाइम

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

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

अनुप्रयोग बिल्ड सिस्टम

सतत वितरण (सीडी) निरंतर एकीकरण (CI) के साथ शुरू होता है। एक प्रणाली जो परिवर्तनों के लिए स्रोत कोड रिपोजिटरी की निगरानी करती है, स्वतंत्र रूप से संबंधित परीक्षणों को चलाती है और प्रत्येक कोड अपडेट के साथ एप्लिकेशन का एक नया संस्करण स्वचालित रूप से (और आदर्श रूप से परीक्षण) बनाता है, उदाहरण के लिए, जेनकिंस प्रोजेक्ट (jenkins.io)।

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

मल्टीलेवल एप्लिकेशन एक-एक करके अपडेट करें

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

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

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

स्वचालन लिपियों के लिए निरंतर तैनाती

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

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

वैकल्पिक अद्यतन और लोड संतुलन प्रणाली

लगातार अपडेट होने पर लोड बैलेंसिंग सिस्टम के साथ एंसिबल बहुत स्वतंत्र रूप से काम करता है। इसलिए, आप केवल एक Playbook स्क्रिप्ट में, मेजबान के एक समूह के लिए किसी भी चक्र में लिख सकते हैं, जैसे "होस्ट Y की ओर से सिस्टम X पर यह क्रिया करना", और Ansible बाकी की देखभाल करेगा।

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

एकीकृत मध्यवर्ती परीक्षण

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

संस्करण नियंत्रण परिनियोजन

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

निगरानी उपकरणों के साथ एकीकरण

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

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

घटना की अधिसूचना

CI / CD प्रतिमान में, हर कोई जल्द से जल्द घटना सूचनाएं प्राप्त करना चाहता है। Ansible दोनों अंतर्निहित कार्यों को प्रदान करता है, जिसमें एक ईमेल मॉड्यूल, साथ ही बाहरी सूचना उपकरण, जैसे त्वरित संदेशवाहक, सामाजिक नेटवर्क या इवेंट पंजीकरण सिस्टम के साथ एकीकरण शामिल है।

संसाधन स्थिति मॉडल का उपयोग करते हुए परिनियोजन

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

Ansible में, आप विभिन्न वास्तुशिल्प स्तरों पर घटनाओं के क्रम को बहुत ही सटीक रूप से पंजीकृत और नियंत्रित कर सकते हैं, जो आपको अन्य प्रणालियों के लिए क्रियाओं को सौंपने की अनुमति देता है, साथ ही साथ संसाधन मॉडल ("पैकेज एक्स राज्य वाई में होना चाहिए") और पारंपरिक कमांड कमांड (जैसे "रन स्क्रिप्ट) को जोड़ती है। .sh ") एक प्रक्रिया के भीतर।

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

परिनियोजन परीक्षण

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

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

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

अनुपालन जांच

ऐसे वातावरण हैं जहां कॉन्फ़िगरेशन तभी बदलता है जब इसके बिना कोई रास्ता नहीं है। ऐसे वातावरण में कोई भी परिवर्तन पूर्व-विश्लेषण किया जाता है। यह "वितरण के साथ" निरंतर वितरण प्रणाली का उपयोग करता है।

Ansible में एक सिमुलेशन रन मोड ("--check" ध्वज द्वारा सक्रिय) है, जब सिस्टम स्क्रिप्ट को निष्पादित किए जाने पर क्या परिवर्तन होगा, इस पर एक रिपोर्ट बनाता है। इस मामले में, स्क्रिप्ट का वास्तविक निष्पादन नहीं होता है, सिमुलेशन रन त्रुटियों को पकड़ने की अनुमति नहीं देता है, लेकिन प्रस्तावित परिवर्तनों के विवरण और परिणामों को बेहतर ढंग से समझने और विश्लेषण करने में मदद करता है।

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

ऑटोपायलट की तैनाती

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

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

एक प्लेबुक क्या है?

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

मॉड्यूल (मॉड्यूल)

हम एक प्लेबुक बनाएंगे जो RHEL / CentOS 7 होस्ट पर वेब सर्वर स्थापित करेगा और स्क्रिप्ट में निर्दिष्ट टेम्पलेट के आधार पर उस पर एक index.html फ़ाइल बनाएगा। यहां दिखाया गया नमूना स्क्रिप्ट पूरी तरह से परिचालन और उपयोग के लिए तैयार है। नीचे हम एक उदाहरण Playbook स्क्रिप्ट को देखेंगे और मॉड्यूल का उपयोग करने का तरीका बताएंगे।

लेखक (लेखक)

लेखक वह व्यक्ति होता है जो ऐसे निर्देश बनाता है जिन्हें मॉड्यूल द्वारा निष्पादित किया जाता है (अक्सर अतिरिक्त मूल्यों के साथ: तर्क, स्थान आदि)। मॉड्यूल को उस लक्ष्य होस्ट पर निष्पादित किया जाता है, जिसमें वे Playbook स्क्रिप्ट में शामिल होते हैं (इसमें शामिल’'और अन्य अतिरिक्त फ़ाइलें शामिल हैं)। मॉड्यूल निष्पादन के परिणामों के आधार पर मेजबान की स्थिति में परिवर्तन होता है (या नहीं बदलता है), जो कि आंसिबल और टॉवर आउटपुट के रूप में प्रदर्शित होते हैं।

Playbook स्क्रिप्ट निष्पादन

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

1. लक्ष्य प्रणाली (लक्ष्य)
क्योंकि Playbook स्क्रिप्ट मॉड्यूल के लिए निर्देश प्रदान करते हैं और इंटरैक्ट करते हैं, इसलिए Ansible का मानना ​​है कि आप समझते हैं कि आप क्या करने की कोशिश कर रहे हैं और इसे स्वचालित करते हैं। इसलिए हम कहते हैं कि Playbooks निर्देश या निर्देशों की तरह हैं: आप स्वचालित तत्वों को बताते हैं कि आप कार्य को कैसे कॉन्फ़िगर करना चाहते हैं। लेकिन एक ही समय में, आपको खुद को अच्छी तरह से समझने की जरूरत है कि प्लेबुक स्क्रिप्ट रन के लक्ष्य होस्ट कैसे काम कर रहा है।

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

Playbook स्क्रिप्ट उदाहरण
निम्नलिखित Playbook स्क्रिप्ट उदाहरण आपको समझने में मदद करेगा कि आपने अभी क्या पढ़ा है। इसमें टारगेट होस्ट RHEL / CentOS 7 सर्वर है, जिस पर हमारी स्क्रिप्ट NGINX वेब सर्वर स्थापित करता है, और फिर डिफ़ॉल्ट webroot निर्देशिका में index.html फ़ाइल बनाता है। , -.

*: Playbook Ansible Tower inventory .

Playbooks YAML (---), :

Name : , Playbook.

Hosts : , Ansible.

Become : , , nginx ( ).

1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 

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

राज्य : निर्देश का अर्थ है कि किसी भी आगे की कार्रवाई करने से पहले, Ansible को लक्ष्य होस्ट की स्थिति की जांच करनी चाहिए। हमारे उदाहरण में, यदि पहले से ही मेजबान पर एक रिपॉजिटरी या नेग्नेक्स है, तो एंसेबल समझता है कि इन दो कार्यों को करने के लिए आवश्यक नहीं है, और निम्नलिखित के लिए आगे बढ़ता है।

 1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present 

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

 1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html 

हमारी Playbook में अंतिम पंक्ति केवल यह सत्यापित करने के लिए कार्य करती है कि nginx सेवा सफलतापूर्वक शुरू की गई है (या यदि नहीं तो इसे शुरू करने के लिए)।

 1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started 

संपूर्ण Playbook स्क्रिप्ट इस पोस्ट में उद्घाटन पैराग्राफ के समान लंबाई के बारे में थी:

 1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started 

सारांश

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

जेनेकिंस की तरह, Ansible आर्किटेक्चर सुविधाओं और CI सिस्टम के साथ एकीकृत करने की क्षमता, न केवल कॉन्फ़िगरेशन प्रबंधन प्रक्रियाओं को स्वचालित करती है, बल्कि आईटी कार्यों की एक बहुत व्यापक श्रेणी भी है। यही कारण है कि हम प्यार से Ansible को एक एकीकृत ऑर्केस्ट्रेशन सिस्टम कहते हैं, न कि केवल एक सॉफ्टवेयर परिनियोजन और कॉन्फ़िगरेशन प्रबंधन उपकरण।