كيفية اتخاذ قرار بين حاوية حجم عامل الميناء وحجم عامل الميناء?

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

يبدو أن هناك 3 خيارات:

  1. ببساطة تعيين حجم لاستضافة الدليل (أي. -v حجة ل docker run)
  2. إنشاء صورة حاوية عامل ميناء للبيانات (أي حاوية منفصلة و --volumes-from)
  3. إنشاء وحدة تخزين عامل ميناء (أي. docker volume create)

الآن ، يبدو أن الممارسة المقبولة هي الخيار # 2 ، ولكن بعد ذلك أتساءل ما هو الغرض من #3.

خاصة كيف تتعامل مع هذه السيناريوهات بشكل صحيح docker volume وهل من الأفضل استخدام حاوية حجم البيانات أو هذا لكل حالة?

  • تحتاج إلى بيانات التطبيق في وحدة تخزين منفصلة و/أو مستوى تخزين في الخادم الخاص بك
  • النسخ الاحتياطي
  • استعادة البيانات

اعتبارا من عامل الميناء 1.9 ، إنشاء مجلدات مسماة مع وحدات التخزين واجهة برمجة التطبيقات (docker volume create --name mydata) يفضل على حاوية حجم البيانات. اعتبارا من فبراير 2016 ، عامل الميناء مجلدات الوثائق هو محزن خارج التاريخ. الناس في عامل الميناء أنفسهم تشير إلى أن حاويات حجم البيانات "لم تعد تعتبر نمطا موصى به,” “يجب أن تكون المجلدات المسماة قادرة على استبدال مجلدات البيانات فقط في معظم الحالات (إن لم يكن كلها، "و"لا يوجد سبب يمكنني رؤيته لاستخدام حاويات البيانات فقط.”

أعتقد أن #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 ، لكنني لست من ذوي الخبرة مع عامل الميناء ، لذلك قد يتغير هذا.

#1 ليس خيارا جادا للإنتاج ؛ يجب ألا يتم ذلك أبدا في حالة وجود بديل.