OS//virtualization//container

A container is a group of processes that the operating system's kernel runs with its own isolated view of the filesystem, processes and network and its own limits on CPU and memory, packaged together with everything the application needs to run, and it is the standard unit in which software is shipped and scheduled today. A **container image** is the frozen package (the application, its libraries, its configuration); a container is that image running. Docker is the tool that made the format popular, but the isolation itself comes from the Linux kernel, and other runtimes (containerd, Podman) use the same images.

A container is a group of processes that the operating system's kernel runs with its own isolated view of the filesystem, processes and network and its own limits on CPU and memory, packaged together with everything the application needs to run, and it is the standard unit in which software is shipped and scheduled today. A container image is the frozen package (the application, its libraries, its configuration); a container is that image running. Docker is the tool that made the format popular, but the isolation itself comes from the Linux kernel, and other runtimes (containerd, Podman) use the same images.

The difference from a virtual machine is the kernel. A VM boots its own kernel on virtual hardware; a container has no kernel of its own and shares the host's, which the kernel partitions with three mechanisms:

Namespaces control what the processes can see: their own process tree, network interfaces, mount points and hostname.

Cgroups control how much they can use: CPU time, memory, disk and network bandwidth.

Seccomp controls which system calls they may make at all (syscall).

A container shares the kernel, and that is both its advantage and its limit.

Sharing makes it start in milliseconds and cost almost nothing beyond the application itself, so a server runs hundreds of them; but every container trusts the same kernel, so a kernel flaw is a way out for all of them. Containers isolate well enough between a company's own services and not enough on their own between mutually hostile tenants, which is why clouds run customers' containers inside VMs (sandbox).

The real gain is reproducibility. The same image runs on a laptop, in the test pipeline and on a thousand production nodes, which ends the works on my machine problem and lets an orchestrator move containers freely between machines (Kubernetes).

Containers are meant to be disposable. State that must survive goes to volumes, databases or object storage, because any container may be killed and replaced at any moment.

An agent that runs code with a tool such as a subprocess call is usually placed in a container, so whatever the code does stays inside these limits (agent containment).