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

रूसी संस्करण

यह DevopsConf 2019-05-28 पर मेरे भाषण ( वीडियो आरयू ) का अनुवाद है।

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

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

हमें स्रोत कोड परिभाषा की जाँच करें: a text listing of commands to be compiled or assembled into an executable computer program । अगर हम चाहें तो इन्फ्रास्ट्रक्चर को कोड की तरह बैश इतिहास के रूप में पेश कर सकते हैं। यह एक पाठ और आदेशों की एक सूची है। यह वर्णन करता है कि सर्वर कैसे कॉन्फ़िगर किया गया था। इसके अलावा, यह है:

1. Reproducible : आप बैश इतिहास प्राप्त कर सकते हैं, कमांड निष्पादित कर सकते हैं और संभवतया वर्किंग इन्फ्रास्ट्रक्चर प्राप्त कर सकते हैं।
2. वर्जनिंग : आप जानते हैं कि किसने कब, क्या किया और क्या किया।
   दुर्भाग्य से, यदि आप सर्वर खो देते हैं, तो आप कुछ भी नहीं कर पाएंगे क्योंकि कोई बैश इतिहास नहीं है, आपने इसे सर्वर के साथ खो दिया है।

क्या करना है?

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

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

सूखी

हम एसडीएस (सॉफ्टवेयर-डिफाइंड स्टोरेज) विकसित कर रहे थे। SDS में कस्टम OS वितरण, upscale सर्वर, बहुत से व्यावसायिक तर्क शामिल थे, नतीजतन, इसे वास्तविक हार्डवेयर का उपयोग करना पड़ा। समय-समय पर, एसडीएस स्थापित करने वाला एक उप-कार्य था। नई रिलीज़ प्रकाशित करने से पहले, हमें इसे स्थापित करना और जांचना होगा। सबसे पहले, ऐसा लग रहा था कि यह एक बहुत ही सरल कार्य है:

• कमांड चलाने और चलाने के लिए एसएसएच।
• एक फ़ाइल SCP।
• एक कॉन्फ़िगरेशन संशोधित करें।
• एक सेवा चलाएं।
• ...
• लाभ!

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

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

मुझे उम्मीद है कि आपको मुख्य विचार मिल गया होगा, इस स्तर पर हमें लगातार स्क्रिप्ट तर्क को तब तक करना होगा जब तक कि सेवा ठीक न हो। लेकिन, इसके लिए एक समाधान था। यह DRY था

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

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

यह परियोजना बढ़ रही थी, जिसके परिणामस्वरूप, हमने Ansible का उपयोग करने का निर्णय लिया। उसके कारण थे:

1. बैश में जटिल तर्क नहीं होना चाहिए ।
2. हमारे पास Ansible में कुछ मात्रा में विशेषज्ञता थी।

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

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

एक वर्ग के पास केवल एक ही जिम्मेदारी होनी चाहिए, अर्थात्, सॉफ़्टवेयर के विनिर्देशन के केवल एक भाग में परिवर्तन कक्षा के विनिर्देश को प्रभावित करने में सक्षम होना चाहिए।

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

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

सॉफ्टवेयर इकाइयाँ ... विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद।

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

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

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

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

हमारे मामले में उदाहरण के लिए, इंफ्रास्ट्रक्चर टीम के अंदर एक समझौता है: यदि आप ibm java भूमिका या oracle java या openjdk को तैनात करते हैं, तो आपके पास निष्पादन योग्य जावा बाइनरी होगा। हमें इसकी आवश्यकता है क्योंकि शीर्ष * स्तर की अंय भूमिकाएँ उस पर निर्भर करती हैं। इसके अलावा, यह तर्क स्थापित करने वाले एप्लिकेशन को संशोधित किए बिना जावा कार्यान्वयन को स्वैप करने की अनुमति देता है।

दुर्भाग्य से, Ansible playbooks में इसके लिए कोई सिंटैक्स चीनी नहीं है। इसका अर्थ है कि आपको अंसिबल भूमिकाएँ विकसित करते समय इसे ध्यान में रखना चाहिए।

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

कई क्लाइंट-विशिष्ट इंटरफेस एक सामान्य-उद्देश्य इंटरफ़ेस से बेहतर हैं।

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

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

एक को "अमूर्तता पर निर्भर होना चाहिए, [नहीं] सहमति।"

• उच्च-स्तरीय मॉड्यूल को निम्न-स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों को अमूर्त (जैसे इंटरफेस) पर निर्भर होना चाहिए।
• विवरण विवरण पर निर्भर नहीं होना चाहिए। विवरण (ठोस कार्यान्वयन) अमूर्तता पर निर्भर होना चाहिए।

मैं इस सिद्धांत का वर्णन प्रतिरूप के माध्यम से करना चाहूंगा।

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

दूसरे शब्दों में, हम एक और क्लाउड में हमारे IaC का पुन: उपयोग करने में सक्षम नहीं थे क्योंकि शीर्ष-स्तरीय परिनियोजन तर्क निम्न-स्तरीय कार्यान्वयन पर निर्भर करता था। कृपया इसे न करें

इंटरेक्शन

इन्फ्रास्ट्रक्चर केवल कोड नहीं है, यह इंटरैक्शन कोड <-> DevOps, DevOps <-> DevOps, IaC <-> लोगों के बारे में भी है।

बस कारक

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

जोड़ी DevOpsing

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

• ऑनबोर्डिंग : मेंटर और नए व्यक्ति को बैकलॉग से एक वास्तविक कार्य मिलता है और एक साथ काम करते हैं - व्यक्ति से व्यक्ति को ज्ञान हस्तांतरित करते हैं।
• हादसा कॉल : समस्या निवारण के दौरान, इंजीनियरों का एक समूह है, वे एक समाधान की तलाश कर रहे हैं। मुख्य बिंदु यह है कि इस घटना का नेतृत्व करने वाला एक व्यक्ति है। व्यक्ति स्क्रीन और विचारों को साझा करता है। अन्य लोग सावधानीपूर्वक उसका अनुसरण कर रहे हैं और बैश ट्रिक्स, गलतियों, लॉग पार्सिंग आदि को नोटिस कर रहे हैं।

कोड समीक्षा

मेरे दृष्टिकोण से, कोड समीक्षा आपके बुनियादी ढांचे के बारे में एक टीम के अंदर ज्ञान साझा करने के सबसे कुशल तरीकों में से एक है। यह कैसे काम करता है?

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

सबसे दिलचस्प बात यह है कि हम एक समीक्षक को घुमा रहे थे। इसका मतलब यह है कि हर दो दिन में हमने एक नया समीक्षक चुना और समीक्षक सभी मर्ज अनुरोधों के माध्यम से देख रहा था। नतीजतन, सैद्धांतिक रूप से, प्रत्येक व्यक्ति को बुनियादी ढांचे के एक नए हिस्से को छूना था और सामान्य रूप से हमारे बुनियादी ढांचे के बारे में औसत ज्ञान था।

कोड शैली

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

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

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

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

• एक रिपॉजिटरी है जिसमें आपका बुनियादी ढांचा विवरण होता है।
• हर कोई एक समर्पित शाखा में अपने बदलाव कर रहा है।
• प्रत्येक शाखा के लिए, हम परीक्षण चला रहे हैं।
• यदि परीक्षण विफल हो रहे हैं, तो आप मास्टर शाखा में विलय करने में सक्षम नहीं हैं।

यह एक कठिन निर्णय था। उम्मीद है कि समीक्षा प्रक्रिया के दौरान, कोड शैली के बारे में कोई तर्क नहीं था और कोड गंध की मात्रा कम हो रही थी।

IaC परीक्षण

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

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

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 परीक्षण: यूनिट टेस्ट

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

जब हम सीएफएम के लिए एसओएलआईडी के बारे में बात कर रहे थे, तो मैंने उल्लेख किया कि हमारे बुनियादी ढांचे को सरल ईंटों / मॉड्यूल से बनाया जाना चाहिए। अब समय आ गया है:

1. सरल मॉड्यूल / ब्रेक में बुनियादी ढांचे को विभाजित करें, अर्थात् Ansible भूमिकाएं।
2. एक वातावरण बनाएं यानी डॉकर या वीएम।
3. पर्यावरण के लिए अपने एक साधारण ब्रेक / मॉड्यूल को लागू करें।
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

शुरुआत में, हमने हाइपर- v के अंदर टेस्टीकेन के माध्यम से ansible भूमिकाओं का परीक्षण करने की कोशिश की:

1. VMs बनाएँ।
2. उत्तर देने योग्य भूमिकाएँ लागू करें।
3. इंस्पेक चलाएं।

25-35 अंसिल भूमिकाओं के लिए 40-70 मिनट का समय लगा। यह हमारे लिए बहुत लंबा था।

अगले चरण में जेनकिंस / docker / Ansible / अणु का उपयोग किया गया था। यह लगभग एक ही विचार है:

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

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

सबसे अच्छा उपाय क्या है? एक ओर, मैं अंतिम अधिकार नहीं बनना चाहता, लेकिन दूसरी ओर, मैं अपनी बात साझा करना चाहूंगा। कोई चांदी की गोली मौजूद नहीं है, हालांकि, यदि अन्न के अणु के मामले में एक अधिक उपयुक्त समाधान है तो परीक्षण करने योग्य है।

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

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

1. सरल मॉड्यूल / ब्रेक में बुनियादी ढांचे को विभाजित करें, अर्थात् Ansible भूमिकाएं।
2. एक वातावरण बनाएं यानी डॉकर या वीएम।
3. पर्यावरण को सरल विराम / मॉड्यूल के संयोजन को लागू करें।
4. जांचें कि सब कुछ ठीक है या नहीं।
   ...
5. लाभ!

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

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

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

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

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

हम शोध जारी रखते हैं और एपीबी (अन्सिबल प्लेबुक बंडल) पाते हैं। मुख्य विचार यह है कि आप सभी आवश्यक चीजों को एक कंटेनर में पैक करते हैं और कंटेनर को Openshift के अंदर चलाते हैं। इसका मतलब है कि आपके पास एक प्रतिलिपि प्रस्तुत करने योग्य और परीक्षण योग्य समाधान है।

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

निष्कर्ष

कोड के रूप में मूल संरचना यह का एक संयोजन है:

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