I have run into a few cases where I have to make a change to a running service (e.g., iptables and BIND) using a command line tool (iptables, nsupdate). This case is different from the more normal (for me): change config file, upload changed file, restart or reload service. Changing a running service using a special tool to insert deltas means I begin collecting small changes almost like a version control system. Making these small changes in Ansible is easy. What I’m struggling with is how best to manage this use case in a formal way with Ansible.
I’d like to hear how other Anisble users are addressing this. How do you keep everything consistent when you have a conf file and you are making small direct changes (named.conf vs nsupdate)? What kind of playbook do you use for nsupdate like changes?
Thanks,
Aaron
How I have managed configurations depends on the changes that I’ve made…
I have replaced files wholesale with entire new files in some cases, sometimes using templates, sometimes not…I have used “lineinfile” to edit configuration files when that approach seemed more useful.
In some cases I’ve used modules that can talk to the service/file I needed (crontab for example).
If I had to deal with a system that provided certain commands to manage the configuration then I would consider writing a module for that particular utility (look someone else might have already done that for you).
If it was only a single change then I would probably just use command to insert the one change I needed…
In your case you could possibly use command (or shell) and with_items to repetitively make changes based on a list you keep of the changes that you want made… It looks like nsupdate takes input on standard in, or from files, so you either create a file consisting of a sequence of lines and then run that through nsupdate or use shell
- name: Update the named service
shell: echo {{ item.command }} | nsupdate
with_items: nsupdatecommands
and in your variables file something like this
nsupdatecommands:
-
{ command: ‘update 1’,
comment: ‘This does something’ }
-
{ command: ‘update 2’,
comment: ‘This does something else’ }
In this case the item.comment isn’t actually used, it’s there to make it easier to annotate the list of commands… If you don’t want it then you can get rid of that. If you wanted more sub elements you could add them…
Of course, that’s just me, but that gives you a fairly compact task and a list of arguments that make the actual changes.
If you were to later write an nsupdate module then you could (with minor formatting changes probably) keep the same command list and pass that into the nsupdate module…
Adam