Docker Volumes: حفظ البيانات بعد حذف الحاويات
Docker Volumes وحدات تخزين يديرها Docker وتعيش خارج طبقة الكتابة الخاصة بالحاوية. تسمح لك بإعادة إنشاء التطبيق دون فقد البيانات المرتبطة بوحدة التخزين. لكن بقاء البيانات بعد حذف الحاوية لا يجعل الوحدة نسخة احتياطية؛ حذف الوحدة أو تلف الجهاز قد يفقدك البيانات نفسها.
سنختبر الفكرة بملف نصي بدل قاعدة بيانات، حتى ترى الفرق بوضوح. تحتاج إلى محرك Docker يعمل. يمكنك مراجعة شرح Docker وتشغيل أول حاوية قبل المتابعة. النتائج المذكورة متوقعة وفق سلوك الأوامر، ولم تُختبر على جهاز Docker أثناء كتابة المقال.
لماذا تختفي ملفات الحاوية عند حذفها؟
التغييرات التي تكتبها الحاوية خارج أي تخزين مرتبط تقع عادةً في طبقتها القابلة للكتابة. تبقى هذه الطبقة عند الإيقاف، لكنها تُزال مع حذف الحاوية. ولهذا لا يكفي استخدام stop بدل rm كخطة لحماية قاعدة بيانات.
تخيّل تحديث تطبيق إلى صورة جديدة. ستحتاج إلى إنشاء حاوية بديلة، بينما يجب أن تستمر ملفات المستخدمين أو قاعدة البيانات. فصل التخزين عن الحاوية يجعل التحديث ممكنًا دون ربط عمر البيانات بعمر عملية التطبيق.
ما الفرق بين Volume وBind mount وtmpfs؟
Volume مورد تخزين يديره Docker، وBind mount يربط مسارًا محددًا من المضيف، وtmpfs يوفر تخزينًا مؤقتًا في الذاكرة في البيئات التي تدعمه. اختر وفق طبيعة الملفات وطريقة إدارتها.
| النوع | من يحدد مكانه؟ | استخدام شائع |
|---|---|---|
| Volume | Docker عبر وحدة مسماة أو مجهولة | بيانات قواعد البيانات |
| Bind mount | أنت تحدد مسار المضيف | ملفات المصدر أثناء التطوير |
| tmpfs | تخزين مؤقت في الذاكرة | ملفات مؤقتة لا تحتاج للاستمرار |
لا تفترض أن كل Volume يمكن الوصول إليه مباشرةً من مجلد عادي في Windows أو macOS. قد يكون التخزين داخل بيئة Docker Desktop الافتراضية. استخدم أدوات Docker والنسخ الاحتياطي المناسبة بدل تعديل ملفات قاعدة البيانات يدويًا من خارجها.
تمرين Docker Volumes خطوة بخطوة
أنشئ وحدة مسماة تحمل اسمًا خاصًا بالدرس:
docker volume create g4a-notes-data
docker volume ls
docker volume inspect g4a-notes-data
الاسم يسهّل إعادة ربط الوحدة. أما inspect فيعرض معلوماتها، لكنه لا يختبر محتوى التطبيق أو سلامة النسخ الاحتياطية. أنشئ الآن ملفًا تجريبيًا داخل المسار المرتبط:
docker run --name g4a-writer --mount type=volume,source=g4a-notes-data,target=/data alpine:3.22 sh -c 'echo hello-volume > /data/note.txt'
docker ps -a
تنتهي الحاوية بعد كتابة الملف لأن الأمر الرئيسي انتهى. هذه نتيجة طبيعية للتجربة، وليست تعطلًا لخادم. احذف كيان حاوية التدريب ثم اقرأ الملف من حاوية أخرى:
docker rm g4a-writer
docker run --rm --mount type=volume,source=g4a-notes-data,target=/data,readonly alpine:3.22 cat /data/note.txt
المتوقع ظهور hello-volume. خيار readonly يجعل الربط للقراءة فقط في الحاوية الثانية. وخيار –rm يزيل هذه الحاوية بعد انتهاء الأمر؛ لا يزيل الوحدة المسماة التي استخدمناها.
هل المسار داخل الحاوية مهم؟
نعم. يجب ربط الوحدة بالمسار الذي يكتب إليه التطبيق فعلًا. إنشاء Volume دون ربطه بالمجلد الصحيح لا يحمي البيانات الموجودة في مسار آخر.
إذا كان التطبيق يخزن ملفاته في /app/uploads، فربط الوحدة إلى /data وحده لا ينقل تلك الملفات تلقائيًا. راجع إعداد التطبيق ومسار البيانات في وثائق الصورة. وينطبق ذلك بقوة على قواعد البيانات؛ لكل صورة إعداداتها ومسارها المتوقع.
كذلك قد يحجب الربط ملفات موجودة في المسار داخل الصورة. هذا لا يعني أن الملفات حُذفت من الصورة. قواعد تهيئة Volume فارغ ونسخ المحتوى إليه تختلف عن ربط مجلد مضيف؛ افهم السلوك قبل الربط فوق مجلد يحمل ملفات مهمة.
متى تستخدم Bind mount؟
استخدم Bind mount عندما تحتاج إلى العمل على ملفات المضيف مباشرةً، مثل تعديل صفحة أو شيفرة ومشاهدة أثرها داخل حاوية التطوير. يحتاج هذا النوع إلى مسار صحيح وصلاحيات مناسبة في نظامك.
مثال بنيوي يجب استبدال مساره بمجلدك الحقيقي:
docker run --rm --mount type=bind,source=/absolute/project/path,target=/work,readonly alpine:3.22 ls /work
المسار المعروض مثال لبيئة Linux وليس أمرًا جاهزًا لكل جهاز. في Windows تختلف كتابة المسار بحسب الطرفية وبيئة التشغيل. ميزة –mount هنا أنها تساعد على كشف مصدر غير موجود بدل إنشاء مجلد خاطئ دون أن تنتبه.
لماذا تظهر مشكلة Permission denied؟
قد تختلف هوية المستخدم داخل الحاوية عن مالك الملفات في التخزين. افحص المستخدم الذي يعمل به التطبيق وملكية المجلد، ثم أصلح الصلاحيات بالقدر الذي يحتاجه التطبيق.
لا تجعل chmod 777 حلًا افتراضيًا. منح الكتابة للجميع قد يخفي المشكلة ويزيد الوصول غير اللازم. وفي بيئات Linux قد تدخل إعدادات حماية النظام أيضًا في الموضوع. ابدأ برسالة الخطأ ومسار الملف وهوية العملية بدل تغيير صلاحيات المشروع كله.
كيف تخطط للنسخ الاحتياطي؟
احفظ نسخًا منفصلة عن الوحدة الأصلية واختبر الاستعادة. بالنسبة لقاعدة بيانات عاملة، استخدم أسلوبًا يضمن اتساق البيانات، مثل أدوات النسخ المنطقي الخاصة بها أو خطة نسخ مادية مدعومة.
نسخ مجلد قاعدة بيانات أثناء الكتابة إليه قد ينتج نسخة غير متسقة. كما أن نقل Volume إلى جهاز آخر لا يضمن توافق إصدار قاعدة البيانات أو إعداد التطبيق. وثّق الإصدار وطريقة الاستعادة، وجرّبها في بيئة مستقلة قبل الاعتماد عليها.
تنظيف تمرين التخزين
بعد التأكد من أنك لا تحتاج الملف التجريبي، يمكنك حذف وحدة هذا الدرس فقط:
docker volume rm g4a-notes-data
هذا الأمر يحذف بيانات الوحدة المحددة، لذلك لا تستبدل اسمها باسم تخزين مشروع فعلي. وتجنب أوامر التنظيف العام التي تشمل وحدات التخزين دون مراجعة. عند استخدام Compose لاحقًا، انتبه إلى أن down -v يطلب حذف وحدات مرتبطة بالمشروع وفق نوعها وإعدادها.
فهم Docker Volumes يمنحك قاعدة واضحة: الحاوية قابلة للاستبدال، والبيانات تحتاج عمرًا وخطة حماية مستقلين. قبل أي تحديث اسأل: أين تُكتب البيانات؟ وكيف أستعيدها إذا فُقدت الوحدة نفسها؟
أسئلة شائعة
هل إيقاف الحاوية يحذف بياناتها؟
لا يحذف الإيقاف طبقة الكتابة. لكن حذف الحاوية يزيلها، ولذلك نستخدم تخزينًا دائمًا للبيانات المهمة.
هل Volume نسخة احتياطية؟
لا. إنها مكان التخزين الأساسي وقد تُحذف أو تتلف. تحتاج نسخة منفصلة وخطة استعادة.
هل –rm يحذف الوحدة المسماة؟
لا يحذف الوحدة المسماة في مثالنا. يجب التمييز بينها وبين وحدات مجهولة وخيارات حذف أخرى.
هل يمكن مشاركة الوحدة بين حاويتين؟
يمكن ربطها بأكثر من حاوية، لكن أمان الكتابة المتزامنة يعتمد على التطبيق. لا تشغّل قاعدتي بيانات مستقلتين على الملفات نفسها.
المصادر والمراجعة التقنية
استُلهم ترتيب موضوعات السلسلة من ملاحظات Narayan Prasad (@code.withnarayan). الشرح العربي والأمثلة والرسوم هنا إعداد مستقل، مع الرجوع إلى الوثائق الرسمية لتصحيح وتوسيع المفاهيم.
مقالات ومعرفة تقنية باللغة العربية.
