A Bottom‑Up Learning Path for Containers

Container Learning Path

Since 2015 the author has used containers and initially thought of them as lightweight virtual machines, a view that made it easy to follow tutorials that simply wrap Python or Node apps but prevented answering three key questions: what containers can and cannot do, what best practices exist, and what is safe to place inside a container.

Realising that the "container‑as‑VM" model is misleading, the author dug deeper, using Docker as the entry point because it is a massive, easy‑to‑run tool (e.g., docker run nginx) that can obscure the underlying concepts. Existing Docker material is either too shallow or too deep, so the author created a structured learning path for readers.

Linux containers – study the low‑level implementation details.

Container images – understand what an image is and why it is needed.

Container manager – learn how Docker manages containers on a single host.

Container orchestrator – see how Kubernetes manages containers across a cluster.

Non‑Linux containers – explore other container implementations to broaden perspective.

Containers Are Not Virtual Machines

A container is an isolated process (namespace) that is constrained by cgroups, capabilities, and seccomp. This definition helps the author grasp what a container really is, even though it is not absolutely precise.

To start a process on Linux you fork/exec it. To start a containerized process you first create namespaces, configure cgroups, etc.—in other words you prepare a box for the process. A container runtime is the tool that prepares the box and then launches the process inside it, and most runtimes follow common specifications, making a container a standard workload unit.

The most widely used runtime is runc, a simple command‑line tool that can be used without Docker or any higher‑level container software.

Running a container does not strictly require an image. For those familiar with how runc starts a container, a bundle is needed, consisting of:

A config.json file containing container parameters such as the executable path and environment variables.

A directory with the executable and its related files (if any).

The bundle’s directory layout resembles a Linux distribution’s filesystem ( /var, /usr, /lib, /etc, …). When runc launches the container, the process sees a root filesystem that looks like a typical Linux distro (e.g., Debian, CentOS, Alpine).

That layout is not mandatory. Modern “scratch” or “distroless” containers are tiny and reduce the attack surface. The author later showed how to build a container that contains only a Go binary and demonstrated inspecting such an image with dive.

Why keep images then? If every container carried a full copy of the root filesystem, disk usage would explode. Images solve storage and distribution problems efficiently.

Single‑Host Container Manager

Containers improve server resource utilization much like containers on a ship increase cargo capacity. A typical server now runs dozens or hundreds of containers, so a manager is needed to handle coexistence on a single host.

The manager’s responsibilities include pulling and unpacking images, configuring container‑to‑container networking, storing logs, etc. Docker is a familiar example, but the author finds containerd more representative. Like runc, containerd started as a Docker component and later became an independent project. It can use runc or any runtime that implements the containerd‑shim interface, and it can be used directly from the command line much like Docker.

Docker’s layered architecture consists of: dockerd – a higher‑level daemon that sits in front of containerd. docker – the CLI client that talks to dockerd.

Docker’s main goal is to make the container workflow friendlier, bundling the major use cases (build/pull/push/scan images; start/stop/inspect/kill containers; create networks/port mappings; mount/unmount/delete volumes; etc.) into a single tool.

Since 2021 many use‑case‑specific tools (e.g., podman, buildah, skopeo, kaniko) have emerged as better alternatives to Docker for particular tasks.

Multi‑Host Orchestrator

Coordinating containers on multiple hosts is far harder than on a single host. Docker Swarm was once the built‑in solution, but Kubernetes won the race and has been the dominant orchestrator since around 2020.

Kubernetes groups servers (nodes) into a cluster; each node runs a local agent called kubelet that starts Pods (groups of containers). Historically kubelet used dockerd, but that has been replaced by the generic Container Runtime Interface (CRI), allowing runtimes such as containerd or cri‑o to be used.

An orchestrator must handle many tasks, including:

Grouping containers with higher‑level primitives (Pods, ReplicaSets, etc.).

Connecting nodes to a common network.

Providing service discovery.

Other responsibilities.

Kubernetes (and alternatives like Nomad or AWS ECS) simplify service creation for development teams, especially at large scale, but they also introduce new challenges not present with traditional VMs, giving rise to the “cloud‑native zoo” of projects.

Some Containers Are Actually Virtual Machines

From an implementation standpoint, containers are not Linux processes; they are isolated, constrained environments that can run one or more processes. Some projects (e.g., Kata) implement containers using real virtual machines. Open standards such as OCI Runtime Spec, OCI Image Spec, and Kubernetes CRI allow VM‑based containers to be used by higher‑level tools without major changes.

Conclusion

Understanding containers solely through Docker or Kubernetes leaves many blind spots. A better approach is to start from the broader ecosystem and decompose it layer by layer, gaining knowledge at each step:

Container runtime – Linux namespaces and cgroups.

Container image – why it exists and how it works.

Container manager – enabling multiple containers to coexist on a single host.

Container orchestrator – combining multiple hosts into a cluster.

Container standards – generalising container knowledge.

Original link: https://iximiuz.com/en/posts/container-learning-path/