LFCS 152 🐧 Docker — Concepts

The previous chapters covered the system administration topics from the storage, networking, and security domains. This chapter introduces the container engine that the LFCS exam lists under “Operations Deployment”: Docker. The exam tests the conceptual model: the client-server architecture, the three core objects (image, container, registry), and the difference between containers and virtual machines. The critical trap is the assumption that a container is a lightweight virtual machine. A virtual machine virtualizes the hardware and runs a full guest operating system with its own kernel. A container virtualizes the operating system and shares the host kernel. The container is a process, not a machine .

Key point: Docker uses a client-server architecture. The docker client sends commands to the dockerd daemon, which does the work of building, running, and distributing containers. The image is the read-only template. The container is the running instance of the image. The registry is the store that holds the images. The container shares the host kernel and uses Linux namespaces for isolation and cgroups for resource limits.

---

Why Docker requires a specific mental model

The virtual machine versus container problem. A virtual machine runs a hypervisor that emulates the hardware. The guest operating system boots its own kernel, and the application runs on top of that kernel. The result is a full machine that is isolated but heavy: gigabytes of disk, seconds of boot time, and dedicated CPU and memory . A container does not boot an operating system. It starts a process on the host kernel, confined by namespaces and cgroups. The container is megabytes in size and starts in milliseconds . The isolation is at the operating system level, not the hardware level.

The client-server problem. The docker command is a client. The dockerd daemon is the server. The client sends the command over a socket or the REST API, and the daemon performs the operation. The client and the daemon can run on the same machine, or the client can connect to a remote daemon. The separation is what allows the Docker CLI to be a thin binary and the daemon to run as a system service .

The image versus container problem. An image is a read-only template. It contains the filesystem, the application, the libraries, and the configuration. The image is built from a Dockerfile, and it is stored in a registry. A container is a running instance of an image. The container adds a writable layer on top of the image, and the processes run inside it. The image is the class; the container is the object. The image is immutable; the container is mutable .

The registry problem. A registry is a library of images. The default public registry is Docker Hub, which hosts millions of images. A private registry is the alternative for the images that must not be public. The docker pull command downloads an image from the registry. The docker push command uploads an image to the registry. The registry is the distribution mechanism, not the runtime .

The namespace and cgroups problem. The container isolation is not magic. The Linux kernel provides the namespaces (PID, network, mount, UTS, IPC) that give the container its own view of the process tree, the network interfaces, the filesystem, and the hostname. The cgroups provide the resource limits (CPU, memory, block I/O). The Docker daemon configures these kernel features when it creates the container. The kernel is doing the work; Docker is the orchestrator .

The trade-off. The container is lighter and faster than the virtual machine, but the isolation is weaker. A kernel vulnerability affects every container on the host. A virtual machine with a separate kernel is isolated from the host kernel vulnerabilities. The container is the right choice for the application packaging and the microservices; the virtual machine is the right choice for the strong isolation and the different operating systems.

---

a. The Docker architecture and the daemon

Docker uses a client-server architecture. The client is the docker binary. The daemon is the dockerd process that runs on the host.

# Check the Docker version (client and server)
docker version

# Check the daemon status
sudo systemctl status docker

The docker version output has two sections: the client and the server. The client is the local binary. The server is the daemon. If the daemon is not running, the server section is empty and the error is “Cannot connect to the Docker daemon” .

The daemon listens on a Unix socket (/var/run/docker.sock) by default. The client connects to the socket. The socket is the local communication channel. The remote client connects over the TCP socket if the daemon is configured to listen on it.

The docker info command shows the daemon configuration: the storage driver, the cgroup driver, the kernel version, and the number of containers and images .

---

b. The image, the container, and the registry

The image is the template. The container is the instance. The registry is the store.

# Pull an image from Docker Hub
docker pull nginx:latest

# List the local images
docker images

# Run a container from the image
docker run -d --name web -p 8080:80 nginx:latest

# List the running containers
docker ps

The docker pull downloads the image from the registry. The image is stored locally in the Docker storage. The docker images lists the local images with the repository, the tag, the image ID, and the size.

The docker run creates a container from the image and starts it. The -d flag runs the container in the background. The --name assigns a name. The -p 8080:80 maps the host port 8080 to the container port 80. The nginx:latest is the image.

The container is a process. The docker ps lists the running containers with the container ID, the image, the command, the status, and the ports.

---

c. The container isolation and the resource limits

The container shares the host kernel. The namespaces isolate the processes. The cgroups limit the resources.

# Run a container with memory and CPU limits
docker run -d --name limited \
  --memory="512m" \
  --cpus="1.5" \
  nginx:latest

# Inspect the container limits
docker inspect limited | grep -A 5 "HostConfig"

The --memory="512m" limits the container to 512 megabytes of memory. The --cpus="1.5" limits the container to 1.5 CPU cores. The limits are enforced by the kernel cgroups.

The docker inspect shows the container configuration, including the resource limits. The HostConfig section has the Memory and NanoCpus fields.

The container is not a virtual machine. It does not have its own kernel. The uname -r command inside the container returns the host kernel version, which is the evidence of the shared kernel .

---

Complete Example Session

# ============================================
# PART 1: CHECK THE DOCKER VERSION
# ============================================

docker version
# Client and server sections.
# Server version confirms the daemon is running.

# ============================================
# PART 2: CHECK THE DAEMON STATUS
# ============================================

sudo systemctl status docker
# active (running)

# ============================================
# PART 3: PULL AN IMAGE
# ============================================

docker pull nginx:latest
# Image downloaded from Docker Hub.

# ============================================
# PART 4: LIST THE IMAGES
# ============================================

docker images
# nginx  latest  abc123  1 week ago  187MB

# ============================================
# PART 5: RUN A CONTAINER
# ============================================

docker run -d --name web -p 8080:80 nginx:latest
# Container started in the background.

# ============================================
# PART 6: LIST THE CONTAINERS
# ============================================

docker ps
# web  nginx:latest  "nginx -g 'daemon of…"  Up 5 seconds  0.0.0.0:8080->80/tcp

# ============================================
# PART 7: VERIFY THE SHARED KERNEL
# ============================================

docker exec web uname -r
# Host kernel version, not a container kernel.

# ============================================
# PART 8: LIMIT THE RESOURCES
# ============================================

docker run -d --name limited --memory="512m" --cpus="1.5" nginx:latest

# ============================================
# PART 9: CLEAN UP
# ============================================

docker stop web limited
docker rm web limited

The nine parts trace the Docker workflow: version check, daemon status, image pull, image list, container run, container list, shared kernel verification, resource limits, and cleanup.

---

Quick Reference

Docker Objects

Object	Purpose
Image	Read-only template
Container	Running instance of an image
Registry	Store of images
Dockerfile	Text file that builds an image

Architecture

Component	Role
docker	Client
dockerd	Daemon (server)
/var/run/docker.sock	Local socket
REST API	Remote communication

Commands

Command	Purpose
docker version	Client and server version
docker info	Daemon configuration
docker pull	Download image
docker images	List images
docker run	Create and start container
docker ps	List running containers
docker exec	Run command in container

Container vs VM

Aspect	Container	Virtual Machine
Kernel	Shared with host	Own kernel
Size	Megabytes	Gigabytes
Boot time	Milliseconds	Seconds
Isolation	Namespaces + cgroups	Hardware virtualization

---

Best Practices

✅ Do This:

docker run -d --name web -p 8080:80 nginx:latest
<!-- Use the daemon for the container runtime -->     # ✅

docker exec web uname -r
<!-- Verify the shared kernel -->                    # ✅

docker run --memory="512m" --cpus="1.5" nginx
<!-- Limit the resources -->                         # ✅

❌ Don’t Do This:

# Treat a container as a virtual machine
<!-- It shares the host kernel -->                   # ❌

# Run the container without the daemon
<!-- The client needs the server -->                 # ❌

# Assume the container has its own kernel
<!-- uname -r shows the host kernel -->              # ❌

---

Common Pitfalls

Pitfall	Why It Happens	Fix
Cannot connect to daemon	Docker service not running	systemctl start docker
Image not found	Wrong tag or registry	docker pull first
Port already in use	Host port conflict	Change the host port
Container exits immediately	No foreground process	Use -d or a long-running command
Resource limits ignored	cgroup not configured	Check the daemon config

---

Real-World Examples

1. Version Check

docker version

2. Daemon Status

sudo systemctl status docker

3. Pull Image

docker pull alpine:latest

4. List Images

docker images

5. Run Container

docker run -d --name app -p 8080:80 nginx

6. List Containers

docker ps

7. Exec Command

docker exec app ls /usr/share/nginx/html

8. Resource Limit

docker run --memory="256m" --cpus="0.5" alpine

9. Inspect

docker inspect app

10. Cleanup

docker stop app && docker rm app

---

Visual

Client-Server Architecture

┌──────────────────────────────────────────────┐
│  Docker Client (docker)                      │
└──────────────────┬───────────────────────────┘
                   │ socket or REST API
                   ▼
┌──────────────────────────────────────────────┐
│  Docker Daemon (dockerd)                     │
│  ├── Image management                        │
│  ├── Container management                    │
│  └── Network management                      │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Linux Kernel (namespaces + cgroups)         │
└──────────────────────────────────────────────┘

Container vs VM

┌──────────────────────────────────────────────┐
│  Virtual Machine                             │
│  ├── App                                     │
│  ├── Guest OS + Kernel                       │
│  └── Hypervisor                              │
│  └── Host OS                                 │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Container                                   │
│  ├── App                                     │
│  ├── Container runtime (namespaces/cgroups)  │
│  └── Host OS Kernel (shared)                 │
└──────────────────────────────────────────────┘

---

Summary

Item	Value
Architecture	Client-server
Client	docker binary
Daemon	dockerd
Image	Read-only template
Container	Running instance
Registry	Image store
Isolation	Namespaces
Resource limits	cgroups
Shared kernel	Yes

Key takeaways:

• Docker is a client-server system. The docker client sends the commands to the dockerd daemon. The daemon does the work. The client and the daemon communicate over a socket or the REST API .
• The image is the template; the container is the instance. The image is read-only. The container adds the writable layer and runs the process. The image is stored in the registry; the container runs on the host .
• The container shares the host kernel. The isolation is provided by the Linux namespaces. The resource limits are provided by the cgroups. The container is not a virtual machine .
• The virtual machine virtualizes the hardware. The container virtualizes the operating system. The virtual machine has its own kernel. The container shares the host kernel. The container is lighter and faster, but the isolation is weaker .
• The registry is the distribution mechanism. Docker Hub is the public registry. The private registry is the alternative. The docker pull downloads; the docker push uploads .

Remember: The image is the build. The container is the run. The registry is the distribution. The client is the interface. The daemon is the engine. The namespace is the isolation. The cgroup is the limit. The exam tests the distinction between the container and the virtual machine.

---

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!