Docker and Kubernetes for Beginners

Almost every software team uses containers. Job posts ask for them by name. You will type many commands in this course, and each one is easier to remember when you know the idea underneath.

An app needs more than its own code. It needs a language runtime, extra libraries, settings and files in the right places. Change any one of these and the app can break. This is where the old complaint 'it works on my machine' comes from.

A container is a box that holds an app and everything the app needs to run. The box runs as an ordinary process on your computer. Inside it, the app sees only its own files, its own network and its own list of processes. That separation is called isolation.

Think of a shipping container. The crane does not care what is inside. The box has a standard shape, so it moves from ship to truck to train without changes. A software container works the same way. It runs the same on your laptop, on a teammate's laptop and on a server.

You may have heard of virtual machines. A virtual machine (VM) pretends to be a whole computer with its own operating system. A container does not. Containers share the core of the host's operating system, called the kernel. So they start in seconds and use less memory. The price is that they are isolated less strongly than a VM.

Most containers you will meet are Linux containers. On Windows and Mac, the tools quietly start a small Linux helper machine to run them. You do not need to manage it.

Two names matter in this course:

• Docker is the most popular tool for building and running containers.
• Kubernetes runs many containers on one or more computers and keeps them healthy.

We start with Docker, because Kubernetes runs containers. It is hard to manage what you do not understand.

How the course works. Every lesson has the same six parts. Type the commands yourself. Where we show output, yours will differ in ids, times and sizes. That is normal. Look for the shape, not the exact characters.

What you will build. A tiny web app called apex-hello. When you open it, it prints a greeting, the name of the machine it runs on, a visit count and a version number. You will:

1. Run ready-made containers (Modules 1 and 2).
2. Package apex-hello into your own image (Module 3).
3. Run three copies of it on a Kubernetes cluster on your own computer (Modules 4 to 6).

Example (illustrative): Ana writes a small app that needs Python 3.13. Ben's laptop has Python 3.8.

Without a container:

1. Ana sends Ben the code and a note that says 'install Python 3.13'.
2. Ben installs it. Now his other project stops working.
3. Ben installs a library. It is the wrong version. He loses an hour.

With a container:

1. Ana packs the app, Python 3.13 and the libraries into one package.
2. Ana sends Ben the name of the package.
3. Ben runs one command. The app starts, and it behaves the way it did for Ana.

Ben never installed Python 3.13. He did not touch his other project. Everything the app needed travelled inside the box. That is the whole idea. The rest of this course is about how to build the box, run it, and run many of them.

• Thinking a container is a small virtual machine. Why: both feel like 'another computer'. Fix: remember that a container is one isolated process that shares the host's kernel.
• Thinking Docker and Kubernetes compete. Why: both appear in the same job posts. Fix: Docker builds and runs containers. Kubernetes manages many of them.
• Skipping the typing. Why: the commands look easy. Fix: type each one. Your hands remember what your eyes skip.

You can say out loud, without looking, what a container is: a box that holds an app and what it needs. Then add how it runs, as an isolated process. You can also name the four things the apex-hello page shows: a greeting, a machine name, a visit count and a version.