Abstract:

This talk explores a frustrating experiment in using Gentoo Linux as a build system for creating minimal, customized Docker containers. The motivation was the cumbersome process of adding extensions like GD to the official PHP Docker image, which requires manual dependency management—a problem solved by package managers years ago.

The speaker leverages Gentoo's emerge package manager and its USE flags to automate dependency handling. However, this approach immediately creates a multi-gigabyte image, which is impractical. The core of the solution involves using multi-stage builds to separate the large Gentoo build environment from a minimal final runtime image. This process is complicated by hidden build-time and runtime dependencies that must be manually resolved.

After significant cleanup of unnecessary packages and files, the image size is reduced from over 1 GB to ~72 MB. The speaker concludes that while using Gentoo directly is not recommended for production, the principles—minimalism, aggressive use of multi-stage builds, and cleaning up artifacts—are highly valuable. For debugging such stripped-down containers, using a separate "fat" container that shares the target's kernel namespaces is the correct approach. The talk also points to the Kuebler project as a more refined tool for those insistent on building with Gentoo.

Gentoo as a Docker Build System: An Experiment in Minimalism

• 0:02:42 The Problem: Customizing official Docker images, like adding the GD extension to PHP, is a needlessly manual and annoying process that forces users to resolve compilation dependencies themselves.
• 0:05:03 Proposed Solution: Gentoo: The speaker proposes using the Gentoo Linux build system (emerge and USE flags) which excels at managing compile-time options and dependencies automatically. For example, simply enabling the gd USE flag pulls in all necessary libraries.
• 0:09:39 Obstacle 1: Massive Image Size: A standard Gentoo Docker image is impractically large (~1.4 GB) due to the inclusion of the entire build system, source code repository (Portage tree), and toolchain. This makes deployment slow and costly.
• 0:15:14 Solution: Multi-Stage Builds: To solve the size issue, a multi-stage Dockerfile is used. The first stage contains the full Gentoo environment to compile the application into a target directory. The second stage starts from a minimal base (scratch) and copies only the compiled files, dramatically reducing the final image size to around 112 MB.
• 0:17:28 Further Optimization: The image is slimmed down to 72 MB by aggressively removing packages and files not strictly required at runtime, such as documentation, man pages, and unneeded binaries that Gentoo installs by default.
• 0:19:43 Debugging Minimalist Images: A container with no shell or tools can be debugged by launching a second, "fat" container with debugging utilities. This debug container shares the target container's kernel namespaces (e.g., --net=container:<target>, --pid=container:<target>), giving it full access to inspect processes and network activity.
• 0:21:49 Practical Takeaway: Don't use Gentoo. Instead, apply these principles to your existing workflow. Use a full-featured image (like Ubuntu) as a builder in your first stage, and copy the compiled artifacts to a minimal runtime image (like Alpine) in your final stage. This separates build-time dependencies from the production artifact.
• 0:23:36 For the Determined: The Kuebler Project: For those who actually want to use Gentoo for this, the Kuebler project provides a structured and refined framework for building Gentoo-based Docker images, achieving even smaller sizes (~65 MB) with a much cleaner workflow.