Lesson: Images, Containers & Layers

What you'll learn

Explain what a container is and how it differs from a virtual machine (VM).
Tell the difference between an image (the blueprint) and a container (a running instance).
Understand image layers and why they make containers small and fast.
Connect containers back to the Linux kernel features (namespaces & cgroups) you met in Module 2.
Run, list, inspect, and clean up containers with the everyday Docker commands.

By the end you can take any published image and run it as a live, isolated process on the lab — the foundation skill for everything else in this module.

The lesson

1. What problem do containers solve?

"It works on my machine" is the oldest complaint in software. Your app needs a specific version of a language runtime, some libraries, an environment variable or two — and the server it lands on has none of that, or has the wrong versions. A container packages your application together with everything it needs to run into one shippable unit. Run it on your laptop, on the lab VMs, or on a cloud server, and it behaves the same way.

A container is just a normal Linux process that has been isolated from the rest of the system. It thinks it has its own filesystem, its own network, and its own list of processes — but it is sharing the one Linux kernel of the host.

2. Container vs Virtual Machine

People often confuse the two. A VM virtualises hardware: a hypervisor boots a whole second operating system (its own kernel, its own init system) on top of fake hardware. That is heavy — gigabytes of disk, a full boot, lots of RAM.

A container virtualises the operating system: there is no second kernel. The host kernel is shared, and each container is just a fenced-off group of processes.

   VIRTUAL MACHINES                 CONTAINERS
 +----------+ +----------+      +--------+ +--------+ +--------+
 |  App A   | |  App B   |      | App A  | | App B  | | App C  |
 |  Libs    | |  Libs    |      | Libs   | | Libs   | | Libs   |
 | Guest OS | | Guest OS |      +--------+ +--------+ +--------+
 +----------+ +----------+      |   Container engine        |
 |     Hypervisor      |        |   Shared Host OS kernel   |
 +---------------------+        +---------------------------+
 |     Host OS         |        |        Hardware           |
 +---------------------+        +---------------------------+
 |     Hardware        |
 +---------------------+

Result: a container starts in milliseconds and is measured in megabytes, while a VM starts in tens of seconds and is measured in gigabytes. The trade-off is that containers must run on the same kernel as the host (Linux containers need a Linux kernel).

3. How isolation actually works (callback to Module 2)

The "fence" around a container is built from two Linux kernel features you learned about in Module 2:

Namespaces give a process its own view of a resource. A PID namespace makes the container see its app as process 1 with no knowledge of the host's other processes. There are namespaces for the network, mounts (filesystem), hostname, users, and more.
Control groups (cgroups) limit and account for what a process can use — how much CPU, how much memory. This is how you stop one container from eating the whole host.

So a container is not magic: it is namespaces (what you can see) + cgroups (what you can use) wrapped around an ordinary process. Docker and Podman just orchestrate those kernel features for you.

4. Images vs containers

This is the single most important distinction in the module:

An image is a read-only template: a packaged filesystem plus metadata (which command to run, which ports, etc.). It is inert, like a class in programming or an .iso file. Images live in registries and on your disk.
A container is a running instance of an image, like an object created from a class. You can start many containers from one image.

  IMAGE (read-only template)  --run-->  CONTAINER (live process)
       nginx:1.27                            nginx running, PID, IP
                              \--run-->  CONTAINER (another instance)

When a container starts, the engine adds a thin writable layer on top of the image. Files the container writes go there; the underlying image is never changed. Delete the container and that writable layer is gone — which is why containers are called ephemeral.

5. Layers and why they matter

Images are built in layers, stacked like transparent sheets. Each instruction in a build (install a package, copy a file) creates one layer. Layers are:

Cached — rebuild and unchanged layers are reused, so builds are fast.
Shared — if ten images all start FROM debian:12, that base layer is stored once on disk and reused.

  +--------------------------+  <- writable container layer (yours)
  +--------------------------+  <- COPY app code
  +--------------------------+  <- RUN install dependencies
  +--------------------------+  <- base image (e.g. debian:12)

You will exploit this caching deliberately in Chapter 5 when you write Dockerfiles.

6. Registries

A registry is a server that stores and serves images, like an app store for containers. Docker Hub is the public default. The lab runs its own private registry at 10.100.100.6 (the registry:2 image, protected with a username/password via htpasswd). You will push your own built images there later in this module. An image's full name looks like 10.100.100.6/myteam/myapp:sha-abc123.

7. The everyday commands

Docker is installed on the lab via the official get.docker.com script. Try these (the engine downloads the image the first time):

# Run a container in the background (-d), name it, publish a port
docker run -d --name web -p 8080:80 nginx:1.27

# List running containers (add -a to include stopped ones)
docker ps
docker ps -a

# Read a container's logs (-f follows live)
docker logs -f web

# Get an interactive shell inside a RUNNING container
docker exec -it web /bin/bash

# Run a one-off container interactively and remove it on exit
docker run -it --rm debian:12 /bin/bash

# Stop and remove
docker stop web
docker rm web

# See images stored locally
docker images

-it means interactive + allocate a terminal; --rm auto-deletes the container when it exits so you do not pile up junk. Practise these against the lab until run / ps / logs / exec / stop / rm are muscle memory.

Dig deeper

Search terms

containers vs virtual machines explained
docker image vs container difference
docker image layers copy-on-write
linux namespaces cgroups containers
docker run ps exec logs tutorial

Check yourself

In one sentence, what is the core difference between a container and a VM?
Which two Linux kernel features (from Module 2) provide a container's isolation, and what does each one do?
What is the relationship between an image and a container? Give the class/object analogy.
Why is data written inside a running container lost when you delete the container?
Write the command to run an nginx:1.27 container in the background, name it web, and publish host port 8080 to container port 80.