Ansible at Home
Some years ago, I started managing my home machines using Ansible, an effort that continues to this day.
The first thing I did, naturally, was to set up an inventory of machines, organized into various classes, like desktop vs. laptop, operating system family, and the like.
The first mistake I made, as I later found out, was to spend all that time setting up classes. That would have been very useful in a large-scale environment, or even a small company with 30 employees, where you want to say “Set up all the Linux machines this way. Set up all the back-end servers this way”. But at home? Every one of my machines is a one-off, a special snowflake, so there’s very little benefit to be had from trying to group hosts into classes. I wound up making one playbook per host, nothing fancy, and that works just fine.
The big advantage, for me, is that this system provides a record of how my machines are set up, and just as importantly, why. Why did I install Inkscape? Did I just want to noodle with drawing pictures, or was that a prerequisite for some other project I was working on? So if I nuke it, will I miss it later? By the same token, if there’s some package I don’t recognize, I can just nuke it, and Ansible will reinstall it if it turns out to be needed.
I said above that it doesn’t help to organize machines into classes, because each one is a unique snowflake. But as it turns out, there are things I want to do everywhere. Things like Emacs config, or installing the Firefox plugins I want to use.
These are the things that roles are made for. So even though each machine is a unique snowflake, there are parts of their configuration that can be copied, and then you can just use that role in each machine’s playbook.
If you wind up with a lot of common tasks that don’t seem big enough to turn into roles, you can also set up a more traditional common.yml playbook for whichever bits of configuration are shared between hosts.
And finally, the big question is: is it worth it? Well, for me it is. At least, I haven’t given up. Your mileage may vary. I find that it keeps things tidy. If I wonder why something is set up some way, I can look at the Ansible directory and its editing history in git and see what I was thinking at the time. On the down side, there’s extra work involved in making any change.
It’s particularly worth it if you regularly need to make changes, whether it’s because you set up new machines all the time (I have an Ansible config for setting up a new Raspberry Pi). Also, Apple has a habit of overwriting /etc/auto_master with every OS upgrade and breaking my automounts. So being able to just run ansible-playbook= to fix it is very handy.