Этап 5 - Сохранение данных

Containers по замыслу disposable. Это хорошо для deployment, но опасно для data. Этот этап объясняет, где Docker хранит state и когда его нужно выносить из container.

Первый вопрос: данные понадобятся потом?

У каждого container есть writable layer. Он удобен для temporary files, но принадлежит конкретному container. Удалите container — и writable layer исчезнет. Поэтому database без volume теряет data после docker rm.

Temporary file -> writable layer
Database data -> named volume
Source code -> bind mount
Production data -> external service or managed volume

Volumes и bind mounts

Named volume — Docker-managed storage со стабильным именем. Это обычный локальный выбор для PostgreSQL, MySQL, Redis snapshots и любого state, который должен переживать замену container. Anonymous volumes тоже сохраняются, но позже их трудно распознать.

Bind mount соединяет конкретный host path с path внутри container. Он удобен для source code в development: изменения на host сразу видны внутри container. Но он менее portable, потому что host paths и permissions различаются между машинами.

Database containers все еще databases

Запуск PostgreSQL в Docker не меняет то, как database думает о durability. PostgreSQL все равно пишет data files, использует write-ahead logs и требует consistent backup strategy. Docker только решает, где эти files живут с точки зрения container.

Для local development named volume обычно достаточно. Для production нужен более сильный план: managed database, проверенные backups, restore procedure, monitoring и clear ownership. Docker volume сам по себе не является backup.

Важное различие — persistence и recoverability. Volume может сохранять data на одном host. Backup позволяет восстановить data после потери host, случайного удаления или corruption.

Bind mounts не плохие

Bind mounts иногда описывают как менее безопасные, чем volumes, но они решают другую задачу. Они полезны, когда host file должен быть виден внутри container: source code, configuration files, certificates в development или generated reports.

Tradeoff — portability. Bind mount зависит от host path и host permissions. Path, который работает на macOS, может не существовать на Linux. UID, который может писать на одной машине, может упасть на другой. Поэтому bind mounts часто используют в development и гораздо осторожнее контролируют в production.

Где физически живут Docker data

Volumes хранятся на Docker host. На Linux это обычно внутренний Docker data directory. В Docker Desktop volume находится внутри Linux virtual machine Docker Desktop, а не рядом с project files.

Это объясняет частую путаницу: named volume переживает удаление container, но пользователь может не видеть его в папке проекта. Им управляет Docker. Чтобы inspect его, используйте Docker commands, а не Finder или Explorer.

На VPS volumes живут на диске этой VPS. Если VPS удалить, volume тоже исчезнет, если нет backups или external storage. Persistence на одном host — это не то же самое, что disaster recovery.

Команды: запустить и проверить

Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.

docker volume create pgdata
docker run -d --name pg -e POSTGRES_PASSWORD=secret -v pgdata:/var/lib/postgresql/data postgres:16
docker volume inspect pgdata
docker exec pg pg_dump -U postgres postgres > backup.sql

Таблица для ориентира

Правило выбора storage

Перед выбором storage задайте один вопрос: должны ли эти data пережить замену container? Если нет, writable layer может быть допустим. Если да, используйте named volume, bind mount, external service или explicit backup strategy.

Для databases предпочитайте database-native backups, например dumps. Копирование raw files без учета consistency может дать backup, который выглядит нормальным, но не восстанавливается.

Контрольная точка

Продолжайте, когда можете указать на path и сказать, принадлежит ли он container writable layer, Docker volume, host bind mount или external system.

Практика: где живут данные

Запустите database один раз без volume и один раз с named volume. Создайте маленькую table в обоих случаях, удалите containers и запустите replacement containers. Первый вариант потеряет table; второй сохранит ее. Это самый быстрый способ понять, почему замена container нормальна, а неосознанное размещение data опасно.