A Docker workstation involves more than the docker version command
The training programme should state the versions of Docker Engine, Compose, Buildx and any add-ons used. The host operating system, kernel, cgroups and storage driver matter as well. Two computers with a similar client can behave differently if one runs native Linux and the other goes through a virtualisation layer.
A separate Linux VM simplifies this model. Every participant gets the same daemon, file system and network configuration. Commands from the material then lead to comparable results, and the instructor does not have to support several variants of Docker Desktop.
Images and dependencies have to be prepared before the session
A group pulling large images at the same time can overload the connection and run into public registry limits. It is worth pulling the base images used in the exercises in advance, or making them available through a controlled repository. Their tags should point to specific versions, not to a moving latest.
An image-building exercise should still do real work. Preparing in advance does not mean handing over a finished result, but removing the dependence on whatever the network happens to be doing. If the material requires packages, check the repositories and the cache under conditions similar to those on the day of the training.
Disk space runs out faster than the project size suggests
Image layers, the build cache, volumes and logs grow with each attempt. The VM profile should allow for several builds as well as the data used by the services. Before the session, it is worth running the whole scenario and checking actual usage with docker system df.
Automatic clean-up run at the wrong moment can delete artefacts needed for comparison. It is better to plan clean-up points between exercises and explain what a given command removes. The participant should be able to tell apart a stopped container, an image, the cache and a volume.
Networks and volumes need an observable scenario
With Compose, you can prepare an application, a database and an auxiliary service, and then demonstrate name resolution, port publishing and communication within the network. It is worth deliberately introducing a wrong port or a faulty healthcheck so that the participant uses logs, inspection and service status to diagnose the problem.
A volume should contain data whose loss becomes visible after a restart. That way, the difference between writing to the container layer and persistent storage does not stay abstract. An exercise reset must state explicitly whether it keeps the volumes or deletes them along with the environment.
Access to the daemon means broad privileges
A user in the docker group can, in practice, obtain elevated privileges on the host. That is why the lab should run on private, temporary VMs rather than on a shared server holding important data. Participants should not be given credentials for a production registry or cluster.
Secrets used by the sample application must be fictitious or have a limited scope. They should not be stored in the image or in a build layer. This is a good opportunity to show the difference between a build argument, an environment variable and a mechanism designed for passing secrets.
Kubernetes requires a separate lab design
Knowing images and containers helps when learning Kubernetes, but a cluster introduces a control plane, nodes, storage, DNS, Ingress and a permission model. Adding a local cluster to the tail end of a Docker workshop does not always leave enough time to understand these components.
If Kubernetes is part of the programme, you need to decide whether participants work in a shared cluster with separate namespaces or on separate clusters. Each option has different resource and isolation requirements. An example topology is described in the Kubernetes training scenario.
The base image should go through all the material before it is replicated
The test covers a build without using the instructor's private cache, starting Compose, healthchecks, network communication, writing to a volume and clean-up. Every step should be carried out from a participant account. Only then does the configuration become the basis for the group.
Ready-made machines for IT training let you keep the freedom to work with the daemon separate from company laptops. After the workshop, it is worth keeping the Dockerfiles, Compose files and notes, and deleting the VMs themselves and the temporary credentials on the agreed date.