Vizualizare sursă pentru „OS Lab 10 - Containers and Docker”

<span id="objectives"></span>
== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how containers use Linux kernel namespaces (PID, mount, network, UTS, IPC, user, cgroup) to provide process isolation without requiring separate operating systems or hypervisors.
* Differentiate between container images (immutable filesystem templates) and running containers (ephemeral process instances in isolated namespaces).
* Understand how OverlayFS provides efficient layered filesystems that allow multiple containers to share common base layers while maintaining separate writable layers.
* Apply cgroup resource limits to constrain container CPU, memory, and I/O usage, preventing resource monopolization.
* Configure Docker networking using custom bridges, port mapping (NAT), and container-to-container communication with automatic DNS resolution.
* Use volumes and bind mounts to persist data beyond container lifecycles and share data between containers and the host.
* Build multi-container applications with coordinated networking and resource management, demonstrating modern microservices architecture patterns.
* Connect container concepts to previous labs: relate network namespaces to Lab 7, mount namespaces to Lab 2, PID namespaces to Lab 3, and Docker networking to Labs 7-9.

<span id="introduction"></span>
== Introduction ==

<span id="from-manual-isolation-to-automated-containers"></span>
=== From Manual Isolation to Automated Containers ===

In Labs 7-9, you manually constructed network isolation using Linux kernel primitives. You created virtual network interfaces with <code>ip link add type veth</code>, configured bridges with <code>ip link add type bridge</code>, established isolated network stacks with <code>ip netns add</code>, and set up routing and NAT rules. Through this hands-on work, you gained deep insight into how the Linux kernel provides network isolation at the namespace level.

Every time you executed <code>sudo ip netns exec red ping 10.0.0.3</code>, you were demonstrating a fundamental concept: the kernel can create completely isolated environments where processes see only a subset of system resources. The <code>red</code> namespace had its own network interfaces, its own routing table, and its own firewall rules—completely invisible to processes running in other namespaces or on the host.

This isolation is powerful, but network namespaces are just one of seven namespace types that the Linux kernel provides. To fully isolate an application and create what we call a &quot;container,&quot; you need:

* '''Network namespace''' (<code>net</code>): Isolated network stack—you've mastered this in Labs 7-9
* '''PID namespace''' (<code>pid</code>): Isolated process tree—each namespace has its own PID 1
* '''Mount namespace''' (<code>mnt</code>): Isolated filesystem view—different root directory from the host
* '''UTS namespace''' (<code>uts</code>): Isolated hostname—each container can have its own hostname
* '''IPC namespace''' (<code>ipc</code>): Isolated inter-process communication—shared memory, semaphores, message queues
* '''User namespace''' (<code>user</code>): Isolated UIDs/GIDs—security boundary for privilege separation
* '''Cgroup namespace''' (<code>cgroup</code>): Isolated view of control group hierarchy

Additionally, you need:

* '''Control groups (cgroups)''' to limit CPU, memory, and I/O resources
* '''Copy-on-write filesystems''' (OverlayFS) for efficient storage
* '''Image management''' for distributing application packages
* '''Orchestration''' for managing the lifecycle of multiple isolated environments

Manually setting up all of these components for every application would require hundreds of commands and deep kernel knowledge. This is the problem that containerization technology solves.

<span id="what-are-containers"></span>
=== What are Containers? ===

A '''container''' is an isolated process (or process tree) that uses Linux kernel features—namespaces, cgroups, and layered filesystems—to provide the illusion of running in a separate system. Containers package an application with its dependencies, libraries, and configuration into a single unit that can run consistently across different environments.

Containers are not a specific product or tool—they are a pattern for using kernel isolation features. Multiple container runtimes exist, each implementing this pattern:

'''Container Runtimes:'''

* '''Docker''': The most widely adopted container platform, providing a complete ecosystem (daemon, CLI, image format, registry)
* '''Podman''': Daemonless container engine, compatible with Docker images and commands, can run rootless
* '''containerd''': Industry-standard container runtime, used by Kubernetes and Docker (as of Docker 1.11+)
* '''CRI-O''': Lightweight container runtime built for Kubernetes, implementing the Container Runtime Interface (CRI)
* '''LXC/LXD''': System containers that more closely resemble traditional VMs, providing full init systems

'''What Container Runtimes Provide:'''

# '''Namespace Management''': Automatically create and configure all necessary namespace types
# '''Filesystem Layers''': Use OverlayFS or similar copy-on-write filesystems for efficient storage
# '''Network Configuration''': Set up bridges, veth pairs, and NAT rules automatically
# '''Resource Control''': Configure cgroups to enforce CPU and memory limits
# '''Image Distribution''': Provide standard formats (OCI) for packaging and distributing applications
# '''Lifecycle Management''': Offer commands to create, start, stop, and remove containers

<span id="docker-as-a-container-runtime"></span>
=== Docker as a Container Runtime ===

In this lab, we use '''Docker''' because it is the most widely deployed and well-documented container runtime. Docker's architecture consists of:

* '''Docker Engine (dockerd)''': Daemon that manages containers
* '''Docker CLI (docker)''': Command-line interface for interacting with the daemon
* '''containerd''': Lower-level runtime that Docker uses internally
* '''runc''': OCI-compliant runtime that actually creates and runs containers

When you execute <code>docker run nginx</code>, Docker performs approximately 50-100 system calls to configure namespaces, mount filesystems, set up networking, and start the process—all operations you could do manually but would require significant time and expertise.

The concepts you learn with Docker apply to all container runtimes, as they all use the same underlying kernel features. The commands may differ (e.g., <code>podman run</code> instead of <code>docker run</code>), but the fundamental mechanisms remain the same.

<span id="the-shift-in-software-deployment"></span>
=== The Shift in Software Deployment ===

Containers represent a fundamental paradigm shift in how we think about software deployment and infrastructure management.

'''Traditional Deployment Model (Pre-Container Era):'''

<pre>1. Provision a server (physical or virtual machine)
2. Install operating system (Ubuntu, RHEL, etc.)
3. Install runtime dependencies (Python 3.9, Node.js 16, specific library versions)
4. Configure environment variables, users, permissions
5. Deploy application code
6. Configure monitoring, logging, security
7. Hope everything works the same as on your development machine
8. Troubleshoot when it doesn't (&quot;works on my machine&quot; problem)</pre>
This model suffers from several critical issues:

* '''Dependency Hell''': Different applications require different, potentially conflicting library versions
* '''Configuration Drift''': Development, staging, and production environments gradually diverge
* '''Snowflake Servers''': Each server becomes unique and unreproducible
* '''Slow Deployment''': Setting up a new environment can take hours or days
* '''Poor Resource Utilization''': Applications can't share servers due to dependency conflicts

'''Container-Based Deployment Model:'''

<pre>1. Developer creates Dockerfile specifying exact environment
2. Build process creates immutable container image with all dependencies
3. Image tested in CI/CD pipeline (identical to production)
4. Image deployed to any server with Docker installed
5. Container starts in seconds with guaranteed-identical environment
6. Multiple isolated applications run on same host without conflicts</pre>
This model provides:

* '''Immutable Infrastructure''': Images never change after building; deploy new versions rather than modifying running systems
* '''Reproducibility''': Development environment = testing environment = production environment
* '''Portability''': &quot;Build once, run anywhere&quot; (laptop, data center, cloud)
* '''Efficiency''': Run 10-100 containers on a single host (vs. 5-10 VMs)
* '''Rapid Deployment''': Start containers in milliseconds vs. minutes for VMs
* '''Microservices Architecture''': Enables decomposing monoliths into independently deployable services

This shift has revolutionized software engineering, enabling modern DevOps practices, continuous deployment, and cloud-native architectures. Companies like Netflix, Uber, and Airbnb run millions of containers to serve billions of requests daily.

<span id="containers-vs-virtual-machines"></span>
=== Containers vs Virtual Machines ===

Understanding the architectural difference between containers and virtual machines is crucial for appreciating why containers have become the dominant deployment model.

'''Virtual Machine Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│   App A     │ │   App B     │ │   App C     │
├─────────────┤ ├─────────────┤ ├─────────────┤
│  Libraries  │ │  Libraries  │ │  Libraries  │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Guest OS    │ │ Guest OS    │ │ Guest OS    │
│ (Kernel)    │ │ (Kernel)    │ │ (Kernel)    │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
       Hypervisor (VMware, KVM, Xen)
─────────────────────────────────────────────────
        Host Operating System &amp; Kernel
─────────────────────────────────────────────────
                 Hardware</pre>
'''Characteristics:'''

* Each VM runs a complete guest operating system with its own kernel
* Hypervisor emulates hardware, providing virtual CPUs, RAM, disks, NICs
* Strong isolation (separate kernels mean vulnerabilities in one VM don't affect others)
* Heavy resource consumption (each OS kernel needs 1-2GB RAM)
* Slow startup (boot entire OS: 30-60 seconds)
* Large disk footprint (each VM stores complete OS: 1-10GB)

'''Container Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│   App A     │ │   App B     │ │   App C     │
├─────────────┤ ├─────────────┤ ├─────────────┤
│  Libraries  │ │  Libraries  │ │  Libraries  │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
       Container Runtime (Docker Engine)
─────────────────────────────────────────────────
    Host Operating System &amp; Shared Kernel
─────────────────────────────────────────────────
                 Hardware</pre>
'''Characteristics:'''

* All containers share the host's kernel (no guest OS needed)
* Container runtime manages namespace and cgroup isolation
* Lightweight isolation (namespaces separate processes, but they're still just processes)
* Minimal resource overhead (containers use only incremental memory beyond their application)
* Fast startup (start process in isolated namespace: milliseconds)
* Small disk footprint (layered filesystem shares common base images: 10-100MB incremental)

'''The Trade-off:'''

Virtual machines provide '''stronger security isolation''' at the cost of '''resource efficiency'''. If your threat model requires complete kernel isolation (e.g., multi-tenant cloud providers hosting untrusted code), VMs are appropriate.

Containers provide '''lighter-weight isolation''' with '''much better resource efficiency'''. If you're running your own applications on your own infrastructure, containers are usually the right choice. You can run 10-100 containers on hardware that would support only 5-10 VMs.

'''An Important Insight:''' When you run <code>ps aux</code> on the host, you see container processes. They're not hidden inside separate kernels like VM processes would be. This demonstrates that containers are just isolated processes on the host—the kernel makes them appear isolated through namespaces, but they're fundamentally just processes.

This is both a feature (efficiency, observability) and a constraint (shared kernel means a kernel vulnerability could affect all containers). Modern container security practices use defense-in-depth: namespaces + cgroups + seccomp + AppArmor/SELinux + user namespaces to create multiple security layers.

<span id="prerequisites"></span>
== Prerequisites ==

<span id="system-requirements"></span>
=== System Requirements ===

* '''Operating System''': Linux-based system (Ubuntu 20.04+ recommended, but Debian, Fedora, CentOS also supported)
* '''RAM''': Minimum 2GB, 4GB recommended for comfortable operation
* '''Disk Space''': At least 20GB free (Docker images and container layers consume significant space)
* '''CPU''': Any modern x86_64 or ARM64 processor
* '''Privileges''': Root access via <code>sudo</code> (required for Docker installation and initial setup)
* '''Kernel''': Minimum Linux kernel 3.10 (kernel 4.0+ recommended for full feature support)

'''Check your kernel version:'''

<syntaxhighlight lang="bash">uname -r</syntaxhighlight>
If below 3.10, you'll need to update your kernel before proceeding.

'''Check available disk space:'''

<syntaxhighlight lang="bash">df -h /var/lib/docker</syntaxhighlight>
Docker stores images and containers in <code>/var/lib/docker</code> by default. Ensure you have sufficient space.

<span id="required-packages"></span>
=== Required Packages ===

Before beginning, ensure the following packages are installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release \
    bridge-utils \
    net-tools</syntaxhighlight>
'''Package descriptions:'''

* <code>apt-transport-https</code>: Enables apt to retrieve packages over HTTPS
* <code>ca-certificates</code>: Common CA certificates for SSL verification
* <code>curl</code>: Command-line tool for transferring data (used to download Docker's GPG key)
* <code>gnupg</code>: GNU Privacy Guard for verifying package signatures
* <code>lsb-release</code>: Provides Linux Standard Base version information (used to detect Ubuntu version)
* <code>bridge-utils</code>: Tools for managing bridge devices (<code>brctl</code> command)
* <code>net-tools</code>: Legacy networking tools (<code>ifconfig</code>, <code>netstat</code>) for compatibility

<span id="knowledge-prerequisites"></span>
=== Knowledge Prerequisites ===

This lab builds directly on concepts from previous labs. You should be comfortable with:

'''From Lab 2 (Filesystems):'''

* Filesystem hierarchy and directory structure
* Mount points and the <code>mount</code> command
* Understanding of <code>/</code>, <code>/etc</code>, <code>/var</code>, <code>/usr</code> purposes
* File permissions and ownership (<code>chmod</code>, <code>chown</code>)
* Symbolic links and filesystem navigation

'''From Lab 3 (Processes and Jobs):'''

* Process IDs (PIDs) and process hierarchy
* Parent-child process relationships
* <code>ps aux</code> command and process listing
* Foreground vs. background processes
* Process signals (SIGTERM, SIGKILL)

'''From Lab 4 (Users, Groups, and Permissions):'''

* User IDs (UIDs) and group IDs (GIDs)
* Root vs. unprivileged users
* <code>sudo</code> for privilege escalation
* File and directory permissions (read, write, execute)
* Security implications of running processes as root

'''From Lab 7 (Network Fundamentals):'''

* Network interfaces and IP addresses
* Bridges and virtual ethernet (veth) pairs
* Subnets and CIDR notation
* Routing tables and default gateways
* Network Address Translation (NAT)
* '''Network namespaces''' (<code>ip netns add</code>, <code>ip netns exec</code>)

This is crucial—Docker networking uses the exact same mechanisms you built manually.

'''From Lab 8 (Transport and Security):'''

* TCP and UDP protocols
* Port numbers and socket addresses (IP:PORT)
* Client-server communication model
* The concept of listening vs. connecting
* TLS/SSL (Docker can use HTTPS for secure image distribution)

'''From Lab 9 (Application Protocols):'''

* HTTP/HTTPS protocols
* Reverse proxies and path-based routing
* DNS and hostname resolution
* Caddy web server configuration
* Multi-tier application architecture

You should also be comfortable with:

* Command-line text manipulation (<code>grep</code>, <code>awk</code>, <code>cut</code>, <code>sed</code>)
* Basic bash scripting (variables, loops, conditionals)
* Using multiple terminal windows simultaneously

<span id="theoretical-background"></span>
== Theoretical Background ==

<span id="linux-namespaces-the-foundation-of-containers"></span>
=== Linux Namespaces: The Foundation of Containers ===

In Labs 7-9, you worked extensively with network namespaces—one of seven namespace types provided by the Linux kernel. Every time you executed:

<syntaxhighlight lang="bash">sudo ip netns add red
sudo ip netns exec red ip addr show</syntaxhighlight>
You were creating an isolated network environment and executing commands within that isolated environment. The processes running in the <code>red</code> namespace could not see network interfaces, routes, or connections in other namespaces. This isolation is the fundamental mechanism that makes containers possible.

Docker extends this concept to six additional namespace types, providing complete process isolation. Understanding namespaces is essential to understanding containers—they are not optional background knowledge, but rather the core technology that defines what a container is.

<span id="the-seven-namespace-types"></span>
==== The Seven Namespace Types ====

'''1. Network Namespace (<code>net</code>)'''

You know this namespace intimately from Labs 7-9. When you created the <code>red</code> and <code>blue</code> namespaces, you were creating isolated network stacks.

'''What it isolates:'''

* Network interfaces (lo, eth0, wlan0, etc.)
* IP addresses (each namespace has its own IPs)
* Routing tables (<code>ip route show</code> output differs per namespace)
* Firewall rules (iptables/nftables rules are namespace-specific)
* Network sockets and ports (multiple processes in different namespaces can bind to the same port number)

'''Connection to Lab 7:'''

In Lab 7, you manually created network namespaces:

<syntaxhighlight lang="bash">sudo ip netns add red                    # Create isolated network stack
sudo ip netns exec red ip link show      # View interfaces in that namespace</syntaxhighlight>
Docker does exactly this when you run a container, but also creates six other namespace types simultaneously.

'''Example implications:'''

* Container A can listen on port 80, Container B can listen on port 80—no conflict
* Container A cannot see Container B's network connections (<code>ss -tuna</code> shows only its own)
* Each container has its own localhost (127.0.0.1) that's separate from the host

'''2. PID Namespace (<code>pid</code>)'''

The PID namespace isolates the process ID number space. This is related to what you learned in Lab 3 about process management.

'''What it isolates:'''

* Process IDs—processes in different PID namespaces can have the same PID
* Process visibility—processes can only see other processes in the same PID namespace
* PID 1 (init process)—each PID namespace has its own PID 1

'''How it works:'''

The kernel maintains a separate process tree for each PID namespace. When you create a PID namespace and start a process in it:

* Inside the namespace, that process is PID 1 (like an init system)
* Outside the namespace, that same process has a different PID (e.g., 12345)
* Processes inside cannot see processes outside their namespace tree

'''Example:'''

<syntaxhighlight lang="bash"># On the host
ps aux | wc -l
# Output: 237 processes

# Inside a container
docker exec container ps aux | wc -l
# Output: 5 processes</syntaxhighlight>
The container's processes think they're the only processes on the system. They cannot see the host's other 232 processes.

'''3. Mount Namespace (<code>mnt</code>)'''

The mount namespace isolates the filesystem mount table. This relates directly to Lab 2 where you learned about filesystems and mounting.

'''What it isolates:'''

* Mount points—what is mounted at <code>/</code>, <code>/tmp</code>, <code>/var</code>, etc.
* Root filesystem—each namespace can have a completely different root directory
* Mount propagation—mounts in one namespace don't affect others (by default)

'''How it works:'''

When you create a mount namespace, the new namespace inherits a copy of the parent's mount table. But subsequent mounts/unmounts in the child don't affect the parent.

Containers use this to provide a completely different filesystem:

<syntaxhighlight lang="bash"># On host (Ubuntu)
ls /
bin  boot  dev  etc  home  lib  ...

# In container (Fedora)
docker exec fedora ls /
bin  boot  dev  etc  home  lib  ...  # Different files!</syntaxhighlight>
Both see <code>/etc</code>, but they're seeing different directories. The container's <code>/etc/os-release</code> shows Fedora, while the host's shows Ubuntu.

'''Technical implementation:'''

Docker uses OverlayFS (covered later) to construct the container's root filesystem from image layers, then uses pivot_root or chroot to make that directory appear as <code>/</code> to the container's processes.

'''4. UTS Namespace (<code>uts</code>)'''

UTS stands for &quot;Unix Timesharing System&quot;—a historical name. The UTS namespace isolates hostname and domain name.

'''What it isolates:'''

* System hostname (<code>hostname</code> command output)
* Domain name (NIS domain name)

'''How it works:'''

Each UTS namespace can set its own hostname independently of other namespaces.

<syntaxhighlight lang="bash"># On host
hostname
# Output: myserver.example.com

# In container
docker exec container hostname
# Output: a1b2c3d4e5f6  (container ID)</syntaxhighlight>
Containers typically use the container ID as hostname by default, but you can override with <code>--hostname</code>:

<syntaxhighlight lang="bash">docker run --hostname=webserver nginx</syntaxhighlight>
'''5. IPC Namespace (<code>ipc</code>)'''

The IPC namespace isolates System V Inter-Process Communication resources. This relates to Lab 6 where you learned about IPC mechanisms.

'''What it isolates:'''

* System V message queues
* System V semaphore sets
* System V shared memory segments
* POSIX message queues (in <code>/dev/mqueue</code>)

'''Connection to Lab 6:'''

In Lab 6, you learned that processes can communicate via shared memory, message queues, and semaphores. The IPC namespace ensures that processes in different namespaces cannot access each other's IPC objects, even if they use the same IPC keys.

'''Example:'''

<syntaxhighlight lang="bash"># Container A creates shared memory segment with key 1234
docker exec containerA ipcmk -M 1024 -p 1234

# Container B tries to access it
docker exec containerB ipcs -m -k 1234
# Output: no segment found (different IPC namespace)</syntaxhighlight>
'''6. User Namespace (<code>user</code>)'''

The user namespace isolates user IDs (UIDs) and group IDs (GIDs). This is the most complex namespace and provides significant security benefits.

'''What it isolates:'''

* User IDs—UID 0 inside namespace can map to UID 100000 outside
* Group IDs—similar mapping for GIDs
* Capabilities—process can have capabilities inside namespace but not outside
* Security attributes—AppArmor/SELinux contexts

'''How it works:'''

User namespaces allow UID/GID mapping. A process can be root (UID 0) inside the namespace but unprivileged (e.g., UID 100000) outside.

<pre>Inside Container: UID 0 (root)
        ↓ mapping
Outside Container: UID 100000 (unprivileged)</pre>
'''Security benefit:'''

Even if an attacker compromises a container and gains root privileges inside the container, they're still unprivileged on the host. If they escape the container, they cannot access files owned by actual root.

'''Docker's approach:'''

By default, many Docker configurations share the host's user namespace (for simplicity and compatibility). Rootless Docker and user-remapped Docker use separate user namespaces for enhanced security.

'''7. Cgroup Namespace (<code>cgroup</code>)'''

The cgroup namespace isolates the view of the cgroup hierarchy. Note this is different from cgroups themselves (which we'll cover separately).

'''What it isolates:'''

* View of <code>/proc/self/cgroup</code>
* View of <code>/sys/fs/cgroup</code> hierarchy
* Ability to see other containers' resource constraints

'''How it works:'''

Without cgroup namespaces, a process can read <code>/proc/self/cgroup</code> and see the full path to its cgroup, revealing information about the container orchestration system.

With cgroup namespaces, the process sees itself at the root of the cgroup tree, hiding the real hierarchy.

'''Note:''' This namespace isolates the ''view'' of cgroups, not the enforcement of resource limits. Resource limits are enforced by cgroups themselves (covered in section 4.5).

<span id="namespace-identifiers-understanding-procpidns"></span>
==== Namespace Identifiers: Understanding /proc/PID/ns/ ====

Every process has a directory at <code>/proc/PID/ns/</code> containing symbolic links to namespace identifiers. These links reveal which namespaces the process belongs to.

'''Examining namespace identifiers:'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/</syntaxhighlight>
'''Example output:'''

<pre>lrwxrwxrwx 1 root root 0 Dec 12 10:30 cgroup -&gt; 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 ipc -&gt; 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 mnt -&gt; 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 net -&gt; 'net:[4026531992]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 pid -&gt; 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 user -&gt; 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 uts -&gt; 'uts:[4026531838]'</pre>
'''Understanding the format:'''

Each symlink follows the pattern: <code>namespace_type:[inode_number]</code>

The '''inode number''' is the critical piece of information. It uniquely identifies that specific namespace instance. Think of it as a &quot;namespace ID.&quot;

'''Key principle: Same inode = Shared namespace, Different inode = Isolated namespace'''

'''Example from Lab 7:'''

When you created network namespaces in Lab 7, each had a unique network namespace inode:

<syntaxhighlight lang="bash"># Host process
sudo ls -la /proc/$$/ns/net
net -> 'net:[4026531992]'  # Host's network namespace

# Process in red namespace
sudo ip netns exec red ls -la /proc/$$/ns/net
net -> 'net:[4026532145]'  # Different inode = isolated!

# Process in blue namespace
sudo ip netns exec blue ls -la /proc/$$/ns/net
net -> 'net:[4026532147]'  # Also different = also isolated!</syntaxhighlight>
'''Comparing container to host:'''

<syntaxhighlight lang="bash"># Get container's PID on host
docker inspect container --format '{{.State.Pid}}'
# Example output: 12345

# View container's namespaces
sudo ls -la /proc/12345/ns/net
# Output: net -> 'net:[4026533672]'

# View host's namespace
sudo ls -la /proc/$$/ns/net
# Output: net -> 'net:[4026531992]'

# Different inodes! Container is isolated.</syntaxhighlight>
'''Namespace sharing:'''

Sometimes containers intentionally share namespaces. For example:

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
This container shares the host's network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]'  # Same as host!</syntaxhighlight>
'''Using namespace identifiers:'''

These symlinks aren't just informational—you can actually use them to enter namespaces:

<syntaxhighlight lang="bash">sudo nsenter --net=/proc/12345/ns/net ip addr show</syntaxhighlight>
This command enters the network namespace of PID 12345 and runs <code>ip addr show</code> inside that namespace. This is how <code>docker exec</code> works under the hood—it uses <code>nsenter</code> to join the container's namespaces.

'''Summary table:'''

{| class="wikitable"
|-
! Namespace Type
! What It Isolates
! Lab Connection
|-
| <code>net</code>
| Network stack (interfaces, IPs, routes, ports)
| Lab 7: You built this manually!
|-
| <code>pid</code>
| Process IDs and process tree
| Lab 3: Process management
|-
| <code>mnt</code>
| Filesystem mounts and root directory
| Lab 2: Mounting and filesystems
|-
| <code>uts</code>
| Hostname and domain name
| -
|-
| <code>ipc</code>
| Shared memory, message queues, semaphores
| Lab 6: IPC mechanisms
|-
| <code>user</code>
| User and group IDs, capabilities
| Lab 4: Users and permissions
|-
| <code>cgroup</code>
| View of cgroup hierarchy
| -
|}

<span id="container-images-vs-running-containers"></span>
=== Container Images vs Running Containers ===

This distinction is fundamental to understanding Docker and is often a source of confusion.

'''Container Image:'''

A container image is a '''read-only template''' consisting of:

# '''A root filesystem''': All files and directories that will appear in the container (applications, libraries, configuration files)
# '''Metadata''': Information about how to run the container (default command, environment variables, exposed ports, volumes)
# '''Layers''': The filesystem is composed of multiple read-only layers (explained in section 4.4)

'''Characteristics:'''

* '''Immutable''': Once built, an image never changes
* '''Shareable''': Multiple containers can use the same image
* '''Versionable''': Images can have tags (e.g., <code>nginx:1.21</code>, <code>nginx:latest</code>)
* '''Distributable''': Images can be pushed to/pulled from registries (Docker Hub, private registries)
* '''Stored on disk''': Images consume storage even when not running

'''Running Container:'''

A running container is an '''instance''' of an image—a process (or process tree) running in isolated namespaces with its own writable filesystem layer.

'''Characteristics:'''

* '''Ephemeral''': State is lost when the container is removed (unless using volumes)
* '''Mutable''': Can make changes inside the container (install packages, create files)
* '''Process-based''': A container is fundamentally just a Linux process in isolated namespaces
* '''Short-lived''': Containers are typically created, used, and destroyed frequently
* '''Stateful during runtime''': Maintains state while running, but that state disappears on removal

'''Example to illustrate:'''

<syntaxhighlight lang="bash"># Pull an image (download the template)
docker pull nginx

# The image now exists on disk
docker images
# Output shows: nginx  latest  a1b2c3d4  100MB

# Start first container from this image
docker run -d --name web1 nginx

# Start second container from the same image  
docker run -d --name web2 nginx

# Both containers share the same base image filesystem
# But each has its own writable layer and separate namespaces</syntaxhighlight>
Now you have:

* '''One image''' (nginx:latest) on disk
* '''Two containers''' (web1 and web2) running as separate processes
* Each container has its own PID namespace, network namespace, etc.
* Changes in web1 don't affect web2 (isolated writable layers)

'''Verification:'''

<syntaxhighlight lang="bash"># Modify web1
docker exec web1 bash -c "echo 'Hello from web1' > /usr/share/nginx/html/test.txt"

# Check web1
docker exec web1 cat /usr/share/nginx/html/test.txt
# Output: Hello from web1

# Check web2
docker exec web2 cat /usr/share/nginx/html/test.txt
# Output: cat: /usr/share/nginx/html/test.txt: No such file or directory</syntaxhighlight>
The file exists in web1 but not in web2, even though they're from the same image. Each container has its own writable layer.

'''Image to Container Relationship Diagram:'''

<pre>          [nginx Image]
          (Read-only)
               |
     ┌─────────┴─────────┐
     ↓                   ↓
[Container 1]       [Container 2]
(Writable layer)    (Writable layer)
(PID namespace)     (PID namespace)
(Net namespace)     (Net namespace)
(Isolated)          (Isolated)</pre>
'''Filesystem perspective:'''

<pre>Image Layers (read-only, shared):
├─ Layer 3: nginx files
├─ Layer 2: nginx dependencies  
└─ Layer 1: Base OS (Debian)

Container 1 (writable, unique):
└─ Writable layer: Changes made in container 1

Container 2 (writable, unique):
└─ Writable layer: Changes made in container 2</pre>
'''Why this design?'''

* '''Efficiency''': 100 containers from the same image share one copy of the base filesystem
* '''Speed''': Starting a container doesn't require copying files—just create a new writable layer
* '''Consistency''': All containers from an image start with identical state
* '''Immutability''': Encourages treating containers as disposable—don't modify running containers, rebuild images instead

<span id="container-lifecycle-and-ephemeral-nature"></span>
=== Container Lifecycle and Ephemeral Nature ===

Understanding the container lifecycle is essential for proper container usage. Containers are designed to be ephemeral—short-lived and replaceable.

'''Container States:'''

<pre>┌─────────┐
│ Created │ (Container exists but not running)
└────┬────┘
     │ docker start
     ↓
┌─────────┐
│ Running │ (Processes executing in isolated namespaces)
└────┬────┘
     │ docker stop (SIGTERM, then SIGKILL after timeout)
     ↓
┌─────────┐
│ Stopped │ (Processes terminated, filesystem layer persists)
└────┬────┘
     │ docker start (restart with same writable layer)
     ↓
┌─────────┐
│ Running │
└────┬────┘
     │ docker rm (delete container)
     ↓
┌─────────┐
│ Removed │ (Container and writable layer deleted forever)
└─────────┘</pre>
'''Key lifecycle commands:'''

<syntaxhighlight lang="bash"># Create and start in one step (most common)
docker run nginx

# Create without starting
docker create --name test nginx

# Start existing stopped container
docker start test

# Stop running container (SIGTERM to main process)
docker stop test

# Force stop (SIGKILL)
docker kill test

# Remove stopped container
docker rm test

# Remove running container (force)
docker rm -f test</syntaxhighlight>
'''The Ephemeral Nature:'''

By default, all changes made inside a container are lost when the container is removed:

<syntaxhighlight lang="bash"># Start container
docker run -d --name demo nginx

# Make changes inside
docker exec demo bash -c "echo 'My data' > /tmp/important.txt"
docker exec demo cat /tmp/important.txt
# Output: My data

# Stop and remove container
docker stop demo
docker rm demo

# Try to access the data
docker run --name demo2 nginx
docker exec demo2 cat /tmp/important.txt
# Output: cat: /tmp/important.txt: No such file or directory
# THE DATA IS GONE!</syntaxhighlight>
'''Why ephemeral?'''

This might seem like a limitation, but it's actually a feature that enables important practices:

# '''Immutable Infrastructure''': Don't patch running systems; deploy new versions
# '''Reproducibility''': Every deployment starts from a known state
# '''Testing''': Test environments are identical to production
# '''Rollback''': Easy to roll back to previous image version
# '''Scaling''': Identical containers can be created/destroyed dynamically

'''When you need persistence:'''

For data that must survive container restarts, use '''volumes''' (covered in section 4.7):

<syntaxhighlight lang="bash"># Create named volume
docker volume create mydata

# Use volume in container
docker run -v mydata:/data nginx

# Data in /data survives container removal</syntaxhighlight>
'''Container lifecycle best practices:'''

* '''Treat containers as cattle, not pets''': Don't name them, don't SSH into them to debug, don't manually configure them
* '''Logs go to stdout/stderr''': Not to files inside the container (so <code>docker logs</code> can capture them)
* '''Configuration via environment variables''': Not by editing files inside the container
* '''Data goes in volumes''': Not in the container's writable layer
* '''Short-lived processes''': Containers should start quickly and shut down gracefully

'''Connection to Lab 3:'''

In Lab 3, you learned about process lifecycle (start, run, terminate). Containers follow a similar lifecycle, but operate at a higher level of abstraction—each container lifecycle event actually involves creating/destroying multiple processes in isolated namespaces.

<span id="control-groups-cgroups-resource-limiting"></span>
=== Control Groups (cgroups): Resource Limiting ===

Control groups (cgroups) are a Linux kernel feature that limits, accounts for, and isolates resource usage (CPU, memory, disk I/O, network) of process groups. Without cgroups, a runaway container could consume all CPU or memory, starving other containers and crashing the host.

'''The Problem:'''

Without resource limits:

<syntaxhighlight lang="bash"># Malicious or buggy container
docker run -d evil-container

# This container's process could:
# - Consume 100% CPU (slow down everything else)
# - Allocate all available RAM (trigger OOM killer on host)
# - Fill up disk space (crash other containers)
# - Monopolize network bandwidth</syntaxhighlight>
This is unacceptable in multi-tenant environments. You need resource isolation.

'''The Solution: cgroups'''

Cgroups organize processes into hierarchical groups with configurable resource limits. The kernel enforces these limits, preventing processes from exceeding their allocation.

'''Cgroup Controllers:'''

The Linux kernel provides several cgroup controllers, each managing a different resource type:

# '''cpu''': Limits CPU time
#* CPU shares (relative priority)
#* CPU quotas (hard limits)
#* CPU affinity (pin to specific cores)
# '''memory''': Limits RAM usage
#* Hard limits (container killed if exceeded)
#* Soft limits (reclaim memory under pressure)
#* Swap limits
# '''blkio''': Limits disk I/O
#* Read/write bandwidth limits
#* I/O operation rate limits
# '''net_cls/net_prio''': Network bandwidth control
#* Traffic classification
#* Priority settings
# '''pids''': Limits number of processes
#* Prevents fork bombs
# '''cpuset''': Assigns specific CPUs and memory nodes
#* NUMA awareness

'''Docker's cgroup integration:'''

When you start a container with resource limits, Docker configures the appropriate cgroups:

<syntaxhighlight lang="bash">docker run --memory=512m --cpus=1.5 nginx</syntaxhighlight>
Docker creates a cgroup hierarchy at <code>/sys/fs/cgroup/</code> and configures:

* <code>memory.limit_in_bytes = 536870912</code> (512MB)
* <code>cpu.cfs_quota_us</code> and <code>cpu.cfs_period_us</code> to enforce 1.5 CPUs

'''Viewing cgroup settings:'''

<syntaxhighlight lang="bash"># Get container's PID
docker inspect container --format '{{.State.Pid}}'
# Example: 12345

# View memory limit
cat /sys/fs/cgroup/memory/docker/12345/memory.limit_in_bytes
# Output: 536870912

# View CPU quota
cat /sys/fs/cgroup/cpu/docker/12345/cpu.cfs_quota_us
# Output: 150000 (1.5 CPUs)</syntaxhighlight>
'''Common resource limit flags:'''

<syntaxhighlight lang="bash"># Memory limits
--memory=512m              # Hard limit: 512MB RAM
--memory-reservation=256m  # Soft limit: try to stay under 256MB
--memory-swap=512m         # Total memory+swap limit

# CPU limits
--cpus=1.5                 # Use at most 1.5 CPU cores
--cpu-shares=512           # Relative CPU priority (default 1024)
--cpuset-cpus=0,1          # Pin to CPU cores 0 and 1

# I/O limits
--device-read-bps=/dev/sda:10mb    # Limit read bandwidth
--device-write-bps=/dev/sda:10mb   # Limit write bandwidth

# Process limits
--pids-limit=100           # Max 100 processes in container</syntaxhighlight>
'''Testing memory limits:'''

<syntaxhighlight lang="bash"># Run container with 256MB memory limit
docker run -it --memory=256m ubuntu bash

# Inside container, try to allocate 512MB
# (requires 'stress' tool)
apt-get update && apt-get install -y stress
stress --vm 1 --vm-bytes 512M

# Container is killed when exceeding limit
# Output: stress: FAIL: [1] (415) <-- worker 7 got signal 9
# Signal 9 = SIGKILL (OOM killer)</syntaxhighlight>
'''Why cgroups are essential:'''

# '''Multi-tenancy''': Run untrusted workloads safely
# '''Quality of Service''': Guarantee resources for critical applications
# '''Fair sharing''': Prevent one container from monopolizing resources
# '''Predictability''': Know exactly how much resources each container can use
# '''Cost control''': In cloud environments, map cgroups to billing

'''cgroup vs namespace distinction:'''

* '''Namespaces''': Provide ''isolation''
* '''cgroups''': Provide ''resource limits''

Both are necessary for containers. Namespaces prevent containers from seeing each other; cgroups prevent containers from starving each other.

<span id="docker-networking-bridges-veth-pairs-and-nat"></span>
=== Docker Networking: Bridges, veth Pairs, and NAT ===

Docker networking should feel familiar—it uses the exact same mechanisms you built manually in Lab 7. The primary difference is automation: Docker sets up bridges, veth pairs, routes, and NAT rules automatically.

'''Default Docker Network Architecture:'''

When you install Docker, it creates a default bridge network:

<pre>┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│  Container A    │  │  Container B    │  │  Container C    │
│  172.17.0.2     │  │  172.17.0.3     │  │  172.17.0.4     │
└────────┬────────┘  └────────┬────────┘  └────────┬────────┘
         │eth0               │eth0               │eth0
         │                   │                   │
      (veth pair)         (veth pair)         (veth pair)
         │                   │                   │
    ┌────┴───────────────────┴───────────────────┴────┐
    │              docker0 Bridge                      │
    │              172.17.0.1/16                       │
    └────────────────────┬─────────────────────────────┘
                         │
                    [Host eth0]
                         │
                    [Internet]
                   (via NAT/MASQUERADE)</pre>
'''Component breakdown (all from Lab 7!):'''

'''1. Bridge Interface (<code>docker0</code>)'''

Docker automatically creates a bridge interface when installed:

<syntaxhighlight lang="bash">ip addr show docker0</syntaxhighlight>
'''Expected output:'''

<pre>3: docker0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP
    link/ether 02:42:8f:a3:f1:2a brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0</pre>
This is '''exactly like <code>br-lab</code>''' from Lab 7:

* Bridge interface acting as virtual switch
* Assigned IP address 172.17.0.1
* Subnet 172.17.0.0/16 (65,536 addresses available)

'''2. veth Pairs'''

For each container, Docker creates a veth pair:

<syntaxhighlight lang="bash">ip link show | grep veth</syntaxhighlight>
'''Expected output:'''

<pre>8: veth7a3f2b1@if7: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 master docker0
10: veth9d4e8c2@if9: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 master docker0</pre>
'''Decoding this:'''

* <code>veth7a3f2b1@if7</code>: One end of veth pair, connected to bridge (<code>master docker0</code>)
* <code>@if7</code>: Paired with interface index 7 (inside container)

This is '''exactly what you did in Lab 7:'''

<syntaxhighlight lang="bash">sudo ip link add v-host type veth peer name v-client</syntaxhighlight>
Docker does the same thing, automatically.

'''3. Container Network Namespace'''

Each container has its own network namespace (you built these manually in Lab 7!):

<syntaxhighlight lang="bash"># View container's network interfaces
docker exec container ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; mtu 65536 qdisc noqueue state UNKNOWN
    inet 127.0.0.1/8 scope host lo

7: eth0@if8: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0</pre>
The container sees:

* <code>lo</code>: Its own loopback interface
* <code>eth0@if8</code>: Its end of the veth pair (paired with host's interface index 8)
* IP address from docker0 subnet

'''4. IP Address Assignment'''

Docker acts as a simple DHCP-like service, assigning IPs sequentially:

* First container: 172.17.0.2
* Second container: 172.17.0.3
* Third container: 172.17.0.4
* etc.

'''5. Routing in Container'''

Check the container's routing table:

<syntaxhighlight lang="bash">docker exec container ip route show</syntaxhighlight>
'''Expected output:'''

<pre>default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2</pre>
'''Translation:'''

* Default route: Send all traffic to 172.17.0.1 (the bridge) for routing to internet
* Local route: 172.17.0.0/16 is directly reachable via eth0

This is '''exactly the routing you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo ip netns exec red ip route add default via 10.0.0.1</syntaxhighlight>
'''6. NAT for Internet Access'''

Docker automatically configures iptables/nftables NAT rules (MASQUERADE) so containers can reach the internet:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep MASQUERADE</syntaxhighlight>
'''Expected output:'''

<pre>MASQUERADE  all  --  172.17.0.0/16  0.0.0.0/0</pre>
This is '''exactly the NAT you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE</syntaxhighlight>
'''7. Port Mapping (<code>-p</code> flag)'''

When you use <code>-p 8080:80</code>, Docker sets up Destination NAT (DNAT):

<syntaxhighlight lang="bash">docker run -d -p 8080:80 nginx</syntaxhighlight>
Docker adds an iptables DNAT rule:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep DNAT</syntaxhighlight>
'''Expected output:'''

<pre>DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:80</pre>
'''Translation:''' Traffic arriving at host port 8080 is redirected to 172.17.0.2:80

This is also NAT, specifically DNAT (Destination NAT). You encountered source NAT (SNAT/MASQUERADE) in Lab 7.

'''Container-to-Container Communication'''

Containers on the same bridge can communicate directly:

<syntaxhighlight lang="bash"># Container A pings Container B
docker exec containerA ping 172.17.0.3</syntaxhighlight>
The packet flow:

# Container A sends to 172.17.0.2 (Container B's IP)
# Packet goes out Container A's eth0 (through veth pair)
# Arrives on docker0 bridge
# Bridge forwards to veth pair for Container B
# Packet arrives at Container B's eth0

'''No routing through host networking needed'''—the bridge forwards directly (Layer 2 switching).

'''Custom Networks'''

You can create custom bridge networks:

<syntaxhighlight lang="bash">docker network create --subnet=10.20.0.0/24 mynet</syntaxhighlight>
Docker creates a new bridge interface (e.g., <code>br-abc123def456</code>) with subnet 10.20.0.0/24.

Containers on different networks are isolated:

<syntaxhighlight lang="bash">docker run -d --network=mynet --name=isolated nginx</syntaxhighlight>
This container is on <code>mynet</code>, not <code>docker0</code>, so it cannot communicate with containers on the default bridge (different Layer 2 segment).

'''DNS Resolution Between Containers'''

Docker provides automatic DNS resolution for container names within custom networks:

<syntaxhighlight lang="bash">docker network create mynet
docker run -d --network=mynet --name=web nginx
docker run -d --network=mynet --name=app alpine

# From app container
docker exec app ping web
# Resolves 'web' to web container's IP address!</syntaxhighlight>
Docker runs an embedded DNS server (listening on 127.0.0.11 inside containers) that resolves container names to IPs.

'''Network Modes:'''

Docker supports several network modes:

* '''bridge''' (default): Container on docker0 bridge (or custom bridge)
* '''host''': Container shares host's network namespace (no isolation)
* '''none''': No networking (container has only loopback)
* '''container:name''': Share another container's network namespace

'''Example: host mode'''

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
The container's network namespace inode is the same as the host's:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]'  # Same as host!</syntaxhighlight>
Container sees all host's network interfaces and can bind to any port on any interface.

'''Summary:'''

Docker networking uses:

* Bridges (like <code>br-lab</code> from Lab 7)
* veth pairs (like <code>v-host</code> ↔ <code>v-client</code> from Lab 7)
* Network namespaces (like <code>red</code> and <code>blue</code> from Lab 7)
* Routing tables and default routes
* NAT/MASQUERADE for internet access
* DNAT for port mapping

<span id="volumes-persistent-and-shared-storage"></span>
=== Volumes: Persistent and Shared Storage ===

By default, container filesystems are ephemeral—all changes are lost when the container is removed. For data that must persist (databases, user uploads, logs), Docker provides volumes.

'''The Problem:'''

<syntaxhighlight lang="bash"># Start database container
docker run -d --name db postgres

# Database writes data
docker exec db psql -c "CREATE DATABASE myapp;"

# Stop and remove container
docker rm -f db

# Data is GONE FOREVER!</syntaxhighlight>
This is unacceptable for stateful applications.

'''The Solution: Volumes'''

Volumes are directories on the host that are mounted into containers. Data written to volumes persists beyond container lifecycle.

'''Two Volume Types:'''

'''1. Named Volumes (Docker-managed):'''

Docker manages the volume storage location.

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# Use in container
docker run -v mydata:/data nginx

# Data written to /data inside container is stored in:
# /var/lib/docker/volumes/mydata/_data (on host)</syntaxhighlight>
'''Advantages:'''

* Docker manages storage location
* Portable across hosts (can be backed up, restored)
* Works with volume plugins (NFS, cloud storage)

'''Best practice:''' Use named volumes for production databases, critical data.

'''2. Bind Mounts (Host directory):'''

Mount a host directory directly into the container.

<syntaxhighlight lang="bash"># Mount host directory into container
docker run -v /home/user/html:/usr/share/nginx/html nginx</syntaxhighlight>
Any changes in <code>/home/user/html</code> on the host are immediately visible in <code>/usr/share/nginx/html</code> inside the container, and vice versa.

'''Advantages:'''

* Direct access to files from host
* Useful for development (edit code on host, see changes in container immediately)
* No Docker management needed

'''Disadvantages:'''

* Tied to specific host filesystem paths
* Less portable
* Permissions can be tricky (host UID vs. container UID)

<syntaxhighlight lang="bash"># Docker essentially does:
mount --bind /var/lib/docker/volumes/mydata/_data /data</syntaxhighlight>
'''Volume Sharing Between Containers:'''

Multiple containers can share the same volume:

<syntaxhighlight lang="bash"># Create volume
docker volume create shared

# Container 1 writes
docker run -v shared:/data --name writer alpine sh -c "echo 'Hello' > /data/file.txt"

# Container 2 reads
docker run -v shared:/data --name reader alpine cat /data/file.txt
# Output: Hello</syntaxhighlight>
'''Use cases:'''

* Shared configuration between containers
* Log aggregation (multiple containers write logs to shared volume)
* Data processing pipelines (one container produces, another consumes)

'''Volume Lifecycle:'''

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# List volumes
docker volume ls

# Inspect volume
docker volume inspect mydata

# Remove volume (only if no containers using it)
docker volume rm mydata

# Remove all unused volumes
docker volume prune</syntaxhighlight>
'''Inspecting Volume Mounts:'''

<syntaxhighlight lang="bash">docker inspect container --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Example output:'''

<syntaxhighlight lang="json">[
    {
        "Type": "volume",
        "Source": "/var/lib/docker/volumes/mydata/_data",
        "Destination": "/data",
        "Mode": "z",
        "RW": true
    }
]</syntaxhighlight>
'''Fields:'''

* <code>Type</code>: &quot;volume&quot; or &quot;bind&quot;
* <code>Source</code>: Host-side path
* <code>Destination</code>: Container-side path
* <code>RW</code>: Read-write (true) or read-only (false)

'''Read-Only Volumes:'''

For security, you can mount volumes read-only:

<syntaxhighlight lang="bash">docker run -v mydata:/data:ro nginx</syntaxhighlight>
Container can read <code>/data</code> but cannot write to it.

'''tmpfs Mounts (In-Memory Temporary Storage):'''

For sensitive data that should never touch disk:

<syntaxhighlight lang="bash">docker run --tmpfs /tmp:size=100m nginx</syntaxhighlight>
The <code>/tmp</code> directory is stored in RAM and disappears when the container stops.

'''Best Practices:'''

* '''Named volumes for databases''': Postgres, MySQL, MongoDB
* '''Bind mounts for development''': Code that you're actively editing
* '''tmpfs for secrets''': Temporary credentials, keys
* '''Volume plugins for cloud''': AWS EBS, Azure Disk, GCP Persistent Disk

<span id="laboratory-exercises"></span>
== Laboratory Exercises ==

The following exercises build progressively, demonstrating how Docker automates the kernel-level primitives you mastered in previous labs. You will install Docker, inspect namespace isolation, explore interactive containers, configure persistent storage, and build a multi-container application with networking and resource limits.

<span id="exercise-a-installing-docker"></span>
=== Exercise A: Installing Docker ===

'''Objective:''' Install Docker Engine from the official Docker repository and configure it for non-root access.

'''Why the official repository?''' Ubuntu's default repositories often contain outdated Docker versions. The official Docker repository provides the latest stable releases with security updates and new features.

'''Step 1: Remove old Docker versions (if any)'''

If you previously installed Docker from Ubuntu's repositories or older Docker installations exist, remove them to avoid conflicts:

<syntaxhighlight lang="bash">sudo apt remove docker docker-engine docker.io containerd runc</syntaxhighlight>
It's safe to run this even if these packages aren't installed—apt will simply report they're not present.

'''Step 2: Install prerequisites'''

Install packages needed for adding Docker's repository:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release</syntaxhighlight>
'''Step 3: Add Docker's GPG key'''

Docker signs its packages with a GPG key to ensure authenticity. Add this key to your system:

<syntaxhighlight lang="bash">sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg</syntaxhighlight>
'''What this does:'''

* Creates <code>/etc/apt/keyrings/</code> directory for storing repository keys
* Downloads Docker's GPG public key
* Converts it to binary format (<code>.gpg</code> file)
* Makes it readable by all users

'''Step 4: Add Docker repository to apt sources'''

<syntaxhighlight lang="bash">sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF</syntaxhighlight>
'''What this does:'''

* Detects your CPU architecture (amd64, arm64, etc.)
* Detects your Ubuntu version codename (focal, jammy, etc.)
* Adds Docker's repository to apt's source list

'''Step 5: Install Docker Engine'''

Update package index and install Docker:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
    docker-ce \
    docker-ce-cli \
    containerd.io \
    docker-buildx-plugin \
    docker-compose-plugin</syntaxhighlight>
'''Packages installed:'''

* <code>docker-ce</code>: Docker Community Edition engine (the main Docker daemon)
* <code>docker-ce-cli</code>: Docker command-line interface
* <code>containerd.io</code>: Container runtime that Docker uses under the hood
* <code>docker-buildx-plugin</code>: Extended build capabilities (multi-platform images)
* <code>docker-compose-plugin</code>: Docker Compose for multi-container applications

'''Step 6: Verify Docker installation'''

Check Docker version:

<syntaxhighlight lang="bash">sudo docker --version</syntaxhighlight>
'''Expected output:'''

<pre>Docker version 24.0.7, build afdd53b</pre>
Your version number may be different (newer), which is fine.

'''Step 7: Start and enable Docker service'''

Ensure Docker daemon starts on boot:

<syntaxhighlight lang="bash">sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
Check service status:

<syntaxhighlight lang="bash">sudo systemctl status docker</syntaxhighlight>
'''Expected output:'''

<pre>● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled)
     Active: active (running) since Thu 2024-12-12 10:30:00 UTC; 5min ago</pre>
Look for <code>Active: active (running)</code>.

'''Step 8: Configure non-root Docker access'''

By default, only root can run Docker commands. To run Docker without <code>sudo</code>, add your user to the <code>docker</code> group:

<syntaxhighlight lang="bash">sudo usermod -aG docker $USER</syntaxhighlight>
'''Important:''' Log out and log back in for this change to take effect. Alternatively, you can run:

<syntaxhighlight lang="bash">newgrp docker</syntaxhighlight>
This starts a new shell with updated group membership.

'''Step 9: Verify non-root access'''

Test that you can run Docker without sudo:

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
If this works without errors, you've successfully installed Docker!

'''Expected output:'''

<pre>Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:4bd78111b6914a99dbc560e6a20eab57ff6655aea4a80c50b0c5491968cbc2e6
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the &quot;hello-world&quot; image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/</pre>
'''What happened:'''

# Docker client (<code>docker</code> command) connected to Docker daemon (dockerd)
# Daemon checked local images—didn't find <code>hello-world</code>
# Daemon pulled <code>hello-world</code> image from Docker Hub (public registry)
# Daemon created container from image
# Container executed its program (printed the message)
# Container exited
# Output sent back to your terminal

'''Step 10: Clean up test container'''

List all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
You should see the hello-world container with status <code>Exited (0)</code>.

Remove it:

<syntaxhighlight lang="bash">docker rm $(docker ps -aq --filter "ancestor=hello-world")</syntaxhighlight>
Verify it's gone:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Deliverable A:'''

Provide screenshots showing:

# Output of <code>docker --version</code>
# Output of <code>sudo systemctl status docker</code> (showing Active: active (running))
# Output of <code>docker run hello-world</code> (the entire message)

<span id="exercise-b-hello-world-and-namespace-inspection"></span>
=== Exercise B: Hello World and Namespace Inspection ===

'''Objective:''' Run your first container, understand the container lifecycle, and inspect the Linux kernel namespaces that provide container isolation—connecting directly to your work in Lab 7.

<span id="part-1-hello-world"></span>
==== Part 1: Hello World ====

'''Step 1: Run the hello-world container (if not done in Exercise A)'''

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
We covered this in Exercise A, but let's examine what actually happened in more detail.

'''Step 2: List all containers'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:''' Nothing (empty list)

'''Why?''' The hello-world container ran, printed its message, and exited immediately. <code>docker ps</code> only shows running containers by default.

To see all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID   IMAGE         COMMAND    CREATED          STATUS                      PORTS     NAMES
a1b2c3d4e5f6   hello-world   &quot;/hello&quot;   10 seconds ago   Exited (0) 8 seconds ago              eager_tesla</pre>
'''Understanding the fields:'''

* '''CONTAINER ID''': Short hex identifier (first 12 chars of full 64-char ID)
* '''IMAGE''': Which image this container was created from
* '''COMMAND''': The process that ran inside the container (<code>/hello</code> executable)
* '''CREATED''': When the container was created
* '''STATUS''': Current state—<code>Exited (0)</code> means process exited with code 0 (success)
* '''PORTS''': Port mappings (none for hello-world)
* '''NAMES''': Random name if you don't specify one (Docker generates names like &quot;eager_tesla&quot;, &quot;hopeful_darwin&quot;)

'''Step 3: Inspect the container'''

Get detailed information about the container:

<syntaxhighlight lang="bash">docker inspect eager_tesla  # Use your actual container name</syntaxhighlight>
This outputs a large JSON document with all container metadata. Let's extract specific fields:

<syntaxhighlight lang="bash"># Just the State section
docker inspect eager_tesla --format='{{json .State}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output (formatted):'''

<syntaxhighlight lang="json">{
    "Status": "exited",
    "Running": false,
    "Paused": false,
    "Restarting": false,
    "OOMKilled": false,
    "Dead": false,
    "Pid": 0,
    "ExitCode": 0,
    "StartedAt": "2024-12-12T10:35:00Z",
    "FinishedAt": "2024-12-12T10:35:01Z"
}</syntaxhighlight>
'''Analysis:'''

* Container ran for about 1 second (started at :00, finished at :01)
* Exit code 0 (successful completion)
* PID is 0 (process has terminated; while running it had a real PID)

'''Step 4: View container logs'''

Even though the container exited, Docker saved its output:

<syntaxhighlight lang="bash">docker logs eager_tesla</syntaxhighlight>
Shows the hello-world message again. This demonstrates that Docker captures stdout/stderr from containers.

'''Step 5: Remove the container'''

Stopped containers still consume disk space (their writable layer persists). Remove it:

<syntaxhighlight lang="bash">docker rm eager_tesla</syntaxhighlight>
Verify removal:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
The container should be gone.

<span id="part-2-inspect-namespaces-connect-to-lab-7"></span>
==== Part 2: Inspect Namespaces (Connect to Lab 7!) ====

Now let's run a longer-lived container and examine its namespace isolation—this directly connects to your hands-on work with network namespaces in Lab 7.

'''Step 1: Run a persistent container'''

<syntaxhighlight lang="bash">docker run -d --name inspector nginx</syntaxhighlight>
'''Flags explained:'''

* <code>-d</code>: Detached mode—run in background
* <code>--name inspector</code>: Give it a memorable name instead of random name

'''Expected output:'''

<pre>Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Status: Downloaded newer image for nginx:latest
b7f9a8e6c4d3a1b2c5e8f9d2a7c4b6e8f3d9a2c1b4e7f8d3a5c2b1</pre>
The long hex string is the full 64-character container ID. Docker returns this after creating the container.

'''Step 2: Verify the container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID   IMAGE   COMMAND                  CREATED          STATUS          PORTS     NAMES
b7f9a8e6c4d3   nginx   &quot;/docker-entrypoint.…&quot;   10 seconds ago   Up 8 seconds    80/tcp    inspector</pre>
The container is running nginx web server.

'''Step 3: Get the container's PID on the host'''

Remember: containers are just processes. Let's find the PID:

<syntaxhighlight lang="bash">docker inspect inspector --format '{{.State.Pid}}'</syntaxhighlight>
'''Expected output:''' A number like <code>12345</code>

This is the process ID on the '''host''' system. Let's verify:

<syntaxhighlight lang="bash">ps aux | grep 12345</syntaxhighlight>
You should see nginx processes! The container is just a process with a fancy namespace wrapper.

'''Step 4: Examine the container's namespaces'''

This is the crucial step connecting to Lab 7. Replace 12345 with your actual PID:

<syntaxhighlight lang="bash">sudo ls -la /proc/12345/ns/</syntaxhighlight>
'''Expected output:'''

<pre>total 0
dr-x--x--x 2 root root 0 Dec 12 10:40 .
dr-xr-xr-x 9 root root 0 Dec 12 10:40 ..
lrwxrwxrwx 1 root root 0 Dec 12 10:40 cgroup -&gt; 'cgroup:[4026533671]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 ipc -&gt; 'ipc:[4026533669]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 mnt -&gt; 'mnt:[4026533667]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 net -&gt; 'net:[4026533672]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid -&gt; 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid_for_children -&gt; 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 user -&gt; 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 uts -&gt; 'uts:[4026533668]'</pre>
'''Analysis of namespace inodes:'''

Note the inode numbers (the numbers in brackets). Each represents a namespace instance.

'''Step 5: Compare with host's namespaces'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/net</syntaxhighlight>
'''Expected output:'''

<pre>lrwxrwxrwx 1 youruser youruser 0 Dec 12 10:40 net -&gt; 'net:[4026531992]'</pre>
'''Critical observation:''' The container's network namespace inode (<code>4026533672</code>) is '''different''' from the host's (<code>4026531992</code>).

'''Step 6: Compare two containers'''

Start a second container:

<syntaxhighlight lang="bash">docker run -d --name inspector2 nginx</syntaxhighlight>
Get its PID:

<syntaxhighlight lang="bash">docker inspect inspector2 --format '{{.State.Pid}}'</syntaxhighlight>
Check its network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/NEW_PID/ns/net</syntaxhighlight>
'''Expected:''' A different inode number from both the host and <code>inspector</code> container!

'''Conclusion:''' Each container has its own isolated network namespace, just like the red and blue namespaces you created manually in Lab 7.

'''Step 7: Examine other namespaces'''

Let's check PID namespace isolation:

<syntaxhighlight lang="bash"># Host PID namespace
sudo ls -la /proc/$$/ns/pid

# Container PID namespace  
sudo ls -la /proc/CONTAINER_PID/ns/pid</syntaxhighlight>
Different inodes = isolated process trees!

'''Step 8: User namespace (often shared)'''

<syntaxhighlight lang="bash"># Host user namespace
sudo ls -la /proc/$$/ns/user

# Container user namespace
sudo ls -la /proc/CONTAINER_PID/ns/user</syntaxhighlight>
'''Expected:''' Often the '''same''' inode number.

Many Docker configurations share the host's user namespace for simplicity. This means UID 0 in the container is UID 0 on the host (less secure, but more compatible).

For enhanced security, Docker can be configured to use separate user namespaces (rootless Docker), but that's beyond this lab's scope.

'''Step 9: Enter the container's namespace with nsenter'''

You can actually enter a container's namespaces using the <code>nsenter</code> command (this is how <code>docker exec</code> works!):

<syntaxhighlight lang="bash">sudo nsenter --target CONTAINER_PID --net ip addr show</syntaxhighlight>
This executes <code>ip addr show</code> inside the container's network namespace, showing the container's view of network interfaces.

'''Step 10: Clean up'''

<syntaxhighlight lang="bash">docker stop inspector inspector2
docker rm inspector inspector2</syntaxhighlight>
<span id="deliverable-b"></span>
=== Deliverable B ===

Provide screenshots showing:

# Output of <code>docker run hello-world</code> (the full hello message)
# Output of <code>docker ps -a</code> showing the exited hello-world container with its random name
# Output of <code>docker inspect inspector --format '{{.State.Pid}}'</code> (showing the PID)
# Output of <code>sudo ls -la /proc/PID/ns/</code> for the inspector container (showing all namespaces)
# Side-by-side comparison:
#* <code>sudo ls -la /proc/$$/ns/net</code> (host's network namespace inode)
#* <code>sudo ls -la /proc/CONTAINER_PID/ns/net</code> (container's network namespace inode)
#* Highlight that the inode numbers are different

<span id="exercise-c-interactive-exploration-with-fedora"></span>
=== Exercise C: Interactive Exploration with Fedora ===

'''Objective:''' Run an interactive container with a different Linux distribution (Fedora instead of Ubuntu), demonstrating mount namespace isolation (different root filesystems), PID namespace isolation (isolated process tree), and UTS namespace isolation (different hostname).

'''Important context:''' Your host might be running Ubuntu, but the container will run Fedora. Both will be using the same Linux kernel, but they'll have completely different filesystems and will appear as different &quot;machines&quot; from inside.

'''Step 1: Run Fedora container interactively'''

<syntaxhighlight lang="bash">docker run -it --name fedora-explore fedora bash</syntaxhighlight>
'''Flags explained:'''

* <code>-i</code>: Interactive—keep STDIN open
* <code>-t</code>: Allocate pseudo-TTY (terminal)
* <code>fedora</code>: Pull Fedora base image from Docker Hub
* <code>bash</code>: Command to run inside container (start bash shell)

'''What happens:'''

# Docker downloads Fedora base image (if not cached)
# Creates container from image
# Starts bash inside the container
# Attaches your terminal to that bash session

'''Expected output:'''

<pre>Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
...
Status: Downloaded newer image for fedora:latest
[root@a1b2c3d4e5f6 /]#</pre>
'''Observe the prompt change:'''

* Before: <code>user@hostname:~$</code> (your normal shell)
* After: <code>[root@a1b2c3d4e5f6 /]#</code> (inside container)

You're now '''inside''' the Fedora container!

'''Step 2: Explore the filesystem (Mount Namespace)'''

Check the operating system:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output:'''

<pre>NAME=&quot;Fedora Linux&quot;
VERSION=&quot;39 (Container Image)&quot;
ID=fedora
VERSION_ID=39
...</pre>
Open a '''new terminal''' on your host (don't close the container terminal) and run:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output on host:'''

<pre>NAME=&quot;Ubuntu&quot;
VERSION=&quot;22.04.3 LTS (Jammy Jellyfish)&quot;
ID=ubuntu
...</pre>
'''Two different operating systems on the same machine!''' This is mount namespace isolation—the container has its own root filesystem.

'''Back in the container''', explore the filesystem:

<syntaxhighlight lang="bash">ls /</syntaxhighlight>
'''Expected output:'''

<pre>bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var</pre>
These are Fedora's files, not your host's Ubuntu files. They're completely different directory trees.

'''Try to use Ubuntu's package manager:'''

<syntaxhighlight lang="bash">apt update</syntaxhighlight>
'''Expected output:'''

<pre>bash: apt: command not found</pre>
apt doesn't exist in Fedora! Fedora uses a different package manager.

'''Try Fedora's package manager:'''

<syntaxhighlight lang="bash">dnf --version</syntaxhighlight>
'''Expected output:'''

<pre>4.18.2
  Installed: dnf-0:4.18.2-1.fc39.noarch
  ...</pre>
dnf exists because we're in a Fedora environment.

'''Install a package:'''

<syntaxhighlight lang="bash">dnf install -y nano</syntaxhighlight>
This works! We can install packages just like on a real Fedora system.

'''Connection to Lab 2:'''

In Lab 2, you learned about the filesystem hierarchy (<code>/etc</code>, <code>/var</code>, <code>/usr</code>, etc.). Mount namespaces let the container have completely different contents at these paths. The container's <code>/etc</code> is different from the host's <code>/etc</code>.

'''Step 3: Examine process isolation (PID Namespace)'''

Inside the container, check running processes:

<syntaxhighlight lang="bash">ps aux</syntaxhighlight>
'''Expected output:'''

<pre>USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0  12345  2345 pts/0    Ss   10:45   0:00 bash
root          67  0.0  0.0  44567  3456 pts/0    R+   10:47   0:00 ps aux</pre>
'''Only two processes visible!'''

* PID 1: bash (the container's init process)
* PID 67: ps command we just ran

'''On the host''' (in your other terminal):

<syntaxhighlight lang="bash">ps aux | wc -l</syntaxhighlight>
'''Expected output:''' 200+ processes

'''The container cannot see the host's processes!''' This is PID namespace isolation.

'''From the container's perspective, bash is PID 1''' (like systemd is PID 1 on a normal Linux system).

'''From the host's perspective, that same bash process has a different PID''' (e.g., 12345).

'''Connection to Lab 3:'''

In Lab 3, you learned about PIDs and the process hierarchy. PID namespaces create separate process hierarchies—the container has its own process tree starting from PID 1.

'''Step 4: Check hostname (UTS Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>a1b2c3d4e5f6</pre>
This is the container ID (first 12 characters of the full container ID).

'''On the host:'''

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>your-hostname.example.com</pre>
Different hostnames! This is UTS namespace isolation.

'''Step 5: Examine network configuration (Network Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
       
17: eth0@if18: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever</pre>
'''Analysis:'''

* <code>lo</code>: Container's loopback interface (127.0.0.1)
* <code>eth0@if18</code>: Container's network interface (part of veth pair)
** <code>@if18</code>: Indicates this interface is paired with interface index 18 (on the host)
** IP address: 172.17.0.2 (from docker0 bridge subnet)

'''On the host:'''

<syntaxhighlight lang="bash">ip addr show | grep "172.17"</syntaxhighlight>
You should see the docker0 bridge has IP 172.17.0.1, and you might see veth interfaces for containers.

'''Connection to Lab 7:'''

This is '''exactly''' what you built manually!

* docker0 bridge ≈ br-lab from Lab 7
* Container's eth0 ≈ v-client from Lab 7
* veth pair connects container to bridge ≈ Lab 7's veth pair architecture

'''Step 6: Test internet connectivity from container'''

<syntaxhighlight lang="bash">ping -c 3 8.8.8.8</syntaxhighlight>
'''Expected:''' Ping succeeds!

This works because:

# Container has default route to 172.17.0.1 (docker0 bridge)
# Host has IP forwarding enabled
# Host has NAT rule (MASQUERADE) for 172.17.0.0/16

'''This is identical to what you configured in Lab 7!'''

'''Step 7: Try to see host's processes (will fail)'''

<syntaxhighlight lang="bash">ps aux | grep systemd</syntaxhighlight>
'''Expected:''' No systemd processes visible.

You cannot see the host's processes from inside the container (PID namespace isolation).

'''Step 8: Exit the container'''

<syntaxhighlight lang="bash">exit</syntaxhighlight>
When you exit bash (PID 1 in the container), the container stops automatically.

'''Verify the container stopped:'''

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID   IMAGE    COMMAND   CREATED         STATUS                     NAMES
a1b2c3d4e5f6   fedora   &quot;bash&quot;    5 minutes ago   Exited (0) 10 seconds ago  fedora-explore</pre>
'''Note:''' The container still exists (STATUS: Exited), but it's not running. You can restart it with <code>docker start fedora-explore</code> if needed.

'''Step 9: Clean up'''

<syntaxhighlight lang="bash">docker rm fedora-explore</syntaxhighlight>
<span id="deliverable-c"></span>
=== Deliverable C ===

Provide screenshots showing:

# '''Inside container''': Output of <code>cat /etc/os-release</code> (showing Fedora)
# '''On host''': Output of <code>cat /etc/os-release</code> (showing Ubuntu or your host OS)
# '''Inside container''': Output of <code>ps aux</code> (showing minimal processes, bash as PID 1)
# '''On host''': Output of <code>ps aux | wc -l</code> (showing many more processes)
# '''Inside container''': Output of <code>hostname</code> (showing container ID)
# '''On host''': Output of <code>hostname</code> (showing host's hostname)
# '''Inside container''': Output of <code>ip addr show</code> (showing eth0 with 172.17.0.x address)
# Brief explanation (4-5 sentences): What do these differences demonstrate about namespace isolation? How does this relate to what you learned in Labs 2, 3, and 7?

<span id="exercise-d-persistent-storage-with-caddy"></span>
=== Exercise D: Persistent Storage with Caddy ===

'''Objective:''' Run Caddy web server with persistent configuration and content using bind mounts, demonstrating that data can survive container removal and be shared between host and container.

Caddy is the web server you've been using throughout Lab 9. We'll run it in a container and configure it using files from the host.

<span id="part-1-basic-caddy-container"></span>
==== Part 1: Basic Caddy Container ====

'''Step 1: Create directory structure on host'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-caddy/{site,data,config}</syntaxhighlight>
'''Directory purposes:'''

* <code>site</code>: Website content (HTML files)
* <code>data</code>: Caddy's data directory (certificates, storage)
* <code>config</code>: Caddy configuration (Caddyfile)

'''Step 2: Create a simple website'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/site/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>Docker Caddy Demo</title>
</head>
<body>
    <h1>Hello from Dockerized Caddy!</h1>
    <div>
        <p><strong>This is running in a Docker container.</strong></p>
        <p>The file you're viewing is mounted from the host filesystem.</p>
        <p>Changes made on the host appear instantly in the container!</p>
    </div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 3: Create Caddyfile configuration'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/config/Caddyfile << 'EOF'
:80 {
    root * /usr/share/caddy
    file_server
    
    log {
        output stdout
        format console
    }
}
EOF</syntaxhighlight>
'''Caddyfile explanation:'''

* <code>:80</code>: Listen on port 80 (inside container)
* <code>root * /usr/share/caddy</code>: Serve files from this directory
* <code>file_server</code>: Enable static file serving
* <code>log</code>: Send access logs to stdout (so <code>docker logs</code> can capture them)

'''Step 4: Run Caddy container with volume mounts'''

<syntaxhighlight lang="bash">docker run -d \
  --name caddy-persistent \
  -p 8080:80 \
  -v ~/lab10-caddy/site:/usr/share/caddy \
  -v ~/lab10-caddy/data:/data \
  -v ~/lab10-caddy/config:/etc/caddy \
  caddy</syntaxhighlight>
'''Breaking down the command:'''

* <code>-d</code>: Detached mode (run in background)
* <code>--name caddy-persistent</code>: Give container a memorable name
* <code>-p 8080:80</code>: Port mapping
** Host port 8080 → Container port 80
** This is NAT (DNAT specifically) from Lab 7!
* <code>-v ~/lab10-caddy/site:/usr/share/caddy</code>: Bind mount
** Host directory <code>~/lab10-caddy/site</code> appears at <code>/usr/share/caddy</code> inside container
** Bidirectional: changes on either side are visible on both sides
* <code>-v ~/lab10-caddy/data:/data</code>: Caddy's data storage
* <code>-v ~/lab10-caddy/config:/etc/caddy</code>: Caddy's configuration
* <code>caddy</code>: Image to use

'''Expected output:'''

<pre>Unable to find image 'caddy:latest' locally
latest: Pulling from library/caddy
...
Status: Downloaded newer image for caddy:latest
f8e9c7b6d5a4e3b2c1f7d8a9e6b5c4d3a2f1e8d7c6b5a4e3d2c1b9f8</pre>
'''Step 5: Verify container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID   IMAGE   COMMAND        CREATED          STATUS          PORTS                  NAMES
f8e9c7b6d5a4   caddy   &quot;caddy run...&quot; 10 seconds ago   Up 8 seconds    0.0.0.0:8080-&gt;80/tcp   caddy-persistent</pre>
'''Note the PORTS column:''' <code>0.0.0.0:8080-&gt;80/tcp</code>

This means:

* Listen on all host interfaces (<code>0.0.0.0</code>)
* Host port 8080 maps to container port 80
* Protocol: TCP

'''Step 6: Test the web server'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected output:''' Your HTML page!

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
<head>
    <title>Docker Caddy Demo</title>
...
    <h1>Hello from Dockerized Caddy!</h1>
...
</html></syntaxhighlight>
You can also open <code>http://localhost:8080</code> in a web browser on your host.

'''Step 7: View Caddy logs'''

<syntaxhighlight lang="bash">docker logs caddy-persistent</syntaxhighlight>
'''Expected output:'''

<pre>{&quot;level&quot;:&quot;info&quot;,&quot;ts&quot;:1702389123.456,&quot;msg&quot;:&quot;using provided configuration&quot;,...}
{&quot;level&quot;:&quot;info&quot;,&quot;ts&quot;:1702389123.789,&quot;msg&quot;:&quot;serving initial configuration&quot;}
...</pre>
These are Caddy's startup logs. When you access the website, you'll see access logs here too.

<span id="part-2-inspect-mounts"></span>
==== Part 2: Inspect Mounts ====

'''Step 8: Inspect the container's mounts'''

<syntaxhighlight lang="bash">docker inspect caddy-persistent --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">[
    {
        "Type": "bind",
        "Source": "/home/youruser/lab10-caddy/site",
        "Destination": "/usr/share/caddy",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
    },
    {
        "Type": "bind",
        "Source": "/home/youruser/lab10-caddy/data",
        "Destination": "/data",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
    },
    {
        "Type": "bind",
        "Source": "/home/youruser/lab10-caddy/config",
        "Destination": "/etc/caddy",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
    }
]</syntaxhighlight>
'''Field explanations:'''

* <code>Type</code>: &quot;bind&quot; (bind mount, not Docker-managed volume)
* <code>Source</code>: Host filesystem path
* <code>Destination</code>: Path inside container
* <code>RW</code>: true (read-write), false would be read-only
* <code>Propagation</code>: How mount events propagate (rprivate = don't propagate to other mounts)

'''Step 9: View from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent df -h | grep caddy</syntaxhighlight>
Shows mounted filesystems inside the container containing &quot;caddy&quot; in the path.

You can also list the files:

<syntaxhighlight lang="bash">docker exec caddy-persistent ls -la /usr/share/caddy</syntaxhighlight>
'''Expected output:'''

<pre>total 12
drwxr-xr-x 2 root root 4096 Dec 12 10:50 .
drwxr-xr-x 1 root root 4096 Dec 12 10:50 ..
-rw-r--r-- 1 root root  687 Dec 12 10:50 index.html</pre>
This is the same <code>index.html</code> you created on the host!

<span id="part-3-test-persistence"></span>
==== Part 3: Test Persistence ====

'''Step 10: Modify the file on the host'''

'''Without stopping the container''', edit the HTML file:

<syntaxhighlight lang="bash">cat >> ~/lab10-caddy/site/index.html << 'EOF'
    <div class="info">
        <p><strong>🎉 This was added from the host!</strong></p>
        <p>The container is still running, and changes appear instantly.</p>
    </div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 11: Verify the change appears in the container immediately'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' The new section appears!

You didn't restart the container, yet the content changed. This demonstrates '''bidirectional bind mount synchronization'''.

'''Step 12: Create a new file from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent bash -c "echo '<h2>Created from container</h2>' > /usr/share/caddy/test.html"</syntaxhighlight>
'''Step 13: Verify the file appears on the host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected output:'''

<pre>total 16
drwxr-xr-x 2 youruser youruser 4096 Dec 12 11:00 .
drwxr-xr-x 5 youruser youruser 4096 Dec 12 10:45 ..
-rw-r--r-- 1 youruser youruser  687 Dec 12 10:50 index.html
-rw-r--r-- 1 root     root       34 Dec 12 11:00 test.html  ← New file!</pre>
The file exists on the host! Changes flow both directions.

'''Note:''' The file is owned by <code>root</code> because the process inside the container runs as root. This is one of the complexities of bind mounts—UID/GID mapping between host and container.

'''Step 14: Stop and remove the container'''

<syntaxhighlight lang="bash">docker stop caddy-persistent
docker rm caddy-persistent</syntaxhighlight>
'''Step 15: Verify files still exist on host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected:''' All files still there!

The files survive because they're stored on the host filesystem, not in the container's ephemeral writable layer.

'''Step 16: Start a NEW container with the same bind mounts'''

<syntaxhighlight lang="bash">docker run -d \
  --name caddy-new \
  -p 8080:80 \
  -v ~/lab10-caddy/site:/usr/share/caddy \
  -v ~/lab10-caddy/data:/data \
  -v ~/lab10-caddy/config:/etc/caddy \
  caddy</syntaxhighlight>
'''Step 17: Verify persistence'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' All your previous content is still there!

The website works immediately because all the content and configuration was stored on the host, not inside the old container.

'''Step 18: Compare to ephemeral storage'''

Let's demonstrate what happens without volumes:

<syntaxhighlight lang="bash"># Start container without volumes
docker run -d --name caddy-temp caddy

# Create file inside container
docker exec caddy-temp bash -c "echo 'temporary' > /tmp/temp.txt"

# Verify file exists
docker exec caddy-temp cat /tmp/temp.txt
# Output: temporary

# Stop and remove container
docker stop caddy-temp
docker rm caddy-temp

# Try to access the file in a new container
docker run -d --name caddy-temp2 caddy
docker exec caddy-temp2 cat /tmp/temp.txt
# Output: cat: /tmp/temp.txt: No such file or directory

# The file is GONE because it was in the ephemeral layer</syntaxhighlight>
'''Step 19: Clean up'''

<syntaxhighlight lang="bash">docker stop caddy-new
docker rm caddy-new</syntaxhighlight>
The files in <code>~/lab10-caddy/</code> remain intact on your host.

<syntaxhighlight lang="bash"># What Docker essentially does:
mount --bind ~/lab10-caddy/site /var/lib/docker/overlay2/.../merged/usr/share/caddy</syntaxhighlight>
<span id="deliverable-d"></span>
=== Deliverable D ===

Provide screenshots showing:

# Output of <code>curl http://localhost:8080</code> showing your custom HTML (initial version)
# Output of <code>docker inspect caddy-persistent --format='{{json .Mounts}}'</code> (formatted with python3 -m json.tool)
# After modifying <code>index.html</code> on the host, output of <code>curl http://localhost:8080</code> showing the new content (without restarting container)
# Output of <code>ls -la ~/lab10-caddy/site/</code> showing both <code>index.html</code> and the <code>test.html</code> created from inside the container
# After removing the original container and starting <code>caddy-new</code>, output of <code>curl http://localhost:8080</code> demonstrating that content persisted

<span id="exercise-e-multi-container-infrastructure-with-networking-and-resource-limits"></span>
=== Exercise E: Multi-Container Infrastructure with Networking and Resource Limits ===

'''Objective:''' Build a complete three-tier architecture with:

* '''Purple''' container acting as reverse proxy (routes requests based on URL path)
* '''Red''' container serving backend content (memory-limited)
* '''Blue''' container serving backend content (CPU-limited)

This exercise synthesizes everything from Labs 7-9:

* Custom networks (Lab 7 bridges)
* Container-to-container communication (Lab 7 veth pairs and routing)
* Reverse proxy with path-based routing (Lab 9 Caddy configuration)
* Resource limits (cgroups)

<span id="part-1-create-a-custom-network"></span>
==== Part 1: Create a Custom Network ====

'''Step 1: Create a custom bridge network'''

<syntaxhighlight lang="bash">docker network create --subnet=10.10.0.0/24 labnet</syntaxhighlight>
This creates a new bridge (just like <code>br-lab</code> from Lab 7) with subnet 10.10.0.0/24.

'''Expected output:'''

<pre>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2</pre>
This is the network ID.

'''Step 2: Inspect the network'''

<syntaxhighlight lang="bash">docker network inspect labnet</syntaxhighlight>
'''Expected output (abbreviated):'''

<syntaxhighlight lang="json">[
    {
        "Name": "labnet",
        "Id": "a1b2c3d4e5f6...",
        "Driver": "bridge",
        "IPAM": {
            "Config": [
                {
                    "Subnet": "10.10.0.0/24",
                    "Gateway": "10.10.0.1"
                }
            ]
        },
        "Containers": {},
        ...
    }
]</syntaxhighlight>
'''Key observations:'''

* <code>Driver: &quot;bridge&quot;</code>: Uses bridge networking (Layer 2 switching)
* <code>Subnet: &quot;10.10.0.0/24&quot;</code>: Our specified subnet
* <code>Gateway: &quot;10.10.0.1&quot;</code>: Docker automatically assigns .1 as gateway
* <code>Containers: {}</code>: No containers connected yet

'''Step 3: Verify bridge creation on host'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
'''Expected output:'''

<pre>5: br-a1b2c3d4e5f6: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP mode DEFAULT group default</pre>
Docker created a new bridge interface! The name includes the network ID prefix.

You can also use:

<syntaxhighlight lang="bash">brctl show</syntaxhighlight>
'''Expected output:'''

<pre>bridge name          bridge id          STP enabled    interfaces
br-a1b2c3d4e5f6      8000.0242a1b2c3d4  no
docker0              8000.0242f7a8b9c0  no</pre>
Two bridges:

* <code>docker0</code>: Default Docker bridge
* <code>br-a1b2c3d4e5f6</code>: Our custom labnet bridge

'''Connection to Lab 7:'''

This is '''exactly''' what you did with:

<syntaxhighlight lang="bash">sudo ip link add br-lab type bridge
sudo ip link set br-lab up
sudo ip addr add 10.0.0.1/24 dev br-lab</syntaxhighlight>
'''Docker automated it!'''

<span id="part-2-create-backend-services-red-and-blue"></span>
==== Part 2: Create Backend Services (Red and Blue) ====

'''Step 4: Create content directories'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-multicontainer/{red,blue,purple}</syntaxhighlight>
'''Step 5: Create Red service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>Red Service</title>
</head>
<body>
    <div>
        <p><strong>Container:</strong> Red</p>
        <p><strong>IP:</strong> 10.10.0.2</p>
        <p><strong>Resource Limit:</strong> Memory capped at 256MB</p>
        <p>This backend is memory-constrained by cgroups.</p>
    </div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 6: Create Red Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/Caddyfile << 'EOF'
:80 {
    root * /usr/share/caddy
    file_server
    
    log {
        output stdout
        format console
    }
}
EOF</syntaxhighlight>
'''Step 7: Create Blue service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>Blue Service</title>
</head>
<body>
    <h1>Blue Service</h1>
    <div class="info">
        <p><strong>Container:</strong> Blue</p>
        <p><strong>IP:</strong> 10.10.0.3</p>
        <p><strong>Resource Limit:</strong> CPU capped at 0.5 cores</p>
        <p>This backend is CPU-constrained by cgroups.</p>
    </div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 8: Create Blue Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/Caddyfile << 'EOF'
:80 {
    root * /usr/share/caddy
    file_server
    
    log {
        output stdout
        format console
    }
}
EOF</syntaxhighlight>
'''Step 9: Start Red container with memory limit'''

<syntaxhighlight lang="bash">docker run -d \
  --name red \
  --network labnet \
  --ip 10.10.0.2 \
  --memory=256m \
  --memory-swap=256m \
  -v ~/lab10-multicontainer/red:/etc/caddy \
  -v ~/lab10-multicontainer/red:/usr/share/caddy \
  caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--network labnet</code>: Connect to our custom network (not default docker0)
* <code>--ip 10.10.0.2</code>: Assign static IP address (just like <code>ip addr add</code> in Lab 7!)
* <code>--memory=256m</code>: cgroup memory limit (hard cap: 256MB RAM)
* <code>--memory-swap=256m</code>: Total memory+swap limit (setting equal to memory means no swap)
** If swap was 512m, container could use 256MB RAM + 256MB swap
* <code>-v ~/lab10-multicontainer/red:/etc/caddy</code>: Mount Caddyfile
* <code>-v ~/lab10-multicontainer/red:/usr/share/caddy</code>: Mount website content

'''Expected output:''' Container ID

'''Step 10: Verify Red is running'''

<syntaxhighlight lang="bash">docker ps --filter "name=red"</syntaxhighlight>
'''Step 11: Test Red directly'''

Since Red has IP 10.10.0.2, let's verify we can reach it:

<syntaxhighlight lang="bash"># From host (won't work directly because we're not in labnet)
# But we can use docker exec from another container

# Quick test: use docker exec to reach Red from Red itself
docker exec red curl -s http://localhost | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre>    &lt;h1&gt;Red Service&lt;/h1&gt;</pre>
'''Step 12: Start Blue container with CPU limit'''

<syntaxhighlight lang="bash">docker run -d \
  --name blue \
  --network labnet \
  --ip 10.10.0.3 \
  --cpus=0.5 \
  -v ~/lab10-multicontainer/blue:/etc/caddy \
  -v ~/lab10-multicontainer/blue:/usr/share/caddy \
  caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--cpus=0.5</code>: cgroup CPU limit (maximum 50% of one CPU core)
** If CPU-intensive work is attempted, kernel will throttle it
* Other flags same as Red

'''Step 13: Verify both containers are running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID   IMAGE   COMMAND        CREATED          STATUS          PORTS   NAMES
a1b2c3d4e5f6   caddy   &quot;caddy run...&quot; 20 seconds ago   Up 18 seconds   80/tcp  red
b7c8d9e0f1a2   caddy   &quot;caddy run...&quot; 10 seconds ago   Up 8 seconds    80/tcp  blue</pre>
'''Step 14: Test container-to-container communication'''

<syntaxhighlight lang="bash"># From Red, ping Blue
docker exec red ping -c 2 10.10.0.3</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># From Red, curl Blue's website
docker exec red curl -s http://10.10.0.3 | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre>    &lt;h1&gt;Blue Service&lt;/h1&gt;</pre>
Containers on the same custom network can communicate directly.

<span id="part-3-create-reverse-proxy-purple"></span>
==== Part 3: Create Reverse Proxy (Purple) ====

'''Step 15: Create Purple's Caddyfile'''

This is the crucial piece—routing based on URL path (from Lab 9!)

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/purple/Caddyfile << 'EOF'
:80 {
    # Health check endpoint
    handle /health {
        respond "Purple Reverse Proxy - OK" 200
    }

    # Root path
    handle / {
        respond "Purple Reverse Proxy - Use /red/ or /blue/ paths" 200
    }

    # Route /red/* to red container (strip /red prefix)
    handle_path /red/* {
        reverse_proxy red:80
    }

    # Route /blue/* to blue container (strip /blue prefix)
    handle_path /blue/* {
        reverse_proxy blue:80
    }

    # Logging
    log {
        output stdout
        format console
    }
}
EOF</syntaxhighlight>
'''Key points:'''

* <code>handle_path /red/*</code>: Matches any path starting with <code>/red/</code>
** <code>handle_path</code> strips the prefix before forwarding
** Client requests <code>/red/index.html</code> → Backend receives <code>/index.html</code>
* <code>reverse_proxy red:80</code>: Forward to container named &quot;red&quot; on port 80
** '''Using hostname &quot;red&quot;, not IP!'''
** Docker's embedded DNS resolves &quot;red&quot; to 10.10.0.2
* Same for blue

'''Step 16: Start Purple reverse proxy'''

<syntaxhighlight lang="bash">docker run -d \
  --name purple \
  --network labnet \
  --ip 10.10.0.10 \
  -p 8080:80 \
  -v ~/lab10-multicontainer/purple:/etc/caddy \
  caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--ip 10.10.0.10</code>: Purple gets IP 10.10.0.10 (different from Red/Blue)
* <code>-p 8080:80</code>: '''Port mapping''' (host port 8080 → container port 80)
** This is NAT (DNAT) from Lab 7!
** Traffic to <code>localhost:8080</code> on host gets forwarded to <code>10.10.0.10:80</code> in container

<span id="part-4-testing-the-infrastructure"></span>
==== Part 4: Testing the Infrastructure ====

'''Step 17: Test health check'''

<syntaxhighlight lang="bash">curl http://localhost:8080/health</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - OK</pre>
This request:

# Reaches host's port 8080
# Docker's DNAT rule forwards to Purple (10.10.0.10:80)
# Purple's Caddy responds directly (no backend needed for /health)

'''Step 18: Test root path'''

<syntaxhighlight lang="bash">curl http://localhost:8080/</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - Use /red/ or /blue/ paths</pre>
'''Step 19: Test routing to Red'''

<syntaxhighlight lang="bash">curl http://localhost:8080/red/</syntaxhighlight>
'''Expected output:''' Red service HTML (with red background styling)

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
...
    <h1>Red Service</h1>
    <div>
        <p><strong>Container:</strong> Red</p>
        <p><strong>IP:</strong> 10.10.0.2</p>
...</syntaxhighlight>
'''What happened:'''

# Your curl → Host port 8080
# DNAT → Purple (10.10.0.10:80)
# Purple sees path <code>/red/</code>, strips <code>/red</code>, forwards <code>/</code> to <code>red:80</code>
# Purple's DNS resolves <code>red</code> to 10.10.0.2
# Request goes to Red (10.10.0.2:80)
# Red's Caddy serves <code>index.html</code>
# Response travels back through Purple to your curl

'''Step 20: Test routing to Blue'''

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/</syntaxhighlight>
'''Expected output:''' Blue service HTML (with blue background styling)

'''Step 21: Test with verbose output to see headers'''

<syntaxhighlight lang="bash">curl -v http://localhost:8080/red/ 2>&1 | grep -A10 "< HTTP"</syntaxhighlight>
'''Expected output:'''

<pre>&lt; HTTP/1.1 200 OK
&lt; Content-Type: text/html; charset=utf-8
&lt; Server: Caddy
&lt; Date: Thu, 12 Dec 2024 11:30:00 GMT
&lt; Content-Length: 687</pre>
'''Observe:''' <code>Server: Caddy</code> header (from Purple, acting as proxy)

'''Step 22: Test in browser'''

Open in your web browser:

* <code>http://localhost:8080/red/</code> → Should see red-styled page
* <code>http://localhost:8080/blue/</code> → Should see blue-styled page

<span id="part-5-inspect-resource-limits"></span>
==== Part 5: Inspect Resource Limits ====

'''Step 23: Check Red's memory limit'''

<syntaxhighlight lang="bash">docker inspect red --format='{{.HostConfig.Memory}}'</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
This is 256 MB in bytes (256 × 1024 × 1024 = 268435456).

'''Step 24: Check Blue's CPU limit'''

<syntaxhighlight lang="bash">docker inspect blue --format='{{.HostConfig.NanoCpus}}'</syntaxhighlight>
'''Expected output:'''

<pre>500000000</pre>
This is 0.5 CPU cores in nanocpus (0.5 × 10^9 = 500,000,000).

'''Step 25: View cgroup settings from the host'''

Get Red's main process PID:

<syntaxhighlight lang="bash">RED_PID=$(docker inspect red --format '{{.State.Pid}}')
echo "Red's PID: $RED_PID"</syntaxhighlight>
View memory limit in cgroup filesystem:

<syntaxhighlight lang="bash">cat /sys/fs/cgroup/memory/docker/$RED_PID/memory.limit_in_bytes</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
View Blue's CPU quota:

<syntaxhighlight lang="bash">BLUE_PID=$(docker inspect blue --format '{{.State.Pid}}')
cat /sys/fs/cgroup/cpu/docker/$BLUE_PID/cpu.cfs_quota_us</syntaxhighlight>
'''Expected output:'''

<pre>50000</pre>
'''Explanation:'''

* <code>cpu.cfs_period_us</code>: 100000 (default, 100ms period)
* <code>cpu.cfs_quota_us</code>: 50000 (50ms out of 100ms = 50% = 0.5 CPUs)

'''Connection to kernel concepts:'''

These cgroup files in <code>/sys/fs/cgroup/</code> are how the kernel enforces resource limits. Docker configures these files, and the kernel does the actual enforcement.

<span id="part-6-network-inspection"></span>
==== Part 6: Network Inspection ====

'''Step 26: Inspect labnet network showing all containers'''

<syntaxhighlight lang="bash">docker network inspect labnet --format='{{json .Containers}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">{
    "a1b2c3d4e5f6...": {
        "Name": "red",
        "EndpointID": "...",
        "MacAddress": "02:42:0a:0a:00:02",
        "IPv4Address": "10.10.0.2/24",
        "IPv6Address": ""
    },
    "b7c8d9e0f1a2...": {
        "Name": "blue",
        "EndpointID": "...",
        "MacAddress": "02:42:0a:0a:00:03",
        "IPv4Address": "10.10.0.3/24",
        "IPv6Address": ""
    },
    "f8e9c7b6d5a4...": {
        "Name": "purple",
        "EndpointID": "...",
        "MacAddress": "02:42:0a:0a:00:0a",
        "IPv4Address": "10.10.0.10/24",
        "IPv6Address": ""
    }
}</syntaxhighlight>
All three containers are on the labnet network with their assigned IPs.

'''Step 27: Test DNS resolution between containers'''

<syntaxhighlight lang="bash"># From Purple, resolve "red" hostname
docker exec purple nslookup red</syntaxhighlight>
'''Expected output:'''

<pre>Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   red
Address: 10.10.0.2</pre>
'''Explanation:'''

* <code>127.0.0.11</code>: Docker's embedded DNS server (listening inside each container)
* DNS resolves container name &quot;red&quot; to IP 10.10.0.2

'''Step 28: Test connectivity using hostnames'''

<syntaxhighlight lang="bash"># Purple pings Red by hostname
docker exec purple ping -c 2 red</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># Purple curls Blue by hostname
docker exec purple curl -s http://blue | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre>    &lt;h1&gt;Blue Service&lt;/h1&gt;</pre>
<span id="part-7-architecture-visualization"></span>
==== Part 7: Architecture Visualization ====

'''The architecture you built:'''

<pre>                    ┌─────────────────┐
                    │   Your Host     │
                    │  (Port 8080)    │
                    └────────┬────────┘
                             │
                     Port Mapping (NAT)
                      8080 → 80
                             │
                    ┌────────▼────────┐
                    │  Purple Proxy   │
                    │  10.10.0.10:80  │
                    │  (Caddy)        │
                    └────────┬────────┘
                             │
                   Docker Network: labnet
                   (Bridge: br-a1b2c3d4e5f6)
                    10.10.0.0/24
                             │
                   ┌─────────┴──────────┐
                   │                    │
          ┌────────▼────────┐  ┌───────▼─────────┐
          │   Red Service   │  │  Blue Service   │
          │   10.10.0.2:80  │  │  10.10.0.3:80   │
          │   (Caddy)       │  │  (Caddy)        │
          │  [mem: 256MB]   │  │  [cpu: 0.5]     │
          └─────────────────┘  └─────────────────┘</pre>
'''Request flow for <code>curl http://localhost:8080/red/</code>:'''

<pre>1. Curl → localhost:8080 (your host)
2. Host's iptables DNAT rule → 10.10.0.10:80 (Purple)
3. Purple receives request to /red/
4. Purple's Caddy config: handle_path /red/* → reverse_proxy red:80
5. Purple strips /red prefix → request becomes /
6. Purple's DNS resolves &quot;red&quot; → 10.10.0.2
7. Purple → Red (10.10.0.2:80) GET /
8. Red's Caddy serves /usr/share/caddy/index.html
9. Response: Red → Purple → Host → Curl</pre>
'''Compare to Lab 7 and Lab 9:'''

* '''Lab 7''': You manually created bridges, veth pairs, assigned IPs, configured routes, set up NAT
* '''Lab 9''': You manually configured Caddy reverse proxy with path-based routing
* '''This exercise''': Docker automated all the networking, you just specified what you wanted

<span id="part-8-cleanup"></span>
==== Part 8: Cleanup ====

'''Step 29: Stop all containers'''

<syntaxhighlight lang="bash">docker stop purple red blue</syntaxhighlight>
'''Step 30: Remove containers'''

<syntaxhighlight lang="bash">docker rm purple red blue</syntaxhighlight>
'''Step 31: Remove the network'''

<syntaxhighlight lang="bash">docker network rm labnet</syntaxhighlight>
'''Step 32: Verify cleanup'''

<syntaxhighlight lang="bash">docker ps -a
docker network ls</syntaxhighlight>
Only default networks (bridge, host, none) should remain.

'''Step 33: Verify host bridge removed'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
The custom bridge (br-a1b2c3d4e5f6) should be gone. Only docker0 remains.

<span id="deliverable-e"></span>
=== Deliverable E ===

Provide screenshots showing:

# Output of <code>docker network inspect labnet</code> showing all three containers with their IPs (before running curl tests)
# Output of <code>curl http://localhost:8080/health</code> (health check response)
# Output of <code>curl http://localhost:8080/red/</code> (Red service HTML) with visible red-styled content
# Output of <code>curl http://localhost:8080/blue/</code> (Blue service HTML) with visible blue-styled content
# Output of <code>docker inspect red --format='{{.HostConfig.Memory}}'</code> showing memory limit in bytes
# Output of <code>docker inspect blue --format='{{.HostConfig.NanoCpus}}'</code> showing CPU limit in nanocpus
# Output of <code>docker exec purple nslookup red</code> showing DNS resolution

<span id="reference-docker-command-quick-guide"></span>
== Reference: Docker Command Quick Guide ==

This section provides a quick reference for Docker commands introduced in this lab.

<span id="container-lifecycle"></span>
=== Container Lifecycle ===

<syntaxhighlight lang="bash"># Run container (create + start)
docker run [OPTIONS] IMAGE [COMMAND]
docker run -d nginx                          # Detached (background)
docker run -it ubuntu bash                   # Interactive with terminal
docker run --name mycontainer nginx          # Assign name

# List containers
docker ps                                    # Running only
docker ps -a                                 # All (including stopped)
docker ps -q                                 # Show only IDs (quiet)

# Start stopped container
docker start CONTAINER

# Stop running container
docker stop CONTAINER                        # Graceful (SIGTERM)
docker kill CONTAINER                        # Forceful (SIGKILL)

# Restart container
docker restart CONTAINER

# Remove container
docker rm CONTAINER                          # Must be stopped first
docker rm -f CONTAINER                       # Force remove (stop + remove)

# Execute command in running container
docker exec CONTAINER COMMAND
docker exec -it CONTAINER bash               # Interactive shell

# View container logs
docker logs CONTAINER
docker logs -f CONTAINER                     # Follow (tail -f style)

# Inspect container (detailed JSON info)
docker inspect CONTAINER
docker inspect CONTAINER --format='{{.State.Status}}'</syntaxhighlight>
<span id="image-management"></span>
=== Image Management ===

<syntaxhighlight lang="bash"># List images
docker images
docker image ls

# Pull image from registry
docker pull IMAGE[:TAG]
docker pull nginx                            # Latest tag (default)
docker pull nginx:1.21                       # Specific tag

# Remove image
docker rmi IMAGE
docker image rm IMAGE

# View image layers
docker history IMAGE

# Remove unused images
docker image prune                           # Dangling images
docker image prune -a                        # All unused images</syntaxhighlight>
<span id="network-management"></span>
=== Network Management ===

<syntaxhighlight lang="bash"># List networks
docker network ls

# Create network
docker network create NETWORK
docker network create --subnet=10.20.0.0/24 mynet

# Inspect network
docker network inspect NETWORK

# Connect container to network
docker network connect NETWORK CONTAINER

# Disconnect container from network
docker network disconnect NETWORK CONTAINER

# Remove network
docker network rm NETWORK

# Remove unused networks
docker network prune</syntaxhighlight>
<span id="volume-management"></span>
=== Volume Management ===

<syntaxhighlight lang="bash"># List volumes
docker volume ls

# Create volume
docker volume create VOLUME

# Inspect volume
docker volume inspect VOLUME

# Remove volume
docker volume rm VOLUME

# Remove unused volumes
docker volume prune</syntaxhighlight>
<span id="resource-management"></span>
=== Resource Management ===

<syntaxhighlight lang="bash"># CPU limits
--cpus=1.5                                   # Limit to 1.5 CPU cores
--cpu-shares=512                             # Relative priority (default 1024)
--cpuset-cpus=0,1                            # Pin to specific cores

# Memory limits
--memory=512m                                # Hard limit: 512 MB RAM
--memory=2g                                  # Hard limit: 2 GB RAM
--memory-swap=1g                             # Total memory+swap
--memory-reservation=256m                    # Soft limit

# I/O limits
--device-read-bps=/dev/sda:10mb             # Limit read bandwidth
--device-write-bps=/dev/sda:10mb            # Limit write bandwidth

# Process limits
--pids-limit=100                             # Max 100 processes</syntaxhighlight>
<span id="inspection-and-debugging"></span>
=== Inspection and Debugging ===

<syntaxhighlight lang="bash"># View resource usage stats
docker stats
docker stats CONTAINER                       # Specific container

# View processes in container
docker top CONTAINER

# View port mappings
docker port CONTAINER

# Copy files between host and container
docker cp CONTAINER:/path/to/file ./file    # Container → Host
docker cp ./file CONTAINER:/path/to/file    # Host → Container

# Stream events from Docker daemon
docker events

# Show disk usage
docker system df

# System-wide cleanup
docker system prune                          # Remove unused objects
docker system prune -a                       # Remove all unused objects
docker system prune -a --volumes            # Include volumes</syntaxhighlight>
<span id="common-troubleshooting"></span>
== Common Troubleshooting ==

<span id="installation-issues"></span>
=== Installation Issues ===

'''Problem:''' <code>docker --version</code> fails after installation

'''Solution:'''

<syntaxhighlight lang="bash"># Check if Docker daemon is running
sudo systemctl status docker

# If not running, start it
sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
'''Problem:''' &quot;Cannot connect to the Docker daemon&quot;

'''Cause:''' Docker daemon not running or permission issue

'''Solution:'''

<syntaxhighlight lang="bash"># Check daemon status
sudo systemctl status docker

# Check if your user is in docker group
groups | grep docker

# If not, add user and log out/in
sudo usermod -aG docker $USER</syntaxhighlight>
<span id="permission-issues"></span>
=== Permission Issues ===

'''Problem:''' &quot;permission denied&quot; when running docker commands

'''Solution:'''

<syntaxhighlight lang="bash"># Option 1: Add user to docker group (permanent)
sudo usermod -aG docker $USER
# Then log out and log back in

# Option 2: Use sudo (temporary)
sudo docker run hello-world</syntaxhighlight>
'''Problem:''' Files created by container are owned by root

'''Cause:''' Container runs as root (UID 0) by default

'''Solution:'''

<syntaxhighlight lang="bash"># Run container as specific user
docker run --user $(id -u):$(id -g) IMAGE

# Or use user namespaces (advanced)</syntaxhighlight>
<span id="network-issues"></span>
=== Network Issues ===

'''Problem:''' Container can't access internet

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Test from container
docker exec CONTAINER ping -c 2 8.8.8.8

# Check Docker's NAT rules
sudo iptables -t nat -L -n | grep docker

# Check IP forwarding
sysctl net.ipv4.ip_forward</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Enable IP forwarding if disabled
sudo sysctl -w net.ipv4.ip_forward=1

# Restart Docker daemon
sudo systemctl restart docker</syntaxhighlight>
'''Problem:''' Containers on custom network can't communicate

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check network exists
docker network ls

# Check containers are on same network
docker network inspect NETWORK

# Test connectivity
docker exec CONTAINER1 ping CONTAINER2_IP</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Ensure both containers on same network
docker network connect NETWORK CONTAINER</syntaxhighlight>
'''Problem:''' Port mapping not working (<code>-p</code> flag)

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check port is actually mapped
docker port CONTAINER

# Check if host port is already in use
sudo ss -tulpn | grep :8080</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># If port in use, use different host port
docker run -p 8081:80 nginx

# Or stop the conflicting process
sudo fuser -k 8080/tcp</syntaxhighlight>
<span id="storage-issues"></span>
=== Storage Issues ===

'''Problem:''' &quot;No space left on device&quot;

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check Docker disk usage
docker system df

# Check host disk space
df -h /var/lib/docker</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Remove unused objects
docker system prune -a

# Remove specific old images
docker images
docker rmi IMAGE_ID</syntaxhighlight>
'''Problem:''' Changes in bind mount not visible in container

'''Cause:''' Path doesn't exist or wrong path specified

'''Solution:'''

<syntaxhighlight lang="bash"># Verify path exists on host
ls -la /path/to/host/directory

# Use absolute paths
docker run -v /absolute/path:/container/path IMAGE

# Or use $PWD for current directory
docker run -v $PWD/relative/path:/container/path IMAGE</syntaxhighlight>
<span id="resource-limit-issues"></span>
=== Resource Limit Issues ===

'''Problem:''' Container killed unexpectedly

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check container exit code
docker inspect CONTAINER --format='{{.State.ExitCode}}'
# Exit code 137 = killed (often OOM)

# Check logs
docker logs CONTAINER</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Increase memory limit
docker run --memory=1g IMAGE

# Or run without memory limit (default)
docker run IMAGE</syntaxhighlight>
'''Problem:''' Container using too much CPU

'''Solution:'''

<syntaxhighlight lang="bash"># Limit CPU usage
docker run --cpus=0.5 IMAGE

# Check what's consuming CPU
docker exec CONTAINER top</syntaxhighlight>
<span id="next-steps-dockerfile-and-docker-compose"></span>
== Next Steps: Dockerfile and Docker Compose ==

Congratulations! You've mastered the fundamental OS concepts behind containers:

* '''Namespaces''' provide isolation (network, PID, mount, UTS, IPC, user, cgroup)
* '''cgroups''' enforce resource limits (CPU, memory, I/O)
* '''OverlayFS''' provides efficient layered filesystems
* '''Bridges and veth pairs''' connect containers (same as Lab 7!)
* '''Volumes''' persist data beyond container lifecycles

However, you've been using '''pre-built images''' and running containers with long <code>docker run</code> commands. In production environments, you need:

# '''Custom images''' tailored to your applications
# '''Reproducible builds''' that can be version-controlled
# '''Multi-container orchestration''' with coordinated startup and networking

This is where '''Dockerfile''' and '''Docker Compose''' come in.

<span id="dockerfile-building-custom-images"></span>
=== Dockerfile: Building Custom Images ===

Instead of starting from a base image and manually installing packages, you define your application's environment in a <code>Dockerfile</code>:

<syntaxhighlight lang="dockerfile"># Start from Ubuntu base image
FROM ubuntu:22.04

# Install dependencies
RUN apt-get update && apt-get install -y \
    python3 \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

# Copy application code
COPY app.py /app/
COPY requirements.txt /app/

# Install Python dependencies
WORKDIR /app
RUN pip3 install -r requirements.txt

# Expose port
EXPOSE 8000

# Define startup command
CMD ["python3", "app.py"]</syntaxhighlight>
'''Build the image:'''

<syntaxhighlight lang="bash">docker build -t myapp:1.0 .</syntaxhighlight>
'''Run containers from your custom image:'''

<syntaxhighlight lang="bash">docker run -d -p 8000:8000 myapp:1.0</syntaxhighlight>
'''Benefits:'''

* '''Reproducibility''': Same Dockerfile always builds identical image
* '''Version control''': Dockerfile lives in git alongside code
* '''Documentation''': Dockerfile explicitly documents dependencies and setup
* '''Automation''': CI/CD pipelines can build images automatically

'''Common Dockerfile instructions:'''

* <code>FROM</code>: Base image to start from
* <code>RUN</code>: Execute command during build (install packages, etc.)
* <code>COPY</code> / <code>ADD</code>: Copy files from host into image
* <code>WORKDIR</code>: Set working directory
* <code>ENV</code>: Set environment variables
* <code>EXPOSE</code>: Document which ports the application uses
* <code>CMD</code>: Default command to run when container starts
* <code>ENTRYPOINT</code>: Configure container as executable

'''Best practices:'''

* Use specific image tags (not <code>latest</code>)
* Minimize layers (combine <code>RUN</code> commands)
* Leverage build cache (order instructions from least to most frequently changing)
* Use <code>.dockerignore</code> (like <code>.gitignore</code> for Docker builds)
* Don't run as root (use <code>USER</code> instruction)
* Multi-stage builds for smaller images

<span id="docker-compose-multi-container-orchestration"></span>
=== Docker Compose: Multi-Container Orchestration ===

Instead of running multiple <code>docker run</code> commands with complex options, define your entire infrastructure in a <code>docker-compose.yml</code> file:

<syntaxhighlight lang="yaml">version: '3.8'

services:
  # Purple reverse proxy
  purple:
    image: caddy
    ports:
      - "8080:80"
    volumes:
      - ./purple:/etc/caddy
    networks:
      labnet:
        ipv4_address: 10.10.0.10
    depends_on:
      - red
      - blue

  # Red backend
  red:
    image: caddy
    volumes:
      - ./red:/etc/caddy
      - ./red:/usr/share/caddy
    networks:
      labnet:
        ipv4_address: 10.10.0.2
    deploy:
      resources:
        limits:
          memory: 256M

  # Blue backend
  blue:
    image: caddy
    volumes:
      - ./blue:/etc/caddy
      - ./blue:/usr/share/caddy
    networks:
      labnet:
        ipv4_address: 10.10.0.3
    deploy:
      resources:
        limits:
          cpus: '0.5'

networks:
  labnet:
    driver: bridge
    ipam:
      config:
        - subnet: 10.10.0.0/24</syntaxhighlight>
'''Start entire infrastructure:'''

<syntaxhighlight lang="bash">docker compose up</syntaxhighlight>
Or in detached mode:

<syntaxhighlight lang="bash">docker compose up -d</syntaxhighlight>
'''Stop everything:'''

<syntaxhighlight lang="bash">docker compose down</syntaxhighlight>
'''View logs:'''

<syntaxhighlight lang="bash">docker compose logs -f</syntaxhighlight>
'''Benefits:'''

* '''Declarative''': Describe desired state, not imperative commands
* '''Single source of truth''': One file defines entire application
* '''Easy to share''': Colleagues can run <code>docker compose up</code> and get identical environment
* '''Development/production parity''': Same compose file works everywhere
* '''Automatic networking''': Compose creates network and DNS automatically

'''This is the production-ready way to deploy multi-container applications.'''

'''Further learning:'''

* '''Dockerfile''': Learn advanced instructions, multi-stage builds, build arguments
* '''Docker Compose''': Learn service dependencies, health checks, scaling
* '''Docker Swarm''': Docker's built-in orchestration for multi-host deployments
* '''Kubernetes''': Industry-standard container orchestration platform
* '''Container registries''': Push images to Docker Hub, GitHub Container Registry, or private registries
* '''Security''': Image scanning, rootless Docker, seccomp profiles, AppArmor

These topics build on the solid foundation you've established in this lab. You now understand what containers actually are at the OS level—the rest is learning tools that make containers easier to build and deploy.

<span id="deliverables-and-assessment"></span>
== Deliverables and Assessment ==

Submit a single PDF document containing all deliverables from Exercises A through E, organized with clear section headers matching the exercise labels.

'''Required deliverables:'''

* '''Deliverable A''': Installation verification (screenshots)
* '''Deliverable B''': Hello World and namespace inspection (screenshots)
* '''Deliverable C''': Fedora exploration (screenshots)
* '''Deliverable D''': Persistent storage (screenshots)
* '''Deliverable E''': Multi-container infrastructure (screenshots)

<span id="additional-resources"></span>
== Additional Resources ==

This lab introduced containerization using Docker, demonstrating how Linux kernel features (namespaces, cgroups, OverlayFS) are composed to create isolated application environments. You've seen that Docker is not magic—it's sophisticated automation of kernel primitives you already understand from previous labs.

<span id="for-further-study"></span>
=== For Further Study ===

'''Container Internals:'''

* Deep dive into runc (the OCI runtime that Docker uses)
* Understanding containerd (container runtime layer)
* Linux capabilities and security contexts
* AppArmor and SELinux profiles for containers
* User namespaces and rootless containers
* Seccomp profiles for system call filtering

'''Dockerfile Best Practices:'''

* Multi-stage builds for smaller images
* Build cache optimization strategies
* Layer ordering for efficient rebuilds
* .dockerignore for excluding files
* Security scanning with Trivy or Clair
* Distroless and minimal base images

'''Docker Compose Advanced:'''

* Service dependencies with health checks
* Environment-specific overrides
* Secrets management
* Multiple compose files (base + overrides)
* Named volumes vs bind mounts
* Integration testing with compose

'''Container Orchestration:'''

* Kubernetes architecture and concepts
* kubectl basics
* Pods, Services, Deployments, ConfigMaps
* Kubernetes networking (CNI plugins)
* Helm charts for package management
* Service mesh (Istio, Linkerd)

'''Container Networking Deep Dive:'''

* Bridge vs host vs macvlan networking
* Overlay networks for multi-host communication
* Network plugins and CNI specification
* Load balancing strategies
* Service discovery patterns
* Network policies and segmentation

'''Security:'''

* Container escape techniques and mitigations
* Image vulnerability scanning
* Runtime security monitoring (Falco)
* Least privilege principles
* Supply chain security
* Harbor for secure image registry

'''Performance:'''

* Container resource tuning
* Storage drivers (overlay2, btrfs, zfs)
* Network performance optimization
* Monitoring with Prometheus and Grafana
* Distributed tracing with Jaeger

'''Production Operations:'''

* Logging strategies (centralized logging)
* Health checks and readiness probes
* Rolling updates and blue-green deployments
* Backup and disaster recovery
* CI/CD integration (Jenkins, GitLab CI)
* Container registries (private, public)

<span id="relevant-manual-pages"></span>
=== Relevant Manual Pages ===

<syntaxhighlight lang="bash">man 7 namespaces                             # Linux namespaces overview
man 7 cgroups                                # Control groups overview
man 2 unshare                                # Create namespaces
man 2 setns                                  # Enter existing namespace
man 8 nsenter                                # Run program in namespace
man 1 docker                                 # Docker CLI reference
man 1 docker-run                             # docker run reference
man 1 docker-compose                         # Docker Compose reference</syntaxhighlight>
<span id="online-resources"></span>
=== Online Resources ===

'''Official Documentation:'''

* [https://docs.docker.com/ Docker Documentation] - Comprehensive official docs
* [https://hub.docker.com/ Docker Hub] - Public image registry
* [https://opencontainers.org/ OCI Specification] - Open Container Initiative standards
* [https://containerd.io/docs/ containerd Documentation] - Container runtime

'''Tutorials and Guides:'''

* [https://docker-curriculum.com/ Docker Curriculum] - Beginner-friendly tutorial
* [https://labs.play-with-docker.com/ Play with Docker] - Free interactive playground
* [https://kubernetes.io/docs/ Kubernetes Documentation] - K8s official docs
* [https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ Dockerfile Best Practices]

'''Deep Dives:'''

* [https://lwn.net/Articles/531114/ Understanding Namespaces (LWN)] - Series on Linux namespaces
* [https://jvns.ca/blog/2016/10/10/what-even-is-a-container/ How Containers Work] - Excellent blog post by Julia Evans
* [https://sysdig.com/blog/dockerfile-best-practices/ Container Security Best Practices] - Security-focused guide

'''Community:'''

* [https://forums.docker.com/ Docker Forums] - Community support
* [https://stackoverflow.com/questions/tagged/docker Stack Overflow - Docker Tag]
* [https://reddit.com/r/docker Reddit r/docker]
* [https://slack.cncf.io/ CNCF Slack] - Cloud Native Computing Foundation community

'''Practice Environments:'''

* [https://www.katacoda.com/ Katacoda] - Interactive Docker and Kubernetes scenarios
* [https://labs.play-with-k8s.com/ Play with Kubernetes] - K8s playground
* [https://killercoda.com/ KillerCoda] - Interactive learning scenarios