कोड के रूप में इन्फ्रास्ट्रक्चर: पहला परिचय

हमारी कंपनी एक एसआरई टीम को शामिल करने की प्रक्रिया में है। मैं इस पूरी कहानी में विकास पक्ष से आया हूं। इस प्रक्रिया में, मेरे मन में ऐसे विचार और अंतर्दृष्टि आई जिन्हें मैं अन्य डेवलपर्स के साथ साझा करना चाहता हूं। इस प्रतिबिंब लेख में मैं इस बारे में बात करता हूं कि क्या हो रहा है, यह कैसे हो रहा है, और हर कोई इसके साथ कैसे रह सकता है।

हमारे आंतरिक कार्यक्रम में भाषणों के आधार पर लिखे गए लेखों की श्रृंखला जारी है देवफ़ोरम:

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

हमने विचारों को क्रियान्वित करते हुए एक एसआरई टीम बनाने का निर्णय लिया गूगल श्री. उन्होंने अपने स्वयं के डेवलपर्स में से प्रोग्रामर की भर्ती की और उन्हें कई महीनों तक प्रशिक्षण के लिए भेजा।

टीम के पास निम्नलिखित प्रशिक्षण कार्य थे:

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

हम इंफ्रास्ट्रक्चर की अवधारणा को कोड के रूप में पेश करते हैं

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

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

दोनों ही स्थितियों में, हम स्वयं को आश्रित बनने में फँसा हुआ पाते हैं:

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

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

इस प्रकार, कोड के रूप में इन्फ्रास्ट्रक्चर (Incfastructure as Code - IaC) कोड के रूप में संपूर्ण मौजूदा बुनियादी ढांचे का विवरण है, साथ ही इसके साथ काम करने और इससे वास्तविक बुनियादी ढांचे को लागू करने के लिए संबंधित उपकरण भी है।

हर चीज़ का कोड में अनुवाद क्यों करें?लोग मशीनें नहीं हैं. वे सब कुछ याद नहीं रख पाते. इंसान और मशीन की प्रतिक्रिया अलग-अलग होती है. स्वचालित कोई भी चीज़ मानव द्वारा की गई किसी भी चीज़ से संभावित रूप से तेज़ होती है। सबसे महत्वपूर्ण बात सत्य का एकल स्रोत है।

नए एसआरई इंजीनियर कहाँ से आते हैं?इसलिए, हमने नए एसआरई इंजीनियरों को नियुक्त करने का निर्णय लिया, लेकिन उन्हें कहां से लाएं? सही उत्तरों के साथ बुक करें (गूगल एसआरई बुक) हमें बताता है: डेवलपर्स से। आख़िरकार, वे कोड के साथ काम करते हैं, और आप आदर्श स्थिति प्राप्त करते हैं।

हमने अपनी कंपनी के बाहर कार्मिक बाज़ार में लंबे समय तक उनकी बहुत खोज की। लेकिन हमें यह स्वीकार करना होगा कि हमें कोई भी ऐसा व्यक्ति नहीं मिला जो हमारे अनुरोधों के अनुकूल हो। मुझे अपनों के बीच ही तलाश करनी थी.

कोड के रूप में समस्याएँ इन्फ्रास्ट्रक्चर

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

टेराफ़ॉर्मा से उदाहरण कोड।

Ansible से उदाहरण कोड।

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

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

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

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

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

2. ऐसे कोड के साथ दूसरी समस्या यह है कि अक्सर यह एक विषम वातावरण होता है. आमतौर पर आप C# के साथ बैठते हैं और काम करते हैं, यानी। एक भाषा, एक स्टैक, एक पारिस्थितिकी तंत्र के साथ। और यहां आपके पास प्रौद्योगिकियों की एक विशाल विविधता है।

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

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

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

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

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

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

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

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

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

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

परीक्षणों के बारे में क्या?

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

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

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

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

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

कोड के रूप में सर्वोत्तम अभ्यास इंफ्रास्ट्रक्चर

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

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

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

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

ये सब कहां हो रहा है और क्या करना है

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

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

1. इस क्षेत्र में विकास बहुत तेजी से हो रहा है. यहां DevOps के लिए अनुरोधों का शेड्यूल दिया गया है।

   
   
   विषय प्रचारित हो सकता है, लेकिन यह तथ्य कि क्षेत्र बढ़ रहा है, कुछ आशा जगाता है।

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

2. पारंपरिक विकास में विकसित तकनीकें और प्रथाएं हैं जिन्हें हम यहां सफलतापूर्वक लागू कर सकते हैं। हां, परीक्षण और एक विषम वातावरण, अपर्याप्त टूलींग के साथ बारीकियां हैं, लेकिन बड़ी संख्या में अभ्यास जमा हो गए हैं जो उपयोगी और सहायक हो सकते हैं।

   एक तुच्छ उदाहरण: जोड़ी प्रोग्रामिंग के माध्यम से सहयोग। इसका पता लगाने में बहुत मदद मिलती है। जब आपके पास कोई पड़ोसी हो जो कुछ समझने की कोशिश कर रहा हो, तो आप मिलकर बेहतर समझ पाएंगे।

   यह समझना कि रिफैक्टरिंग कैसे की जाती है, ऐसी स्थिति में भी इसे पूरा करने में मदद मिलती है। यानी आप एक बार में सब कुछ नहीं बदल सकते, लेकिन नाम बदल सकते हैं, फिर स्थान बदल सकते हैं, फिर आप कुछ हिस्से को हाइलाइट कर सकते हैं, ओह, लेकिन यहां पर्याप्त टिप्पणियां नहीं हैं।

निष्कर्ष

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

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

स्रोत: www.habr.com