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

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

स्लाइड और वीडियो

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

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

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

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

क्या करना है?

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

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

सूखा

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

यहां ssh के माध्यम से लॉग इन करें और कमांड निष्पादित करें।
फ़ाइल को वहां कॉपी करें.
यहां कॉन्फ़िगरेशन ठीक करें.
वहां सेवा प्रारंभ करें
...
लाभ!

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

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

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

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

एकल उत्तरदायित्व सिद्धांत

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

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

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

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

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

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

लिस्कोव प्रतिस्थापन सिद्धांत

बारबरा लिस्कोव का प्रतिस्थापन सिद्धांत। किसी प्रोग्राम में ऑब्जेक्ट को प्रोग्राम के सही निष्पादन को बदले बिना उनके उपप्रकारों के उदाहरणों से बदला जाना चाहिए

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

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

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

इंटरफ़ेस पृथक्करण सिद्धांत

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

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

निर्भरता व्युत्क्रम सिद्धांत

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

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

ग्राहकों में से एक के पास निजी क्लाउड था।
हमने क्लाउड के अंदर वर्चुअल मशीनें ऑर्डर कीं।
लेकिन क्लाउड की प्रकृति के कारण, एप्लिकेशन परिनियोजन इस बात से जुड़ा था कि वीएम किस हाइपरविजर पर था।

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

इंटरेक्शन

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

बस कारक

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

जोड़ी देवोपसिंग

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

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

कोड समीक्षा

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

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

यहां मुख्य बात यह थी कि समीक्षकों को एक कार्यक्रम के अनुसार, एक-एक करके चुना गया था। कुछ हद तक संभावना के साथ आप बुनियादी ढांचे के एक नए हिस्से में पहुंच जाएंगे।

कोड शैली

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

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

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

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

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

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

आईएसी परीक्षण

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

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

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 "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

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

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

भाषा
उपकरण

खूब जोर से पीटना
शेलचेक

माणिक
रूबोकॉप

अजगर
पाइलिंट

ansible
अन्सिबल लिंट

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

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

शुरुआत में ही हमने बात की ठोस और हमारा बुनियादी ढांचा छोटी ईंटों से बना होना चाहिए। उनका समय आ गया है.

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

IaC परीक्षण: इकाई परीक्षण उपकरण

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

CFM
उपकरण

Ansible
टेस्टिनफ्रा

महाराज
inspec

महाराज
सर्वरस्पेक

नमक का ढेर
गॉस

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 Testing frameworks

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

CFM
उपकरण

Ansible
अणु

महाराज
टेस्ट किचन

terraform
टेराटेस्ट

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

अणु बनाम. टेस्टकिचन

प्रारंभ में हम टेस्टकिचन का उपयोग करने का प्रयास किया:

समानांतर में एक VM बनाएं.
उत्तरदायी भूमिकाएँ लागू करें।
निरीक्षण चलाएँ.

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

अगला कदम जेनकींस/डॉकर/एन्सिबल/अणु में संक्रमण था। वैचारिक तौर पर सब कुछ एक जैसा है

लिंट प्लेबुक.
भूमिकाओं को पंक्तिबद्ध करें.
कंटेनर लॉन्च करें
उत्तरदायी भूमिकाएँ लागू करें।
टेस्टिनफ़्रा चलाएँ.
निष्क्रियता की जाँच करें.

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

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

IaC परीक्षण: एकीकरण परीक्षण

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

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

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

IaC परीक्षण: शुरू से अंत तक परीक्षण

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

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

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

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

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

निष्कर्ष

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

भंडार में कोड.
मानव वार्तालाप।
बुनियादी ढांचे का परीक्षण.

लिंक

स्रोत: www.habr.com

इन्फ्रास्ट्रक्चर कोड की 200 लाइनों के परीक्षण से मैंने क्या सीखा