clarify httpapi with an example (#65083)
This commit is contained in:
parent
b2fc12a29f
commit
7084dd727a
2 changed files with 26 additions and 2 deletions
|
@ -9,7 +9,7 @@ Network automation leverages the basic Ansible concepts, but there are important
|
|||
Execution on the Control Node
|
||||
================================================================================
|
||||
|
||||
Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad-hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs.
|
||||
Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad-hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs.
|
||||
|
||||
Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory.
|
||||
|
||||
|
@ -27,13 +27,16 @@ Because network modules execute on the control node instead of on the managed no
|
|||
"httpapi", "API over HTTP/HTTPS", "network_os setting", "yes"
|
||||
"local", "depends on provider", "provider setting", "no"
|
||||
|
||||
.. note::
|
||||
``httpapi`` deprecates ``eos_eapi`` and ``nxos_nxapi``. See :ref:`httpapi_plugins` for details and an example.
|
||||
|
||||
Beginning with Ansible 2.6, we recommend using one of the persistent connection types listed above instead of ``local``. With persistent connections, you can define the hosts and credentials only once, rather than in every task. For more details on using each connection type on various platforms, see the :ref:`platform-specific <platform_options>` pages.
|
||||
|
||||
|
||||
Modules Organized by Network Platform
|
||||
================================================================================
|
||||
|
||||
A network platform is a set of network devices with a common operating system that can be managed by a collection of modules. The modules for each network platform share a prefix, for example:
|
||||
A network platform is a set of network devices with a common operating system that can be managed by a collection of modules. The modules for each network platform share a prefix, for example:
|
||||
|
||||
- Arista: ``eos_``
|
||||
- Cisco: ``ios_``, ``iosxr_``, ``nxos_``
|
||||
|
|
|
@ -32,6 +32,27 @@ Most httpapi plugins can operate without configuration. Additional options may b
|
|||
Plugins are self-documenting. Each plugin should document its configuration options.
|
||||
|
||||
|
||||
The following sample playbook shows the httpapi plugin for an Arista network device, assuming an inventory variable set as ``ansible_network_os=eos`` for the httpapi plugin to trigger off:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- 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"]
|
||||
|
||||
See the full working example at https://github.com/network-automation/httpapi.
|
||||
|
||||
.. _httpapi_plugin_list:
|
||||
|
||||
Plugin List
|
||||
|
|
Loading…
Reference in a new issue