एक कोड के रूप में अवसंरचना, हम एक पैमाने पर जीतते हैं (किरिल वचिन्किन, TYME)

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

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

यह ठीक वैसा ही है जैसा कि DevOpsDays Moscow 2018 में Kirill Vetchinkin की रिपोर्ट के बारे में बताया गया है। रिपोर्ट: Ansible मॉड्यूल का पुन: उपयोग, Git में भंडारण, समीक्षा, पुनर्निर्माण, वित्तीय लाभ, 1-क्लिक क्षैतिज स्केलिंग।

कौन परवाह करता है, कृपया, बिल्ली के नीचे।

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

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

तदनुसार, इस पूरे चिड़ियाघर को पूर्ण DevOps के बिना प्रबंधित करना बहुत मुश्किल है। इसलिए, हमारी कंपनी ने विभिन्न DevOps प्रथाओं को लागू किया है। स्वाभाविक रूप से, हम kanban पर काम करते हैं, SCRUM पर, हम सब कुछ git में संग्रहीत करते हैं। करने के बाद, निरंतर एकीकरण है, परीक्षण चलाए जाते हैं। परीक्षक PyTest पर एंड-टू-एंड टेस्ट लिखते हैं जो हर रात शुरू होते हैं। यूनिट-टेस्ट प्रत्येक कमिट के बाद शुरू होता है। हम एक अलग बिल्ड और परिनियोजन प्रक्रिया का उपयोग करते हैं: असेंबल किया जाता है, फिर कई बार विभिन्न वातावरणों में तैनात किया जाता है। हम खिड़कियों पर थे। ऑक्टोपस की तैनाती का उपयोग करते हुए खिड़कियों पर तैनात। इस साल हम डॉटनेट कोर पर विकसित कर रहे हैं। इसलिए, अब हम लिनक्स सिस्टम पर सॉफ्टवेयर चलाने में सक्षम हैं। हम ऑक्टोपस को छोड़कर अंसिबल आ गए। आज हम इस भाग के बारे में बात करेंगे, जो एक नई प्रथा है जो हमने इस वर्ष विकसित की, कुछ ऐसा जो हमने पहले नहीं किया था। जब आपके पास परीक्षण होते हैं, जब आप जानते हैं कि आवेदन को अच्छी तरह से कैसे बनाया जाए, तो इसे कहीं पर तैनात करना ठीक है। लेकिन अगर आपके पास दो वातावरण अलग-अलग कॉन्फ़िगर किए गए हैं, तो आप अभी भी गिर जाएंगे, और उत्पादन पर गिर जाएंगे। इसलिए, विन्यास का प्रबंधन एक बहुत महत्वपूर्ण अभ्यास है। आज हम इसी पर बात करेंगे।

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

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

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

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

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

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

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

बस समस्या को स्वयं देखें: हमने सीखा कि कैसे सर्वर का उपयोग करके कॉन्फ़िगर किया जा सकता है और सब कुछ ठीक था। लेकिन, जैसा कि मैंने कहा, हमारे पास कई परियोजनाएं हैं। वे लगभग सभी समान हैं। इनमें से कुछ सिस्टम प्रत्येक प्रोजेक्ट (k8s, RabbitMQ, Vault, ELK, PostgreSQL, HAProxy) में शामिल हैं। प्रत्येक के लिए, हमने एक भूमिका लिखी। हम इसे बटन से रोल कर सकते हैं।

लेकिन हमारे पास कई परियोजनाएं हैं, और प्रत्येक में वे अनिवार्य रूप से ओवरलैप करते हैं। यानी ऐसे एक सेट में, दूसरे में ऐसा, तीसरे में ऐसा। हमें चौराहे अंक मिलते हैं जिसमें विभिन्न परियोजनाओं में समान भूमिकाएं होती हैं।

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

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

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

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

लेकिन यहां हम आंसर के साथ संयोजन में डॉकटर का उपयोग करते हैं। यही है, हम में से विशिष्ट बुनियादी ढाँचा, अन्सिबल में गैर-विशिष्ट है। और इसलिए, हम इस छोटे से डेल्टा को डॉकटर में, बाकी सब, मौलिक - अंसिबेल में साझा करने का प्रयास करते हैं।

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

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

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

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

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

जब हमने इस दृष्टिकोण को पेश किया, तो CI (टीमसिटी), जिसने एकीकरण सर्वर में परिवर्तन किए, 10. में से 8 बार गिर गया। किसी ने भी इस पर ध्यान नहीं दिया क्योंकि कोई प्रतिक्रिया नहीं थी। डेवलपर्स के लिए, इन प्रक्रियाओं को लंबे समय तक लागू किया गया है, लेकिन संदेश ओपीएस (सिस्टम एडमिनिस्ट्रेटर) तक नहीं पहुंचे। इसलिए, हमने कार्यालय में एक प्रमुख स्थान पर एक बड़े मॉनिटर के लिए इस परियोजना की विधानसभाओं के साथ एक डैशबोर्ड जोड़ा। इस पर, विभिन्न परियोजनाओं को हरे रंग में हाइलाइट किया गया है - इसका मतलब है कि सब कुछ उसके साथ क्रम में है। यदि लाल रंग में हाइलाइट किया गया है, तो इसका मतलब है कि उसके साथ सब कुछ खराब है। हम देखते हैं कि कुछ परीक्षण विफल रहे। प्रस्तुति में, दूसरे के बाईं ओर, ऊपर से हम परिनियोजन परिनियोजन का परिणाम देखते हैं . , , , . : - . . Slack , - - - .

Ok, , , - , . trunk based . Master — . Master CI (Teamcity) integration . CI , integration . release candidate. . . , end-to-end , staging . production. , staging .

. ? , PostgreSQL. 5 . , . 1-2 . . , PostgreSQL . PostgreSQL , staging, production 4 . , , . , . - .

git submodule Ansible . , . git submodule Ansible . inventories , . 30 . git submodule .

: , . , , , staging , . , , , , , , staging. — , , - .

6 . — 10 . . . , . - git submodule, . . , , , . , , .

.

-, , : , Ansible git , : “ , - ”. ? git . , . 100% . . .

, . . , RabbitMQ, ELK, . , ELK . , , ELK. ELK, , ELK .

, , , , . , , , , . , . .

. , , , , , , . git. , — git, , : , - . .

, , , code review. , , . , . , , , , , . , : . . . , - - .

, .

: , git submodule, . - , latest . inventories. — , . , , .. . — . .

: - Ansible ( A B, B C A, )? , ?

: . . , - IP , , , , . . , , , , , . , - , , , RabbitMQ RabbitMQ, . - , .

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