Containers & Images
Containers from the operations side — the OS internals live in the Operating Systems domain. Image composition and layers, the build pipeline, why image size is an operational and security concern, registries and digests, configuration kept out of images, and where state is allowed to live.
What containerizing a workload actually changes for the people who run it: one immutable artifact carries the application, its runtime and its dependencies, so the bytes that passed CI are the bytes production starts.
Q · What does packaging a workload as a container actually change for the team that has to run it in production?
A VM virtualizes hardware and boots its own kernel; a container is an isolated process on a kernel it shares. That single difference sets startup time, density, portability — and the strength of the security boundary, which is the axis people skip.
Q · When does a workload need its own kernel, and when is an isolated process on a shared kernel enough?
An image is an ordered stack of read-only layers plus a metadata document. Understanding that stack explains build caching, why images share disk, why a rebuild changes bytes you did not touch, and why anything written into a layer is permanent.
Q · What is actually inside a container image, and why does its internal structure change how you build and ship?
Dockerfile, build, image, container, registry, volume, network, published port: eight nouns that cover almost everything a team does day to day. They are the vocabulary of one popular toolchain, not the definition of containers.
Q · What is the minimum working vocabulary for operating containers, and which parts of it are Docker rather than containers?
Source → Dockerfile → build → image → registry → deployment. Six states, each with its own failure mode, its own identity, and one rule that holds them together: build the artifact once and promote the same bytes.
Q · How does a commit become the exact artifact that production runs, and where does that chain usually break?
A large image is slower to pull, slower to deploy, more expensive to move, and carries more software an attacker can use. The one that hurts most is the one nobody attributes to it: new capacity arrives late because it is still downloading.
Q · What does an extra gigabyte of image actually cost, and where does that cost land?
The registry is the boundary between "built" and "deployable", and the one component every host in the fleet pulls from. Tags are mutable pointers, digests are the artifact, and :latest in a production manifest is the classic finding.
Q · Where do images live between build and deployment, and how do you know the thing production pulled is the thing you tested?
Application Image + Environment Configuration = Running Workload. One artifact promoted through every environment, with configuration injected at start — and never a secret in a layer, because a layer is forever and docker history reads it back.
Q · What belongs inside the image, what is injected at start, and where do secrets actually live?
A container is a replaceable compute unit with a disposable filesystem. Anything that must survive a restart, a rescheduling or a node failure lives outside it — in a volume, a managed database or an object store.
Q · Where is a workload allowed to write, and what happens to everything else it writes?