00 - Introduction¶

What this session is¶

A 10-minute read. No code. Sets expectations.

What you're going to be able to do, eventually¶

By the end:

Run any container from a Docker image.
Write a Dockerfile that packages your own application.
Use volumes to keep data; networks to let containers talk.
Compose multi-container apps with docker compose.
Push and pull images to/from a registry.
Read a real-world Dockerfile and know what it does and why.
Clone a containerized open-source project, find and fix a small issue with its Dockerfile or compose.yaml, and submit a pull request.

That last bullet is the goal.

The deal¶

It's slow on purpose. One concept per page.
It assumes nothing about containers. It assumes basic terminal comfort.
You will run real containers. Most pages have hands-on commands.
You will see surprising behavior. Containers behave like tiny isolated machines, and the first 2 weeks of using them is "wait, why didn't that work?" That's normal.

What containers actually are (briefly)¶

A container is a running process (or a few) wrapped in: - Its own view of the filesystem. - Its own network namespace (own IP, own ports). - Its own process tree (it can't see the host's other processes). - Limited CPU and memory if you configure it.

The container shares the host's kernel - unlike a VM, no separate kernel boots up. Cheap and fast: starts in milliseconds, costs almost nothing when idle.

An image is a recipe for creating a container - a frozen filesystem snapshot plus some metadata ("when you start me, run this command").

You'll get the full picture as we go. Don't try to absorb it all from one paragraph.

What you need¶

Docker Desktop on macOS / Windows. Free for personal use. Includes the Docker engine, the CLI, and a UI.
On Linux: Docker Engine (sudo apt install docker.io or similar) or Podman (drop-in replacement, doesn't need a root daemon - often nicer).
A text editor.
A terminal.
~5 hours/week. Path is sized for 3-4 months.

What you do NOT need¶

Kubernetes. (Different path. Containers come first.)
A cloud account. We work locally.
A programming language. (Some examples use simple Node/Python/Go for variety, but you'll just be running pre-built images.)

How long this realistically takes¶

3 to 4 months at 5 hours/week to the "submit a PR" goal. Shorter than the language paths because there's no new syntax to learn - just commands, concepts, and YAML.

What success looks like¶

You'll be able to: - Look at a Dockerfile and explain every instruction. - Look at a compose.yaml and explain the service topology. - Debug a container that won't start. - Improve someone's Dockerfile to be smaller, faster, or more secure. - Submit a PR.

You will not be able to: - Operate a production Kubernetes cluster. (Different path.) - Write your own container runtime. (Different path: "Container Internals" senior reference.)

A note on Docker vs Podman vs containerd¶

You'll see multiple "container runtimes" mentioned in the wild:

Docker - original, most popular, has both a CLI and a daemon. Docker Desktop bundles everything.
Podman - Red Hat's daemon-less alternative. CLI is nearly identical to Docker's; alias docker=podman often works. No root daemon by default.
containerd - the low-level runtime under both Docker and Kubernetes. You usually don't talk to it directly.

This path uses Docker commands in examples (most common, most documented). If you're on Podman, the commands are the same - just substitute podman for docker.

One last thing¶

If a page feels too dense - stop, re-read. Still dense? Skip, come back.

Ready? Next: Setup →