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

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

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

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

वेब के लिए DevOps

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

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

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

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

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

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

लेकिन एक ऐसी स्थिति है जहां विपक्ष लगभग समतल हो जाता है, और केवल पेशेवरों का ही रहता है। मैं डिजाइन के काम के बारे में बात कर रहा हूं।

परियोजना

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

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

पहला चरण

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

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

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

अब थोड़ा घूम कर देखना संभव था।
और वह दूसरे चरण की शुरुआत थी।

दूसरा चरण

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

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

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

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

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

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

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

यह स्पष्ट है कि पहले संपादन में बहुत समय व्यतीत होता था, लेकिन एक या दो सप्ताह के बाद यह पहले से ही अधिक दुर्लभ था।

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

देव और मंचन

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

संक्षेप में देना

तो नीचे की पंक्ति में मेरे पास क्या है?

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

यह सब इस तथ्य को जन्म देता है

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

भुगतान, F5Y, ACY

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

PAY = परिनियोजन P alo A lto from Y aml = येलो से Palo Alto
F5Y = Y aml से F5 की तैनाती Y Yl से F5 = (जल्द ही आ रहा है)
ACY = Y aml से F से AC i पर तैनाती = Y aml से F5

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

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

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

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

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

लेकिन एक कमी है, और मेरी राय में यह पेशेवरों से आगे निकल जाता है। परिवर्तन को नियंत्रित करना और टीम के काम में समन्वय करना और अधिक कठिन हो जाता है।

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