What is Docker? A Complete Introduction for Beginners

Beginner 10 min read

What you'll learn

✓What a container actually is, in concrete terms
✓How containers differ from virtual machines
✓The role of images, registries, and the Docker engine
✓Why Docker became the default packaging format for modern software
✓The vocabulary you will see in every later post

Prerequisites

•Comfort opening a terminal on Windows, macOS, or Linux
•No prior containers experience required

Docker is the tool that made containers mainstream. If you have ever struggled to run a project because it needed a different version of Node, Python, or PostgreSQL than the one already on your machine, Docker exists to make that problem go away. This post explains, in plain terms, what a container is and why it has become the default way to package, ship, and run software.

The problem Docker solves

Software depends on its environment. A web application written in Node 20 will not run on a machine that only has Node 14. A data pipeline that needs Python 3.12 and a specific build of numpy may break on a colleague’s laptop that has a slightly different setup. Production servers add another layer of variation — different Linux distributions, different system libraries, different file paths.

For decades, the standard fixes were either to write long setup instructions (“install these eight packages in this order”) or to ship a full virtual machine image. The first approach is fragile. The second is heavy.

Docker takes a third path. It packages an application together with everything it needs to run — language runtime, libraries, configuration, files — into a single, portable artifact called a container image. Anyone with Docker installed can run that image and get an identical environment, regardless of their host operating system.

Quick definition. A container is a running process that has been given its own isolated view of the filesystem, network, and process tree, while still sharing the host machine’s kernel. An image is the read-only template a container is created from.

Containers vs virtual machines

Containers are often compared to virtual machines, and it is worth being precise about the difference.

A virtual machine runs a full guest operating system on top of a hypervisor. Each VM has its own kernel, its own init process, and typically gigabytes of disk overhead before any application code is installed. Booting one takes tens of seconds.

A container does not include a kernel. It runs as a normal process on the host kernel, isolated using features built into Linux — namespaces and cgroups — so it sees only its own files, its own processes, and its own network interfaces. The image only contains the application and the user-space libraries it needs. A typical container image is tens to hundreds of megabytes, and a container starts in well under a second.

This is the key trade-off:

VMs give stronger isolation (separate kernels) at a higher cost (more RAM, slower startup, larger images).
Containers give lighter isolation (shared kernel) at a much lower cost, which is exactly what you want when you run many small services or want to spin up identical environments on demand.

On macOS and Windows, Docker Desktop runs a small Linux virtual machine in the background — because containers fundamentally need a Linux kernel — and presents it as if it were native. You generally do not need to think about that detail.

The core vocabulary

Five terms cover almost everything you will read in Docker documentation.

Image. A read-only template that contains the filesystem and metadata needed to run an application. Images are built from instructions in a Dockerfile.

Container. A running (or stopped) instance of an image. You can run many containers from the same image, just as you can launch many processes from the same executable.

Dockerfile. A plain-text file with step-by-step instructions for building an image — for example, “start from Node 20, copy these files in, install dependencies, run this command.”

Registry. A server that stores and distributes images. Docker Hub is the default public registry; companies typically also run private ones. When you run docker pull nginx, Docker fetches the nginx image from a registry.

Docker Engine. The background service (a daemon) that actually builds images and runs containers. The docker command you type in your terminal is a client that talks to the engine over a local socket.

Keep these five words in mind as you read on — every later post in this series builds on them.

A first concrete example

You do not need Docker installed to follow the shape of this example — we will install in the next post — but it helps to see what a typical workflow looks like.

# 1. Pull a prebuilt image from Docker Hub
docker pull nginx

# 2. Run it as a container, mapping host port 8080 to the
#    container's port 80
docker run -d -p 8080:80 --name web nginx

# 3. Visit http://localhost:8080 in your browser — you will
#    see the default nginx welcome page

# 4. Stop and remove the container
docker stop web
docker rm web

In four commands, you went from “no web server installed” to “running web server” and back, without touching the host system’s package manager or configuration files. Nothing about your machine has changed — no new system services, no edited config, no global packages.

That is the everyday value of Docker.

Try it yourself (after the next post). Once you have Docker installed, run the four commands above. Then try docker run -d -p 8081:80 --name web2 nginx. You now have two independent nginx containers running on two different ports, both from the same image. Stop and remove them when you are done.

Where Docker fits in your workflow

Docker is useful at three distinct stages of a project.

Local development. Instead of installing Postgres, Redis, and a message queue on your laptop, you describe them in a docker compose file and run docker compose up. When you switch to a different project that needs different versions, you do not have conflicts — each project gets its own isolated services.

Continuous integration. CI systems use Docker to give every build a clean, identical environment. Tests that pass on your laptop pass in CI because they run inside the same image.

Production. Containers are the unit of deployment in modern infrastructure. Whether you are using a managed platform (Fly.io, Render, Cloud Run) or an orchestrator (Kubernetes, Nomad), the artifact you ship is almost always a container image.

The same image can move through all three stages, which removes an enormous amount of “works on my machine” friction.

What Docker is not

A few common misconceptions are worth clearing up.

Docker is not a virtual machine. As discussed above, containers share the host kernel. You cannot run a Windows container on a Linux host (and vice versa) without help.

Docker is not a security boundary equivalent to a VM. Containers provide strong isolation for normal workloads, but for hostile multi-tenant scenarios you typically want VM-level isolation underneath.

Docker is not the only container runtime. Podman, containerd, and CRI-O all implement the same container concepts, often using the same image format. Docker is simply the most popular and the easiest to start with — and the skills transfer.

Docker does not magically make your application faster. A containerized app runs at essentially native speed, but Docker is a packaging and isolation tool, not a performance booster.

Try it yourself. Without running any code, write down — in your own words — the difference between an image and a container. Then write down what a registry is for. If both definitions feel solid, you are ready for the next post.

Why Docker won

A handful of decisions, made early, turned Docker from a curiosity into infrastructure:

A simple command-line interface that hid the complexity of Linux namespaces and cgroups
A standard image format that could be shared between machines and teams
A free public registry (Docker Hub) preloaded with official images for every major piece of open-source software
A declarative build file (Dockerfile) that made image creation reproducible
A consistent experience across Linux, macOS, and Windows via Docker Desktop

None of those ideas were brand-new, but Docker bundled them into a single tool with a gentle learning curve. The result is that today, “containerize it” is the default answer to “how do we ship this?” — and most cloud platforms expect a container image as input.

Recap

You now know:

A container is an isolated process running on the host kernel, built from a read-only image
Containers are lighter than virtual machines because they do not include their own kernel
A Dockerfile describes how to build an image; a registry stores and distributes images; the Docker engine runs them
Docker is used in local development, CI, and production — usually with the same image flowing through all three
Docker is a packaging and isolation tool, not a VM, not a magic performance boost, and not the only container runtime

Next steps

The next post is hands-on: you will install Docker on your machine and run your first container from scratch. We will check that everything is wired up correctly and finish with a small web server you can hit from your browser.

→ Next: Install Docker and Run Your First Container

Questions or feedback? Email codeloomdevv@gmail.com.