Chapter 10: Extending Ansible

It must be said that Ansible takes the kitchen sink approach to functionality and tries to provide, out of the box, every piece of functionality you might ever need. With the ansible-core package and its associated collections, there are almost 6,000 modules available for use within Ansible at the time of writing – compare that to the (roughly) 800 that were included when the second edition of this book was published! In addition to these, there is a rich plugin and filter architecture with numerous callback plugins, lookup plugins, filter plugins, and dynamic inventory plugins included. Now, collections provide a whole new vector through which new functionality can be provided.

Despite this, there will always be cases where Ansible doesn't quite perform the tasks required, especially in large and complex environments, or ones where bespoke in-house systems have been developed. Luckily, the design of Ansible, coupled with its open source...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do – for those interested in the specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 LTS unless stated otherwise and on Ansible 4.3. The example code that accompanies this chapter can be downloaded from GitHub at https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter10.

Check out the following video to see the code in action: https://bit.ly/3DTKL35.

Developing modules

Modules are the workhorse of Ansible. They provide just enough abstraction so that playbooks can be stated simply and clearly. There are over 100 modules and plugins maintained by the core Ansible development team and they are distributed as part of the ansible-core package, covering commands, files, package management, source control, system, utilities, and so on. In addition, there are nearly 6,000 other modules maintained by community contributors that expand functionality in many of these categories and many others, such as public cloud providers, databases, networking, and so on, through collections. The real magic happens inside the module's code, which takes in the arguments that are passed to it and works to establish the desired outcome.

Modules in Ansible are the pieces of code that get transported to the remote host to be executed. They can be written in any language that the remote host can execute; however, Ansible provides some very useful shortcuts...

Developing plugins

Plugins are another way of extending or modifying the functionality of Ansible. While modules are executed as tasks, plugins are utilized in a variety of other places. Plugins are broken down into a few types, based on where they would plug into the Ansible execution. Ansible ships some plugins for each of these areas, and end users can create their own to extend the functionality of these specific areas.

Connection-type plugins

Any time Ansible makes a connection to a host to perform a task, a connection plugin is used. Ansible ships with a few connection plugins, including ssh, community.docker.docker, local, and winrm. Additional connection mechanisms can be utilized by Ansible to connect to remote systems by creating a connection plugin, which may be useful if you must connect to some new type of system, such as a network switch, or perhaps your refrigerator someday. To create a new connection plugin, we would have to understand and work with an underlying...

Developing dynamic inventory plugins

Inventory plugins are bits of code that will create inventory data for an Ansible execution. In many environments, the simple ini file-style inventory source and variable structure are not sufficient for representing the actual infrastructure being managed. In such cases, a dynamic inventory source is desired, one that will discover the inventory and data at runtime at every execution of Ansible. A number of these dynamic sources ship with Ansible, primarily to operate Ansible with the infrastructure built into one cloud computing platform or another. A short, incomplete list of dynamic inventory plugins that ship with Ansible 4.3 (there are now over 40) includes the following – note from the FQCNs that many of these that were once shipped as part of the Ansible 2.x releases are now being included as part of the wider set of collections that form Ansible 4.3:

• azure.azcollection.azure_rm
• community.general.cobbler
• community...

Contributing to the Ansible project

Not all modifications need to be for local site requirements. Ansible users will often identify an enhancement that could be made to the project that others would benefit from. These enhancements can be contributed via a collection, and in the new structure of Ansible that proceeds from version 3.0, this is likely to be the most suitable route for most people. In this case, you will be able to follow the guidance given in Chapter 2, Migrating from Earlier Ansible Versions, to build and release a collection. However, what if you develop the next killer plugin or filter that should be added to the ansible-core project itself? In this section, we'll look at how you can do this. Contributions could be in the form of updates to an existing built-in module or core Ansible code, updates to documentation, new filters or plugins, or simply testing proposed contributions from other community members.

Contribution submissions

The Ansible project...

Summary

Ansible is a great tool; however, sometimes, it doesn't offer all the functionality you might desire. Not every bit of functionality is appropriate to submit to the ansible-core project, nor is it possible to provide bespoke integration with custom proprietary data sources, as these would be different in every case. As a result, there are many facilities within Ansible to extend its functionality. Creating and using custom modules is made easy by the shared module base code. Many different types of plugins can be created and used with Ansible to affect operations in a variety of ways. Inventory sources beyond those provided with the Ansible release collections can still be used with relative ease and efficiency.

In this chapter, you learned about developing modules and including them in your playbooks. You then learned about extending Ansible through plugins, and we went into specific details about creating dynamic inventory plugins. Finally, you learned how to contribute...

Questions

1. For Ansible releases after 3.0, you would almost always develop a new module and distribute it via which of the following?

   a) The ansible-core project.

   b) Your collection.

   c) An existing collection with overlapping functionality, with the project maintainer's approval.

   d) A role.

   e) b, c, and maybe d only

2. The easiest way to develop a custom module is to write it in what language?

   a) Bash

   b) Perl

   c) Python

   d) C++

3. Providing facts from a custom module does what?

   a) Saves you from needing to register the output to a variable and then using set_fact.

   b) Gives your code greater capabilities.

   c) Helps you debug your code.

   d) Shows you how the module is running.

4. Callback plugins allow you to do what?

   a) Help you call other playbooks.

   b) Easily alter the behavior of Ansible at key operational points without having to alter the ansible-core code.

   c) Provide an efficient means of altering the code's state.

   d) Help you to call back to your playbook during runtime.

5. To distribute...