I’m in the middle of a server redo - right now, I’m setting up a replacement server for my trusty Dell T30, plus it was time to give this web server a new home. When I started the migration from my old WordPress site to the new static site, the static site was running on a small 1 core / 1GB RAM cloud server at Vultr. That had enough oomph for testing and for the last couple of months. That said, this machine is running FreeBSD with ZFS on root, and ZFS likes to have a lot of RAM. Why ZFS on root? Because it allows me to use boot environments. I’ve started using them on my other servers - especially the aforementioned home server - and decided that all my other servers also need them right now as it makes upgrading the OS a lot safer.

As a result, I wanted to rebuild this VM on a cloud instance with NVMe drive and 2GB of RAM, which requires a rebuild of the server as Vultr currently doesn’t support migrating “normal” instances to NVMe-backed instances.

Instead of doing it all by hand, I decided to pull the relevant configuration files down from the old server and build an Ansible script to configure the server fully once I created the instance manually?

Why the manual creation? Well, as mentioned I want to set up the server as ZFS on Root, and Vultr’s FreeBSD image still uses UFS. As a result I ended up setting up the VM by hand and then pointing Ansible at the basic, running VM. That worked quite well and ensured that all of the required configurations made it over. It’s still not a fully automated configuration because I have to manually build NGINX. FreeBSD’s default nginx-devel port doesn’t include Brotli support, and I prefer to run the server with Brotli support so I have to manually build NGINX. Which is not a big deal - configure the port and then let FreeBSD’s port system do its work.

So why am I calling this “making my server a bit less of a pet”? Well, there is this thinking that production servers should be treated more like a herd of cattle that a pet or your favourite potted plant that needs a lot of attention. I don’t plan to run enough server that I need to fully subscribe to this approach, but being anble to relatively quickly regenerate the web server setup to the extent that all I have to do is spin up a new cloud server/VM somewhere, point the Ansible script at it and then sync the static websites, plus copy over the ISSO database for the comments. Now that it’s set up, it’s pretty quick to recreate the server. Still not quite as easy as I would like it to be, but much easier overall and of course all the configuration files are now in version control as well. The second advantage is that the script doesn’t contain any Vultr-specific code, so if I ever decide to move the server somewhere else, the script is still reusable. Not that I have any plans to do that as I’m happy with the service at Vultr.

Some additional, random notes

• If you’re trying to a fully automated setup of FreeBSD boxes on Vulter an you’re not that interested in ZFS boot environments, use the Vultr image for FreeBSD 13. That already comes with Python preinstalled so you don’t have to manually install Python just to be able to use Ansible, and as a result should be able to script up the whole instantiation process of the server in Ansible and thus eliminate a bunch of the manual work my setup requires.
• I’m a long time user of both FreeBSD and OpenBSD. That’s why I keep using them for server-type installations, and Ansible works reasonably well for at least FreeBSD - I’ve yet to try OpenBSD, although I’ll probably try that soon. I’ve done some work with Ansible and Linux servers, and it feels to me like the Linux support is smoother and a bit more fully featured, but I’ve yet to encounter something on a FreeBSD machine that I wasn’t able to configure using Ansible. YMMV.
• The big advantage of using static site generators is the ease with which you can move everything to another server. The main effort in scripting the server build was for me to figure out how to set up the Python virtualenv that hosts ISSO, and that was very well supported. Once ISSO is set up, it’s a simple matter of copying the comment database from the old server to the new server. It’s a single file SQLite database which makes for really easy migration.