Containers and Docker: Ship Code Like Shipping Containers

You spend a weekend writing a Python program that takes attendance for your class — it reads a list of roll numbers, checks them against a CSV file, and prints who is absent. It works perfectly on your laptop. You zip the folder and email it to your friend so she can run it for her section. She unzips it, types python attendance.py, and gets a wall of red error text: ModuleNotFoundError: No module named 'pandas'. She installs pandas, runs it again, and gets a different error, because her computer has Python 3.8 and your code uses a feature that only exists in Python 3.11. Twenty minutes of "just install this, now install that" later, she finally gets it running — and it behaves slightly differently anyway, because a date-parsing function on her older Python version reads dates in a different default format.

Nothing about your code was wrong. The problem was the environment around the code — which Python version, which libraries, which operating system — and that environment was never packaged along with the program. This chapter is about the tool that solves exactly this problem: Docker, and the idea of a container, which packages a program together with everything it needs to run, so that it behaves identically no matter which computer it lands on.

An old idea from the docks, borrowed by software

Before you meet Docker, it helps to know where the word "container" in this context actually comes from, because the history explains the design better than any analogy invented after the fact.

Before the 1950s, cargo ships were loaded by hand. A ship carrying goods to another country might hold thousands of separate items — sacks of grain, wooden crates, barrels, loose machine parts — each a different size and shape. Dock workers spent days manually loading and unloading each item, fitting it into the ship's hold like an enormous, disorganized puzzle. This was called "break bulk" shipping, and it was slow, expensive, and prone to damage and theft, because every port needed a different crew to unload every differently shaped item by hand.

In 1956, an American trucking entrepreneur named Malcom McLean tried something different. He loaded 58 identical, standardized metal boxes onto a converted tanker ship, the SS Ideal-X, and sailed it from Newark to Houston. Each box was the same shape, with the same corner fittings, so the same crane could lift any of them, the same truck chassis could carry any of them, and the same slots in the ship could hold any of them — regardless of what was actually packed inside. It didn't matter if the box held clothes, machine parts, or rice. The box was standard, so the entire system around it — cranes, ships, trucks, ports — could also become standard. Within a couple of decades, the shipping container had collapsed the cost and time of global trade so dramatically that it reshaped how the world manufactures and moves goods.

Notice what actually made this powerful: it was not the box itself. It was that the box had a standard interface — a fixed size and a fixed way of being picked up — while its contents stayed completely flexible. Docker containers apply the exact same idea to software. The "box" is a standard way of packaging a program with everything it depends on; the "crane and ship" is any computer that has Docker installed. What is inside the box — a Python script, a web server, a database — can be anything, but the box behaves identically wherever it is placed.

What a container actually is

Here is the definition to build carefully, because it is the part most learners get wrong: a container is not a small virtual machine. To see why, you need to know what a virtual machine (VM) actually does.

A physical computer runs one operating system (OS) directly on its hardware. That OS has a kernel — the core part of the OS that talks to the CPU, memory, and disk, and decides which program gets to run when. A virtual machine is a way of pretending a second, third, or fourth "computer" exists inside your one real computer. A program called a hypervisor (examples: VirtualBox, VMware) creates a fake set of hardware, and a complete second operating system — with its own separate kernel — is installed and booted inside that fake hardware, exactly as if it were a real machine. If you run three VMs, you have booted three entire operating systems, each with its own kernel, sitting on top of your one real machine's one real OS. This is why VMs are heavy: each one carries the full weight of an operating system, and each one takes tens of seconds to minutes to boot, the same way your laptop takes time to start up.

A container skips the second operating system entirely. It does not boot a kernel, because it does not need one — it simply reuses the kernel that is already running on the host machine. What Docker does instead is use two features built into the Linux kernel:

• Namespaces — these give a group of processes their own private view of things like the filesystem, network interfaces, and list of running processes, so that a program inside a container cannot see or interfere with programs outside it, even though they share the same kernel underneath.
• Control groups (cgroups) — these limit how much CPU, memory, and disk I/O a group of processes is allowed to use, so one container cannot starve the others of resources.

Together, namespaces and cgroups make a container feel like an isolated machine to the program running inside it, without the cost of actually being one. A container is really just an ordinary process (or a small group of processes) on the host machine, wrapped in enough isolation that it can't tell it's sharing the machine with anyone else.

A common misconception, so common it is worth stating and correcting directly: "a Docker container is basically a lightweight virtual machine." It is not. A VM virtualizes hardware and boots an entire second operating system with its own kernel. A container virtualizes nothing at the hardware level — it is an isolated process on the host's existing, already-running kernel. This single difference explains almost every practical difference you will notice between the two: a VM might take 30–60 seconds to boot because an entire OS has to start up inside it; a container typically starts in well under a second, because there is no OS left to boot — the host OS was already running before the container existed. It also explains a real limitation: because a Linux container shares a Linux kernel, it cannot run natively on a Windows machine's kernel. Docker Desktop on Windows or macOS quietly runs a small Linux virtual machine in the background specifically to provide that shared Linux kernel — so even "container on Windows" is secretly still "container on a Linux kernel," just hidden from you.

Images and containers: a blueprint and its instances

Docker itself uses two words precisely, and mixing them up is the second most common source of confusion for beginners.

A Docker image is a read-only template — a packaged snapshot containing an operating system's base files, your application code, and every library your code depends on, all frozen together. It is inert; it does nothing by itself, the same way a class definition in code does nothing until you create an object from it, or the same way an architect's blueprint does not become a building until construction happens.

A Docker container is a running instance created from an image. You can start several containers from the same image, and each one runs independently, with its own isolated filesystem changes and its own process, even though they all began from an identical starting point. If your attendance-tracking image is started three times, you get three separate running containers, each able to be stopped, restarted, or deleted without touching the others or the original image.

This mirrors a distinction you may already know from programming: an image is like a class, and a container is like an object created from that class — one definition, many independent instances.

Writing your first Dockerfile

An image is built from a plain text recipe called a Dockerfile. Suppose your attendance program is a small Flask web app with two files: app.py (the program, which starts a web server listening on port 5000) and requirements.txt (a list of the Python libraries it needs, such as flask and pandas). Here is a Dockerfile that packages it:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Read it top to bottom exactly as Docker will execute it when you run docker build -t attendance-app .:

1. FROM python:3.11-slim — Docker downloads (or reuses, if already cached locally) a base image that already contains a minimal Linux filesystem with Python 3.11 pre-installed. Every image starts from some base; you are not building an operating system from nothing.
2. WORKDIR /app — creates a folder called /app inside the image and makes it the current directory, so every instruction after this runs relative to /app.
3. COPY requirements.txt . — copies just that one file from your project folder on your computer (the "build context") into /app inside the image.
4. RUN pip install --no-cache-dir -r requirements.txt — actually executes pip install during the build, inside the image, and permanently saves the result (the installed libraries) as part of the image.
5. COPY . . — now copies everything else from your project folder — app.py and any other files — into /app.
6. CMD ["python", "app.py"] — this does not run now. It records the command that should run automatically whenever a container is later started from this finished image.

The distinction in the last two steps matters and is frequently confused: RUN executes immediately, while the image is being built, and its result is baked permanently into the image. CMD only records an instruction for later — it fires each time a new container starts, not while the image is being assembled.

Once the image exists, docker run -p 8080:5000 attendance-app starts a container from it. The -p 8080:5000 flag matters because a container's network is isolated by default: it maps port 8080 on your real computer to port 5000 inside the container, where your Flask app is actually listening. Without that mapping, the app would be running perfectly inside its isolated container, and you would have no way to reach it from your browser.

Why the order of instructions is not an accident

Docker builds an image as a stack of layers, one per instruction, and it is clever about reusing layers it has already built before. Each layer is cached and identified by a checksum of the instruction and the files involved. If you run the build again and a given layer's inputs haven't changed, Docker skips rebuilding that layer and reuses the cached copy instantly.

This is precisely why the Dockerfile above copies requirements.txt and installs libraries before copying the rest of the code, rather than copying everything in one step. Suppose installing pandas, flask, and their dependencies takes 90 seconds. If you instead wrote COPY . . once at the top (copying all your files, including app.py) and then ran pip install, then every single time you edited even one line of app.py — which changes far more often than your library list — Docker would see that the COPY layer's input changed, invalidate that layer, and be forced to invalidate and rerun every layer after it too, including the 90-second install, on every single build.

By separating them, a code-only edit looks like this instead: the FROM, WORKDIR, COPY requirements.txt ., and RUN pip install layers are all untouched — Docker reuses all four from cache in well under a second — and only the final COPY . . layer (a couple of seconds, since it's just copying files, not installing anything) needs to be redone. A rebuild that could have taken over 90 seconds instead takes 2–3 seconds. The rule this teaches generalizes: put the things that change least often earliest in the Dockerfile, and the things that change most often last.

Pulling, pushing, and the registry

Images are shared through a registry — a server that stores images by name and version tag, the way GitHub stores code repositories. Docker Hub is the default public registry. docker pull python:3.11-slim downloads an image from it; that is exactly what happened silently the first time your FROM line ran. If you build your own image and want to share it, docker push uploads it to a registry under your account, so anyone with access — a teammate, a deployment server — can docker pull the exact same image and run an identical container from it. Two other commands are worth knowing for working with what is already on your machine: docker images lists every image you have downloaded or built locally, and docker ps lists containers currently running.

Why this matters at real scale

The "it works on my machine" problem gets far more serious once you stop thinking about one laptop and start thinking about a live service handling many users at once. Consider what happens on IRCTC when Tatkal booking opens at a fixed time each morning and a very large number of people try to book tickets within the same few seconds. Handling that kind of concentrated spike well means running many copies of the same booking service simultaneously, across many machines, and — critically — every single copy has to behave identically. If even one server in the group were running a slightly different library version, it could reject or mishandle requests differently from the rest, and users would see inconsistent, unpredictable behaviour at the exact moment reliability matters most. Because a Docker image is a frozen, exact package of code plus dependencies, starting the hundredth copy of it produces a container that behaves exactly like the first — there is no "server 47 was configured slightly differently" possible, because nothing about it was configured by hand at all; it was built once, as an image, and merely started many times.

This is also why containers, not VMs, became the standard building block for scaling web services up and down quickly. If adding capacity meant booting a new full virtual machine each time — complete with its own operating system starting from scratch — responding to a sudden traffic spike would itself take minutes, by which point the spike might already be over. Starting another container from an already-built image, sharing the kernel that's already running, takes a small fraction of that time.

Summary

• A container packages an application together with its exact dependencies so it behaves identically on any machine that runs Docker — solving the "it works on my machine" problem.
• The idea borrows directly from the standardized shipping container introduced in 1956: a fixed, standard outer format lets the same handling system (cranes and ships, or here, the Docker Engine) move completely different contents.
• A container is not a lightweight VM. A VM boots an entire separate operating system with its own kernel via a hypervisor; a container shares the host's already-running kernel and is isolated from other processes using Linux namespaces and cgroups. This is why containers start in a fraction of a second while VMs take much longer.
• A Docker image is a read-only template; a Docker container is a running instance created from that image. Many containers can be started from one image, independently of each other.
• A Dockerfile is a text recipe of instructions (FROM, WORKDIR, COPY, RUN, CMD) that docker build turns into an image, layer by layer. RUN executes during the build; CMD only records what should run when a container later starts.
• Docker caches each layer. Ordering instructions so that rarely-changing steps (like installing dependencies) come before frequently-changing steps (like copying your code) means small code edits rebuild in seconds instead of minutes.
• Images are shared through a registry (such as Docker Hub) using docker pull and docker push, so the same exact image can run identically across many machines — essential for services that need to scale reliably during sudden traffic spikes.

Check yourself

1. A classmate says, "A Docker container is just a smaller, faster virtual machine." Explain precisely what is wrong with that sentence, using the words "kernel" and "hypervisor" in your answer.
2. In the Dockerfile shown in this chapter, if you deleted the line COPY requirements.txt . and the separate RUN pip install step, and instead did the install after COPY . ., what would happen to build speed every time you edited app.py? Explain why, in terms of layer caching.
3. What is the difference between what happens when Docker reaches a RUN instruction versus when it reaches a CMD instruction?
4. You build an image called attendance-app and run it three separate times with docker run. How many images exist afterward, and how many containers? Explain the difference using the blueprint/instance idea.
5. Why does a docker run command that maps -p 8080:5000 need that flag at all — what would happen to a web app inside the container if you left it out?
6. Explain, using the 1956 shipping container story, why standardizing the "box" (rather than standardizing what's inside it) was the actual insight that made global shipping faster — and name the equivalent "box" in Docker.

Think About It

Think about this: How would you explain containers and docker: ship code like shipping containers to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where containers and docker: ship code like shipping containers is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting containers and docker: ship code like shipping containers to at least 3 other topics you have studied.