Thanks to Brian Coca, Josh Drake, and some minor fiddling from myself, I’m pleased to announce the 1.8 development branch now has the popular “fact caching” feature implemented and is ready for testing.
What is fact caching?
Well, it’s a pretty basic feature, but Ansible’s fundamental architecture of not having a server meant we didn’t address this for some time.
Imagine you have webservers and database servers.
All the webservers need to know about all the IPs from the database servers.
Previously, to get this, a playbook would have to do this:
-
hosts: dbservers
tasks: -
hosts: webservers
tasks: -
template: …
Now, this can be run as two seperate playbooks, ONCE fact caching is so configured, because the results of a prior play can be saved.
What variables are saved? All facts and all registered variables, with a configurable timeout.
To enable this, in the [defaults] section of ansible.cfg, set the following:
[defaults]
fact_caching=redis
Redis is currently the only thing I want to support until this feature “bakes in” a bit, and I have suspicions this will be the only thing fast enough.
You will need to install Redis, and by default, the support for this is such that no passwords
are used and it must be running locally on your Ansible machine. This will change
over time, I’m sure, to be more configurable.
Documentation for this is pending, but it fits a fair number of use cases including:
- If you have 50 distributed datacenters, it’s not neccessary to ping every single machine you own to get facts and information about another
- Have a datastore of what all the values for a thing on host X was when it was last talked to
The result of enabling fact caching is potentially much shorter playbook runs, or playbook runs that can set variables that inform other playbook runs.
In simple cases, you might not need it.
There will be documentation on this pending soon, but I wanted to indicate that this was now merged in and ready for testing.
Thanks Brian and Josh for a lot of hard work in getting this going.
–Michael