Docker для первого учебного проекта: образы, контейнеры и данные

Если вы хотите понять Docker без погружения в оркестрацию и сложную инфраструктуру, полезно собрать один маленький учебный проект и на нем разобрать четыре вещи: что такое образ, чем он отличается от контейнера, как открыть приложение через порт и где на самом деле лежат данные. Этого достаточно, чтобы первый запуск не превращался в набор случайных команд.

Ниже будет пример без перестройки рабочей машины под Node, Python или базу данных. Docker не отменяет хост-систему и не дает «полной изоляции», но позволяет запускать приложение как отдельный процесс с предсказуемым набором файлов и настроек. Для начала этого достаточно: вы видите результат в браузере и отдельно понимаете, почему одни данные исчезают вместе с контейнером, а другие переживают его замену.

Образ и контейнер: не одно и то же

Образ удобно представлять как заготовку. В нем лежат файлы приложения, нужные зависимости и команда запуска. Сам по себе образ ничего не обслуживает и не «работает в фоне»: это исходная точка, из которой Docker создает контейнер. Один и тот же образ можно использовать много раз, если вам нужно поднять несколько одинаковых экземпляров.

Контейнер — это уже запущенный или созданный экземпляр образа. У него есть собственный записываемый слой: туда попадают файлы, которые приложение создало или изменило во время работы. Поэтому после запуска контейнер перестает быть просто копией образа: у него появляется свое состояние. Важно не смешивать эти уровни. Удаление контейнера не удаляет образ, а пересборка образа не меняет уже работающий контейнер автоматически.

По документации Docker контейнер — это изолированный процесс, а не полноценная виртуальная машина. Контейнеры не получают отдельное ядро операционной системы, как виртуальные машины, а используют ядро хоста. Для первого проекта это полезно помнить по двум причинам: контейнеры запускаются легче, чем отдельные ВМ, но и воспринимать их как абсолютный барьер между приложением и хостом не стоит.

Как выглядит первое окружение без лишней настройки хоста

Самый спокойный старт — взять простое приложение, которое видно в браузере. Для этого подойдет статическая HTML-страница. Локально вам не нужен установленный веб-сервер: он попадет в образ, а на хосте останется только Docker. Так вы тренируете именно механику образа и контейнера, а не долгую подготовку окружения.

Минимальный Dockerfile для такой страницы может быть совсем коротким:

FROM nginx
COPY index.html /usr/share/nginx/html/index.html

Дальше логика простая. Сначала вы собираете образ, например командой docker build -t study-page .. Потом запускаете контейнер: docker run --name study-page -d -p 8080:80 study-page. В этой записи слева указан порт хоста, справа — порт внутри контейнера. Если контейнерный сервер слушает 80-й порт, а вы публикуете его как 8080, страницу нужно открывать по адресу http://localhost:8080.

Практическая польза такого шага в том, что вы сразу отделяете две задачи. Сборка образа отвечает на вопрос «что именно входит в мое приложение», а публикация порта — на вопрос «как я к нему подключаюсь с хоста». Когда новичок смешивает эти уровни, начинаются типичные ошибки: образ собран, контейнер запущен, а страница не открывается, потому что опубликован не тот порт или приложение внутри контейнера слушает другой.

Где живут данные: слой контейнера и том

После первого удачного запуска обычно возникает следующий вопрос: если приложение что-то записало, оно останется? Ответ зависит от того, куда была запись. У каждого контейнера есть собственный записываемый слой. Если вы остановили контейнер и потом запустили этот же контейнер снова, его изменения обычно сохраняются: сам контейнер никуда не делся, просто процесс был остановлен и запущен заново.

Проблема начинается в момент удаления контейнера или его замены новым экземпляром из того же образа. Записываемый слой связан именно с этим контейнером. Удалили контейнер — потеряли и изменения, которые жили только в его слое. Поэтому для данных, которые должны пережить замену контейнера, Docker использует тома. Том монтируется в путь внутри контейнера, но живет отдельно от его жизненного цикла.

На практике разграничение выглядит так: код страницы и стартовая конфигурация хорошо подходят для образа; временные файлы одного конкретного контейнера могут жить в его слое; а пользовательские данные, база, загруженные файлы, кэши, которые нужно сохранить при пересоздании контейнера, стоит выносить в том. Именно это различие и спасает от ситуации «все работало, пока я не заменил контейнер новым».

Учебный пример: страница в браузере и отдельное хранилище данных

Учебный пример. Представим мини-проект из двух шагов. Шаг первый — собрать образ study-page из Dockerfile выше и запустить контейнер с публикацией порта 8080:80. Проверяем результат просто: страница открывается в браузере, а команда docker ps показывает, что контейнер работает и какой порт опубликован наружу.

Шаг второй нужен уже не для интерфейса, а для понимания хранения данных. Создаем отдельный контейнер-хранилище с томом: docker run --name notes-store -d -v notes-data:/data alpine sh -c "while true; do sleep 3600; done". После этого можно записать два файла: один в путь /data, другой во временный путь контейнера, например /tmp. Смысл не в команде как таковой, а в разделении мест хранения: /data связан с томом notes-data, а /tmp остается частью записываемого слоя контейнера.

Что это дает в понимании Docker? Если контейнер notes-store просто остановить и потом снова запустить, оба файла останутся, потому что контейнер тот же самый. Но если позже вы решите заменить контейнер новым и снова подключите том notes-data, файл из /data можно будет использовать дальше, а файл из /tmp к новому контейнеру не перейдет. Так становится наглядно видно, почему «остановка контейнера» и «удаление контейнера» — разные события.

Практический результат этого мини-проекта двойной. Во-первых, вы видите реальное приложение на localhost через опубликованный порт. Во-вторых, понимаете архитектурное правило, которое пригодится дальше: контейнер — это место для запуска процесса, а том — место для данных, которые нельзя привязывать к судьбе одного экземпляра контейнера.

Типичные ошибки первого запуска и как себя проверить

Самая частая ошибка — перепутанные порты. Формат -p 8080:80 читается слева направо как «8080 на хосте ведет к 80 внутри контейнера». Если приложение внутри слушает 8000-й порт, а вы публикуете 80-й, браузер не покажет ожидаемый результат, хотя контейнер может считаться запущенным. Поэтому проверяйте не только адрес в браузере, но и то, какой внутренний порт использует сам процесс.

Вторая ошибка — смешение действий остановить и удалить. Остановка завершает процесс в контейнере, но сам контейнер остается. Его можно снова запустить и получить прежний записываемый слой. Удаление контейнера — другое действие: вместе с контейнером уходит и его собственный слой изменений. Когда это различие не проговорено, у новичка появляется ложное ощущение, что Docker «теряет данные после stop», хотя проблема возникает после удаления или замены контейнера без тома.

Третья ошибка — подключить том не туда, куда приложение реально пишет данные. Сам факт наличия тома еще не помогает. Если приложение сохраняет файлы в одном каталоге, а том смонтирован в другой, устойчивого хранения не получится. Для первого проекта полезно проверять себя по короткому списку: какой образ я собрал, какой контейнер из него запустил, какой порт контейнера опубликовал и какой путь внутри контейнера связан с томом.

Если вы хотите изучать Docker не только по статье, посмотрите, есть ли в программе практика именно по этим шагам: базовые команды, различие контейнеризации и виртуализации, работа с данными и сетями, создание образов и Dockerfile, запуск нескольких сервисов через Compose. У курса «Установка, использование Docker. Практикум» в подтвержденной программе как раз заявлены введение в Docker, работа с данными и сетями, создание образов, Dockerfile и Docker Compose. Перед выбором обучения спросите себя: будет ли у вас самостоятельное задание на сборку образа, запуск контейнера с опубликованным портом и отдельная проверка того, что данные лежат в томе, а не только в слое контейнера.