Red Hat Buildah Provides a Way to Build Containers without the Docker Daemon
Red Hat wants to rid the daemons from the process of building containers.
This week, the company has released the first production-ready version of its tool for building container images, called Buildah. Wait, doesn’t Docker already do this? But Red Hat engineers, among others, are not crazy about the client-server model Docker is built on.
This model, which bundles multiple functionalities in one program, could introduce security vulnerabilities, and limits the deployability of container build systems on Kubernetes-based clusters, they argue.
For the process of simply building a container, “Why do we need a big container daemon to basically create content inside a directory, tar it up, and write some simple json files to with it?” said Daniel Walsh, Red Hat consulting software engineer.
The Buildah command-line tool can create Open Containers Initiative (OCI)-compliant and Docker container images, even using the standard Dockerfile format itself. It is compatible with all the scriptable Linux tools supporting container creation, like cp, make, yum.
Doing away with the Docker daemon is one of the chief benefits of Buildah, Walsh claims (the “Builder” named comes from pronouncing “Builder” with Walsh’s thick Boston accent). A daemon is basically a program that runs in the background on a host system, waiting for input of some kind. Docker’s own daemon-based software, by far the most popular way of building and then running containers, handles multiple tasks from a single command line, including the pulling of images, building the images, and running them.
Over the past few years, however, much work has been going on, through the efforts of the OCI among others, to decompose these functions into separate components, for greater control and flexibility.
One of the issues with the daemon-based approach is that of security, namely that the container requires a socket to the daemon running on the host. Docker has done a lot of work to limit the container access to the host in all but the approved ways, but this conduit into the host still gives security experts the heebie-jeebies. “It allows containers to have full access over the node that runs the builds. As soon as you have access on the Docker solution, you basically have root on whatever machine is running the Docker daemon. There is no authorization,” Walsh said.
Buildah began within Red Hat’s Project Atomic initiative, though others have been working towards a similar goal. Microsoft engineer Jess Frazelle, in her spare time, spun up software called img, a “standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder.” And Google’s container team created Kanikos for building containers with Kubernetes.
Buildah also offers some features not offered by the core Docker components. During the build process, developers can specify when to do commits, in contrast to Docker Build, which creates a new image after executing each line in the Dockerfile. This was a feature created to speed build times but also introduces complexities.
“A classic problem with Dockerfiles is people putting in Kerberos keys or different kinds of secrets to get content, and then those get embedded in the image. There have always been people trying to figure out ways of removing that content from that image,” Walsh said. “Buildah, on the other hand, basically processes all the commands in the Dockerfile into a single image,” thereby giving the developer an opportunity to clean up unnecessary content before it is committed to an image.
Docker also bundles some tools into the container image, such as the YUM and DNF package managers, which may not actually be needed after the initial build, and could introduce security vulnerabilities. “IT teams may want their build systems running the bare minimum of processes and tools, otherwise, additional complexity can be introduced that could lead to loss of system stability and even security risks,” Walsh wrote, in a blog post announcing the Buildah 1.0 release. Buildah gets around this requirement by temporarily adding external read/write volumes during builds.
In terms of migrating from Docker to Buildah, all that would be needed is to replace the docker build command over to buildah bud on the command line, and in scripts. Bear in mind, the Buildah doesn’t replicate the entire Docker command line, though another Atomic Project effort is taking on that job, Podman, which would manage the runtime and the push/pull capabilities as well.
“Our overall effort is all about breaking down into its base functionalities what everybody is doing with Docker at this point, and allowing people to experiment and building new ways of doing things,” Walsh said.
This approach may also be more amiable to creating GitOps-based development workflows, where the developer doesn’t worry about containerizing the code at all. In this scenario, whenever a developer commits some revised code to git, Kubernetes or OpenShift (Red Hat’s commercial version of Kubernetes) will fire off a job behind the scenes to rebuild the container image that houses the code, and push it into the CI/CD system for testing, and out to quality assurance or directly into production. All automatically (in theory).
“If you have hundreds of users checking in code, and firing off hundreds of streams building containers, that’s where we see taking advantage of Kubernetes orchestration and running individual builds inside containers,” Walsh said.
Buildah 1.0 has full, product-level support in Red Hat Enterprise Linux 7.5, obtainable through the yum -y install buildah command. Buildah also features full support for the Federal Information Processing Standards (FIPS), required by the U.S. federal government for its computer systems.
Gartner estimates that by 2020, more than 50 percent of global organizations will be running containerized applications in production, up from less than 20 percent today.
