इनसाइड प्लेबुक। नए Ansible इंजन 2.9 में नेटवर्क कार्य करता है

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

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

• अरिस्ता EOS
• सिस्को IOS
• सिस्को आईओएस एक्सआर
• सिस्को एनएक्स-ओएस
• जुनिपर जूनोस
• व्योस

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

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

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

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

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

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

तथ्य सुधार

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

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

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

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

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

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

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

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

किसी कीवर्ड का उपयोग करना 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

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

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_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 3 और पिछले संस्करणों में संसाधन मॉड्यूल के बीच 2.9 मुख्य अंतर हैं।

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

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

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

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

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

इन सभी का क्या अर्थ है? यह महत्वपूर्ण क्यों है?

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

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

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

Ansible इंजन 2.9 में कौन से संसाधन मॉड्यूल आएंगे?

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

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

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

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

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

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

Ansible 2.10 और उससे आगे की योजनाएँ

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

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

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

स्रोत: www.habr.com