Speed up container builds with overlay mounts

Overlay mounts help to address a challenge we run into when we have several containers on a single host. The basic problem is that every time you run dnf or yum inside a container, the container downloads and processes the metadata of all the repositories. To address this, we added an advanced volume mount to allow all of the containers to share the host's metadata. This approach avoids repeating the download and processing for each container. I previously wrote a blog post introducing the concept of overlay mounts inside of builds.

Personally, I think this is a really cool feature. I like to use it whenever I do a series of builds and am playing with Containerfiles or Dockerfiles.

How to populate the host's case

I had a question about the blog from Guillaume Moutier about how to populate the host's case:

Hi Dan! I just read your article on speeding up container builds with local cache, so I wanted to implement the technique for one of my builds as I have to try different things, so relaunch build every 5-10 minutes... I guess I understood most of it (I'm relatively new to this part of the process), but as I am on Fedora 31 and using a CentOS 7 base image, I was wondering how to populate the case on my host. Especially as dnf is not part of CentOS7 if I am right... Does that make sense?

I searched for information on creating a cache for Centos 7 on a Fedora box, and I looked for the /etc/yum.repos.d/centos.repo file on the Internet. I was worried about how yum inside of Centos 7 would handle metadata created by dnf on Fedora. Would it even work?

At that moment, I gave myself a dope slap and figured, I should just use a centos:7 container to create the cache on Fedora!

It's easy

Here is how simple this is to do. First, I create a directory on my host to store the cache. Then I run a centos:7 container and execute the yum makecache command.

# mkdir -p /var/cache/centos/7
# podman run -v /var/cache/centos/7:/var/cache/yum:z -ti centos:7 yum makecache

Note that I did this with a locked-down Podman container and allowed it to write to the cache.

Next, I create a test Containerfile, which runs a yum -y update.

# cat /tmp/Containerfile
FROM centos:7
RUN yum -y update
Now I can just run a podman build with an overlay volume mount and take advantage of the local repo.

# time podman build -v /var/cache/centos/7:/var/cache/yum:O /tmp
…
real    0m56.132s
user    0m26.298s
sys    0m10.332s

Versus:

# time podman build /tmp
...
real    1m5.902s
user    0m29.404s
sys    0m11.332s

This represents about a 20% time savings on the build!

Obviously, you could repeat this process for all of your favorite RPM-based distributions.

But what about the EPEL repo?

After I suggested this to Guillaume, he responded with:

That makes sense, I guess, but what about the EPEL repo (used in the second set of installs)?

The answer is to configure an image based on the original Centos:7 image with the EPEL repos defined inside of it. Then use the podman command to run makeimage on that container with the volume from the host.

Wrap up

The bottom line is, with overlay mounts in your build farm, you can use containers to speed up builds for multiple distributions at the same time.

[ Getting started with containers? Check out this free course - Deploying containerized applications: A technical overview. ]