Plugins are pieces of code that augment(அதிகப்படுத்து) Ansible’s core functionality.
Ansible uses a plugin architecture to enable a rich, flexible and expandable feature set.
Ansible ships with several handy plugins, and you can easily write your own.
This section covers the various types of plugins that are included with Ansible:
- Action plugins
- Become plugins
- Cache plugins
- Callback plugins
- Cliconf plugins
- Connection plugins
- Docs fragments
- Filter plugins
- Httpapi plugins
- Inventory plugins
- Lookup plugins
- Modules
- Module utilities
- Netconf plugins
- Shell plugins
- Strategy plugins
- Terminal plugins
- Test plugins
- Vars plugins
Action plugins act in conjunction with modules to execute the actions required by playbook tasks. They usually execute automatically in the background doing prerequisite work before modules execute.
The ‘normal’ action plugin is used for modules that do not already have an action plugin. If necessary, you can create custom action plugins.
You can enable a custom action plugin by either dropping it into the action_plugins directory adjacent to your play, inside a role, or by putting it in one of the action plugin directory sources configured in ansible.cfg.
Action plugins are executed by default when an associated module is used; no additional action is required.
Become plugins
The --become-method command line option, you can use the become_method keyword in a play or, if you need to be ‘host specific’, the connection variable ansible_become_method to select the plugin to use.
Cache plugins allow Ansible to store gathered facts or inventory source data without the performance hit of retrieving them from the source.
You can use different cache plugins for inventory and facts. If you enable inventory caching without setting an inventory-specific cache plugin, Ansible uses the fact cache plugin for both facts and inventory.
Callback plugins
Callback plugins enable adding new behaviors to Ansible when responding to events. By default, callback plugins control most of the output you see when running the command line programs
There are three types of callback plugins:
- stdout callback plugins:
- aggregate callback plugins:
- notification callback plugins:
stdout callback plugins: These plugins handle the main console output. Only one can be active. They always get the event first; the rest of the callbacks get the event in the order they are configured.
aggregate callback plugins: Aggregate callbacks can add additional console output next to a stdout callback. This can be aggregate information at the end of a playbook run, additional per-task output, or anything else.
notification callback plugins:Notification callbacks inform other applications, services, or systems. This can be anything from logging to databases, informing on errors in Instant Messaging applications, or sending emails when a server is unreachable.
Cliconf plugins
Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices.
These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ansible_network_os variable.
Connection plugins
Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time.
By default, Ansible ships with several connection plugins. The most commonly used are the paramiko SSH, native ssh (just called ssh), and local connection types. All of these can be used in playbooks and with /usr/bin/ansible to decide how you want to talk to remote machines. If necessary, you can create custom connection plugins. To change the connection plugin for your tasks, you can use the connection keyword.
The basics of these connection types are covered in the getting started section.
ssh plugins
Because SSH is the default protocol used in system administration and the protocol most used in Ansible, SSH options are included in the command line tools.
You can set the connection plugin globally with configuration, at the command line (-c, --connection), as a keyword in your play, or by setting a variable, most often in your inventory. For example, for Windows machines, you might want to set the winrm plugin as an inventory variable.
ansible_host
The name of the host to connect to, if different from the inventory hostname.
ansible_port
The ssh port number, for ssh and paramiko_ssh it defaults to 22.
ansible_user
The default username to use for log in. Most plugins default to the ‘current user running Ansible’.
Docs fragments
Docs fragments allow you to document common parameters of multiple plugins or modules in a single place.
Filter plugins
Filter plugins manipulate data.
With the right filter, you can extract a particular value, transform data types and formats, perform mathematical calculations, split and concatenate strings, insert dates and times, and do much more. Ansible uses the standard filters shipped with Jinja2 and adds some specialized filter plugins.
Httpapi plugins
Httpapi plugins tell Ansible how to interact with a remote device’s HTTP-based API and execute tasks on the device.
Inventory plugins
Inventory plugins allow users to point at data sources to compile the inventory of hosts that Ansible uses to target tasks, either using the -i /path/to/file and/or -i 'host1, host2' command line parameters or from other configuration sources.
aggregate callback plugins: Aggregate callbacks can add additional console output next to a stdout callback. This can be aggregate information at the end of a playbook run, additional per-task output, or anything else.
notification callback plugins:Notification callbacks inform other applications, services, or systems. This can be anything from logging to databases, informing on errors in Instant Messaging applications, or sending emails when a server is unreachable.
Cliconf plugins
Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices.
These plugins generally correspond one-to-one to network device platforms. Ansible loads the appropriate cliconf plugin automatically based on the ansible_network_os variable.
Connection plugins
Connection plugins allow Ansible to connect to the target hosts so it can execute tasks on them. Ansible ships with many connection plugins, but only one can be used per host at a time.
By default, Ansible ships with several connection plugins. The most commonly used are the paramiko SSH, native ssh (just called ssh), and local connection types. All of these can be used in playbooks and with /usr/bin/ansible to decide how you want to talk to remote machines. If necessary, you can create custom connection plugins. To change the connection plugin for your tasks, you can use the connection keyword.
The basics of these connection types are covered in the getting started section.
ssh plugins
Because SSH is the default protocol used in system administration and the protocol most used in Ansible, SSH options are included in the command line tools.
You can set the connection plugin globally with configuration, at the command line (-c, --connection), as a keyword in your play, or by setting a variable, most often in your inventory. For example, for Windows machines, you might want to set the winrm plugin as an inventory variable.
ansible_host
The name of the host to connect to, if different from the inventory hostname.
ansible_port
The ssh port number, for ssh and paramiko_ssh it defaults to 22.
ansible_user
The default username to use for log in. Most plugins default to the ‘current user running Ansible’.
Docs fragments
Docs fragments allow you to document common parameters of multiple plugins or modules in a single place.
Filter plugins
Filter plugins manipulate data.
With the right filter, you can extract a particular value, transform data types and formats, perform mathematical calculations, split and concatenate strings, insert dates and times, and do much more. Ansible uses the standard filters shipped with Jinja2 and adds some specialized filter plugins.
Httpapi plugins
Httpapi plugins tell Ansible how to interact with a remote device’s HTTP-based API and execute tasks on the device.
Inventory plugins
Inventory plugins allow users to point at data sources to compile the inventory of hosts that Ansible uses to target tasks, either using the -i /path/to/file and/or -i 'host1, host2' command line parameters or from other configuration sources.
Most inventory plugins shipped with Ansible are enabled by default or can be used with the auto plugin.
[inventory]
enable_plugins = host_list, script, auto, yaml, ini, toml
Lookup plugins
Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks.
vars:
file_contents: "{{ lookup('file', 'path/to/file.txt') }}"
Modules
Modules are the main building blocks of Ansible playbooks. Although we do not generally speak of “module plugins”, a module is a type of plugin. For a developer-focused description of the differences between modules and other plugin
You can enable a custom module by dropping it into one of these locations:
any directory added to the ANSIBLE_LIBRARY environment variable ($ANSIBLE_LIBRARY takes a colon-separated list like $PATH)
~/.ansible/plugins/modules/
/usr/share/ansible/plugins/modules/
Module utilities
Module utilities contain shared code used by multiple plugin
Netconf plugins
Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices.
Shell plugins
Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks.
Strategy plugins
Strategy plugins control the flow of play execution by handling task and host scheduling.
export ANSIBLE_STRATEGY=free
ansible.cfg
[defaults]
strategy=linear
- hosts: all
strategy: debug
Terminal plugins
Terminal plugins contain information on how to ensure that a particular network device’s SSH shell is properly initialized to be used with Ansible. This typically includes disabling automatic paging, detecting errors in output, and enabling privileged mode if the device supports and requires it.
Test plugins
Test plugins evaluate template expressions and return True or False. With test plugins you can create conditionals to implement the logic of your tasks, blocks, plays, playbooks, and roles. Ansible uses the standard tests shipped as part of Jinja and adds some specialized test plugins
vars:
is_ready: '{{ task_result is success }}'
tasks:
- name: conditionals are always in 'template' context
action: dostuff
when: task_result is failed
- name: pass a positional parameter to match test
action: dostuff
when: myurl is match("https://example.com/users/.*/resources")
Vars plugins
Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like ‘host_vars’ and ‘group_vars’ work using vars plugins. For more details about variables in Ansible
[inventory]
enable_plugins = host_list, script, auto, yaml, ini, toml
Lookup plugins
Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other services) within your playbooks.
vars:
file_contents: "{{ lookup('file', 'path/to/file.txt') }}"
Modules
Modules are the main building blocks of Ansible playbooks. Although we do not generally speak of “module plugins”, a module is a type of plugin. For a developer-focused description of the differences between modules and other plugin
You can enable a custom module by dropping it into one of these locations:
any directory added to the ANSIBLE_LIBRARY environment variable ($ANSIBLE_LIBRARY takes a colon-separated list like $PATH)
~/.ansible/plugins/modules/
/usr/share/ansible/plugins/modules/
Module utilities
Module utilities contain shared code used by multiple plugin
Netconf plugins
Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface for Ansible to execute tasks on those network devices.
Shell plugins
Shell plugins work to ensure that the basic commands Ansible runs are properly formatted to work with the target machine and allow the user to configure certain behaviors related to how Ansible executes tasks.
Strategy plugins
Strategy plugins control the flow of play execution by handling task and host scheduling.
export ANSIBLE_STRATEGY=free
ansible.cfg
[defaults]
strategy=linear
- hosts: all
strategy: debug
Terminal plugins
Terminal plugins contain information on how to ensure that a particular network device’s SSH shell is properly initialized to be used with Ansible. This typically includes disabling automatic paging, detecting errors in output, and enabling privileged mode if the device supports and requires it.
Test plugins
Test plugins evaluate template expressions and return True or False. With test plugins you can create conditionals to implement the logic of your tasks, blocks, plays, playbooks, and roles. Ansible uses the standard tests shipped as part of Jinja and adds some specialized test plugins
vars:
is_ready: '{{ task_result is success }}'
tasks:
- name: conditionals are always in 'template' context
action: dostuff
when: task_result is failed
- name: pass a positional parameter to match test
action: dostuff
when: myurl is match("https://example.com/users/.*/resources")
Vars plugins
Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like ‘host_vars’ and ‘group_vars’ work using vars plugins. For more details about variables in Ansible
No comments:
Post a Comment