Don't Panic: Container Images

A container image is a prepared application environment: files plus instructions for starting them. Before images, keeping two machines ready for the same release meant repeated installations and hopeful comparison of libraries, certificates, and settings. An image makes that environment one named thing to build, test, store, copy, and deploy. The host still supplies the kernel, because an image is not a tiny operating system in a trench coat.

The first useful distinction is image versus container. The image is stored content and runtime defaults. A container is one running instance made from it. One image can create many containers, each with different runtime settings and writable state. A registry is the delivery warehouse between build and runtime, holding the manifests and blobs that clients push and pull.

The central paperwork is the image manifest. It points to configuration and an ordered list of layers. A layer is a filesystem changeset, so later layers can add, modify, or hide paths from earlier ones. Hiding is not erasing, which is an awkward fact with excellent timing: a secret copied into an earlier layer remains in that blob even if a later step removes the file. Keep secrets out of the build context and layers.

A tag is the label people recognize, such as a release channel. It can move. A digest identifies exact bytes and changes when those bytes change. That makes a tag useful for communication and a resolved digest useful for approval or audit. Neither proves the publisher, freshness, or safe behavior. Those questions need separate evidence, because images decline to solve every operational problem merely by being neatly packaged.

Read the intro and cheatsheet for the manifest, configuration, layers, descriptor, and image index. The slides compress the delivery path and tag-versus-digest choice. The practice reference gives local inspection commands, and the exercise makes you inspect a two-stage image and multi-platform index. Then follow the reference links into provenance, signing, vulnerability management, and deployment policy.