عامل الميناء-مجلدات مقابل جبل يربط. ما هي حالات الاستخدام?

بعد القراءة واللعب حولها مع عامل الميناء لفترة قصيرة ، وأنا أفكر في استخدامه في بيئة الإنتاج بلدي. ومع ذلك أنا لا تزال تحاول فهم الفرق بين جبل يربط وأحجام.

وفقا لوثائق عمال الرصيف على ربط جبل (https://docs.docker.com/storage/bind-mounts/):

ربط يتصاعد كانت موجودة منذ الأيام الأولى من عامل الميناء. ربط يتصاعد لها وظائف محدودة مقارنة مع وحدات التخزين. عند استخدام جبل ربط ، يتم تثبيت ملف أو دليل على الجهاز المضيف في حاوية. تتم الإشارة إلى الملف أو الدليل من خلال مساره الكامل أو النسبي على الجهاز المضيف. على النقيض من ذلك ، عند استخدام وحدة تخزين ، يتم إنشاء دليل جديد داخل دليل تخزين عامل الميناء على الجهاز المضيف ، ويدير عامل الميناء محتويات هذا الدليل.

من هذا (ومن اللعب حولها) يبدو لي أن جبل يربط وأحجام هي نفس الشيء ، والفرق الوحيد هو موقع البيانات. (وحدات التخزين المخزنة في منطقة التخزين "الخاصة" عامل الميناء، في حين يربط جبل يمكن تخزينها في أي مكان). نعم ، يجب أن يكون ربط التثبيت موجودا قبل بدء تشغيل حاوية عامل الإرساء ، بينما يمكن إنشاء وحدات التخزين بواسطة محرك عامل الإرساء عند بدء تشغيل الحاوية-ولكن هذا الاختلاف هو أداء غير موقر أو صيانة حكيمة.

لم أتمكن من فهم الفوائد المفترضة للأحجام التي ذكرتها الوثائق (https://docs.docker.com/storage/volumes/) كما يبدو أن كل منهم ينطبق على جبل يربط بنفس الطريقة.

يمكن لأي شخص يرجى شرح الاختلافات الرئيسية بين وحدات التخزين وجبل يربط (الأداء والصيانة الحكمة) والأهم من حالات استخدامها?

شكرا للمساعدة.

افتراضيا ، وحدة تخزين اسمه المحلي هو بالضبط كما تصفون ، ربط جبل إلى دليل عامل ميناء خاص. الاختلافات أرى:

  • أولا ، واحد كبير هو اختلاف السلوك بين وحدات التخزين المسماة وأحجام المضيف (ويعرف أيضا باسم ربط يتصاعد). سوف عامل الميناء تهيئة وحدة تخزين اسمه من محتويات الصورة. وهذا يشمل أصحاب الملفات والأذونات. هذا يعني أنه يمكنك تجنب القلق بشأن مشكلات الأذونات التي يتم مواجهتها بشكل شائع مع وحدات تخزين المضيف.

  • ثانيا ، قابلية النقل. يمكن استخدام وحدات التخزين المسماة من مضيفات عامل ميناء مختلفة دون القلق بشأن مسارات نظام الملفات المحلي أو المستخدم الذي يقوم بتشغيل الأوامر. سواء كان ذلك على جهاز كمبيوتر محمول ماك ، أو خادم لينكس في الإنتاج ، يمكنك مجرد اسم وحدة تخزين وتفترض أنها ستعمل كجزء من عامل الميناء الافتراضي تثبيت.

  • ثالثا ، كيف تدار. تدار وحدات التخزين المضيف عادة خارج عامل الميناء الذي هو المكان الذي غالبا ما تأتي مشاكل إذن في اللعب (منذ إيد/جيد على المضيف عادة لا تتطابق مع إيد/جيد داخل الحاوية). باستخدام وحدات التخزين المسماة ، يمكنك إدارتها من داخل حاوية عامل ميناء أخرى حيث يمكنك التحكم في الأدوات المثبتة والمستخدمين الذين تم إنشاؤهم وما إلى ذلك.

هناك أيضا فرق كبير آخر مع وحدات التخزين المسماة. هذا لأنني قلت "بشكل افتراضي" أعلاه ، ويمكن تكوين حجم مسمى في عدد غير قليل من الطرق. يمكن تغيير برنامج تشغيل وحدة التخزين إلى برنامج تشغيل آخر يدرك السحابة. أو يمكنك تمرير الخيارات إلى برنامج تشغيل وحدة التخزين المحلية للتغيير من جبل الربط المحلي إلى دليل معين إلى أي شيء يمكنك القيام به مع جبل سيسكال. ويشمل ذلك إجراء ربط جبل إلى دليل مختلف ، جبل نفس ، ويمكنك حتى إنشاء نظام الملفات تراكب الخاصة بك كمجلد للسماح للحاويات للوصول وتعديل بعض البيانات داخل الحاوية دون تغيير الملفات الأساسية في طبقة أساسية.

باستخدام وحدات التخزين المسماة ، يمكنك أيضا فصل إدارة التخزين عن إدارة الحاويات. يمكنك ببساطة الإشارة إلى الاسم ويمكن لأداة خارجية إنشاء وحدة التخزين هذه للإشارة إلى الموقع المناسب في تلك البيئة.

تتضمن بعض الأمثلة على وحدات التخزين المسماة التي استخدمتها مع برنامج تشغيل وحدة التخزين المحلية ما يلي:

# named bind mount$ docker volume create --driver local \      --opt type=none \      --opt device=/home/user/test \      --opt o=bind \      test_vol# nfs$ docker volume create --driver local \      --opt type=nfs \      --opt o=nfsvers=4,addr=nfs.example.com,rw \      --opt device=:/path/to/dir \      foo# overlay$ docker volume create --driver local --opt type=overlay \    --opt o=lowerdir=${PWD}/ro-data,upperdir=${PWD}/upper1,workdir=${PWD}/work1 \    --opt device=overlay overlay1