Container Lab
Spin up real ephemeral containers in isolated environments
Your Active Labs
0Choose a Lab Template
Each template provisions a real LXC container on isolated infrastructure
💻 Beginner
Linux Sandbox
Alpine Linux with bash, vim, curl
1 vCPU 512MB RAM 60 min
🐳 Intermediate
Container Workshop
Docker-in-container environment
1 vCPU 512MB RAM 60 min
🌐 Intermediate
Networking Lab
3 interconnected containers
1 vCPU 512MB RAM 60 min
📝 Advanced
IaC Playground
Ansible + target container
1 vCPU 512MB RAM 60 min
Active Lab
Running
LIVE Connecting...
Session
--- Time Left --:--
CPU 0%
MEM 0%
Challenges
Get familiar with the container environment
○ Check the OS release
- Run cat /etc/os-release to see the distribution info
- Note the NAME and VERSION_ID fields — this is Alpine Linux
- Alpine is popular for containers because it is tiny (~5MB base image)
cat /etc/os-release 💡 Alpine uses musl libc instead of glibc, and busybox for core utilities. This keeps it small but some software needs special builds.
○ View available disk space
- Run df -h to display disk usage in human-readable format
- Look at the / (root) filesystem — that is your container's writable layer
- Notice how small the container filesystem is compared to a full VM
df -h 💡 Containers share the host kernel and use overlay filesystems. The disk you see is a thin layer on top of the base image.
Expected:
A table showing filesystems, their sizes, used/available space, and mount points
○ Check available memory
- Run free -h to see total, used, and available memory
- The "available" column is what your container can actually use
- Compare total memory to what a full Linux install typically needs (512MB+)
free -h 💡 In a containerized environment, memory may be limited by cgroups. The total you see might be the host's total or a cgroup-enforced limit.
○ List installed packages
- Run apk list --installed to see every package in this container
- Count how few packages there are — Alpine keeps it minimal
- Look for busybox, musl, and alpine-baselayout — these are the core of Alpine
apk list --installed 💡 A minimal Alpine install has around 15-20 packages. Compare that to Ubuntu which ships hundreds by default. Fewer packages means a smaller attack surface.
○ View running processes
- Run ps aux to list all running processes
- Notice how few processes are running — likely just your shell and ps itself
- In a container, PID 1 is not systemd or init — it is whatever the container entrypoint is
ps aux 💡 Containers use PID namespaces, so PID 1 inside the container is not PID 1 on the host. This isolation is a core part of containerization.
Expected:
A short list of processes, typically just the shell session and the ps command itself
Install and manage software in Alpine Linux
○ Update the package index
- Run apk update to download the latest package list from Alpine repositories
- Watch for the repository URLs — Alpine uses main and community repos
- This is similar to apt update on Debian or dnf check-update on Fedora
apk update 💡 Alpine packages are fetched from dl-cdn.alpinelinux.org by default. The package index is small because Alpine itself is small — updates take seconds, not minutes.
○ Search for a package
- Run apk search nginx to find packages matching "nginx"
- Notice the results include the package name and version number
- You can also use apk search -d nginx to include descriptions in the search
apk search nginx 💡 Alpine's repository has fewer packages than Debian or Fedora, but covers most server workloads. If a package is missing, you can often compile from source or use a community repo.
○ Install a package
- Run apk add curl to install the curl HTTP client
- Watch the output — apk resolves dependencies and installs them automatically
- Note how fast installation is compared to apt or yum — Alpine packages are tiny
apk add curl 💡 The apk add command is equivalent to apt install or dnf install. You can install multiple packages at once: apk add curl wget git.
Expected:
Download and install messages followed by OK
○ Verify the installation
- Run curl --version to confirm curl was installed correctly
- Check the protocols listed — curl supports HTTP, HTTPS, FTP, and more
- Try which curl to see where the binary was installed
curl --version 💡 On Alpine, binaries go to /usr/bin. You can also run apk info curl to see package details including size and dependencies.
○ Remove a package
- Run apk del curl to uninstall curl and any orphaned dependencies
- Verify removal with which curl — it should return nothing
- Keeping containers clean by removing unused packages reduces image size and attack surface
apk del curl 💡 In real container workflows, you often install build tools, compile something, then remove the tools in the same Dockerfile layer to keep images small. This is called a multi-stage build pattern.
Run and manage services inside the container
○ Install nginx
- Run apk add nginx to install the nginx web server
- Alpine ships a lightweight nginx build linked against musl libc
- Check that /etc/nginx/nginx.conf was created — this is the main config file
apk add nginx 💡 Alpine uses OpenRC as its init system, not systemd. You will not find systemctl here. Services are managed through rc-service and rc-update commands instead.
○ Start nginx
- Run nginx to start the web server in the foreground daemon mode
- Alternatively, you can use rc-service nginx start if OpenRC is initialized
- Nginx forks a master process and worker processes to handle connections
nginx 💡 In containers, services are often run in the foreground (nginx -g "daemon off;") so the container stays alive. Here we run it normally since we already have a shell session.
Expected:
No output on success — nginx starts silently as a daemon
○ Verify nginx is running
- Run curl localhost to make an HTTP request to the local nginx server
- You should see a default welcome page or a 404 — either means nginx is responding
- This confirms the web server is listening on port 80 inside the container
curl localhost 💡 Port 80 inside the container is isolated. External access would require port mapping (e.g., docker run -p 8080:80). Inside the container, localhost works normally.
Expected:
HTML content from the nginx default page or a 404 page
○ Check the nginx process
- Run ps aux | grep nginx to find the nginx processes
- You should see a master process running as root and worker processes
- The master process manages configuration reloads; workers handle actual requests
ps aux | grep nginx 💡 Nginx uses an event-driven architecture. A single worker process can handle thousands of concurrent connections, which is why it is popular for reverse proxying in container environments.
Expected:
Lines showing nginx master and worker processes with their PIDs
○ Stop nginx
- Run nginx -s stop to send a stop signal to the nginx master process
- Verify it stopped by running ps aux | grep nginx — there should be no results
- The -s flag sends a signal: stop, quit, reload, and reopen are all valid
nginx -s stop 💡 The difference between stop and quit: stop is a fast shutdown (SIGTERM), quit is a graceful shutdown (SIGQUIT) that waits for active requests to finish.
Manage users and explore system logs
○ Create a new user
- Run adduser -D testuser to create a user without a password prompt
- The -D flag means "defaults" — no password, default shell, auto home directory
- Verify with cat /etc/passwd | grep testuser to see the new entry
adduser -D testuser 💡 Alpine uses busybox adduser, which has slightly different flags than the full useradd from shadow-utils. The -D flag skips interactive prompts.
Expected:
No output on success — the user is created silently
○ Switch to the new user
- Run su - testuser to switch to the new user account
- Run whoami to confirm you are now testuser
- Try touching a file in /root — it should fail with permission denied
su - testuser 💡 The dash (-) in su - means "login shell" — it sets up the environment as if testuser just logged in. Without the dash, you keep root's environment variables.
Expected:
Your shell prompt changes to reflect the testuser account
○ Exit back to root
- Type exit to leave the testuser session and return to root
- Run whoami to confirm you are root again
- In containers, running as root is common but considered a security risk in production
exit 💡 Production containers should run as a non-root user. Dockerfiles use the USER directive to switch. Running as root inside a container can be dangerous if the container escapes its namespace.
○ View system logs
- Run dmesg | tail to see the last kernel ring buffer messages
- These messages show hardware detection, driver loading, and kernel events
- In a container, dmesg shows the host kernel's messages (if permitted)
dmesg | tail 💡 Containers share the host kernel, so dmesg output comes from the host. Many container runtimes restrict dmesg access for security. If you get "permission denied," that is normal container hardening.
Expected:
Kernel log messages or a permission denied error depending on container privileges
○ Write to syslog
- Run logger "Hello from container lab" to send a message to the system logger
- Check if syslog is running with ps aux | grep syslog
- If syslog is running, check /var/log/messages for your message
logger "Hello from container lab" 💡 Containers often skip running a syslog daemon and instead send logs to stdout/stderr. Docker and Kubernetes capture stdout and make it available through their logging drivers. This is the "twelve-factor app" approach to logging.
Understand the Linux filesystem hierarchy
○ Explore the /proc filesystem
- Run ls /proc to see the virtual filesystem that exposes kernel data structures
- Run cat /proc/1/status to see details about PID 1 — the container's init process
- Note the Name, Pid, PPid, and Threads fields — they describe the main process
cat /proc/1/status 💡 /proc is not on disk — it is generated by the kernel on the fly. Every numbered directory is a running process. Files like /proc/cpuinfo, /proc/meminfo, and /proc/uptime expose system information.
Expected:
Process status fields including Name, State, Pid, PPid, Uid, Gid, and memory details
○ Check mount points
- Run mount | head -20 to see the first 20 mounted filesystems
- Look for overlay or aufs entries — these are the container's layered filesystem
- Identify /proc, /sys, and /dev mounts — these are bind-mounted from the host
mount | head -20 💡 Container filesystems use overlayfs to layer a writable top layer over read-only base image layers. When you modify a file, only the changes are stored in the upper layer. This is called copy-on-write.
Expected:
A list of mounted filesystems showing overlay, proc, sysfs, tmpfs, and other mounts
○ View filesystem type
- Run stat -f / to display filesystem information for the root mount
- Look at the Type field to identify the filesystem (overlay, ext4, xfs, etc.)
- Note the block size and total/free blocks for the container's writable layer
stat -f / 💡 The root filesystem in a container is typically overlayfs. The actual storage backend (ext4, xfs, btrfs) is on the host. Overlay just provides the layering mechanism on top.
Expected:
Filesystem statistics showing type, block size, blocks total/free, and inodes
○ Create a tmpfs mount
- Run mkdir -p /tmp/ramdisk first to ensure the mount point exists
- Run mount -t tmpfs tmpfs /tmp/ramdisk to create a RAM-backed filesystem
- Write a file to it: echo "stored in RAM" > /tmp/ramdisk/test.txt
mkdir -p /tmp/ramdisk && mount -t tmpfs tmpfs /tmp/ramdisk 💡 tmpfs lives entirely in RAM (and swap). It is extremely fast but data is lost when the container stops. Kubernetes uses tmpfs for emptyDir volumes with medium: Memory. This requires appropriate container privileges.
Expected:
No output on success — verify with df -h /tmp/ramdisk
○ Check inode usage
- Run df -i to display inode usage for all mounted filesystems
- Inodes are data structures that store file metadata (permissions, owner, timestamps)
- Each file and directory consumes one inode — running out of inodes means no new files even if disk space is free
df -i 💡 Inode exhaustion is a real production issue. Containers generating many small files (logs, temp files, cache entries) can hit inode limits before disk space limits. Monitor both.
Expected:
A table showing filesystem inode counts — total, used, free, and percentage
Understand container resource boundaries
○ Check CPU limits
- Run cat /sys/fs/cgroup/cpu.max to see the CPU bandwidth limit
- The format is "quota period" — e.g., "100000 100000" means 100% of one CPU
- "max 100000" means no CPU limit is set (the container can use all available CPUs)
cat /sys/fs/cgroup/cpu.max 💡 cgroups v2 uses cpu.max with a quota/period format. A value of "50000 100000" means the container gets 50% of one CPU core. Docker --cpus=0.5 sets this. This prevents noisy-neighbor problems.
Expected:
Two numbers (quota and period) or "max" followed by a period value
○ Check memory limits
- Run cat /sys/fs/cgroup/memory.max to see the memory ceiling
- "max" means no limit is set; a number shows the limit in bytes
- Also check cat /sys/fs/cgroup/memory.current to see how much memory is in use right now
cat /sys/fs/cgroup/memory.max 💡 When a container exceeds its memory limit, the kernel OOM killer terminates it. This is why containers get "killed" with exit code 137 (128 + SIGKILL signal 9). Always set memory limits in production.
Expected:
"max" if unlimited, or a number in bytes representing the memory cap
○ View all cgroup settings
- Run ls /sys/fs/cgroup/ to see all available cgroup controllers
- Each file controls a different resource: cpu, memory, io, pids, etc.
- Try cat /sys/fs/cgroup/pids.max to see how many processes the container can create
ls /sys/fs/cgroup/ 💡 cgroups (control groups) are one of the two pillars of containers, alongside namespaces. Namespaces provide isolation (what you can see), cgroups provide limits (how much you can use).
Expected:
Files like cpu.max, memory.max, memory.current, pids.max, io.max, and controller files
○ Check ulimits
- Run ulimit -a to see all shell-level resource limits
- Key limits include open files (-n), max processes (-u), and stack size (-s)
- These are inherited from the container runtime configuration and can differ from the host
ulimit -a 💡 ulimits are per-process resource limits set by the kernel. They work independently from cgroups. A container might have cgroup memory at 512MB but ulimit stack size at 8MB. Both enforce boundaries at different levels.
Expected:
A list of resource limits including core file size, open files, pipe size, stack size, and more
○ Run a CPU stress test
- Run apk add stress-ng to install the stress testing tool
- Run stress-ng --cpu 1 --timeout 5 to stress one CPU core for 5 seconds
- Watch the output — it reports how many operations were completed under any CPU limits
apk add stress-ng && stress-ng --cpu 1 --timeout 5 💡 Stress testing inside a container lets you verify that resource limits are working. If cpu.max is set, the stress test will be throttled. Run top in another terminal to observe CPU usage in real time.
Expected:
stress-ng output showing the test ran for 5 seconds with a summary of operations completed
Understand Linux namespaces from inside the container
○ List namespaces
- Run ls -la /proc/1/ns/ to see all namespaces attached to PID 1
- Each entry is a symbolic link pointing to a namespace identifier like mnt:[4026532xxx]
- Common namespaces: mnt (filesystem), pid (process IDs), net (networking), uts (hostname), ipc (inter-process comms), user (UIDs)
ls -la /proc/1/ns/ 💡 Namespaces are the isolation mechanism that makes containers feel like separate machines. Each namespace type hides a different part of the system. Two containers can both have PID 1 because they are in different PID namespaces.
Expected:
Symbolic links for cgroup, ipc, mnt, net, pid, pid_for_children, user, and uts namespaces
○ Check your PID namespace
- Run echo $$ to see your shell's PID inside the container
- Run cat /proc/self/status | grep NSpid to see the nested PID mapping
- The NSpid line shows your PID in each nested namespace level — the first number is the host PID, the last is your container PID
echo $$ && cat /proc/self/status | grep NSpid 💡 PID namespaces are hierarchical. The host can see all container PIDs (mapped to different numbers), but the container can only see its own PIDs. This is why ps aux inside a container shows so few processes.
Expected:
Your shell PID (e.g., 1 or a small number) and NSpid line showing namespace PID mapping
○ View network namespace info
- Run ip link show to see all network interfaces in your container's network namespace
- Look for eth0 or similar — this is your container's virtual network interface
- Run ip addr show to see the IP addresses assigned to each interface
ip link show 💡 Each container gets its own network namespace with its own interfaces, IP addresses, routing table, and iptables rules. The virtual ethernet (veth) pair connects the container namespace to the host namespace through a bridge.
Expected:
Network interfaces including lo (loopback) and eth0 or similar with their state and addresses
○ Check hostname isolation
- Run hostname to see this container's hostname
- The hostname is isolated by the UTS namespace — changing it here does not affect the host
- Try hostname test-container to change it, then run hostname again to verify
hostname 💡 UTS stands for "UNIX Time-Sharing" — a historical name. The UTS namespace isolates hostname and domain name. This is why each container can have its own hostname without conflicting with others.
Expected:
The container's hostname, which is typically a random string or the container ID
○ Explore cgroup namespace info
- Run cat /proc/self/cgroup to see which cgroup paths this process belongs to
- In cgroups v2 (unified hierarchy), you should see a single entry with path /
- Run cat /proc/1/cgroup to compare — PID 1 and your shell should be in the same cgroup
cat /proc/self/cgroup 💡 The cgroup namespace (added in Linux 4.6) virtualizes the cgroup path. Inside the container, the path appears as / even though the host sees it as /docker/<container-id> or similar. This prevents containers from discovering the host's cgroup hierarchy.
Expected:
One or more lines showing the cgroup controller and path, typically "0::/" for cgroups v2
Compile and run software from source
○ Install build tools
- Run apk add build-base to install gcc, g++, make, and standard C headers
- This is Alpine's equivalent of Debian's build-essential package
- Run gcc --version to confirm the compiler is installed and check the version
apk add build-base 💡 build-base is a meta-package that pulls in gcc, g++, musl-dev (C library headers), make, and other essentials. On Alpine, everything is compiled against musl libc, so binaries built here may not work on glibc-based distros without static linking.
Expected:
Package download and installation messages, ending with OK
○ Write a C program
- Create a simple C source file using the command below
- This writes a minimal "Hello from inside a container!" program to hello.c
- Run cat hello.c to verify the file was written correctly
echo '#include <stdio.h>
int main() {
printf("Hello from inside a container!\n");
return 0;
}' > hello.c 💡 Writing and compiling code inside a container is a common workflow for reproducible builds. The container ensures the build environment is identical every time, regardless of what is on the host.
○ Compile the program
- Run gcc -o hello hello.c to compile the source code into a binary
- The -o flag specifies the output filename (hello)
- If there are no errors, the compiler produces the binary silently
gcc -o hello hello.c 💡 This binary is linked against musl libc (Alpine's C library). To make it portable to other Linux distros, use gcc -static -o hello hello.c for static linking. Static binaries include all dependencies and run anywhere.
Expected:
No output on success — errors would appear if the code had syntax problems
○ Run the program
- Run ./hello to execute the compiled binary
- You should see the greeting message printed to stdout
- This binary ran entirely inside the container's isolated environment
./hello 💡 The binary uses the container's libc, kernel syscall interface, and filesystem. Even though it is a native binary, it is still contained by namespaces and cgroups.
Expected:
Hello from inside a container!
○ Inspect the binary
- Run file hello to identify the binary format — it should show ELF 64-bit, dynamically linked
- Run ldd hello to list the shared libraries it depends on
- Note that it links against musl libc (ld-musl-x86_64.so) instead of glibc (ld-linux-x86-64.so)
file hello && ldd hello 💡 The file command shows the binary format (ELF), architecture (x86-64 or aarch64), and linking type. ldd lists runtime dependencies. musl-linked binaries are smaller but some software with glibc-specific code (like NSS plugins) needs workarounds on Alpine.
Expected:
ELF binary details from file, followed by shared library paths from ldd showing musl libc
Running Containers
0 active
🐳
No containers running
Select a template to get started
Connected to live container -- this is a real, isolated Linux environment
Lab engine unavailable. Running in simulation mode.
Container Concepts
🐳 Docker Containers
Lightweight, portable execution environments that package applications with their dependencies.
- Image-based deployment
- Isolated networking
- Volume mounts for persistence
☸️ Kubernetes
Container orchestration platform for automating deployment, scaling, and management.
- Pod-based workloads
- Service discovery
- Auto-scaling & healing
📦 LXC Containers
System containers that provide full Linux environments with lower overhead than VMs. Powers these labs.
- Full init systems
- Better for persistent workloads
- Used by Proxmox