द इनसाइड प्लेबुक। नए अंसिबल इंजन 2.9 में नेटवर्क सुविधाएँ

Red Hat Ansible Engine 2.9 की आगामी रिलीज प्रभावशाली सुधार के साथ आपकी प्रतीक्षा कर रही है, जिनमें से कुछ इस लेख में वर्णित हैं। हमेशा की तरह, हमने समुदाय समर्थन के साथ खुले तौर पर Ansible Network सुधार विकसित किया। ज्वाइन करें - गिटहब पर टास्क बोर्ड पर एक नजर डालें और रेडी हैटसबल इंजन 2.9 की रिलीजिंग के लिए विकास योजना का अध्ययन करें।

जैसा कि हमने हाल ही में घोषणा की, Red Hat Ansible स्वचालन प्लेटफॉर्म में अब Ansible Tower, Ansible Engine और सभी Ansible नेटवर्क सामग्री शामिल हैं। अब, अधिकांश लोकप्रिय नेटवर्क प्लेटफ़ॉर्म को Ansible मॉड्यूल के माध्यम से कार्यान्वित किया जाता है। उदाहरण के लिए:

• अरिस्ता eos
• सिस्को IOS
• सिस्को IOS XR
• सिस्को एनएक्स-ओएस
• जुनिपर जूनो
• VyOS

प्लेटफ़ॉर्म की एक पूरी सूची जो पूरी तरह से रेड हैट द्वारा ऐन्सिबल ऑटोमेशन के माध्यम से समर्थित है, यहां उपलब्ध है ।

हमने क्या सीखा है

पिछले चार वर्षों में, हमने नेटवर्क स्वचालन के लिए एक मंच विकसित करने के बारे में बहुत कुछ सीखा है। हमने यह भी सीखा कि अंत-उपयोगकर्ता प्लेटफ़ॉर्म की कलाकृतियों को एन्सिबल प्लेबुक और भूमिकाओं में कैसे खेलते हैं। और यहाँ हमें पता चला है:

• संगठन न केवल एक, बल्कि कई विक्रेताओं को उपकरणों को स्वचालित करते हैं।
• स्वचालन न केवल एक तकनीकी घटना है, बल्कि एक सांस्कृतिक भी है।
• ऑटोमेशन डिज़ाइन के मूलभूत वास्तु सिद्धांतों के कारण, नेटवर्क के बड़े पैमाने पर स्वचालन अधिक जटिल है।

जब हमने एक साल पहले हमारी दीर्घकालिक विकास योजनाओं पर चर्चा की, तो हमारे कॉर्पोरेट ग्राहकों ने निम्नलिखित अनुरोध किया:

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

तथ्य वृद्धि

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

आपने देखा होगा कि हमने किस तरह से Ansible Network Engine भूमिका पर काम किया है। स्वाभाविक रूप से, 24,000 डाउनलोड के बाद, नेटवर्क स्वचालन की भूमिका नेटवर्क स्वचालन परिदृश्यों के लिए Ansible Galaxy में Ansible की सबसे लोकप्रिय भूमिकाओं में से एक बन गई। इससे पहले कि हम Ansible 2.8 की तैयारी के लिए इस से अधिक से अधिक Ansible 2.8 में चले गए, इस Ansible भूमिका ने कमांड पार्सिंग, कमांड प्रबंधन और नेटवर्क उपकरणों के लिए डेटा संग्रह में सहायता करने के लिए उपकरणों का पहला सेट प्रदान किया।

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

संक्षेप में, बड़े पैमाने पर स्वचालन के लिए उपकरणों से तथ्यों को प्राप्त करना और उन्हें कुंजी-मूल्य जोड़े में सामान्य करना बहुत महत्वपूर्ण है, लेकिन जब आपके पास कई विक्रेता और नेटवर्क प्लेटफ़ॉर्म हैं, तो यह हासिल करना मुश्किल है।

Ansible 2.9 में प्रत्येक नेटवर्क फैक्ट मॉड्यूल अब एक नेटवर्क डिवाइस के कॉन्फ़िगरेशन का विश्लेषण कर सकता है और संरचित डेटा को लौटा सकता है - अतिरिक्त पुस्तकालयों, Ansible भूमिकाओं या कस्टम पार्सर के बिना।

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

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

तथ्य एकत्र करने के समय:

gather_facts का उपयोग करके gather_facts आप प्लेबुक की शुरुआत में वर्तमान डिवाइस कॉन्फ़िगरेशन को निकाल सकते हैं, और फिर इसे प्लेबुक में उपयोग कर सकते हैं। डिवाइस से पुनर्प्राप्त करने के लिए व्यक्तिगत संसाधनों को निर्दिष्ट करें।

 - hosts: arista module_defaults: eos_facts: gather_subset: min gather_network_resources: - interfaces gather_facts: True 

आप इन उदाहरणों में कुछ नया देख सकते हैं, जिसका नाम है gather_facts: true अब नेटवर्क उपकरणों के लिए मूल तथ्य-खोज के लिए उपलब्ध है।

सीधे नेटवर्क तथ्यों मॉड्यूल का उपयोग करना:

 - name: collect interface configuration facts eos_facts: gather_subset: min gather_network_resources: - interfaces 

Playbook इंटरफ़ेस के बारे में निम्नलिखित तथ्य देता है:

 ansible_facts: ansible_network_resources: interfaces: - enabled: true name: Ethernet1 mtu: '1476' - enabled: true name: Loopback0 - enabled: true name: Loopback1 - enabled: true mtu: '1476' name: Tunnel0 - enabled: true name: Ethernet1 - enabled: true name: Tunnel1 - enabled: true name: Ethernet1 

ध्यान दें कि कैसे Ansible ने Arista डिवाइस से मूल कॉन्फ़िगरेशन को पुनर्प्राप्त किया और बाद के कार्यों और संचालन के लिए मानक कुंजी-मूल्य जोड़े के रूप में उपयोग करने के लिए इसे संरचित डेटा में परिवर्तित किया।

इंटरफ़ेस तथ्यों को अतिरिक्त संग्रहित या रूपांतरण के बिना eos_interfaces संसाधन eos_interfaces इनपुट के रूप में Ansible संग्रहीत चर में जोड़ा जा सकता है और तुरंत या बाद में उपयोग किया जा सकता है।

संसाधन मॉड्यूल

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

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

संसाधन मॉड्यूल क्या करता है यह समझाने के लिए, आइए एक प्लेबुक के एक उदाहरण को देखें जो नेटवर्क संसाधन और eos_l3_interface मॉड्यूल से नए तथ्यों का उपयोग करते हुए एक निष्क्रिय ऑपरेशन को eos_l3_interface है।

 - name: example of facts being pushed right back to device. hosts: arista gather_facts: false tasks: - name: grab arista eos facts eos_facts: gather_subset: min gather_network_resources: l3_interfaces - name: ensure that the IP address information is accurate eos_l3_interfaces: config: "{{ ansible_network_resources['l3_interfaces'] }}" register: result - name: ensure config did not change assert: that: not result.changed 

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

कॉन्फ़िगरेशन विचलन का पता लगाने का एक आदर्श तरीका है कि अंसिबल संग्रहीत चर में तथ्यों को संग्रहीत किया जाए और समय-समय पर उन्हें चेक मोड में संसाधन मॉड्यूल के साथ उपयोग किया जाए। यह देखने के लिए एक सरल विधि है कि क्या किसी ने मानों को मैन्युअल रूप से बदल दिया है। ज्यादातर मामलों में, संगठन मैन्युअल परिवर्तन और कॉन्फ़िगरेशन की अनुमति देते हैं, हालांकि कई ऑपरेशन Ansible स्वचालन के माध्यम से किए जाते हैं।

नए संसाधन मॉड्यूल पिछले वाले से अलग कैसे हैं?

एक नेटवर्क ऑटोमेशन इंजीनियर के लिए, पिछले संस्करणों से Ansible 2.9 में संसाधन मॉड्यूल के बीच 3 मुख्य अंतर हैं।

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

2) संसाधन मॉड्यूल में अब एक राज्य मूल्य शामिल है।

• merged किए merged : कॉन्फ़िगरेशन को प्रदान किए गए कॉन्फ़िगरेशन (डिफ़ॉल्ट) के साथ विलय कर दिया गया है;
• replaced : संसाधन कॉन्फ़िगरेशन को प्रदान किए गए कॉन्फ़िगरेशन के साथ बदल दिया जाएगा;
• overridden : संसाधन कॉन्फ़िगरेशन को प्रदान किए गए कॉन्फ़िगरेशन के साथ बदल दिया जाएगा; अतिरिक्त संसाधन उदाहरण हटा दिए जाएंगे;
• deleted : संसाधन कॉन्फ़िगरेशन को डिफ़ॉल्ट रूप से हटा दिया जाएगा / पुनर्स्थापित किया जाएगा।

3) संसाधन मॉड्यूल में अब स्थिर रिटर्न मान शामिल हैं। जब नेटवर्क संसाधन मॉड्यूल ने नेटवर्क डिवाइस में आवश्यक परिवर्तन किए (या सुझाए गए), तो यह वही कुंजी-मूल्य जोड़े को प्लेबुक में लौटाता है।

• before : कार्य से पहले संरचित डेटा के रूप में डिवाइस पर कॉन्फ़िगरेशन;
• after : यदि डिवाइस बदल गया है (या सत्यापन मोड का उपयोग करने पर बदल सकता है), परिणामी कॉन्फ़िगरेशन संरचित डेटा के रूप में वापस आ जाएगा;
• commands : किसी भी कॉन्फ़िगरेशन कमांड को वांछित स्थिति में लाने के लिए डिवाइस पर चल रहा है।

इस सबका क्या मतलब है? यह महत्वपूर्ण क्यों है?

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

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

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

Ansible Engine 2.9 में कौन से संसाधन मॉड्यूल दिखाई देंगे?

Ansible 2.9 में क्या होगा, विस्तार से बताने से पहले, आइए याद करते हैं कि हमने काम की पूरी राशि कैसे विभाजित की।

हमने 7 श्रेणियों और प्रत्येक निर्दिष्ट विशिष्ट नेटवर्क संसाधनों की पहचान की:

नोट: बोल्ड संसाधनों की योजना बनाई गई थी और उन्हें Ansible 2.9 में लागू किया गया था।
कॉर्पोरेट ग्राहकों और समुदाय की प्रतिक्रिया के आधार पर, पहले उन मॉड्यूल के साथ सौदा करना तर्कसंगत था जो नेटवर्क टोपोलॉजी प्रोटोकॉल, वर्चुअलाइजेशन और इंटरफेस से संबंधित हैं।
निम्नलिखित संसाधन मॉड्यूल को Ansible नेटवर्क टीम द्वारा विकसित किया गया है और उन प्लेटफार्मों के अनुरूप है जो Red Hat समर्थन करता है:

निम्नलिखित मॉड्यूल Ansible समुदाय द्वारा विकसित किए गए हैं:

• exos_lldp_global - चरम नेटवर्क से।
• nxos_bfd_interfaces - सिस्को से
• nxos_telemetry - सिस्को से

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

2.10 के लिए योजनाएं आगे चलकर

Ansible 2.9 के रिलीज़ होने के बाद, हम Ansible 2.10 के लिए संसाधन मॉड्यूल के निम्नलिखित सेट से निपटेंगे, जिसका उपयोग टोपोलॉजी और नेटवर्क नीति, जैसे ACL, OSPF और BGP को और कॉन्फ़िगर करने के लिए किया जा सकता है। विकास की योजना को अभी भी समायोजित किया जा सकता है, इसलिए यदि आपके पास कोई टिप्पणी है, तो इसे Ansible Network समुदाय को रिपोर्ट करें।

संसाधन और आरंभ करना

Ansible स्वचालन मंच प्रेस विज्ञप्ति
Ansible स्वचालन प्लेटफ़ॉर्म ब्लॉग
अंसिबल पर सामग्री वितरण का भविष्य
परिवर्तनशील परियोजना संरचना को बदलने पर विचार