⌘
My Laptop / local terminal
Execution guidance
Type in your project folder on your laptop. Open its local browser. Docker Desktop uses a local Linux VM; no SSH is needed.
↗
Remote / Cloud / SSH terminal on your own Ubuntu
Execution guidance
After SSH, your shell is on the server. Use the laptop’s SSH tunnel to reach the server’s loopback service. Same lab, different host.
◈
Environment setup ↗Badr’s Hades reference / no student access
Reference evidence boundary
A sanitized engineering walkthrough, not a live connection. Historical TD1/TD2 local observations; registry and TD3–TD6 Hades replay remain unexecuted.
Your engineering workspace
Choose today’s lab ↓01 / YOUR OWN DESK · BEGINNER → INTERMEDIATE
Everything starts on your laptop.
Open your project in a local terminal. Your Docker client reaches your local engine; your browser reaches the web container through local loopback. On Docker Desktop, the engine runs inside its local Linux VM.
Windows uses Ubuntu Bash in WSL2 with Docker Desktop integration. Check your setup.
UBUNTU BASH / TERMINAL
$ docker versionCheck Client + Server before work.EDITOR / PROJECTDockerfilecompose.yamlscripts/
LOCAL DOCKER ENGINEpinned image container
one hostLOCAL BROWSER127.0.0.1:8080container :8080
Illustrated model · no Docker command runs on this page.
02 / YOUR OWN UBUNTU · BEGINNER → ADVANCED
Cross the machine boundary. Know where you are.
Your laptop opens an SSH shell on your own Ubuntu server. Docker commands then run on that server. A separate laptop tunnel lets your local browser reach the server’s loopback port.
Your shell is on the laptop. Before SSH, no command is running on the Ubuntu server.
The server, account and bill are yours. Provider selection is secondary. See verified SSH and tunnel setup.
YOUR LAPTOP
Terminal ALaptop shellBefore SSH
Browser127.0.0.1:8080
INTERNET / BOUNDARY
YOUR UBUNTU SERVER
Terminal A after SSHServer shellDocker commands run here
Docker Engineloopback 127.0.0.1:8080 → web container
Browser stays on the laptop. The tunnel reaches server loopback; it does not publish the service to the Internet. Illustration only: no SSH session or tunnel is opened here.
03 / SOVEREIGN VPS · INTERMEDIATE → ADVANCED · REFERENCE ONLY
Look over the engineer’s shoulder. Inspect Hades.
Hades is Badr’s own Ubuntu VPS. This is a sanitized worked reference: students receive no account, address or access. Select a boundary in the host map to see why it matters.
Evidence boundary TD1 lifecycle and TD2 local image behavior were observed historically. GHCR publication and the revised TD3–TD6 route have not been executed on Hades.
HADESBadr’s Ubuntu VPS / reference map
NO STUDENT ACCESS01 / LINUX HOST
02 / DOCKER RUNTIME
03 / DELIVERY CHAIN
Choose one node. The map shows conceptual responsibilities, not live telemetry.
Host boundary
Users
The login identity decides which host actions are possible. The reference asks Badr to inspect id; it publishes no account names or credentials.
Read sanitized TD1 referenceHost boundary
Filesystem
The project checkout and Docker-owned data have different locations and lifetimes. The reference begins by checking pwd; it does not expose Hades paths.
Read sanitized TD1 referenceConceptual layer
systemd
A Linux service manager can supervise the Docker daemon. The current Hades walkthrough does not claim a systemd inspection or a service recovery test.
Read sanitized TD1 referenceConceptual layer
Firewall
The Docker host binds the course web port to loopback. A provider firewall and an SSH tunnel are separate boundaries; this reference does not claim a firewall audit.
Read sanitized TD1 referenceHistorical TD1 context
Docker daemon
The Docker client sends requests to the engine on the chosen host. The earlier Hades TD1 replay ran the locked web container; it does not validate every revised lab command.
Read sanitized TD1 referenceHistorical TD1 observation
Containers
The earlier replay reached the web container through loopback and a tunnel, then observed a new container identity after recreation. Its pinned image remained reusable.
Read sanitized TD1 referenceIllustrative / not replayed
Networks
The TD3 reference connects the API to postgres:5432 by service name on a private network. Its revised V4 route has not been replayed on Hades.
Read sanitized TD3 referenceIllustrative / not replayed
Volumes
A named volume can outlive its container; it is not a backup. The TD3 reference keeps the database off host ports and distinguishes persistence from restore proof.
Read sanitized TD3 referenceIllustrative / not replayed
Logs
The TD4 reference follows the browser → proxy → API → database request path. Logs and health observations help test a fault hypothesis before repair.
Read sanitized TD4 referenceIllustrative / not replayed
Backups
The TD3 reference checks a separate database dump and restores into a clean destination. No Hades backup or restore success is asserted for the revised route.
Read sanitized TD3 referenceNot run on Hades
Registry
TD2 built the supplied API locally, but GHCR publication and digest pull were not run. A local image ID must not be presented as a registry digest.
Read sanitized TD2 referenceIllustrative / not replayed
CI
The TD6 reference shows build once, record digest D and obtain digest-specific approval. No CI-to-Hades deployment success is claimed.
Read sanitized TD6 referenceIllustrative / not replayed
Rollback
A failed candidate D returns to known-good application digest P and is verified again. Database recovery is separate; the Hades exercise was not executed.
Read sanitized TD6 referenceChoose today’s labTD0 → TD6
Release an exact image and roll back
An immutable release, smoke tests and a known-good way back.
Enter lab