Red Hat Ansible में नया नेटवर्क ऑटोमेशन सुविधाएँ

Ansible Engine 2.6 में कार्यान्वित महत्वपूर्ण सुधारों के प्रकाश में, साथ ही Ansible Tower 3.3 की रिलीज़ और हाल ही में Ansible Engine 2.7 की रिलीज़ को ध्यान में रखते हुए, आइए हम नेटवर्क स्वचालन के लिए संभावनाओं पर करीब से नज़र डालें।



इस पोस्ट में:

• Httpapi कनेक्शन प्लगइन।
  • Arista eAPI और सिस्को NX-API के लिए समर्थन।
• नया नेटवर्क स्वचालन मॉड्यूल।
  • net_get और net_put।
  • netconf_get, netconf_rpc और netconf_config।
  • cli_command और cli_config।
• बेहतर Ansible टॉवर वेब इंटरफ़ेस।
• नेटवर्क डिवाइसेस के साथ काम करने पर एंज़िबल टॉवर में क्रेडेंशियल्स प्रबंधित करें।
• एक ही समय में टॉवर में Ansible के विभिन्न संस्करणों का उपयोग करना

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

HTTPAPI कनेक्शन प्लगइन

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

Ansible 2.5 में, eAPI और NX-API तरीकों से जुड़ना केवल पुराने प्रदाता विधि का उपयोग करना संभव था। Ansible 2.6 में अब यह सीमा नहीं है और आप स्वतंत्र रूप से उच्च-स्तरीय httpapi कनेक्शन विधि का उपयोग कर सकते हैं। आइए देखें कि यह कैसे किया जाता है।

आपको पहले नेटवर्क डिवाइस पर eAPI या NX-API को सक्षम करना होगा ताकि आप उसके बाद httpapi विधि का उपयोग कर सकें। यह आसानी से उपयुक्त Ansible टीम द्वारा किया जाता है, उदाहरण के लिए, यहां एक Arista EOS स्विच पर eAPI को सक्षम करने का तरीका बताया गया है।

[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01 leaf01 | SUCCESS => { "ansible_facts": { "eos_eapi_urls": { "Ethernet1": [ "https://192.168.0.14:443" ], "Management1": [ "https://10.0.2.15:443" ] } }, "changed": false, "commands": [] } 

जब एक वास्तविक Arista EOS स्विच से कनेक्ट किया जाता है, तो शो प्रबंधन एपीआई http-कमांड कमांड दिखाएगा कि एपीआई सक्षम है:

 leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<<rest of output removed for brevity>>> 

नीचे दी गई Ansible Playbook स्क्रिप्ट केवल शो संस्करण कमांड को निष्पादित करती है, और फिर डिबग अनुभाग में केवल कार्य के JSON आउटपुट से संस्करण को वापस करता है।

 --- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"] 

इस स्क्रिप्ट को चलाने पर निम्न परिणाम प्राप्त होंगे:

 [user@rhel7]$ ansible-playbook playbook.yml PLAY [leaf01]******************************************************** TASK [type a simple arista command] ********************************* ok: [leaf01] TASK [print command output to terminal window] ********************** ok: [leaf01] => { "command_output.stdout[0][\"version\"]": "4.20.1F" } PLAY RECAP*********************************************************** leaf01 : ok=2 changed=0 unreachable=0 failed=0 

नोट: Arista eAPI कमांड के संक्षिप्त संस्करणों का समर्थन नहीं करता (जैसे "शो वर्जन" के बजाय "शो संस्करण 2), इसलिए आपको उन सभी को लिखना होगा। Httpapi कनेक्शन प्लगइन पर अधिक जानकारी के लिए, दस्तावेज़ीकरण देखें।

नया नेटवर्क स्वचालन मॉड्यूल

अक्टूबर में जारी किए गए अंसारी 2.6 और संस्करण 2.7 नेटवर्क स्वचालन के लिए सात नए मॉड्यूल पेश करते हैं।

• net_get - एक फाइल को नेटवर्क डिवाइस से Ansible कंट्रोलर में कॉपी करें ।
• net_put - एक नेटवर्क डिवाइस के लिए Ansible नियंत्रक से एक फ़ाइल की प्रतिलिपि बनाएँ ।
• netconf_get - NETCONF सक्षम नेटवर्क डिवाइस से कॉन्फ़िगरेशन / स्थिति डेटा को पुनर्प्राप्त करता है।
• netconf_rpc - NETCONF सक्षम के साथ एक नेटवर्क डिवाइस पर ऑपरेशन करता है।
• netconf_config - netconf डिवाइस कॉन्फ़िगरेशन, मॉड्यूल उपयोगकर्ता को netconf उपकरणों के लिए एक XML फ़ाइल भेजने और यह देखने के लिए अनुमति देता है कि कॉन्फ़िगरेशन बदल गया है या नहीं।
• cli_command - उन नेटवर्क उपकरणों पर cli कमांड चलाता है जिनके पास कमांड इंटरफ़ेस (cli) है।
• cli_config - network_cli के माध्यम से नेटवर्क उपकरणों के लिए पाठ विन्यास (धक्का) भेजता है।

net_get और net_put

• net_get - एक फाइल को नेटवर्क डिवाइस से Ansible कंट्रोलर में कॉपी करें ।
• net_put - एक नेटवर्क डिवाइस के लिए Ansible नियंत्रक से एक फ़ाइल की प्रतिलिपि बनाएँ ।

Net_get और net_put मॉड्यूल किसी विशेष निर्माता के उपकरण से बंधे नहीं हैं और बस मानक SCP या SFTP स्थानांतरण प्रोटोकॉल (प्रोटोकॉल पैरामीटर द्वारा निर्दिष्ट) का उपयोग करके नेटवर्क डिवाइस से फ़ाइलों की प्रतिलिपि बनाते हैं। इन दोनों मॉड्यूल के लिए network_cli कनेक्शन विधि के उपयोग की आवश्यकता होती है, और यह भी तभी काम करता है जब नियंत्रक पर scp (पिप इंस्टॉल स्कैप) स्थापित हो और SCP या SFTP नेटवर्क डिवाइस पर सक्षम हो।

हम मानते हैं कि हमारी प्लेबुक के साथ उदाहरण में, हमने पहले ही लीफ 01 डिवाइस पर निम्नलिखित कमांड को निष्पादित कर दिया है:

 leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully. 

यहाँ दो कार्यों के साथ एक प्लेबुक की तरह दिखता है (पहला पत्ता01 डिवाइस से फाइल को कॉपी करता है, और दूसरा पत्ता01 डिवाइस को फाइल कॉपी करता है):

 --- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt 

netconf_get, netconf_rpc और netconf_config

• netconf_get - NETCONF सक्षम नेटवर्क डिवाइस से कॉन्फ़िगरेशन / स्थिति डेटा को पुनर्प्राप्त करता है।
• netconf_rpc - NETCONF सक्षम के साथ एक नेटवर्क डिवाइस पर ऑपरेशन करता है।
• netconf_config - netconf डिवाइस कॉन्फ़िगरेशन, मॉड्यूल उपयोगकर्ता को netconf उपकरणों के लिए एक XML फ़ाइल भेजने और यह देखने के लिए अनुमति देता है कि कॉन्फ़िगरेशन बदल गया है या नहीं।

नेटवर्क प्रबंधन प्रोटोकॉल NETCONF (नेटवर्क कॉन्फ़िगरेशन प्रोटोकॉल) IETF द्वारा विकसित और मानकीकृत है। RFC 6241 के अनुसार, NETCONF का उपयोग नेटवर्क डिवाइस कॉन्फ़िगरेशन को स्थापित करने, हेरफेर करने और हटाने के लिए किया जा सकता है। NETCONF SSH कमांड लाइन (network_cli) और API जैसे सिस्को NX-API या Arista eAPI (httpapi) का विकल्प है।

नए netconf मॉड्यूल को प्रदर्शित करने के लिए, हम सबसे पहले junos_netconf मॉड्यूल का उपयोग करके जुनिपर राउटर पर netconf को सक्षम करते हैं। Netconf सभी नेटवर्क उपकरण मॉडल पर समर्थित नहीं है, इसलिए इसका उपयोग करने से पहले अपने दस्तावेज़ की जाँच करें।

 [user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli rtr4 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } rtr3 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } 

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

 <rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]> 

इसे आसानी से Ansible Playbook में अनुवाद किया जाता है। get-interface-information एक RPC कॉल है, और अतिरिक्त पैरामीटर कुंजी-मूल्य जोड़े के रूप में निर्दिष्ट हैं। इस उदाहरण में, केवल एक पैरामीटर है - इंटरफ़ेस-नाम - और हमारे नेटवर्क डिवाइस पर हम सिर्फ em1.0 को देखना चाहते हैं। हम रजिस्टर पैरामीटर का उपयोग करते हैं जो कार्य पर सेट किया गया था, बस परिणामों को बचाने के लिए, इसलिए हम डीबग मॉड्यूल का उपयोग करते हैं और टर्मिनल स्क्रीन पर परिणाम प्रदर्शित करते हैं। Netconf_rpc मॉड्यूल आपको सीधे XML आउटपुट का JSON में अनुवाद करने की भी अनुमति देता है।

 --- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info 

प्लेबुक शुरू करने के बाद, हमें यह मिलता है:

 ok: [rtr4] => { "netconf_info": { "changed": false, "failed": false, "output": { "rpc-reply": { "interface-information": { "logical-interface": { "address-family": [ { "address-family-flags": { "ifff-is-primary": "" }, "address-family-name": "inet", "interface-address": [ { "ifa-broadcast": "10.255.255.255", "ifa-destination": "10/8", "ifa-flags": { "ifaf-current-preferred": "" }, "ifa-local": "10.0.0.4" }, <<<rest of output removed for brevity>>> 

अधिक जानकारी के लिए, जुनिपर प्लेटफ़ॉर्म गाइड और NETCONF प्रलेखन देखें ।

cli_command और cli_config

• cli_command - अपने कमांड लाइन इंटरफ़ेस (यदि वहाँ है) का उपयोग करके नेटवर्क उपकरणों पर एक कमांड चलाता है।
• cli_config - network_cli के माध्यम से नेटवर्क उपकरणों के लिए पाठ विन्यास (धक्का) भेजता है।

Cli_command और cli_config मॉड्यूल जो कि अंसिबल इंजन 2.7 में दिखाई देते हैं, वे भी किसी विशेष निर्माता के उपकरण से बंधे नहीं हैं और विभिन्न नेटवर्क प्लेटफार्मों को स्वचालित करने के लिए उपयोग किया जा सकता है। वे वांछित cliconf प्लगइन का उपयोग करने के लिए चर ansible_network_os (इन्वेंट्री फ़ाइल में सेट या group_vars फ़ोल्डर में) के मूल्य पर आधारित हैं। प्रलेखन में ansible_network_os चर के सभी मूल्यों की एक सूची प्रदान की गई है। Ansible के इस संस्करण में, आप अभी भी विशिष्ट प्लेटफार्मों के लिए पुराने मॉड्यूल का उपयोग कर सकते हैं, इसलिए अपना समय मौजूदा प्लेबुक को फिर से लिखने के लिए लें। अधिक जानकारी के लिए, आधिकारिक पोर्टिंग गाइड देखें ।



आइए देखें कि इन मॉड्यूल का उपयोग Ansible Playbook में कैसे किया जाता है। यह प्लेबुक IOS-XE पर चलने वाले दो सिस्को क्लाउड सर्विसेज रूटर्स (CSR) सिस्टम पर चलेगी। इन्वेंट्री फ़ाइल में ansible_network_os चर ios पर सेट है।

 <config snippet from inventory> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios 

यहां बताया गया है कि कैसे cli_config और cli_command का उपयोग किया जाता है:

 --- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout 

और यहाँ इस प्लेबुक का आउटपुट है:

 [user@rhel7 ~]$ ansible-playbook cli.yml PLAY [AGNOSTIC PLAYBOOK] ********************************************* TASK [CONFIGURE DNS] ************************************************* ok: [rtr1] ok: [rtr2] TASK [CHECK CONFIGURATION] ******************************************* ok: [rtr1] ok: [rtr2] TASK [PRINT OUTPUT TO SCREEN] **************************************** ok: [rtr1] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } ok: [rtr2] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } PLAY RECAP ********************************************************** rtr1 : ok=3 changed=0 unreachable=0 failed=0 rtr2 : ok=3 changed=0 unreachable=0 failed=0 

कृपया ध्यान दें कि जब तक आप संबंधित नेटवर्क उपकरणों के लिए उपयुक्त सिंटैक्स का उपयोग नहीं करते तब तक ये मॉड्यूल निष्क्रिय हैं।

बेहतर आंसर टॉवर इंटरफ़ेस

Red Hat Ansible Tower 3.3 में वेब इंटरफ़ेस अधिक सुविधाजनक और कार्यात्मक हो गया है, जिससे विभिन्न कार्यों को करते समय कम क्लिक की अनुमति मिलती है।



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

Ansible टॉवर में नेटवर्क उपकरणों के लिए क्रेडेंशियल्स प्रबंधित करें

Red Hat Ansible Tower 3.3 नेटवर्क उपकरणों के लिए लॉगिन पासवर्ड का प्रबंधन करना बहुत आसान बनाता है। नए वेब इंटरफ़ेस में, क्रेडेंशियल कमांड मुख्य मेनू में संसाधन समूह में तुरंत स्थित है।



Ansible टॉवर 3.3 ने एक विशेष तथाकथित "नेटवर्क" प्रकार का क्रेडेंशियल (नेटवर्क) छोड़ा, जो पर्यावरण चर ANSIBLE_NET_USERNAME और ANSIBLE_NET_PASSWORD पुराने प्रदाता विधि में उपयोग किया जाता है। यह सब अभी भी काम करता है, जैसा कि दस्तावेज में लिखा गया है, ताकि आप मौजूदा Ansible Playbooks स्क्रिप्ट का उपयोग कर सकें। हालाँकि, httpapi और network_cli को जोड़ने के नए उच्च-स्तरीय तरीकों के लिए, नेटवर्क क्रेडेंशियल प्रकार की अब आवश्यकता नहीं है, क्योंकि Ansible पासवर्ड लॉगिन के साथ समान रूप से काम करता है। नेटवर्क उपकरणों से कनेक्ट हो रहा है, और लिनेक्सू होस्ट से कनेक्ट होने पर। इसलिए, नेटवर्क उपकरणों के लिए, अब आपको मशीन क्रेडेंशियल प्रकार का चयन करने की आवश्यकता है - बस इसे चुनें और अपना लॉगिन पासवर्ड दर्ज करें या एसएसएच कुंजी प्रदान करें।



नोट: आपके द्वारा क्रेडेंशियल्स को सहेजने के तुरंत बाद, Ansible टॉवर पासवर्ड को एन्क्रिप्ट करता है।



एन्क्रिप्शन के लिए धन्यवाद, क्रेडेंशियल्स को अन्य उपयोगकर्ताओं और समूहों को सुरक्षित रूप से सौंपा जा सकता है - वे बस पासवर्ड नहीं देखेंगे या पहचान नहीं पाएंगे। क्रेडेंशियल्स कैसे काम करते हैं, क्या एन्क्रिप्शन का उपयोग किया जाता है, और अधिक विश्वसनीय प्रकार (जैसे अमेज़ॅन एडब्ल्यूएस, माइक्रोसॉफ्ट एज़्योर , और Google जीसीई) के बारे में अधिक जानकारी के लिए, Ansible टॉवर प्रलेखन में पाया जा सकता है।

Red Hat Ansible Tower 3.3 का अधिक विस्तृत विवरण यहां पाया जा सकता है ।

एक ही समय में टॉवर में Ansible के विभिन्न संस्करणों का उपयोग करना

मान लें कि हम चाहते हैं कि कुछ प्लेबुक अंसिबल इंजन 2.4.2 के माध्यम से चलें, और अन्य अंसिबल इंजन 2.6.4 के माध्यम से चलें। टॉवर में परस्पर निर्भरता और विभिन्न संस्करणों के साथ संघर्ष से बचने के लिए पायथन सैंडबॉक्स बनाने के लिए एक विशेष वर्चस्व टूल है। Ansible टॉवर 3.3 आपको विभिन्न स्तरों पर वर्चुअलाइजेशन सेट करने की अनुमति देता है - संगठन, परियोजना या नौकरी टेम्पलेट। अपने नेटवर्क का बैकअप लेने के लिए हमने Ansible Tower में जो जॉब टेम्पलेट बनाया है, वह ऐसा दिखता है।



जब आपके पास कम से कम दो आभासी वातावरण होते हैं, तो Ansible पर्यावरण पॉप-अप मेनू Ansible टॉवर मुख्य मेनू में दिखाई देता है, जहां आप आसानी से निर्दिष्ट कर सकते हैं कि कार्य करते समय Ansible के किस संस्करण का उपयोग किया जाना चाहिए।



इसलिए, यदि आपके पास नेटवर्क को स्वचालित करने के लिए playbooks का मिश्रण है, जिनमें से कुछ पुराने प्रदाता विधि (Ansible 2.4 और पिछले संस्करण) का उपयोग करते हैं, और कुछ नए httpapi या network_cli प्लगइन्स (Ansible 2.5 और उच्चतर) का उपयोग करते हैं, तो आप आसानी से प्रत्येक कार्य को असाइन कर सकते हैं। उत्तर देने योग्य संस्करण। इसके अलावा, यह सुविधा उपयोगी होगी यदि डेवलपर्स और उत्पादन Ansible के विभिन्न संस्करणों का उपयोग करते हैं। दूसरे शब्दों में, आप सुरक्षित रूप से टॉवर को अपडेट कर सकते हैं, बिना इस बात की चिंता किए कि उसके बाद आपको किसी भी एक संस्करण को अंसिबल इंजन में बदलना होगा, जो विभिन्न प्रकार के नेटवर्क उपकरण और वातावरण, साथ ही उपयोग परिदृश्यों को स्वचालित करने में लचीलापन बढ़ाता है।

Virtualenv का उपयोग करने के बारे में अधिक जानकारी के लिए, दस्तावेज़ देखें।