# Containerisation – Basics

Generic concepts behind containerisation, applicable to any runtime.

Related pages:

- [Containerisation / Docker Basics](./Docker/Basics.md)

---

## 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](./Docker/Basics.md).
- **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.