Этап 1 - Основы контейнеризации
Перед командами нужно понять, какую именно проблему решает Docker. Команды используют containers не потому, что любят лишние инструменты. Они используют их потому, что запуск приложения слишком сильно начинает зависеть от конкретной машины.
Проблема простыми словами
Разработчик говорит: «у меня работает». Обычно это значит, что код — не вся система. В систему также входят версия Java, библиотеки ОС, версия базы данных, открытые порты, локальные файлы, environment variables и startup commands. Если эти части ставятся вручную, каждая машина постепенно становится уникальной.
Virtual machine решает это упаковкой целой guest operating system. Изоляция сильная, но тяжелая: каждой VM нужны своя ОС, память, boot process и обслуживание. Container берет меньшую границу. Он упаковывает process и filesystem dependencies, но использует общий host kernel.
Docker стал популярным потому, что объединил containers с практичным workflow: Dockerfile для инструкций build, image как повторяемый artifact, registry для распространения и Docker CLI для ежедневной работы.
Runtime становится описанным artifact
1. Source code
2. Dockerfile описывает runtime
3. Image собирается один раз
4. Container запускается из image
5. CI/server запускают тот же image
Главная идея: Docker переносит знание об окружении из памяти разработчика в files, images и commands, которые команда может проверить.
Как думать о границе
Самая важная идея containerization — это граница. Без Docker граница приложения размыта: часть находится в Git, часть в wiki, часть на ноутбуке разработчика, часть в CI configuration. Docker не отменяет необходимость понимать эти части, но заставляет команду назвать их явно.
Граница container обычно включает process, filesystem dependencies, environment variables, user, network interfaces и resource limits. Она не включает всю operating system так же, как virtual machine. Поэтому containers быстро стартуют и обычно дешевле в запуске, чем VMs.
Для новичка это различие важно, потому что убирает неверные ожидания. Container может изолировать application process, но все равно зависит от host kernel и Docker runtime. Он повторяемый, а не магический.
Где Docker помогает первым
Первый полезный сценарий Docker — onboarding. Вместо того чтобы просить нового разработчика вручную установить PostgreSQL, Redis, Java и набор command-line tools, проект может дать Compose file или documented Docker commands. Разработчику все еще нужно понимать services, но путь запуска становится повторяемым.
Второй сценарий — CI. Pipeline может скачать тот же image tag, который разработчики используют локально, запустить tests с реальными dependencies и не зависеть от того, что случайно установлено на CI worker.
Третий сценарий — deployment. Server должен запускать известную image version, а не пересобирать приложение из неизвестного local state. Это делает rollback и investigation возможными.
Где Docker реально выполняется
Docker устанавливается на реальную машину. Это может быть ваш ноутбук, CI runner или Linux server. Docker не запускается внутри браузера и не начинает автоматически работать где-то в облаке. Когда пользователь вводит docker run, обычно он вводит command в terminal на своем компьютере.
Команду принимает Docker CLI — command-line client. CLI отправляет request в Docker Engine. Docker Engine включает Docker daemon: background service, который создает images, containers, networks и volumes на этой машине.
На Linux daemon работает напрямую с Linux kernel. На macOS и Windows Docker Desktop обычно запускает маленькую Linux virtual machine в фоне, потому что containers требуют возможностей Linux kernel. Пользователь все равно вводит commands в обычном terminal, но containers фактически работают внутри Linux-среды Docker Desktop.
Docker Hub или другой registry находится удаленно. Он хранит images. Ваша машина скачивает image из registry, затем локальный Docker daemon создает из него container. После этого container работает локально, если вы специально не подключились к remote Docker host.
Команды: запустить и проверить
Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.
docker version
docker run hello-world
docker ps -a
docker rm <container-id>
Таблица для ориентира
| Тема | Что означает | Практический вывод |
|---|---|---|
| Ручная настройка | Dependencies ставятся вручную на каждой машине | Быстро сначала, нестабильно позже |
| Virtual machine | Полная guest OS с сильной изоляцией | Полезна, когда важна изоляция на уровне ОС |
| Container | Изолированный process плюс упакованная файловая система | Лучший default для повторяемого app runtime |
Аудит окружения
Перед использованием Docker в проекте выпишите, что сейчас скрыто в машине разработчика. Укажите runtime versions, external services, ports, local files и environment variables.
Если новый teammate не может восстановить этот список из repository, в проекте все еще есть undocumented environment state. Docker должен сделать это state видимым.
Контрольная точка
Можно идти дальше, когда вы можете объяснить, почему container легче virtual machine, почему image не равен container и почему Docker помогает CI запускать то же самое, что разработчики запускают локально.
Практика: разбор окружения
Возьмите реальный project и сделайте две колонки: что принадлежит application repository и что сейчас принадлежит машине разработчика. Java version, database version, Redis, ports, environment variables и startup commands попадут во вторую колонку, если они не описаны в repository. Затем отметьте, какие пункты Docker может сделать явными через Dockerfile, Compose file, image tag или documented command. Так фраза «у меня работает» становится конкретной, а не эмоциональной.