दृष्टिकोन आयएसी (कोड म्हणून पायाभूत सुविधा) मध्ये केवळ रेपॉजिटरीमध्ये संग्रहित केलेला कोडच नाही तर या कोडच्या सभोवतालच्या लोकांचा आणि प्रक्रियांचा समावेश होतो. सॉफ्टवेअर डेव्हलपमेंटपासून इन्फ्रास्ट्रक्चर मॅनेजमेंट आणि वर्णनापर्यंतच्या पद्धतींचा पुनर्वापर करणे शक्य आहे का? आपण लेख वाचत असताना ही कल्पना मनात ठेवणे चांगले होईल.

हा माझा उतारा आहे कामगिरी वर DevopsConf 2019-05-28.

स्लाइड आणि व्हिडिओ

इंग्रजी आवृत्ती
रशियन आवृत्ती
ड्राय रन 2019-04-24 SpbLUG
DevopsConf 2019-05-28 कडून व्हिडिओ(RU).
DINS DevOps 2019-06-20 संध्याकाळी व्हिडिओ(RU)
स्लाइड

बॅश इतिहास म्हणून पायाभूत सुविधा

समजा तुम्ही एका नवीन प्रोजेक्टवर आलात आणि ते तुम्हाला सांगतात: “आमच्याकडे आहे संहिता म्हणून पायाभूत सुविधा" प्रत्यक्षात ते बाहेर वळते बॅश इतिहास म्हणून पायाभूत सुविधा किंवा उदाहरणार्थ बॅश इतिहास म्हणून दस्तऐवजीकरण. ही एक अतिशय वास्तविक परिस्थिती आहे, उदाहरणार्थ, डेनिस लिसेन्को यांनी भाषणात अशाच प्रकारचे वर्णन केले होते संपूर्ण पायाभूत सुविधा कशा बदलायच्या आणि शांतपणे झोपायला सुरुवात कशी करावी, त्यांनी बॅश इतिहासातून प्रकल्पासाठी सुसंगत पायाभूत सुविधा कशा मिळाल्या हे सांगितले.

काही इच्छेने, आपण असे म्हणू शकतो बॅश इतिहास म्हणून पायाभूत सुविधा हे कोडसारखे आहे:

पुनरुत्पादनक्षमता: तुम्ही बॅश हिस्ट्री घेऊ शकता, तिथून कमांड्स चालवू शकता आणि तुम्हाला कदाचित आउटपुट म्हणून कार्यरत कॉन्फिगरेशन मिळेल.
आवृत्ती तयार करणे: तुम्हाला माहिती आहे की आत कोण आले आणि त्यांनी काय केले, हे तथ्य नाही की हे तुम्हाला बाहेर पडताना कार्यरत कॉन्फिगरेशनकडे नेईल.
इतिहास: कोणी काय केले याची कथा. आपण सर्व्हर गमावल्यास केवळ आपण ते वापरू शकणार नाही.

मी काय करावे?

संहिता म्हणून पायाभूत सुविधा

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

कोरडे

स्टोरेज सिस्टम डेव्हलपमेंट प्रोजेक्टवर, एक सबटास्क होता वेळोवेळी SDS कॉन्फिगर करा: आम्ही एक नवीन प्रकाशन जारी करत आहोत - ते पुढील चाचणीसाठी आणले जाणे आवश्यक आहे. कार्य अत्यंत सोपे आहे:

येथे ssh द्वारे लॉग इन करा आणि कमांड कार्यान्वित करा.
तेथे फाइल कॉपी करा.
येथे कॉन्फिगरेशन दुरुस्त करा.
तेथे सेवा सुरू करा
...
लाभ!

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

असे दिसून आले की DRY (स्वतःची पुनरावृत्ती करू नका) सारखी प्रथा आहे. विद्यमान कोड पुन्हा वापरण्याची कल्पना आहे. हे सोपे वाटते, परंतु आम्ही लगेच याकडे आलो नाही. आमच्या बाबतीत, ही एक सामान्य कल्पना होती: स्क्रिप्ट्समधून कॉन्फिग्स वेगळे करणे. त्या. प्रतिष्ठापन स्वतंत्रपणे कसे उपयोजित केले जाते याचे व्यवसाय तर्क, स्वतंत्रपणे कॉन्फिग.

CFM साठी सॉलिड

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

एकल जबाबदारी तत्त्व

प्रत्येक वर्ग एकच कार्य करतो.

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

ओपन क्लोज्ड तत्व

खुले/बंद तत्त्व.

विस्तारासाठी उघडा: म्हणजे नवीन अस्तित्व प्रकार तयार करून एखाद्या घटकाचे वर्तन वाढवले जाऊ शकते.
बदलासाठी बंद: एखाद्या घटकाच्या वर्तनाचा विस्तार केल्यामुळे, त्या घटकांचा वापर करणाऱ्या कोडमध्ये कोणतेही बदल केले जाऊ नयेत.

सुरुवातीला, आम्ही व्हर्च्युअल मशीनवर चाचणी पायाभूत सुविधा तैनात केल्या, परंतु तैनातीचे व्यावसायिक तर्क लागू करण्यापासून वेगळे असल्यामुळे, आम्ही कोणत्याही समस्यांशिवाय बेअरमेटलमध्ये रोल आउट जोडले.

लिस्कोव्ह प्रतिस्थापन तत्त्व

बार्बरा लिस्कोव्हचे प्रतिस्थापन तत्त्व. प्रोग्राममधील ऑब्जेक्ट्स प्रोग्रामची योग्य अंमलबजावणी न बदलता त्यांच्या उपप्रकारांच्या उदाहरणांसह बदलण्यायोग्य असणे आवश्यक आहे

जर आपण अधिक व्यापकपणे पाहिले तर ते कोणत्याही विशिष्ट प्रकल्पाचे वैशिष्ट्य नाही जे तेथे लागू केले जाऊ शकते घन, हे सामान्यतः CFM बद्दल असते, उदाहरणार्थ, दुसऱ्या प्रोजेक्टवर विविध Java, ऍप्लिकेशन सर्व्हर, डेटाबेस, OS, इ. वर बॉक्स्ड Java ऍप्लिकेशन तैनात करणे आवश्यक आहे. हे उदाहरण वापरून, मी पुढील तत्त्वांचा विचार करेन घन

आमच्या बाबतीत, इन्फ्रास्ट्रक्चर टीममध्ये एक करार आहे की जर आम्ही imbjava किंवा oraclejava भूमिका स्थापित केली असेल, तर आमच्याकडे जावा बायनरी एक्झिक्युटेबल आहे. हे आवश्यक आहे कारण अपस्ट्रीम भूमिका या वर्तनावर अवलंबून असतात; त्याच वेळी, हे आम्हाला ऍप्लिकेशन डिप्लॉयमेंट लॉजिक न बदलता एक जावा अंमलबजावणी/आवृत्ती बदलण्याची परवानगी देते.

येथे समस्या अशी आहे की हे उत्तरदायी मध्ये लागू करणे अशक्य आहे, परिणामी संघामध्ये काही करार दिसून येतात.

इंटरफेस पृथक्करण तत्त्व

इंटरफेस वेगळे करण्याचे तत्व: “अनेक क्लायंट-विशिष्ट इंटरफेस एका सामान्य-उद्देश इंटरफेसपेक्षा चांगले असतात.

सुरुवातीला, आम्ही ऍप्लिकेशन डिप्लॉयमेंटची सर्व परिवर्तनशीलता एका उत्तरदायी प्लेबुकमध्ये ठेवण्याचा प्रयत्न केला, परंतु त्याचे समर्थन करणे कठीण होते आणि जेव्हा आमच्याकडे बाह्य इंटरफेस निर्दिष्ट केला जातो (क्लायंटला पोर्ट 443 अपेक्षित आहे), तेव्हा वैयक्तिकरित्या एक पायाभूत सुविधा एकत्र केली जाऊ शकते. विशिष्ट अंमलबजावणीसाठी विटा.

अवलंबित्व उलथापालथ तत्त्व

अवलंबित्व उलथापालथ तत्त्व. उच्च स्तरावरील मॉड्यूल खालच्या स्तरावरील मॉड्यूलवर अवलंबून नसावेत. दोन्ही प्रकारचे मॉड्यूल ॲब्स्ट्रॅक्शनवर अवलंबून असले पाहिजेत. ॲब्स्ट्रॅक्शन तपशीलांवर अवलंबून नसावेत. तपशील अमूर्ततेवर अवलंबून असणे आवश्यक आहे.

येथे उदाहरण अँटीपॅटर्नवर आधारित असेल.

एका ग्राहकाकडे खाजगी क्लाउड होता.
आम्ही क्लाउडमध्ये व्हर्च्युअल मशीन्सची ऑर्डर दिली.
परंतु क्लाउडच्या स्वरूपामुळे, ॲप्लिकेशन डिप्लॉयमेंट कोणत्या हायपरवाइजरवर VM चालू आहे त्याच्याशी जोडले गेले.

त्या. हाय-लेव्हल ऍप्लिकेशन डिप्लॉयमेंट लॉजिक हायपरवाइजरच्या खालच्या स्तरांवर अवलंबित्वांसह प्रवाहित होते आणि याचा अर्थ या तर्कशास्त्राचा पुनर्वापर करताना समस्या होत्या. असे करू नका.

संवाद

कोड म्हणून पायाभूत सुविधा केवळ कोडबद्दलच नाही, तर कोड आणि लोकांमधील संबंध, पायाभूत सुविधा विकासकांमधील परस्परसंवादाबद्दल देखील आहे.

बस घटक

चला असे गृहीत धरू की तुमच्या प्रोजेक्टवर वास्य आहे. वास्याला तुमच्या पायाभूत सुविधांबद्दल सर्व काही माहित आहे, वास्या अचानक गायब झाल्यास काय होईल? ही अगदी खरी परिस्थिती आहे, कारण त्याला बसने धडक दिली. कधी कधी असं होतं. जर असे घडले आणि कोड, त्याची रचना, ते कसे कार्य करते, दिसणे आणि संकेतशब्द याबद्दलचे ज्ञान कार्यसंघामध्ये वितरित केले गेले नाही, तर तुम्हाला अनेक अप्रिय परिस्थितींना सामोरे जावे लागू शकते. हे धोके कमी करण्यासाठी आणि कार्यसंघामध्ये ज्ञान वितरित करण्यासाठी, तुम्ही विविध पद्धती वापरू शकता

जोडी Devopsing

तसे नाही एक विनोद म्हणून, की प्रशासकांनी बिअर प्यायली, पासवर्ड बदलले आणि पेअर प्रोग्रामिंगचे ॲनालॉग. त्या. दोन अभियंते एका संगणकावर, एका कीबोर्डवर बसतात आणि तुमची पायाभूत सुविधा एकत्रितपणे सेट करणे सुरू करतात: सर्व्हर सेट करणे, उत्तरदायी भूमिका लिहिणे इ. हे छान वाटते, परंतु ते आमच्यासाठी कार्य करत नाही. परंतु या सरावाच्या विशेष प्रकरणांनी काम केले. एक नवीन कर्मचारी येतो, त्याचा गुरू त्याच्यासोबत प्रत्यक्ष काम करतो, काम करतो आणि ज्ञान हस्तांतरित करतो.

दुसरी विशेष बाब म्हणजे घटना कॉल. एखाद्या समस्येच्या वेळी, कर्तव्यावर असलेल्या आणि त्यात सहभागी झालेल्यांचा एक गट एकत्र येतो, एक नेता नियुक्त केला जातो, जो त्याची स्क्रीन सामायिक करतो आणि विचारांच्या ट्रेनला आवाज देतो. इतर सहभागी नेत्याच्या विचारांचे अनुसरण करतात, कन्सोलमधून युक्त्या शोधतात, त्यांनी लॉगमधील एक ओळ चुकली नाही हे तपासा आणि सिस्टमबद्दल नवीन गोष्टी जाणून घ्या. हा दृष्टिकोन जास्त वेळा काम करत नाही.

कोड पुनरावलोकन

व्यक्तिनिष्ठपणे, कोड पुनरावलोकन वापरून पायाभूत सुविधा आणि ते कसे कार्य करते याबद्दल ज्ञान प्रसारित करणे अधिक प्रभावी होते:

रेपॉजिटरीमधील कोडद्वारे पायाभूत सुविधांचे वर्णन केले जाते.
बदल वेगळ्या शाखेत होतात.
विलीनीकरण विनंती दरम्यान, तुम्ही पायाभूत सुविधांमधील बदलांचा डेल्टा पाहू शकता.

येथे ठळक गोष्ट अशी होती की समीक्षकांची निवड एका शेड्यूलनुसार केली गेली होती, म्हणजे. काही प्रमाणात संभाव्यतेसह तुम्ही पायाभूत सुविधांच्या नवीन तुकड्यात जाल.

कोड शैली

कालांतराने, पुनरावलोकनांदरम्यान भांडणे दिसू लागली, कारण... समीक्षकांची स्वतःची शैली होती आणि समीक्षकांच्या रोटेशनने त्यांना वेगवेगळ्या शैलींसह स्टॅक केले: 2 स्पेस किंवा 4, camelCase किंवा snake_case. त्याची लगेच अंमलबजावणी करणे शक्य नव्हते.

लिंटर वापरण्याची शिफारस करण्याची पहिली कल्पना होती, शेवटी, प्रत्येकजण अभियंता आहे, प्रत्येकजण हुशार आहे. परंतु भिन्न संपादक, OS, सोयीस्कर नाहीत
हे एका बॉटमध्ये विकसित झाले ज्याने प्रत्येक समस्याग्रस्त कमिटसाठी स्लॅक करण्यासाठी लिहिले आणि लिंटर आउटपुट संलग्न केले. परंतु बऱ्याच प्रकरणांमध्ये आणखी महत्त्वाच्या गोष्टी करायच्या होत्या आणि कोड अनिश्चित राहिला.

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

वेळ निघून जातो, आणि आम्ही या निष्कर्षापर्यंत पोहोचलो आहोत की विशिष्ट चाचण्या उत्तीर्ण न करणाऱ्यांना मास्टरमध्ये प्रवेश दिला जाऊ शकत नाही. व्होइला! आम्ही ग्रीन बिल्ड मास्टरचा शोध लावला, जो बर्याच काळापासून सॉफ्टवेअर डेव्हलपमेंटमध्ये प्रचलित आहे:

वेगळ्या शाखेत विकास सुरू आहे.
या धाग्यावर चाचण्या चालू आहेत.
चाचण्या अयशस्वी झाल्यास, कोड त्याला मास्टरमध्ये बनवणार नाही.

हा निर्णय घेणे खूप क्लेशदायक होते, कारण... खूप वाद झाला, पण ते फायद्याचे होते, कारण... पुनरावलोकनांना शैलीतील फरकांशिवाय विलीनीकरणासाठी विनंत्या प्राप्त होऊ लागल्या आणि कालांतराने समस्या क्षेत्रांची संख्या कमी होऊ लागली.

IaC चाचणी

शैली तपासणी व्यतिरिक्त, तुम्ही इतर गोष्टी वापरू शकता, उदाहरणार्थ, तुमची पायाभूत सुविधा प्रत्यक्षात तैनात करू शकते हे तपासण्यासाठी. किंवा पायाभूत सुविधांमधील बदलांमुळे पैशाचे नुकसान होणार नाही हे तपासा. याची गरज का असू शकते? प्रश्न जटिल आणि तात्विक आहे, पॉवरशेलवर एक ऑटो-स्केलर होता ज्याने सीमा परिस्थिती तपासली नाही => आवश्यकतेपेक्षा अधिक 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 अंतर्गत तुमच्या स्टॅकसाठी लिंटर सापडेल.

भाषा
साधन

बाश
शेलचेक

रुबी
रुबोकॉप

अजगर
पायलंट

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

IaC चाचणी: युनिट चाचण्या

आपण मागील उदाहरणावरून पाहिल्याप्रमाणे, लिंटर सर्वशक्तिमान नसतात आणि सर्व समस्या क्षेत्र दर्शवू शकत नाहीत. पुढे, सॉफ्टवेअर डेव्हलपमेंटमधील चाचणीशी साधर्म्य ठेवून, आम्ही युनिट चाचण्या आठवू शकतो. जे लगेच मनात येते ते shunit, जुनिट, rspec, pytest. पण उत्तरदायी, आचारी, सॉल्टस्टॅक आणि त्यांच्यासारख्या इतरांचे काय करायचे?

अगदी सुरुवातीला आम्ही याबद्दल बोललो घन आणि आपल्या पायाभूत सुविधांमध्ये लहान विटांचा समावेश असावा. त्यांची वेळ आली आहे.

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

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 साठी गिथबवरील प्रकल्पांमधील बदलांचे उदाहरण आहे:

IaC चाचणी फ्रेमवर्क

प्रश्न उद्भवतो: हे सर्व एकत्र कसे ठेवायचे आणि ते कसे सुरू करायचे? करू शकतो ते घ्या आणि ते स्वतः करा पुरेशा प्रमाणात अभियंते असल्यास. किंवा आपण तयार केलेले उपाय घेऊ शकता, जरी त्यापैकी बरेच नाहीत:

CFM
साधन

उत्तर द्या
रेणू

डोके
चाचणी किचन

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

2018-2019 साठी गिथबवरील प्रकल्पांमधील बदलांचे उदाहरण:

रेणू वि. टेस्टकिचेन

सुरुवातीला आम्ही टेस्टकिचेन वापरून पहा:

समांतर एक VM तयार करा.
उत्तरदायी भूमिका लागू करा.
तपासणी चालवा.

25-35 भूमिकांसाठी 40-70 मिनिटे काम केले, जे लांब होते.

पुढची पायरी म्हणजे जेनकिन्स/डॉकर/अँसिबल/मॉलिक्युलमध्ये संक्रमण. वैचारिकदृष्ट्या सर्व काही समान आहे

लिंट प्लेबुक.
भूमिकांची रांग लावा.
कंटेनर लाँच करा
उत्तरदायी भूमिका लागू करा.
टेस्टिनफ्रा चालवा.
अशक्तपणा तपासा.

40 भूमिकांसाठी लिंटिंग आणि डझनभर चाचण्यांना सुमारे 15 मिनिटे लागतील.

काय निवडायचे हे अनेक घटकांवर अवलंबून असते, जसे की वापरलेला स्टॅक, संघातील कौशल्य इ. येथे प्रत्येकजण युनिट चाचणी प्रश्न कसा बंद करायचा हे स्वतः ठरवतो

IaC चाचणी: एकत्रीकरण चाचणी

पायाभूत सुविधा चाचणी पिरॅमिडमधील पुढील पायरी एकीकरण चाचण्या असेल. ते युनिट चाचण्यांसारखेच आहेत:

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

साधारणपणे सांगायचे तर, आम्ही युनिट चाचण्यांप्रमाणे सिस्टमच्या वैयक्तिक घटकाचे कार्यप्रदर्शन तपासत नाही, आम्ही सर्व्हर संपूर्णपणे कसे कॉन्फिगर केले आहे ते तपासतो.

IaC चाचणी: एंड टू एंड टेस्ट

पिरॅमिडच्या शीर्षस्थानी आम्हाला एंड टू एंड चाचण्यांद्वारे स्वागत केले जाते. त्या. आम्ही वेगळ्या सर्व्हरची, वेगळ्या स्क्रिप्टची किंवा आमच्या पायाभूत सुविधांची वेगळी वीट तपासत नाही. आम्ही तपासतो की अनेक सर्व्हर एकत्र जोडलेले आहेत, आमची पायाभूत सुविधा आमच्या अपेक्षेप्रमाणे कार्य करते. दुर्दैवाने, मी कधीही तयार बॉक्स केलेले समाधान पाहिले नाही, कदाचित कारण... पायाभूत सुविधा बहुधा अद्वितीय आणि टेम्प्लेट करणे आणि चाचणीसाठी फ्रेमवर्क तयार करणे कठीण असते. परिणामी, प्रत्येकजण स्वतःचे उपाय तयार करतो. मागणी आहे, पण उत्तर नाही. म्हणून, मी तुम्हाला सांगेन की इतरांना योग्य विचारांकडे ढकलण्यासाठी किंवा नाक घासण्यासाठी काय आहे की प्रत्येक गोष्ट आपल्या आधी शोधली गेली होती.

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

ही योजना फ्रेमवर्कमध्ये येईपर्यंत बराच काळ काम करत होती संशोधन आम्ही हे ओपनशिफ्टमध्ये हस्तांतरित करण्याचा प्रयत्न केला नाही. कंटेनर तेच आहेत, परंतु लॉन्च वातावरण बदलले आहे (हॅलो ड्राय पुन्हा).

संशोधनाची कल्पना पुढे गेली आणि ओपनशिफ्टमध्ये त्यांना APB (अँसिबल प्लेबुक बंडल) सारखी गोष्ट सापडली, जी तुम्हाला कंटेनरमध्ये पायाभूत सुविधा कशी तैनात करायची याचे ज्ञान पॅक करण्यास अनुमती देते. त्या. पायाभूत सुविधा कशा तैनात करायच्या याविषयी ज्ञानाचा एक पुनरावृत्ती करण्यायोग्य, चाचणी करण्यायोग्य मुद्दा आहे.

आम्ही एक विषम पायाभूत सुविधांमध्ये पोहोचेपर्यंत हे सर्व चांगले वाटले: आम्हाला चाचण्यांसाठी विंडोजची आवश्यकता होती. परिणामी, जेनकिन्समध्ये काय, कुठे, कसे तैनात करायचे आणि चाचणीचे ज्ञान आहे.

निष्कर्ष

संहिता म्हणून पायाभूत सुविधा

रेपॉजिटरीमध्ये कोड.
मानवी संवाद.
पायाभूत सुविधांची चाचणी.

दुवे

स्त्रोत: www.habr.com

पायाभूत सुविधा कोडच्या 200 लाइन्सच्या चाचणीतून मी काय शिकलो

बॅश इतिहास म्हणून पायाभूत सुविधा

संहिता म्हणून पायाभूत सुविधा

कोरडे

CFM साठी सॉलिड

एकल जबाबदारी तत्त्व

ओपन क्लोज्ड तत्व

लिस्कोव्ह प्रतिस्थापन तत्त्व

इंटरफेस पृथक्करण तत्त्व

अवलंबित्व उलथापालथ तत्त्व

संवाद

बस घटक

जोडी Devopsing

कोड पुनरावलोकन

कोड शैली

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

IaC चाचणी

IaC चाचणी पिरॅमिड

IaC चाचणी: स्थिर विश्लेषण

बाश अवघड आहे

स्थिर विश्लेषण साधने

IaC चाचणी: युनिट चाचण्या

IaC चाचणी: युनिट चाचणी साधने

IaC चाचणी फ्रेमवर्क

रेणू वि. टेस्टकिचेन

IaC चाचणी: एकत्रीकरण चाचणी

IaC चाचणी: एंड टू एंड टेस्ट

निष्कर्ष

एक टिप्पणी जोडा Отменить ответ