A service image moves from a full distribution base to a minimal base — what goes away with it?
answer
- convenience against footprint
- the base is a userland
- everything your artifact did not pack
- shell, package manager, certificate store
- timezone data and system libraries too
basics
~20 sEverything the distribution shipped that the process does not carry itself: the shell and its utilities, the package manager, usually the trusted-certificate store, timezone and locale data, and most system libraries. Only the artifact and whatever the build copied in remain.
solid answer
~50 sA base image is a working userland, and most of it exists for humans and for convenience rather than for the process. A full distribution base ships a shell and its utilities, a package manager, a trusted-certificate store, timezone and locale data, user and group files, and a wide set of system libraries. A minimal base keeps a small fraction of that; an empty base keeps none of it, so the image contains only what the build copied in. What you gain is a smaller transfer on first pull, fewer packages for someone to patch, and less surface inside the image. What you pay is that anything the process quietly relied on — certificate verification, timezone conversion, a shared library, a shell to run a wrapper line — must now be supplied deliberately, and you cannot open a prompt inside the image to find out which one is missing.
go deeper
Be able to name what a base image supplies: a shell and utilities, a package manager, certificates, timezone data, system libraries. Then say plainly that a minimal base keeps little of it and an empty base keeps none.
Explain the invisible dependencies rather than just the visible ones — why verification, time conversion and a dynamically linked artifact all depend on files the base happened to ship, and why removing the package manager means every addition is a rebuild.
Show that you decide from the run-time requirement set, validate the final image in the pipeline before publishing, and have already answered how the thing gets diagnosed once there is no prompt inside it.
Frame it as an estate trade-off: a base choice sets the patch stream, the debugging story and the migration bill for every team that adopts it, so the interesting question is which small set of bases you are willing to maintain.
## What a base image actually is A **base image** is the filesystem a build starts from: read-only layers holding a *userland* — programs, libraries and data files — onto which the build copies your own artifact. It is not an operating system in the full sense. Every container on a host shares that host's kernel; the base supplies everything *above* the kernel that a process might reach for. That is the whole of what this choice is about. Three points on the spectrum come up in practice: - **A full distribution base** — a complete working userland: a shell and its command-line utilities, a package manager, a maintained set of root certificates, timezone and locale data, user and group files, and a broad library set. Hundreds of megabytes is normal. - **A minimal base** — a few megabytes. Typically a tiny library set and little else; some variants ship a certificate bundle and a stripped shell, many ship neither. Which one you picked matters, so read what it contains rather than assuming. - **An empty base** — nothing at all. The image is exactly what the build copied in, on top of an empty filesystem. ## What departs with the strip | What the full distribution shipped | Typically on a minimal base | On an empty base | What its absence costs you | |---|---|---|---| | Shell and command-line utilities | Sometimes, stripped | No | Start commands written as a shell line, wrapper scripts and health scripts stop working | | Package manager | No | No | You cannot add anything after the build; every addition is a rebuild | | Trusted root certificates | Sometimes | No | Outbound connections fail to verify the server's certificate | | Timezone and locale data | Rarely | No | Time conversion and formatting fall back or fail | | User and group files | Sometimes | No | A numeric identity with no name behind it; some processes object | | System libraries | A small set | No | A dynamically linked artifact will not start | ## The dependencies you did not know you had The surprises are never the things you would have listed. They are the ones the distribution supplied silently: - **Trusted root certificates.** A client verifies the chain a server presents against roots it reads from the local filesystem. No store, no verification, and every outbound call over an encrypted connection is refused. - **Timezone and locale data.** Converting an instant into a named zone reads data files. Strip them and the process either falls back to a single zone or refuses the conversion. - **Name-resolution configuration and helpers.** Some processes read these from files the base supplied. - **User and group files.** Running under a numeric identity that no name maps to is legal, and some software still refuses. - **System libraries.** An artifact linked dynamically names the libraries it needs and resolves them at start-up. If the image does not hold them, it dies before its own first line runs. - **A shell.** Not only for you: anything phrased as a shell line — a start command with a pipe in it, a wrapper, a periodic check — needs one to exist. ## What you gain, honestly - **Transfer cost.** Size is paid on the first pull by each host that does not already hold those layers, and again whenever the base itself changes. On an estate of several hundred hosts that is real, but it is a one-off per host, not a per-request cost. - **Fewer things to patch.** Every package present is something whose changes someone must track. Removing packages you never call removes that work — provided you track what you added in their place. - **Fewer moving parts.** An image with one artifact and three libraries has an obvious inventory; an image with a whole distribution does not. - **Less inside the boundary.** A smaller userland is less to reach for after something goes wrong inside the container. ## Choosing between the three 1. **Start from what the artifact needs at run time**, not from what the build needed. Those are different sets, and most of the second one has no business in the final image. 2. **If the workload needs a runtime or interpreter shipped alongside it**, an empty base is not a candidate; the runtime and its own library needs come with it. 3. **If the artifact is genuinely self-contained**, a near-empty base is straightforward and small. 4. **Decide who patches what you add**, before you strip. Hand-copied files have no publisher behind them. 5. **Decide how you will diagnose it** at three in the morning, when there is no prompt to be had inside the image. ## How teams get this wrong - Treating the choice as purely a size number, and discovering the missing certificate store in production rather than in the pipeline. - Stripping the base and copying half the distribution back in, one file at a time, until the image is the same size with none of the maintenance. - Assuming every minimal base is interchangeable with every other, when their library sets differ. - Planning to install the missing piece inside the running container, which is exactly what removing the package manager prevents.
- The start command worked on the full distribution base and does nothing on the minimal one. Why?It was almost certainly written as a shell line — a command with a redirect, a pipe, a variable expansion or a chained second command — and something had to interpret it. A full distribution base supplied that interpreter; the minimal one does not. Express the start command as a direct executable with its arguments listed, so nothing needs interpreting.
- Does a smaller base always mean less transferred across the estate?No. A host pulls only what it does not already hold. A slightly larger base that every image in the estate shares is pulled once per host and reused, while a unique tiny base per team is pulled once per team per host. Size matters most on first pull and on base changes, not on every deployment.
saying these in an interview costs you the question
- Thinks a minimal base only changes the image's size
- Assumes certificate verification works with no certificate store present
- Believes a compiled artifact always carries its own system libraries
- Treats an empty base as the right default for every workload
- Expects to install a missing tool inside a running minimal image