Ansible is an infrastructure management tool. You have an “inventory” with your hosts and what kinds of hosts they are (‘webserver’, ‘database’), combined with a “playbook” that tells what to do with what kind of host.
They started with mapping the various manual deployment steps to ansible tasks. A playbook would just be a list of tasks that call shell scripts. This was wrong. A task would always result in a change.
Another big problem? Ansible’s check mode (or diff mode) would not work. A shell script cannot be simulated, so “check” will skip it.
The solution? Use proper ansible modules. Modules can mostly check the state and determen what should be done. You can write your own modules, which means writing python code. This means you can also properly test your code (which is harder to do with shell scripts).
He showed some example code, including code for checking whether something would change. And with a test playbook for testing the module.
A common problem is that ansible doesn’t know if something changed in your application: does it need to be restarted or not? The “solution” is often to always restart your application (or nginx or so).
The cause for this problem is that there is configuration outside of ansible that ansible doesn’t know about. The solution is obvious: move all configuration to ansible. That way, ansible will know whether something changed and can restart the application if necessary.
You want only one management source of configuration.
ansible-playbook --check --diffshould always work.
The slides are at https://github.com/blue-yonder/documents
Photo explanation: picture from our recent cycling holiday (NL+DE). Wesel, where the Lippe flows into the Rhein.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):