jpetazzo/container.training: the repo behind the Docker and Kubernetes workshops

What container.training actually is, and who it is for

This repository, formerly named orchestration-workshop, is a collection of materials used for workshops, tutorials and training sessions about Docker, containers and orchestration. The README lists three courses: Introduction to Docker and Containers, Container Orchestration with Docker Swarm, and Container Orchestration with Kubernetes. The stated design principles are that the material assumes very little prior knowledge of Docker, containers or any particular programming language, that it works both in a classroom with an instructor and self-paced at home, and that the chapters build on each other.

The audience is therefore narrow and specific. If you are the person who has to stand in front of twenty engineers and explain why a container is not a virtual machine, this repository is aimed at you. If you are looking for a Go library to embed a container runtime, you are in the wrong place, and no amount of reading will change that. The README even tells readers who only want the material to stop reading and go to http://container.training/, which hosts the slide decks.

The DockerCoins demo app is the spine of the orchestration workshops

Everything in the orchestration courses hangs off a sample application called DockerCoins, kept in the dockercoins directory. The README describes it as a micro-services application: it is first run on a single node with Docker Compose, then the workshop pretends the app needs to scale and moves it onto a cluster managed by SwarmKit or Kubernetes. Only after that do the chapters cover scaling, load balancing, updates, and global services or daemon sets.

That ordering is the actual pedagogical mechanism. A reader meets Compose first, feels the limits of a single node, and only then is handed an orchestrator as the answer. It is a deliberate build-up rather than a feature tour, and it is why the material is split into many Markdown files assembled according to a YAML manifest. The README says this modularity exists so content can be reused between different workshops, and the shared slides in slides/shared/ are updated identically across decks. The trade-off is real: reusing a chapter means inheriting its assumptions about what the audience has already seen.

Installing nothing: running the workshop material locally

There is no package to install here. The README points readers who want the slides at http://container.training/, and the repository is the source those decks are built from. The one concrete runnable artifact the README documents is the demo app, and it gives the commands directly.

Change into the dockercoins directory and bring the stack up in detached mode:

cd dockercoins && docker-compose up -d

The README states that this builds and starts all the services, and that the web UI will be available on port 8000. Nothing else in the repository is presented as a first-run experience. The bin directory is described as helper scripts you can safely ignore for now, and prepare-local and prepare-machine are described as contributed scripts to automate local environments that could use help being tested.

If you want to deliver a workshop rather than just read it, the README's own guidance is to fork the repository and run through the slides yourself, doing the hands-on exercises, then update the first few slides and the last slide with your own information. It also says the workshop expects five servers per student, and that you can get away with as few as two if you change the slide deck to accommodate.

The build and test tooling is where the maintenance cost sits

The reason these materials live in one repository is stated plainly: shared slides, a build system that generates HTML slides from Markdown, a semi-automated test harness in slides/autopilot/ to check that the exercises work, a PhantomJS script at slides/slidechecker.js to check that slides render without formatting problems, deployment scripts in prepare-vms/ to start training VMs in bulk, and a Netlify pipeline that continuously deploys to http://container.training/.

That is a lot of moving parts for teaching material, and it is the honest cost of adopting it. A PhantomJS-based slide checker is a dependency you inherit and will eventually have to replace or remove. The README is candid about uneven maintenance across the repository: the Docker introduction is described as still maintained but receiving only minor updates once in a while, while the Swarm and Kubernetes workshops are described as actively maintained. The prepare-labs scripts are described as routinely used and actively maintained, whereas prepare-local and prepare-machine are flagged as needing help to verify they work. Read those labels as a map of where breakage is most likely.

The repository is not archived, and the last push was on 2026-09-16.

Where container.training is the wrong tool

The clearest failure mode is expecting a supported product. There are no retrieved releases, so there is no versioned artifact to pin, no changelog to read before an upgrade, and no compatibility contract. If your platform team wants a dependency with a semver range and a security response process, this repository does not offer one.

The second limitation is environmental. The classroom path assumes you can provision machines in bulk; the README names AWS as the most tested process for generating student machines and warns that you should test creating all your needed servers a week before the workshop, because you will likely hit AWS limits in the region closest to your class and raising those limits through a support ticket sometimes takes days. That is not a footnote. It is a scheduling constraint that can sink a training date.

Third, the material assumes a specific cluster shape. Five servers per student is the default expectation, and dropping to two means editing the deck. If you cannot change the slides, you cannot shrink the lab. Finally, the Kubernetes workshop uses pre-configured clusters rather than having students build a cluster from scratch, so anyone hoping to teach cluster installation from this deck alone will need to look elsewhere.

Alternatives, and what changes if you pick one

The README itself points to jpetazzo/intro-to-docker as the origin of the Introduction to Docker course, noting that the version in this repository was adapted to the Markdown publishing pipeline. Choosing between them is a choice about tooling rather than content: the standalone repository is the older lineage, and container.training is the one wired into the shared-slides build and the Netlify deployment.

For the orchestration half, the meaningful alternative is official documentation and vendor tutorials. The difference in approach is structural. Official docs are reference material organized by feature, written to be correct for a specific version and updated as that version changes. This repository is organized by narrative: a demo app, a scaling problem, then an orchestrator as the solution. Reference material answers a question you already have; this material tries to create the question first. That makes it better for a room of beginners and worse for an engineer who needs the exact flag for the version they are running. It also means the decks age differently from the software they describe, which is why the README's distinction between the actively maintained orchestration workshops and the occasionally updated Docker introduction matters.

Licence and what to verify before you teach from it

The repository is distributed under a licence that GitHub reports as NOASSERTION, meaning the platform could not map the LICENSE file to a known identifier. The README does not discuss licensing terms for reuse of the slides, and the LICENSE file is the only authoritative source. Before you fork the deck, rebrand the first and last slides as the README instructs, and deliver it to a paying audience, read that file and decide whether your use is covered. This is not legal advice, and the repository text does not resolve the question for you.

On upgrades, there is nothing to upgrade in the usual sense. You fork, you edit Markdown, and you rebuild. Your maintenance burden is therefore the build chain (the Python script that assembles slides, gnab/remark for rendering, the PhantomJS slide checker) plus the demo app's images. If you only consume the published decks at http://container.training/, none of that touches you.

Editorial conclusion

Adopt it if you are teaching containers and want a modular deck plus a demo app you can rebuild locally; the last push was on 2026-09-16 and the README states the Swarm and Kubernetes workshops are actively maintained while the Docker introduction only receives minor updates. Do not adopt it if you want a supported library with versioned releases, an API to call or a package to install: there are none. Before committing to a delivery date, verify the two things the README leaves open, namely which course you will actually run and whether your cluster size matches the five servers per student the material assumes.

Frequently asked questions

Official sources

1. Issues
2. jpetazzo/container.training on GitHub
3. Project website
4. README