Что переживёт удаление контейнера

Представьте тестовую SQLite-базу, созданную приложением в /data. Если каталог находится только в слое записи контейнера, остановка и повторный старт того же контейнера сохранят файл. Но удаление контейнера удалит и этот слой. Новый контейнер из прежнего образа не получит новые записи автоматически.

Named volume хранит данные отдельно от конкретного контейнера и управляется Docker. Пример ниже создаёт том и подключает его к пути /data. Здесь qa-api:1 — заранее собранный вами образ; наш текущий HTTP-сервис ничего в этот каталог не записывает.

docker volume create qa-data
docker run --name qa-with-data --mount type=volume,source=qa-data,target=/data qa-api:1

Этот урок объясняет команды для собственного Docker. Лаборатория на сайте не предоставляет постоянные тома: её временная машина удаляется после проверки. Не пытайтесь хранить результаты курса внутри неё.

Подробнее: volumes в документации Docker.

Bind mount связывает путь на машине Docker с путём в контейнере. Это удобно, когда тестовые фикстуры уже лежат в папке проекта. Создайте локальную папку fixtures, затем разберите пример: источник находится на хосте, назначение — внутри контейнера.

docker run --rm \
  --mount type=bind,source="$(pwd)/fixtures",target=/fixtures,readonly \
  qa-api:1

readonly запрещает запись через это подключение. Без него bind mount по умолчанию допускает запись, и изменение из контейнера затронет исходные файлы на хосте. Признак RW: false в разделе Mounts у docker inspect помогает проверить настройку.

Путь относится к машине, на которой работает Docker daemon, а не обязательно к вашему ноутбуку. Также подключение поверх /app скроет файлы образа в этом каталоге. Поэтому для фикстур мы выбрали отдельный путь /fixtures.

Подробнее: bind mounts в документации Docker.

Для базы данных полезный сценарий таков: создать запись, удалить именно контейнер, создать другой с тем же named volume и прочитать запись. Для фикстур — открыть файл на чтение, попытаться изменить его и убедиться, что readonly блокирует запись. Это разные требования, поэтому один общий тест «файлы есть» недостаточен.

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

# План проверки сохранности:
# 1. Создать запись через приложение.
# 2. Заменить контейнер, сохранив named volume.
# 3. Прочитать ту же запись.
# 4. Отдельно проверить запуск без тома.

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