Developing Plugins

    This section will explore these features, though they are generally not common in terms of things people would look to extend quiteas often.

    By default, ansible ships with a ‘paramiko’ SSH, native ssh (just called ‘ssh’), ‘local’ connection type, and there are also some minor players like ‘chroot’ and ‘jail’. All of these can be usedin playbooks and with /usr/bin/ansible to decide how you want to talk to remote machines. The basics of these connection typesare covered in the 新手上路 section. Should you want to extend Ansible to support other transports (SNMP? Message bus?Carrier Pigeon?) it’s as simple as copying the format of one of the existing modules and dropping it into the connection pluginsdirectory. The value of ‘smart’ for a connection allows selection of paramiko or openssh based on system capabilities, and chooses‘ssh’ if OpenSSH supports ControlPersist, in Ansible 1.2.1 an later. Previous versions did not support ‘smart’.

    More documentation on writing connection plugins is pending, though you can jump into and figure things out pretty easily.

    Lookup Plugins

    Language constructs like “with_fileglob” and “with_items” are implemented via lookup plugins. Just like other plugin types, you can write your own.

    More documentation on writing lookup plugins is pending, though you can jump into lib/ansible/plugins/lookup and figurethings out pretty easily.

    Playbook constructs like ‘host_vars’ and ‘group_vars’ work via ‘vars’ plugins. They inject additional variabledata into ansible runs that did not come from an inventory, playbook, or command line. Note that variablescan also be returned from inventory, so in most cases, you won’t need to write or understand vars_plugins.

    If you find yourself wanting to write a vars_plugin, it’s more likely you should write an inventory script instead.

    Filter Plugins

    If you want more Jinja2 filters available in a Jinja2 template (filters like to_yaml and to_json are provided by default), they can be extended by writing a filter plugin. Most of the time, when someone comes up with an idea for a new filter they would like to make available in a playbook, we’ll just include them in ‘core.py’ instead.

    Jump into for details.

    Callbacks are one of the more interesting plugin types. Adding additional callback plugins to Ansible allows for adding new behaviors when responding to events.

    Example callbacks are shown in lib/ansible/plugins/callback.

    The callback is an example of how to intercept playbook events to a logfile, and the mailcallback sends email when playbooks complete.

    To activate a callback drop it in a callback directory as configured in ansible.cfg.

    More information will come later, though see the source of any of the existing callbacks and you should be able to get started quickly.They should be reasonably self-explanatory.

    Distributing Plugins

    Plugins are loaded from both Python’s site_packages (those that ship with ansible) and a configured plugins directory, which defaultsto /usr/share/ansible/plugins, in a subfolder for each plugin type:

    To change this path, edit the ansible configuration file.

    In addition, plugins can be shipped in a subdirectory relative to a top-level playbook, in folders named the same as indicated above.

    See also

    • List of built-in modules
    • Python API
    • Learn about how to develop dynamic inventory sources
    • Developing Modules
    • Learn about how to write Ansible modules
    • The development mailing list

    • ansible IRC chat channel