Balancing size and features is a universal challenge when building software. So, it\u2019s unsurprising that this holds true when building container images. If you don\u2019t include enough packages in your base image, you end up with images which are difficult to troubleshoot, missing something you need, or just cause different development teams to add the exact same package to layered images (causing duplication). If you build it too big, people complain because it takes too long to download \u2013 especially for quick and dirty projects or demos. This is where Buildah comes in.<\/p>\n
In the currently available ecosystem of build tools, there are two main kinds of build tools:<\/p>\n
Buildah is unique in that it elegantly blurs the line between both \u2013 and, it has a rich set of capabilities for each. One of those rich capabilities is multi-stage builds.<\/p>\n
At Red Hat Summit 2018 in San Francisco, Scott McCarty and I boiled the practice of building production ready containers down into five key tenets \u2013 standardize, minimize, delegate, process, and iterate (video<\/a> & presentation<\/a>). <\/p>\n Two tenets in particular are often at odds \u2013 standardize and minimize. It makes sense to standardize on a rich base image, while at the same time minimizing the content in layered builds. Balancing both is tricky, but when done right, reaps the benefits of OCI image<\/a> layers at scale (lots of applications) and improves registry storage efficiency.<\/p>\n A particularly powerful example of how to achieve this balance is the concept of multi-stage builds. Since build dependencies like compilers and package managers are rarely required at runtime, we can exclude them from the final build by breaking it into two parts. We can do the heavy lifting in the first part, then use the build artifacts (think Go binaries or jars) in the second. We will then use the container image from the second build in production.<\/p>\n Using this methodology leverages the power of rich base images, while at the same time, results in a significantly smaller container image. The resultant image isn\u2019t carrying additional dependencies that aren\u2019t used during runtime. The multi-stage build concept became popular last year with the release of Docker v17.05, and OpenShift has long had a similar capability with the concept of chaining builds<\/a>.<\/p>\n OK, multi-stage builds are great, you get it, but to make this work right, the two builds need to be able to copy data between them. Before we tackle this, let\u2019s start with some background.<\/p>\n Buildah was a complete rethink of how container image builds could and should work. It follows the Unix philosophy of small, flexible tools. Multi-stage builds were part of the original design and have been possible since its inception. With the release of Buildah 1.0, users can now take advantage of the simplicity of using multi-stage builds with the Dockerfile format. All of this, with a smaller tool, no daemon<\/a>, and tons of flexibility during builds (ex. build time volumes).<\/p>\n Below we\u2019ll take a look at how to use Buildah to accomplish multi-stage builds with a Dockerfile and also explore a simpler, yet more sophisticated way to tackle them.<\/p>\n $buildah bud -t [image:tag] . <\/p>\n \u2026.and that\u2019s it! Assuming your Dockerfile is written for multi-stage builds and in the directory the command is executed, everything will just work. So if this is all you\u2019re looking for, know that it\u2019s now trivial to accomplish this with Buildah in Red Hat Enterprise Linux 7.5.<\/p>\n Now, let\u2019s dig a little deeper and take a look at using Buildah\u2019s native commands to achieve the same outcome and some reasons why this can be a powerful alternative for certain use cases. <\/p>\n For clarity, we\u2019ll start by using Alex Ellis\u2019s blog post<\/a> that demonstrates the benefits of performing multi-stage builds. Use of this example is simply to compare and contrast the Dockerfile version with Buildah\u2019s native capabilities. It\u2019s not an endorsement any underlying technologies such as Alpine Linux or APK. These examples could all be done in Fedora, but that would make the comparison less clear.<\/p>\n Using his https:\/\/github.com\/alexellis\/href-counter<\/a> we can convert the included Dockerfile.multi<\/a> file to a simple script like this:<\/p>\n #!\/bin\/bash
Using simple variables like this are not required, but they will make the later commands clearer to read so it\u2019s recommended. Think of the buildcntr1<\/i> as a handle which represents the container build, while the variable buildmnt1<\/i> represents a directory which will mount the container.<\/p>\n buildah run $buildcntr1 go get -d -v golang.org\/x\/net\/html<\/p>\n This is the first command verbatim in the original Dockerfile. All that\u2019s needed is to change RUN to run<\/i> and point Buildah to the container we want to execute the command in. Once, the command completes, we are left with a local copy of the go program. Now we can move it wherever we want. Buildah has a native directive to copy the contents out of a container build:<\/p>\n buildah copy $buildcntr1 app.go .<\/p>\n Alternatively, we can use the system command to do the same thing by referencing the mount point:<\/p>\n cp app.go $buildmnt1\/go<\/p>\n For this example both of these lines will accomplish the same thing. We can use buildah\u2019s copy command the same way the COPY command works in a Dockerfile, or we can simply use the host\u2019s cp command to perform the task of copying the binary out of the container. In the rest of this tutorial, we\u2019ll rely on the hosts command.<\/p>\n Now, let\u2019s build the code:<\/p>\n buildah run $buildcntr1 \/bin\/sh -c “CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .” <\/p>\n The same applies to this command. We\u2019re changing RUN to run and executing the command in the same container:<\/p>\n # runtime container
Now let\u2019s define a separate runtime image that we\u2019ll use to run our application in production with.<\/p>\n buildah run $buildcntr2 apk –no-cache add ca-certificates<\/p>\n Same tweaks for the RUN command<\/p>\n #buildah copy $buildcntr2 $buildmnt1\/go\/app .<\/p>\n Or: <\/p>\n cp $buildmnt1\/go\/app $buildmnt2<\/p>\n Here we have the same option as above. To bring the compiled application into the second build, we can use the copy command from buildah or the host. <\/p>\n Now, add the default command to the production image.<\/p>\n buildah config –cmd .\/app $buildcntr2<\/p>\n Finally, we unmount and commit the image, and optionally clean up the environment:<\/p>\n #unmount & commit the image
Don\u2019t forget that Buildah can also push the image to your desired registry using \u200bbuildah push`<\/p>\n The beauty of Buildah is that we can continue to leverage the simplicity of the Dockerfile format, but we\u2019re no longer bound by the limitations of it. People do some nasty, nasty things in a Dockerfile to hack everything onto a single line. This can make them hard to read, difficult to maintain, and it\u2019s inelegant.<\/p>\n When you combine the power of being able to manipulate images with native Linux tooling from the build host, you are now free to go beyond the Dockerfile commands! This opens up a ton of new possibilities for the content of container images, the security model involved, and the process for building. <\/p>\n A great example of this was explored in one of Tom Sweeney\u2019s blog posts on creating minimal containers.<\/a> Tom\u2019s example of leveraging the build host\u2019s package manager is a great one, and means we no longer require something like \u201cyum\u201d to be available in the final image. <\/p>\n On the security side, we no longer require access to the Docker socket which is a win for performing builds from Kubernetes\/OpenShift. In fairness Buildah currently requires escalated privileges on the host, but soon this will no longer be the case. Finally, on the process side, we can leverage Buildah to augment any existing build process, be it a CI\/CD pipeline or building from a Kubernetes cluster to create simple and production-ready images. <\/p>\n Buildah provides all of the primitives needed to take advantage of the simplicity of Dockerfiles combined with the power of native Linux tooling, and is also paving the way to more secure container builds in OpenShift. If you are running Red Hat Enterprise Linux, or possibly an alternative Linux distribution, I highly recommend taking a look at Buildah and maximizing your container build process for production. <\/p>\nMulti-stage builds<\/h2>\n
Buildah background <\/h2>\n
Using Dockerfiles:<\/h3>\n
Using Buildah Commands<\/h3>\n
First Build<\/h4>\n
\n
\n# build container
\n
\nbuildcntr1=$(buildah from golang:1.7.3)
\n
\nbuildmnt1=$(buildah mount $buildcntr)<\/p>\nSecond Build<\/h4>\n
\n
\nbuildcntr2=$(buildah from alpine:latest)
\n
\nbuildmnt2=$(buildah mount $buildcntr2)<\/p>\n
\n
\nbuildah unmount $buildcntr2
\n
\nbuildah commit $buildcntr2 multi-stage:latest
\n
\n
\n#clean up build
\n
\nbuildah rm $buildcntr1 $buildcntr2<\/p>\n