A container is a lightweight, isolated package that bundles an application with its dependencies and runs as an ordinary process on a shared operating-system kernel — making software portable and reproducible across machines.¹

Same job, two weights. Each virtual machine carries a full guest OS, so the tower is tall; a container holds only the app and shares the one host OS and kernel underneath. Dropping the per-container OS is what makes containers start in a blink and pack far more densely — at the cost of the harder isolation a separate kernel gives.

Overview

Containers are a form of OS-level virtualization. Unlike a virtual machine, a container does not carry its own kernel or boot an operating system; it shares the host’s kernel and is isolated using kernel features such as namespaces (separate views of processes, files, and networking) and cgroups (resource limits). A container starts from an image — a layered, read-only template — so the same image runs identically on a laptop, a server, or the cloud. The result is fast startup, low overhead, and “it works the same everywhere” packaging.

Where it fits

Containers are usually built and run with Docker and orchestrated at scale by Kubernetes. They are lighter than full virtualization under a hypervisor but offer weaker isolation, since all containers share one kernel. Packaging GopherTrunk in a container makes the decoder easy to deploy reproducibly, though USB radio access (the SDR dongle) must be passed through from the host.

Sources

1. Containerization (computing) — Wikipedia, on OS-level containers. ↩

See also

• Docker
• Kubernetes
• Virtualization
• Hypervisor
• Operating system
• Serverless computing