Томи: де насправді зберігаються дані контейнера

Контейнер є одноразовим. Усе, що записано всередині нього, зникає разом із ним. Дані мають жити зовні, і є рівно два способи: іменований том і прив'язка каталогу хоста.

Два способи та коли який використовувати

services:
  db:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data   # named volume
  app:
    image: nginx:1.27
    volumes:
      - ./site:/usr/share/nginx/html:ro    # directory bind mount
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

volumes:
  db-data:

Іменований том створює й зберігає сам Docker, у /var/lib/docker/volumes/<name>/_data. Права всередині встановлюються автоматично образом. Так зберігають бази даних і внутрішній стан сервісів.

Прив'язка каталогу — це звичайний шлях на диску машини. Так ви надаєте конфігураційні файли, статичні файли сайту та сертифікати: їх зручно редагувати в редакторі й зберігати в репозиторії.

Прапорець :ro робить прив'язку доступною лише для читання. Використовуйте його всюди, де контейнеру не потрібен запис — це дешевий захист.

Де все фізично зберігається

docker volume ls
docker volume inspect db-data
docker inspect -f '{{json .Mounts}}' <container> | python3 -m json.tool
sudo du -sh /var/lib/docker/volumes/* | sort -h | tail

Останню команду варто виконати першою, коли закінчується місце на диску. Докладніше: місце на диску.

docker compose down -v і docker volume prune видаляють томи назавжди. Том із базою даних виглядає «невикористаним», поки контейнер зупинено, і потрапляє під очищення. Перед очищенням подивіться на список: docker volume ls -f dangling=true.

Копіювання та міграція

Копіювання іменованого тому за допомогою одноразового контейнера:

docker run --rm -v db-data:/from -v $(pwd):/to alpine \
  tar czf /to/db-data.tar.gz -C /from .

Відновлення:

docker volume create db-data
docker run --rm -v db-data:/to -v $(pwd):/from alpine \
  tar xzf /from/db-data.tar.gz -C /to

Для баз даних цей метод придатний лише коли контейнер зупинено: копіювання файлів працюючої бази на рівні файлів може бути неузгодженим. Краще робити дамп власними засобами бази — pg_dump, mysqldump. Дивіться що саме копіювати.

Права

Найпоширеніша помилка з прив'язками каталогів — невідповідність власника. Усередині контейнера процес працює під власним UID, і файл, створений хостом від імені root, для нього недоступний.

docker compose exec app id
sudo chown -R 1000:1000 ./data

Багато образів приймають змінні PUID/PGID — це зручніше, ніж змінювати власника каталогу.

Поширені помилки

• Дані записувалися всередині контейнера. Ви перестворили контейнер під час оновлення — дані зникли. Перевірка: docker diff <container> покаже, що змінилося в його файловій системі; великі записи там — тривожний знак.
• Ви прив'язали каталог поверх непорожнього шляху в образі. Вміст образу приховано, і сервіс не може знайти свої файли.
• Відносний шлях у прив'язці каталогу. Він обчислюється від каталогу, що містить compose.yaml, а не від поточного. Запуск з іншого місця створить новий порожній каталог.
• Томи забули під час перевстановлення ОС. Перевстановлення повністю стирає диск. Копію потрібно зберігати не на цій машині.