DEV Community: Backend By Dmytro

Docker Containers Aren't Magic Boxes: Seeing Linux Namespaces in Action

Backend By Dmytro — Fri, 27 Feb 2026 13:32:39 +0000

You restart a container with one extra flag—--pid=host—and suddenly top inside it shows every process on the host. Nothing else changed. That's the moment the "container as isolated VM" mental model breaks down, and the real one has to replace it.

Containers aren't virtual machines. They don't have a separate kernel. They're Linux processes whose view of the system — process table, filesystem, users, network interfaces — is scoped by kernel namespaces. Change the namespace configuration, and what the process can see changes. That's the whole story.

The Runtime Chain (and Where Namespaces Attach)

When you run docker run, you're triggering a chain of processes:

dockerd → containerd → containerd-shim → runc → your application

The critical piece is runc. It's short-lived—it configures the namespaces, forks the container process (say, nginx), then exits. The containerd-shim process sticks around to supervise that process and hold onto its file descriptors. After runc finishes, the container is just nginx running under a set of kernel namespace constraints.

The namespaces that runc process configures - such as PID, mount, net, and optionally user, are attached to the application process. They're not a property of Docker. They're a property of the process.

You can inspect them directly:

PID=$(docker inspect -f '{{.State.Pid}}' my-nginx)
sudo ls -l /proc/$PID/ns

That /proc/<pid>/ns listing is your ground truth. Everything else follows from it.

PID Namespace: Process Visibility Is a Configuration Choice

Run nginx normally, exec in, and run top. You'll see only nginx master and workers—nothing from the host. That's the PID namespace working: the process has its own view of the process table, starting from PID 1.

Now restart with --pid=host:

docker run --rm --name=my-nginx -p 8080:80 --pid=host -d nginx:latest
docker exec -ti my-nginx bash
apt update && apt install -f procps
top

top now shows the host's full process list. The container joined the host PID namespace—there's no isolation there anymore.

The debugging implication: if a tool inside a container "can't see" a process, or if it can see more than you expected, check whether --pid=host is set. Don't assume the default.

Mount Namespace: Same Machine, Different Filesystem

Start a default nginx container and compare OS identity inside vs. outside:

# Inside the container
cat /etc/os-release   # → Debian

# On the host
cat /etc/os-release   # → Fedora (or whatever the host runs)

Same machine, different filesystem roots. The container's /etc/nginx/nginx.conf exists in the container's mount view but doesn't show up at /etc/nginx on the host—it lives in Docker's image storage layer and is mounted into the container's isolated namespace.

The practical lesson here is about file path reasoning: paths that exist in the container may not exist at the same location on the host, and vice versa. If you're troubleshooting config files or bind mounts, you need to reason about which mount table you're looking at.

User Namespace: Whether Container Root Is Host Root

By default, Docker does not use user namespaces. The consequence is direct: root in the container is root on the host for any host-mounted paths.

mkdir -p /tmp/userns-demo
docker run --rm --name=my-nginx -p 8080:80 -v /tmp/userns-demo:/demo -d nginx:latest
docker exec -ti my-nginx bash
echo "test" > /demo/container_file.txt
chmod 600 /demo/container_file.txt

On the host:

ls -la /tmp/userns-demo
# → owned by root, mode 600

A non-root user on the host can't touch that file. Root in the container wrote it as host root.

Enabling `userns-remap`

Add this to /etc/docker/daemon.json:

{
    "userns-remap": "default"
}

Restart Docker. Now the container runs under a dockremap user that has a subordinate UID range—typically 100000–165536—assigned in /etc/subuid. Container UID 0 maps to host UID 100000, UID 1 maps to 100001, and so on.

You can verify the mapping by chown-ing the bind-mounted directory on the host and watching how the container perceives it:

sudo chown -R 100000:100000 /tmp/userns-demo
# Container sees: owned by root (UID 0)

sudo chown -R 1001003:1001003 /tmp/userns-demo
# Container sees: owned by UID 1003

The offset is consistent and predictable. What changes is whether a container process that runs as "root" actually has host-root-level access to host-mounted paths—and with userns-remap, it doesn't.

Network Namespace: Interfaces, Isolation, and `--network=host`

By default, the container gets its own network namespace with a limited interface set. The host side has a docker0 bridge; each container gets a veth pair—one end in the host namespace attached to the bridge, the other end in the container's namespace exposed as eth0.

Traffic from the container reaches the internet through that bridge, with iptables handling NAT on the way out.

With --network=host, all of that is bypassed. The container shares the host's network namespace entirely:

docker run --rm --name=my-nginx --network=host -d nginx:latest
# ip addr inside container == ip addr on host

Same output, same interfaces. No veth, no bridge, no NAT. The process is just using the host network stack directly.

Practical Checklist

When something feels "leaky" or unexpectedly isolated, these are the four questions worth asking:

PID visibility off? Check if --pid=host is set; inspect /proc/<pid>/ns/pid on both container and host.
Wrong filesystem path? Verify which mount namespace you're in; don't assume host and container paths agree.
Bind mount permissions wrong? Check whether userns-remap is enabled and what UID mapping applies to the path.
Network interface missing or unexpected? Confirm whether the container uses an isolated network namespace or --network=host.

None of these require special tooling—just /proc, ip addr, and ls -la.

Wrapping Up

A container is a Linux process. The isolation you observe isn't inherent to Docker—it's a set of namespace configurations that runc applies when the container starts. Those configurations are visible, inspectable, and explicitly changeable.

When isolation breaks in unexpected ways, it's almost always because a namespace is being shared (--pid=host, --network=host) or because UID mapping isn't set up the way you assumed. Check the namespaces, then reason from there.

Watch the full video walkthrough (diagrams + demo)

Docker does not exist: processes and reliability

Backend By Dmytro — Sat, 21 Feb 2026 16:03:31 +0000

Stop me if this has happened to you: you restart the Docker service expecting your Nginx container to die, and it just... keeps serving traffic. That's not a bug. It's the architecture telling you something important about what a "container" actually is.

Here's the mental model shift: a Docker container isn't a VM-like object managed by Docker. It's an application process running on the host kernel, supervised by a chain of other processes—dockerd, containerd, containerd-shim, and runc. Docker as the brand is real; Docker the monolithic runtime is not.

The Setup

Everything below runs on Fedora Linux. MacOS/Windows users: Docker runs a Linux VM under the hood, so the process tree will be inside that VM, not directly on your host.

First, enable live-restore in /etc/docker/daemon.json— this is what lets containers survive a Docker Engine restart:

{
    "live-restore": true
}

Then restart Docker and spin up Nginx:

sudo service docker restart
docker run --rm --name=my-nginx -p 8080:80 -d nginx

What the Host Actually Sees

ps -ef --forest | grep -E 'docker|containerd|nginx' | grep -v grep

The output isn't a single "container" process. You'll see a tree: dockerd → containerd → containerd-shim → nginx. Four separate processes on the host, each with a distinct job. That tree structure is the whole story.

dockerd: REST API and Manager, Not a Runtime

When you run docker run ..., the CLI translates it into a REST API request sent to dockerd. That's it — the CLI is a thin HTTP client.

dockerd handles image management, volume management, and port-mapping (via a spawned docker-proxy process). What it doesn't do is actually run your container. For that, it makes gRPC calls to containerd over /run/containerd/containerd.sock. Think of dockerd as the control plane; the execution happens elsewhere.

containerd: The Actual Runtime

containerd is where execution begins. It's OCI-compliant, which is why Kubernetes can use it directly without Docker at all.

For each container start, containerd:

pulls the image from the registry,
prepares the root filesystem,
spawns a containerd-shim process.

The shim is the key piece. That's what makes the restart behavior make sense.

containerd-shim: The Per-Container Supervisor

Each container gets exactly one containerd-shim. Its responsibilities:

Runs runc to set up Linux namespaces and cgroups, then runc exits—it's just a setup tool
Holds the stdin/stdout/stderr file descriptors for the container process (that's how docker logs and docker attach work)
Relays signals like SIGTERM to the application
Acts as the direct parent of your app process—so the app stays alive even if containerd or dockerd goes away

That last point is the one most people don't expect.

Proof: Stop Docker, Container Keeps Running

sudo systemctl stop docker
ps -ef --forest | grep -E 'docker|containerd|nginx' | grep -v grep

dockerd is gone. containerd, containerd-shim, and nginx are still there. With live-restore: true, the shim holds the process alive independently of the engine.

Go further—kill containerd itself:

sudo kill $(pgrep -o containerd)
ps -ef --forest | grep -E 'containerd|nginx' | grep -v grep

The shim and Nginx survive. The shim is the direct parent; containerd dying is irrelevant to the running workload.

This is what makes zero-downtime Docker Engine upgrades possible: live-restore + the shim architecture means your app doesn't care what the daemons are doing.

Filesystem: No Hard Boundary Against Host Root

Containers provide process isolation—not a security boundary against a root user on the host. Here's proof:

NGINX_PID=$(pgrep -o nginx)
sudo cat /proc/$NGINX_PID/root/etc/nginx/nginx.conf

That's the container's Nginx config, read directly from the host via /proc. No volume mounts, no docker exec. The container's filesystem is just a view the kernel provides; /proc/<pid>/root exposes it to any sufficiently privileged host process.

Security implication: if the host is compromised at root level, assume all containers on that host are too.

What This Changes Operationally

A few places where this model pays off immediately:

Debugging "container still running after Docker restart": check for containerd-shim and your app process on the host—they're just ps entries
Port-mapping issues: docker-proxy is a real process; it shows up in ss or lsof output
Engine upgrades: live-restore: true + a shim-aware mental model = no forced downtime
Security reviews: treat host root access as full container access, because /proc makes it so

The next time you type docker run, what's actually happening is: the CLI talks to an API, the API tells a runtime, the runtime spawns a supervisor, the supervisor sets up isolation via runc and then stays out of the way. Your Nginx is just a process. And that's exactly what makes containers fast, composable, and debuggable with standard Linux tools.

Watch the full video walkthrough (diagrams + demo)

My First Contribution to Symfony (and Why You Should Start Small in Open Source)

Backend By Dmytro — Wed, 24 Sep 2025 17:35:41 +0000

This week, I made my very first contribution to the Symfony Framework — and it got merged! 🎉

Pull Request

The change itself was small: a correction in translations. But the importance for me is huge: it marks the beginning of consistent contributions to the open source ecosystem.

Why does this matter?

Because Symfony is the foundation of much of my professional work.

Because giving back strengthens both the framework and the community.

Because small steps build momentum — no one starts with a huge feature.

If you’re considering contributing to open source but feel overwhelmed: don’t wait. Fixing a typo, clarifying docs, or improving a translation is already valuable.

I’ll continue documenting my journey and sharing tips on how to get involved with Symfony and backend development in general.