Oci-Image

Intro I’ve been working on the JustEnough project on and off for the last several years. It started after examining upstream container images and realizing they could be a lot simpler. After watching a presentation from Brian Harrington of CoreOS fame, I started using Buildroot to create a minimal root filesystem that got imported into the container image. This worked great for a single container image, but got unwieldy when building multiple container images. ...

Minimal or distroless container images provide only the components required to run an application. By design, they exclude shells and common troubleshooting utilities. While this keeps images small and secure, reality kicks in when you need to debug something. You could find yourself needing a shell for runtime initialization scripts, health checks, or troubleshooting. ...

I hit a runtime error with my manifest built container image. It was caused by a missing libz dependency overlooked by lddtree. I thought the image had everything it needed, but I was wrong. So how does one verify what a container actually needs? Why static analysis fails Using tools like lddtree to explore ELF dependencies only work to a point. Binary ELF files list linked dependencies in a section named DT_NEEDED. Tooling will read the DT_NEEDED section to discover linked dependencies. This works great for direct links, but not implicit dependencies. ...

I previously described how I think container base images should be built. This post turns that idea into a working example. Usually a container image starts with something like FROM: python:3.x or FROM debian:bookworm-slim. What gets pulled in is more than just a runtime. It’s an entire filesystem assembled by an upstream distribution. The filesystem often includes tools and binaries that aren’t required for the application. They’re not necessarily harmful, but they are unexplained. When a container image includes a Perl interpreter, USB utilities, or terminal tooling that the application never uses, it raises a simple question. Why is that there? ...

Many container images start with FROM python:3.x. What gets imported is not only Python, its a preassembled filesystem of decisions you didn’t make. Understanding what’s inherited from the base image is key to building container images. Instead of implicitly trusting what’s included with the base image, think of the image as a collection of artifacts that are intentionally assembled. Large Container Images The official Python container image hosted on Docker Hub is a great demonstration of inheriting unknown layers. For Linux environments, the Python image comes with either a Debian or Alpine base image. Both base images come with additional applications not required by Python. ...

Forget about needing Docker’s buildx or Redhat’s buildah for this OCI container image deep dive. I will explain the OCI container image model and demonstrate building a new container image with a little JSON and a few SHA256 hash sums. You will understand that container images aren’t a file you download, but instead a graph of nodes and how the nodes are addressed after reading this article. ...