I'm not the best at remembering to back up my home lab, mainly because it doesn't tend to stay in one piece long enough. But I've been trying to work more automation into things, so that spinning up containers and VMs is auto, and I can focus on the things I want to do with them.

I've been playing with automation tools and realized I can automate my entire network with Ansible. Its powerful YAML-based scripting language is quick to pick up, and I can cobble bits together from wherever I find them on the internet, because that's how the playbooks work, as a declarative list of what (and in what order) you want to do. And since I'm about to upgrade to Ubiquiti hardware, I'll be able to set things up once, write out the Ansible playbooks I need, and then nothing I do should keep me away from running some scripts and getting back to working order.

Infrastructure as Code is fantastic

Make sure your network setup is the same, every time

I'm my own worst nightmare when it comes to breaking things, fixing them again, then breaking them later when I haven't documented the fix. That's okay if the pages are in my browser history, but what if I can't remember them or they've gone to the dreaded 404? If I set things up in Ansible while I'm setting up the hardware, I'll have a jumping-off point if I need to do disaster recovery.

Think of it as writing out company policies that are going to train the new intern. Except in this case, they're more of a "how we do things" instead of a "why we do them this way." In some ways, Ansible playbooks are better than traditional backups, because they take less space, and don't require anything more complicated than Notepad to open and read.

I can save VLAN rules, firewall rules, anything that I set up on my network stack. And that can be a lot of data over time, as anyone who's spent time fine-tuning rule sets knows. Plus, I can put in plugin installation and setup, or anything else that can be done via SSH on my hardware.

It doesn't work with every network appliance

Ansible supports a wide range of networking gear, but some devices might not work as intended. That's not going to be an issue with my hardware, but outdated SDK's like Meraki's could be an issue, as could any older hardware from the big networking companies that otherwise work fine. If they only work with Telnet it just means more scripting, but I don't want to be using insecure connections on my network anyway. It's pretty quick to check whether your hardware is compatible, and the community has plenty of options to browse.

Setting some sane ground rules

Disorder in, disorder out

Eventually, I'll have Ansible playbooks for every aspect of my home lab and home network, including Proxmox hosts, their contents, and any other servers I have set up. For now, I'll be focusing on the network equipment, because that's going to be more than enough to get on with.

I'll be using Ansible roles to make management easier on myself, so each role is in charge of associated tasks, variables, handlers, and templates in reusable units arranged in sane folders:

roles/
├── network_base/
│ ├── tasks/main.yml # SSH config, NTP, SNMP setup
│ ├── handlers/main.yml # Service restart handlers
│ ├── templates/
│ │ ├── ntp.conf.j2
│ │ └── snmp.conf.j2
│ ├── vars/main.yml # NTP pools, SNMP communities
│ └── defaults/main.yml # Override-safe defaults
├── vlan_config/
│ ├── tasks/
│ │ ├── main.yml
│ │ └── create_vlans.yml # Separate concerns
│ └── vars/main.yml
├── firewall_rules/
│ ├── tasks/main.yml
│ ├── templates/rules.j2 # Jinja2-rendered rule templates
│ └── vars/main.yml
└── container_networking/
 ├── tasks/main.yml # netplan, network bridges
 └── templates/netplan.j2

This is partly to make editing and updates easier, and partly to make it harder to duplicate efforts, as tasks are clearly segregated. I'll be saving everything (except Ansible vault for secrets) to a Git repository for version control, and I'll share my progress as I do, because someone will likely find it helpful, and there aren't a ton of recent resources for UniFi gear.

Some Ubiquiti-specifics

Ubiquiti hasn't always supported Ansible on all its devices, or should I say used an OS that Ansible can talk to as expected. But that's changed with newer appliances, and anything running UniFi OS Server should be fine (at least, as far as I can tell). But if not, I can still use the self-hosted container version of UniFi OS Server, which includes the UniFi Controller, which is what I need.

Here's the YAML to log into the UniFi Controller with Ansible:

- name: Provisioning (Authenticating) uri: url: https://unifi.REDACTED.local:8443/api/login method: POST validate_certs: false body_format: json body: '{"username": "Sfascia17", "password": "REDACTED"}' register: logincookie

Technically, it's called UniFi OS Server because it's now a complete self-hosted stack for all UniFi control apps, but only a few are available right now. The only one we really need is the controller app, and that's part of the installation. Once we've set up SSH so Ansible can log in, we can tell the UniFi OS Server to handle the rest of our stack however we want.

For example, we can make the USG provision a new config.gateway.json file:

- name: uri: url: https://unifi.REDACTED.local:8443/api/s/default/cmd/devmgr method: POST validate_certs: false body_format: json body: '{"mac":"xx:xx:xx:xx:xx:xx","cmd":"force-provision"}' headers: Cookie: "{{ logincookie.cookies_string }}"

And keeping the config files alongside the Ansible playbooks reduces the risk of setting drift, because I'll always be editing from the same stack of files. It does seem that newer equipment, like what I'm about to set u,p can be poked with Ansible directly, so this inventory tool to map out the network is one of the first things I'll be testing.

I hope I don't mess up a command

The thing about powerful automation tools like Ansible is that, umm, they're powerful. Running the wrong playbook can take your whole network offline, but hopefully you're not in charge of a countrywide WAN like that poor hapless sysadmin. Pushing the wrong file would temporarily nuke my setup, but I'll still have physical access so I can use a serial cable if the worst comes to it, and push a known good settings file from before I destroyed the running one.

Ansible is now firmly part of my home network

I don't particularly enjoy setting things up the first time, even when they're new and shiny. I enjoy it even less the 50th time, and now I can run a script to do it for me. The next thing for me to check is how to automate installing the programs and files I use when testing laptops, because that is an incredibly tedious process, and I'd rather offload it to some CPU cycles.