Ansible is a very flexible and extensible automation tool, and it can be used in a lot of 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 you can do with Ansible, and a few ways to further customize and configure how your automation works. I hope these tips are useful! If you have any of your own to share, feel free to send us a tweet @ansible!
1. Ansible can be used to manage more than just servers
Most Ansible playbooks are used to configure and manage servers. Web servers, database servers, and so on. But anything with an SSH interface or an API can be managed with Ansible, too. For example we have modules to talk to cloud platforms, Citrix NetScaler and F5 load balancers, and other networking equipment. These modules are really helpful for tasks like multi-server rolling upgrades or other complicated orchestration tasks that need coordination with your broader networking environment.
You can also implement custom connection plugins for those really weird or legacy devices. There are a number of lesser-known ones shipped with Ansible, including methods to “connect to” a chroot environment and LXC containers. (Kermit connection plugin, anyone?)
2. You can mix on-premise and cloud inventories easily
You’re probably familiar with Ansible inventory files. They are simple text files describing your inventory of hosts. They usually look like this:
Ansible also has a series of cloud inventory sources to dynamically retrieve the latest list of servers from Amazon, Azure, Rackspace, and more. But what if you have a mixed environment? You can create a directory, say, called inventory/ and put both static inventory files (like above) and cloud inventory scripts together, and run your playbooks against the mixed inventory, by specifying the directory name as your inventory file.
Ansible Tower also has built-in mechanisms to handle mixing cloud and static inventory.
3. You can write playbooks in JSON (if you really want to!)
We chose YAML as the text file format for Ansible playbooks because it’s easily readable and writable by both humans and machines: it’s a nice middle ground that remains 100% machine parsable but not too verbose and structured for general consumption like, say, XML. But, because JSON is a subset of YAML, you can write playbooks in JSON format as well! Here’s a simple playbook in YAML:
And here’s the equivalent playbook in JSON:
Personally, I think YAML is easier to work with than JSON, but this feature may have some interesting possibilities if you are dynamically generating playbooks or playbook content for some reason. Your mileage may vary!
4. Ansible can be used to manage Windows machines
One of the extra connection plugins that we’ve built allows you to run PowerShell scripts on Windows, using the WinRM protocol. We wanted to add Windows support to Ansible but we didn’t want to require Windows admins to do unnatural things like install Python and SSH on the managed machines. We have a small but growing library of Windows modules, too.
5. Ansible has a rich plugin infrastructure
There are a lot of ways to extend Ansible. The most common way is to write a custom module, but there are also a series of interesting Python plugin interfaces that you can use to build custom behavior beyond just modules:
-
Dynamic Inventory Sources: If you have a custom CMDB or another source of truth about your environment, you can easily write a custom inventory plugin to pull hosts and groups directly from your existing database.
-
Callback Plugins: Callback plugins are very powerful, and can be used to trigger notifications such as posting messages to chat tools, signal monitoring events, or react in flexible ways to basically any event during a playbook run.
-
If you find yourself dealing with complicated data structures in your playbooks, you may want to look into custom filter plugins or lookup plugins. Both allow you to manipulate data in various ways (limited only by Python!) and can greatly simplify your playbook by offloading logic to a small Python plugin. A lot of the common Jinja2 filters and iterators you probably use every day are implemented as plugins.
All of these plugins will work with Tower, as well!
6. You have a lot of control over how a playbook runs
Playbooks always run from the top to the bottom in Ansible, which is fine once your playbook is fully tested and running in production. But what about during development? It is sometimes convenient to skip certain sections of a playbook, or step through your tasks one by one to examine the results on a live system. You can do this with a couple of ansible-playbook command-line options.
For more permanent ways to fine-tune which tasks run and which don’t, you can use playbook tags.
Conclusion
Hopefully these tips and tricks have shown you a few more interesting ways to use and extend Ansible.
