What Is Docker and runC? A Complete Guide to Containerization for Beginners

If you have run docker run ubuntu and wondered what actually happens inside your machine, you are not alone. Containerization looks like magic until you understand the Linux building blocks behind it. This guide explains Docker, runC, and how they work together — the same concepts we teach hands-on in our DevOps course in Coimbatore.

What Is a Container, Really?

A container is not just “a process in a namespace.” Modern containers combine several Linux features working together:

• Namespaces — isolate processes, networking, mount points, hostnames, and more (PID, NET, MNT, UTS, IPC, USER)
• cgroups (control groups) — limit CPU, memory, and I/O so one app cannot starve the host
• Union filesystems — stack image layers efficiently (copy-on-write)
• Container images — portable packages of filesystem + metadata (what Docker popularized)
• Container runtime — the low-level tool that assembles all of the above (runC)

Namespaces alone do not make a container. You need coordinated setup across networking, filesystems, and resource limits — that is what runC does.

What Is Docker?

Docker is a platform that makes containers easy for developers and operations teams. Most people interact with:

• Docker CLI — commands like docker build, docker run, docker ps
• Docker Engine (daemon) — receives API requests and orchestrates container lifecycle
• Docker images — templates with OS libraries, app code, and JSON config (ports, env vars, entrypoint)

Docker did not invent containers — it made them approachable. In production, many teams also use containerd and Kubernetes, which still rely on runC under the hood.

What Is runC?

runC is the Open Container Initiative (OCI) reference implementation of a container runtime. It is not a random mix of namespaces — it carefully configures:

• Network namespace (virtual Ethernet, isolation from host)
• PID namespace (process tree isolation)
• IPC and mount namespaces
• Overlay/union mounts from image layers
• cgroups for resource limits
• Optional user namespace mapping for UID/GID security

Docker Engine delegates container creation to containerd, which calls runC via a protobuf API. The image supplies the filesystem and spec; runC builds the isolated environment.

Step-by-Step: What Happens When You Run docker run ubuntu

1. You type docker run ubuntu — the Docker client sends a request to the Docker daemon over the local API (Unix socket).
2. The daemon finds the ubuntu image locally or pulls it from a registry (Docker Hub).
3. The image contains layered root filesystem (binaries, libraries) plus JSON metadata (config).
4. The daemon asks containerd to create the container (gRPC).
5. containerd invokes runC to set up namespaces, cgroups, and mounts.
6. runC starts a small shim process, then the container init process (e.g. shell or app entrypoint).
7. Ubuntu (or your app) runs inside an environment isolated from the host kernel — sharing the host kernel, unlike VMs.
8. Success flows back: runC → containerd → Docker daemon → your terminal shows a running container.

Understanding this stack helps you debug networking issues, volume mounts, and resource limits — skills employers expect from DevOps engineers.

Common Myths vs Reality

Myth: Containers are just namespaces

Reality: Namespaces are one piece. cgroups, images, runtimes, and networking logic complete the picture.

Myth: Containers are lightweight VMs

Reality: VMs virtualize hardware and run separate kernels. Containers share the host kernel — lighter and faster to start, but different isolation trade-offs.

Myth: You must use Docker everywhere

Reality: Docker is excellent for learning and local development. Production often uses containerd, CRI-O, and Kubernetes — all OCI-compatible.

Myth: Containers are always secure by default

Reality: Containers isolate at the OS level. Kernel vulnerabilities, misconfigured privileges, and weak images still matter. Use scanning, least privilege, and seccomp/AppArmor where appropriate.

Myth: Containers are only for microservices

Reality: You can containerize monoliths, batch jobs, databases (with care), and dev environments — not only microservices.

How the Pieces Connect (Quick Reference)

• Docker Client → Docker API → Docker Daemon
• Docker Daemon → gRPC → containerd
• containerd → runC → isolated container
• Docker image → filesystem + config fed to runC

Why This Matters for Your Career in Coimbatore

Job postings for DevOps, Cloud, and SRE roles routinely list Docker, Kubernetes, and CI/CD. Students who only click buttons without understanding runtimes struggle in interviews and on the job.

At OneInfo Academy, our DevOps training in Coimbatore covers Docker, Kubernetes, Jenkins, Terraform, and AWS with real projects — so you build and ship containers, not just memorize definitions. Graduates have placed in roles from Coimbatore to the UAE using these skills.

Want to go deeper? Combine this with our guides on DevOps engineer salary in India and AWS training for a full cloud career path.

Key Takeaways

• Containers = namespaces + cgroups + layered filesystems + runtime + image format
• Docker simplifies the developer experience; runC does the low-level Linux work
• containerd sits between Docker/Kubernetes and runC in modern stacks
• Knowing the lifecycle helps you troubleshoot and ace technical interviews