Select a language
We’re excited to announce our latest step in the further optimizing of Red Hat Enterprise Linux (RHEL) for containers with the release of the RHEL Atomic base image. This image is much smaller than the current RHEL base image, giving just enough to get started on building your application or service.
We carved out python, systemd, and yes, even Yum is gone - leaving you with only the bare bone essentials like glibc, rpm, bash, and their remaining dependencies. This leaves us with an image that’s just under 30MB compressed, 75MB on disk; composed of 81 packages.
Does size matter? For containers, the answer is it might
There’s a lot of hype in the industry around tiny base images such as Busybox, Alpine, or even static linking binaries from “scratch.” On one hand it’s really fun to work with such a tiny, embedded feeling footprint that is lightning fast to transfer over the network. On the other, some of our testing with these images shows that once these get loaded up with application stacks, they don’t always end up saving as much space as you’d think.
Regardless of the base images chosen in your environment, we strongly recommend standardizing on as few as possible and being disciplined in your build processes in order to reuse as many image layers as possible. Platforms like OpenShift tend to encourage this type of behavior by design, and it results in much smaller deltas being transferred to hosts when they pull containers. This is really important for full scale production environments.
Apart from the general “image hygiene” that we recommend, there are times where smaller images are beneficial. For example, highly dispersed environments like IoT and retail often have bandwidth limitations and can benefit from a reduced base image.
Most importantly, applications written in languages like Java or Go that bundle dependencies, often only require a handful of libraries - albeit crucial ones. We worked hard to strike the right balance with this image being small while simultaneously providing availability to the entire Red Hat ecosystem of content and management tools.
Earlier we mentioned that Yum has been removed, but don’t panic! We’re including a new, miniature version called microdnf, tailored specifically for containers.
Microdnf handles all of the common operations needed in a container like install, update, remove, etc., plus it’s written in C and allows us to be incredibly efficient moving forward. It’s also based on the underlying technology that our next version of YUM will leverage.
Remember, Microdnf is not a full yum replacement, but it’s perfectly suited for the container use case. On “pet” systems where you want a fully interactive package manager, yum is what you need. When you’re building a container, though, you really only need to handle a few package operations to create and deploy a container.
Using microdnf is simple. Let’s start with an existing dockerfile and adjust the relevant sections for the Atomic Base Image.
FROM registry.access.redhat.com/rhel7 RUN yum-config-manager --enable rhel-7-server-rpms RUN yum install -y --setopt=tsflags=nodocs java-1.8.0-openjdk-headless ;\ yum clean all
With the Atomic Base Image this becomes:
FROM registry.access.redhat.com/rhel7-atomic RUN microdnf --enablerepo=rhel-7-server-rpms \ install java-1.8.0-openjdk-headless --nodocs ;\ microdnf clean all
As you can see in this example, we collapsed the repository configuration into the install command for microdnf. This will be the default behavior when the container host is registered via subscription-manager. Alternatively, we could simply use a standard .repo file under /etc/yum.repos.d/ to configure this for us.
More to come!
We hope you enjoy using the new Atomic Base Image and find it as useful as we have. Also, don’t think we’re anywhere close to being done innovating with our container images!
Upstream we have several other efforts in the works that will continue our minimization effort, additional base images geared toward enabling monolithic applications, and ways to deliver more trusted and supported application stacks with life cycles that enterprises can depend on.
About the author
Joe Brockmeier is the editorial director of the Red Hat Blog. He joined Red Hat in 2013 as part of the Open Source and Standards (OSAS) group, now the Open Source Program Office (OSPO). Prior to Red Hat, Brockmeier worked for Citrix on the Apache OpenStack project, and was the first OpenSUSE community manager for Novell between 2008-2010.