This presentation details an experiment to use Gentoo Linux as a source-based Docker build system to achieve highly customized, minimal container images, motivated by the frustrations of managing dependencies in standard distributions (like Debian/Ubuntu). By leveraging Gentoo's robust dependency tracking (emerge) and granular feature control (use flags), the speaker demonstrates how to precisely compile software (specifically PHP with the GD extension) without manual dependency hunting. The crucial optimization steps involve aggressive multi-stage building—copying only the final compiled artifacts into a scratch image—and meticulous cleanup of unnecessary files and binaries. This process successfully reduced the resulting PHP image size from an impractical 1.48 GB (due to the included build environment) down to 72 MB (or 65 MB using the community-developed Kuebler tool), confirming that source-based, highly customized builds can yield minimal production images, though complexity remains high.
Using Gentoo as a Minimal Docker Build System
0:03:09 The Problem with Standard Images: The project was initiated out of frustration when the official PHP Docker image failed to include the GD image library, forcing the user to manually track and install external dependencies (like libjpeg, libpng) and build from source—a massive waste of time that should have been solved by proper package management (0:05:09). Reject the premise that this level of manual effort should be necessary for standard libraries.
0:06:09 Gentoo’s Advantage: Gentoo Linux solves complex dependency resolution using emerge and "use flags." These flags allow granular control over compiled features (e.g., enabling use gd) and automatically pull in all necessary build dependencies (0:07:30).
0:09:44 Initial Failure (Image Bloat): The first attempt using a standard Gentoo base image resulted in an image size of 1.39 GB, primarily due to the inclusion of the large Portage tree (source repository). This size is unacceptable; it validates the need for optimization.
0:10:32 High Cost of Bloat: Large images lead to slow CI/CD deployments and high costs in constrained networking environments (e.g., the speaker noted a 20-minute deployment and a 300 Euro roaming bill, though I don't care about the personal financial details, the principle holds).
Takeaway (0:11:03): Build minimalistic images and keep debug utilities separate.
0:12:33 Hidden Dependencies: Attempting to compile PHP directly into a target root directory failed because some software requires the build tools (like PHP itself) to be pre-installed and available on the host system due to implicit/undocumented dependencies (0:13:37).
Takeaway (0:13:43): Software often has hidden runtime dependencies (e.g., required timezone data, 0:14:15) and build-time dependencies that require careful tracking.
0:15:14 Optimization via Multi-Stage Builds: The size was reduced from 1.48 GB to 112 MB by employing multi-stage builds (FROM scratch) and copying only the necessary compiled artifacts from the Gentoo build stage (0:16:08).
Takeaway (0:16:16): Multi-stage builds are essential for eliminating extraneous build layers and keeping images small.
0:17:32 Final Cleanup: Further reductions to 72 MB were achieved by ruthlessly pruning unnecessary OS packages (e.g., file, set, coreutils dependencies) and deleting documentation (man pages, shared docs) that are useless in a container (0:19:29).
0:19:43 Debugging Strategy: Debugging production containers that lack a shell or basic tools must be done using a separate, "fat" container that shares Linux namespaces (Network, PID) with the running application container (0:20:48).
0:23:46 Kuebler Simplification: For production Gentoo usage, the Kuebler project dramatically simplifies the custom build process, managing the complexity of source compilation, configuration, and cleanup routines, achieving a final image size of 65 MB (0:27:31). As far as I can tell, this is the only sensible way to maintain a source-compiled production image.