Docker Fundamentals · Module 01 of 12

Containers and Docker

Understand the problem containers solve, how containers differ from virtual machines, and where Docker Engine fits in the application lifecycle.

Learning objectives

By the end of this module, you should be able to:

Explain why teams package applications into container images.
Distinguish an image from a running container.
Compare containers with virtual machines without treating them as interchangeable.

The portability problem

Applications rarely consist of source code alone. They depend on runtimes, libraries, configuration and operating-system behavior. A package that works on one machine can fail elsewhere when those dependencies differ.

A container image packages an application with the filesystem content and metadata needed to run it consistently. Docker gives developers and operators a standard workflow to build that image, start containers from it and distribute the image through registries.

Image = immutable application package and metadata.
Container = runtime instance created from an image.
Registry = service used to store and distribute images.

Containers are isolated processes, not miniature VMs

On Linux, containers use kernel isolation mechanisms such as namespaces and cgroups. They share the host kernel rather than booting a separate guest kernel for every workload.

A virtual machine virtualizes hardware and normally boots a complete guest operating system. Containers are typically lighter and faster to start, while virtual machines provide a different isolation boundary and operating-system model.

Where Docker fits

Docker Engine manages images, containers, networks and volumes. The Docker CLI sends requests to the Engine API. Modern Docker Engine relies on lower-level container runtime components under the hood, but Fundamentals learners should focus first on the user-facing workflow: build, run, inspect, connect, persist and remove.

Worked examples

See the idea in practice.

Run a disposable container

docker run --rm hello-world

Docker pulls the image if it is not already local.
A container is created and started from the image.
--rm removes the stopped container automatically.

List local images and containers

docker image ls
docker ps
docker ps -a

docker image ls shows local image references.
docker ps shows running containers.
docker ps -a includes stopped containers.

Hands-on lab

Lab — Prove the image/container distinction

Goal: Create two containers from one image and observe that the image remains while container instances come and go.

Before you start

Docker Engine or Docker Desktop is installed and the docker CLI can reach the daemon.

STEP 1

Pull a small image

docker pull alpine:3.20

STEP 2

Create two independent containers

docker run --name dockerlab-one alpine:3.20 sh -c "echo one > /tmp/value; cat /tmp/value"
docker run --name dockerlab-two alpine:3.20 sh -c "echo two > /tmp/value; cat /tmp/value"

STEP 3

Inspect stopped containers and the shared image

docker ps -a --filter name=dockerlab-
docker image ls alpine:3.20

STEP 4

Clean up containers

docker rm dockerlab-one dockerlab-two

Verify

Both containers were created from alpine:3.20.
The containers have different IDs.
Removing containers does not remove the alpine image.

Expected outcome

The first container prints one and the second prints two.
docker image ls still shows alpine:3.20 after container removal.

If it fails

If the daemon is unreachable, verify the Docker service/Desktop is running and your account has permission to use it.
If image pull fails, verify DNS, proxy and registry connectivity.

Real-world connection

CI/CD systems routinely build one image and create many short-lived containers from that immutable artifact.

Avoid these traps

Common mistakes

Using the words image and container as if they mean the same thing.
Assuming a stopped container is automatically deleted.
Treating containers as a replacement for every virtual-machine use case.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What is the simplest distinction between an image and a container?

An image is the packaged template; a container is a runtime instance created from that image.

2Why can containers start quickly compared with many VMs?

They normally run isolated processes while sharing the host kernel instead of booting a full guest operating system.

3What does a registry provide?

Storage and distribution of container images.