Cloud Shells, Containers, and Browser-Based Labs

1. Lab environments form a fidelity spectrum

flowchart TD
  B["Browser command sandbox"] --> C["Disposable container"]
  C --> S["Provider cloud shell"]
  S --> W["WSL 2"]
  W --> V["Full virtual machine"]
  V --> P["Physical or cloud server"]
  B -. lower setup and lower fidelity .-> C
  P -. higher control and higher responsibility .-> V

There is no universally best lab. A regular-expression exercise needs little system fidelity. A boot-recovery exercise needs control of firmware, disks, and the operating-system lifecycle. Choosing a larger environment than necessary wastes time and money; choosing a smaller one can teach false assumptions.

2. Compare the options

3. Cloud shells: managed convenience with provider boundaries

A cloud shell is a provider-managed terminal with preinstalled command-line tools and an authenticated context. It can be ideal for learning provider CLIs and short infrastructure tasks.

4. Containers: fast, disposable user spaces

A Linux container packages a user-space filesystem and processes while sharing the host kernel. This makes containers fast to create and delete, but it also explains why kernel versions and low-level capabilities may come from the host rather than the container image.

# Use Docker or a compatible CLI. Pull an explicit image tag rather than "latest".
docker pull ubuntu:24.04

# Start an interactive disposable shell. --rm deletes the stopped container.
docker run --rm -it --name devops-linux-lab ubuntu:24.04 bash

# Inside the container:
cat /etc/os-release
uname -a
ps -ef
mount | head
exit

The user space reports Ubuntu, while uname reports the host kernel. PID 1 may be Bash rather than systemd. This is expected container behavior, not a broken Ubuntu installation.

5. Use disposable containers safely

• Use explicit, trusted image references and record the image digest for high-reproducibility work.
• Avoid --privileged, host PID/network modes, device access, and broad host mounts unless the lesson specifically requires and explains them.
• Mount only a dedicated lab directory, not the home directory or container-runtime socket.
• Do not embed credentials in images, shell history, Dockerfiles, or public command output.
• Use --rm for disposable exercises and verify that named volumes are not left behind.

lab="$HOME/devops-academy/linux/chapter02/lesson04/shared"
mkdir -p "$lab"
printf 'host-created file\n' > "$lab/input.txt"

# Mount only the dedicated directory and make it read-only.
docker run --rm \
  --mount type=bind,src="$lab",dst=/workspace,readonly \
  ubuntu:24.04 \
  bash -lc 'id; cat /workspace/input.txt; touch /workspace/should-fail'

# The final touch should fail because the mount is read-only.
ls -la "$lab"

6. Browser-based guided labs

Browser labs can provide temporary VMs, containers, or simulated terminals with instructions and automatic validation. Treat each platform as an ephemeral training environment unless it clearly documents persistence.

7. Match the environment to the lesson

8. Cost, cleanup, and evidence

Hosted labs and cloud shells can launch resources that outlive the terminal session. Build cleanup into the exercise:

• Tag resources with owner, purpose, and expiration.
• Use budgets, quotas, and non-production accounts where available.
• List resources before and after the lab.
• Delete compute, disks, public IPs, snapshots, and managed services deliberately.
• Record commands and outcomes without recording secrets.

9. Hands-on lab: compare a container with the primary VM

Run the following report first on the primary VM and then inside a disposable Ubuntu container. Save both outputs outside the container and compare them.

report() {
  printf '=== release ===\n'
  cat /etc/os-release
  printf '\n=== kernel ===\n'
  uname -a
  printf '\n=== pid 1 ===\n'
  ps -p 1 -o pid,comm,args
  printf '\n=== virtualization ===\n'
  systemd-detect-virt 2>/dev/null || true
  printf '\n=== mounts ===\n'
  findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | head -n 20
  printf '\n=== cgroup ===\n'
  cat /proc/1/cgroup
}

lab="$HOME/devops-academy/linux/chapter02/lesson04"
mkdir -p "$lab"
report > "$lab/vm-report.txt"

# Export the function definition into a temporary script for the container.
declare -f report > "$lab/report.sh"
printf '\nreport\n' >> "$lab/report.sh"

docker run --rm \
  --mount type=bind,src="$lab",dst=/output \
  ubuntu:24.04 \
  bash /output/report.sh > "$lab/container-report.txt"

diff -u "$lab/vm-report.txt" "$lab/container-report.txt" || true

10. Common disposable-lab mistakes

11. Knowledge check

12. Summary

Cloud shells, containers, and browser labs reduce setup and are excellent for bounded exercises. Their restrictions are part of the engineering model: containers share a kernel, cloud shells inherit provider identity and policy, and browser labs may be temporary. Use the smallest environment that preserves the behavior being learned, and retain the full VM for system-level work.

13. Further reading

• Open Container Initiative runtime and image specifications — container process and filesystem contracts.
• Docker or Podman documentation — bind mounts, image references, cleanup, and rootless operation.
• Your cloud provider’s cloud-shell documentation — persistence, quotas, authentication, and network limits.
• Linux namespaces, cgroups, and capabilities manual pages.
• Provider billing and resource-cleanup documentation for sandbox environments.