أعتقد أن #2 و #3 هما نفس الشيء إلى حد كبير ، والفرق الرئيسي هو أنه لا توجد حاوية متوقفة مع #3 (إنها حرفيا ، مجرد وحدة تخزين مسماة). على سبيل المثال ، يمكنك إنشاء وحدة تخزين مسماة والقيام بالمثل بما ستفعله بالرقم 2 باستخدام -v بدلا من ذلك.
إنشاء وحدة تخزين مسماة:
$ docker volume create --name test
جبل وكتابة بعض البيانات إلى هذا الحجم من حاوية:
$ docker run -v test:/opt/test alpine touch /opt/test/hello
يمكنك بعد ذلك تركيب نفس الشيء test حجم في حاوية أخرى وقراءة البيانات:
$ docker run -v test:/opt/test alpine ls -al /opt/test total 8drwxr-xr-x 2 root root 4096 Jan 23 22:28 .drwxr-xr-x 3 root root 4096 Jan 23 22:29 ..-rw-r--r-- 1 root root 0 Jan 23 22:28 hello
الميزة هنا هي أن وحدة التخزين لن تختفي عن طريق الخطأ إذا قمت بإزالة حاوية البيانات فقط. يمكنك الآن إدارتها مع docker volume القيادة الفرعية.
$ d volume lsDRIVER VOLUME NAMElocal test
كما أنه يفتح إمكانيات للسائقين حجم على الطريق لذلك قد تكون قادرة على القيام وحدات التخزين المشتركة بين المضيفين (أي. مجلدات مسماة على نفس). ومن الأمثلة على ذلك فلوكر و قافلة. إلى وجهة نظرك على وجه التحديد حول نقل أو النسخ الاحتياطي للبيانات ، قافلة لديها أوامر فرعية محددة لنسخ البيانات احتياطيا ويسمح للتخزين على نفس أو إبس الخارجية إلى المضيف الخاص بك.
لهذا السبب ، أعتقد أن طريقة المدرسة الجديدة (عامل الميناء 1.9+) هي استخدام وحدة تخزين مسماة بدلا من حاوية بيانات فقط.
@دوكوفغامينغ ناهيك عن أنه يمكنك تشغيل بترفس فرك على ذلك لإيجاد وتصحيح الملفات التالفة. لست متأكدا من كيفية عمل الأشياء المرصفة ، لكنني أعتقد أنها لا تحمي من تعفن البيانات ، لذلك أحتاج دائما إلى استعادة كاملة إذا حدث شيء سيء بدلا من مجرد استعادة الملفات الفردية. يعتقد آخر أنه يضيف طبقة أخرى من التجريد ، لذلك يبطئ قراءة الملفات والكتابة أكثر من ذلك. أنا بطريقة ما لا أرى مزايا #2 و #3 ، لكنني لست من ذوي الخبرة مع عامل الميناء ، لذلك قد يتغير هذا.