Composing systems in an automated way with Ansible, Podman, and bootc

 February 2, 2026 -  Gent, BE

Red Hat Certified Specialist in Containers

 January 20, 2026

Yesterday, I passed the Red Hat EX188 exam, which allowed me to renew my Red Hat Certified Specialist in Containers certification.

I had a very good memory of this exam from the last time I took it, so I was happy to go through it again. Different from last time, I did encounter some difficulties with the last exercise, which was a little surprising to me, since the last time I found it testing the same capabilities as a walk in the park, but maybe this time I simply started with the wrong foot. This obviously had no major impact on my exam, allowing me to easily achieve and exceed the required score to pass.

Simplifying container orchestration with Ansible and Podman

 November 5, 2025 -  Whittlebury, GB

Simplifying container orchestration with Ansible and Podman

 June 13, 2025 -  Brno, CZ

Route traffic across Podman networks with Traefik

 April 30, 2025

If you’ve followed my posts over the years, you know I prefer clean solutions to less clean ones for my home lab (more to come on this!). Over the past year, I settled on a pattern that gives me the isolation of Kubernetes Namespaces without any of its weight: one private Podman network per application, plus Traefik in a shared “DMZ” network that terminates TLS and forwards traffic where it needs to go.

Simplifying container orchestration with Ansible and Podman

 February 3, 2025 -  Gent, BE

Build and publish multi-arch containers with Quay and GitHub Actions

 February 29, 2024

When I deploy a system, I always try to automate it fully. There are many reasons for this, one of which is that, in this way, the automation becomes the documentation for the system itself. Another reason that drives me to automate everything is my preference for clean systems. Another consequence of this preference I have is that in the last few years, I’ve moved many systems to a Fedora rpm-ostree flavor (eg: Fedora CoreOS, Fedora IoT, Fedora Atomic) with the various services running in containers managed directly by systemd via podman. I prefer to create container images via CI/CD processes for the same reasons. Since I use Quay.io a lot, I usually leverage its capability to hook into git repos and rebuild images based on git tags or git commits. Recently, I needed a multi-arch image, and I discovered that the usual process does not support multi-arch images.

Share volumes between Podman Systemd services

 December 31, 2023

Since the merge of Quadlet in Podman, I’ve been moving multiple services to Podman Systemd services. I find them to be easy to create, manage, and automate.

I recently migrated a complex system to Podman Systemd, where multiple processes write in a folder, and one process reads the folder’s content. Before the migration, everything worked properly since all the processes were running natively on the machine with the same user. After the migration, there were some permissions issues. This issue allowed me to dive a little more deeply into the whole implementation of SELinux for containers and realize a few interesting things.

Manage Podman containers with Systemd and Quadlet

 May 17, 2023

Until a few months ago, the only option to start containers from Systemd was to create a Systemd unit which called podman (or docker) with the run sub-command. Podman was also providing podman generate systemd to easily create such Systemd file.

This has now changed. From version 4.4 of Podman, in addition to the mentioned method, it is possible to use Quadlet to simplify the execution of containers from Systemd.

Quadlet allows you to create additional kinds of Systemd units to manage your container needs:

GitHub Actions and containers

 April 17, 2023

GitHub Actions allows the use of containers with different Operating Systems. Although, it does not mean that everything is seamless when you are using them. I’ve discovered this the hard way! Below are my findings and the process I followed to make the GitHub Action pipeline work properly with containers.

It all started with the addition of a new tool in the pipeline, which was not installable on Ubuntu (the GitHub Actions default operating system), due to a packaging issue. Therefore, I decided to use a Fedora container since I was sure that our toolchain was present and well-maintained in Fedora. After adding the container definition and changing the toolchain installation command from apt to dnf, the pipeline seemed to be working properly. After a few days, it was noticed that the pipeline did not fail but was not working.