Ansible Tricks
Some Useful Ansible tricks
Including a playbook
I am working on extending my automation to do some new things. We refresh test environments from production. Previously we used to copy all the code from production back to development. Now we build the VMs from scratch, so we don’t need to do this any more, but it would be convenient to call the VM build in the middle of the refresh.
You can easily call a playbook from another one using import_playbook
. This makes the playbook work in the same way as if it was run.
See the documentation for the difference between include and import.
Starting at a particular task.
When developing a playbook, it is useful to be able to start off from where it failed. I typically have a silly error in a play which I notice as soon as it fails. So long as all the tasks are named uniquely, I can run the following:
|
|
The role can be included as well, in case two roles have the same task in:
|
|
This is the same format Ansible prints out the task name on the screen.
Sometimes the error is caused by an error in a script that was deployed by a previous step. In that case, obviously once the script is corrected the playbook needs to be restarted from the step that deploys the script.
Timings and profiling.
Often I would like to see how long something took. If the playbook takes a long time to run, it is useful
to see what the slowest plays are. To discover this, simply put the following in ansible.cfg
|
|
Ansible Configuration File
I am not the sysadmin to my management server, and even though I know the root password
I don’t want to step on anyone’s toes by changing ansible.cfg
for everyone.
It turns out that putting ansible.cfg
into the same path as the playbook means it is
read and overrides the default, so no need to mess with anyone elses settings, or
even to become root.
Viewing stdout of command/shell/script
When testing anisble playbooks, it is often useful to be able to see the stdout of commands to see what is going wrong. To do this call ansible with a single -v
|
|
Human readable output
Once the above is done, the output is sent to the screen in a json format. It would be nice to get something formatted as it came out of the script.
Here is how:
|
|
Weird Error
I got the following error running a playbook:
This happened because the become
user didn’t exist, because I had missed out running
the part that created it. It is reasonable for it to fail, but the error isn’t very clear.
Hopefully this will help someone in the future (Probably me!)