कोड के रूप में अवसंरचना: पहला अधिग्रहण

हमारी कंपनी SRE टीम को ऑनबोर्ड करने की प्रक्रिया में है। मैं विकास की तरफ से इस पूरी कहानी में गया था। इस प्रक्रिया में, मेरे पास विचार और अंतर्दृष्टि थी जो मैं अन्य डेवलपर्स के साथ साझा करना चाहता हूं। इस ध्यान लेख में, मैं बात करता हूं कि क्या होता है, यह कैसे होता है, और बाकी सभी लोग इसके साथ कैसे रह सकते हैं।

हमारे आंतरिक DevForum घटना पर भाषणों पर आधारित लेखों की एक श्रृंखला की निरंतरता :

1. बॉक्स के बिना श्रोडिंगर बिल्ली: वितरित प्रणालियों में आम सहमति की समस्या।
2. इन्फ्रास्ट्रक्चर कोड के रूप में। (आप यहाँ हैं)
3. सी # मॉडल के लिए टाइपस्क्रिप्ट अनुबंध की पीढ़ी। (प्रगति पर है ...)
4. सर्वर एक-दूसरे से कैसे सहमत होते हैं: रेज़िस्टेंस कंसिस्टेंट एल्गोरिथम वितरित करता है।
5. इन्फ्रास्ट्रक्चर कोड के रूप में: कैसे XP के साथ समस्याओं को दूर करने के लिए।
...

हमने Google sre विचारों को लागू करने वाली SRE टीम बनाने का निर्णय लिया। हमने अपने स्वयं के डेवलपर्स से प्रोग्रामर की भर्ती की और उन्हें कई महीनों तक अध्ययन करने के लिए भेजा।

टीम को निम्नलिखित प्रशिक्षण कार्यों का सामना करना पड़ा:

• हमारे बुनियादी ढांचे का वर्णन करें, जो ज्यादातर कोड के रूप में Microsoft Azure में है (Terraform और वह सब जो आसपास है)।
• डेवलपर्स को बुनियादी ढांचे के साथ काम करने का तरीका सिखाएं।
• ड्यूटी के लिए डेवलपर्स तैयार करें।

कोड के रूप में इन्फ्रास्ट्रक्चर की अवधारणा का परिचय

दुनिया के सामान्य मॉडल (शास्त्रीय प्रशासन) में, बुनियादी ढांचे के बारे में ज्ञान दो स्थानों पर है:

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

दोनों ही मामलों में, हम फंसे हुए हैं, जो आश्रित हैं:

• या उस व्यक्ति से, जो नश्वर है, बीमारी का शिकार है, प्यार में पड़ रहा है, मिजाज बिगड़ता है और बस केला खारिज कर देता है;
• या एक शारीरिक रूप से काम करने वाली मशीन से जो भी गिरता है, चोरी करता है, अप्रत्याशितता और असुविधा को प्रस्तुत करता है।

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

इस प्रकार, एक कोड के रूप में अवसंरचना (कोड - IaC के रूप में उत्कृष्ठता) कोड के रूप में संपूर्ण उपलब्ध अवसंरचना का विवरण है, साथ ही साथ इसके साथ काम करने और इससे बुनियादी ढांचे को साकार करने के लिए संबंधित उपकरण।

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

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

Terraforma से नमूना कोड।



Ansible से नमूना कोड।



सज्जनों, लेकिन अगर सब कुछ इतना आसान था! हम वास्तविक दुनिया में आपके साथ हैं, और वह आपको आश्चर्यचकित करने, समस्याओं को प्रस्तुत करने के लिए हमेशा तैयार है। यहां उनके बिना नहीं।

1. पहली समस्या यह है कि ज्यादातर मामलों में IaC किसी तरह का डीएसएल है।

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

परेशानी यह है कि इसमें आसानी से हमारे लिए ऐसी परिचित चीजें नहीं हो सकती हैं:

• चर;
• स्थिति;
• कहीं भी, कोई टिप्पणी नहीं है, उदाहरण के लिए, जोसन में, डिफ़ॉल्ट रूप से वे प्रदान नहीं किए जाते हैं;
• समारोह;
• और मैं इस तरह की उच्च स्तरीय चीजों के बारे में बात नहीं कर रहा हूं जैसे कि कक्षाएं, विरासत और वह सब।

2. इस कोड के साथ दूसरी समस्या अक्सर एक विषम वातावरण है । आमतौर पर आप C # के साथ बैठते हैं और काम करते हैं, अर्थात एक भाषा, एक ढेर, एक पारिस्थितिकी तंत्र के साथ। और यहाँ आपके पास कई प्रकार की प्रौद्योगिकियाँ हैं।

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

एक कार्य के ढांचे के भीतर पारंपरिक विकास एक भाषा के साथ आता है। यहां हम बड़ी संख्या में भाषाओं के साथ काम करते हैं।

3. तीसरी समस्या है सत्तारूढ़ होना । हम संपादकों (सुश्री विज़ुअल स्टूडियो, जेटब्राइंस राइडर) को शांत करने के लिए उपयोग किए जाते हैं जो हमारे लिए सब कुछ करते हैं। और अगर हम सुस्त हैं, तो भी वे कहेंगे कि हम गलत हैं। यह सामान्य और प्राकृतिक लगता है।

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

लेखन के समय, vscode-terraform plugin को अभी तक संस्करण 0.12 का समर्थन करने के लिए जारी नहीं किया गया है, हालांकि यह पहले ही 3 महीने के लिए जारी किया गया है।

यह भूलने का समय है ...

1. डिबगिंग।
2. उपकरण को फिर से सक्रिय करना।
3. ऑटो पूरा करना।
4. संकलन त्रुटियों का पता लगाएं।

यह हास्यास्पद है, लेकिन यह विकास के समय को भी बढ़ाता है और त्रुटियों की संख्या को बढ़ाता है जो अनिवार्य रूप से होते हैं।

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

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

लेकिन परीक्षणों का क्या?

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



उनके पास अच्छे दस्तावेज हैं। मैंने हमेशा Microsoft को प्रलेखन और प्रशिक्षण के लिए अपने दृष्टिकोण के लिए पसंद किया है। लेकिन आपको यह समझने के लिए चाचा बॉब होने की आवश्यकता नहीं है कि यह एक आदर्श कोड नहीं है। नोट सत्यापन को दाईं ओर प्रदान किया गया है।

यूनिट टेस्ट के साथ समस्या यह है कि आप और मैं Json के आउटपुट की शुद्धता को सत्यापित कर सकते हैं। मैंने 5 मापदंडों को फेंक दिया, मुझे 2000 लाइनों के लिए Json फुटक्लॉथ दिया गया। मैं विश्लेषण कर सकता हूं कि यहां क्या होता है, परीक्षा परिणाम को मान्य करें ...

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

Microsoft स्वयं अपने मॉड्यूल लिखता है, उनका परीक्षण इस प्रकार करता है। बेशक, यह ओपन सोर्स है। मैं आपके बारे में जो कुछ भी बोलता हूं वह आकर मरम्मत कर सकता है। मैं एक हफ्ते में सब कुछ ठीक कर सकता हूं, वीएस-कोड प्लगइन्स खोल सकता हूं, टेराफॉर्म कर सकता हूं, राइडर प्लगइन बना सकता हूं। हो सकता है कि कुछ विश्लेषण करें, स्क्रू लेंटर लिखें, परीक्षण के लिए पुस्तकालय की प्रतिलिपि बनाएँ। मैं सब कुछ कर सकता हूं। लेकिन मुझे ऐसा नहीं करना है।

कोड के रूप में बेस्ट प्रैक्टिसेज इंफ्रास्ट्रक्चर

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



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

IaC अनुरोध के लिए: यहां आप बिटकॉइन या HashiConf की रिपोर्टों को आधिकारिक दस्तावेज़ीकरण और गीथूब पर कई मुद्दों से जानकारी एकत्र करने की कोशिश कर रहे हैं। आप इन मॉड्यूल को कैसे फैलाते हैं, उनके साथ क्या करना है? ऐसा लगता है कि यह एक वास्तविक समस्या है ... एक समुदाय है, सज्जनों, जहां आपको किसी भी प्रश्न के लिए गीथब पर 10 टिप्पणियां दी जाएंगी। लेकिन यह सटीक नहीं है।

दुर्भाग्य से, इस समय, विशेषज्ञ अभी दिखाई देने लगे हैं। जबकि उनमें से बहुत कम हैं। और समुदाय स्वयं ही प्राइमर्डिया के स्तर पर लटका हुआ है।

यह सब कहां जाता है और क्या करना है

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

व्यक्तिगत रूप से, मैंने कुछ चीजों पर ध्यान दिया:

1. इस क्षेत्र में विकास बहुत तेजी से हो रहा है। मैं DevOps के लिए अनुरोधों का शेड्यूल देता हूं।
   
   
   
   हो सकता है कि विषय प्रचार का हो, लेकिन यह तथ्य कि क्षेत्र बढ़ रहा है, हमें कुछ आशा देता है।
   
   अगर कुछ इतनी तेजी से बढ़ता है, तो स्मार्ट लोग निश्चित रूप से दिखाई देंगे जो कहेंगे कि यह कैसे करना है, और कैसे नहीं। लोकप्रियता में वृद्धि इस तथ्य की ओर ले जाती है कि शायद किसी के पास आखिरकार vscode के लिए jsonnet प्लगइन जोड़ने का समय होगा, जो हमें ctrl + shift + f के माध्यम से देखने के बजाय फ़ंक्शन के कार्यान्वयन के लिए आगे बढ़ने की अनुमति देगा। जब सब कुछ विकसित होता है, तो अधिक सामग्री दिखाई देती है। SRE के बारे में वही Google पुस्तक एक महान उदाहरण है।
2. पारंपरिक विकास में विकसित तकनीक और प्रथाएं हैं जिन्हें हम यहां सफलतापूर्वक लागू कर सकते हैं। हां, परीक्षण और एक विषम वातावरण, अपर्याप्त ट्यूनिंग के साथ बारीकियां हैं, लेकिन बड़ी संख्या में प्रथाओं को संचित किया गया है जो काम में आ सकते हैं और मदद कर सकते हैं।
   
   एक तुच्छ उदाहरण: जोड़ी प्रोग्रामिंग के माध्यम से सहयोग। यह पता लगाने में बहुत मदद करता है। जब आपके पास कोई पड़ोसी होगा जो कुछ समझने की कोशिश भी कर रहा है, तो साथ में आप बेहतर समझ पाएंगे।
   
   यह समझना कि रिफैक्टिंग कैसे की जाती है, ऐसी स्थिति में भी इसका उत्पादन करने में मदद करता है। यही है, आप एक बार में सब कुछ नहीं बदल सकते हैं, लेकिन नामकरण बदल सकते हैं, फिर स्थान बदल सकते हैं, फिर यह कुछ भाग को उजागर कर सकता है, ओह, लेकिन पर्याप्त टिप्पणियां नहीं हैं।

निष्कर्ष

इस तथ्य के बावजूद कि मेरा तर्क निराशावादी लग सकता है, मैं आशा और ईमानदारी के साथ आशा करता हूं कि हम (और आप) सफल होंगे।

इसके बाद लेख का दूसरा भाग आता है। इसमें, मैं इस बारे में बात करता हूं कि कैसे हमने सीखने की प्रक्रिया में सुधार करने और बुनियादी ढांचे के साथ काम करने के लिए चरम प्रोग्रामिंग प्रथाओं का उपयोग किया।