IaC (इन्फ्रास्ट्रक्चर इन कोड) दृष्टिकोण न केवल उस कोड का होता है जो भंडार में संग्रहीत होता है, बल्कि उन लोगों और प्रक्रियाओं का भी होता है जो इस कोड को घेरते हैं। क्या सॉफ्टवेयर विकास से लेकर प्रबंधन और बुनियादी ढांचे के विवरण तक के दृष्टिकोण का पुन: उपयोग संभव है? लेख पढ़ते समय इस विचार को ध्यान में रखना अतिश्योक्तिपूर्ण नहीं होगा।

रूसी संस्करण

यह DevopsConf 2019-05-28 पर मेरे प्रदर्शन का एक प्रतिलेख है।

बैश इतिहास के रूप में बुनियादी ढाँचा

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

यदि आप चाहें, तो आप कह सकते हैं कि इंफ्रास्ट्रक्चर जैसे बैश इतिहास कोड की तरह है:

1. प्रजनन क्षमता : आप बैश इतिहास ले सकते हैं, वहां से कमांड निष्पादित कर सकते हैं, शायद, वैसे, आपको आउटपुट पर एक काम करने वाला कॉन्फ़िगरेशन मिलेगा।
2. संस्करण : आप जानते हैं कि कौन आया था और क्या किया था, फिर से, इस तथ्य से नहीं कि यह आपको आउटपुट पर काम करने वाले कॉन्फ़िगरेशन तक ले जाएगा।
3. इतिहास : किसने क्या किया इसका इतिहास। यदि आप सर्वर खो देते हैं तो केवल आप इसका उपयोग नहीं कर सकते।

क्या करें?

कोड के रूप में अवसंरचना

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

सूखी

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

• यहाँ आकर ssh और कमांड निष्पादित करें।
• वहां फाइल कॉपी करें।
• यहाँ विन्यास के लिए एक ट्वीक है।
• वहां सेवा शुरू करें
• ...
• लाभ!

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

यह पता चला है कि इस तरह की एक प्रथा DRY है (डोंट रिपीट योरसेल्फ)। विचार मौजूदा कोड का पुन: उपयोग करने के लिए है। यह सरल लगता है, लेकिन यह अभी तक नहीं आया था। हमारे मामले में, यह एक सामान्य विचार था: स्क्रिप्ट से कॉन्फ़िगरेशन को अलग करना। यानी व्यवसाय तर्क कैसे स्थापना अलग से तैनात है, अलग से कॉन्फ़िगर करता है।

सीएफएम के लिए ठोस

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

एकल जिम्मेदारी सिद्धांत

प्रत्येक वर्ग केवल एक कार्य करता है।

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

खुले बंद सिद्धांत

खुलेपन / बंद करने का सिद्धांत।

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

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

Liskov प्रतिस्थापन सिद्धांत

बारबरा लिस्कॉव का प्रतिस्थापन सिद्धांत। कार्यक्रम की शुद्धता को बदले बिना कार्यक्रम में वस्तुओं को उनके उपप्रकारों के उदाहरणों के साथ बदली जाना चाहिए

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

हमारे मामले में, इंफ्रास्ट्रक्चर टीम के हिस्से के रूप में, एक समझौता है कि अगर हमने imjjava या oraclejava की भूमिका स्थापित की है, तो हमारे पास एक द्विआधारी जावा निष्पादन योग्य है। यह आवश्यक है क्योंकि उच्च भूमिकाएं इस व्यवहार पर निर्भर करती हैं; वे उम्मीद करती हैं कि जावा मौजूद होगा। उसी समय, यह हमें एप्लिकेशन परिनियोजन तर्क को बदले बिना जावा के एक कार्यान्वयन / संस्करण को दूसरे के साथ बदलने की अनुमति देता है।

यहाँ समस्या इस तथ्य में निहित है कि Ansible में इस तरह के कार्यान्वयन को असंभव है, परिणामस्वरूप, टीम के भीतर कुछ समझौते दिखाई देते हैं।

इंटरफ़ेस अलगाव सिद्धांत

इंटरफ़ेस पृथक्करण का सिद्धांत "विशेष रूप से ग्राहकों के लिए डिज़ाइन किए गए कई इंटरफेस एक सामान्य उद्देश्य वाले इंटरफ़ेस से बेहतर हैं।

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

निर्भरता उलटा सिद्धांत

निर्भरता उलटा का सिद्धांत। ऊपरी स्तर के मॉड्यूल को निचले स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों प्रकार के मॉड्यूल को अमूर्तता पर निर्भर होना चाहिए। विवरण विवरण पर निर्भर नहीं होना चाहिए। विवरण अमूर्तता पर निर्भर होना चाहिए।

यहां उदाहरण एंटीपैटर्न पर आधारित होगा।

1. ग्राहकों में से एक के पास एक निजी क्लाउड था।
2. बादल के अंदर, हमने आभासी मशीनों का आदेश दिया।
3. लेकिन क्लाउड की विशेषताओं के मद्देनजर, आवेदन की तैनाती को बांध दिया गया था कि वीएम किस हाइपरवाइजर पर था।

यानी उच्च-स्तरीय अनुप्रयोग परिनियोजन तर्क, निर्भरताएं हाइपरविज़र के निचले स्तर तक प्रवाहित होती हैं, और इसका अर्थ इस तर्क का पुन: उपयोग करते समय समस्याएँ हैं। ऐसा मत करो।

इंटरेक्शन

एक कोड के रूप में इन्फ्रास्ट्रक्चर न केवल कोड के बारे में है, बल्कि कोड और किसी व्यक्ति के बीच के संबंध के बारे में भी है, जो बुनियादी ढांचे के डेवलपर्स के बीच बातचीत के बारे में है।

बस कारक

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

जोड़ी चटकती है

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

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

कोड समीक्षा

विशेष रूप से, अधिक कुशलता से, बुनियादी ढांचे के बारे में ज्ञान का प्रसार और यह कैसे कोड समीक्षा का उपयोग करके आयोजित किया गया था:

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

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

कोड शैली

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

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

ग्रीन बिल्ड मास्टर

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

• विकास एक अलग शाखा में है।
• इस धागे पर टेस्ट चलता है।
• यदि परीक्षण विफल हो जाते हैं, तो कोड विज़ार्ड में नहीं जाएगा।

यह निर्णय लेना बहुत दर्दनाक था क्योंकि बहुत विवाद हुआ, लेकिन यह इसके लायक था, क्योंकि विलय के अनुरोध शैली में असहमति के बिना समीक्षा के लिए आने लगे और समय के साथ, समस्या क्षेत्रों की संख्या कम होने लगी।

IaC परीक्षण

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

कोई यह पूछ सकता है कि जटिल बुनियादी ढांचे को और अधिक कठिन क्यों बनाया जाए? बुनियादी ढांचे के लिए टेस्ट, साथ ही साथ कोड के लिए सरलीकरण के बारे में नहीं है, लेकिन यह जानने के बारे में कि आपका बुनियादी ढांचा कैसे काम करना चाहिए।

IaC परीक्षण पिरामिड

IaC परीक्षण: स्थैतिक विश्लेषण

यदि आप तुरंत पूरे बुनियादी ढांचे को तैनात करते हैं और यह सत्यापित करते हैं कि यह काम करता है, तो यह पता चला सकता है कि इसमें बहुत समय लगता है और बहुत समय की आवश्यकता होती है। इसलिए, आधार को जल्दी से काम करना चाहिए, यह बहुत कुछ है, और यह कई आदिम स्थानों को कवर करता है।

बैश मुश्किल है

यहाँ एक तुच्छ उदाहरण है। वर्तमान निर्देशिका में सभी फ़ाइलों का चयन करें और किसी अन्य स्थान पर कॉपी करें। पहली बात जो मन में आती है:

for i in * ; do cp $i /some/path/$i.bak done 

लेकिन क्या होगा अगर फ़ाइल नाम में कोई स्थान है? ठीक है, ठीक है, हम स्मार्ट हैं, हम उद्धरण का उपयोग कर सकते हैं:

 for i in * ; do cp "$i" "/some/path/$i.bak" ; done 

अच्छा किया? नहीं! क्या होगा अगर डायरेक्टरी में कुछ नहीं है, यानी ग्लोबिंग से काम नहीं चलेगा।

 find . -type f -exec mv -v {} dst/{}.bak \; 

अब अच्छा किया? नहीं ... भूल गए कि फ़ाइल का नाम \n हो सकता है।

 touch x mv x "$(printf "foo\nbar")" find . -type f -print0 | xargs -0 mv -t /path/to/target-dir 

स्थैतिक विश्लेषण उपकरण

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

IaC परीक्षण: यूनिट टेस्ट

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

शुरुआत में, हमने SOLID और इस तथ्य के बारे में बात की कि हमारे बुनियादी ढांचे में छोटी ईंटें शामिल होनी चाहिए। उनका समय आ गया है।

1. इंफ्रास्ट्रक्चर को छोटी ईंटों में कुचल दिया जाता है, उदाहरण के लिए, अंसिबल भूमिकाएँ।
2. किसी तरह का माहौल सामने आता है, चाहे वह डॉकटर हो या वीएम।
3. हम इस परीक्षण के वातावरण के लिए अपनी Ansible भूमिका को लागू करते हैं।
4. हम जांचते हैं कि सब कुछ काम किया जैसा कि हम उम्मीद करते हैं (परीक्षण चलाते हैं)।
5. हम तय करते हैं कि ठीक है या नहीं।

IaC परीक्षण: यूनिट परीक्षण उपकरण

सवाल यह है कि सीएफएम के लिए परीक्षण क्या हैं? आप स्क्रिप्ट कोरी चला सकते हैं, या आप इसके लिए तैयार समाधान का उपयोग कर सकते हैं:

Testinfra के लिए उदाहरण, हम सत्यापित करते हैं कि उपयोगकर्ता test1 , test2 मौजूद हैं और sshusers समूह में हैं:

 def test_default_users(host): users = ['test1', 'test2' ] for login in users: assert host.user(login).exists assert 'sshusers' in host.user(login).groups 

क्या चुनना है? सवाल जटिल और अस्पष्ट है, यहाँ 2018-2019 के लिए गिटब पर परियोजनाओं में बदलाव का एक उदाहरण है:

IaC परीक्षण रूपरेखा

यह सब एक साथ रखना और चलाना कैसे है? इंजीनियरों की पर्याप्त संख्या होने पर आप स्वयं सब कुछ ले और कर सकते हैं । और आप तैयार समाधान ले सकते हैं, हालांकि उनमें से बहुत सारे नहीं हैं:

2018-2019 के लिए गीथब पर परियोजनाओं में बदलाव का एक उदाहरण:

अणु बनाम Testkitchen

प्रारंभ में, हमने परीक्षण करने की कोशिश की :

1. समानांतर में VMs बनाएँ।
2. अन्सिबल रोल्स लगायें।
3. इंस्पेक्टर को भगाओ।

25-35 भूमिकाओं के लिए, इसने 40-70 मिनट तक काम किया, जो एक लंबा समय था।

अगला कदम जेनकिंस / डॉकटर / एंसिबल / अणु पर स्विच करना था। आदर्श रूप से, सब कुछ समान है

1. लिंट प्लेबुक।
2. भूमिकाएं निभाने के लिए।
3. कंटेनर चलाएं
4. अन्सिबल रोल्स लगायें।
5. टेस्टिनफ्रा को दूर भगाएं।
6. आलस्य की जाँच करें।

एक दर्जन के लिए 40 भूमिकाओं और परीक्षणों के लिए एक शासक को लगभग 15 मिनट लग गए।

क्या चुनना है यह कई कारकों पर निर्भर करता है, जैसे कि उपयोग किए गए स्टैक, टीम में विशेषज्ञता, आदि। यहां हर कोई निर्णय लेता है कि यूनिट परीक्षण के मुद्दे को कैसे बंद किया जाए

IaC परीक्षण: एकीकरण टेस्ट

बुनियादी ढांचे के परीक्षण के पिरामिड के अगले चरण में, एकीकरण परीक्षण दिखाई देंगे। वे इकाई परीक्षणों के समान हैं:

1. इंफ्रास्ट्रक्चर को छोटी ईंटों में कुचल दिया जाता है, जैसे कि अंसिबल भूमिकाएँ।
2. किसी तरह का माहौल सामने आता है, चाहे वह डॉकटर हो या वीएम।
3. इस परीक्षण वातावरण में कई अंसनीय भूमिकाएँ लागू होती हैं।
4. हम जांचते हैं कि सब कुछ काम किया जैसा कि हम उम्मीद करते हैं (परीक्षण चलाते हैं)।
5. हम तय करते हैं कि ठीक है या नहीं।

मोटे तौर पर, हम सिस्टम के एक व्यक्तिगत तत्व के संचालन की जांच नहीं करते हैं जैसा कि यूनिट परीक्षणों में होता है, हम जांचते हैं कि सर्वर को समग्र रूप में कैसे कॉन्फ़िगर किया गया है।

IaC परीक्षण: एंड टू एंड टेस्ट

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

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

इस योजना ने लंबे समय तक काम किया, जब तक कि अध्ययन के हिस्से के रूप में हमने इसे ओपेंशिफ्ट में स्थानांतरित करने की कोशिश नहीं की। कंटेनर वही रहे, लेकिन लॉन्च का माहौल बदल गया (हेलो DRY फिर से)।

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

यह सब अच्छा लग रहा था, जब तक हम खुद को एक विषम बुनियादी ढांचे में दफन नहीं करते: हमें परीक्षणों के लिए विंडोज की आवश्यकता थी। नतीजतन, ज्ञान को तैनात करने और परीक्षण करने के बारे में ज्ञान कहाँ है।

निष्कर्ष

कोड जैसा इन्फ्रास्ट्रक्चर है

• भंडार में कोड।
• लोगों की सहभागिता।
• अवसंरचना परीक्षण।