Docker Basics

Every developer has heard it. Every operations engineer has dreaded it.

"It works on my machine."

This phrase represents hours of debugging, fingers pointed across teams, and the quiet desperation of trying to figure out why code that runs perfectly in development crashes mysteriously in production. Different library versions. Missing environment variables. Subtle OS differences. The gap between "my machine" and "the server" has consumed countless engineering hours.

Docker makes this problem disappear.

What Docker Actually Does

Docker packages your application and everything it needs to run—code, runtime, libraries, configuration—into a single artifact called a container. That container runs identically whether it's on your laptop, a test server, or a production cluster in the cloud.

The container carries its own environment with it. No more "did you install the right version of Node?" No more "the production server has a different OpenSSL." The container is the environment.

The Core Concepts

Images are blueprints. An image contains your application code, its runtime (Node.js, Python, Go—whatever it needs), system libraries, and configuration. Images are built from a Dockerfile and are read-only.

Containers are images brought to life. When you run an image, Docker creates a container—an isolated instance with its own filesystem, network, and processes. Run the same image ten times, get ten independent containers.

Dockerfile is a recipe. It's a text file that says: start from this base, copy these files, install these dependencies, run this command. Deterministic. Repeatable. Version-controlled.

Docker Hub is a library. Thousands of pre-built images—official Node.js, Python, PostgreSQL, Redis—ready to use as starting points.

Containers vs. Virtual Machines

Both provide isolation. The difference is what they isolate.

A virtual machine virtualizes hardware. It runs a complete operating system—kernel, system files, everything. Your application runs inside that OS, which runs on virtualized hardware, which runs on actual hardware. VMs consume gigabytes of disk and significant memory. They take minutes to start.

A container shares the host's kernel. It virtualizes only the user space—your application sees its own filesystem, its own network interfaces, its own process tree, but the kernel underneath is shared. Containers consume megabytes. They start in seconds.

Here's the intuition: A VM is like shipping your entire house to mail a letter. A container is like shipping just the letter—with very precise instructions for what kind of desk to read it on.

VMs provide stronger isolation (separate kernels mean kernel exploits can't spread). Containers provide sufficient isolation for most applications while being dramatically more efficient. Use VMs when you need to run different operating systems or require ironclad security boundaries. Use containers for everything else.

A Real Workflow

Create a Dockerfile:

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]

Build an image:

docker build -t myapp:1.0 .

Run a container:

docker run -p 3000:3000 myapp:1.0

That's it. Your application is now running in an isolated container, accessible on port 3000. The same commands work on any machine with Docker installed.

Why Teams Adopt Docker

"It works on my machine" dies. Development, testing, staging, production—they all run the same container. Environment discrepancies become impossible.

Onboarding becomes trivial. New developer? docker-compose up. They're running the full application stack in minutes, not hours of installing dependencies and debugging configuration.

Density increases. Because containers share the kernel, you can run far more containers on a server than VMs. The same hardware supports more applications.

Deployment becomes deterministic. Deploy image version 1.2.3 to production. Something breaks? Deploy 1.2.2. The images are immutable artifacts—what you tested is what you deploy.

Microservices become practical. Each service in its own container, with its own dependencies, scaling independently. Docker didn't invent microservices, but it made them manageable.

Docker Compose: Multiple Containers

Real applications have multiple parts. A web server. A database. Maybe a cache. Docker Compose orchestrates them together:

version: '3'
services:
  web:
    build: .
    ports:
      - "3000:3000"
  database:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: secret

One command—docker-compose up—starts both containers with proper networking between them. The web service can reach the database at hostname database. No manual network configuration.

The Commands You'll Use

docker build creates images from Dockerfiles.

docker run creates and starts containers.

docker ps lists running containers.

docker stop and docker start control container lifecycle.

docker logs shows what a container has printed.

docker exec runs commands inside a running container (useful for debugging).

docker-compose up and docker-compose down start and stop multi-container applications.

What Docker Doesn't Solve

Persistent data needs care. Container filesystems are ephemeral—when the container stops, changes disappear. Databases and other stateful applications need volumes to persist data outside the container.

Security requires attention. Containers share the kernel. A kernel vulnerability affects all containers on that host. Running containers as root (the default) increases risk. Production deployments need hardening.

Orchestration is a separate problem. Docker runs containers. Running hundreds of containers across dozens of servers, handling failures, scaling up and down—that's orchestration. Kubernetes exists because Docker alone isn't enough at scale.

Linux-centric by nature. Docker containers share the host OS kernel. Linux containers need a Linux kernel. Windows containers exist but are less mature. On macOS, Docker runs a Linux VM behind the scenes.