4.8 KiB
Containerisation – Basics
Generic concepts behind containerisation, applicable to any runtime.
Related pages:
1. What Is Containerisation?
Containerisation is a lightweight form of virtualisation. Instead of emulating hardware, it isolates applications at the operating-system level: each container runs in its own namespace but shares the host kernel.
Key benefits:
- Portability – a container image packages the application and its dependencies together and runs the same way on any compatible host.
- Isolation – processes inside a container cannot directly affect other containers or the host.
- Efficiency – containers start in milliseconds and consume far less overhead than virtual machines.
- Reproducibility – images are versioned and built from explicit definitions, making deployments predictable.
2. Containers vs Virtual Machines
| Container | Virtual Machine | |
|---|---|---|
| Kernel | Shared with host | Separate (emulated or paravirtualised) |
| Startup time | Seconds or less | Seconds to minutes |
| Overhead | Very low | Higher (memory, CPU) |
| Isolation | Process-level | Hardware-level |
| Portability | Image-based, very portable | Depends on hypervisor |
Containers are generally chosen when the goal is to package and run applications efficiently. Virtual machines are preferred when stronger isolation or a different operating-system kernel is required.
3. Core Concepts
3.1 Image
An image is a read-only template used to create containers. It bundles:
- A base operating-system layer (for example a minimal Debian or Alpine image).
- Application binaries and their dependencies.
- Configuration and entrypoint instructions.
Images are built from a definition file (for Docker, a Dockerfile) and are composed of layers. Each layer represents a change on top of the previous one, and layers are cached and reused across images.
3.2 Container
A container is a running instance of an image. It is:
- Isolated from the host and other containers through Linux namespaces.
- Resource-limited using control groups (cgroups).
- Ephemeral by default – its writable layer is discarded when the container is removed.
Persistent data must be stored outside the container lifecycle using volumes or bind mounts.
3.3 Registry
A registry is a server that stores and distributes container images. Common examples include:
- Docker Hub – the default public registry.
- GitHub Container Registry (GHCR).
- Self-hosted registries (for example Gitea's built-in package registry or a dedicated Harbor instance).
Images are referenced as registry/name:tag. The tag identifies a specific version.
3.4 Volume
A volume is a mechanism for persisting data independently of the container lifecycle. Two common forms:
- Managed volumes – created and tracked by the container runtime; stored in a dedicated area on the host.
- Bind mounts – a specific host directory exposed inside the container at a given path.
4. Linux Primitives Behind Containers
Containers rely on two core Linux kernel features.
4.1 Namespaces
Namespaces provide process-level isolation for system resources so that each container sees only its own view of the system:
- PID namespace – containers see their own process tree.
- Network namespace – each container gets its own network stack and interfaces.
- Mount namespace – containers see their own filesystem tree.
- UTS namespace – each container can have a distinct hostname.
- User namespace – container user IDs can be remapped to different host IDs.
4.2 cgroups (control groups)
cgroups limit and account for resource consumption per process group:
- CPU usage.
- Memory limits.
- I/O bandwidth.
This prevents a single container from monopolising host resources.
5. Container Runtimes
Several implementations exist:
- Docker – the most widely adopted; includes a CLI, a build system, and Docker Compose for multi-container setups. See Docker / Basics.
- Podman – daemonless and Docker-compatible; supports rootless containers by default.
- containerd – a lower-level runtime used by Kubernetes and sometimes by Docker as its engine backend.
- LXC / LXD – older but still used for system containers, which behave more like lightweight virtual machines than application containers.