A practical Docker course for PHP developers who want to do more than just run containers: understand the environment model, build a reproducible stack, connect the IDE, diagnose failures, and maintain local infrastructure as part of the engineering system. The course examples are validated on Docker Engine 29.1.3.
Published version: modules, lessons, and duration.
After the lesson, the student understands how to describe `app`, `postgres`, and `redis` in one Compose stack, why a service name differs from `container_name`, why environment must be explicit, and how `docker compose config` helps verify the final shape of the local environment.
After the lesson, the student understands why `depends_on` alone does not guarantee readiness, how a healthcheck makes a dependency more reliable, why restart policy must be chosen deliberately, and how to reason about init or one-shot services without the false assumption that every container must run forever.
After the lesson, the student understands how to split a stack into internal and external networks, why `postgres` and `redis` usually should not receive published ports, how the application resolves dependencies through service-name DNS, and why excessive port publishing adds noise and risk.
After the lesson, the student understands the difference between a named volume and a bind mount, knows where project code should live, where the database should persist, why a read-only mount is sometimes useful, and how a weak mount strategy quickly harms both performance and reproducibility.
After the lesson, the student understands what `UID/GID` means, why a container may create "foreign-owned" files on the host, how to align the container user through `user`, build args, or environment parameters, and why solving the problem with `777` is not a solution but a degraded security model.
A deliberate external boundary for the local stack: one edge, localho.st domains, Traefik, and local HTTPS without magic.
Goal: Show why a local environment should have one external entry point and why domains express product structure better than a pile of published ports. Outcome: After the lesson, the student understands why `app:8080`, `api:8081`, and `admin:8082` form a weak external model, why a single edge is useful, and why the `*.localho.st` zone is convenient for local development with multiple web entry points.
Goal: Teach the student to read and write the core Traefik configuration in `Compose`: the Docker provider, entrypoints, routers, services, labels, and network selection. Outcome: After the lesson, the student understands how `Traefik` discovers services through the Docker provider, why `exposedByDefault=false` is safer, how labels become routing rules, and why `traefik.docker.network` sometimes must be specified explicitly.
Goal: Give the student a working model of local `HTTPS` through `Traefik`: `websecure`, certificates, a redirect from `web` to `websecure`, and basic diagnostics for broken domain routing. Outcome: After the lesson, the student understands that local `HTTPS` is part of a reproducible environment, can connect self-signed certificates to Traefik, knows how to verify a domain with `curl`, and does not confuse DNS, router-rule, and TLS problems.
Logs, readiness, restart policies, resource limits, and safe maintenance for the local Docker environment.
Goal: Teach the student not to panic when a container fails: first inspect the logs, then verify the process state, and only then enter the container. Outcome: After the lesson, the student understands the difference between logs and interactive access, does not use `docker exec` as the first reaction to every issue, and can produce a short diagnostic report for a container.
Goal: Teach the student to distinguish process start, service readiness, and automatic restart as three different ideas. Outcome: After the lesson, the student understands that `depends_on` does not guarantee readiness, that a healthcheck exists to signal state, and that `restart` does not fix broken configuration.
Goal: Teach the student to see the local Docker environment as a consumer of host CPU and memory rather than as a free abstract sandbox. Outcome: After the lesson, the student understands why resource-hungry containers should be constrained, how to read basic signs of resource pressure, and why even a laptop-based local environment needs a resource budget.
Goal: Teach the student to clean a Docker environment selectively and safely: understanding the difference between image cleanup, build-cache cleanup, and the risk of deleting useful data. Outcome: After the lesson, the student understands that `docker system prune -a` should not be the first reaction, can explain the difference between dangling images and data-bearing volumes, and knows how to clean build cache separately.
After the lesson, the student understands why the IDE connects to Docker at all, which problems this solves, and why a mismatch between the IDE and the container environment destroys predictability.
After the lesson, the student understands why a remote interpreter is needed, why Composer and tests should go through it, and how interpreter mismatch destroys trust in the IDE's results.
After the lesson, the student understands that Xdebug is not "enable the extension and hope"; it is a combination of container configuration, an IDE listener, and correct path mapping.
After the lesson, the student understands why a consistent project structure accelerates onboarding, reduces chaos, and keeps the environment readable for the whole team.
After the lesson, the student understands that environment as code requires documentation, `.env.example`, onboarding artifacts, and a reproducible workflow for other developers.