3 Containers and Containerization
Learn how containers, images, registries, and runtimes work together, and how container isolation compares with virtual machines.
fundamentals
A is an application process running in an isolated environment on a host operating system. It can have its own view of files, processes, networking, and other system resources, while the host kernel provides operating-system services underneath. Containerization packages an application and its dependencies so it can run consistently across compatible systems.
Operating-system features enable containerization by isolating processes and controlling resource use. Containers are lightweight compared with full virtual machines, but they should not be treated as an infallible security boundary: configuration and host security still matter.
For example, a web application might run in one and its database in another. The containers can be started, stopped, updated, and scaled independently. Containers are often treated as disposable; if one is removed, data stored only in its writable layer may be lost. Store persistent data separately, such as in a volume.
Images and image versions
A is a read-only packaged template containing the files and configuration needed to start an application, such as application code, libraries, and a language runtime. Images are built in layers, which can be reused when building or downloading related images. An image itself does not change when a runs; changes made by the running go into a separate writable layer.
The distinction is that an image is the packaged template, while a is a running or stopped instance created from that template. Multiple containers can be started from the same image, and each has its own runtime state.
A is a human-readable image-version label, such as python:3.12. Because tags can be reassigned, a alone does not guarantee that the same image will always be selected. A identifies particular image content more precisely.
Registries and image trust
A stores and distributes images. It contains repositories, and repositories contain images identified by tags or digests. Docker Hub is one example; organizations also use private registries or registries provided by cloud providers.
A typical workflow is to build an image, push it to a registry, and have a host pull it before starting a . Treat images as software supply-chain inputs: use trusted publishers, verify image identity where appropriate, and keep images updated. A familiar image name alone does not prove that an image is trustworthy.
Runtimes and starting containers
A is software that sets up and runs containers. It obtains or uses an image, configures the ’s isolated environment and resource controls, and starts the application process. Docker Engine provides tools for building and managing containers; lower-level runtime components such as containerd and runc are commonly involved in starting them. In Kubernetes, each node needs a runtime compatible with Kubernetes’ Interface (CRI).
This Docker example downloads an image if it is not already available locally, then creates and starts a from it:
The -p 8080:80 option maps port 8080 on the host to port 80 in the . The latest is convenient for exploration, but reproducible deployments should use a deliberately chosen version or image .
Containers and virtual machines
Containers and virtual machines both provide isolation, but do so differently. A hypervisor runs virtual machines, each with a guest operating system and its own kernel. Containers are isolated processes that generally share the host’s kernel.
The shared-kernel design usually makes containers quicker to start and more resource-efficient. Virtual machines typically have higher overhead because each runs a guest operating system, but a VM can run a different guest operating system and typically provides a stronger isolation boundary. Containers still need a compatible host kernel.
Linux containers on Windows or macOS are commonly run inside a Linux VM managed by the software. Containers and VMs can also be used together: a cloud VM can serve as the host for multiple containers.