After moving a service image to a near-empty base, who patches the system libraries it still carries?

## Two patch streams, not one An image is immutable once built. Patching it therefore always means **build a new image and replace the running containers** — never changing something in place. What differs between base choices is not that mechanic; it is *who notices that a change is needed*, and *how many things they have to notice*. - **The base publisher's stream.** Whoever publishes the base maintains the packages inside it and republishes when they change. You consume that by rebuilding on the newer base — a **rebase** — and redeploying. You do not have to know which package moved. - **Your stream.** Everything the build copied on top: your artifact, its own dependencies, and, on a stripped base, the system libraries, the trusted-certificate bundle and the data files you supplied by hand. Nobody else is watching these on your behalf. Stripping the base shifts volume from the first stream into the second. That is a good trade when the second stream is small and tracked. It is a bad one when the second stream is untracked, because untracked means it never moves at all. ## What the strip actually moved | Base | Who maintains the userland | How you learn a change is needed | What a fix costs you | |---|---|---|---| | Full distribution | The base publisher, for a broad package set | Rebase on a schedule and take everything | One rebuild; you need not know what changed | | Minimal | The base publisher, for a small set | Rebase, plus watching whatever you added | One rebuild, plus deciding about your own additions | | Empty | Nobody — the image is only what you copied | Only what you track yourself | One rebuild, and you must first know it is needed | Read the middle column, not the first. The base's size is the headline, but the column that decides how long a fix takes to reach production is *how you find out*. ## The monthly rebuild on several hundred hosts A common misreading is that a large base makes the monthly patch expensive because hundreds of hosts re-transfer hundreds of megabytes. That is not how it lands: - A host pulls only what it does not already hold. A rebuild that changes your artifact and nothing else transfers those changed layers, not the whole image. - The base's size is paid on the **first** pull by each host, and again whenever the base itself changes. - A base shared across many of your images is pulled once per host and reused by all of them; a unique base per team is not. So base size is a real cost with a specific shape — first pull per host, plus every rebase — rather than a monthly bill multiplied by the fleet. The cost that *does* scale with the estate is the number of distinct images someone must rebuild and redeploy when something in a base changes. ## Making the second stream real 1. **Record what you copied in.** A list of the system libraries, bundles and data files the build adds, kept with the build rather than in someone's memory. 2. **Give each entry a source.** Where it came from and what to watch for changes. An entry with no source is one you will never patch. 3. **Make a base change trigger a rebuild.** A newer base that nothing rebuilds on is a fix you did not take. 4. **Rebuild and redeploy on a cadence you can defend**, not only when something forces you. Monthly is a common answer; the number matters less than that it happens without a crisis. 5. **Measure the lag.** Time from a base publishing a change to every image in the estate running on it. That number is the honest description of your patch posture. ## Where teams get trapped - **Treating the base as fixed forever once the image builds.** The image keeps working, which is exactly why nobody revisits it, and the userland inside slowly falls years behind. - **Copying files in with no record of what or from where**, so the second stream exists but cannot be acted on. - **Believing a small image needs no patching.** Fewer components means fewer changes, not none; the ones that remain are the ones your process actually calls. - **Trying to patch a running container**, which changes nothing about the next replica that starts from the same image. - **Optimising the size number** while the rebuild-and-redeploy path stays manual, which is the only part of this that determines how fast a fix lands. ## The direction to state clearly Stripping the base does not remove patch work; it relocates it from a publisher you inherited to a team you are on. That is often the right call — a small, known set of components that you actually call is easier to keep current than a broad distribution you mostly do not. It is only the right call if the relocation is acknowledged, which is what an interviewer is listening for.