इनसाइड प्लेबुक। नयाँ उत्तरदायी इन्जिन 2.9 मा नेटवर्क प्रकार्यहरू

Red Hat Ansible Engine 2.9 को आगामी रिलीजले रोमाञ्चक सुधारहरू ल्याउँछ, जसमध्ये केही यस लेखमा छलफल गरिएको छ। सधैं झैँ, हामीले समुदायको सहयोगमा खुला रूपमा उत्तरदायी नेटवर्क सुधारहरू विकास गर्दै आएका छौं। हामीसँग सामेल हुनुहोस् - हेर्नुहोस् GitHub मा जारी बोर्ड र विकास योजना अध्ययन गर्नुहोस् Red Hat Ansible इन्जिन 2.9 को रिलीज को लागि विकि पृष्ठमा उत्तरदायी नेटवर्क.

हामीले भर्खरै घोषणा गरे अनुसार, Red Hat उत्तरदायी स्वचालन प्लेटफार्म अब उत्तरदायी टावर, उत्तरदायी इन्जिन र सबै उत्तरदायी नेटवर्क सामग्री समावेश गर्दछ। आजकल, सबैभन्दा लोकप्रिय नेटवर्किङ प्लेटफर्महरू उत्तरदायी मोड्युलहरू मार्फत लागू गरिन्छ। उदाहरणका लागि:

• अरिस्टा EOS
• सिस्को आईओएस
• सिस्को आईओएस एक्सआर
• सिस्को NX-OS
• जुनिपर जुनोस
• VyOS

उत्तरदायी स्वचालन सदस्यता मार्फत Red Hat द्वारा पूर्ण रूपमा समर्थित प्लेटफर्महरूको पूर्ण सूचीको लागि, यहाँ प्रकाशित.

हामीले के सिकेका छौं

विगत चार वर्षहरूमा, हामीले नेटवर्क स्वचालन प्लेटफर्मको विकासको बारेमा धेरै कुरा सिकेका छौं। त्यो पनि हामीले सिकेका छौं कसरी प्लेटफर्म कलाकृतिहरू उत्तरदायी प्लेबुक र अन्तिम प्रयोगकर्ताहरूद्वारा भूमिकाहरूमा प्रयोग गरिन्छ। र यहाँ हामीले के पत्ता लगायौं:

• संगठनहरू एक मात्र होइन, तर धेरै विक्रेताहरूबाट स्वचालित यन्त्रहरू हुन्।
• स्वचालन प्राविधिक मात्र होइन, सांस्कृतिक पनि हो।
• स्वचालन डिजाइनको आधारभूत वास्तुशिल्प सिद्धान्तहरूको कारणले गर्दा स्केलमा सञ्जालहरू स्वचालित गर्न गाह्रो छ।

जब हामीले हाम्रो दीर्घकालीन वृद्धि योजनाहरू एक वर्ष पहिले छलफल गर्यौं, हाम्रा कर्पोरेट ग्राहकहरूले निम्नको लागि सोधे:

• तथ्य सङ्कलनलाई सबै यन्त्रहरूमा अझ राम्रो मानकीकृत र स्वचालन कार्यप्रवाहहरूसँग पङ्क्तिबद्ध गर्न आवश्यक छ।
• यन्त्रमा कन्फिगरेसनहरू अद्यावधिक गर्न पनि मानकीकृत र एकरूप हुन आवश्यक छ ताकि उत्तरदायी मोड्युलहरूले तथ्यहरू सङ्कलन गरेपछि चक्रको दोस्रो भागलाई ह्यान्डल गर्न सक्छन्।
• हामीलाई यन्त्र कन्फिगरेसनलाई संरचित डेटामा रूपान्तरण गर्नको लागि कठोर र समर्थित विधिहरू चाहिन्छ। यस आधारमा, सत्यको स्रोत नेटवर्क उपकरणबाट सार्न सकिन्छ।

तथ्य सुधारहरू

Ansible को प्रयोग गरेर नेटवर्क यन्त्रहरूबाट तथ्यहरू सङ्कलन गर्ने काम अक्सर अनियमित रूपमा हुन्छ। वेब-आधारित प्लेटफर्महरूमा तथ्य-संकलन क्षमताहरूको फरक-फरक डिग्रीहरू छन्, तर तिनीहरूसँग कुञ्जी-मान जोडीहरूमा डेटाको प्रतिनिधित्व पार्सिङ र मानकीकरणको लागि कम वा कुनै कार्यक्षमता छैन। पढ्नुहोस् पोस्ट केन सेलेन्जाले तथ्यात्मक तथ्याङ्कको विश्लेषण र मानकीकरण गर्न कत्तिको गाह्रो र पीडादायी हुन सक्छ भन्ने बारेमा

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

यदि तपाइँ नेटवर्क इन्जिन कसरी प्रयोग गर्ने भनेर जान्नुहुन्छ भने, यो 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

तपाईंले देख्न सक्नुहुने रूपमा, यन्त्रबाट सङ्कलन गरिएको डाटा रूपान्तरण बिना सम्बन्धित स्रोत मोड्युलमा सीधा स्थानान्तरण गरिएको छ। जब सुरु हुन्छ, प्लेबुकले यन्त्रबाट मानहरू प्राप्त गर्छ र अपेक्षित मानहरूसँग तुलना गर्छ। यस उदाहरणमा, फिर्ता गरिएका मानहरू अपेक्षित रूपमा छन् (अर्थात, यसले कन्फिगरेसन विचलनहरूको लागि जाँच गर्दछ) र कन्फिगरेसन परिवर्तन भएको छ कि छैन भनेर रिपोर्ट गर्दछ।

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

नयाँ स्रोत मोड्युलहरू अघिल्लाहरूबाट कसरी भिन्न छन्?

नेटवर्क स्वचालन इन्जिनियरको लागि, उत्तरदायी 3 र अघिल्लो संस्करणहरूमा संसाधन मोड्युलहरू बीच 2.9 मुख्य भिन्नताहरू छन्।

1) दिइएको नेटवर्क स्रोतको लागि (जसलाई कन्फिगरेसन खण्डको रूपमा पनि सोच्न सकिन्छ), मोड्युलहरू र तथ्यहरू सबै समर्थित नेटवर्क अपरेटिङ सिस्टमहरूमा एकैसाथ विकसित हुनेछन्। हामी सोच्दछौं कि यदि Ansible ले एक नेटवर्क प्लेटफर्ममा संसाधन कन्फिगरेसनलाई समर्थन गर्दछ, हामीले यसलाई सबै ठाउँमा समर्थन गर्नुपर्छ। यसले स्रोत मोड्युलहरूको प्रयोगलाई सरल बनाउँछ किनभने नेटवर्क स्वचालन इन्जिनियरले अब नेटिभ र समर्थित मोड्युलहरू भएका सबै नेटवर्क अपरेटिङ सिस्टमहरूमा स्रोत (जस्तै LLDP) कन्फिगर गर्न सक्छ।

2) संसाधन मोड्युलहरूले अब राज्य मान समावेश गर्दछ।

• merged: कन्फिगरेसन प्रदान गरिएको कन्फिगरेसनसँग मर्ज गरिएको छ (पूर्वनिर्धारित);
• replaced: स्रोत कन्फिगरेसन प्रदान गरिएको कन्फिगरेसनसँग प्रतिस्थापन गरिनेछ;
• overridden: स्रोत कन्फिगरेसन प्रदान गरिएको कन्फिगरेसनसँग प्रतिस्थापन गरिनेछ; अनावश्यक स्रोत उदाहरणहरू मेटिनेछन्;
• deleted: स्रोत कन्फिगरेसन मेटाइनेछ/पूर्वनिर्धारितमा पुनर्स्थापित गरिनेछ।

3) संसाधन मोड्युलहरूले अब स्थिर फिर्ता मानहरू समावेश गर्दछ। जब नेटवर्क स्रोत मोड्युलले नेटवर्क उपकरणमा आवश्यक परिवर्तनहरू (वा प्रस्तावित) गरेको छ, यसले प्लेबुकमा समान कुञ्जी-मान जोडीहरू फर्काउँछ।

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

यी सबैको अर्थ के हो? यो किन महत्त्वपूर्ण छ?

यस पोष्टले धेरै जटिल अवधारणाहरू समेट्छ, तर हामी आशा गर्छौं कि अन्तमा तपाईले उद्यम क्लाइन्टहरूले तथ्य सङ्कलन, डेटा सामान्यीकरण, र स्वचालन प्लेटफर्मको लागि लुप कन्फिगरेसनमा के सोधिरहेका छन् भन्ने बारे राम्रोसँग बुझ्नुहुनेछ। तर तिनीहरूलाई किन यी सुधारहरू चाहिन्छ? धेरै संस्थाहरूले अब आफ्नो IT वातावरणलाई अझ चुस्त र प्रतिस्पर्धी बनाउन डिजिटल रूपान्तरणलाई पछ्याइरहेका छन्। राम्रो वा नराम्रोको लागि, धेरै नेटवर्क इन्जिनियरहरू या त स्वार्थको लागि वा व्यवस्थापनको आदेशमा नेटवर्क विकासकर्ता बन्छन्।

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

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

उत्तरदायी इन्जिन 2.9 मा कुन स्रोत मोड्युलहरू आउँदैछन्?

Ansible 2.9 मा के हुनेछ भनेर हामीले विस्तृत रूपमा बताउन अघि, हामीले कामको सम्पूर्ण दायरा कसरी विभाजित गर्यौं भनेर सम्झौं।

हामीले 7 कोटिहरू पहिचान गर्यौं र प्रत्येकलाई निर्दिष्ट नेटवर्क स्रोतहरू तोक्यौं:

नोट: बोल्डमा स्रोतहरू उत्तरदायी २.९ मा योजना र कार्यान्वयन गरिएका थिए।
इन्टरप्राइज ग्राहकहरू र समुदायबाट प्रतिक्रियाको आधारमा, नेटवर्क टोपोलोजी प्रोटोकल, भर्चुअलाइजेसन, र इन्टरफेसहरूसँग सम्बन्धित ती मोड्युलहरूलाई पहिले समाधान गर्न तार्किक थियो।
निम्न स्रोत मोड्युलहरू उत्तरदायी नेटवर्क टोलीद्वारा विकसित गरिएका थिए र Red Hat द्वारा समर्थित प्लेटफर्महरूसँग मेल खान्छ:

निम्न मोड्युलहरू उत्तरदायी समुदायद्वारा विकसित गरिएका छन्:

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

तपाईंले देख्न सक्नुहुने रूपमा, संसाधन मोड्युलहरूको अवधारणा हाम्रो प्लेटफर्म-केन्द्रित रणनीतिमा फिट हुन्छ। त्यो हो, हामीले नेटवर्क मोड्युलहरूको विकासमा मानकीकरणलाई समर्थन गर्न, र जवाफदेही भूमिका र प्लेबुकहरूको स्तरमा प्रयोगकर्ताहरूको कामलाई सरल बनाउनको लागि Ansible मा आवश्यक क्षमताहरू र कार्यहरू समावेश गर्दछौं। संसाधन मोड्युलहरूको विकास विस्तार गर्न, उत्तरदायी टोलीले मोड्युल बिल्डर उपकरण जारी गर्‍यो।

उत्तरदायी 2.10 र माथिका लागि योजनाहरू

एकपटक Ansible 2.9 रिलीज भएपछि, हामी Ansible 2.10 को लागि संसाधन मोड्युलहरूको अर्को सेटमा काम गर्नेछौं, जुन नेटवर्क टोपोलोजी र नीतिलाई थप कन्फिगर गर्न प्रयोग गर्न सकिन्छ, उदाहरणका लागि। ACL, OSPF र BGP। विकास योजना अझै पनि समायोजन गर्न सकिन्छ, त्यसैले यदि तपाईंसँग टिप्पणी छ भने, कृपया यसलाई रिपोर्ट गर्नुहोस् उत्तरदायी नेटवर्क समुदाय.

स्रोतहरू र सुरु गर्दै

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

स्रोत: www.habr.com