Ansible: Automatic state

Before I set up VyOS, I had the urge to learn Ansible, as it should work perfectly with anything CLI. However, this was the reason why it took almost a month to set up my network. I had to learn Ansible, figure out its quirks, find out that VyOS collection was poorly written, and that I didn’t understand Ansible until I’ve tinkered with it for a long while.

But don’t get me wrong, Ansible is good. My first playbook made it possible to update all my services, no matter what package manager they have, nor where they are located. (apt/apk/pacman/dnf/zypper for package managers; VM/CT/bare for services) By then I only had manually set up my main account to have a key used for SSH. I later extended this into a bootstrap playbook that on some services created a new ansible user that only has a key for access and can only be reachable from the ansible container. Neat.

But before that bootstrap, I wanted to tinker more with my network, as that was a big thorn at my side, having several services (router; firewall; DNS; DHCP; port forwarding) that doesn’t know about each other, yet they should as they relate to each for the whole network to function properly. Luckily, VyOS had its own collection, but the sad part is that most functionality I use I had to manually configure anyway. I therefore made a jinja filter to convert yaml to VyOS config. Added all services, grouped them together into neat piles, and added specific information for each one of them. Finally I created three roles, one for the router, one for the piholes and finally one for prometheus. The router group would then generate configs for VyOS that related to routing, firewall, port forwarding and DHCP. The pihole included DNS, not only internal DNS, but also external for those services that is located on the intranet. Everything is then updated each time I run the playbook. The prometheus is just putting the hosts in config files for prometheus to parse.

While this took some time to set up, it makes it a lot easier to fix stuff in the future. The best part is that if I ever decide to move from one system to an another, I can either recreate all the things I did before, as the playbooks are basically documentation, but I can also easily switch to some other software if necessary. Ansible may have exclusive collections for a specific system, but as long as you got variables, and hosts, you can easily switch between them with less tinkering than one normally would.

For instance, I’m trying to set up a playbook that handles my web server in a smarter manner. This could reduce my previous 5 min adding a domain, to less than a minute. It’s also easier to verify that everything works with Ansible as well.

I’m still not done , though. Ansible got so much potential that it wont cover my whole infrastructure for an another year.