Volumes в Docker: как правильно хранить данные контейнеров

Почему файловая система контейнера временная

Контейнер Docker строится из образа как набора неизменяемых слоёв только для чтения, поверх которых при запуске добавляется тонкий записываемый слой, принадлежащий именно этому конкретному контейнеру. Любые файлы, созданные или изменённые внутри контейнера во время его работы — загруженные пользователями изображения, содержимое базы данных, сгенерированные логи — физически попадают именно в этот временный записываемый слой.

docker run --name test-app myapp:latest
docker rm test-app

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

Именно поэтому любые данные, которые должны пережить перезапуск, обновление образа или пересоздание контейнера, обязаны находиться вне временного записываемого слоя — в одном из механизмов постоянного хранения, которые Docker предоставляет специально для этой цели и которые разбираются в следующих разделах.

Именованные тома (named volumes): рекомендуемый способ хранения

Именованный том — это область хранения, которую создаёт и полностью обслуживает сам Docker, независимо от жизненного цикла любого конкретного контейнера. Физически данные хранятся в управляемой Docker части файловой системы хоста (по умолчанию внутри /var/lib/docker/volumes), но взаимодействие с томом происходит исключительно через команды Docker, а не через прямую работу с этим путём.

docker volume create pgdata
docker run -d --name postgres-db -v pgdata:/var/lib/postgresql/data postgres:16

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

docker volume ls
docker volume inspect pgdata

Дополнительное практическое преимущество именованных томов — переносимость: одну и ту же команду docker run с указанием тома можно выполнить на любом хосте с установленным Docker, не заботясь о том, существует ли на этом конкретном хосте нужный путь в файловой системе и правильные ли на нём права доступа, — этим Docker берёт на себя заботу о физическом расположении данных.

Bind mounts: прямой проброс пути с хоста

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

docker run -d --name web-app \
    -v /srv/app/uploads:/var/www/html/uploads \
    -v /srv/app/config/app.env:/app/.env:ro \
    myapp:latest

Bind mount удобен для сценариев, где нужен прямой и предсказуемый доступ с хоста к данным контейнера — например, чтобы редактировать конфигурационный файл прямо на хосте обычным текстовым редактором и видеть изменения внутри контейнера немедленно, без пересборки образа или копирования файла внутрь контейнера отдельной командой. Именно поэтому bind mount широко используется при локальной разработке, где исходный код проекта пробрасывается с хоста прямо в контейнер для мгновенного отражения изменений.

Оборотная сторона гибкости bind mount — меньшая переносимость и повышенный риск: путь на хосте должен физически существовать и иметь корректные права доступа именно на этом конкретном сервере, а процесс внутри контейнера с достаточными привилегиями получает возможность изменять файлы хоста через такой проброс — для непроверенных образов или контейнеров, запущенных с повышенными привилегиями, проброс с правами записи в чувствительные пути хоста стоит по возможности исключать или явно ограничивать флагом :ro (только чтение).

tmpfs mounts: данные только в оперативной памяти

tmpfs mount — третий, менее часто используемый механизм: он хранит данные исключительно в оперативной памяти хоста, без какого-либо физического следа на диске, и подходит для временных, часто перезаписываемых или чувствительных данных, где важна скорость и где сохранность между перезапусками не требуется или прямо нежелательна.

docker run -d --name cache-app \
    --tmpfs /app/tmp:rw,size=256m \
    myapp:latest

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

Volume drivers: хранение данных не только на локальном диске

По умолчанию именованные тома используют локальный драйвер, хранящий данные на диске того же хоста, где запущен Docker, — этого достаточно для подавляющего большинства одиночных серверов. Docker, однако, поддерживает подключаемые драйверы томов, позволяющие хранить данные в других местах: на сетевом хранилище через NFS, в объектном хранилище через сторонние плагины, или в распределённой файловой системе для кластерных сценариев.

docker volume create --driver local \
    --opt type=nfs \
    --opt o=addr=192.168.1.50,rw \
    --opt device=:/exports/app-data \
    nfs-shared-data

Такой подход особенно ценен для контейнеров, которые должны переезжать между разными хостами (например, при использовании оркестрации вроде Docker Swarm или Kubernetes) — если данные физически привязаны к конкретному диску конкретного сервера, перенос контейнера на другой хост означает потерю доступа к этим данным, тогда как том на внешнем сетевом хранилище остаётся доступен независимо от того, на каком именно хосте кластера в данный момент запущен контейнер.

Для одиночного сервера без задач по горизонтальному масштабированию и переезду контейнеров между хостами локальный драйвер по умолчанию остаётся простым, быстрым и абсолютно достаточным выбором — усложнение через внешние volume driver имеет смысл вводить только тогда, когда конкретная задача (кластеризация, высокая доступность через несколько хостов) действительно этого требует.

Как выбрать между тремя вариантами хранения

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

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

tmpfs подходит исключительно для данных, чья временность — осознанное и желаемое свойство: кэш, временные файлы обработки, чувствительные данные, которые не должны оставлять след на диске. Использование tmpfs для данных, которые на самом деле нужно сохранить между перезапусками, — распространённая и досадная ошибка конфигурации, приводящая к неожиданной потере данных при первом же перезапуске контейнера.

Резервное копирование данных из volume

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

docker run --rm \
    -v pgdata:/data:ro \
    -v $(pwd):/backup \
    alpine tar czf /backup/pgdata-$(date +%F).tar.gz -C /data .

Флаг --rm автоматически удаляет вспомогательный контейнер сразу после завершения его работы, поскольку он нужен исключительно на время создания архива и не должен оставаться работающим или даже просто существующим постоянно. Монтирование тома с флагом :ro (только чтение) для этой операции — разумная предосторожность, исключающая случайное изменение архивируемых данных в процессе самого резервного копирования.

docker run --rm \
    -v pgdata:/data \
    -v $(pwd):/backup \
    alpine sh -c "cd /data && tar xzf /backup/pgdata-2026-11-05.tar.gz"

Для баз данных внутри контейнеров зачастую надёжнее использовать штатные инструменты самой СУБД (mysqldump, pg_dump, физическое резервное копирование через XtraBackup) поверх работающего контейнера, а не резервное копирование содержимого тома на уровне файлов, — это гарантирует согласованность данных на момент снятия копии, тогда как копирование файлов данных работающей базы данных напрямую рискует захватить их в промежуточном, не полностью согласованном состоянии.

Совместное использование одного тома несколькими контейнерами

Один именованный том можно подключить сразу к нескольким контейнерам одновременно — это стандартный способ организовать обмен файлами между ними без построения отдельного сетевого механизма передачи данных.

docker volume create shared-uploads

docker run -d --name app -v shared-uploads:/app/uploads myapp:latest
docker run -d --name nginx -v shared-uploads:/usr/share/nginx/html/uploads nginx:alpine

В этом примере контейнер приложения записывает загруженные пользователями файлы в общий том, а отдельный контейнер nginx отдаёт эти же файлы напрямую посетителям сайта, минуя более медленную обработку через сам код приложения, — типичный паттерн разделения ответственности между контейнером приложения и контейнером веб-сервера в многоконтейнерной архитектуре.

При одновременной записи в общий том из нескольких контейнеров стоит заранее продумать, не возникнет ли конфликтов доступа к одним и тем же файлам — сам механизм тома не предоставляет встроенной блокировки на уровне приложения, и ответственность за корректную параллельную работу с общими данными остаётся на логике самих приложений, использующих этот том.

Практический пример: docker-compose с постоянным томом для базы данных

Полноценный пример docker-compose.yml с приложением и базой данных PostgreSQL, где данные базы данных сохраняются в именованном томе, переживающем пересоздание контейнеров при обновлении версии образа приложения.

services:
  app:
    image: myapp:latest
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgres://appuser:secret@db:5432/appdb
    volumes:
      - app-uploads:/app/uploads
    ports:
      - "8080:8080"

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:
  app-uploads:

Секция volumes верхнего уровня объявляет именованные тома pgdata и app-uploads, которые Docker Compose создаёт автоматически при первом запуске (docker compose up) и переиспользует при последующих запусках, если явно не указано иное. Это означает, что команду docker compose down && docker compose up -d — обычный способ пересоздать контейнеры при обновлении образов — можно выполнять сколько угодно раз без риска потерять содержимое базы данных, поскольку данные физически находятся в томе, а не в самих пересоздаваемых контейнерах.

Важная деталь: команда docker compose down с флагом -v дополнительно удаляет и объявленные тома, а не только контейнеры и сети, — эта разница между обычным down и down -v регулярно становится причиной случайной потери данных, когда администратор, желая просто перезапустить контейнеры, по привычке или из другого проекта добавляет флаг -v, не задумываясь о его реальном эффекте.

Контроль использования диска и очистка неиспользуемых томов

Тома, как и образы, со временем накапливаются на сервере, особенно если контейнеры пересоздавались много раз с разными именами анонимных томов или если из проекта удалялись сервисы, но их тома не были удалены явно вместе с ними.

docker system df -v
du -sh /var/lib/docker/volumes/*/_data 2>/dev/null | sort -rh | head -10

Команда docker system df -v показывает детальную разбивку занятого места отдельно по образам, контейнерам и томам, что быстро отвечает на вопрос, что именно занимает место на диске, если сервер начинает испытывать нехватку свободного пространства. Отдельная колонка в её выводе показывает, сколько томов существует и сколько из них реально используются хотя бы одним контейнером прямо сейчас.

docker volume prune

Команда docker volume prune запрашивает подтверждение и удаляет только тома, никак не связанные ни с одним контейнером на момент выполнения, — это безопасная операция для очистки места, но перед её выполнением на продакшн-сервере стоит убедиться, что среди неиспользуемых томов нет тех, что временно отключены от контейнера намеренно (например, при плановом обслуживании) и предназначены для повторного подключения позже.

Итоги: данные и жизненный цикл контейнера — разные вещи

Главный принцип работы с данными в Docker — осознанное разделение между эфемерной файловой системой самого контейнера, которая может и должна пересоздаваться при каждом обновлении образа, и постоянным хранилищем данных в виде именованных томов или bind mounts, которое переживает эти пересоздания без потерь.

Именованные тома остаются разумным выбором по умолчанию для большинства данных приложения благодаря управляемости и переносимости, bind mounts — для случаев, требующих прямого контроля над физическим расположением на конкретном хосте, а tmpfs — исключительно для осознанно временных данных. Отдельное и обязательное резервное копирование содержимого томов вне самого Docker остаётся необходимым даже при полностью корректной настройке хранения — том защищает данные от пересоздания контейнера, но не от отказа диска, ошибки администратора или полной утраты сервера.