Част 5: Docker Volumes & Persistent Data

1. Проблемът с Ephemeral Storage

Всеки Docker контейнер използва слой за писане (writable layer) над неизменяемия си Image. Когато процесът вътре създава или модифицира файлове, те се записват именно в този слой.

Този подход има няколко сериозни недостатъка:

• Загуба на данни: При изтриване на контейнера (docker rm), целият writable layer се заличава завинаги;
• Производителност: Писането през Docker Storage Driver (Overlay2) е по-бавно от директния достъп до хост файловата система;
• Трудна споделяемост: Данните са капсулирани и трудно достъпни за други контейнери или процеси на хоста.

2. Видове Storage в Docker

За да осигури персистентност и висока производителност, Docker предлага три основни типа за монтиране (mounts):

3. Docker Volumes (Named Volumes)

Volumes са за предпочитане при работа с бази данни и съхранение на оперативни данни на приложения в production.

3.1. Управление на Volumes чрез CLI

# Създаване на нов volume
docker volume create db_data

# Преглед на наличните volumes
docker volume ls

# Детайлна информация за volume (път на хоста, driver и др.)
docker volume inspect db_data

# Премахване на volume
docker volume rm db_data

3.2. Монтиране на Volume в Container

Монтирането става чрез флага -v (съкратен) или --mount (по-подробен и препоръчителен при по-сложни конфигурации).

docker run -d \
  --name postgres_db \
  -v db_data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:16-alpine

docker run -d \
  --name postgres_db \
  --mount source=db_data,target=/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:16-alpine

4. Bind Mounts

Bind Mounts монтират съществуваща директория или файл от хост системата директно в контейнера.

docker run -d \
  --name web_server \
  -p 80:80 \
  -v /srv/mywebsite:/usr/share/nginx/html:ro \
  nginx:alpine

В горния пример суфиксът :ro означава Read-Only. Контейнерът може да чете файловете, но няма право да ги променя или изтрива.

5. tmpfs Mounts

Когато не искате данни да се записват на диска (нито в контейнера, нито на хоста), използвате tmpfs. Данните се съхраняват в RAM паметта и се изтриват моментално при спиране на контейнера.

docker run -d \
  --name secure_app \
  --tmpfs /tmp/secrets:rw,noexec,nosuid,size=64m \
  myapp:latest

6. Сравнителна таблица

7. Архивиране и възстановяване на Volumes

Тъй като Volumes се намират под контрола на Docker Engine, най-безопасният начин за правене на backup е чрез временен контейнер.

7.1. Backup на Volume

docker run --rm \
  -v db_data:/volume \
  -v $(pwd):/backup \
  alpine tar -czvf /backup/db_data_backup.tar.gz -C /volume .

Това създава архива db_data_backup.tar.gz в текущата работна директория на хоста.

7.2. Restore (Възстановяване) на Volume

# 1. Създаване на новия volume
docker volume create db_data_new

# 2. Разархивиране на данните вътре в него
docker run --rm \
  -v db_data_new:/volume \
  -v $(pwd):/backup \
  alpine sh -c "cd /volume && tar -xzvf /backup/db_data_backup.tar.gz"

8. Права за достъп (UID / GID) и Permissions

При монтиране на Bind Mounts често възникват проблеми с правата за писане. Процесът вътре в контейнера може да работи с даден UID (напр. 1000 или 999), който няма права да пише в директорията на хоста.

docker run -d \
  --user $(id -u):$(id -g) \
  -v $(pwd)/app:/app \
  node:18-alpine npm start

9. Почистване на неизползвани Volumes

Когато премахвате контейнери с docker rm, свързаните с тях Named Volumes не се изтриват автоматично. С времето те могат да заемат значително дисково пространство.

# Преглед на неизползваните volumes
docker volume ls -q -f dangling=true

# Премахване на всички неизползвани volumes
docker volume prune