Processes and Containerization

A container is easier to understand when you first understand a normal Linux process.

A process is a running instance of a program. The program is the file on disk; the process is what the operating system creates when that program is executed.

Program vs Process

Program on disk                  Process in memory
 
/usr/bin/nginx          --->     PID 1234
package file                     code mapped into memory
not running yet                  stack, heap, open files
                                 scheduled by the kernel

The executable file is static. A process is active: it has memory, a process ID, environment variables, file descriptors, and CPU time assigned by the kernel.

Term	Meaning
Program	Executable code stored on disk
Process	A running instance of a program
PID	Process ID assigned by the kernel
Parent process	Process that started another process
Child process	New process created by a parent

What Happens When a Program Runs

At a high level, running a program looks like this:

User runs command
      |
      v
Shell asks kernel to create a process
      |
      v
Kernel assigns a PID and process metadata
      |
      v
Executable code and libraries are mapped into memory
      |
      v
Process is scheduled on CPU
      |
      v
Program instructions execute

In Unix-like systems, this often involves two important ideas:

Step	What It Does
fork	Creates a child process from the current process
exec	Replaces the current process image with a different program

A shell running nginx does not become Nginx forever. The shell starts a child process, and that child process executes the Nginx program.

Shell process
  |
  | fork
  v
Child process
  |
  | exec nginx
  v
Nginx process

Key Insight: Linux already knows how to run isolated units of execution: processes. Containers build on that model instead of replacing it with a full virtual machine.

Where Containers Fit

A container is not magic and it is not a tiny VM. At runtime, it is still one or more processes running on a host operating system.

The difference is that the process runs with extra boundaries around it:

Normal process
 
+----------------------------------+
| Process                          |
| sees host filesystem, network,   |
| process tree, users, limits      |
+----------------------------------+
| Host Linux kernel                |
+----------------------------------+
 
Containerized process
 
+----------------------------------+
| Process                          |
| sees container filesystem,       |
| container network, container PID |
| view, configured resource limits |
+----------------------------------+
| Host Linux kernel                |
+----------------------------------+

The process is real. The isolation is created by Linux kernel features around the process.

Containerization Overview

Containerization packages an application with the files it needs, then runs it as an isolated process on a host OS.

Container image
  app code
  runtime files
  libraries
  default command
       |
       v
Container runtime starts process
       |
       v
Linux kernel applies isolation and limits
       |
       v
Containerized process runs on host OS

The host operating system still provides the kernel. The container provides the application filesystem and runtime environment.

Runtime Engine on the Host OS

Tools like Docker sit above the host OS and make this process manageable.

docker run
    |
    v
Docker client
    |
    v
Docker daemon / engine
    |
    v
Container runtime
    |
    v
Linux kernel
    |
    v
Container process

The runtime engine prepares the container environment and asks the kernel to start the process with the right isolation.

Layer	Role
Docker client	Command-line interface used by the user
Docker daemon / engine	Manages images, containers, networks, and volumes
Container runtime	Starts and manages the container process
Linux kernel	Enforces namespaces, cgroups, filesystems, and process scheduling
Container process	The actual application process

Isolation Building Blocks

Kernel Feature	Simple Meaning
Namespaces	Give a process its own view of things like PIDs, mounts, networking, users, and hostnames
cgroups	Limit and account for resource usage such as CPU, memory, and process counts
Root filesystem	Gives the process a filesystem built from the container image
Capabilities / security settings	Reduce what the process is allowed to do

This is why a process inside a container can feel like it has its own machine, even though it is sharing the host kernel.

PID View Example

Inside a container, the main process often appears as PID 1:

Inside container
 
PID 1  app
PID 7  worker

On the host, those same processes have normal host PIDs:

Host OS
 
PID 48120  app
PID 48135  worker

Both views are valid. The PID namespace changes what the process can see.

Mental Model

Process:   running program managed by the OS
Container: process + packaged filesystem + isolation + resource controls
Docker:    tooling that builds images and asks the runtime to start containers

TL;DR

A process is a running instance of a program.
The kernel assigns a PID, memory, file descriptors, and scheduling time to a process.
Containers are still processes running on the host OS kernel.
Containerization adds a packaged filesystem, isolation, and resource controls around those processes.
Docker is tooling around this model; it is not the kernel feature itself.

Resources

Linux man-pages: fork(2) Linux reference for creating a child process.

Linux man-pages: execve(2) Linux reference for replacing the current process image with a new program.

Linux man-pages: namespaces(7) Linux reference for namespace isolation.

Linux man-pages: cgroups(7) Linux reference for control groups and resource management.

Docker: What is a container? Docker’s explanation of containers as isolated application processes.

Lalit's Cloud & DevOps notes