// Docker Fundamentals · Lesson 1
Why containers?
Your program runs on your laptop. Then it moves to a test server, then to production, and somewhere on the way it breaks, although nobody changed a line. This lesson shows why that happens, and how a container fixes it by shipping the program together with everything it needs.
BY THE END OF THIS LESSON YOU CAN
- Explain why the same program works on one machine and fails on another
- Say what a container really is: an isolated process, not a small computer
- Compare containers with virtual machines and pick the right one
- Use the words image, container and registry correctly
- Read your first Docker commands and their output
Part 1 of 5
It works on my machine
The most common excuse in software teams has a real cause: a program depends on much more than its own code.
// 1.1
What a program needs to run
Your code is only the top layer. Click each layer to see what it is, what breaks when it differs between machines, and where it lives once the program runs in a container.
// 1.2
Same code, different machine
Here is the failure from the start of the lesson in full. One Main.class, compiled once with Java 25, run on two machines. You don’t need to know Java: read what each machine prints.
Nothing was wrong with the code. The machine was different. Every fix you can think of (“install Java 25 on production”, “build for Java 17”) means changing one machine to match another, and keeping them matched forever.
// 1.3
True stories
Three real events: what happens when machines drift apart, where the idea of a container comes from, and the day Docker was shown for the first time.
// 1.4
Game: where does it live?
Twelve things a real order service depends on. Sort each one: your code, a library, the runtime and operating system, or configuration.
// 1.5
Checkpoint: it works on my machine
Eight quick questions on Part 1. Pick an answer to see why it is right or wrong.
Part 2 of 5
What a container is
A container is not a small computer. It is an ordinary process on the host, started with a private view of files, processes and the network, and with limits on what it may use.
// 2.1
A process with its own view
Each tab is a real command, run in a fresh alpine container on a Mac. alpine is a very small Linux image. Read what the process inside can see.
Underlined values, such as a container’s name or address, are different on every run and on your machine.
// 2.2
Every container starts fresh
Two containers from the same image, one after the other. The first one writes a file. Does the second one see it? Step through.
// 2.3
One kernel, many distributions
Alpine and Ubuntu are two different Linux distributions: different files, different tools, different sizes. Run both on the same Mac and ask each one what it is and which kernel it runs on.
A distribution is the set of files and tools around the kernel. An image brings those files; the kernel always comes from the host. On a Linux server that is the server’s own kernel. On a Mac or a Windows PC, Docker Desktop starts a small Linux virtual machine, and its kernel serves every container: that is the linuxkit kernel above.
// 2.4
Namespaces and cgroups
Two features of the Linux kernel make a container. Docker’s job is to set them up for you with one command.
Namespaces: what it can see
Each namespace gives the process its own copy of one thing. You met them in 2.1:
- mount: its own file tree, from the image
- PID: its own process numbers, starting at 1
- UTS: its own hostname
- network: its own network address
- IPC: its own channels for processes to talk to each other
Control groups (cgroups): how much it can use
A cgroup puts limits on memory, CPU time and the number of processes. Without a limit, the file that holds the memory limit says max. With --memory 64m it holds a number of bytes:
64 × 1024 × 1024 = 67108864
If the process tries to use more, the kernel stops it. Lesson 19 sets limits on purpose.
// 2.5
Game: true or false?
Twelve statements about containers. Some are traps that sound right.
// 2.6
Checkpoint: what a container is
Eight questions on Part 2. Several show a real run: read the output carefully.
Part 3 of 5
Containers and virtual machines
A virtual machine (VM) pretends to be a whole computer, and runs a whole operating system inside. A container is one process with its own view. Both isolate programs; they pay very different prices for it.
// 3.1
Two stacks
Up to three programs, isolated two ways. Add programs one by one, and watch what each stack has to repeat.
// 3.2
Side by side
The measurements under the table are real runs on the Mac from Part 2.
| Virtual machine | Container | |
|---|---|---|
| What is inside | A whole operating system with its own kernel, plus your program | Your program and the files it needs, no kernel |
| Starting it | Boots an operating system | Starts one process: the whole docker run below took 0.2 seconds |
| Size | A disk with a full operating system, usually gigabytes | Megabytes: the alpine image has 3.86MB of content |
| Kernel | Its own | Shared with the host |
| Isolation | Strong: a separate kernel on virtual hardware | Weaker: a bug in the shared kernel affects every container |
| Other systems | Any: Windows in a VM on a Linux server, Linux on a Mac | Needs a matching kernel: Linux containers need Linux |
// 3.3
When a VM is the right tool
Containers did not replace virtual machines. Most of the time you use both, one inside the other.
Another operating system
To run Windows programs on a Linux server, or a different kernel version, you need a VM: a container cannot bring its own kernel.
Code you do not trust
A hosting company that runs strangers’ code gives each customer a VM. A separate kernel is a much higher wall than a namespace.
Both together
A cloud server you rent is usually a VM, and on it you run containers. Docker Desktop on your Mac or PC is the same idea: one Linux VM, many containers inside it.
Rule of thumb: a VM when you need another kernel or the strongest wall; a container when you want to ship a program with its environment and start it in a second.
// 3.4
Game: VM or container?
Twelve real situations. Pick the better tool for each one.
// 3.5
Checkpoint: containers and virtual machines
Eight questions on Part 3.
Part 4 of 5
Image, container, registry
Three words carry the whole course. Learn them precisely now, and every Docker command later reads like a sentence.
// 4.1
Three words
An image is what you ship, a container is what runs, and a registry is where images wait to be downloaded.
Image
A read-only package: the files a program needs (code, runtime, libraries, OS files) plus settings such as which command to start. It never changes once it is built.
Like a program’s installer: one file, copied to many machines.
Container
A process started from an image, with its own writable layer and its own view. It can be running or stopped, and it is removed when you no longer need it.
Like the installed program while it runs. Many can run from one image.
Registry
A server that stores images so that other machines can download them. Docker Hub is the public registry Docker uses by default; companies also run private ones.
Like an app store for images.
// 4.2
Reading an image name
Short names like alpine are full addresses with parts left out. Pick a name to see its four parts and what Docker fills in for the missing ones.
// 4.3
A first look
Five commands, recorded in this order, show all three words at work. You will type them yourself in lesson 2; for now, run them one by one here and read the notes.
// 4.4
Build, ship, run
The path of the order service from your laptop to production. Each step is one Docker command, and each one has its own lesson later in the course.
// 4.5
Game: image, container or registry?
Twelve descriptions. Which of the three words does each one describe?
// 4.6
Checkpoint: image, container, registry
Eight questions on Part 4.
Part 5 of 5
Wrap-up
What to remember, a final quiz, your homework and a look at the next lesson.
// 5.1
Key takeaways
A program depends on much more than its code: libraries, a runtime such as Java, OS files and configuration. When any of these differ between machines, the same code can work on one and fail on another.
A container ships the program together with its libraries, runtime and OS files, so it runs the same everywhere. Configuration is given to it when it starts; data is kept outside it.
A container is an ordinary process on the host. Namespaces give it its own view (files, process numbers, hostname, network); cgroups limit what it may use (memory, CPU).
Every container starts from an unchanged image and writes into its own layer. When the container is removed, that layer and its changes are gone.
All containers on a machine share one kernel. On a Mac or a Windows PC, Docker Desktop provides a Linux kernel in a small virtual machine.
A virtual machine runs a whole operating system with its own kernel: slower to start and bigger, but stronger isolation, and it can run other systems. In the cloud, containers usually run inside VMs.
An image is a read-only package, a container is a process started from it, and a registry stores images; Docker Hub is the default one.
An image name has four parts,
registry/. Left out, they default tonamespace/ repository:tag docker.io,libraryandlatest.
// 5.2
Check yourself
Twenty questions on the whole lesson, in the order of the parts. Outputs in the questions are real runs.
Your checkpoints
// 5.3
Homework
Fifteen tasks in three levels. You install Docker in lesson 2, so none of them needs it: you look at your own machine, read real outputs and explain them. Write your answers in a notebook or a text file, then open Check yourself.
A model answer is one good answer, not the only one. Your ticks are saved in this browser only.
// 5.4
Questions?
Next lesson: Installing Docker and your first container. You install Docker Desktop on your own machine, check that it works, and start your first containers yourself. The first command you type will be this one: