दृष्टिकोण आईएसी (कोडको रूपमा पूर्वाधार) भण्डारमा भण्डारण गरिएको कोड मात्र होइन, तर यो कोडलाई घेरेका व्यक्ति र प्रक्रियाहरू पनि समावेश गर्दछ। के यो सफ्टवेयर विकास देखि पूर्वाधार व्यवस्थापन र विवरण को दृष्टिकोण को पुन: प्रयोग गर्न सम्भव छ? लेख पढ्दा यो विचार मनमा राख्नु राम्रो हुनेछ।

यो मेरो ट्रान्सक्रिप्ट हो प्रदर्शन मा DevopsConf 2019-05-28.

स्लाइड र भिडियोहरू

संस्करण française
रूसी संस्करण
ड्राई रन 2019-04-24 SpbLUG
भिडियो(RU) DevopsConf 2019-05-28 बाट
भिडियो(RU) DINS DevOps EVENING 2019-06-20 बाट
स्लाइडहरू

ब्याश इतिहासको रूपमा पूर्वाधार

मानौं तपाईं नयाँ परियोजनामा आउनुभयो, र तिनीहरूले तपाईंलाई यसो भन्छन्: "हामीसँग छ कोडको रूपमा पूर्वाधार"। वास्तवमा यो बाहिर जान्छ ब्याश इतिहासको रूपमा पूर्वाधार वा उदाहरणका लागि ब्यास इतिहासको रूपमा दस्तावेज। यो एक धेरै वास्तविक स्थिति हो, उदाहरण को लागी, एक समान मामला एक भाषण मा डेनिस Lysenko द्वारा वर्णन गरिएको थियो कसरी सम्पूर्ण पूर्वाधार बदल्ने र राम्रोसँग सुत्न सुरु गर्ने, उनले बास इतिहासबाट कसरी परियोजनाको लागि एक सुसंगत पूर्वाधार पाएको बताए।

केहि इच्छा संग, हामी यो भन्न सक्छौं ब्याश इतिहासको रूपमा पूर्वाधार यो कोड जस्तै छ:

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

मैले के गर्नु पर्छ?

कोडको रूपमा पूर्वाधार

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

सुक्खा

भण्डारण प्रणाली विकास परियोजनामा, त्यहाँ सबटास्क थियो आवधिक रूपमा SDS कन्फिगर गर्नुहोस्: हामी नयाँ रिलीज जारी गर्दैछौं - यसलाई थप परीक्षणको लागि रोल आउट गर्न आवश्यक छ। कार्य एकदम सरल छ:

यहाँ ssh मार्फत लग इन गर्नुहोस् र आदेश कार्यान्वयन गर्नुहोस्।
त्यहाँ फाइल प्रतिलिपि गर्नुहोस्।
यहाँ कन्फिगरेसन सच्याउनुहोस्।
त्यहाँ सेवा सुरु गर्नुहोस्
...
लाभ!

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

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

CFM को लागि ठोस

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

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

प्रत्येक कक्षाले एउटा मात्र कार्य गर्दछ।

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

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

खुला / बन्द सिद्धान्त।

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

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

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

बारबरा लिस्कोभको प्रतिस्थापन सिद्धान्त। कार्यक्रममा भएका वस्तुहरू कार्यक्रमको सही कार्यान्वयनलाई परिवर्तन नगरी तिनीहरूको उपप्रकारका उदाहरणहरूसँग प्रतिस्थापनयोग्य हुनुपर्छ।

यदि तपाइँ यसलाई अझ व्यापक रूपमा हेर्नुभयो भने, यो कुनै विशेष परियोजनाको विशेषता होइन जुन त्यहाँ लागू गर्न सकिन्छ ठोस, यो सामान्यतया CFM को बारे मा छ, उदाहरण को लागी, अर्को परियोजना मा विभिन्न Java, अनुप्रयोग सर्भर, डाटाबेस, OS, आदि को शीर्ष मा एक बाकस Java अनुप्रयोग तैनात गर्न आवश्यक छ। यो उदाहरण प्रयोग गरेर, म थप सिद्धान्तहरू विचार गर्नेछु ठोस

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

यहाँ समस्या यो तथ्यमा छ कि यसलाई जवाफदेहीमा कार्यान्वयन गर्न असम्भव छ, जसको परिणाम स्वरूप टोली भित्र केही सम्झौताहरू देखा पर्छन्।

इन्टरफेस विभाजन सिद्धान्त

इन्टरफेस विभाजन सिद्धान्त: "धेरै ग्राहक-विशेष इन्टरफेसहरू एक सामान्य-उद्देश्य इन्टरफेस भन्दा राम्रो छन्।

प्रारम्भमा, हामीले एप्लिकेसन डिप्लोइमेन्टको सबै परिवर्तनशीलतालाई एउटा उत्तरदायी प्लेबुकमा राख्ने प्रयास गर्‍यौं, तर यसलाई समर्थन गर्न गाह्रो थियो, र जब हामीसँग बाह्य इन्टरफेस निर्दिष्ट हुन्छ (ग्राहकले पोर्ट 443 को अपेक्षा गर्दछ), त्यसपछि एक पूर्वाधार व्यक्तिगतबाट भेला गर्न सकिन्छ। विशिष्ट कार्यान्वयनको लागि ईंटहरू।

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

निर्भरता उल्टो सिद्धान्त। उच्च स्तरहरूमा मोड्युलहरू तल्लो तहहरूमा मोड्युलहरूमा निर्भर हुनु हुँदैन। दुबै प्रकारका मोड्युलहरू अमूर्तहरूमा निर्भर हुनुपर्छ। Abstractions विवरण मा निर्भर हुनु हुँदैन। विवरणहरू abstractions मा निर्भर हुनुपर्छ।

यहाँ उदाहरण एक antipattern मा आधारित हुनेछ।

एकजना ग्राहकको निजी क्लाउड थियो।
हामीले क्लाउड भित्र भर्चुअल मेसिनहरू अर्डर गर्यौं।
तर क्लाउडको प्रकृतिको कारणले गर्दा, एप डिप्लोइमेन्ट VM अन भएको हाइपरभाइजरसँग जोडिएको थियो।

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

अन्तरक्रिया

कोडको रूपमा पूर्वाधार भनेको कोडको बारेमा मात्र होइन, तर कोड र व्यक्तिहरू बीचको सम्बन्ध, पूर्वाधार विकासकर्ताहरू बीचको अन्तरक्रियाको बारेमा पनि हो।

बस कारक

मानौं कि तपाइँसँग तपाइँको परियोजनामा Vasya छ। Vasya लाई तपाईको पूर्वाधार बारे सबै थाहा छ, यदि Vasya अचानक गायब भयो भने के हुनेछ? यो एकदमै वास्तविक अवस्था हो, किनकि उसलाई बसले ठक्कर दिन सक्छ। कहिलेकाहीँ यस्तो हुन्छ। यदि यो हुन्छ र कोड, यसको संरचना, यसले कसरी काम गर्दछ, उपस्थिति र पासवर्डहरूको बारेमा टोलीमा वितरण गरिएको छैन भने, त्यसपछि तपाईंले धेरै अप्रिय परिस्थितिहरूको सामना गर्न सक्नुहुन्छ। यी जोखिमहरूलाई कम गर्न र टोली भित्र ज्ञान वितरण गर्न, तपाईं विभिन्न दृष्टिकोणहरू प्रयोग गर्न सक्नुहुन्छ

जोडी Devopsing

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

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

कोड समीक्षा

विषयगत रूपमा, यो पूर्वाधारको बारेमा ज्ञान फैलाउन र यसले कोड समीक्षा प्रयोग गरेर कसरी काम गर्छ भन्ने अझ प्रभावकारी थियो:

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

यहाँ हाइलाइट यो थियो कि समीक्षकहरू एक एक गरेर चयन गरिएको थियो, एक तालिका अनुसार, अर्थात्। केही हदसम्म सम्भावनाको साथ तपाईं पूर्वाधारको नयाँ टुक्रामा चढ्नुहुनेछ।

कोड शैली

समय बित्दै जाँदा, झगडाहरू समीक्षाहरूमा देखा पर्न थाले, किनभने ... समीक्षकहरूको आफ्नै शैली थियो र समीक्षकहरूको रोटेशनले तिनीहरूलाई विभिन्न शैलीहरू: 2 खाली ठाउँहरू वा 4, camelCase वा snake_case बनाए। यसलाई तत्काल कार्यान्वयन गर्न सकिएन ।

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

हरियो निर्माण मास्टर

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

छुट्टै शाखामा विकास भइरहेको छ ।
यस थ्रेडमा परीक्षणहरू चलिरहेका छन्।
यदि परीक्षणहरू असफल भएमा, कोडले यसलाई मास्टरमा बनाउँदैन।

यो निर्णय गर्नु निकै पीडादायी थियो, किनकि... धेरै विवाद उत्पन्न भयो, तर यो यसको लायक थियो, किनकि ... समीक्षाहरूले शैलीमा भिन्नता बिना मर्जरको लागि अनुरोधहरू प्राप्त गर्न थाले, र समयसँगै समस्या क्षेत्रहरूको संख्या घट्न थाल्यो।

IaC परीक्षण

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

कसैले सोध्न सक्छ, जटिल पूर्वाधारलाई किन झनै जटिल बनाउने ? पूर्वाधारका लागि परीक्षणहरू, कोडको लागि जस्तै, सरलीकरणको बारेमा होइन, तर तपाइँको पूर्वाधारले कसरी काम गर्नुपर्छ भनेर जान्नको बारेमा हो।

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

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

अघिल्लो चरणको समस्या समात्न सकिन्छ जब हामीले उद्धरणहरू बिर्सन्छौं, यसको लागि प्रकृतिमा धेरै उपायहरू छन्। शेलचेक, सामान्यतया त्यहाँ ती मध्ये धेरै छन्, र सम्भवतः तपाईंले आफ्नो IDE अन्तर्गत आफ्नो स्ट्याकको लागि लिन्टर पाउन सक्नुहुन्छ।

भाषा
उपकरण

बाश
शेलचेक

रूबी
RuboCop

अजगर
पिलिन्ट

उत्तरदायी
उत्तरदायी लिन्ट

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

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

सुरुमा हामीले कुरा गर्यौं ठोस र हाम्रो पूर्वाधारमा साना इँटाहरू हुनुपर्छ। उनीहरुको पालो आएको छ ।

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

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

प्रश्न, CFM को लागि परीक्षणहरू के हुन्? तपाइँ केवल स्क्रिप्ट चलाउन सक्नुहुन्छ, वा तपाइँ यसको लागि तयार समाधानहरू प्रयोग गर्न सक्नुहुन्छ:

CFM
उपकरण

अज्ञात
टेस्टिनफ्रा

सेफ
इन्स्पेक्टर

सेफ
सर्भरस्पेक

साल्ट स्ट्याक
गस

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 को लागि github मा परियोजनाहरु मा परिवर्तन को एक उदाहरण छ:

IaC परीक्षण फ्रेमवर्क

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

CFM
उपकरण

अज्ञात
अणु

सेफ
टेस्ट भान्सा

ट्राफर्म
टेरेटेस्ट

2018-2019 को लागि github मा परियोजनाहरु मा परिवर्तन को उदाहरण:

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

सुरुमा हामीले testkitchen प्रयोग गरेर प्रयास गरे:

समानान्तरमा VM सिर्जना गर्नुहोस्।
उत्तरदायी भूमिकाहरू लागू गर्नुहोस्।
निरीक्षण चलाउनुहोस्।

25-35 भूमिकाहरूको लागि यसले 40-70 मिनेट काम गर्यो, जुन लामो थियो।

अर्को चरण जेनकिन्स/डकर/एन्सिबल/मोलिक्युलमा संक्रमण थियो। वैचारिक हिसाबले सबै एउटै हो

लिन्ट प्लेबुकहरू।
भूमिकाहरू पङ्क्तिबद्ध गर्नुहोस्।
कन्टेनर सुरु गर्नुहोस्
उत्तरदायी भूमिकाहरू लागू गर्नुहोस्।
testinfra चलाउनुहोस्।
इडम्पोटेन्सी जाँच गर्नुहोस्।

40 भूमिकाहरूको लागि लिन्टिङ र एक दर्जनका लागि परीक्षणहरू लगभग 15 मिनेट लिन थाले।

के छनौट गर्ने धेरै कारकहरूमा निर्भर गर्दछ, जस्तै प्रयोग गरिएको स्ट्याक, टोलीमा विशेषज्ञता, आदि। यहाँ सबैले एकाइ परीक्षण प्रश्न कसरी बन्द गर्ने भनेर आफै निर्णय गर्छन्

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

पूर्वाधार परीक्षण पिरामिडमा अर्को चरण एकीकरण परीक्षण हुनेछ। तिनीहरू एकाइ परीक्षणहरू जस्तै छन्:

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

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

IaC परीक्षण: अन्त्यदेखि अन्त्य परीक्षणहरू

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

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

यो योजना फ्रेमवर्क भित्र सम्म, धेरै लामो समय को लागी काम गर्यो अनुसन्धान हामीले यसलाई Openshift मा स्थानान्तरण गर्ने प्रयास गरेका छैनौं। कन्टेनरहरू उस्तै रहन्छन्, तर प्रक्षेपण वातावरण परिवर्तन भएको छ (नमस्ते DRY फेरि)।

अनुसन्धान विचार अगाडी बढ्यो, र ओपनशिफ्टमा उनीहरूले APB (Ansible Playbook Bundle) जस्ता कुरा फेला पारे, जसले तपाईंलाई कन्टेनरमा पूर्वाधार कसरी डिप्लोय गर्ने भन्ने ज्ञान प्याक गर्न अनुमति दिन्छ। ती। त्यहाँ पूर्वाधार कसरी प्रयोग गर्ने भन्ने बारे ज्ञानको दोहोर्याउन सकिने, परीक्षण योग्य बिन्दु छ।

यो सबै राम्रो लाग्थ्यो जबसम्म हामी एक विषम पूर्वाधारमा पुग्दैनौं: हामीलाई परीक्षणको लागि Windows चाहिन्छ। नतिजाको रूपमा, के, कहाँ, कसरी प्रयोग गर्ने, र परीक्षण गर्ने ज्ञान जेन्किन्समा छ।

निष्कर्ष

संहिता अनुसार पूर्वाधार

भण्डारमा कोड।
मानव अन्तरक्रिया।
पूर्वाधार परीक्षण।

लिंक

स्रोत: www.habr.com

200 लाइनहरू पूर्वाधार कोडको परीक्षणबाट मैले के सिकें