Ever wonder how containers running on the same host can still provide isolation from each other? Docker’s power comes from various Linux building blocks we can understand and by doing so we could gain a greater understanding of containers and their magic.

Let’s dive right in:

Namespaces

A namespace wraps a global system resource to make it look to other processes in the same namespace as if they were using that resource exclusively.

We can illustrate it with the following hotel room analogy:
🏠 Imagine you're in a hotel room. Inside your room:

You see your own TV, bed, and bathroom.
You don’t see the rooms of other guests.
You don’t know what channels they’re watching, or if they’re even there.

Even though you're all in the same hotel (the same Linux system), you only see your part of it — because walls (namespaces) are hiding everything else from you.

🖥️ In the real Linux system, this means:

Depending on the type of namespace, it hides different things:

PID namespace: You only see your own processes. Other processes still run, but you don’t see them in ps.
Network namespace: You only see your own network interfaces, IP address, ports, etc.
Mount namespace: You only see your own view of the filesystem (maybe /home is empty, or /etc has different configs).
UTS namespace: You can set your own hostname, and it won’t affect anyone else.

So the namespace is like a filter or a barrier — it doesn't delete the other things, just makes it so your process can’t see or touch them.

🐳 Why This Matters for Docker:

Docker uses namespaces so that each container feels like a mini-computer, even though it shares the same Linux kernel with others. That is how Docker creates lightweight, isolated environments.

Namespace hands-on experiment:

Try this:

1 - Open your terminal and let’s run a Linux container:

# Run a lightweight Alpine Linux container, give me an interactive terminal, and automatically clean it up when I’m done."
docker run -it --rm alpine

2 - Then inside that container run:

# List the processes that are currently running in detailed format
ps -ef 

# Show the hostname
hostname

3- Finally, open another terminal and compare the previous output to:

# List the processes that are currently running in detailed format
ps -ef

# Show the hostname
hostname

You’ll notice that within the container, the process list and hostname appear different—it functions like its own mini-system.

📝 Note: This experiment works on Linux distributions (including containers like Alpine). If you're using Windows, you'll need to run it in a Linux environment — such as through Docker Desktop or another compatible setup — since native Windows terminals don't support Linux commands like ps -ef.

Cgroups

Cgroups (short for control groups) are a Linux kernel feature that lets you: Limit, monitor, and isolate the resource usage (CPU, memory, disk I/O, network, etc.) of a group of processes.

So while namespaces isolate what a process can see, cgroups control how much a process can use.

🔧 Example use cases:

Limit a container to use only 512MB of RAM.
Cap CPU usage to 20% for a background job.
Prioritize certain processes over others.
Prevent one container from hogging all the memory and crashing your system.

🐳 How Docker uses cgroups:

When you run a Docker container, Docker sets up cgroups automatically behind the scenes. You can specify limits like:

docker run -it --rm --memory=256m --cpus=0.5 alpine

This command:

Limits the container to 256MB of RAM
Caps CPU usage to half a CPU core

With cgroups, containers can run predictably and within their configured resource limits — without needing the application itself to enforce or even be aware of those limits.

Union Mount Filesystems

A union file system lets you combine multiple file system layers into one — so they appear as a single unified file system to the user or process.

🐳 How Docker uses Union Mount Filesystems:

When you run a container, Docker builds its file system using layers. These are:

Read-only image layers (from the base image)
A read-write layer on top (created when the container starts)

The union file system "merges" these layers together so that your container sees them as one complete file system.

🏗️ Example:

Imagine your image layers are like this:

Layer 1: /bin, /lib (from Alpine base)
Layer 2: /app (your custom app code)
Layer 3: /config (added by Dockerfile)
Container Layer: any files you create at runtime (like /tmp/file.txt)

Thanks to the union file system, you see:

/
├── bin/
├── lib/
├── app/
├── config/
├── tmp/  ← created at runtime

But behind the scenes, these came from different layers — combined transparently.

Docker uses a union file system to give containers a merged view of multiple layers, with their own writable space on top — so they behave like full, independent systems, and changing the data in one container won’t affect the others.

Conclusion

In this article, we explored how Linux namespaces, cgroups, and union mount file systems form the foundation of Docker containers. Docker abstracts away these underlying technologies, allowing us to build and run containers easily — without needing to interact with the kernel or understand every detail.

By understanding these building blocks, we gain a deeper appreciation for how containers provide isolation, resource control, and efficient storage — all while running on a shared Linux kernel.

If you're curious and want to learn more, I recommend this free resource: Complete Docker Course – From Beginner to PRO.

What Makes Docker Work? A Simple Guide to the Linux Magic Inside