docker_practice: the Chinese Docker book you can read, build and run yourself

What docker_practice actually is, and who it is written for

The repository is a book, not a library. Its README describes it as covering Docker and container technologies from zero, aimed at readers with basic Linux knowledge and also at advanced users who want the underlying implementation. The chapters are numbered directories in the repository root, starting at 01_introduction and running through 21_case_devops, which makes the table of contents visible from a plain directory listing rather than only from the rendered site.

The README splits the material into four bands. Chapters 1 to 6 cover images, containers and registries. Chapters 7 to 11 cover Dockerfile instructions, data and network management, Buildx and Compose. Chapters 12 to 17 go into implementation details and orchestration with Kubernetes and Etcd, plus ecosystem projects such as Fedora CoreOS and Podman. Chapters 18 to 21 cover container security, monitoring and log aggregation with Prometheus and ELK, and case studies for operating systems and CI/CD.

The README also maps reader roles onto chapter ranges: operations beginners get chapters 1 to 6, developers get 1 to 8 then 11, DevOps engineers get 1 to 11 then 13 to 14 then 18 to 21, and architects get 1 to 6 then 12 to 17 then 18 to 19. That routing table is the most useful thing on the page. It tells you the book expects you to skip, not read linearly.

How the book is structured as a repository

Each chapter is a directory of Markdown, and SUMMARY.md holds the reading order. The repository ships a book.json and a _config.yml, which are the configuration files for the GitBook-style tooling, plus a package.json whose scripts drive the build. The package.json declares the project private and versioned at 1.9.2, with a single devDependency on @mermaid-js/mermaid-cli at 11.16.0, so diagrams in the text are rendered by Mermaid rather than stored as images.

The scripts are where the maintenance cost lives. The test script chains a Node metadata check, a Python unittest module for PDF source preparation, a unittest discovery run over the tests directory, and a Python example validator. That means a content change touches Markdown, metadata, and possibly the example validation fixtures. The repository also carries check_emphasis.py and check_project_rules.py at the root, which are style checks over the prose itself.

There is a docker-compose.yml with three services. mdpress-build uses the image yeasy/docker_practice:latest, mounts the repository at /srv/gitbook-src, and runs the build command. mdpress-server reuses that service definition through a YAML anchor, publishes port 4000, and runs server. mdpress-offline uses dockerpracticesig/docker_practice:mdpress, built by a GitHub Action, and maps port 4000 to port 80 inside the container. A comment in that file gives the equivalent one-liner: docker run -it --rm -p 4000:80 dockerpracticesig/docker_practice.

Installing mdPress and serving the book locally

The README's local reading instructions do not install Docker at all. They install mdPress, the author's own static site tool, and then serve the repository. On macOS the README gives a Homebrew tap and install:

brew tap yeasy/tap && brew install mdpress
mdpress serve

After mdpress serve, the README implies you read the book from a local server rather than from the GitBook site. The package.json exposes the same operation under two other names, npm run serve and npm run start, so you can skip the global install if you prefer to run it through the project's own scripts.

If you would rather not install mdPress on the host, the compose file gives a container path. The mdpress-offline service runs a prebuilt image and publishes the site on port 4000:

docker compose up mdpress-offline

The compose file maps 4000 on the host to 80 in the container. You should then see the rendered book at http://localhost:4000. The alternative one-liner from the compose comment does the same thing without compose:

docker run -it --rm -p 4000:80 dockerpracticesig/docker_practice

For offline reading without any tooling, the README points at GitHub Releases for the PDF, and at a preview PDF at releases/download/preview-pdf/docker_practice.pdf. The README states plainly that the preview file is overwritten as the main branch updates and does not represent a formal release, so treat the tagged release as the stable artifact.

Where the book stops being the right tool

The most obvious limitation is language. The repository, README, chapter directories and release notes are in Chinese. The topics list and the badges are in English, and the code samples are universal, but the explanatory prose is not. An engineer who cannot read Chinese gets a table of contents and a lot of fenced commands, which is a thin return on a book-length document.

A second limitation is that it is a book. Nothing here provisions containers for you. There is no CLI, no daemon, no library to import. If your actual need is a browser-based Docker environment to practice commands in, this repository does not provide one; the closest it gets is instructions for running the book itself in a container, which is a different thing from running Docker exercises. The README's five-minute path is a reading path, not a sandbox.

A third issue is version drift. The README badge claims the book is based on Docker Engine v29.x, and the release history shows v1.11.0 tagged on 2026-07-04 and v1.10.0 on 2026-05-31. The last push to the repository was on 2026-09-16, so the book is still being edited. But chapter text and a badge can diverge: a chapter on Compose or Buildx written for an earlier engine may still read correctly while a flag has changed. The repository does not publish a per-chapter compatibility matrix, so the badge is a claim about the book as a whole, not a guarantee for the page you are on. Verify flags against the Docker Engine release notes the badge links to before copying them into a pipeline.

How it compares with the official Docker documentation

The official Docker documentation is the reference implementation of Docker knowledge: it is maintained by the vendor, it is in English, and it is versioned alongside the engine. It is also organized by product surface, so a reader who wants a single narrative from docker run to Kubernetes concepts has to assemble that path themselves.

docker_practice takes the opposite approach. It is a single authored narrative with an explicit reading order and role-based routes, and it is free to redistribute under CC BY-NC-SA 4.0, which the official docs are not. That licence is the practical difference for a teacher or a study group: you can share and adapt the book with attribution, non-commercially, under the same terms. You cannot do that with vendor documentation.

The trade-off is authority and latency. When Docker changes a default or deprecates a flag, the vendor docs change with the release. Here, the change has to be noticed, written, reviewed against the repository's own test scripts, and pushed. The repository has tooling for that, including an example validator and a PDF source preparation step, which suggests the maintainers care about correctness. It still is not the same as a vendor changelog.

Licence, maintenance and the cost of keeping a fork current

The README and package.json both state CC BY-NC-SA 4.0. The README summarizes the terms: share and adapt freely, with attribution, non-commercial use, and share-alike. For most readers that is a non-issue. For a company that wants to print the book into internal training material, the non-commercial clause is the constraint to read carefully, and the share-alike clause means a modified version carries the same licence. This is a description of the licence text, not legal advice; if the material is going into a paid product, talk to someone qualified.

Maintenance looks active by the only measure available here: the last push was on 2026-09-16, five days before this writing, and the release history shows v1.11.0 on 2026-07-04. The repository is not archived. Upgrading your own copy is cheap if you only read it: pull the branch, or download the newest PDF from Releases. It gets more expensive if you build it, because the build path has real dependencies. The test script needs Node for the metadata check, Python 3 for the unittest suites and the example validator, and Mermaid CLI for diagrams. The PDF script additionally prepares sources into a temporary directory before invoking mdpress build with the pdf format.

If you fork the book to localize or extend it, budget for the style checks. check_emphasis.py and check_project_rules.py exist precisely because prose rules are enforced mechanically, so contributions that ignore them will fail before a human reads them.

Editorial conclusion

Adopt docker_practice if you need a structured, book-length path from docker run to Kubernetes concepts and want it in Chinese, offline, and free to share under CC BY-NC-SA 4.0. Do not adopt it if you need an English-language reference, a runnable lab environment, or a source that tracks Docker Engine releases faster than its chapter revisions. Before relying on it, verify the chapter you care about against the Docker Engine v29.x release notes it claims to follow, and check whether the preview PDF or the tagged release matches the branch you are reading.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yeasy/docker_practice on GitHub