Repurposing a bootc host

Instead of just running a webserver, what if we needed to run WordPress instances, and our developers need those to be containerized? Normally, that would start the hunt for available infrastructure, an examination of the software needed to support the containers, changes to automation, deploying new machines to support the testing, and a lot of back and forth between the different teams.

With image mode, a few new options are available. The developers can take a standard build that has podman available, add their container configurations, and pick an existing host to run the image. If they have problems or if they need to change the host back to it’s previous role, that’s as simple as a rollback.

Let’s explore how that can work by creating a new Containerfile with the following contents.

For an 'advanced` configuration, this doesn’t have a lot in it, what’s happening?

First up, the FROM line references the image you’ve been building and updating during this lab. This means that every bit of customization and software you’ve installed previously will be available on the host built from this new definition. This style of derived images is something very powerful for collaborating while keeping teams focused on their needs. Different teams can work directly from images built by and certified by others, rather than starting from scratch or trying to integrate and apply controls at the end of a long build process.

Remember the ADD directive pulls full directories into the image at build time. So most of the work here is somehow being done in /usr or /etc, let’s see what’s in there.

The "hidden" part is the use of quadlets to run containers. A full description of quadlets is outside the scope of this lab, but in short, a quadlet is a way to run a container (or group of containers in this case) as a systemd service.

In wordpress-quadlet/etc/ we have a configuration file for the caddy server, a Golang HTTPS server acting as a proxy, and a file of environment variables to be passed to the quadlet.

In wordpress-quadlet/usr/share/containers/systemd/ we have all of the files that define the quadlet. The .container file defines each of the containers for systemd to run. These are typical systemd unit files, aside from the [Container] block which is unique to quadlets.

Feel free to explore these files and directories before moving on.

When we build this image, we will use a new name to denote it’s new purpose. Your naming and tagging conventions should aim to convey information to the people who need them as much as providing hooks to automate and control visibility to hosts.

And of course push it to the local registry:

Notice that even though we used a new tag for this image, the push still used cached layers. This is an advantage of stacking images in a standard build design.

You can now login to the virtual machine:

After the new container image has been pushed to the local registry, you can switch the bootc image to the WordPress one. This bootc command is how we change what image to follow for updates. From here on, any changes made to the original httpd image would not show up as an available update, only changes to the new caddy-wp image.

From a status perspective, a switch looks the same as an update. There’s a new deployment that’s been staged and prepared for the next boot, but the image reference is completely different.

As usual, after the command is done you need to reboot the virtual machine for the changes to take effect. Before doing that, please make sure you are logged in to the virtual machine and not the hypervisor (the prompt should look like [core@qcow-vm ~]$):

After a short while, you can log back in to the virtual machine:

Check on the status of our newly created quadlet by checking the caddy proxy server and what it inherited from the standard build.

We weren’t prompted for our sudo password, but it looks like our new caddy server couldn’t bind to port 80 when it tried to start. What’s going on? The answer to both lies in the image we built from.

If we check the status of Apache, we can see that it is indeed running and listening on port 80.

If you look at the original Containerfile, you’ll recall we set Apache to start at boot:

Since local changes to /etc are kept by bootc when changing images, httpd stayed enabled on this new host as well. Let’s disable it and restart caddy.

It looks like caddy started, let’s check to see that it’s passing requests to the WordPress container in the quadlet. Curl will dump a mess of HTML and we don’t have a GUI, but that’s why we installed the Lynx browser.

You should see the WordPress configuration dialog box. You can hit Q (Shift + q) to quit lynx and then log out of the VM.

That solution is fine for this host, but how to we fix it in the image? The answer depends on the goal and how container layers operate.

The simplest solution would be to stop the service from starting. You may find there are other services in the base image you may want to disable in certain downstream images as well. One way to stop these sorts of services from activation, especially those defined in /usr/lib/systemd/system, is with masking.

Let’s add a heredoc to our Containerfile to tell systemd to mask the httpd service and the bootc update timer.

This means these services won’t even be able to be started manually.

And of course push it to the local registry:

The name of the image has stayed the same, but we’ve now added the V2 to add some semantic versioning. Tags are part of how bootc keeps track of images, which is important when it comes to updates. Since this is a new tag, we would need to switch to it in order to use it, just like we did the first time. This might be fine, especially since we’ve turned off auto-updates.

We can check this by having bootc look for an update. Notice the new V2 image isn’t seen.

Remember from the OS base image discussion that an image can have multiple tags associated with it, and bootc can track an single tag for an image. To make this new image appear as be an update, then we can add a tag to this new image that matches what bootc is currently tracking.

Since we haven’t been adding tags to any of our previous builds, they all have the default latest tag automatically applied.

You can see both of our caddy images, and the tags associated with them. To make V2 appear as an available update, add the latest tag to that image. The first image is the one to operate on, and the second is the complete target name you want to apply. This can be used in a lot of ways, for example to build all images locally without any registry, organization, and tag info and add that only to specific builds that are ready to be pushed to a registry.

This changed the tag locally, so we need to push the newly tagged image to the registry to pick up the change there. You’ll notice all of the layers are skipped since this is really just a metadata change.

Logging back into the VM, you should see an update available for the caddy-wp image with the one layer that has our change.

Feel free to apply the update and test the changes.

Before proceeding to the next exercise, make sure you have logged out of the virtual machine:

Easy updates, rollbacks, and image switching are part of the core improvements to the operation of image mode systems. Layering is an important part of the design of standard builds and can have some downstream effects as well. Just like stacking configuration management, thinking through the idea of layered builds can be powerful.

In this lab we’ve covered the very basics of image mode to get you started in your exploration of what this can do for you and your environment. There’s a lot we haven’t covered, like compliance, managing kernel arguments, integrating with other tools like Ansible or Satellite, and much more. Image mode is just leaving tech preview, so there’s a full roadmap of improvements to come.

We’ve got other ways to learn more, including documentation, example snippets, other exercises, and more.

In the next modules, we’ll add a little more color to ways image mode can be used.