What Docker Solves

What is it? #

Docker packages an application together with everything it needs to run: the runtime, the libraries, the system packages and the configuration.

The problem it addresses is environment difference. Code that works on one machine fails on another because the Python version differs, a system library is missing, or an environment variable is not set.

A container is a process running with its own filesystem view and isolated resources. It shares the host kernel, which is why it starts in milliseconds rather than the seconds a virtual machine needs.

The cost is real: another layer to learn, debug and operate. For a single application on a single server, it is often not worth it.

Think of it like this #

Shipping containers. Before them, every cargo was loaded differently and every port needed different equipment.

The container did not make goods better. It made them uniform to handle, so any crane, ship or lorry could move any container without knowing what was inside.

Simple example #

An application needs Python 3.12, a specific image library and a particular locale. On your laptop it works; on the server the locale is missing and dates format differently. A container carries all three, so both machines behave identically.

Code #

Virtual machine                      Container

┌─────────────────────┐              ┌─────────────────────┐
│  app  │  app  │ app │              │  app  │  app  │ app │
├───────┼───────┼─────┤              ├───────┼───────┼─────┤
│  OS   │  OS   │ OS  │              │ libs  │ libs  │libs │
├───────┴───────┴─────┤              ├───────┴───────┴─────┤
│     hypervisor      │              │   container runtime │
├─────────────────────┤              ├─────────────────────┤
│      host OS        │              │      host OS        │
└─────────────────────┘              └─────────────────────┘

each VM: its own kernel,             containers share the host kernel,
gigabytes, seconds to boot           megabytes, milliseconds to start

# The whole idea in four commands
docker run hello-world                 # pull an image and run it
docker run -it --rm ubuntu:24.04 bash  # a shell in a clean Ubuntu, then discarded
docker run -d -p 8080:80 nginx         # a web server on port 8080, in the background
docker ps                              # what is running

What containers genuinely give you

identical environments    the same image runs the same way everywhere
fast startup              milliseconds, which makes scaling and CI practical
isolation                 dependencies do not conflict between applications
reproducible builds       the Dockerfile is the environment, in version control
easy cleanup              remove the container and nothing is left behind

When Docker is NOT worth it

- one simple application on one server that rarely changes
- a team with no container experience and no time to build it
- workloads needing direct hardware access or unusual kernel features
- when a managed platform already solves the same problem

Docker is a tool, not a requirement. The VPS track deploys real
applications without it perfectly well.

How it works #

A container is an ordinary Linux process with restricted visibility. Namespaces give it its own view of the filesystem, network and process list; cgroups limit its CPU and memory.

Because it shares the host kernel, there is no operating system to boot. Starting a container is starting a process, which is why it takes milliseconds.

The image is a stack of read-only layers containing the filesystem. Running a container adds a thin writable layer on top, which is discarded when the container is removed.

That disposability is the key behavioural difference. Anything written inside a container is gone unless it was written to a volume, which the volumes lesson covers.

Sharing the kernel also means a container cannot run a different operating system. Linux containers on Windows or macOS run inside a hidden Linux virtual machine, which is why file access can be slower there.

The isolation is good but weaker than a virtual machine's, since a kernel vulnerability affects every container on the host. For multi-tenant workloads, that distinction matters.

Real-world use #

Containers are now the default packaging format for server software. Most projects publish images, and most deployment platforms accept them.

The strongest practical benefit for a team is consistency: the same image runs in CI, in staging and in production, which removes a large category of environment-specific bugs.

CI pipelines benefit enormously. A clean, identical environment per run in seconds is what makes reliable automated testing practical.

Local development with several services — an application, a database, a cache, a queue — becomes one command with Compose instead of installing four things on each developer's machine.

The honest counterweight is that containers add operational complexity. A single-server deployment with systemd is simpler, and simpler is a genuine advantage.

Common mistakes #

• Adopting Docker for a simple single-server application that did not need it.
• Expecting virtual machine level isolation from containers.
• Assuming data written inside a container persists after it is removed.
• Trying to run a different operating system than the host kernel.
• Treating containers as small virtual machines rather than as processes.

Practice #

Run an interactive Ubuntu container, install a package inside it, exit, and start a new one — then observe that the package is gone. Then run Nginx in the background with a published port, confirm it responds, and remove it.