Containers Are Just Processes

Imagine you’re running a race.

You can see the other runners. You can see the track, the spectators, the finish line. You have a complete view of the world around you.

Now imagine someone puts a blindfold on you. They give you earphones playing music so you can’t hear the other runners. They put you on a treadmill so you think you’re moving forward, but you’re actually staying in place.

To you, the race feels exactly the same. You’re running. You’re breathing hard. You feel like you’re making progress. But your perception of reality has been altered. You can’t see that there are other runners. You can’t see where you actually are.

This is what Linux namespaces do to a process.

The process is real. It’s running. It’s doing work. But its view of the world has been restricted. It can’t see other processes. It can’t see the full filesystem. It thinks it has its own network, its own hostname, its own everything.

The process isn’t in a special container box. The process is running on the host, just like any other process. It’s just been given a very limited view of reality.

Let’s establish what a process actually is on Linux.

A process is a running program.

When you execute a binary — /usr/bin/python, /usr/sbin/nginx, /bin/bash — the kernel creates a process. That process gets:

• A unique process ID (PID)
• Memory allocated from RAM
• CPU time slices for execution
• File descriptors to access files, network, etc.
• An environment (variables, working directory)
• A user and group ID for permissions

Every program running on your system is a process. Your web browser. Your terminal. Your text editor. The system services. Everything.

Containers are also just processes.

When Docker runs a container, it:

1. Starts a process (e.g., /usr/sbin/nginx)
2. That process runs on the host kernel
3. But the kernel has been instructed to give this process a restricted view

From the host’s perspective, you can see the containerized process in the process list. It’s right there, running alongside everything else.

# On the host
ps aux | grep nginx

You’ll see nginx processes. Some might be from a container. Some might be running directly on the host. To the kernel, they’re all just processes.

So what does Docker actually do when you run docker run?

Step 1: Docker tells the kernel to create a new process

Just like when you run ./my-program in your terminal, Docker asks the kernel to start a process. The difference is in how it asks.

Step 2: Docker requests special isolation features

When creating the process, Docker uses Linux kernel features:

• Namespaces: “Give this process its own view of PIDs, network, filesystem, etc.”
• Cgroups: “Limit this process to 512MB RAM and 50% of one CPU”
• Capabilities: “Drop dangerous permissions, don’t let this process reboot the system”

Step 3: The kernel grants these restrictions

The Linux kernel creates the process with these restrictions applied. The process starts running, but it’s running in a “restricted reality.”

Step 4: Docker monitors the process

Docker keeps track of this process. When the process exits, the container stops. When you run docker stop, Docker sends a signal to the process to terminate gracefully.

Let’s prove that containers are just processes.

Experiment 1: View container processes from the host

Start a container:

docker run -d --name my-nginx nginx

This starts nginx in detached mode. Now, from your host terminal:

ps aux | grep nginx

You’ll see something like:

root     12345  0.0  0.1  nginx: master process
www-data 12346  0.0  0.1  nginx: worker process

These are real processes running on your host system. They are not hidden inside a separate machine. They are real processes on your real kernel.

Experiment 2: Find the container’s main process PID

docker inspect my-nginx --format '{{.State.Pid}}'

This gives you the process ID of the main container process. Let’s say it’s 12345.

Now from the host:

ps -p 12345 -f

You can see that process. It exists. It’s running on your system.

Experiment 3: What happens when the process dies?

If you kill the process from the host:

kill 12345

The container stops. Because the container is the process. When the process exits, there’s no container anymore.

Experiment 4: Process tree

Run pstree or ps -ejH to see the process hierarchy. You’ll see Docker daemon (dockerd) as a parent process, with container processes as children.

The container does not exist in a separate universe. It is in your process tree.

This is a mental model shift that’s important to internalize:

There is no container.

There’s no box or mini-VM or special construct. There’s a process running on your Linux kernel with restricted permissions and a limited view of the system.

When people say “container,” they really mean:

• A process (or group of processes)
• With namespace isolation (restricted view)
• With cgroup resource limits
• With a root filesystem from a layered image
• Managed by a container runtime (Docker)

The “container” is an abstraction. A very useful abstraction. But under the hood, it’s just your Linux kernel doing what it does best: running processes and managing resources.