ميزات جديدة أتمتة الشبكة في القبعة الحمراء Ansible

في ضوء التحسينات الكبيرة التي تم تنفيذها في Ansible Engine 2.6 ، فضلاً عن مراعاة إصدار Ansible Tower 3.3 والإصدار الأخير من Ansible Engine 2.7 ، دعونا نلقي نظرة فاحصة على آفاق أتمتة الشبكة.



في هذا المنشور:

• اتصال Httpapi البرنامج المساعد.
  • دعم Arista eAPI و Cisco NX-API.
• وحدات أتمتة الشبكة الجديدة.
  • net_get و net_put.
  • netconf_get و netconf_rpc و netconf_config.
  • cli_command و cli_config.
• تحسين واجهة الويب برج Ansible.
• إدارة بيانات الاعتماد في برج Ansible عند العمل مع أجهزة الشبكة.
• استخدام إصدارات مختلفة من Ansible في Tower في نفس الوقت

لا تنس أن إصدار كل إصدار جديد من Ansible مصحوبًا بتحديث إلى دليل النقل ، مما سيسهل بشكل كبير الانتقال إلى الإصدار الجديد.

اتصال HTTPAPI المساعد

مكوّنات التوصيل هي ما يمكّن Ansible من الاتصال بالمضيفين المستهدفين ثم القيام بالمهام عليهم. بدءًا من Ansible 2.5 ، ظهر مكون إضافي جديد من هذا النوع يسمى network_cli. إنها تلغي الحاجة إلى استخدام معلمة الموفر وتقيِّم ترتيب تنفيذ وحدات الشبكة ، ونتيجة لذلك يتم الآن تنفيذ وتنفيذ قواعد التشغيل الخاصة بأجهزة الشبكة وتنفيذها بنفس طريقة تشغيل playbooks لمضيفي Linux. بدوره ، بالنسبة إلى برج Ansible ، يختفي الفرق بين أجهزة الشبكة والمضيفين ، ولم يعد بحاجة إلى التمييز بين أسماء المستخدمين وكلمات المرور لأجهزة الشبكة وللآلات. نوقش هذا بمزيد من التفاصيل هنا ، ولكن باختصار ، يمكن الآن استخدام كلمات مرور تسجيل الدخول لخادم Linux وتبديل Arista EOS أو Cisco router بطريقة مماثلة.

في Ansible 2.5 ، كان الاتصال عبر أساليب eAPI و NX-API ممكنًا فقط باستخدام طريقة الموفر القديمة. لم يعد لدى Ansible 2.6 هذا القيد ويمكنك استخدام طريقة اتصال httpapi عالية المستوى بحرية. دعونا نرى كيف يتم ذلك.

يجب عليك أولاً تمكين eAPI أو NX-API على جهاز الشبكة حتى تتمكن من استخدام طريقة httpapi. يتم ذلك بسهولة بواسطة فريق Ansible المناسب ، على سبيل المثال ، فيما يلي كيفية تمكين eAPI على مفتاح Arista EOS.

[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 حقيقي ، فإن أمر show إدارة api http-commands سيظهر أن واجهة برمجة التطبيقات ممكنة:

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

سيناريو Ansible Playbook أدناه ينفّذ ببساطة أمر show version ، ثم في قسم debug يُرجع الإصدار فقط من إخراج 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 إصدارات مختصرة من الأوامر (مثل "show ver" بدلاً من "show version2)" ، لذا يجب عليك كتابتها جميعًا. لمزيد من المعلومات حول البرنامج المساعد للاتصال httpapi ، راجع الوثائق.

وحدات أتمتة الشبكة الجديدة

يقدم Ansible 2.6 والإصدار 2.7 الصادر في أكتوبر سبع وحدات جديدة لأتمتة الشبكة.

• net_get - نسخ ملف من جهاز شبكة إلى Ansible Controller.
• net_put - نسخ ملف من Ansible Controller إلى جهاز شبكة.
• netconf_get - يسترجع بيانات التكوين / الحالة من جهاز شبكة مع تمكين NETCONF.
• netconf_rpc - يؤدي عمليات على جهاز شبكة مع تمكين NETCONF.
• netconf_config - تكوين جهاز netconf ، تسمح الوحدة للمستخدم بإرسال ملف XML إلى أجهزة netconf والتحقق من تغير التكوين.
• cli_command - يقوم بتشغيل الأمر cli على أجهزة الشبكة التي لها واجهة أمر (cli).
• cli_config - يرسل (نص) تكوين النص إلى أجهزة الشبكة عبر network_cli.

net_get و net_put

• net_get - نسخ ملف من جهاز شبكة إلى Ansible Controller.
• net_put - نسخ ملف من Ansible Controller إلى جهاز شبكة.

لا ترتبط وحدات net_get و net_put بأجهزة أي مُصنِّع معين ، وببساطة تنسخ الملفات من جهاز الشبكة إلى الأجهزة التي تستخدم بروتوكولات نقل SCP أو SFTP القياسية (المحددة بواسطة معلمة البروتوكول). تتطلب كلتا الوحدتين استخدام طريقة اتصال network_cli ، كما تعمل فقط إذا تم تثبيت scp (نقطة تثبيت scp) على وحدة التحكم وتم تمكين SCP أو SFTP على جهاز الشبكة.

نفترض أنه في المثال مع playbook لدينا ، قمنا بالفعل بتنفيذ الأمر التالي على جهاز Leaf01:

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

إليك ما يبدو عليه كتاب قواعد اللعبة ذي المهمتين (الأول ينسخ الملف من جهاز Leaf01 ، والثاني ينسخ الملف إلى جهاز Leaf01):

 --- - 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 ، تسمح الوحدة للمستخدم بإرسال ملف XML إلى أجهزة netconf والتحقق من تغير التكوين.

بروتوكول إدارة الشبكة تم تطوير NETCONF (بروتوكول تكوين الشبكة) وتوحيده بواسطة IETF. وفقًا لـ RFC 6241 ، يمكن استخدام NETCONF لتثبيت تكوينات جهاز الشبكة ومعالجتها وحذفها. NETCONF هو بديل لسطر الأوامر SSH (network_cli) وواجهات برمجة التطبيقات مثل Cisco NX-API أو Arista eAPI (httpapi).

لإظهار وحدات netconf الجديدة ، نقوم أولاً بتمكين netconf على أجهزة التوجيه Juniper باستخدام الوحدة النمطية junos_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" ] } 

تقدم Juniper Networks مستكشف Junos XML API لعلامات التشغيل ولعلامات التكوين . اطلع على مثال طلب التشغيل الذي تستخدمه Juniper Networks في وثائقها لتوضيح طلب 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 

بعد بدء playbook ، نحصل على هذا:

 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>>> 

لمزيد من المعلومات ، راجع دليل منصة Juniper ووثائق NETCONF .

cli_command و cli_config

• cli_command - يقوم بتشغيل أمر على أجهزة الشبكة باستخدام واجهة سطر الأوامر الخاصة بهم (إذا كان هناك واحد).
• cli_config - يرسل (نص) تكوين النص إلى أجهزة الشبكة عبر network_cli.

كما أن وحدات cli_command و cli_config التي ظهرت في Ansible Engine 2.7 ليست مرتبطة أيضًا بأجهزة شركة معينة ويمكن استخدامها لأتمتة منصات الشبكات المختلفة. وهي تستند إلى قيمة المتغير ansible_network_os (المعين في ملف المخزون أو في مجلد group_vars) لاستخدام البرنامج المساعد cliconf المطلوب. يتم توفير قائمة بكافة قيم متغير ansible_network_os في الوثائق . في هذا الإصدار من Ansible ، لا يزال بإمكانك استخدام الوحدات القديمة لأنظمة تشغيل معينة ، لذلك خذ وقتك لإعادة كتابة كتب اللعب الحالية. لمزيد من المعلومات ، راجع أدلة النقل الرسمية .



دعونا نرى كيف يتم استخدام هذه الوحدات في Ansible Playbook. سيتم تشغيل كتاب اللعب هذا على نظامي Cisco Cloud Services Routers (CSR) يشغّلان IOS-XE. يتم تعيين متغير 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 

وهنا إخراج هذا playbook:

 [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 

يرجى ملاحظة أن هذه الوحدات هي idempotent طالما كنت تستخدم بناء الجملة المناسب لأجهزة الشبكة المقابلة.

تحسين واجهة برج Ansible

أصبحت واجهة الويب في Red Hat Ansible Tower 3.3 أكثر ملاءمة ووظيفية ، مما يسمح بنقرات أقل عند أداء المهام المختلفة.



يتم الآن جمع إدارة بيانات الاعتماد ، وجدولة المهام ، البرامج النصية للمخزون ، التحكم في الوصول المستند إلى الأدوار ، الإخطارات وغير ذلك الكثير في القائمة الرئيسية على الجانب الأيسر من الشاشة وهي متوفرة بنقرة واحدة. تعرض شاشة عرض الوظائف Job Jobs الإضافية فورًا معلومات إضافية مهمة: من الذي بدأ المهمة ومتى ؛ ما المخزون الذي تم تطويره أثناء تنفيذه ؛ ما المشروع الذي تم الحصول عليه من playbook.

إدارة بيانات الاعتماد لأجهزة الشبكة في برج Ansible

Red Hat Ansible Tower 3.3 يسهل إدارة كلمات مرور تسجيل الدخول لأجهزة الشبكة. في واجهة الويب الجديدة ، يوجد أمر مؤهلات الاعتماد مباشرةً في القائمة الرئيسية ، في مجموعة الموارد.



ترك Ansible Tower 3.3 نوعًا خاصًا يسمى "الشبكة" من بيانات الاعتماد (الشبكة) ، والذي يحدد متغيرات البيئة ANSIBLE_NET_USERNAME و ANSIBLE_NET_PASSWORD المستخدمة في أسلوب الموفر القديم. كل هذا لا يزال يعمل ، كما هو مكتوب في الوثائق ، بحيث يمكنك استخدام البرامج النصية Ansible Playbooks الموجودة ، ومع ذلك ، بالنسبة للطرق الجديدة عالية المستوى لربط httpapi و network_cli ، لم تعد هناك حاجة لنوع بيانات اعتماد الشبكة ، حيث يعمل Ansible الآن بالتساوي مع تسجيلات كلمة المرور كما هو الحال مع الاتصال بأجهزة الشبكة ، وذلك عند الاتصال بمضيفي Linxu. لذلك ، بالنسبة لأجهزة الشبكة ، تحتاج الآن إلى تحديد نوع بيانات اعتماد الجهاز - ما عليك سوى تحديده وإدخال كلمة مرور تسجيل الدخول أو توفير مفتاح SSH.



ملاحظة: برج Ansible بتشفير كلمة المرور مباشرة بعد حفظ بيانات الاعتماد.



بفضل التشفير ، يمكن تفويض بيانات الاعتماد بأمان إلى المستخدمين والمجموعات الأخرى - فهم ببساطة لن يروا كلمة المرور أو يتعرفون عليها. لمزيد من المعلومات حول كيفية عمل بيانات الاعتماد ، وما هو التشفير المستخدم ، وما أنواع بيانات الاعتماد الأخرى (مثل Amazon AWS و Microsoft Azure و Google GCE) التي يمكن العثور عليها في وثائق Ansible Tower .

يمكن الاطلاع هنا على مزيد من التفاصيل حول Red Hat Ansible Tower 3.3.

استخدام إصدارات مختلفة من Ansible في Tower في نفس الوقت

لنفترض أننا نريد تشغيل بعض قواعد اللعب من خلال Ansible Engine 2.4.2 ، والبعض الآخر من خلال Ansible Engine 2.6.4. يحتوي Tower على أداة virtualenv خاصة لإنشاء صناديق بيثون الرملية لتجنب التعارض مع التبعيات المتعارضة والإصدارات المختلفة. يتيح لك Ansible Tower 3.3 ضبط virtualenv على مستويات مختلفة - التنظيم أو المشروع أو قالب الوظيفة. هذا هو ما يشبه قالب الوظيفة الذي أنشأناه في Ansible Tower لعمل نسخة احتياطية لشبكتنا.



عندما يكون لديك بيئتان ظاهرتان على الأقل ، تظهر القائمة المنسدلة "بيئة Ansible" في القائمة الرئيسية لـ Ansible Tower ، حيث يمكنك بسهولة تحديد إصدار Ansible الذي يجب استخدامه عند تنفيذ المهمة.



لذلك ، إذا كان لديك مزيج من قواعد التشغيل لأتمتة الشبكة ، حيث يستخدم بعضها طريقة الموفر القديم (Ansible 2.4 والإصدارات السابقة) ، ويستخدم البعض مكونات إضافية httpapi أو network_cli (Ansible 2.5 وما فوق) ، يمكنك بسهولة تعيين كل مهمة نسخة غير صالحة. بالإضافة إلى ذلك ، ستكون هذه الميزة مفيدة إذا استخدم مطورو البرامج والإنتاج إصدارات مختلفة من Ansible. بمعنى آخر ، يمكنك تحديث البرج بأمان ، دون الحاجة إلى القلق بعد ذلك ، سيتعين عليك التبديل إلى أي إصدار واحد من محرك Ansible ، مما يزيد بشكل كبير من المرونة في أتمتة أنواع مختلفة من معدات الشبكات والبيئات ، وكذلك سيناريوهات الاستخدام.

لمزيد من المعلومات حول استخدام virtualenv ، راجع الوثائق .