Ansible Lessons Learned
I’ve been automating the installation of a Brocade SDN Controller high-availability cluster with 6-nodes, this is essentially Opendaylight Boron wrapped in a Linux init script. My full deployment script took about 10 minutes to run and 5 minutes to build the VMs I was installing on, so when my automation task to start the application was failing the wait time between test results was killing me. The frustrating part with the application was that logging into the server and typing ‘sudo service my-app start’ would get things going right away. So, after going through the shell, command, and raw ansible modules without much success I started looking at the init service itself. Had the application developers missed something when they wrote the init script?
Long story short when the application is installed the systemd unit files are not updated. So, when I was trying to trigger service to start, ansible was not detecting the new unit as something that could be targeted. By configuring ‘daemon_reload’ systemd will ‘refresh’ the unit files detecting new services before it tries to execute the task!
- For custom applications, do a systemd daemon reload after installation.
systemd: state: started daemon_reload: yes name: my-app
- There are alot of files to manage. Git makes alot of sense here!
- It feels quite a bit like configuring something on the CLI. After you wrap your head around the YAML syntax that is.
- There is an ansible module for most of the linux things you do, so do alittle bit of homework before wrapping everything in a ‘shell execute-my-script’ task.