कोडको रूपमा पूर्वाधार: पहिलो परिचित

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

हाम्रो आन्तरिक कार्यक्रममा भाषणहरूमा आधारित लेखहरूको श्रृंखलाको निरन्तरता DevForum:

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

हामीले एसआरई टोली बनाउने निर्णय गर्‍यौं, विचारहरू कार्यान्वयन गर्दै गुगल sre। तिनीहरूले आफ्नै विकासकर्ताहरू मध्येबाट प्रोग्रामरहरू भर्ती गरे र तिनीहरूलाई धेरै महिनाको लागि तालिमको लागि पठाए।

टोलीसँग निम्न प्रशिक्षण कार्यहरू थिए:

• हाम्रो पूर्वाधारको वर्णन गर्नुहोस्, जुन प्राय: Microsoft Azure मा कोडको रूपमा छ (टेराफार्म र वरपरका सबै कुरा)।
• विकासकर्ताहरूलाई पूर्वाधारसँग कसरी काम गर्ने भनेर सिकाउनुहोस्।
• कर्तव्यको लागि विकासकर्ताहरू तयार गर्नुहोस्।

हामीले पूर्वाधारको अवधारणालाई कोडको रूपमा प्रस्तुत गर्छौं

संसारको सामान्य मोडेलमा (शास्त्रीय प्रशासन), पूर्वाधारको बारेमा ज्ञान दुई ठाउँमा अवस्थित छ:

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

दुबै अवस्थामा, हामी आफैंलाई निर्भर बन्नमा फसेका छौं:

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

यो भनाइ बिना जान्छ कि आदर्श रूपमा सबै कुरा मानव-पठनीय, रखरखाव योग्य, राम्रोसँग लिखित कोडमा अनुवाद हुनुपर्छ।

तसर्थ, कोडको रूपमा पूर्वाधार (संहिताको रूपमा इन्फ्रास्ट्रक्चर - IaC) कोडको रूपमा सम्पूर्ण अवस्थित पूर्वाधारहरूको विवरण हो, साथै यससँग काम गर्न र यसबाट वास्तविक पूर्वाधार कार्यान्वयन गर्न सम्बन्धित उपकरणहरू।

किन सबै कुरा कोडमा अनुवाद गर्ने?मान्छे मेसिन होइनन् । तिनीहरू सबै याद गर्न सक्दैनन्। मान्छे र मेसिनको प्रतिक्रिया फरक हुन्छ। कुनै पनि स्वचालित काम मानव द्वारा गरेको कुनै पनि कुरा भन्दा सम्भावित रूपमा छिटो हुन्छ। सबैभन्दा महत्त्वपूर्ण कुरा सत्यको एउटै स्रोत हो।

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

हामीले हाम्रो कम्पनी बाहिर कर्मचारी बजारमा उनीहरूको लागि लामो समयको लागि धेरै खोज्यौं। तर हामीले स्वीकार गर्नैपर्छ कि हामीले हाम्रो अनुरोधहरू मिल्ने कसैलाई भेट्टाएनौं। आफ्नै मान्छेहरु माझ खोज्नु पर्यो ।

कोडको रूपमा पूर्वाधारमा समस्याहरू

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

Terraforma बाट उदाहरण कोड।

Ansible बाट उदाहरण कोड।

सज्जनहरू, यदि यो यति सरल भएको भए! हामी वास्तविक संसारमा छौं, र यो सँधै तपाईलाई आश्चर्यचकित गर्न, तपाईलाई आश्चर्य र समस्याहरू प्रस्तुत गर्न तयार छ। तिनीहरू बिना यहाँ पनि गर्न सक्दैन।

1. पहिलो समस्या यो हो कि धेरै जसो केसहरूमा IaC कुनै प्रकारको dsl हो।

र DSL, बारीमा, संरचनाको विवरण हो। थप स्पष्ट रूपमा, तपाईंसँग के हुनुपर्छ: Json, Yaml, केही ठूला कम्पनीहरूबाट परिमार्जनहरू जुन तिनीहरूको आफ्नै dsl (HCL टेराफर्ममा प्रयोग गरिन्छ)।

समस्या यो हो कि यसले सजिलैसँग यस्ता परिचित चीजहरू समावेश नगर्न सक्छ:

• चर;
• सर्तहरू;
• कतै त्यहाँ कुनै टिप्पणीहरू छैनन्, उदाहरणका लागि, Json मा, पूर्वनिर्धारित रूपमा तिनीहरू प्रदान गरिएका छैनन्;
• कार्यहरू;
• र म वर्ग, विरासत र ती सबै जस्ता उच्च-स्तरका चीजहरूको बारेमा पनि कुरा गरिरहेको छैन।

2. यस्तो कोडको साथ दोस्रो समस्या यो हो कि प्राय: यो एक विषम वातावरण हो। सामान्यतया तपाईं C# सँग बसेर काम गर्नुहुन्छ, अर्थात्। एउटा भाषा, एउटा स्ट्याक, एउटा इकोसिस्टमको साथ। र यहाँ तपाईंसँग प्रविधिहरूको एक विशाल विविधता छ।

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

एउटै कार्यको ढाँचाभित्रको परम्परागत विकास एउटै भाषामा हुन्छ। यहाँ हामी धेरै भाषाहरूसँग काम गर्छौं।

3. तेस्रो समस्या ट्युनिङ हो। हामी हाम्रा लागि सबै कुरा गर्ने सम्पादकहरू (सुश्री भिजुअल स्टुडियो, जेटब्रेन्स राइडर) शीतल गर्न प्रयोग गरिन्छ। र यदि हामी मूर्ख छौँ भने पनि, तिनीहरूले हामी गलत छौँ भन्नेछन्। यो सामान्य र प्राकृतिक देखिन्छ।

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

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

यो बिर्सने समय हो ...

1. डिबगि।
2. Refactoring उपकरण।
3. स्वत: पूरा।
4. संकलनको क्रममा त्रुटिहरू पत्ता लगाउँदै।

यो हास्यास्पद छ, तर यसले विकास समय पनि बढाउँछ र अनिवार्य रूपमा हुने त्रुटिहरूको संख्या बढाउँछ।

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

एक शुरुवातको रूपमा, तपाईं टेराफार्महरू सिक्न प्रयास गर्दै हुनुहुन्छ, र IDE ले तपाईंलाई कुनै पनि मद्दत गरिरहेको छैन। जब त्यहाँ कागजात छ, भित्र जानुहोस् र हेर्नुहोस्। तर यदि तपाइँ नयाँ प्रोग्रामिङ भाषा प्रविष्ट गर्दै हुनुहुन्छ भने, IDE ले तपाइँलाई बताउनेछ कि त्यहाँ यस्तो प्रकार छ, तर त्यहाँ त्यस्तो केहि छैन। कम्तिमा int वा स्ट्रिङ स्तरमा। यो अक्सर उपयोगी छ।

परीक्षणहरूको बारेमा के हो?

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

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

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

Go मा Json लाई पार्स गर्न गाह्रो छ। र तपाईंले Go मा लेख्नु आवश्यक छ, किनकि तपाईंले लेख्नु भएको भाषामा परीक्षणको लागि गोमा टेराफर्म राम्रो अभ्यास हो। संहिताको संगठन आफैमा धेरै कमजोर छ। एकै समयमा, यो परीक्षणको लागि उत्तम पुस्तकालय हो।

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

कोडको रूपमा उत्तम अभ्यासहरू पूर्वाधार

अगाडि बढौं। यदि IaC मा कुनै परीक्षणहरू छैनन् भने, IDE र ट्युनिङ खराब छन्, त्यसपछि त्यहाँ कम्तिमा उत्कृष्ट अभ्यासहरू हुनुपर्छ। म भर्खरै गुगल एनालिटिक्समा गएँ र दुई खोज प्रश्नहरूको तुलना गरें: टेराफॉर्म उत्तम अभ्यासहरू र c# उत्तम अभ्यासहरू।

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

IaC अनुरोधको लागि: यहाँ तपाइँ हाइलोड वा HashiConf रिपोर्टहरू, आधिकारिक कागजातहरू र Github मा असंख्य मुद्दाहरूबाट बिट द्वारा जानकारी सङ्कलन गर्ने प्रयास गर्दै हुनुहुन्छ। यी मोड्युलहरूलाई सामान्य रूपमा कसरी वितरण गर्ने, तिनीहरूलाई के गर्ने? यस्तो देखिन्छ कि यो एक वास्तविक समस्या हो ... त्यहाँ एक समुदाय छ, सज्जनहरू, जहाँ कुनै प्रश्नको लागि तपाईंलाई Github मा 10 टिप्पणी दिइनेछ। तर यो ठ्याक्कै होइन।

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

यो सब कहाँ जान्छ र के गर्ने

तपाईं सबै कुरा छोड्न सक्नुहुन्छ र C# मा फिर्ता जान सक्नुहुन्छ, राइडरको संसारमा। तर होइन। समाधान खोज्न नसकेमा किन यसो गरिरहने हो। तल म मेरो व्यक्तिपरक निष्कर्ष प्रस्तुत गर्दछु। तपाईं टिप्पणीहरूमा मसँग बहस गर्न सक्नुहुन्छ, यो रोचक हुनेछ।

व्यक्तिगत रूपमा, म केहि चीजहरूमा शर्त गर्दैछु:

1. यस क्षेत्रमा विकास धेरै छिटो भइरहेको छ। यहाँ DevOps को लागि अनुरोधहरूको तालिका छ।

   
   
   विषय हाइप हुन सक्छ, तर क्षेत्र बढ्दै गएको तथ्यले केही आशा दिन्छ।

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

2. त्यहाँ परम्परागत विकासमा विकसित प्रविधिहरू र अभ्यासहरू छन् जुन हामी यहाँ सफलतापूर्वक लागू गर्न सक्छौं। हो, त्यहाँ परीक्षण र एक विषम वातावरण, अपर्याप्त टूलिङ्ग, तर उपयोगी र उपयोगी हुन सक्ने अभ्यासहरूको एक ठूलो संख्या जम्मा भएको छ।

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

   रिफ्याक्टरिङ कसरी गरिन्छ भन्ने बुझ्दा यस्तो अवस्थामा पनि यसलाई पूरा गर्न मद्दत गर्छ। त्यो हो, तपाइँ एकैचोटि सबै कुरा परिवर्तन गर्न सक्नुहुन्न, तर नामकरण परिवर्तन गर्नुहोस्, त्यसपछि स्थान परिवर्तन गर्नुहोस्, त्यसपछि तपाइँ केहि भाग हाइलाइट गर्न सक्नुहुन्छ, ओह, तर यहाँ पर्याप्त टिप्पणीहरू छैनन्।

निष्कर्षमा

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

अर्को लेखको दोस्रो भाग तयार हुँदैछ। यसमा, म कसरी हाम्रो सिक्ने प्रक्रिया सुधार गर्न र पूर्वाधारको साथ काम गर्न फुर्तिलो विकास अभ्यासहरू प्रयोग गर्ने प्रयास गर्यौं भन्ने कुरा गर्नेछु।

स्रोत: www.habr.com