इनसाइड प्लेबुक. नवीन उत्तरदायी इंजिन 2.9 मध्ये नेटवर्किंग वैशिष्ट्ये

Red Hat Ansible Engine 2.9 चे आगामी प्रकाशन रोमांचक सुधारणा आणते, त्यापैकी काही या लेखात समाविष्ट आहेत. नेहमीप्रमाणे, आम्ही समुदायाच्या पाठिंब्याने उघडपणे उत्तरदायी नेटवर्क सुधारणा विकसित करत आहोत. आमच्यात सामील व्हा - पहा GitHub वर बोर्ड जारी करा आणि विकास आराखड्याचा अभ्यास करा Red Hat Ansible Engine 2.9 चे प्रकाशन साठी विकी पृष्ठावर उत्तरदायी नेटवर्क.

आम्ही अलीकडेच जाहीर केल्याप्रमाणे, रेड हॅट एन्सिबल ऑटोमेशन प्लॅटफॉर्म आता उत्तरदायी टॉवर, उत्तरदायी इंजिन आणि सर्व उत्तरदायी नेटवर्क सामग्री समाविष्ट आहे. आजकाल, सर्वात लोकप्रिय नेटवर्किंग प्लॅटफॉर्म उत्तरदायी मॉड्यूल्सद्वारे कार्यान्वित केले जातात. उदाहरणार्थ:

• Arista EOS
• सिस्को आयओएस
• सिस्को IOS XR
• सिस्को NX-OS
• जुनिपर जुनोस
• VyOS

उत्तरदायी ऑटोमेशन सबस्क्रिप्शनद्वारे Red Hat द्वारे पूर्णपणे समर्थित असलेल्या प्लॅटफॉर्मच्या संपूर्ण सूचीसाठी, येथे प्रकाशित.

आम्ही काय शिकलो

गेल्या चार वर्षांत, आम्ही नेटवर्क ऑटोमेशन प्लॅटफॉर्म विकसित करण्याबद्दल बरेच काही शिकलो आहोत. तेही आम्ही शिकलो कसे प्लॅटफॉर्म आर्टिफॅक्ट्स अंतिम वापरकर्त्यांद्वारे उत्तरदायी प्लेबुक आणि भूमिकांमध्ये वापरल्या जातात. आणि आम्हाला जे आढळले ते येथे आहे:

• संस्था केवळ एक नव्हे तर अनेक विक्रेत्यांकडून स्वयंचलित उपकरणे आहेत.
• ऑटोमेशन ही केवळ तांत्रिक घटना नाही तर सांस्कृतिक देखील आहे.
• ऑटोमेशन डिझाइनच्या मूलभूत आर्किटेक्चरल तत्त्वांमुळे मोठ्या प्रमाणावर नेटवर्क स्वयंचलित करणे हे दिसते त्यापेक्षा अधिक कठीण आहे.

एका वर्षापूर्वी आम्ही आमच्या दीर्घकालीन वाढीच्या योजनांवर चर्चा केली तेव्हा आमच्या कॉर्पोरेट क्लायंटने पुढील गोष्टींसाठी विचारले:

• तथ्य संकलन अधिक चांगल्या प्रकारे प्रमाणित आणि सर्व उपकरणांवर ऑटोमेशन वर्कफ्लोसह संरेखित करणे आवश्यक आहे.
• डिव्हाइसवरील कॉन्फिगरेशन अद्यतनित करणे देखील प्रमाणित आणि सुसंगत असणे आवश्यक आहे जेणेकरून उत्तरदायी मॉड्यूल तथ्ये गोळा केल्यानंतर सायकलचा दुसरा भाग हाताळू शकतील.
• डिव्हाइस कॉन्फिगरेशनला संरचित डेटामध्ये रूपांतरित करण्यासाठी आम्हाला कठोर आणि समर्थित पद्धतींची आवश्यकता आहे. या आधारावर, नेटवर्क डिव्हाइसवरून सत्याचा स्रोत हलविला जाऊ शकतो.

तथ्य सुधारणा

Ansible वापरून नेटवर्क उपकरणांमधून तथ्ये गोळा करणे अनेकदा यादृच्छिकपणे घडते. वेब-आधारित प्लॅटफॉर्ममध्ये भिन्न प्रमाणात तथ्य-संकलन क्षमता आहेत, परंतु त्यांच्याकडे की-व्हॅल्यू जोड्यांमध्ये डेटाचे प्रतिनिधित्व पार्सिंग आणि प्रमाणित करण्यासाठी कमी किंवा कोणतीही कार्यक्षमता नाही. वाचा पोस्ट तथ्यात्मक डेटाचे विश्लेषण आणि प्रमाणीकरण करणे किती कठीण आणि वेदनादायक असू शकते यावर केन सेलेन्झा.

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

तुम्हाला नेटवर्क इंजिन कसे वापरायचे हे माहित असल्यास, उत्तरेमध्ये वापरण्यासाठी तथ्य डेटा गोळा करणे, विश्लेषित करणे आणि प्रमाणित करण्याचा हा एक अतिशय कार्यक्षम मार्ग आहे. या भूमिकेचा तोटा असा आहे की आपल्याला प्रत्येक प्लॅटफॉर्मसाठी आणि सर्व नेटवर्क क्रियाकलापांसाठी पार्सर्सचा संपूर्ण समूह तयार करण्याची आवश्यकता आहे. पार्सर तयार करणे, पाठवणे आणि देखरेख करणे किती कठीण आहे हे समजून घेण्यासाठी, एक नजर टाका 1200 पेक्षा जास्त विश्लेषक सिस्कोमधील मुलांकडून.

थोडक्यात, डिव्हाइसेसमधून तथ्ये मिळवणे आणि त्यांना की-व्हॅल्यू जोड्यांमध्ये सामान्य करणे स्केलवर ऑटोमेशनसाठी आवश्यक आहे, परंतु तुमच्याकडे अनेक विक्रेते आणि नेटवर्क प्लॅटफॉर्म असताना हे साध्य करणे कठीण आहे.

Ansible 2.9 मधील प्रत्येक नेटवर्क फॅक्ट मॉड्यूल आता नेटवर्क डिव्हाइसच्या कॉन्फिगरेशनचे विश्लेषण करू शकते आणि संरचित डेटा परत करू शकते - अतिरिक्त लायब्ररी, उत्तरदायी भूमिका किंवा कस्टम पार्सरशिवाय.

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 एका नेटवर्क प्लॅटफॉर्मवर संसाधन कॉन्फिगरेशनला समर्थन देत असेल, तर आम्ही सर्वत्र त्याचे समर्थन केले पाहिजे. हे संसाधन मॉड्यूल्सचा वापर सुलभ करते कारण नेटवर्क ऑटोमेशन अभियंता आता मूळ आणि समर्थित मॉड्यूल्ससह सर्व नेटवर्क ऑपरेटिंग सिस्टमवर संसाधन (जसे की LLDP) कॉन्फिगर करू शकतो.

2) संसाधन मॉड्यूल्समध्ये आता राज्य मूल्य समाविष्ट आहे.

• merged: कॉन्फिगरेशन प्रदान केलेल्या कॉन्फिगरेशनमध्ये विलीन केले आहे (डीफॉल्ट);
• replaced: संसाधन कॉन्फिगरेशन प्रदान केलेल्या कॉन्फिगरेशनसह बदलले जाईल;
• overridden: संसाधन कॉन्फिगरेशन प्रदान केलेल्या कॉन्फिगरेशनसह बदलले जाईल; अनावश्यक संसाधन उदाहरणे हटविली जातील;
• deleted: संसाधन कॉन्फिगरेशन हटवले जाईल/डिफॉल्टवर पुनर्संचयित केले जाईल.

3) संसाधन मॉड्यूल्समध्ये आता स्थिर परतावा मूल्ये समाविष्ट आहेत. जेव्हा नेटवर्क रिसोर्स मॉड्यूलने नेटवर्क डिव्हाइसमध्ये आवश्यक बदल केले (किंवा प्रस्तावित केले) तेव्हा ते प्लेबुकमध्ये समान की-व्हॅल्यू जोड्या परत करते.

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

या सगळ्याचा अर्थ काय? ते महत्त्वाचे का आहे?

या पोस्टमध्ये बर्‍याच गुंतागुंतीच्या संकल्पनांचा समावेश आहे, परंतु आम्हाला आशा आहे की शेवटी एंटरप्राइझ क्लायंट वस्तुस्थिती संकलन, डेटा सामान्यीकरण आणि ऑटोमेशन प्लॅटफॉर्मसाठी लूप कॉन्फिगरेशन काय विचारत आहेत याची आपल्याला अधिक चांगली समज असेल. पण त्यांना या सुधारणांची गरज का आहे? अनेक संस्था आता त्यांचे IT वातावरण अधिक चपळ आणि स्पर्धात्मक बनवण्यासाठी डिजिटल परिवर्तनाचा पाठपुरावा करत आहेत. चांगले किंवा वाईट, बरेच नेटवर्क अभियंते एकतर स्वार्थासाठी किंवा व्यवस्थापनाच्या आदेशानुसार नेटवर्क डेव्हलपर बनतात.

संस्थांना हे समजले आहे की वैयक्तिक नेटवर्क टेम्पलेट स्वयंचलित केल्याने सायलोची समस्या सुटत नाही आणि केवळ काही प्रमाणात कार्यक्षमता वाढते. Red Hat उत्तरदायी ऑटोमेशन प्लॅटफॉर्म नेटवर्क उपकरणावरील अंतर्निहित डेटा प्रोग्रामेटिकरित्या व्यवस्थापित करण्यासाठी कठोर आणि मानक संसाधन डेटा मॉडेल प्रदान करते. म्हणजेच, वापरकर्ते विशिष्ट विक्रेत्याच्या अंमलबजावणीऐवजी तंत्रज्ञानावर (उदाहरणार्थ, IP पत्ते, VLAN, LLDP, इ.) भर देऊन अधिक आधुनिक पद्धतींच्या बाजूने वैयक्तिक कॉन्फिगरेशन पद्धती हळूहळू सोडून देत आहेत.

याचा अर्थ विश्वासार्ह आणि सिद्ध कमांड मॉड्यूल्स आणि कॉन्फिगरेशनचे दिवस क्रमांकित आहेत का? कोणत्याही परिस्थितीत नाही. अपेक्षित नेटवर्क संसाधन मॉड्यूल्स सर्व प्रकरणांमध्ये किंवा प्रत्येक विक्रेत्यासाठी लागू होणार नाहीत, त्यामुळे काही अंमलबजावणीसाठी नेटवर्क अभियंत्यांना कमांड आणि कॉन्फिगरेशन मॉड्यूलची आवश्यकता असेल. रिसोर्स मॉड्यूल्सचा उद्देश मोठ्या जिन्जा टेम्प्लेट्स सुलभ करणे आणि संरचित JSON फॉरमॅटमध्ये असंरचित डिव्हाइस कॉन्फिगरेशन सामान्य करणे हा आहे. संसाधन मॉड्यूल्ससह, विद्यमान नेटवर्कसाठी त्यांचे कॉन्फिगरेशन संरचित की-व्हॅल्यू जोड्यांमध्ये रूपांतरित करणे सोपे होईल जे सत्याच्या वाचण्यास-सोप्या स्त्रोताचे प्रतिनिधित्व करतात. संरचित की-व्हॅल्यू जोड्यांचा वापर करून, तुम्ही प्रत्येक डिव्हाइसवर कॉन्फिगरेशन चालवण्यापासून स्वतंत्र संरचित डेटासह कार्य करण्यापर्यंत आणि नेटवर्क्सना इन्फ्रास्ट्रक्चर-एज-कोड दृष्टिकोनाच्या आघाडीवर आणू शकता.

Ansible Engine 2.9 मध्ये कोणते संसाधन मॉड्यूल येणार आहेत?

Ansible 2.9 मध्ये काय होईल हे आम्ही तुम्हाला तपशीलवार सांगण्यापूर्वी, आम्ही कामाची संपूर्ण व्याप्ती कशी विभागली ते लक्षात ठेवूया.

आम्ही 7 श्रेणी ओळखल्या आणि प्रत्येकाला विशिष्ट नेटवर्क संसाधने नियुक्त केली:

टीप: ठळक अक्षरात संसाधने नियोजित आणि उत्तरदायी 2.9 मध्ये लागू करण्यात आली.
एंटरप्राइझ ग्राहक आणि समुदायाच्या अभिप्रायाच्या आधारे, नेटवर्क टोपोलॉजी प्रोटोकॉल, व्हर्च्युअलायझेशन आणि इंटरफेसशी संबंधित त्या मॉड्यूल्सना प्रथम हाताळणे तर्कसंगत होते.
खालील रिसोर्स मॉड्यूल्स अॅन्सिबल नेटवर्क टीमने विकसित केले आहेत आणि Red Hat द्वारे समर्थित प्लॅटफॉर्मशी संबंधित आहेत:

खालील मॉड्यूल्स उत्तरदायी समुदायाद्वारे विकसित केले जातात:

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

तुम्ही बघू शकता, संसाधन मॉड्यूलची संकल्पना आमच्या प्लॅटफॉर्म-केंद्रित धोरणात बसते. म्हणजेच, नेटवर्क मॉड्यूल्सच्या विकासामध्ये मानकीकरणास समर्थन देण्यासाठी आणि उत्तरदायी भूमिका आणि प्लेबुकच्या स्तरावर वापरकर्त्यांचे कार्य सुलभ करण्यासाठी आम्ही Ansible मध्येच आवश्यक क्षमता आणि कार्ये समाविष्ट करतो. संसाधन मॉड्यूल्सच्या विकासाचा विस्तार करण्यासाठी, उत्तरदायी टीमने मॉड्यूल बिल्डर टूल जारी केले.

उत्तरदायी 2.10 आणि त्यापुढील योजना

एकदा Ansible 2.9 रिलीज झाल्यावर, आम्ही Ansible 2.10 साठी रिसोर्स मॉड्यूल्सच्या पुढील सेटवर काम करू, ज्याचा वापर नेटवर्क टोपोलॉजी आणि पॉलिसी कॉन्फिगर करण्यासाठी केला जाऊ शकतो, उदा. ACL, OSPF आणि BGP. विकास आराखडा अजूनही समायोजित केला जाऊ शकतो, म्हणून तुमच्या टिप्पण्या असल्यास, कृपया कळवा उत्तरदायी नेटवर्क समुदाय.

संसाधने आणि प्रारंभ करणे

उत्तरदायी ऑटोमेशन प्लॅटफॉर्मबद्दल प्रेस प्रकाशन
उत्तरदायी ऑटोमेशन प्लॅटफॉर्म ब्लॉग
उत्तरदायी मध्ये सामग्री वितरणाचे भविष्य
उत्तरदायी प्रकल्प संरचना बदलण्यावर प्रतिबिंब

स्त्रोत: www.habr.com