Docker Volume چیست؟ تفاوت Volume و Bind Mount و مدیریت داده کانتینرها

خلاصه سریع: اگر داده مهم را فقط داخل فایل‌سیستم خود کانتینر نگه دارید، با حذف یا بازسازی کانتینر ممکن است آن داده از بین برود. در Docker برای نگهداری پایدار داده معمولاً از Volume یا Bind Mount استفاده می‌شود. Volume توسط خود Docker مدیریت می‌شود و برای دیتابیس‌ها و داده‌های Production انتخاب پیش‌فرض بهتری است؛ Bind Mount یک مسیر واقعی از فایل‌سیستم میزبان را مستقیم داخل کانتینر Mount می‌کند و برای کد، فایل‌های تنظیمات و سناریوهایی که باید از سمت Host به فایل‌ها دسترسی داشته باشید مناسب‌تر است.

Docker Volume چیست؟

Docker Volume یک فضای ذخیره‌سازی مستقل از فایل‌سیستم داخلی کانتینر است که Docker آن را روی Host ایجاد و مدیریت می‌کند. وقتی Volume را به مسیر مشخصی داخل کانتینر Mount می‌کنید، داده‌های نوشته‌شده در آن مسیر در Volume ذخیره می‌شوند و با حذف و ساخت مجدد کانتینر از بین نمی‌روند؛ مگر اینکه خود Volume را هم صراحتاً حذف کنید.

برای مثال، اگر MySQL را داخل کانتینر اجرا می‌کنید، نگهداری دیتابیس فقط در Writable Layer کانتینر ایده خوبی نیست. بهتر است مسیر داده MySQL مثل /var/lib/mysql روی یک Volume قرار بگیرد.

چرا نگهداری داده داخل خود کانتینر خطرناک است؟

کانتینرها برای قابل‌جایگزین‌بودن طراحی شده‌اند. در عمل ممکن است برای آپدیت Image، تغییر تنظیمات، Deployment یا بازیابی سرویس، کانتینر قدیمی حذف و کانتینر جدید ساخته شود. اگر داده دائمی فقط در Writable Layer کانتینر باشد، حذف کانتینر می‌تواند آن داده را هم حذف کند.

این موضوع برای دیتابیس، فایل‌های آپلود کاربران، Assetهای تولیدشده در زمان اجرا و هر داده‌ای که باید بعد از Recreate باقی بماند مهم است. استفاده از Volume باعث می‌شود چرخه عمر داده از چرخه عمر کانتینر جدا شود.

تفاوت Docker Volume و Bind Mount چیست؟

قاعده ساده این است: اگر داده متعلق به برنامه است و Docker باید آن را مدیریت کند، Volume انتخاب خوبی است. اگر لازم است یک مسیر مشخص از سرور را مستقیم داخل کانتینر ببینید، Bind Mount منطقی‌تر است.

ساخت و مدیریت Docker Volume

برای ساخت یک Volume با نام app_data:

docker volume create app_data

برای مشاهده Volumeها:

docker volume ls

برای دیدن جزئیات یک Volume:

docker volume inspect app_data

و برای حذف Volume‌ای که دیگر استفاده نمی‌شود:

docker volume rm app_data

هشدار: قبل از حذف هر Volume مطمئن شوید داده مهمی داخل آن نیست و در صورت نیاز Backup معتبر دارید.

مثال عملی: اجرای MySQL با Docker Volume

نمونه ساده زیر یک Volume را به مسیر داده MySQL متصل می‌کند:

docker run -d 
  --name mysql-db 
  -e MYSQL_ROOT_PASSWORD='StrongPassword' 
  --mount source=mysql_data,target=/var/lib/mysql 
  mysql:8

در این مثال داده MySQL داخل Volume با نام mysql_data ذخیره می‌شود. اگر کانتینر mysql-db حذف شود، Volume همچنان باقی می‌ماند و می‌توان آن را به کانتینر دیگری متصل کرد.

در محیط Production رمز عبور را داخل History شل یا فایل‌های عمومی نگه ندارید و برای Secretها روش مناسب‌تری در نظر بگیرید.

Bind Mount چیست و چه زمانی بهتر است؟

Bind Mount یک فایل یا پوشه واقعی از سیستم‌عامل میزبان را داخل کانتینر Mount می‌کند. مثلاً اگر کد پروژه روی مسیر /srv/myapp قرار دارد و می‌خواهید کانتینر همان فایل‌ها را ببیند:

docker run --rm 
  --mount type=bind,src=/srv/myapp,dst=/app 
  nginx:alpine

این روش در محیط توسعه، ویرایش زنده فایل‌ها، Mount کردن Configها یا اشتراک‌گذاری مستقیم مسیرهای Host بسیار کاربردی است.

نکته مهم این است که Bind Mount کانتینر را به ساختار فایل‌سیستم همان Host وابسته می‌کند. اگر کانتینر روی سرور دیگری اجرا شود، باید همان مسیر و فایل‌ها آنجا هم وجود داشته باشند.

Volume و Bind Mount در Docker Compose

اگر قبلاً با Docker Compose کار می‌کنید، تعریف Volume بسیار ساده است:

services:
  db:
    image: mariadb:11
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

برای Bind Mount نیز می‌توانید مسیر Host را مستقیم مشخص کنید:

services:
  web:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

گزینه :ro دسترسی Mount را Read-only می‌کند و برای فایل‌های تنظیمات در بسیاری از سناریوها انتخاب امن‌تری است.

آیا Volume به‌تنهایی Backup محسوب می‌شود؟

خیر. Volume فقط داده را از چرخه عمر کانتینر جدا می‌کند؛ Backup نیست. اگر دیسک Host خراب شود، Volume حذف شود یا داده داخل آن Corrupt شود، داشتن Volume به‌تنهایی کمکی به بازیابی نمی‌کند.

برای داده‌های مهم باید Backup مستقل و قابل‌بازیابی داشته باشید. مثلاً برای دیتابیس بهتر است علاوه بر Backup فایل‌سیستم، Dump منطقی دوره‌ای هم داشته باشید و Restore را واقعاً تست کنید.

یک روش عمومی برای آرشیوکردن محتوای Volume می‌تواند استفاده از یک کانتینر موقت باشد:

docker run --rm 
  -v app_data:/data 
  -v $(pwd):/backup 
  alpine 
  tar czf /backup/app_data.tar.gz -C /data .

این مثال عمومی است؛ برای دیتابیس‌های در حال اجرا بهتر است از روش Backup سازگار با همان دیتابیس استفاده شود تا Consistency داده حفظ شود.

tmpfs چه تفاوتی با Volume دارد؟

Docker علاوه بر Volume و Bind Mount از tmpfs هم پشتیبانی می‌کند. tmpfs داده را در حافظه نگه می‌دارد و برای اطلاعات موقت، Cache یا داده‌ای که نباید روی دیسک باقی بماند مناسب است. با پایان چرخه Mount، داده tmpfs پایدار نمی‌ماند؛ بنابراین برای دیتابیس یا فایل دائمی مناسب نیست.

بهترین انتخاب برای Production چیست؟

برای بیشتر سرویس‌های Production روی یک سرور مجازی، این الگو کاربردی است:

• دیتابیس و داده‌های دائمی برنامه: Named Volume
• Configهای کنترل‌شده و Read-only: Bind Mount
• کد پروژه در Development: Bind Mount
• داده حساس و موقت: tmpfs در صورت تناسب
• Backup: مستقل از خود Volume و با تست Restore

همچنین از حذف بی‌برنامه Volumeها با دستورهایی مثل docker volume prune خودداری کنید. این دستور می‌تواند Volumeهای بدون استفاده را حذف کند و اگر درک دقیقی از وابستگی‌ها ندارید، ریسک از دست‌رفتن داده ایجاد می‌کند.

اشتباهات رایج در مدیریت داده Docker

• ذخیره دیتابیس فقط داخل Writable Layer کانتینر.
• فرض اینکه Volume همان Backup است.
• استفاده از Bind Mount با مسیرهایی که روی سرور مقصد وجود ندارند.
• دادن دسترسی Write غیرضروری به فایل Config.
• اجرای docker volume prune بدون بررسی.
• حذف Volume هنگام docker compose down بدون توجه به گزینه‌های حذف Volume.
• نداشتن تست Restore برای داده‌های مهم.

عیب‌یابی: چرا فایل‌ها داخل کانتینر دیده نمی‌شوند؟

اگر بعد از Mount فایل موردانتظار را نمی‌بینید، ابتدا نوع Mount را بررسی کنید:

docker inspect CONTAINER_NAME

در بخش Mounts می‌توانید Source، Destination و نوع Mount را ببینید. در Bind Mount مطمئن شوید مسیر Source روی Host واقعاً وجود دارد و Permission آن مناسب است. در Volume نیز نام Volume و مسیر Target داخل کانتینر را بررسی کنید.

اگر روی یک مسیر داخل کانتینر قبلاً فایل وجود داشته و سپس Mount دیگری روی همان مسیر قرار داده‌اید، محتوای اصلی آن مسیر تا زمانی که Mount فعال است پشت Mount پنهان می‌شود؛ این رفتار را با حذف فایل اشتباه نگیرید.

سوالات متداول

Docker Volume چیست؟

فضای ذخیره‌سازی پایداری است که Docker آن را جدا از فایل‌سیستم داخلی کانتینر مدیریت می‌کند و برای نگهداری داده دائمی مناسب است.

برای MySQL از Volume استفاده کنیم یا Bind Mount؟

در بیشتر سناریوهای معمول، Named Volume انتخاب ساده‌تر و قابل‌حمل‌تری است. Bind Mount زمانی مناسب‌تر است که دلیل مشخصی برای کنترل مستقیم مسیر Host داشته باشید.

آیا حذف کانتینر Volume را هم حذف می‌کند؟

به‌صورت معمول Named Volume با حذف کانتینر باقی می‌ماند، مگر اینکه صراحتاً دستور حذف Volume داده شود یا از گزینه‌ای استفاده کنید که Volumeهای مرتبط را حذف کند.

آیا Bind Mount امن است؟

می‌تواند امن باشد، اما چون کانتینر مستقیماً به مسیر Host دسترسی دارد باید Permission و Read-only بودن Mount را با دقت تنظیم کنید. دسترسی Write غیرضروری می‌تواند ریسک ایجاد کند.

برای Backup Volume چه کنیم؟

برای فایل‌های عمومی می‌توان از آرشیو Volume استفاده کرد، اما برای دیتابیس بهتر است از ابزار Backup خود دیتابیس و برنامه بازیابی تست‌شده استفاده کنید.

جمع‌بندی

Docker Volume و Bind Mount هر دو برای خارج‌کردن داده از فایل‌سیستم داخلی کانتینر استفاده می‌شوند، اما فلسفه متفاوتی دارند. Volume توسط Docker مدیریت می‌شود و برای داده دائمی برنامه انتخاب پیش‌فرض مناسبی است؛ Bind Mount کنترل مستقیم روی فایل‌های Host می‌دهد و برای کد، Config و سناریوهای توسعه بسیار مفید است. مهم‌تر از انتخاب نوع Mount، این است که داده حیاتی را از چرخه عمر کانتینر جدا کنید و Backup مستقل و قابل‌بازیابی داشته باشید.

منابع: Docker Storage Documentation، Docker Volumes، Docker Bind Mounts.