Add network & containerisation

Doc/Containerisation/Basics.md

@@ -0,0 +1,112 @@
+# 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.