Brent Baude

Brent is a software engineer with Red Hat where he works from his home in Rochester, MN. He is a co-maintainer of the libpod project.

Recent Posts

Monitoring container vitality and availability with Podman

Monitoring container vitality and availability with Podman

Not long after Podman developed a certain level of stability and functionality we started to hear questions like, “What about container healthchecks?” It was a tough question with no easy, obvious answers. My colleagues and I would occasionally discuss healthchecks, but we are a daemonless environment, which makes this kind of thing challenging. Without a long-running process or daemon to schedule healthchecks, we needed to look at other parts of the operating system to launch them. Recently, the questions grew more pronounced, and it was high time we resolved this for our users.

I am pleased to say that the latest Podman release 1.2 now has the ability to perform container healthchecks. This article describes healthchecks and explains how we implemented them for Podman.

Continue reading “Monitoring container vitality and availability with Podman”

Podman can now ease the transition to Kubernetes and CRI-O

Podman can now ease the transition to Kubernetes and CRI-O

Configuring Kubernetes is an exercise in defining objects in YAML files.  While not required, it is nice to have an editor that can at least understand YAML, and it’s even better if it knows the Kubernetes language.  Kubernetes YAML is descriptive and powerful. We love the modeling of the desired state in a declarative language. That said, if you are used to something simple like podman run, the transition to YAML descriptions can be a bitter pill to swallow.

As the development of Podman has continued, we have had more discussions focused on developer use cases and developer workflows.  These conversations are fueled by user feedback on our various principles, and it seems clear that the proliferation of container runtimes and technologies has some users scratching their heads.  One of these recent conversations was centered around orchestration and specifically, local orchestration. Then Scott McCarty tossed out an idea: “What I would really like to do is help users get from Podman to orchestrating their containers with Kubernetes.” And just like that, the proverbial light bulb went on.

A recent pull request to libpod has started to deliver on that very idea. Read on to learn more.

Continue reading “Podman can now ease the transition to Kubernetes and CRI-O”

Podman: Managing pods and containers in a local container runtime

Podman: Managing pods and containers in a local container runtime

People associate running pods with Kubernetes. And when they run containers in their development runtimes, they do not even think about the role pods could play—even in a localized runtime.  Most people coming from the Docker world of running single containers do not envision the concept of running pods. There are several good reasons to consider using pods locally, other than using pods to naturally group your containers.

For example, suppose you have multiple containers that require the use of a MariaDB container.  But you would prefer to not bind that database to a routable network; either in your bridge or further.  Using a pod, you could bind to the localhost address of the pod and all containers in that pod will be able to connect to it because of the shared network name space.

Continue reading “Podman: Managing pods and containers in a local container runtime”


Creating a custom atomic scan plug-in

In my previous article where I introduced atomic scan, I largely talked about using atomic to scan your containers and images for CVE Vulnerabilities. I also discussed how atomic scan had been architected to a plug-in approached so that you can implement your own scanners.  The plug-ins do not have to focus on vulnerabilities, it could be as simple a scanner that collects information about containers and images.

In this blog, I will walk through how you can create your own custom scanner within the atomic plug-in framework.

Continue reading “Creating a custom atomic scan plug-in”


Introducing atomic scan – Container vulnerability detection

In the world of containers, there is a desperate need to be able to scan container images for known vulnerabilities and configuration problems, and as we proliferate containers and bundled applications into the enterprise, many groups and companies have started to build container scanning tools. Even Red Hat has been building a scanning tool based on the tried and true OpenSCAP project, but there were several problems we saw time and again.

The problems with existing container scanning tools included:

  • Either these tools were required to be installed on the host, or if they were installed via a container they would have to be very privileged; therefore, the containers themselves could use that authority on the host machine.
  • They were being hard coded to only support a single container framework – docker.
  • We saw some very slow implementations, where the container scanning tools were actually copying all of the content out of the container image, then scanning the content, and finally removing the content.  You can image how inefficient this could be for hundreds or thousands of images or containers.

We decided we wanted to build a tool, atomic scan, that understood the underlying architecture and could download and run containers with scanning tools in them. But, we also didn’t want the scanning tools to be privileged; the atomic tool would be able to mount up read only rootfs from the host’s file system. These mounted file systems could then be passed onto the scanning container, along with a writeable directory for the scanner to place its output.

Continue reading “Introducing atomic scan – Container vulnerability detection”


Creating custom Atomic trees, images, and installers – Part 2

Shipping_containers_at_ClydeThis blog is a continuation of “Creating custom Atomic trees, images, and installers – Part 1.”  In part one, we learned how to compose our own atomic trees and consume them in a guest.  In part two, we will learn how to create our own disk images and installer media.


Creating custom disk images

As mentioned in the previous blog, the subcommand imagefactory can be used to create disk images.  As of this writing, the imagefactory subcommand can output the following image types:

  • kvm – results in a qcow2 image perfect for importing with KVM
  • raw – a raw image, which can be used as it or converted to another type
  • vsphere –
  • rhevm – suitable image for importing into RHEV-M

Continue reading “Creating custom Atomic trees, images, and installers – Part 2”

Creating custom Atomic trees, images, and installers – Part 1

Creating custom Atomic trees, images, and installers – Part 1

Shipping_containers_at_ClydeNot too soon after people start using Atomic images, the question of customization soon follows. It is a natural progression for most people when they use Atomic. There are a number of different ways to accomplish using custom images not withstanding using docker and containers. The Atomic tool called ‘rpm-ostree-toolbox‘ is emerging as the best tool for customizing Atomic.

The ‘rpm-ostree-toolbox’ main command is actually a wrapper (much like virsh) for three subcommands: treecompose, imagefactory, and installer.  With these three subcommands, you can create:

  • a custom Atomic tree
  • customized disk images (qcow2 and the like) based on your tree
  • install media (ISO) that installs your tree

Continue reading “Creating custom Atomic trees, images, and installers – Part 1”