असरदार भूमिकाओं का प्रभावी विकास और रखरखाव

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

Ansible एक जादू की गोली नहीं है , और केवल पहली बार में मदद करता है। जब कोई परियोजना बढ़ती है, तो विस्तारित भूमिकाओं को बनाए रखना मुश्किल हो जाता है। भूमिकाओं के लिए निरंतर वितरण तंत्र समस्या को हल करने में मदद करता है।

बस इसके बारे में, DevOps Conf Russia में अलेक्जेंडर खारकेविच की रिपोर्ट का डिकोडिंग। रिपोर्ट में: सीआई के माध्यम से अन्सिबल भूमिकाओं का विकास, निजी अवसंरचना में परीक्षण रन के साथ सार्वजनिक भूमिकाओं और सार्वजनिक भूमिकाओं के विकास के लिए एक तंत्र। और रिपोर्ट में कोई निष्कर्ष नहीं निकला है।



स्पीकर के बारे में : अलेक्जेंडर खारकेविच ( खारकेविच ) EPAM सिस्टम्स में वरिष्ठ सिस्टम इंजीनियर।

चलो एक त्वरित अवलोकन के साथ शुरू करते हैं।

अन्सिबल के बारे में

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

3 साल बाद रेडी हैट के पूरे संस्करण को खरीदने के बाद, 2012 में एन्सिबल दिखाई दिया, और दो साल बाद एन्सिबल टॉवर का प्रोजेक्ट ओपन सोर्स संस्करण AWX पेश किया।

स्थापना

Ansible का उपयोग करने के लिए, आपको दो सरल काम करने होंगे।

पहले चरण में, स्टैटिक इन्फ्रास्ट्रक्चर के मामले में इन्वेंट्री फ़ाइल संकलित करें।



दूसरा प्लेबुक लिखना है जो सिस्टम को अपेक्षित स्थिति में लाएगा।



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

भूमिका

यह एक संरचित इकाई है जो स्वचालन के पुन: उपयोग की क्षमता के साथ सिस्टम को उसकी अपेक्षित स्थिति में लाएगा।



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

हमने भूमिकाओं के साथ काम करने की कल्पना कैसे की

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


हमने सोचा कि हम सुंदर और स्मार्ट भूमिकाएँ लिखेंगे ...



लेकिन जीवन अधिक जटिल हो गया।

जैसा कि यह निकला, वास्तव में

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

यह अच्छा है जब इसे अंत तक लागू किया जाता है, लेकिन ऐसा हमेशा नहीं होता है। कभी-कभी एक भूमिका सफलतापूर्वक निभाई जाती है, लेकिन लक्ष्य प्रणाली पर यह बिल्कुल प्रभावित नहीं करता है जैसा कि मूल रूप से चाहते थे।


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



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

• सर्वोत्तम प्रथाओं को इकट्ठा करें।
• स्थैतिक विश्लेषण, लिंट लागू करें।
• परीक्षण करना।
• ओवरक्लॉक करने के लिए, रिलीज प्रबंधन में प्राप्त करने के लिए।

हमने घर पर अभ्यास को लागू करने का फैसला किया और तुरंत उपयुक्त उपकरणों की तलाश में चले गए।

उपकरण

संस्करण नियंत्रण प्रणालियों और निरंतर एकीकरण के दृष्टिकोण से, दर्जनों उपलब्ध समाधान हैं, और एक शाखा परीक्षण चिड़ियाघर है।



रिलीज़ प्रबंधन के दृष्टिकोण से, Ansible के पास कई समाधान नहीं हैं: Git में टैग, Git में टैग या गैलेक्सी में अपलोड करें।

परीक्षण उपकरणों के लिए कई दृष्टिकोण हैं, जिनमें से प्रत्येक का उपयोग करना उन्हें पसंद है। किचनसीआई, इनस्पीक, सर्वरस्पेक का उपयोग कर लोकप्रिय समाधान।

हमारी आत्मा पायथन में लिखे गए अन्सिबल को लेने के लिए झूठ नहीं बोलती, और रूबी दुनिया से उपकरण को मिलाती है। इसलिए, पायथन दुनिया के लिए गैर-देशी सब कुछ बाहर फेंकने के बाद, हमें निम्नलिखित चित्र मिला।



हम उपयोग करते हैं:

• कॉन्फ़िगरेशन प्रबंधन के लिए - गिटहब और गिटलैब। GitLab सीधे GitHub पर देख रहा है। ऐसा क्यों किया, मैं बाद में बताऊंगा।
• CI के लिए, हमने पब्लिक पार्ट के लिए ट्रैविस और प्राइवेट पार्ट के लिए गिटलैब रनर लिया।
• परीक्षण अणु।
• GitHub में लॉन्च करें और Ansible Galaxy में जोड़ें।

इन उपकरणों के साथ हमारा विकास चक्र अधिक मजेदार हो गया है।

अणु

यह उपकरण एक भूमिका को पूरी तरह से परखने में मदद करता है। ऐसा करने के लिए, उसके पास सब कुछ है:

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

टेस्ट मैट्रिक्स

चरणों में परीक्षण मैट्रिक्स पर विचार करें। कुल 11 चरण हैं, लेकिन मैं संक्षिप्त होगा।

नंबर 1. लिंट

वे YAML लिंट और अन्सिबल लिंट चलाते हैं, और कुछ पाते हैं।



ऊपर के उदाहरण में, लिंट ने कसम खाई है कि शेल को केवल अन्सिबल में नहीं बुलाया जाना चाहिए, लेकिन कुछ के लिए बाध्य होना चाहिए।

नंबर 2. नष्ट

पिछले परीक्षणों के बाद बनी हुई चीज़ों से अणु मुक्त हो जाता है।

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

नंबर 3. निर्भरता

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

--- - src: lean_delivery.java version: 1.4 

अणु इसे समझता है और स्क्रिप्ट निष्पादित करेगा:

• गैलेक्सी या गिट जाता है
• पता चलता है कि निर्भरता को संबोधित करने की आवश्यकता है;
• फिर से गैलेक्सी में जाता है;
• डाउनलोड;
• का विस्तार होगा।

नंबर 4. सिंटेक्स

अगला चरण वाक्यविन्यास जाँच है। लेकिन आपकी भूमिका नहीं, बल्कि टेस्ट प्लेबुक जिसे आप अणु में जोड़ते हैं। इस चरण में भी सिंटैक्स त्रुटियां हैं।

स्लाइड से पता चलता है कि ansible भूमिका को 'kibana' कहा जाता है, और परीक्षण Playbook में, इसे ansible-role-kibana कहा जाता है। सिस्टम कहता है: "सब कुछ ठीक होगा और आप इसे यहां बना सकते हैं, लेकिन मैं ऐसा नहीं करूंगा क्योंकि नाम मेल नहीं खाते!"

नंबर 5. क्रिएट करें

इस स्तर पर, हम उस ड्राइवर को इंगित करते हैं जिसके साथ परीक्षण स्थल तैनात है। प्वाइंट गूगल - यह Google मेघ में परीक्षण मशीनों को बढ़ाएगा।

हम अणु में लिख सकते हैं। हम क्या चाहते हैं फ़ाइल। आइए देखें कि यह डॉकर के लिए एक उदाहरण पर कैसे दिखता है।

• मैं खींचने के लिए डॉक छवियों को निर्दिष्ट कर रहा हूं।
• मैं इंगित करता हूं कि उन्हें कैसे समूहित किया जाए ताकि एक इन्वेंट्री फ़ाइल बन जाए।

मैं दो डॉकटर चित्र रखना चाहता हूं: एक आरएचईएल-जैसे के लिए, दूसरा डेबियन-जैसे के लिए, यह सुनिश्चित करने के लिए कि टेस्ट रन के दौरान आरएचईएल और डेबियन दोनों के साथ सब कुछ ठीक होगा।

नंबर 6. तैयार करें

यह परीक्षण निष्पादन पर्यावरण के लिए प्रारंभिक तैयारी कदम है।

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

नंबर 7. धर्मान्तरित

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

• अणु संदर्भित करने के लिए संदर्भित करता है।
• एक परीक्षण स्थल पर तैनात करने योग्य।
• यह चलता है।
• सब कुछ ठीक है!

नंबर 8. इम्पोटेंस

इम्पोटेन्सी टेस्ट सरल है और इस तरह दिखता है।

• पहली बार भूमिका पिछले चरण के माध्यम से चलती है।
• उत्तर देने योग्य रिपोर्ट में कितने परिवर्तन किए गए हैं।
• उसी भूमिका को पुनः लॉन्च करता है।
• चेक करता है कि सिस्टम अपेक्षित स्थिति में लाया गया है, लेकिन दूसरे किराये पर कोई बदलाव नहीं हुआ है।

परिणामस्वरूप, हम समझते हैं कि हमारी भूमिका विनाशकारी नहीं है।

इस चरण में मेरे साथ काम करने वाले लोगों के लिए दर्द हुआ। उन्होंने आलस्य परीक्षण को विफल करने के लिए चारों ओर काम करने की कोशिश की। अणु उन चरणों को नियंत्रित कर सकता है, जिनसे वह गुजरता है, और पहली चीज जो उन्होंने की थी, वह था ईमपेडेंसी चेक।



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

हालांकि वास्तव में किसी तरह की टीम यहां दिखाई देगी। Ansible सीधे ले जाएगा और
फ़ाइल को अधिलेखित कर देगा, लेकिन एक ही समय में सब कुछ बेकार लग रहा है।



जब यह तरकीब भी पकड़ी गई, तो तस्वीर कुछ ऐसी दिखने लगी।



अच्छा - स्क्रिप्ट डिफ़ॉल्ट नाम के तहत चलती है, और यह एक आदर्श है।

नंबर 9. साइड_फैक्ट

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

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

संख्या 10. सत्यापित करें

बुनियादी ढांचे का परीक्षण।



ऊपर एक बहुत ही सरल परीक्षण का एक उदाहरण है। हम जांचते हैं कि हमारे पास डॉकर सामुदायिक संस्करण पैकेज स्थापित है यदि उबंटू स्थापित है, तो इसका सही संस्करण है, और सेवा चल रही है।

कार्यात्मक परीक्षणों के शुभारंभ के इस चरण में, सब कुछ बहुत जटिल हो सकता है।

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



जब कार्यात्मक परीक्षण चलते हैं, तो यह पूरी सूची में सुंदर, ऊपर और नीचे लगता है, और सिस्टम हमें बताता है कि हमारे साथ सब कुछ ठीक है। यदि हम उन्हें लिखते हैं तो फिर से परीक्षण चलेंगे।

नंबर 11. नष्ट

हमने परीक्षण किए, किसी न किसी रूप में एक परीक्षण रिपोर्ट है, और अब हम अपने पीछे के सभी कचरे को हटा देते हैं।

स्वचालन

अणु एक महान उपकरण है। अब सबसे सरल बात बनी हुई है - अपनी भूमिकाओं के स्वत: परीक्षण का आनंद लेने के लिए इसे एक निरंतर एकीकरण प्रणाली से जोड़ना, जो हमने किया।



कहीं और, कई विशेषताएं हैं।

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

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

• GitLab ने अपने नवीनतम रिलीज़ में से एक में तीसरे पक्ष के रिपॉजिटरी के लिए CI करना सीखा।
• भूमिका सार्वजनिक GitHub में निहित है, वही सार्वजनिक GitLab.com इससे जुड़ा है, जिसमें हमने संकेत दिया था: "प्रिय GitLab, बाहरी रिपॉजिटरी के लिए CI एकत्र करें"।
• निजी धावक एक बंद परिधि में गिटलैब की ओर बढ़ रहे हैं, और उनके पास पहले से ही बाइनरी तक पहुंच है, जिसे वे तैनात कर सकते हैं।

वास्तव में, भूमिका सार्वजनिक रूप से निहित है, डेटा भी, और हम किसी को धोखा नहीं दे रहे हैं - हम वास्तविक उपकरणों के साथ वास्तविक परीक्षण चलाते हैं।

आइए एक नज़र डालते हैं कि ट्रैविस में क्या दिखता है।

ट्रैविस

कदम:

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

सार्वजनिक सीआई

सार्वजनिक CI प्राथमिक दिखता है।



GitHub से, Travis का एक तीर, जिसके अंदर Molecule और Docker रहते हैं।

निजी सीआई

GitLab के निजी भाग के लिए, सब कुछ समान है।



निजी परिधि में, हम एक धावक चलाते हैं, और तस्वीर अधिक मजेदार लगती है।



कोड GitHub से GitLab तक मिलता है, कहीं-कहीं एक निजी धावक चलाता है जो बाहरी सेवाओं को खींच सकता है, उदाहरण के लिए, अमेज़ॅन के लिए कुछ चलाएं।

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

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

उत्तर देने योग्य आकाशगंगा

हम समापन पर आए, हमारी भूमिका हरी, सुंदर है, हम इसे गैलेक्सी में प्रकाशित करेंगे।



यह एक सरल ऑपरेशन है:

• ट्रैविस में है कि webhook कॉल।
• इस मामले में, ट्रैविस ट्रिगर होगा, सीआई फिर से चलेगा।
• Webhook को बुलाओ।
• नया संस्करण गैलेक्सी में सफलतापूर्वक बढ़ेगा।

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

यदि आप गैलेक्सी पर कुछ प्रकाशित करते हैं, तो उसे टैग करना न भूलें, ठीक है ताकि संस्करण हैं, और सब कुछ अच्छा था।

टेम्पलेट्स

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

टेम्प्लेट में Ansible lint और GitHub issue_template के लिए डिफ़ॉल्ट सेटिंग्स हैं। सब कुछ सार्वजनिक डोमेन में है, इसलिए हमें एक सुंदर रूप में जारी करना भी पुल अनुरोध या बग रिपोर्ट जारी करने के लिए सुंदर रूप में था। हम Gitignore, Gitlab-ci और उसी रिपॉजिटरी के लाइसेंस के लिए टेम्प्लेट जोड़ते हैं।



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

हमारे पास कई परीक्षण विकल्प हैं ताकि आप जल्दी से सब कुछ किक कर सकें और शुरू कर सकें।

परिणाम

कोई निष्कर्ष नहीं निकलेगा, इसके बजाय मेरे GitHub , My Galaxy प्रोफ़ाइल , GitHub Lean Delivery और Ansible Galaxy के लिंक हैं । लिंक का उपयोग करके आप देख सकते हैं कि सब कुछ कैसे काम करता है। सभी उदाहरण स्वतंत्र रूप से उपलब्ध हैं।

अगला DevOps सम्मेलन मई में आयोजित किया जाएगा।

जब हम घटना की प्रतीक्षा कर रहे हैं, YouTube चैनल और न्यूज़लेटर की सदस्यता लें। चैनल को सर्वश्रेष्ठ रिपोर्टों के रिकॉर्ड के साथ फिर से भरना होगा, और मेलिंग सूची में उपयोगी सामग्री, डिक्रिप्शन और DevOps समाचार के चयन होंगे।

सदस्यता लें, यह दिलचस्प होगा :)