Go-Between

In the old days, before virtualization was practical, if you wanted to run a service, you installed an operating system (OS) on a physical machine and then manually installed the service. If more than one instance of the OS was required, you needed to purchase additional computers and repeat the process manually. As you might imagine, administering a large fleet of computers this way is unworkable in the long run, so automation tools were created. Fully Automatic Installation (FAI) [1] is a good example of an early, generic tool for deploying Linux distributions over a sizable number of machines.

Tools such as FAI created for physical machines are of use when deploying virtual machines, as well, as are distro-specific tools (e.g., autoinstall for OpenBSD [2], preseed for Debian [3], Kickstart for Enterprise Linux-compatible distributions [4], etc.). However, these tools might take a bit too long to build the environment you want to your specifications, because installing every OS from the ground up is a slow process.

In this article, I demonstrate the capabilities of modern automation tools through example. I deploy a set of web servers and a reverse proxy in a virtual environment hosted by a Proxmox VE hypervisor. (See the "Why Proxmox?" box if you are not familiar with it.)

Why Proxmox?

Proxmox VE is a hypervisor intended to be installed on your hardware on which virtual machines and containers are deployed. Proxmox is a commercial distribution, and therefore a paid subscription is required for accessing the production-ready repositories. Non-production repositories are available free of charge and without restrictions and are quite sufficient for use in testing and for home labs.

Proxmox VE is based on Debian and can act as a host for LXC containers and Qemu/KVM virtual machines. It offers a nice web interface for management (Figure 1) and supports a self-hostable backup solution (Proxmox Backup Server) that makes it quite convenient to take backups from your guest systems and store them in an orderly manner. Proxmox VE has been covered before in other articles [5][6], so I suggest you check them out if you want an in-depth review.

Figure 1: A recently created Proxmox 8.2 install. Proxmox offers a web interface that acts as a centralized control panel for a myriad of virtualization-related functions.

The main reason to use Proxmox VE is because it is inexpensive while offering lots of features. VMware's strategy has pivoted into turning ESXi into a product for high-budget customers [7], so Proxmox VE might end up being one of the last good affordable hypervisors. Finally, OpenTofu supports Proxmox VE through providers that are far from featureful but get the job done more often than not.

OG Virtualization

When virtualization became good enough for massive use, the number of OS instances system administrators had to manage multiplied. You no longer had to purchase a computer for each system you wanted to run, because you could just build a virtualization server and run 20 virtual computers. Instances became disposable: You could create a virtual machine for testing some service and discard it 10 minutes later. You could deploy a chat service and a game server for a weekend LAN party and delete everything afterward, virtually free of cost.

The traditional way of creating a virtual machine instance was to run the usual install process, which meant you would boot the virtual machine from a regular install medium and go through every setup step. Again, this process only works if you create and destroy virtual machines every so often; however, for environments in which virtual environments are counted with more fingers than you have on your hands, that method no longer works.

Enter OpenTofu

Terraform used to be the tool sys admins used when they wanted to deploy services in the cloud or in a virtual environment, especially if they didn't want a full orchestrator with all the associated complexity and overhead. Terraform is programed in a declarative language, which defines the final desired state. In other words, if you declare that you want your infrastructure to reside on an OpenBSD virtual machine called rproxy with three OpenBSD instances called webserver-1 , webserver-2 , and webserver-3 , Terraform creates that for you. If you ever want to add a new machine, you just add the characteristics of the new instance to your declaration and run Terraform again. If you need to remove one of the machines, you remove it from the declaration and execute Terraform one more time.

Terraform has been covered in other articles [8] and, because of its popularity, is one of the options most people know. Unfortunately, the company developing it switched its licensing model away from the Mozilla Public License (MPL 2.0) into the vague, commercially non-free Business Source License (BSL). Because Terraform was a critical component for so many organizations, the OpenTofu fork appeared shortly thereafter.

As a fork of Terraform, OpenTofu supports every Terraform provider that was available for Terraform 1.6 – where provider refers to a module supporting a cloud or hypervisor system (e.g., AWS, ESXi, or Proxmox). OpenTofu does not have feature parity with Terraform as a goal, so its feature set is expected to differ in the future.

OpenTofu is intended to run on the administrator's computer and issue instructions to the cloud environment or hypervisor from there. OpenTofu offers packages for a number of Linux distributions; has a generic installer for Windows, macOS, Linux, and FreeBSD; and is available in OpenBSD's port tree.

Introducing cloud-init

OpenTofu is a provisioner, which means it will deploy your virtual machines and infrastructure, but it won't configure them. You could say OpenTofu is a bit like a technician contracted to set your machines in place, run the wiring, and install an operating system, and then let the next specialist take over.

A brand new install in its default configuration is not of much use. For it to do any good, somebody has to create users, configure credentials, install packages, and so on. OpenTofu is not smart enough to accomplish all of this on its own, so it is usually paired with a complementary tool. Ansible is a common choice: OpenTofu creates the infrastructure, and Ansible configures it. Another widely available industry standard is cloud-init, Ubuntu's proposal for configuring new installs automatically. It is supported in one form or another by most relevant cloud providers and is typically used as follows:

1. Install a cloud-init-capable image of the OS you need on your virtual machines. You could either build your own or download a prepackaged image; many distributions offer either official or unofficial versions of cloud-init. For this article, I use an unofficial OpenBSD image from a reputable source [9], because both OpenBSD's HTTP daemon and reverse proxy are extremely simple to set up.

2. Load your cloud-init configuration into your host provider, which should have a facility to introduce the parameters you need cloud-init to set for each of your virtual machines. For example, Proxmox allows you to introduce a limited number of parameters from its web interface (Figure 2). In the case of Proxmox, your configuration options would be built into a special virtual CD drive that would be attached to the virtual machine you want to configure.

Figure 2: Proxmox VE offers limited support for cloud-init in its web interface, but full cloud-init capabilities can be leveraged through different mechanisms.

3. Boot each of the machines; cloud-init, which is already included in their images, would then fetch its configuration from the provider and apply it at first boot. The cloud-init tool can set users and passwords, import SSH public keys, install and upgrade packages, and run arbitrary scripts.

This setup is all you need for a simple deployment.