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
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!
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
# 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.
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. ]