113 lines
4.8 KiB
Markdown
113 lines
4.8 KiB
Markdown
# 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.
|