Kernel Mode

Score: 0/20

🐧 Master Quiz: Linux & Networking

Deep dive into Namespaces, Cgroups, PID 1, and IPVS.

🎉 Kernel Compile Complete!​

Your Architect Level:

0/20 User Space

• **↺ Reboot System**

Data Flow

Score: 0/20

🌐 Master Quiz: Linux Networking

Bridges, iptables, and IPVS: The Plumbing of Containers.

🎉 Transmission Complete!​

Your Throughput:

0/20 Offline

• **↺ Re-Connect**

PID 1 Manager

Score: 0/20

⚙️ Master Quiz: Systemd vs Init

Zombies, Signals, and the Private Bodyguard.

🎉 Process Terminated!​

Your Exit Code:

0/20 Zombie

• **↺ Reboot Container**

Lab 1: Moving from Docker to Podman​

If you are on Linux (Fedora/CentOS/RHEL), try this to see how seamless the switch is.

Install Podman:

`sudo dnf install -y podman`

Set the Alias:

`alias docker=podman`

Run a container (Notice no sudo!):

`docker run --rm -it alpine echo "I am running rootless!"`

Lab 2: Debugging K8s with crictl​

Since Docker is gone from K8s, use crictl (Container Runtime Interface Control).

List running pods on a K8s node:

`sudo crictl pods`

List images:

`sudo crictl images`

Note: The syntax is almost identical to Docker!

Runtime Wars

Score: 0/20

🔧 Master Quiz: Runtimes

Docker vs. Containerd vs. CRI-O vs. Podman. Choose your engine.

🎉 Engine Status​

Your Performance:

0/20 Dockershim

• **↺ Restart Service**

Lab 1: The "Resource Hog" Hunt​

Goal: Identify a container causing performance issues.

• Start a Stress Container: docker run -d --name heavy-load alpine sh -c "yes > /dev/null" (This command runs an infinite loop, eating CPU).

• Run Monitor: docker stats

• Observe: Look at the CPU column. You will see heavy-load hitting 100% CPU.

• Fix: Press Ctrl+C to exit stats. docker rm -f heavy-load

Lab 2: The "Hidden Secret" Hunt​

Goal: Extract hidden configuration details.

• Start App with Secret: docker run -d --name secret-app -e PASSWORD=SuperSecret123 alpine sleep 1000

• Inspect: docker inspect secret-app

• Find the Password:

• Beginner Way: Scroll through the text until you see "Env".

• Pro Way: docker inspect secret-app | grep PASSWORD

• Architect Way: docker inspect -f '{{.Config.Env}}' secret-app

• Result: You see [PASSWORD=SuperSecret123].

• Lesson: Never rely on Environment Variables for high security!

Lab 1: The "Silent Killer" (OOM Investigation)​

Goal: Diagnose why a container crashed silently.

• Run with Limits: docker run -d --name memory-test --memory="10m" alpine sleep 1000 (We are giving it a tiny 10MB limit).

• Trigger the Crash:

• We will run a command that eats memory instantly.

• docker exec memory-test grep -r "x" /

• Wait a few seconds. The container will likely stop running.

• The Mystery:

• Run docker ps. It's gone.

• Run docker logs memory-test. It's likely empty or unhelpful.

• The Autopsy (Inspect):

• docker inspect memory-test | grep OOMKilled

• Result:

• "OOMKilled": true

• Conclusion: The Linux Kernel killed your container to save the system. This is the #1 reason for "random" crashes in production.

Lab 2: The "Intruder" Check (Filesystem Forensics)​

Goal: Detect unauthorized changes inside a container.

• Start a Clean Container: docker run -d --name secure-server nginx

• Simulate an Attack:

• docker exec -it secure-server touch /etc/hacker-was-here.txt

• docker exec -it secure-server rm /usr/share/nginx/html/index.html

• Run Forensics: docker diff secure-server

A /etc/hacker-was-here.txt   (A = Added)
C /run/nginx.pid             (C = Changed - this is normal)
D /usr/share/nginx/html/index.html (D = Deleted - CRITICAL!)

Lesson: Security tools use this logic to alert you if critical files change.

Lab 3: The "Data Miner" (Go Template Magic)​

Goal: Extract specific data for automation scripts without using grep.

• Scenario: You have a container, and you need only its IP address to pass to another script.

• Start Container: docker run -d --name my-app nginx

• Attempt 1 (Grep - The Messy Way):docker inspect my-app | grep IPAddress

• Result: Gives you 4-5 lines of output with commas and quotes. Bad for scripts.

• Attempt 2 (Go Template - The Pro Way): docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' my-app

• Result: 172.17.0.2 (Clean, pure text).

• Challenge: Get the Log Path. docker inspect --format='{{.LogPath}}' my-app

• Use Case: You can use this to back up logs automatically: cp $(docker inspect --format='{{.LogPath}}' my-app) ./backup.log

Diagnostics

Score: 0/20

🔍 Master Quiz: Docker Debugging

Stats, Inspect, Diff, and Top: The Investigator's Toolkit.

🎉 Investigation Closed!​

Your Diagnostic Skill:

0/20 Junior Admin

• **↺ Re-Examine**

Lab 1: The "Junk Generator" (Visualize the problem)​

• Check Space: docker system df (Note the numbers).

• Create Junk:

• Run a container: docker run -d --name junk-app alpine sleep 1000

• Stop it: docker stop junk-app

• Pull an image: docker pull busybox

• Check Space Again: docker system df (Reclaimable space increased).

• Clean Up: docker system prune -f

• Verify: docker ps -a (The stopped container is gone). docker images (Busybox is still there! Why? Because it is not "dangling", just unused).

• Deep Clean: docker system prune -a -f

• Verify: docker images (Busybox is gone).

Lab 2: The "Orphan Volume" Hunt​

• Create Volume: docker volume create orphan-vol

• Check List: docker volume ls

• Prune: docker volume prune -f

• Check List: docker volume ls (It’s gone).

Lab 1: The "Time Machine" Clean (Using Filters)​

Goal: Automate cleanup safely by only deleting old junk.

• Create "Old" and "New" Junk:

• We can't actually fake time easily, so we will use the logic.

• Pull an image: docker pull hello-world (This is "New").

• The Command:

• docker system prune -a --filter "until=24h"

• Explanation: This command looks for junk created more than 24 hours ago.

• Result: Since you just pulled hello-world, it is preserved.

• The Comparison:

• Now run: docker system prune -a (Without filter).

• Result: hello-world gets deleted because it is not currently running.

• Lesson: Use until=24h in your cron jobs (automated scripts) to avoid deleting images you just built but haven't started yet.

Lab 2: The "Dependency Hell" (Why can't I delete this?)​

Goal: Understand image layers and why Docker sometimes refuses to delete.

• Create Base Image:

• Create file Dockerfile.base: FROM alpine

• Build: docker build -t my-base:v1 -f Dockerfile.base .

• Create Child Image:

• Create file Dockerfile.child: FROM my-base:v1

• Build: docker build -t my-child:v1 -f Dockerfile.child .

• Attempt Deletion:

• docker rmi my-base:v1

• Result:

• Error: image is being used by ...

• Why? Docker protects you. If you delete the base, the child breaks.

• Fix:

• Delete the child first: docker rmi my-child:v1

• Now delete the base: docker rmi my-base:v1

• Success!

Lab 3: The "Silent Disk Killer" (Log Explosion)​

Goal: Simulate a container filling the disk with logs and fix it without restarting.

• Create the Problem:

• Run a container that spams logs endlessly.

• docker run -d --name spammer alpine sh -c "while true; do echo 'CRITICAL ERROR: Disk is filling up fast...'; sleep 0.01; done"

• Observe the Growth:

• Let it run for 30 seconds.

• Find the log file: LOG_PATH=$(docker inspect --format='{{.LogPath}}' spammer)

• Check size: ls -lh $LOG_PATH (It will grow by MBs every second).

• Attempt Prune (Fail):

• Run docker system prune.

• Result: Does nothing. The container is running, so logs are "active."

• The Architect Fix (Truncate):

• You cannot delete the file while open, but you can empty it.

• truncate -s 0 $LOG_PATH

• Check size again: ls -lh $LOG_PATH (It is now 0 bytes!).

• The Permanent Fix (Log Rotation):

• Stop the spammer: docker rm -f spammer

• Run with limits: docker run -d --log-opt max-size=1m --log-opt max-file=3 alpine ...

• Result: Docker will now automatically delete old logs when they reach 1MB.

Disk Usage

Score: 0/20

🧹 Master Quiz: Docker Cleanup

Garbage Collection, Pruning, and the "Nuclear Option."

🎉 System Cleaned!​

Your Efficiency:

0/20 Intern

• **↺ Run Prune**