Practice Linux, Docker and kubectl in Your Browser, No VM Required

Reading about chmod is not the same as typing it. Everyone who learned the terminal knows this, and everyone who teaches it says the same thing: you learn the command line in your fingers, not your eyes.

The usual advice is "spin up a VM and practice". That advice loses half the audience at the word VM. Downloading VirtualBox, finding an Ubuntu ISO, allocating RAM on a laptop that has none to spare: that is a full evening of setup before the first ls. For Docker and Kubernetes the setup tax is worse. A realistic kubectl playground means a cluster, and nobody's first contact with Kubernetes should be debugging why minikube will not start.

There is a simpler on-ramp: simulated terminals that run entirely in the browser. Nothing to install, nothing to break, and when you do break something, refresh the page. Below is a three-stage practice path using free browser simulators, with the exact commands worth drilling at each stage. Each stage takes an evening.

Stage 1: the shell itself

Before containers make sense, the shell has to be boring. That means the core loop of navigating, creating, inspecting and searching files should happen without thinking.

The Linux Terminal Simulator gives you a simulated shell with guided lessons, no signup. It covers six areas: navigation basics, file operations, viewing and searching, permissions and ownership, system information, and pipes and redirection.

The commands worth drilling until they are automatic:

pwd                     # where am I
ls -la                  # what is here, including hidden files
cd /var/log             # go somewhere absolute
cd ..                   # go up one level
mkdir -p app/config     # create nested directories
cp config.yml backup/   # copy
mv old.txt new.txt      # rename is just move
rm -r build/            # delete a directory tree

Then the inspection set, which is what you will actually use at work:

cat /etc/hostname            # print a whole file
head -n 20 app.log           # first 20 lines
tail -n 50 app.log           # last 50 lines, where the errors are
grep ERROR app.log           # find the errors
grep -r "timeout" ./config   # search a whole directory
find . -name "*.yml"         # find files by name

The stage-1 graduation exercise is pipes, because pipes are the moment the shell stops being a list of commands and becomes a language:

grep ERROR app.log | wc -l        # how many errors
grep ' 500 ' access.log | tail    # the most recent 500s

If you can predict what each of those prints before pressing enter, stage 1 is done.

One caveat about simulators: they are a subset of a real system. The simulator above supports a couple dozen core commands, which is the point at this stage. A real shell offers you thousands of ways to get lost; a training shell offers the small set of commands you will actually type every day. Graduate to a real machine once those feel automatic: any cheap VPS or WSL on Windows works, and the core syntax and concepts transfer directly.

Stage 2: containers

Docker's CLI is the shell pattern again, one level up: instead of files you manage images and containers. If stage 1 is comfortable, stage 2 is mostly learning which noun goes with which verb.

The Docker Terminal Simulator runs the same guided-lesson format against a simulated Docker daemon: lifecycle, debugging, building images, volumes and networks, and a Compose workflow at the end.

The lifecycle loop to drill first:

docker pull nginx           # get an image
docker images               # what do I have locally
docker run -d -p 8080:80 nginx   # run it, mapped to a port
docker ps                   # what is running
docker stop <id>            # stop it
docker rm <id>              # remove the container

Then the debugging pair that answers most "my container is broken" questions:

docker logs <id>            # what did it print
docker exec -it <id> sh     # get a shell inside it

docker logs plus docker exec is the container equivalent of tail plus cd: they are the first two commands to reach for when a container misbehaves. The simulator's debugging lesson makes you use them to find an actual failure, which is the right way around: learn the command by needing it.

Round out the stage with images and state:

docker build -t myapp .     # build from a Dockerfile
docker history myapp        # what layers did that create
docker volume ls            # list volumes (persistent data)
docker network ls           # list networks
docker network inspect bridge   # who is attached to a network

The layer model behind docker history is worth a detour on its own, because layers explain both why builds are fast the second time and why images bloat. But that is a topic for after the muscle memory.

Stage 3: Kubernetes, or, kubectl without a cluster

Here the setup tax is normally highest and the browser option pays off most. Real Kubernetes needs a cluster even to practice kubectl get pods. Local tools like kind and k3d have made that much quicker than it used to be, but it is still setup before the first command, and the failure modes of a half-configured local cluster are a rough first impression.

The Kubernetes Terminal Simulator puts you in front of a simulated cluster that responds to kubectl: cluster basics, pods and deployments, services and networking, scaling and rollouts, debugging workloads, and config cleanup.

The reading set comes first, because most real kubectl usage is reading:

kubectl cluster-info                 # is there a cluster
kubectl get pods                     # what is running
kubectl get deployments              # what is managing what
kubectl describe pod <name>          # everything about one pod
kubectl logs <name>                  # the pod's output

Notice the shape repeating: get is ls, describe is a verbose cat, logs is docker logs. The three stages of this path are the same five verbs wearing different uniforms, which is why learning them in order works.

Then the mutation set:

kubectl create deployment web --image=nginx
kubectl scale deployment web --replicas=3
kubectl expose deployment web --port=80
kubectl rollout status deployment web
kubectl set image deployment/web nginx=nginx:1.27   # ship a new version
kubectl rollout undo deployment web                 # take it back
kubectl delete service web
kubectl delete deployment web

rollout undo is the one to internalize. The first time a bad deploy needs reverting in production is a bad time to learn it, and it is the command a simulator lets you practice consequence-free.

Why this order works

Each stage reuses the previous one. Docker's CLI assumes you can read a shell; Kubernetes assumes containers make sense. Skipping ahead is why Kubernetes has a reputation for being impossible: kubectl exec is baffling if docker exec is baffling, and docker exec is baffling if a shell is baffling. Taken in order, each stage is one new idea instead of three.

The browser simulators remove the two things that usually end self-study before it starts: setup friction and fear of breaking something. What they deliberately do not give you is the full mess of a real system, so the workflow that works is: drill in the simulator until the commands are automatic, then move to a real machine, a real Docker daemon, and eventually a real (managed) cluster, carrying the muscle memory with you.

All three simulators are free and run without an account, part of a larger set of 50+ DevOps games and simulators covering everything from SQL terminals to DNS resolution. (Disclosure: I help build them.) If you outgrow simulators and want real environments in the browser, KillerCoda and OverTheWire are the natural next steps.

An evening per stage, and the terminal stops being the scary part of DevOps.