तपाईंको नेटवर्क पूर्वाधारको नियन्त्रण कसरी लिने। अध्याय चार। स्वचालन। टेम्प्लेटहरू

यो लेख "तपाईंको नेटवर्क पूर्वाधारको नियन्त्रण कसरी लिने" श्रृंखलाको छैटौं हो। श्रृंखला र लिङ्कहरूमा सबै लेखहरूको सामग्रीहरू फेला पार्न सकिन्छ यहाँ.

धेरै विषयहरू पछाडि छोडेर, मैले नयाँ अध्याय सुरु गर्ने निर्णय गरें।

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

नेटवर्कको लागि DevOps

स्क्रिप्टको साथ कन्फिगरेसन सिर्जना गर्दै, IT पूर्वाधारमा परिवर्तनहरू नियन्त्रण गर्न GIT प्रयोग गर्दै, रिमोट "अपलोडिङ" - यी विचारहरू पहिले आउँछन् जब तपाइँ DevOps दृष्टिकोणको प्राविधिक कार्यान्वयनको बारेमा सोच्नुहुन्छ। फाइदाहरू स्पष्ट छन्। तर, दुर्भाग्यवश, त्यहाँ पनि हानिहरू छन्।

जब 5 वर्ष भन्दा बढी अघि, हाम्रा विकासकर्ताहरू, नेटवर्करहरू, यी प्रस्तावहरूको साथ हामीकहाँ आए, हामी खुसी थिएनौं।

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

अन्य प्रश्नहरू पनि उठ्छन्, उदाहरणका लागि, इन्टरफेस सफ्टवेयरको संस्करणबाट संस्करणमा थोरै परिवर्तन हुन सक्छ। यसले अन्ततः तपाइँको स्क्रिप्टलाई गलत "कन्फिग" सिर्जना गर्ने कारण बनाउँछ। म "रनिङ इन" को लागि उत्पादन प्रयोग गर्न चाहन्न।

वा, कसरी बुझ्ने कि कन्फिगरेसन आदेशहरू सही रूपमा लागू गरिएको थियो र त्रुटिको अवस्थामा के गर्ने?

म भन्न चाहन्न कि यी सबै मुद्दाहरू समाधान गर्न नसकिने छन्। केवल "A" भन्नुले "B" पनि भन्नुको अर्थ हो, र यदि तपाइँ विकासमा जस्तै परिवर्तन नियन्त्रणका लागि समान प्रक्रियाहरू प्रयोग गर्न चाहनुहुन्छ भने, तपाइँसँग उत्पादनको अतिरिक्त dev र स्टेजिङ वातावरणहरू हुनु आवश्यक छ। त्यसपछि यो दृष्टिकोण पूर्ण देखिन्छ। तर कति खर्च लाग्ने ?

तर त्यहाँ एक अवस्था छ जब बेफाइदाहरू व्यावहारिक रूपमा स्तरबद्ध हुन्छन्, र केवल फाइदाहरू रहन्छन्। म डिजाइनको कामको कुरा गर्दैछु।

परियोजना

विगत दुई वर्षदेखि म एक ठूलो प्रदायकको लागि डाटा सेन्टर निर्माण गर्ने परियोजनामा ​​भाग लिइरहेको छु। म यस परियोजनामा ​​F5 र Palo Alto को लागि जिम्मेवार छु। सिस्कोको दृष्टिकोणबाट, यो "3rd पार्टी उपकरण" हो।

मेरो लागि व्यक्तिगत रूपमा, यस परियोजनामा ​​दुई फरक चरणहरू छन्।

एक चरण

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

पहिलो परीक्षणहरू सुरु भइसकेका छन्, र म कति साना त्रुटिहरू र अशुद्धताहरू बनाइयो भनेर छक्क पर्नेछु। निस्सन्देह, सबै कुराले काम गर्यो, तर नाममा एउटा हराइरहेको अक्षर थियो, कमाण्डमा एउटा हराइरहेको रेखा थियो... परीक्षणहरू चलिरहेकै थिए, र म पहिलेदेखि नै त्रुटिहरू, परीक्षणहरू र कागजातहरूसँग निरन्तर संघर्षमा थिएँ। ।

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

अब हामी अलिकति वरिपरि हेर्न सक्छौं।
र यो दोस्रो चरणको सुरुवात थियो।

दुई चरण

मैले प्रक्रिया स्वचालित गर्ने निर्णय गरें।

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

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

त्यसोभए, YAML र Jinja2 प्रयोग गर्दा, IP ठेगानाहरू, BGP AS नम्बरहरू, ... जस्ता कन्फिगरेसन प्यारामिटरहरू सहितको YAML फाइलले NIP को भूमिका पूर्ण रूपमा पूरा गर्दछ, जबकि Jinja2 टेम्प्लेटहरूले डिजाइनसँग सम्बन्धित वाक्य रचना समावेश गर्दछ, अर्थात्, यो अनिवार्य रूपमा एक हो। LLD को प्रतिबिम्ब।

YAML र Jinja2 सिक्न दुई दिन लाग्यो। यो कसरी काम गर्छ भनेर बुझ्न केही राम्रा उदाहरणहरू पर्याप्त छन्। त्यसपछि हाम्रो डिजाइनसँग मेल खाने सबै टेम्प्लेटहरू सिर्जना गर्न लगभग दुई हप्ता लाग्यो: पालो अल्टोको लागि एक हप्ता र F5 को लागि अर्को हप्ता। यो सबै कर्पोरेट githab मा पोस्ट गरिएको थियो।

अब परिवर्तन प्रक्रिया यस्तो देखिन्थ्यो:

• YAML फाइल परिवर्तन गर्नुभयो
• टेम्प्लेट प्रयोग गरेर कन्फिगरेसन फाइल सिर्जना गरियो (Jinja2)
• रिमोट रिपोजिटरीमा सुरक्षित
• उपकरणमा सिर्जना गरिएको कन्फिगरेसन अपलोड गरियो
• मैले एउटा त्रुटि देखेँ
• YAML फाइल वा Jinja2 टेम्प्लेट परिवर्तन गरियो
• टेम्प्लेट प्रयोग गरेर कन्फिगरेसन फाइल सिर्जना गरियो (Jinja2)
• ...

यो स्पष्ट छ कि सुरुमा धेरै समय सम्पादनमा खर्च गरिएको थियो, तर एक वा दुई हप्ता पछि यो एक दुर्लभता भयो।

एक राम्रो परीक्षण र सबै कुरा डिबग गर्ने अवसर नामकरण कन्भेन्सन परिवर्तन गर्ने ग्राहकको इच्छा थियो। F5 मा काम गर्नेहरूले स्थितिको चरमता बुझ्दछन्। तर मेरो लागि यो सबै एकदम सरल थियो। मैले YAML फाइलमा नामहरू परिवर्तन गरें, उपकरणबाट सम्पूर्ण कन्फिगरेसन मेटाए, नयाँ उत्पन्न गरे र यसलाई अपलोड गरें। सबै कुरा, बग समाधान सहित, 4 दिन लाग्यो: प्रत्येक प्रविधिको लागि दुई दिन। त्यस पछि, म अर्को चरणको लागि तयार थिएँ, अर्थात् DEV र स्टेजिङ डेटा केन्द्रहरूको सिर्जना।

देव र स्टेजिङ

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

संक्षेप गरौं

त्यसोभए, मसँग तल्लो रेखामा के छ?

• कन्फिगरेसन परिवर्तन गर्न मैले गर्नुपर्ने भनेको कन्फिगरेसन प्यारामिटरहरूको साथ एक साधारण, स्पष्ट रूपमा संरचित YAML फाइल परिवर्तन गर्नु हो। म पाइथन स्क्रिप्ट कहिल्यै परिवर्तन गर्दिन र धेरै विरलै (यदि त्यहाँ त्रुटि छ भने) म Jinja2 heatlate परिवर्तन गर्छु
• दस्तावेजीकरण दृष्टिकोणबाट, यो लगभग एक आदर्श स्थिति हो। तपाइँ कागजात परिवर्तन गर्नुहुन्छ (YAML फाइलहरू NIP को रूपमा सेवा गर्दछ) र उपकरणमा यो कन्फिगरेसन अपलोड गर्नुहोस्। यस तरिकाले तपाईंको कागजातहरू सधैं अद्यावधिक हुन्छ

यी सबैले यो तथ्यलाई निम्त्यायो

• त्रुटि दर लगभग ० मा झरेको छ
• ९० प्रतिशत दिनचर्या सकिएको छ
• कार्यान्वयनको गति निकै बढेको छ

भुक्तानी, F5Y, ACY

मैले भने कि यसले कसरी काम गर्छ भनेर बुझ्न केही उदाहरणहरू पर्याप्त छन्।
यहाँ मेरो कामको क्रममा सिर्जना गरिएको छोटो (र निश्चित रूपमा परिमार्जित) संस्करण हो।

PAY = तैनाती Pआलो Aबाट Yaml = Yaml बाट Palo Alto
F5Y = तैनाती F5 बाट Yaml = F5 बाट Yaml (चाँडै आउँदैछ)
ACY = तैनाती ACम बाट Yaml = F5 बाट Yaml

म ACY को बारेमा केहि शब्दहरू थप्नेछु (ACI संग भ्रमित नहुनु)।

ACI सँग काम गर्नेहरूलाई थाहा छ कि यो चमत्कार (र राम्रो तरिकामा पनि) पक्कै पनि नेटवर्करहरू द्वारा सिर्जना गरिएको थिएन :)। तपाईंले नेटवर्कको बारेमा जान्नुभएको सबै कुरा बिर्सनुहोस् - यो तपाईंको लागि उपयोगी हुनेछैन!
यो थोरै बढाइचढाइ हो, तर यसले लगभग 3 वर्षदेखि ACI सँग काम गर्दा मैले निरन्तर अनुभव गरिरहेको भावनालाई व्यक्त गर्दछ।

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

यस परियोजनाका इन्जिनियरहरूले ठ्याक्कै उही उद्देश्यका लागि YAML को सट्टा ACI कन्फिगर गर्न Excel प्रयोग गर्छन्। त्यहाँ, निस्सन्देह, एक्सेल प्रयोग गर्ने फाइदाहरू छन्:

• तपाईंको NIP एउटा फाइलमा
• सुन्दर संकेतहरू जुन ग्राहकलाई हेर्नको लागि रमाइलो हुन्छ
• तपाइँ केहि एक्सेल उपकरणहरू प्रयोग गर्न सक्नुहुन्छ

तर त्यहाँ एक माइनस छ, र मेरो विचारमा यो पेशेवरहरू भन्दा बढी छ। परिवर्तनहरू नियन्त्रण गर्न र टोली कार्य समन्वय गर्न धेरै गाह्रो हुन्छ।

ACY वास्तवमा उही दृष्टिकोणको एउटा अनुप्रयोग हो जुन मैले तेस्रो पक्षको लागि ACI कन्फिगर गर्न प्रयोग गरेको थिएँ।

स्रोत: www.habr.com