Red Hat’s Atomic Team Builds a Docker-Less Container Builder – InApps 2022

Getting more organizations to deploy containers in production will require foolproof automation. There’s a viable argument that you don’t need a developer tool to accomplish this — that all an operations team really needs is something that follows instructions and gets out of the way. The CRI-O project was begun by Kubernetes contributors as a way of automating the container assembly process without involving Docker in the mix.

Now, there’s another project underway by the Project Atomic team, which makes the open source distribution of the Atomic container host, to make mostly the “compose” part of a containerization system, but not as an engine. Rather, it’s more of an ordinary command-line tool, but one that is more adaptable to the needs of any orchestrator or host, including Atomic Host or — now that Red Hat owns it — Tectonic.

Buildah (which I’m told is best spoken with a Boston accent) is a project, currently in the alpha stage, to have a conventional tool build a container in Docker or OCI format, possibly mount and unmount its filesystem once built, and delete the container. It doesn’t sound like much, but in a way, that’s the whole point. It performs a few of the tasks that an automated system would require, leaving management to the orchestrators and/or daemons such a system would use.

What’s missing, at least in a production environment, would not be required: the Docker development engine.

“I wouldn’t necessarily position it like, ‘Oh, they’re going after Docker!’” said Joe “Zonker” Brockmeier, Red Hat’s senior evangelist for Linux containers (and my former colleague at the original ReadWriteWeb). “The point of Buildah is this: There are a lot of scenarios where you need to be able to build OCI- or Docker-style images, without Docker itself running.”

Output Only

When a build host is producing containers at high volume for production, the presence of a full container engine on that host could conceivably slow it down, Brockmeier argued. “You might really just want to throw your source and your configs and everything at a system, only build it, and not have something that’s capable of running it.”

One of the problems that sparked the creation of CRI-O did also inspire the minds behind Buildah, he told InApps: Back when Kubernetes was considered an orchestrator for “Docker containers,” orchestration systems that were one day running in perfect order suddenly became gummed up when either Docker or Kubernetes was upgraded. Their different development tracks had no dependencies upon one another, and as a result, the behavior of the system as a whole was never guaranteed.

The Container Runtime Interface (which lent CRI-O its first syllable) was designed as an abstraction layer, enabling Kubernetes to run with any container runtime by utilizing CRI as a proxy. “In the same way,” said Zonker, “Buildah is breaking out a piece of what we need to build containers.”

Although the project is still in the embryonic stage, he told us, Red Hat is supporting Buildah’s use in CentOS, Fedora, Debian, and RHEL distributions. That’s not the typical buildout for container developers, who Brockmeier perceives as probably using Mac workstations. Buildah won’t replace anything in the developer’s realm, at least not entirely, unless that developer is working on a prototype for a future production environment.

Chain Link

In a CI/CD pipeline system such as Jenkins, Buildah might actually serve a security benefit, he proposed: A task in a pipeline could call Buildah simply to build an image. The call would not, in turn, create an instance of a container engine that someone else could leverage, probably unmonitored, for another purpose. That’s one less executable component in the chain that could be exploited.

A system taking inventory of the contents of a container, perhaps for the purposes of evaluating its security risk, could acquire its Dockerfile (which still serves as the container’s manifest), pass that Dockerfile to Buildah, have it build the container image, and then mount that container’s file system. It could then inspect the complete contents of the image and determine, for instance, whether its dependent libraries are safe to use, all without creating an executable component capable of running an unsafe library were it not safe to use.

It might be a much simpler method to evaluate a container, perhaps in a CI/CD context, than invoking an entire container inspection environment, or a separate scanner such as OpenSCAP.

“For a while, folks have wanted a way to just build images without having a daemon running in the background,” Brockmeier said. “If your daily workflow doesn’t actually include running something locally, and all you want to do is be able to build an image and spit it out, that’s the impetus behind it.”

Red Hat will commit to supporting Buildah with any edition of RHEL in which it ships, he told InApps, but the tool’s long-term future depends now upon whether the operator community adopts it as much as the company believes it will.

Red Hat is a sponsor of InApps.

Title image of a five-month-old American bulldog puppy by Davepd19, licensed under Creative Commons 3.0.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.