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.