What Is Docker

You deploy your application to production. It works locally. Your teammate pulls the latest code, installs dependencies, and — boom — something breaks. The familiar chorus of "it works on my machine" echoes across the room. This friction — environment inconsistency — wastes hours, delays releases, and erodes confidence. Docker solves this by packaging your application with everything it needs to run: code, runtime, system tools, libraries, and settings. Once packaged, that container runs identically on any machine that has Docker installed. This lesson unpacks what Docker is and why it matters for modern development.

The problem this lesson solves

Before Docker, every deployment required careful environment setup: install Python 3.10, pin exact library versions, configure OS-level dependencies, and pray the production server had the same glibc version. Teams relied on long setup scripts, manual checklists, and often discovered mismatches only after deployment.

The core pain points: - Environment drift: Your laptop and the production server diverge over time, causing bugs that are hard to replicate. - Dependency hell: Library A needs patched OpenSSL; Library B needs unpatched OpenSSL. Stuck. - Onboarding friction: New developers spend days installing tools and fighting obscure OS-specific errors. - CI/CD variability: Tests pass on your machine but fail on the CI server because of slight environment differences.

Docker eliminates "works on my machine" by bundling the application with its full execution environment into a container image — a lightweight, standalone, executable package.

Core concept / mental model

Think of Docker containers as standardized shipping containers for software. A shipping container can carry any cargo — electronics, grain, cars — and it fits onto any ship, truck, or train around the globe because of a uniform interface (size, corner castings). Similarly, a Docker container can carry any application and its dependencies, and it runs on any system that has a Docker engine.

Key terms

Mental model: A container image is the "blueprint," a container is the "running house," and a Dockerfile is the "construction plan."

What makes containers different from virtual machines?

Traditional virtual machines (VMs) virtualize hardware — each VM includes a full guest operating system, kernel, and virtual devices. This is heavy and slow to start. Containers virtualize the operating system — they share the host kernel but isolate the application process and its filesystem.

This means you can run dozens of containers on a single laptop with negligible overhead.

How it works step by step

Docker uses client-server architecture. You interact with the Docker daemon via a command-line client.

1. Write a Dockerfile — define the application environment (base OS, dependencies, code copy, commands).
2. Build the image — docker build . reads the Dockerfile, executes each instruction, and produces an image. Each instruction creates a cached layer, enabling fast rebuilds.
3. Run a container — docker run <image> creates a writable container layer on top of the immutable image layers and starts the process inside.
4. Share or distribute — push the image to a registry (docker push), and anyone can pull and run it (docker pull) with zero setup beyond having Docker installed.

Pro tip: Image layers are cached. If you change your code but not your dependencies, only the layer with code changes is rebuilt. This makes development iteration fast.

Lifecycle of a container: - Created from a base image or scratch. - Starts in its own isolated filesystem, network, and process namespace. - Runs the defined command (e.g., python app.py). - When the main process exits, the container stops — unless you restart it.

Hands-on walkthrough

Let's Dockerize a minimal Python app and see the magic. Ensure you have Docker Desktop installed (download from docker.com). Run these commands in your terminal.

Step 1: Create a simple Python app

# app.py
from http.server import HTTPServer, BaseHTTPRequestHandler

class HelloHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Hello from Docker!\n")

if __name__ == "__main__":
    server = HTTPServer(("0.0.0.0", 8000), HelloHandler)
    print("Server running on port 8000...")
    server.serve_forever()

Step 2: Write a Dockerfile

Create a file named Dockerfile (no extension) in the same directory:

# Use an official Python 3.10 image as the base
FROM python:3.10-slim

# Set working directory inside the container
WORKDIR /app

# Copy the app file into the container
COPY app.py .

# Command to run when the container starts
CMD ["python", "app.py"]

Step 3: Build the image

docker build -t hello-docker .

Expected output (last lines):

Successfully built abc123
Successfully tagged hello-docker:latest

Step 4: Run the container

docker run -p 4000:8000 hello-docker

• -p 4000:8000 maps your machine's port 4000 to the container's port 8000.
• You should see: Server running on port 8000...

Now open a browser to http://localhost:4000. You'll see Hello from Docker!.

Step 5: Stop the container

Press Ctrl+C in the terminal running the container.

Pro tip: Use docker ps to list running containers and docker stop <container_id> to stop them gracefully.

Compare options / when to choose what

Docker is not the only container runtime, but it's the most popular and user-friendly.

For most developers starting with containers, Docker is the right choice. It has the largest ecosystem, best documentation, and integrates with nearly every CI/CD tool.

Troubleshooting & edge cases

Common errors

Edge case: Container exits immediately

If your container runs and exits right away, check the command. A web server stays running until you stop it. A script that finishes its work will exit. Use docker logs <container_id> to see the output.

docker run --name test hello-docker
# If it exits, check logs
docker logs test

Edge case: Permission issues on Linux

Add your user to the docker group to run Docker without sudo:

sudo usermod -aG docker $USER
newgrp docker  # or log out and back in

What you learned & what's next

This lesson introduced you to the central pain point Docker solves — environment inconsistency — and gave you a mental model of containers as standardized shipping containers. You built a real Docker image from a Dockerfile, ran a container, and mapped ports to access the app. You also compared Docker with alternatives and saw how to fix common issues.

Key takeaways: - Docker packages an application with its dependencies into a portable container image. - Containers share the host OS kernel, making them lightweight vs. VMs. - A Dockerfile defines how to build an image layer by layer. - docker build creates the image; docker run starts a container. - Port mapping (-p host:container) connects container services to your machine.

What's next: In the next lesson, you'll learn how to manage multiple containers with Docker Compose, connecting a web app to a database — all defined in a single YAML file. This is the next step toward replicating a microservices environment locally.