Тома и персистентность

Writable-слой — это черновик, а не хранилище

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

Запущенный контейнер — это его read-only слои образа плюс один тонкий writable-слой (writable layer, записываемый слой) сверху, сшитые union-файловой системой (объединяющей ФС). Каждый файл, который твой процесс создаёт или меняет в рантайме — каталог данных Postgres, загруженная аватарка, лог-файл — попадает в этот writable-слой. Он ощущается как обычный диск, и в этом-то и ловушка.

Этот слой привязан к жизненному циклу контейнера. Удали контейнер (docker rm, compose down, передеплой, который пересоздаёт его) — и writable-слой удаляется вместе с ним. Данные не «где-то на хосте, откуда их можно выкопать» — они жили внутри собственного diff’а контейнера и исчезли. Хуже того, пока контейнер жив, всё, что ты туда пишешь, раздувает размер контейнера и идёт через union-абстракцию storage-драйвера, которая медленнее записи прямо на хост. Writable-слой — для эфемерного черновика: временных файлов, рантайм-состояния процесса, — но никогда для того, что было бы жаль потерять.

Чтобы персистить данные, ты монтируешь storage, который живёт вне writable-слоя. Docker даёт три типа mount’ов, и выбор правильного — это и есть весь навык.

Named volumes: дефолт для данных, которые хранишь

Named volume — это storage, который Docker создаёт и сам им управляет; он живёт на хосте под /var/lib/docker/volumes/<name>/_data. Ты никогда не трогаешь этот путь напрямую — ты обращаешься к volume по имени, а Docker делает остальное. Это рекомендуемый механизм для всего stateful: файлов баз данных, данных очередей, загруженного пользователями контента.

# Создать по требованию и смонтировать; -v <name>:<путь-в-контейнере>
docker run -d --name db \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

# Явная, самодокументирующаяся форма
docker run -d --name db \
  --mount type=volume,src=pgdata,dst=/var/lib/postgresql/data \
  postgres:16

# docker-compose.yml — одна строка, которая спасает staging-машину
services:
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Named volumes выигрывают для stateful-данных по трём пунктам. Они отвязаны от раскладки хоста — ты ссылаешься на pgdata, а не на /home/deploy/что-то, поэтому один и тот же compose-файл бежит и на ноутбуке, и на сервере. Они портируемы и бэкапятся — Docker управляет ими, инспектирует и бэкапит как объекты первого класса, и они переживают удаление контейнера by design. И они пишут прямо в файловую систему хоста, а не через union-слой, поэтому быстрее для write-heavy нагрузок, которые генерируют базы данных.

Bind mounts: путь хоста, проброшенный напрямую

Bind mount мапит конкретный каталог или файл с машины-хоста внутрь контейнера. В отличие от volume, ты владеешь путём на хосте и его раскладкой; Docker просто прокидывает его, и хост с контейнером видят одни и те же файлы вживую.

# Смонтировать исходники текущего проекта в контейнер для live reload
docker run -it \
  --mount type=bind,src="$(pwd)",dst=/app \
  node:22 bash

# Короткая форма (-v с абсолютным путём хоста — это bind mount, а не volume)
docker run -it -v "$(pwd)":/app node:22 bash

Убойный сценарий — разработка: bind-монтируешь дерево исходников в контейнер, и dev-сервер делает hot-reload на каждом сохранении, без пересборки. Но bind mounts привязывают тебя к раскладке каталогов хоста (путь должен существовать и выглядеть одинаково везде, где бежит контейнер) и несут острый край — bind mount поверх пути, который образ уже наполнил, скрывает исходное содержимое этого пути на всё время mount’а. Прокинь пустую папку хоста на /app после того, как node_modules поставился туда при сборке, — и контейнер теперь видит пустой /app: установка затенена, а не слита. Это одна из самых частых загадок «в образе работало, а при запуске нет».

tmpfs: в памяти, никогда не персистится

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

# Смонтировать in-memory файловую систему на /run/secrets (только Linux)
docker run -it --tmpfs /run/secrets myapp

# Явная форма с опциями
docker run -it \
  --mount type=tmpfs,dst=/run/secrets,tmpfs-size=64m \
  myapp

Тянись к tmpfs, когда секрет должен существовать как файл, чтобы один процесс его прочитал, но никогда не должен касаться долговечного storage, — или для горячего черновика, где важна скорость RAM, а не долговечность. Никогда не используй его для того, что нужно после рестарта: by design восстанавливать нечего.

Жизненный цикл volume: ловушка «куда делся диск»

У volumes жизненный цикл, намеренно независимый от контейнеров, и эта независимость режет в обе стороны. Volume создаётся по требованию при первой ссылке на него и переживает удаление контейнера — это и есть нужная долговечность. Но это же значит, что volume никогда не чистится автоматически. Удали контейнер — и named volume остаётся, занимая диск, пока ты явно его не удалишь.

docker volume ls                 # список томов
docker volume inspect pgdata     # посмотреть Mountpoint на хосте
docker volume rm pgdata          # удалить один том (должен быть не используемым)
docker volume prune              # удалить ВСЕ тома, не используемые контейнером

Сеньорская ловушка живёт в docker volume prune. Он удаляет каждый volume, не прикреплённый сейчас к контейнеру, — а volume, чей контейнер ты удалил на прошлой неделе, по этому определению «не используется». Запусти небрежный prune, чтобы освободить диск, — и можешь стереть базу, которую полностью собирался оставить. Обратная сторона, протухшие volumes молча съедают диск, — более частый повседневный сюрприз: месяцы мёртвых анонимных томов от удалённых контейнеров копятся под /var/lib/docker/volumes, пока на хосте не кончается место.

Сеньорские случаи: host-local — это не сеть

Три правила отделяют того, кто умеет смонтировать volume, от того, кто умеет гонять stateful-нагрузки. Первое: данные базы ДОЛЖНЫ жить на named volume, а не на слое контейнера — хук и есть это правило, выученное на горьком опыте. Второе: никогда не bind-монтируй поверх пути, который наполнил образ, если только ты специально не хочешь его затенить; именно так node_modules и другое build-time содержимое молча исчезает в рантайме. Третье, и оно кусает на масштабе: volumes — host-local. Named volume живёт на диске одной машины. В кластере из нескольких узлов (Swarm, Kubernetes, несколько VM за балансировщиком) volume на узле A невидим контейнеру, запланированному на узел B. Для многоузловой персистентности нужен сетевой или объектный storage — управляемая база, S3-совместимое объектное хранилище или CSI/network-volume драйвер, — а не простой локальный volume. Считать локальный volume общим хранилищем — классическая ошибка, когда одноузловой compose-сетап дорастает до кластера. Вместе эти три правила означают: решения о хранилище, принятые при написании compose-файла, определяют устойчивость всей системы — пропустить второе правило значит потерять данные молча, пропустить третье — потерять данные всего узла на масштабе кластера.