5 Things You (Maybe) Didn’t Know About Ansible
Ansible is a really flexible and powerful automation tool that can be used in many different environments that may not fit your preconceived notions of Ansible as an SSH-based tool to configure Linux and Unix systems. Here are a few other things that you can do with Ansible, and a few ways to further customize and configure how your automation works.
1. Ansible can be used to manage more than just servers
Many Ansible playbooks are used for configuring and managing servers. Cloud servers, database servers, etc. But, Ansible can also manage anything with an SSH interface or an API. For example, there are modules that communicate to load balancers from the cloud platforms, F5 load balancers, and other networking equipment. Such modules are genuinely useful for tasks such as multi-server rolling upgrades or other complicated orchestration activities that require collaboration with the wider networking community.
2. You can mix on-premise and cloud inventories easily
You are probably familiar with Ansible files for the product. Those are simple text files which define your hosts inventory. Typically they do look like this:
[webservers]
foowebserver1
foowebserver2
foowebserver3
[dbservers]
db1
Ansible also has a collection of cloud inventory outlets to automatically access Amazon ‘s latest server list, Aws, Rackspace, and more. But what if you have a mixed environment? You can create a directory, say, named inventory/ and bring together both static inventory files (like above) and cloud inventory scripts, and run your playbooks against the mixed inventory by defining the name of the directory as the inventory file. Ansible Tower also has built-in mechanisms to handle mixing cloud and static inventory.
4. Ansible can be used to manage Windows machines
One of the extra link plugins ansible developed enables you to run Windows PowerShell scripts, using the WinRM protocol. They wanted to add Windows support to Ansible but they didn’t want to allow Windows administrators on the controlled machines to do unnatural things like installing Python and SSH on them. Anisble also has a small but growing Windows Modules library.
5. Ansible has a rich plugin infrastructure
There are many ways to stretch Ansible. Writing a custom module is the most common way, but there are also a range of interesting Python plugin interfaces that you can use to create custom behavior beyond just modules:
Dynamic Inventory Sources: You can easily write a custom inventory plugin to pull hosts and groups directly from your current database, whether you have a custom CMDB or another source of truth about your environment.
Callback Plugins: Callback plugins are highly powerful and can be used to trigger notifications such as posting messages to chat tools, signal monitoring events, or reacting flexibly to any event during playbook running.
If you find yourself in your playbooks dealing with complicated data structures, you may want to look into custom filter plugins or lookup plugins. Both allow you to manipulate data in different ways (limited by Python only!) and can greatly simplify your playbook by offloading logic to a small Python plugin. A lot of the popular Jinja2 filters and iterators are implemented as plugins that you probably use every day.
All of these plugins are going to work with Tower, too!
6. You have a lot of control over how a playbook runs
Playbooks always run from top to bottom in Ansible, which is fine once your playbook is fully tested and in production. But what about the development process? It is sometimes convenient to skip certain sections of a playbook, or to go through your tasks one by one to examine the results of a live system. You can do this with a few advisable-playbook command-line options. You can use playbook tags for more permanent ways to fine-tune which tasks run and which do not.
Conclusion
Hopefully these tips and tricks have shown you a few more interesting ways to use and extend Ansible.
