Docker Introduction: Why Containers?

If you have ever heard a developer say "it works on my machine", you already understand the problem Docker was built to solve. Docker is a platform for packaging an application together with everything it needs to run - code, runtime, libraries, and system settings - into a single portable unit called a container. In this first lesson of our Docker series you will learn what containers are, why they beat older approaches, and how the core pieces of Docker fit together.

The Problem: Environments Drift

A typical web application depends on far more than its own source code. It needs a specific language runtime, a set of libraries, environment variables, and often system packages. When each developer, test server, and production server installs these pieces by hand, the environments slowly drift apart. An app that runs perfectly on a laptop with Node 20 may crash on a server running Node 16. Debugging these mismatches wastes enormous amounts of time.

Containers fix this by shipping the environment with the app. The same container image runs identically on your laptop, a teammate machine, a CI server, and a cloud host.

Containers vs Virtual Machines

Before containers, the standard isolation tool was the virtual machine. A VM emulates an entire computer, including its own operating system kernel, which makes it heavy: gigabytes of disk, minutes to boot, and significant memory overhead.

A container takes a lighter approach. All containers on a host share the host operating system kernel and are isolated using Linux features such as namespaces and cgroups. The result:

• Containers start in milliseconds instead of minutes
• Images are usually megabytes instead of gigabytes
• You can run dozens of containers on hardware that would struggle with a few VMs

VMs still matter when you need full kernel isolation, but for packaging and running applications, containers are the modern default.

The Core Concepts

Docker is built around a few ideas you will use constantly:

• Image: a read-only template containing your app and its environment. Think of it as a snapshot or a class.
• Container: a running instance of an image, like an object created from a class. You can start many containers from one image.
• Dockerfile: a text file with instructions for building an image.
• Registry: a server that stores and distributes images. Docker Hub is the default public registry.
• Docker Engine: the background service (daemon) that builds images and runs containers, controlled through the docker command line client.

Seeing It in Action

Once Docker is installed (covered in the next lesson), running your first container takes one command:

Behind the scenes Docker checks whether the hello-world image exists locally, downloads it from Docker Hub if not, creates a container from it, and runs it. A more useful example starts a real web server:

This launches the Nginx web server in the background and maps port 8080 on your machine to port 80 in the container. Visit http://localhost:8080 and you are serving pages from a container - without installing Nginx on your system at all.

Why Teams Adopt Docker

• Consistency: dev, test, and production run the same image.
• Speed: onboarding a new developer becomes "install Docker, run one command".
• Isolation: two apps needing conflicting library versions can run side by side.
• Density and cost: more workloads per server compared to VMs.
• Ecosystem: thousands of ready-made images for databases, caches, and tools.

Key Takeaways

• Docker packages an app plus its environment into a portable container.
• Containers share the host kernel, making them far lighter than virtual machines.
• Images are templates; containers are running instances of those images.
• Registries like Docker Hub distribute images so anyone can pull and run them.
• One command, docker run, can download and start a complete application.

Next up: Installing Docker and First Commands, where you will set up Docker on your own machine and learn the essential commands every Docker user relies on.