鉴于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 Tower Web界面。
- 使用网络设备时，在Ansible Tower中管理凭据。
- 同时使用Tower中不同版本的Ansible
不要忘记，每个新版本的Ansible都会伴随着
移植指南的更新，这将极大地促进向新版本的过渡。
HTTPAPI连接插件
连接插件使Ansible能够连接到目标主机，然后在目标主机上执行任务。 从Ansible 2.5开始，出现了一个名为network_cli的新类型的插件。 它消除了使用提供程序参数的需要，并标准化了网络模块的执行顺序，因此，现在可以执行，执行和使用与Linux主机的手册相同的方式使用网络设备的手册。 反过来，对于Ansible Tower，网络设备和主机之间的差异消失了，并且不再需要区分网络设备和机器的用户名和密码。
此处对此进行了更详细的讨论，但是总之，现在可以类似的方式使用和存储Linux服务器和交换机Arista EOS或Cisco路由器的登录密码。
在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交换机后，show management api http-commands命令将显示该API已启用：
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和net_put
net_get和net_put模块不与任何特定制造商的设备绑定，而是仅使用标准SCP或SFTP传输协议（由协议参数指定）将文件从网络设备复制到设备。 这两个模块都需要使用network_cli连接方法，并且仅在控制器上安装了scp（pip install scp）并且在网络设备上启用了SCP或SFTP时才起作用。
我们假设在剧本示例中，我们已经在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（网络配置协议）是由IETF开发和标准化的。 根据RFC 6241，NETCONF可用于安装，操作和删除网络设备配置。 NETCONF是SSH命令行（network_cli）和API（例如Cisco NX-API或Arista eAPI（httpapi））的替代方法。
为了演示新的netconf模块，我们首先使用
junos_netconf模块在Juniper路由器上启用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" ] }
瞻博网络为
操作标签和
配置标签提供了Junos XML API Explorer。 考虑瞻博网络在其
文档中用于说明特定接口的RPC请求的操作请求示例。
<rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>
它很容易翻译成Ansible Playbook。 get-interface-information是RPC调用，其他参数指定为键值对。 在此示例中，只有一个参数-interface-name-，而在我们的网络设备上，我们只想查看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>>>
有关更多信息，请参见《
Juniper平台指南》和
NETCONF文档 。
cli_command和cli_config
出现在Ansible Engine 2.7中的cli_command和cli_config模块也不与特定制造商的设备捆绑在一起，可用于自动运行各种网络平台。 它们基于变量ansible_network_os的值（在清单文件或group_vars文件夹中设置）来使用所需的cliconf插件。
文档中提供了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
请注意，只要您为相应的网络设备使用适当的语法，这些模块就是
幂等的 。
改进的Ansible塔式界面
Red Hat Ansible Tower 3.3中的Web界面变得更加便捷和功能强大，在执行各种任务时可以减少点击次数。
凭证管理，任务计划程序，清单脚本，基于角色的访问控制，通知等等，现在都收集在屏幕左侧的主菜单中，只需单击一下即可使用。 Jobs View作业查看屏幕立即显示重要的附加信息：谁启动了任务以及何时启动； 在实施过程中开发了哪些清单； 该剧本来自哪个项目。
管理Ansible Tower中网络设备的凭据
红帽Ansible Tower 3.3使管理网络设备的登录密码变得更加容易。 在新的Web界面中，“凭据”命令位于主菜单的“资源”组中。
Ansible Tower 3.3留下了一种特殊的所谓的“网络”凭证类型（网络），它设置了旧提供程序方法中使用的环境变量ANSIBLE_NET_USERNAME和ANSIBLE_NET_PASSWORD。 正如
文档中所述，所有这些仍然有效，因此您可以使用现有的Ansible Playbooks脚本，但是，对于新的高级连接方法httpapi和network_cli，不再需要网络凭据类型，因为Ansible现在与密码登录一样可以使用连接到网络设备，等等。 因此，对于网络设备，您现在需要选择计算机凭据类型-只需选择它并输入您的登录密码或提供SSH密钥即可。
注意：Ansible Tower在保存凭据后立即加密密码。
借助加密，可以将凭据安全地委派给其他用户和组-他们根本看不到或无法识别密码。 有关凭证如何工作，使用哪种加密以及其他哪些凭证类型（例如Amazon AWS，Microsoft Azure和Google GCE）的更多信息，可以在
Ansible Tower文档中找到 。
可以在
此处找到有关Red Hat Ansible Tower 3.3的详细说明。
同时使用Tower中不同版本的Ansible
假设我们希望一些剧本通过Ansible Engine 2.4.2运行，而另一些则通过Ansible Engine 2.6.4运行。 Tower有一个特殊的virtualenv工具，用于创建Python沙箱，以避免与冲突的依赖项和不同版本发生冲突。 Ansible Tower 3.3允许您在不同级别（组织，项目或作业模板）设置virtualenv。 这就是我们在Ansible Tower中创建的用于备份网络的作业模板。
当您拥有至少两个虚拟环境时，Ansible Environment下拉菜单将出现在Ansible Tower主菜单中，您可以在其中轻松指定执行任务时应使用哪个版本的Ansible。
因此，如果您有多种混合使用的手册来实现网络自动化，其中一些使用旧的提供者方法（Ansible 2.4和以前的版本），而另一些使用新的httpapi或network_cli插件（Ansible 2.5及更高版本），则可以轻松分配每个任务Ansible版本。 此外，如果开发人员和生产人员使用不同版本的Ansible，则此功能将很有用。 换句话说，您可以安全地更新Tower，而不必担心之后必须切换到任何版本的Ansible Engine，这大大增加了自动化各种类型的网络设备和环境以及使用场景的灵活性。
有关使用virtualenv的更多信息，请参阅
文档 。