Практический курс по Docker для PHP-разработчика, который хочет не просто запускать контейнеры, а понимать модель среды, собирать воспроизводимый стек, подключать IDE, диагностировать проблемы и поддерживать локальную инфраструктуру как часть инженерной системы. Примеры курса валидируются на Docker Engine 29.1.3.
Опубликованная версия: модули, уроки и длительность
После урока студент понимает, как описывать сервисы `app`, `postgres`, `redis` в одном Compose-стеке, зачем отличать service name от `container_name`, почему environment должен быть явным и как через `docker compose config` проверять итоговую форму локальной среды.
После урока студент понимает, почему `depends_on` сам по себе не гарантирует readiness, как healthcheck превращает сервис в более надежную зависимость, зачем выбирать restart-политику осмысленно и как смотреть на init- и one-shot-сервисы без ложной модели "все контейнеры должны жить вечно".
После урока студент понимает, как делить стек на внутренние и внешние сети, почему `postgres` и `redis` чаще не должны получать published ports, как приложение находит зависимости по DNS-именам сервисов и почему лишняя публикация портов увеличивает шум и риск.
После урока студент понимает разницу между named volume и bind mount, знает где должен жить код проекта, где должна сохраняться база, зачем иногда нужен read-only mount и почему плохая стратегия mount быстро ломает производительность и воспроизводимость среды.
После урока студент понимает, что такое `UID/GID`, почему контейнер может создавать "чужие" файлы на хосте, как через `user`, build args или env-параметры согласовывать пользователя контейнера и почему разрешение через `777` — не решение, а деградация модели безопасности.
Осмысленная внешняя граница локального стека: один edge, домены на localho.st, Traefik и локальный HTTPS без магии.
Цель: Показать студенту, почему локальная среда должна иметь одну внешнюю точку входа, а домены лучше выражают структуру продукта, чем набор published ports. Результат: После урока студент понимает, почему `app:8080`, `api:8081` и `admin:8082` — это слабая внешняя модель, зачем вводить единый edge, и почему зона `*.localho.st` удобна для локальной разработки нескольких web-точек входа.
Цель: Научить студента читать и писать базовую Traefik-конфигурацию в `Compose`: provider Docker, entrypoints, routers, services, labels и выбор сети. Результат: После урока студент понимает, как `Traefik` обнаруживает сервисы через Docker provider, почему `exposedByDefault=false` безопаснее, как labels превращаются в маршрутизацию и зачем иногда нужно явно указать `traefik.docker.network`.
Цель: Дать студенту рабочую модель `HTTPS` в локальной среде через `Traefik`: `websecure`, сертификаты, redirect с `web` на `websecure` и базовую диагностику поломанной доменной маршрутизации. Результат: После урока студент понимает, что локальный `HTTPS` — это часть воспроизводимой среды, умеет подключить самоподписанные сертификаты к Traefik, знает, как проверить домен через `curl`, и не путает проблему DNS, router rule и TLS.
Логи, readiness, restart-политики, лимиты ресурсов и безопасное обслуживание локальной Docker-среды.
Цель: Научить студента не паниковать при падении контейнера: сначала смотреть логи, затем проверять состояние процесса и только потом заходить внутрь контейнера. Результат: После урока студент понимает разницу между логами и интерактивным доступом, не использует `docker exec` как первую реакцию на любую проблему и умеет формировать короткий диагностический отчет по контейнеру.
Цель: Научить студента различать старт процесса, готовность сервиса и автоматический рестарт как три разные идеи. Результат: После урока студент понимает, что `depends_on` не гарантирует готовность, что healthcheck нужен для сигнала о состоянии, а `restart` не исправляет неверную конфигурацию.
Цель: Научить студента видеть локальную Docker-среду как потребителя CPU и памяти хоста, а не как абстрактную "песочницу без цены". Результат: После урока студент понимает, зачем ограничивать прожорливые контейнеры, как читать базовые признаки нехватки ресурсов и почему локальная среда на ноутбуке тоже требует бюджета.
Цель: Научить студента чистить Docker-среду адресно и безопасно: понимать разницу между image cleanup, build cache cleanup и риском удалить полезные данные. Результат: После урока студент понимает, что `docker system prune -a` не должен быть первой реакцией, умеет объяснить разницу между dangling images и volumes с данными и знает, как чистить build cache отдельно.
После урока студент понимает, зачем IDE вообще подключается к Docker, какие задачи это решает и почему рассинхрон между IDE и контейнерной средой ломает предсказуемость разработки.
После урока студент понимает, зачем нужен remote interpreter, почему Composer и тесты должны идти через него и как несоответствие интерпретатора ломает доверие к результатам IDE.
После урока студент понимает, что Xdebug — это не "включил расширение и как-нибудь заработает", а связка из контейнерной конфигурации, IDE-listener и корректного сопоставления путей.
После урока студент понимает, почему одинаковая структура проектов ускоряет onboarding, снижает хаос и делает среду читаемой для всей команды.
После урока студент понимает, что среда как код требует документации, `.env.example`, onboarding-артефактов и воспроизводимого workflow для других разработчиков.