Тома, bind mount и tmpfs: три способа сбежать из записываемого слоя

Именованные тома: хранилищем владеет Docker

Именованный том — это хранилище, которое движок создаёт и которым управляет. docker volume create pgdata материализует директорию в /var/lib/docker/volumes/pgdata/_data, и монтирование её в /var/lib/postgresql/data заставляет контейнер писать прямо в эту директорию хоста, полностью обходя драйвер хранилища overlay2. Этот обход — вся история про производительность: записи идут напрямую в ФС хоста, а не через union-монтирование, поэтому нет налога copy-up и лишнего слоя для ядра. Для нагруженной на запись задачи вроде базы том нужен не только ради долговечности; он ощутимо быстрее записываемого слоя и без файловых затыков copy-up.

$ docker volume inspect pgdata --format '{{ .Mountpoint }}'
/var/lib/docker/volumes/pgdata/_data

# Том переживает контейнер; данные живут дольше любого rm/пересоздания:
$ docker run -d -v pgdata:/var/lib/postgresql/data postgres:16
$ docker rm -f $(docker ps -lq)      # контейнера нет
$ docker run -d -v pgdata:/var/lib/postgresql/data postgres:16   # данные на месте

Тома переносимы и удобны для бэкапа: поскольку Docker владеет путём и жизненным циклом, вы бэкапите, мигрируете и переносите их между хостами и между Linux- и Windows-контейнерами, не заботясь о раскладке директорий хоста. У них есть важное поведение при первом запуске: когда вы монтируете пустой именованный том поверх директории контейнера, которую заполнил образ, Docker копирует содержимое образа в том при первом использовании — так что монтирование пустого pgdata поверх свежего образа Postgres сохраняет seed-файлы образа. (Эта копия происходит только для пустых именованных томов, никогда для bind mount и никогда, если в томе уже есть данные — что и есть ловушка из истории: другой пустой том инициализировал чистую базу.)

Bind mount: сырой путь хоста, по правилам хоста

Bind mount отображает конкретный путь хоста прямо в контейнер: -v /data/pg:/var/lib/postgresql/data или явный --mount type=bind,source=/data/pg,target=.... Нет управляемой Docker директории и нет копии при первом запуске — что лежит на пути хоста, то и видит контейнер, немедленно и двунаправленно. Это правильный инструмент для dev-hot-reload (смонтировать дерево исходников, редактировать на хосте, контейнер видит) и для проброса конфиг-файлов хоста. Но вы наследуете семантику ФС хоста целиком, и острый угол — владение UID/GID.

Права Linux-файлов числовые. У контейнера свой /etc/passwd, но ядро применяет права по числу, а не по имени. Если директория хоста принадлежит UID 0, а процесс контейнера работает под UID 1000 (как и должен закалённый образ), каждая запись получает EACCES — permission denied — независимо от того, как «выглядит» имя пользователя внутри контейнера. Для обычного bind mount нет автоматического ремаппинга UID (rootless Docker и user namespaces это меняют, но демон по умолчанию — нет), так что директорию хоста нужно chown-нуть на UID, под которым контейнер реально работает, либо контейнер должен работать под UID, владеющим файлами хоста. Это самый частый отказ bind mount в проде, и фреймворки регулярно маскируют его под ошибку отсутствующего файла.

tmpfs: хранилище, которое есть RAM

Прежде чем тянуться за томом или bind mount для токенов сессий или временного каталога сортировки, спроси себя: должны ли эти байты пережить рестарт? Если нет — tmpfs правильный выбор. Монтирование tmpfs не устойчивое и не на диске — это ФС в памяти. --tmpfs /tmp или --mount type=tmpfs,destination=/tmp,tmpfs-size=64m даёт контейнеру быструю черновую область, которая никогда не касается ни драйвера хранилища, ни диска, и исчезает при остановке контейнера (она ещё эфемернее записываемого слоя, который хотя бы переживает stop/start). Применяют для двух вещей: секреты и чувствительные данные, которые никогда не хочется писать на диск, и высокооборотный черновик (файлы сессий, временные данные рендера, спил сортировки), где нужна скорость и нулевая долговечность. Подвох в том, что tmpfs потребляет RAM хоста: без tmpfs-size tmpfs может расти, пока не исчерпает память и OOM killer не убьёт контейнер, так что прод-tmpfs всегда должен задавать явный лимит размера.