अपने नेटवर्क बुनियादी ढांचे का नियंत्रण कैसे लें। चौथा अध्याय। स्वचालन। टेम्पलेट्स

यह लेख "अपने नेटवर्क इन्फ्रास्ट्रक्चर पर नियंत्रण कैसे रखें" श्रृंखला में छठा है। श्रृंखला के सभी लेखों की सामग्री और लिंक पाए जा सकते हैं यहां.

कई विषयों को पीछे छोड़ते हुए, मैंने एक नया अध्याय शुरू करने का फैसला किया।

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

नेटवर्क के लिए DevOps

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

जब 5 साल से भी अधिक समय पहले, हमारे डेवलपर्स, नेटवर्कर्स हमारे पास इन प्रस्तावों के साथ आए, तो हमें खुशी नहीं हुई।

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

अन्य प्रश्न भी उठते हैं, उदाहरण के लिए, इंटरफ़ेस सॉफ़्टवेयर के संस्करण से संस्करण में थोड़ा बदल सकता है। यह अंततः आपकी स्क्रिप्ट को गलत "कॉन्फ़िगरेशन" बनाने का कारण बनेगा। मैं "रनिंग इन" के लिए उत्पादन का उपयोग नहीं करना चाहूंगा।

या, यह कैसे समझें कि कॉन्फ़िगरेशन कमांड सही तरीके से लागू किए गए थे और त्रुटि होने पर क्या करना है?

मैं यह नहीं कहना चाहता कि ये सभी मुद्दे अनसुलझे हैं। केवल "ए" कहने से शायद "बी" कहने का भी अर्थ हो जाता है, और यदि आप विकास में परिवर्तन नियंत्रण के लिए समान प्रक्रियाओं का उपयोग करना चाहते हैं, तो आपको उत्पादन के अलावा विकास और स्टेजिंग वातावरण की आवश्यकता है। तब यह दृष्टिकोण पूर्ण दिखता है। लेकिन इसकी कीमत कितनी होगी?

लेकिन एक स्थिति ऐसी होती है जब नुकसान व्यावहारिक रूप से समाप्त हो जाते हैं, और केवल फायदे ही रह जाते हैं। मैं डिज़ाइन कार्य के बारे में बात कर रहा हूँ।

परियोजना

पिछले दो वर्षों से मैं एक बड़े प्रदाता के लिए डेटा सेंटर बनाने की परियोजना में भाग ले रहा हूं। मैं इस परियोजना में F5 और पालो ऑल्टो के लिए जिम्मेदार हूं। सिस्को के दृष्टिकोण से, यह "तृतीय पक्ष उपकरण" है।

मेरे लिए व्यक्तिगत रूप से, इस परियोजना में दो अलग-अलग चरण हैं।

पहला चरण

पहले साल मैं बेहद व्यस्त था, मैंने रातें और सप्ताहांत काम किया। मैं अपना सिर नहीं उठा पा रहा था. प्रबंधन और ग्राहक का दबाव मजबूत और निरंतर था। निरंतर दिनचर्या में, मैं इस प्रक्रिया को अनुकूलित करने का प्रयास भी नहीं कर सका। यह न केवल उपकरणों के विन्यास के बारे में था, बल्कि डिज़ाइन दस्तावेज़ीकरण की तैयारी के बारे में भी था।

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

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

अब हम थोड़ा इधर-उधर देख सकते थे।
और यह दूसरे चरण की शुरुआत थी.

दूसरे चरण

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

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

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

इसलिए, YAML और Jinja2 का उपयोग करते समय, IP पते, BGP AS नंबर जैसे कॉन्फ़िगरेशन मापदंडों के साथ एक YAML फ़ाइल पूरी तरह से NIP की भूमिका को पूरा करती है, जबकि Jinja2 टेम्पलेट्स में डिज़ाइन के अनुरूप सिंटैक्स शामिल होता है, यानी यह मूल रूप से एक है एलएलडी का प्रतिबिंब.

YAML और Jinja2 को सीखने में दो दिन लगे। यह कैसे काम करता है यह समझने के लिए कुछ अच्छे उदाहरण पर्याप्त हैं। फिर हमारे डिज़ाइन से मेल खाने वाले सभी टेम्पलेट बनाने में लगभग दो सप्ताह लग गए: पालो ऑल्टो के लिए एक सप्ताह और F5 के लिए एक और सप्ताह। यह सब कॉर्पोरेट गीथैब पर पोस्ट किया गया था।

अब परिवर्तन प्रक्रिया इस प्रकार दिखी:

• YAML फ़ाइल बदल दी
• टेम्पलेट (Jinja2) का उपयोग करके एक कॉन्फ़िगरेशन फ़ाइल बनाई गई
• एक दूरस्थ रिपॉजिटरी में सहेजा गया
• निर्मित कॉन्फ़िगरेशन को उपकरण पर अपलोड करें
• मुझे एक त्रुटि दिखी
• YAML फ़ाइल या Jinja2 टेम्पलेट बदल दिया
• टेम्पलेट (Jinja2) का उपयोग करके एक कॉन्फ़िगरेशन फ़ाइल बनाई गई
• ...

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

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

देव और मंचन

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

संक्षेप करने के लिए

तो, मेरे पास अंतिम पंक्ति में क्या है?

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

यह सब इस तथ्य की ओर ले गया

• त्रुटि दर लगभग 0 तक गिर गई है
• 90 फीसदी दिनचर्या खत्म हो गई है
• कार्यान्वयन की गति में काफी वृद्धि हुई है

भुगतान, F5Y, ACY

मैंने कहा कि कुछ उदाहरण यह समझने के लिए पर्याप्त हैं कि यह कैसे काम करता है।
मेरे काम के दौरान जो बनाया गया था उसका एक संक्षिप्त (और निश्चित रूप से संशोधित) संस्करण यहां दिया गया है।

भुगतान = परिनियोजन Pआलो Aएलतक से Yएएमएल = यमल से पालो ऑल्टो
F5Y = परिनियोजन F5 से Yएएमएल = F5 से Yएएमएल (जल्द ही आ रहा है)
ACY = परिनियोजन ACमैं से Yएएमएल = F5 से Yएएमएल

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

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

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

इस प्रोजेक्ट के इंजीनियर बिल्कुल समान उद्देश्यों के लिए YAML के बजाय ACI को कॉन्फ़िगर करने के लिए एक्सेल का उपयोग करते हैं। बेशक, एक्सेल का उपयोग करने के फायदे हैं:

• एक फ़ाइल में आपका एनआईपी
• सुंदर संकेत जो ग्राहक को देखने में सुखद लगते हैं
• आप कुछ एक्सेल टूल का उपयोग कर सकते हैं

लेकिन एक खामी है, और मेरी राय में यह फायदे पर भारी पड़ती है। परिवर्तनों को नियंत्रित करना और टीम कार्य का समन्वय करना अधिक कठिन हो जाता है।

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

स्रोत: www.habr.com