I’ve been tinkering with automation utilities since the beginning of the year, and have gradually plummeted down the slippery slope of YAML configs and trigger-action rules. And I don’t just mean the automation workflows on Home Assistant, Node-RED, and other smart home management tools, either. I came across Ansible while working on a DevOps project during my uni days, and the tool really fascinated me.

Fast-forward a couple of months, and I’d created multiple Ansible Playbooks to configure my virtual machines, LXCs, Docker containers, and everything in between – without requiring any manual input whatsoever! These days, I’m so deep into the Ansible rabbit hole that I’ve added most of the nodes and virtual guests in my home lab to my hosts file just so I don't have to set everything up manually.

Ansible can automate the most boring tasks

And it’s pretty versatile, too

Since I work on home server projects extensively, I spin up new virtual machines and containers on my virtualization platforms. And when it comes to working with DevOps projects, I often end up provisioning multiple virtual guests. If I were to configure them manually, it would take me an hour or two at the very least. Combine that with all the devices I have to review, and you can see why I find manually configuring apps, creating users, and modifying network settings a royal pain.

That’s where Ansible comes in handy with its powerful automation provisions. Instead of setting up everything myself, Ansible lets me define Playbooks to configure my VMs and containers. Better yet, it’s just as effective for bare-metal systems, as all it needs is an IP address and a couple of login credentials to pair with my devices. Plus, Ansible’s flexible nature lets me use it for typical maintenance tasks, including updating packages and backing up essential files.

I can hoard multiple Playbooks and schedule them per my needs

Ansible is just the automation engine on its own, so it needs instructions detailing all the processes I wish to automate. Playbooks are the YAML configs that contain this code, and are responsible for all the wizardry Ansible is capable of. The best part? I can keep multiple Playbooks for all my tasks and execute them as I see fit.

Plus, Ansible pairs really well with schedulers. In my early automation days, I relied on a combination of Ansible and Cron scripts to run maintenance-oriented Playbooks at regular intervals. But these days, I use Semaphore instead (and I’ll talk more about this tool in a bit).

Ansible Playbooks aren’t all that difficult to set up, either

The syntax is way easier than I expected

Considering that I was mostly familiar with the trigger-action workflow of Home Assistant at the beginning of my Ansible journey, I was worried I’d have to learn complex syntax just to create basic Playbooks. Luckily, Ansible uses YAML configs, and its Playbook parameters and arguments are really easy to pick – far more so than the ones used by its companion, Terraform.

For a completely barebones setup, I need two files: a typical YAML document containing the operation details and an inventory file detailing the hostnames/IP addresses of the devices where I want to run the Playbooks. The inventory file’s syntax is as simple as the name of the group in square brackets followed by the IP address or hostname in the subsequent lines. Meanwhile, the general code for a Playbook includes the name of the task, the group name of the hosts (from the inventory file), a privilege escalation parameter (typically become: yes), and then the actual operation.

Let’s say I want to set up Darktable, Krita, LibreOffice, and a bunch of other essential FOSS apps on a mini-PC I want to review. Well, I can just add the names of the apps under the ansible.builtin.apt module (or ansible.builtin.p_m, where p_m is the package manager that ships with the distro) in a Playbook – something like this (with the right indentation, of course):

---
- name: Package installation
 hosts: all
 become: true
 tasks:
 - name: Install typical productivity apps
 apt:
 name: 
 - emacs
 - krita
 - libreoffice
 state: latest
 update_cache: true

I also use third-party tools to manage my Ansible artifacts

Although managing a couple of Ansible Playbooks is simple, organizing multiple inventory files, variable groups, and credentials can get rather cumbersome from a terminal interface, especially when your home lab is as much of an unorganized mess as mine. I initially relied on a Debian VM to house all my Ansible artifacts, but quickly pivoted to a Semaphore-based LXC setup.

Technically, Semaphore locks some features behind a paywall, but the essential facilities like managing config files and scheduling Playbooks are available in the free version of the tool. UI-wise, it’s easy to get used to Semaphore, and I typically create my Playbooks using Visual Studio Code before transferring them to the LXC. Better yet, Ansible supports a plethora of cool modules that let me use APIs, parse Terraform files, and even spin up virtual guests using Playbooks on typical virtualization platforms like Proxmox.