Practice Linux and Docker commands in a safe, self-contained browser simulation. Build images, run containers, inspect logs, use volumes and networks, launch a Compose project, and complete guided student missions without installing Docker.
Standalone HTMLPersistent simulated labNo real commands executed
Container Lab TerminalSimulated Bash host and Docker Engine
engine ready
OrientationUnderstand the simulator and begin safely
Lesson 01 · Orientation
A safe container laboratory inside one HTML file
This page models a Linux host, a Docker command-line client, images, containers, networks, volumes, port mappings, Dockerfiles, and a small Compose workflow. It is designed for learning command syntax and operational reasoning—not for running untrusted software or replacing a real Docker installation.
Identify the simulation boundaryUse the terminal effectivelyLocate tutorials and missionsReset or export your work
1
What this lab does
A deliberately constrained model of common container workflows
CLI
Interprets commands
The terminal recognizes a useful subset of Bash, GNU-style file commands, Docker CLI commands, and Docker Compose commands. Type help for the supported set.
FS
Maintains virtual filesystems
The simulated host and each container have files and directories. Named-volume data can survive removal of a container, illustrating persistence.
STATE
Tracks resources
The inspector updates as you create, start, stop, inspect, and remove containers, images, networks, and volumes. State is stored locally in your browser.
Important simulation boundary
No Linux command, Docker command, image, network request, or container process is executed on your computer. Pulls, builds, logs, resource statistics, DNS, and HTTP responses are educational simulations. Commands or flags outside the supported subset may produce a teaching message instead of real Docker behavior.
2
First five minutes
Learn the terminal controls before starting a mission
01
Ask the terminal for help
The help command lists simulated shell and Docker features.
help
Observe: commands are grouped by shell, Docker, files, networking, and lab controls.
02
Check the Docker client and engine model
Docker uses a client command that communicates with an engine. Here both are simulated.
docker version
03
Inspect the starting images
Images are read-only templates from which containers are created.
docker images
04
Run the traditional first container
The hello-world image prints a message and exits.
docker run --name first-container hello-world
Observe: the process exits, but the stopped container remains visible with docker ps -a.
05
Review your command history
Use the Up and Down arrow keys, or print the history list.
history
Knowledge check
What is the most important limitation of this page?
Lesson 02 · Linux shell
Build the command-line habits container work depends on
Docker commands are usually entered from a shell, and interactive container troubleshooting happens inside a shell. Practice paths, files, redirection, pipelines, environment variables, and command history before moving to lifecycle operations.
Read a promptUse absolute and relative pathsCreate and inspect filesRedirect and filter output
1
Anatomy of the prompt
User, host, working directory, and privilege marker
studentcurrent user
@
container-labhost name
:
~ $home directory; non-root shell
Paths matter
An absolute path begins with /, such as /home/student/projects. A relative path is interpreted from the current working directory. The symbols . and .. mean the current and parent directory.
2
Guided shell practice
Use each command, then inspect what changed
01
Locate yourself and list files
pwd prints the current directory; ls -la includes details and hidden entries.
pwd && ls -la
02
Create a lab directory
The -p flag creates missing parent directories and does not fail if they already exist.
mkdir -p ~/labs/shell-practice && cd ~/labs/shell-practice
03
Create content with redirection
One greater-than sign replaces a file. Two append to it.
echo "container notes" > notes.txt
echo "images create containers" >> notes.txt
04
Read and filter content
A pipeline sends the output of one command into another. This simulator supports common teaching pipelines such as grep, head, tail, and wc -l.
cat notes.txt | grep image
05
Use the built-in file editor
The simulated nano and vi commands open an in-browser editor.
nano notes.txt
06
Work with variables
Environment variables carry configuration into shells and containers.
export COURSE=containers && echo $COURSE
3
Useful shell command families
A compact map for daily use
Purpose
Commands
Typical question
Orientation
pwd, ls, tree
Where am I, and what is here?
Movement
cd
Which directory should be the working context?
Create
mkdir, touch, echo >
How do I create project inputs?
Read
cat, head, tail, grep
What is inside a file or output stream?
Change
cp, mv, rm, nano
How do I update or remove an object?
System
ps, env, id, uname
What process, environment, or identity am I using?
Knowledge check
Which command appends a second line without replacing the first?
Lesson 03 · Mental model
Understand what Docker creates—and what it does not
A container is a process with isolation and resource controls, not a miniature physical computer. Docker packages application files and metadata into images, then asks the engine to create runnable container instances from those images.
Distinguish image and containerFollow a run requestExplain layersCompare containers and VMs
An immutable template containing filesystem layers and metadata such as a default command, environment, and exposed ports.
CTR
Container
A runnable instance of an image with its own identity, process state, writable layer, network attachments, and mounts.
REG
Registry
A service that stores and distributes images. Docker Hub is one registry; organizations also operate private registries.
VOL
Volume
Storage managed separately from the container writable layer so important data can outlive an individual container.
2
Image layers and container state
Why rebuilding and replacing containers is normal
Read-only image layers
Dockerfile instructions generally add cacheable image layers. Multiple containers can share the same underlying image data while maintaining separate writable layers.
Ephemeral container layer
Changes made only in a container can disappear when the container is removed. Durable application data should normally use a volume or an external service.
3
Containers versus virtual machines
Both isolate workloads, but at different boundaries
Dimension
Container
Virtual machine
Kernel
Shares the host kernel through operating-system isolation mechanisms.
Runs a guest operating system and guest kernel on virtualized hardware.
Typical startup
Starts a process and its container configuration.
Boots a guest operating system.
Packaging
Application, runtime, libraries, configuration, and image metadata.
Guest OS plus applications and supporting components.
Security boundary
Useful isolation, but kernel sharing matters; hardening remains necessary.
Hypervisor boundary with a separate guest kernel; still requires hardening.
Best fit
Portable application deployment and scalable services.
Strong OS separation, different kernels, or full-machine workloads.
TRY
See image and engine information
Compare the image inventory with the engine summary.
docker images && docker info
Knowledge check
Which statement best describes a container?
Lesson 04 · Core operations
Manage the complete lifecycle of a container
A repeatable workflow is more valuable than memorizing isolated commands. Name containers, inspect their state, distinguish stopped from removed objects, and understand when the process inside determines container status.
Pull an imageRun detachedInterpret docker psStop and remove cleanly
1
Lifecycle states
The main process controls whether a container is running
Createdconfiguration exists
→
Runningmain process active
→
Exitedprocess ended
2
Guided lifecycle lab
Create a named web container and manage it deliberately
01
Pull the image explicitly
Pulling before a run separates image acquisition from container creation.
docker pull nginx:alpine
02
Run a named detached container
-d detaches the terminal; --name gives the object a readable identifier.
docker run -d --name web-lifecycle nginx:alpine
03
List running and all containers
Without -a, stopped containers are omitted.
docker ps
docker ps -a
04
Stop and start the same object
Stopping ends the process but preserves container configuration and writable state.
A stopped container still consumes metadata and may retain changes in its writable layer. Use docker ps -a to find it and docker rm to remove it. Use --rm on short-lived runs when automatic cleanup is appropriate.
Knowledge check
Why might docker ps appear empty immediately after running a command container?
Lesson 05 · Observability
Investigate containers instead of guessing
Operational troubleshooting starts with state, configuration, logs, process information, port mappings, and resource use. The Docker CLI exposes each of these views without requiring an interactive shell inside the container.
Read logsInspect configurationMap portsReview processes and resource use
1
Evidence sources
Choose the least intrusive command that answers the question
LOG
docker logs
Reads standard output and standard error captured from the container process.
JSON
docker inspect
Returns detailed configuration and runtime state, including mounts and networks.
CPU
docker stats
Shows a resource-use view such as CPU, memory, network, and process counts.
PID
docker top
Shows processes associated with the container from the host perspective.
2
Web-service investigation
Run a mapped service and examine it from several angles
01
Publish a host port
This maps host port 8080 to container port 80.
docker run -d --name web-demo -p 8080:80 nginx:alpine
02
Read startup logs
Logs can reveal configuration errors, crashes, and requests.
docker logs web-demo
03
Inspect low-level configuration
Find the image, command, state, environment, mounts, networks, and port bindings.
docker inspect web-demo
04
Confirm the port mapping
The host address is the entry point for the simulated HTTP request.
docker port web-demo
05
Test the service
curl uses the published host port. The Preview Ports button renders a browser-style view.
curl http://localhost:8080
06
Review resource and process views
This simulator produces stable teaching values rather than real measurements.
docker stats --no-stream web-demo && docker top web-demo
Knowledge check
Which command is generally the best first choice to see the complete configured port bindings and mounts?
Lesson 06 · Interactive troubleshooting
Enter a running container without confusing host and container
The docker exec command starts an additional process inside a running container. In this simulation, an interactive shell changes the prompt and routes file commands to that container until you type exit.
Recognize prompt contextUse docker execChange container filesCopy between host and container
Context mistakes are common
Before running a destructive file command, read the prompt and use pwd. A host path and a container path can have the same spelling but refer to different filesystems.
1
Interactive shell lab
Create a long-running container, enter it, and leave it safely
01
Start an Alpine container that stays alive
sleep 3600 becomes the main process.
docker run -d --name toolbox alpine:3.20 sleep 3600
02
Start an interactive shell
The prompt changes from student@container-lab to root@toolbox.
docker exec -it toolbox sh
03
Explore the container
These commands now operate on the container filesystem.
pwd && ls -la / && cat /etc/os-release
04
Create a troubleshooting note
This satisfies part of the interactive-shell mission.
echo "checked from inside" > /tmp/student-note.txt
cat /tmp/student-note.txt
05
Return to the host
exit ends the simulated exec shell but leaves the container running.
exit
06
Copy the note to the host
The colon separates a container name from its internal path.
Docker asks the runtime to start another process inside the existing container namespaces. A container does not need an SSH server for docker exec.
Minimal images may lack tools
Production images often omit shells, package managers, and diagnostic binaries. Troubleshooting plans should not assume every utility is installed.
Knowledge check
After entering docker exec -it toolbox sh, what does rm /tmp/file target?
Lesson 07 · Image construction
Build a reproducible image from a Dockerfile
A Dockerfile records the steps and metadata needed to create an image. The simulator includes a small web project at ~/projects/web-demo and implements common instructions such as FROM, RUN, WORKDIR, COPY, ENV, EXPOSE, and CMD.
Read a DockerfileUnderstand build contextTag an imageInspect image history
1
Common Dockerfile instructions
Each instruction has a distinct role
Instruction
Purpose
Example
FROM
Selects the base image for the build stage.
FROM nginx:alpine
RUN
Executes a build-time command and contributes a layer.
RUN mkdir -p /app
WORKDIR
Sets the working directory for later instructions and the default runtime context.
WORKDIR /app
COPY
Copies files from the build context into the image.
COPY index.html /site/
ENV
Defines an environment variable in the image metadata.
ENV APP_ENV=production
EXPOSE
Documents a port the application is expected to listen on.
EXPOSE 80
CMD
Defines a default runtime command; later runtime arguments can replace it.
CMD ["nginx","-g","daemon off;"]
EXPOSE does not publish a host port
It documents intended container ports. A runtime option such as -p 8081:80 creates the host-to-container mapping.
2
Guided image build
Inspect the project, build it, and run the result
01
Enter the build context
The final dot in docker build will refer to this directory.
cd ~/projects/web-demo && ls -la
02
Read the Dockerfile and application file
Never build a Dockerfile you have not reviewed.
cat Dockerfile && cat index.html
03
Build and tag the image
-t assigns a repository name and tag.
docker build -t student-web:1.0 .
Observe: the simulated build shows numbered steps, a resulting image ID, and a tag.
04
Inspect the image and layer history
History connects image metadata to Dockerfile instructions.
docker image inspect student-web:1.0
docker image history student-web:1.0
05
Run the custom image
Map host port 8081 to the image's web port.
docker run -d --name student-site -p 8081:80 student-web:1.0
curl http://localhost:8081
3
Build-quality habits
Practices to carry into a real environment
PIN
Choose bases deliberately
Use trusted sources and deliberate versioning. Smaller is not automatically safer; provenance and maintenance matter.
CTX
Control the context
Use a .dockerignore file in real projects to avoid sending secrets, build outputs, and unrelated files to the builder.
USR
Plan non-root runtime
Create or select an application user and avoid unnecessary privileges in the final runtime image.
Knowledge check
What does the final dot mean in docker build -t student-web:1.0 .?
Lesson 08 · Runtime configuration
Separate an image from the settings of one deployment
The same image can become many differently configured containers. Port publishing creates host entry points, while environment variables supply runtime settings without rebuilding the image.
Read port syntaxDetect conflictsPass environment valuesInspect effective configuration
1
Port publishing
Host port on the left; container port on the right
Browser or clientconnects to localhost
→
Host port 8090-p 8090:80
→
Container port 80service listener
Published versus exposed
EXPOSE 80 is image metadata. -p 8090:80 creates a host binding at runtime. A container service can also communicate over a Docker network without publishing a host port.
Host port conflicts
Two running containers cannot normally bind the same host address and port. This simulator detects duplicate host-port mappings.
2
Configuration lab
Run two instances from the same image with different settings
01
Run the first instance
Give the container a role label through an environment variable.
docker run -d --name blue-web -p 8090:80 -e SITE_ROLE=blue nginx:alpine
02
Run a second instance
The image is reused, but the container name, port, and environment differ.
docker run -d --name green-web -p 8091:80 -e SITE_ROLE=green nginx:alpine
03
Compare effective configuration
Use inspect and an exec command to read the environment.
docker inspect blue-web
docker exec green-web printenv SITE_ROLE
04
Test both host endpoints
Each host port routes to its corresponding container.
Do not treat plain environment variables as a universal secret store
Environment variables can be exposed through inspection, diagnostics, crash reporting, or process environments. In real systems, use an appropriate secrets mechanism and minimize secret lifetime and exposure.
Knowledge check
In -p 8090:80, which port is used by a client on the host?
Lesson 09 · Storage
Keep important data outside a replaceable container layer
Containers are often replaced during upgrades, scaling, or recovery. Named volumes provide a storage object with a lifecycle distinct from any one container. The simulator models volume mounts and preserves files written below the mount target.
Create and inspect volumesMount a volumeVerify persistenceAvoid accidental deletion
1
Three storage locations
Choose based on ownership and lifetime
RW
Container writable layer
Convenient for temporary changes, but coupled to that container. Removing the container removes this layer.
VOL
Named volume
Managed by Docker and mounted into one or more containers. It can remain after a container is removed.
BIND
Bind mount
Maps a specific host path. Useful for development and controlled host integration, but host path and permission behavior matter.
2
Persistence lab
Write through one container and read through a replacement
01
Create a named volume
The volume initially contains only its root directory.
docker volume create course-data
docker volume inspect course-data
02
Mount the volume at /data
The source name is on the left and the container path is on the right.
docker run -d --name writer -v course-data:/data alpine:3.20 sleep 3600
03
Write data through the mount
The file belongs to the volume, not only to the writer container.
docker exec writer sh -c "echo persistent-learning > /data/message.txt"
docker exec writer cat /data/message.txt
04
Remove the writer container
The volume is not removed by docker rm.
docker rm -f writer
docker volume ls
05
Read the same data from a replacement
A new container mounts the existing storage object.
docker run -d --name reader -v course-data:/data alpine:3.20 sleep 3600
docker exec reader cat /data/message.txt
Observe: the replacement reads persistent-learning, demonstrating a lifecycle independent of the removed container.
Volume deletion is a data operation
docker volume rm and pruning can permanently remove application data in a real environment. Confirm ownership, backups, and active mounts before cleanup.
Knowledge check
Which event removes the data in a named volume?
Lesson 10 · Networking
Connect containers without publishing every service
A user-defined Docker network gives containers a shared communication domain and name-based discovery. A backend service can remain reachable to peer containers without being exposed on a host port.
Create a bridge networkAttach containersUse service namesSeparate internal and external access
1
Two different access paths
Host publishing and container-to-container networking solve different problems
Host clientlocalhost:8082
→
frontendpublished port 80
↔
cacheinternal port 6379 only
2
Custom-network lab
Create two containers and verify name-based reachability
01
Create a network
User-defined bridge networks support convenient container-name resolution.
docker network create lab-net
docker network ls
02
Run a web service on the network
The host port is optional for peer communication, but useful for testing from the host.
docker run -d --name frontend --network lab-net -p 8082:80 nginx:alpine
03
Run a peer toolbox
No host port is needed for this troubleshooting container.
docker run -d --name net-tool --network lab-net alpine:3.20 sleep 3600
04
Resolve the service by container name
The simulated ping succeeds only when running containers share a suitable network.
Container addresses can change when objects are recreated. Name-based discovery expresses intent and works naturally with Compose service names.
Network membership is connectivity, not authorization
Applications still need authentication, encryption where appropriate, least privilege, and input validation. A private network alone is not a complete security control.
Knowledge check
Must the cache container publish port 6379 to the host for the frontend container to reach it on the same Docker network?
Lesson 11 · Multi-container applications
Replace a long sequence of run commands with a declarative model
Docker Compose reads a YAML file that describes services, images or builds, ports, environment, volumes, and networks. The included project at ~/projects/compose-demo defines a web service and a cache service.
Read Compose YAMLStart a projectInspect service status and logsTear down project resources
1
Included Compose model
Services become containers connected through project networks
Operate the project from the directory containing the model
01
Open and validate the project
docker compose config renders the interpreted configuration. The simulation displays the source model.
cd ~/projects/compose-demo && cat compose.yaml
docker compose config
02
Start all services
-d starts the project in detached mode.
docker compose up -d
03
Review project status
Compose groups related containers by project and service.
docker compose ps
docker compose logs
04
Test the web service
The model publishes port 8088 from the web service.
curl http://localhost:8088
05
Remove project containers and network
down reverses the project creation. Add -v only when you intentionally want project volumes removed.
docker compose down
This is a teaching subset of Compose
The simulator parses the included project's common service, image, port, network, environment, and volume patterns. Real Compose supports a much larger specification and platform-dependent behavior.
Knowledge check
What is the main advantage of the Compose model in this lesson?
Lesson 12 · Security
Treat containers as a security boundary that still needs defense in depth
Containers improve packaging and process isolation, but they do not make vulnerable code safe. Image provenance, minimal privileges, restricted resources, controlled mounts, network policy, secrets handling, patching, logging, and host security all remain important.
Run as non-rootUse read-only filesystemsSet resource limitsReview image and runtime risk
1
Defense-in-depth checklist
Questions to ask before deployment
SRC
Image source
Is the image from a trusted source? Is the tag or digest deliberate? Is it maintained and scanned?
UID
Identity
Does the process need root? Are Linux capabilities and host privileges minimized?
RO
Filesystem
Can the root filesystem be read-only? Are writable paths limited to specific volumes or temporary storage?
LIM
Resources
Are CPU, memory, process, and storage limits appropriate to contain failures or abuse?
NET
Connectivity
Are only required ports published? Are internal services separated and authenticated?
SEC
Secrets and logging
Are secrets supplied through an appropriate mechanism, and do logs avoid leaking them?
2
Hardened runtime exercise
Model a constrained container and inspect the result
01
Run with a non-root user, read-only root, and limits
The simulator records these controls and enforces the read-only flag for unmounted writes.
Review user, read-only setting, and host resource configuration.
docker inspect secure-tool
03
Test the read-only root filesystem
The write should be denied because /tmp is not separately mounted in this model.
docker exec secure-tool sh -c "echo test > /tmp/test.txt"
04
Review the simulated resource view
Limits appear alongside current usage.
docker stats --no-stream secure-tool
A privileged container can be exceptionally dangerous
Options such as --privileged, broad device access, host PID/network namespaces, or mounting the Docker socket can erode isolation and expose the host. This simulator intentionally does not implement privileged execution.
Knowledge check
Which control most directly reduces the effect of a process trying to modify its packaged application files?
Lesson 13 · Diagnosis
Use a repeatable troubleshooting sequence
Container failures become easier when you separate image problems, process problems, configuration problems, network problems, storage problems, and host constraints. Start with observable state and narrow the scope before changing anything.
Classify a symptomCollect evidenceAvoid destructive first stepsUse cleanup carefully
1
Seven-question sequence
A practical order for investigation
1
Does the object exist?
Use docker ps -a, docker images, and the exact name or ID.
2
What state is it in?
Running, exited, paused, restarting, or absent each suggest different next steps.
3
What did the main process report?
Read docker logs and the exit code from docker inspect.
4
Does effective configuration match intent?
Inspect command, environment, user, mounts, resource limits, networks, and port bindings.
5
Is the application actually listening?
Review processes and sockets, then distinguish internal service ports from host-published ports.
6
Can dependencies be resolved and reached?
Check shared networks, service names, credentials, and application-level protocol behavior.
7
Is persistent data mounted and permitted correctly?
Inspect mounts and test access without deleting or reinitializing data.
2
Common symptom map
Use the symptom to choose the first evidence source
Symptom
Likely categories
First commands
Container exits immediately
Main command completed, crash, invalid configuration, missing dependency
docker ps -a, docker logs NAME, docker inspect NAME
Port does not respond
Container stopped, port not published, wrong mapping, app not listening
docker ps, docker port NAME, docker logs NAME
Service name not resolved
Different networks, stopped peer, incorrect name
docker network inspect NET, docker inspect NAME
Data disappeared
Written to container layer, wrong mount, volume removed, application initialized a new path
Runtime user, ownership, read-only filesystem, mount permissions
docker inspect NAME, docker exec NAME id, docker exec NAME ls -la PATH
Name already in use
Stopped or running container retains the requested name
docker ps -a, then rename or remove intentionally
3
Safe cleanup exercise
Review before pruning
01
Measure the simulated footprint
Use the system summary before changing resources.
docker system df
02
List stopped containers explicitly
Do not assume every stopped object is disposable.
docker ps -a
03
Use prune only after review
The simulator asks for confirmation before removing stopped containers and unused custom networks.
docker system prune
Knowledge check
A container is absent from docker ps. What should you do next?
Lesson 14 · Capstone
Deploy, investigate, protect, and remove a small container application
The capstone combines shell navigation, image building, runtime configuration, networking, persistent storage, observability, and cleanup. Complete it from the requirements rather than copying one long command sequence.
Translate requirements into commandsVerify every assumptionDocument evidenceTransition to official labs
1
Capstone scenario
A controlled deployment task for a student operator
Student Site Deployment
You have been asked to deploy a static training site and a diagnostic companion container. The web service must use your built image, preserve an operator note in a named volume, join a dedicated network, publish host port 8085, and be verifiable from both the host and its peer.
Build student-web:1.0 from ~/projects/web-demo.
Create a network named capstone-net and a volume named capstone-data.
Run capstone-web from the built image with -p 8085:80, mount the volume at /data, and join the network.
Run capstone-tool from Alpine on the same network with a long-running command.
Write an operator note to /data/operator.txt in the web container.
Use logs, inspect, port, stats, and network inspect to document the deployment.
From the host, request http://localhost:8085. From the peer, request http://capstone-web.
Remove both containers and the custom network, but retain and verify the named volume.
A browser-accessible Docker playground for moving from simulation to commands against a real temporary Docker environment. Availability and access requirements can change.
Hands-on transition
Before using a real Docker environment
Review every command, understand the privileges of the Docker daemon or desktop runtime, avoid untrusted images, do not paste secrets into terminals or Dockerfiles, and treat deletion and pruning commands as potentially destructive.
Final knowledge check
Which sequence reflects sound container operations?
Virtual File Editor
Edit a file in the current simulated filesystem.
Container Lab Command Sheet
Commands implemented by this educational simulator.
Shell and files
pwd · ls [-la] · cd · treemkdir [-p] · touch · catecho · > · >> · grep · head · tail · wccp · mv · rm [-rf] · nano · vienv · export · printenv · history