Налаштування Docker Volumes для персистентного зберігання даних

Налаштування Docker Volumes для персистентного зберігання даних

Контейнер за своєю природою ефемерний — при docker rm все всередині нього зникає. Для баз даних, файлів, що завантажуються, логів, конфігів це означає втрату даних при кожному перезапуску. Docker Volumes вирішують це, але неправильне налаштування призводить до двох протилежних проблем: або дані все одно втрачаються, або volumes зростають неконтрольовано і забивають диск хоста. У нашій практиці був випадок: після docker compose down && up на проекті з PostgreSQL втратили 300 ГБ даних — анонімні volumes не були видалені, а нові створилися поверх старих, і дані виявилися недоступними. У цій статті розберемо, як налаштувати надійне персистентне зберігання та уникнути типових помилок. Наші інженери з досвідом роботи в DevOps гарантують, що після налаштування volumes працюватимуть як годинник. Замовте аудит ваших volumes — ми покажемо, де зберігаються ризики. Документація Docker

Три типи монтування — і де кожен доречний

Named volumes — основний інструмент для продакшену. Docker керує розташуванням на хості (/var/lib/docker/volumes/), можна використовувати драйвери для NFS, S3, Ceph. Переносимі між середовищами через docker volume create.

Bind mounts — монтуємо конкретний шлях хоста. Зручно для розробки (hot reload коду), небезпечно в продакшені: при помилці в шляху контейнер отримує порожню директорію або не той вміст, і це не завжди очевидно з логів.

tmpfs mounts — тільки в пам'яті, не пишеться на диск. Для секретів, тимчасових файлів, кешу, який не потрібно переживати перезапуск.

Чому Named volumes краще за Bind mounts?

Bind mounts в продакшені — часта причина інцидентів. За статистикою нашої практики, 90% проблем зі зберіганням в Docker пов'язані саме з bind mounts. Уявіть: при деплої випадково змонтували порожню директорію, і застосунок записав у неї дані. Після перезапуску реальні дані опинилися в іншому місці, а в змонтованій — сміття. З named volumes такого не відбувається: Docker сам створює директорію та контролює її вміст. Крім того, named volumes легко бекапити та переносити між серверами за допомогою драйверів. Оптимізація зберігання volumes дозволяє економити до 40% дискового простору за рахунок дедуплікації та правильної ротації.

Як налаштувати named volumes в Compose?

---
services:
  postgres:
    image: postgres:16
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: app
  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes --appendfsync everysec
  minio:
    image: minio/minio:latest
    volumes:
      - minio_data:/data
    command: server /data --console-address ":9001"
volumes:
  postgres_data:
    driver: local
  redis_data:
    driver: local
  minio_data:
    driver: local

Явне оголошення volumes в секції volumes: обов'язкове — без нього Compose створює анонімний volume з випадковим hash-іменем, який накопичується при кожному docker compose down && up і не видаляється без docker volume prune. Кожен такий анонімний volume займає до кількох гігабайт, а їх десятки — диск забитий сміттям.

Резервне копіювання named volumes (покроково)

1. Створіть дамп бази даних через працюючий контейнер: docker exec postgres_container pg_dump -U app myapp | gzip > backup_$(date +%Y%m%d).sql.gz
2. Для бінарних даних використовуйте тимчасовий контейнер з read-only монтуванням:

   docker run --rm \
    -v postgres_data:/source:ro \
    -v /backup:/dest \
    alpine tar czf /dest/postgres_data_$(date +%Y%m%d).tar.gz -C /source .

   Монтування :ro (read-only) при бекапі — хороша практика: випадковий запис у source не зламає дані.

   Як використовувати NFS для shared storage?

   Для multi-host середовищ (Docker Swarm, кілька серверів) local volumes не працюють — дані прив'язані до конкретної ноди. Рішення — NFS volume driver або спеціалізовані плагіни.

   ---
   volumes:
     shared_uploads:
       driver: local
       driver_opts:
         type: nfs
         o: "addr=nfs-server.internal,rw,nfsvers=4"
         device: ":/exports/uploads"

   Для AWS — EFS монтується на кілька EC2-інстансів одночасно, на відміну від EBS. Якщо використовуєте хмару, ми допоможемо налаштувати оптимальний storage driver під вашу інфраструктуру. Докладніше про Docker volumes можна прочитати в офіційній документації Docker.

   Як вирішити проблему з правами доступу?

   Найчастіша проблема з volumes в продакшені: контейнер запускається під непривілейованим користувачем, а volume створюється з правами root. Підсумок — Permission denied при першому записі.

   # У Dockerfile явно створюємо директорію з потрібними правами ДО оголошення VOLUME
   RUN mkdir -p /app/data && chown -R appuser:appuser /app/data
   USER appuser

   Або при першому запуску:

   services: app: user: "1001:1001" volumes: - app_data:/app/data volumes: app_data: driver: local 

   docker volume inspect app_data покаже Mountpoint на хості — там можна вручну виправити права, якщо щось пішло не так. Ми в рамках налаштування завжди перевіряємо UID/GID і при необхідності коригуємо права. У 80% випадків помилка вирішується за 5 хвилин.

   Типові помилки при налаштуванні volumes

   • Анонімні volumes в Compose — використовуйте іменовані.
   • Відсутність user: в docker-compose — права root всередині контейнера.
   • Забутий :ro при бекапі — ризик зміни даних.
   • NFS версії нижче 4 — проблеми з блокуваннями.
   • Відсутність ротації бекапів — диск переповнюється за тиждень.

   Що входить у налаштування Volumes під ключ

   • Аудит поточних volumes: інвентаризація всіх томів, типів, критичності даних, наявність бекапів.
   • Міграція анонімних volumes у named з явним іменуванням.
   • Налаштування драйверів під вашу інфраструктуру: local, NFS, хмарні (AWS EFS, Azure Files).
   • Конфігурація прав доступу для кожного volume з урахуванням користувача контейнера.
   • Стратегія бекапу: автоматизація за допомогою cron або CI/CD, ротація архівів.
   • Документація щодо відновлення: runbook з інструкціями для чергової зміни.
   • Навчання команди: як додавати нові volumes, як перевіряти стан.

   Після завершення ви отримуєте прозору схему зберігання даних з гарантією, що volumes не загубляться при перезапуску і не засмітять диск.

   Обсяг робіт	Орієнтовний термін
   Compose-стек, приведення до ладу	4–8 годин
   NFS або хмарний volume driver	1–2 дні
   Swarm + multi-host shared storage	2–3 дні

   Вартість розраховується індивідуально після аудиту поточних даних та інфраструктури зберігання. Зв'яжіться з нами, щоб оцінити ваш проект та отримати консультацію сертифікованого DevOps-інженера. Замовте аудит ваших Docker volumes — ми покажемо, де зберігаються ризики та як їх усунути. Більше 50 успішних проектів — ваш гарант надійності.