Container Images

A container image is a packaged filesystem plus instructions for starting a container. It gives you one named object to build, test, store, copy, and deploy.

The image is not the running application. It is the input that a container runtime uses to create a container. That distinction is the foundation for everything else in this course.

The problem an image solves

An application rarely consists of one executable. It may need a language runtime, shared libraries, certificates, configuration defaults, and static files. Installing those pieces by hand on every machine creates drift. Two machines can receive different versions or settings even when they are meant to run the same release.

An image packages the required files and runtime configuration together. You build it once, then move the same content through testing and deployment. The host still supplies a compatible kernel and container runtime. The image supplies the application environment above that kernel.

This gives you repeatable packaging, not universal portability. A Linux image does not include a Linux kernel. Its programs must match the operating system and processor architecture available at runtime.

Image, container, and registry

Keep three objects separate:

1. An image is stored content and runtime configuration.
2. A registry stores and distributes images.
3. A container is a runtime instance created from an image.

The common flow is:

source + build instructions -> image -> registry -> runtime -> container

You can create many containers from one image. Each starts with the same image content. Runtime settings and writable state can differ between containers.

The OCI image model

The Open Container Initiative, or OCI, defines a standard image format. Its core objects are a manifest, a configuration object, and filesystem layers. Descriptors connect those objects.

An image manifest points to one configuration object and an ordered list of layers. A descriptor records the media type, byte size, and digest of referenced content. The configuration records execution parameters and the ordered layer identities that form the root filesystem.

The simplified structure looks like this:

image manifest
├── configuration descriptor -> runtime defaults and platform metadata
└── layer descriptors
    ├── base filesystem changes
    ├── installed dependencies
    └── application files

The manifest does not embed every file. It references content blobs by descriptor. A registry can store identical blobs once and let several manifests reference them.

Layers are ordered changes

A layer is a filesystem changeset. It can add, modify, or remove paths relative to the layers below it. The runtime applies layers in order to produce the image root filesystem.

Layers are immutable after creation. Changing an application file does not edit an existing layer. A new build produces new content and a new manifest.

Layering supports reuse. Two images based on the same base image can share its unchanged blobs. A client can also skip downloading a blob already present in its local content store.

Layering has an important limit. A later layer can hide a file from the final filesystem, but it does not erase the file from an earlier distributed layer. Never place secrets in a build context or image layer. Supply secrets through a protected build or runtime mechanism.

Configuration completes the package

Filesystem content alone does not explain how to start an application. Image configuration can declare a default executable, arguments, environment values, working directory, user, and exposed ports. It also identifies the target operating system and architecture.

These values are defaults. A container engine or orchestrator can override many of them when it creates a container. Image configuration describes the intended starting point; runtime configuration describes a particular container.

Treat configuration metadata as visible image content. Do not place credentials in environment defaults, labels, or build arguments that become part of the image.

Tags and digests answer different questions

An image reference often ends with a tag:

registry.example/team/payments:2.4

The registry host identifies the service. The repository path groups related content. The tag is a human-readable pointer to a manifest.

A tag can move. A publisher may update 2.4 or latest to point to a newer manifest. That behavior is useful for release channels, but a tag alone does not identify fixed content.

A digest is derived from content:

registry.example/team/payments@sha256:...

If the referenced bytes change, the digest changes. Use a digest when you need an exact deployment or audit reference. Use a meaningful tag to communicate release intent. Many teams record both: the tag for people and the resolved digest for machines.

A digest verifies content identity after you obtain a trusted expected value. It does not tell you who produced the image, whether its packages are vulnerable, or whether its behavior is safe.

Registries distribute content

A registry exposes APIs for pushing and pulling manifests and blobs. A repository is a scope within that registry for related manifests, blobs, and tags.

During a push, the client uploads missing blobs and then the manifest. During a pull, the client resolves a tag or digest, retrieves the manifest, and downloads missing referenced blobs. Content addressing lets the client verify each object against its digest.

Registry access, retention, replication, and trust policies are operational concerns outside the image format. An OCI-compatible image can move between compatible tools, but each registry still has its own authentication and governance.

One name, several platforms

A single-platform image manifest describes one configuration and one layer set. An image index can point to several manifests, each with platform information such as operating system and processor architecture.

This makes one tag usable across several platforms:

image index
├── linux on amd64 -> image manifest -> config + layers
└── linux on arm64 -> image manifest -> config + layers

The client selects a compatible manifest before pulling its configuration and layers. The platform variants are distinct images with distinct digests. Test every platform you publish; a successful build for one architecture does not prove another variant works.

Build for repeatability and maintenance

A build tool turns a build context and instructions into an image. The build context is the set of files available to the build. Exclude files that are not required. This reduces transfer size and lowers the chance of copying private material into a layer.

Order build steps so stable, expensive work can be reused from the build cache. Copy dependency declarations before frequently changing source files when the tool and language allow it. Cache reuse improves speed, but it does not make a stale dependency current.

Use multi-stage builds when compilation needs tools that the running application does not need. Build in one stage, then copy only the runtime result into a smaller final stage.

Choose a maintained base image from a trusted source. Keep the final image focused. Remove unnecessary packages and rebuild regularly with reviewed dependency updates. Immutability means an old image remains old; it does not update itself after publication.

Reproducibility and freshness pull in different directions

Pinning a base image by digest makes the selected input repeatable. It also prevents an updated base from arriving automatically. A sound update process does both jobs deliberately:

1. Pin the reviewed digest.
2. Monitor for a newer acceptable base.
3. Update the pin through version control.
4. Rebuild and test the application image.
5. Deploy the new image by its resolved digest.

Tags help you discover updates. Digests help you control exactly when those updates enter a build or deployment.

What an image does not guarantee

An image standard gives tools a common package format. It does not guarantee that the package is small, current, trusted, compatible with your host, or safe to run.

Before production use, identify the publisher and source, inspect platform support, scan relevant packages, review configuration defaults, and test the image under the intended runtime policy. Record the exact digest you approved.

Container image security is a broader discipline. It includes provenance, signatures, software bills of materials, vulnerability management, registry controls, and build-system protection. This course gives you the image model needed to reason about those controls.

When container images fit

Container images fit applications that benefit from a portable, versioned user-space package. They work well for services, command-line tools, batch jobs, build environments, and orchestrated workloads.

They fit poorly as a substitute for full machine management. An image is not a guest operating system, persistent data store, secret store, or hardware abstraction layer. Choose a virtual machine when you need a separate kernel or machine boundary. Keep durable data outside the replaceable container filesystem.

Your path forward

First, learn to read an image reference and distinguish a tag from a digest. Next, inspect a manifest, configuration, and layer history. Then build a small image and trace how each instruction affects its content.

After that, practice cache-aware and multi-stage builds. Add multi-platform output only when you can test each target. Finally, study image provenance, signing, vulnerability management, and deployment policy.