Chapter 1 · Lesson 3

How to Use This Text Course

The read-and-do workflow, the conventions you'll see throughout, and why later labs depend on earlier ones.
6 min read Text Updated 2 hours ago Free preview
In this lesson you'll learn
  • Adopt the read-and-do workflow that makes this text course effective.
  • Recognize the conventions used throughout: labs, expected output, knowledge checks, and reading time.
  • Set up a terminal and editor so you can follow every lab smoothly.
  • Know how to reset your environment and where to get help when something breaks.
The Read, Type, Verify learning loop used throughout the course The Learning Loop 1 · Read Understand the idea 2 · Type Run the commands 3 · Verify Check the output then then repeat
Read an idea, type the commands yourself, then verify the output matches — then move to the next idea.

The read-and-do workflow

This is a text course, but it is built to be practiced, not skimmed. The single most important habit is the loop in the diagram above: Read the explanation until the idea makes sense, Type the commands into your own terminal (do not copy-paste blindly — typing builds memory), and Verify that your output matches what the lesson shows. When all three line up, you have truly learned the step. Then move on.

Resist the urge to read three lessons ahead before doing the first. Containers and Kubernetes are skills of the hands as much as the head. A learner who completes every lab will finish far more capable than one who read twice as fast.

Conventions used throughout

To keep things predictable, the course uses a small set of repeating elements:

  • 🧪 Lab callouts — numbered, hands-on exercises. Do these in order; later labs build on the files and images created in earlier ones.
  • Expected output — after each lab command, the realistic output you should see. If yours differs meaningfully, stop and investigate before continuing.
  • Code blocks — commands, Dockerfiles, and YAML appear in monospaced blocks. Type exactly what you see, including indentation (YAML is whitespace-sensitive).
  • Knowledge checks — short questions between sections to confirm the ideas stuck.
  • Estimated reading time — a rough guide per lesson; labs add hands-on time on top.
  • Key Takeaways — a green summary box ends each lesson; revisit these when reviewing.

Commands are shown without a shell prompt so they are easy to copy, like this:

docker --version
docker compose version

When a command's result matters, the lesson shows it under an Expected output heading so you can compare directly.

Terminal and editor setup

You need two things open while you work: a terminal and a code editor.

  • Terminal. On macOS or Linux, the built-in terminal is perfect. On Windows, use Windows Terminal with either PowerShell or WSL2 (the Windows Subsystem for Linux). Docker Desktop integrates cleanly with WSL2, which is the smoothest path on Windows.
  • Editor. Any editor works, but VS Code is recommended. Install the official Docker and Kubernetes extensions for syntax highlighting and helpful previews of your compose.yaml and manifest files.

Keep a single project folder for the whole course and track it with Git. A clean structure makes later labs far easier to follow.

How labs depend on each other

The course project grows lab by lab. The image you build in one lesson is the image you run in the next; the compose.yaml you write for Docker becomes the basis for your Kubernetes manifests later. Because of this, do the labs in order and keep your project folder intact between sessions. Skipping a lab and jumping ahead usually means a later step has nothing to build on.

Resetting your environment

Experiments leave behind stopped containers, dangling images, and unused volumes. When your machine feels cluttered, or a lab tells you to start fresh, you can reclaim space safely. Stop and remove containers, then prune what is no longer referenced:

docker ps -a
docker compose down
docker system prune

The prune command asks for confirmation and removes only stopped containers, unused networks, and dangling images by default. It does not touch running containers.

Be careful with aggressive pruning

Commands like docker system prune -a --volumes delete all unused images and named volumes — including data you may want to keep. Only use the -a and --volumes flags when you genuinely intend a full reset, and never on a machine running anything important.

Where to get help

When something does not match the expected output, work through it in order: re-read the step, check for typos (especially YAML indentation), and read the error message carefully — Docker and Kubernetes errors are usually descriptive. Beyond that, the official Docker documentation, the Kubernetes documentation, and --help on any command are your best references:

docker --help
kubectl --help

With the workflow and conventions in hand, you are ready to begin building. The next part takes you into Docker itself.

Lesson Summary
  • Follow the Read → Type → Verify loop for every lesson — type commands yourself and check the output.
  • Learn the conventions: 🧪 labs, expected output, knowledge checks, and reading-time estimates.
  • Keep one Git-tracked project folder; labs build on each other and must be done in order.
  • Reset safely with docker compose down and docker system prune, avoiding aggressive -a --volumes wipes.
Sign up to track progress