Compose: أضف "نسخ" إلى تكوين yaml

ما هي دلالات copy هنا؟ هل نقوم بنسخ الملفات من المضيف حيث يتم تشغيل docker-compose من الحاوية قيد التشغيل حديثًا باستخدام docker cp ؟

AFAIK هناك _لا توجد طريقة حالية للقيام بذلك:

نرى:

باش #!
$ عامل ميناء cp -h

الاستخدام: docker cp [الخيارات] حاوية: PATH HOSTDIR | -

نسخ الملفات / المجلدات من PATH على الحاوية إلى HOSTDIR على المضيف
تشغيل الأمر. استخدم "-" لكتابة البيانات كملف tar إلى STDOUT.

--مساعدة = استخدام طباعة خاطئة
""

ما هي دلالات النسخ هنا؟ هل نقوم بنسخ الملفات من المضيف حيث يتم تشغيل docker-compose من الحاوية قيد التشغيل حديثًا باستخدام docker cp؟

نعم

AFAIK لا توجد طريقة حالية للقيام بذلك:

أرى أن الأمر docker cp غير قادر على القيام بذلك. ومع ذلك ، لا يزال من الممكن الوصول إلى بيانات الحاوية على الجانب المضيف (والتي أعتبرها قبيحة)

http://stackoverflow.com/a/24805696/210090

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

الآن بعد أن أضاف docker-1.8 دعمًا للنسخ إلى حاوية عبر docker cp و swarm-0.4.0-rc2 أضاف دعمًا لـ docker cp ، سيكون من الرائع إعادة النظر في هذه المشكلة على مستوى الإنشاء. إليك حالة الاستخدام (التي تعكس ما نفعله بالفعل في _أغلب_ الإنتاج الآن):

ملف docker-compose.yml يذكر العديد من الحاويات بواسطة علامة صورة مبنية من CI (أي أننا لا نستخدم build: في الإنتاج ؛ ربما يمكننا الآن ولكن لم يتم اللعب بشكل جيد مع swarm في الإصدارات السابقة) التي تحتاج جميعها ، على سبيل المثال ، إلى تعيين ملفات تكوين hadoop ثابتة تتطابق تمامًا مع بيئة النشر. في الوقت الحالي ، يجب على المرء مزامنة الدليل الذي يوجد فيه docker-compose.yml على المسار الدقيق على كل آلة عامل إرساء مستهدفة في السرب. ثم يضيف أحدهم مكدسًا من خطوط volume: .

سيسمح دعم docker cp بإزالة مزامنة ملف التكوين المخصص في طريقة نشر النظام لدينا ويسمح بتحكم أفضل في وقت إدخال تغييرات التكوين (نظرًا لأن أي شخص يغير الملفات المذكورة في خطوط volume: يؤثر على جميع الحاويات التي تم نشرها مسبقًا (وبغض النظر عن الوقت الذي أعادت فيه التطبيقات الداخلية قراءة التكوين المذكور ، ربما فقط عند إعادة تشغيل الحاوية التالية ، ربما عند بدء تشغيل الأدوات المختلفة داخل الحاوية ؛ وهو ما قد يكون غير متوقع) والمستقبل (وهو أمر متوقع).

OTOH ، (كما ذكرنا باختصار أعلاه) ربما يجب أن نستخدم build: . الجانب السلبي هنا هو أننا نحتاج إلى كتابة Dockerfile إضافي لكل نوع حاوية نشر. واحد للصور المبنية CI والثاني لحاقن ملف التكوين الثابت. copy: مدعومًا بالتغييرات الأخيرة إلى docker cp سيسمح لنا بدقة بتجنب كل هذا الازدواجية.

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

Bedies docker-machine لديه docker-machine scp أي حال يمكنك القيام به مع إعداد الجهاز ؛ وبعد ذلك يمكنك عمل مجلدات المضيف بالطريقة العادية ، مثل docker أو docker-compose

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

لا يمكنك نشر حاوية حجم البيانات على عقدة للغاية عبر السرب نفسه على أي حال كما يمكنك مع أي استراتيجية جدولة حاوية أخرى؟

"Bedies docker-machine has docker-machine scp على أي حال وهو ما يمكنك القيام به مع إعداد الجهاز ؛ وبعد ذلك يمكنك عمل وحدات تخزين مضيفة بالطريقة المعتادة مثل docker أو docker-compose"
أنا أفعل هذا حاليًا. إنه مؤلم. ينسى الأشخاص الذين يديرون عمليات النشر نقل ملفات التكوين. إذا كان مدعومًا في docker-compose yml ، فسيحدث ذلك عندما يتم إعادة إنشاء حاوية بدون الخطوة (الخطوات) اليدوية.

"ألا يمكنك نشر حاوية حجم بيانات على عقدة معينة عبر السرب نفسه على أي حال كما يمكنك مع أي استراتيجية جدولة أخرى للحاويات؟"
ربما يمكننا ولكن أعترف أنني لا أرى كيف في ضوء التوسع.

"ألا يمكنك نشر حاوية حجم بيانات على عقدة معينة عبر السرب نفسه على أي حال كما يمكنك مع أي استراتيجية جدولة أخرى للحاويات؟"
هم ، إذا علمت أن حجم سربي هو 10 عقد ؛ هل يمكنني فقط قياس حجم حاوية حجم البيانات لتكون بحجم 10 مع سياسة عدم السماح بالمغادرين على عقدة محرك عامل إرساء معينة؟ المشكلة (إلا إذا فاتني شيء ما) هي أنه على سبيل المثال ، الحاويات التي تحتاج إلى الإشارة إلى أن حجم البيانات ليس لديها طريقة - الحجم - من حاوية مع فهرس مطابق. يا رفاق ، لقد كنت أبحث في هذه المشكلة لمدة شهرين حتى الآن. أفضل ما يمكنني فعله هو إنشاء برنامج نصي يستخدم docker-machine scp . لكنها خطوة يدوية بعد تحرير ملف التكوين وقبل docker-compose up . كما يتطلب أيضًا أنه يمكن للمرء أن يكتب المسار الدقيق على الأجهزة المستهدفة للسرب باعتباره جذر عامل التحميل compose.yml (أي أنه يشبه رائحة اختراق رئيسي).

ربما يمكن أن تساعد جهودي في المصنع في أتمتة عملية تدوير آلات الرصيف و clsuters مع البيانات "الصحيحة" الموجودة هناك جاهزة للاستخدام؟ (_ على الرغم من أنها لا تزال في مرحلة التطوير المبكرة وأنا أستخدمها للجمع بين docker-machine و docker-compose في setp_0 واحدة.

copy هي عملية وليست جزءًا من تكوين الخدمة ، لذا فهي لا تنتمي إلى ملف الإنشاء.

يقوم Docker 1.9 بإضافة وحدات تخزين جديدة ، وبرامج تشغيل وحدة التخزين موجودة بالفعل. الأحجام هي حقًا الطريقة الصحيحة لدعم هذا. لا تحاول نسخ الملفات.

شكرا على اقتراحك! لكنني لا أعتقد أن هذا يتناسب حقًا مع تصميم الإنشاء الآن.

تعد عملية النسخ عملية وليست جزءًا من تكوين الخدمة ، لذا فهي لا تنتمي إلى ملف الإنشاء.

ماذا لو أراد المرء نسخ ملف التكوين فقط؟ (إلى سرب عمال الرصيف ، لذا لن يعمل volume_from)

لدي نفس الموقف تمامًا ، وأريد نسخ ملفات التكوين mysql و nginx و haproxy وما إلى ذلك ، ولدينا مجموعات في الإنتاج ، وبدلاً من استخدام أمر نسخة واحدة لنسخ التكوينات من المحلي إلى البعيد

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

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

ضرب نفس المشكلة. أنا أعيد استخدام Dockerfile لـ N من الخدمات المختلفة ولا أرغب في إنشاء N مختلفة Dockerfiles باستخدام أمر COPY الخاص بهم أو إنشاء وحدة تخزين لذلك فقط.

راجع للشغل أنا حاليًا أقوم بحل ذلك عن طريق تشغيل عشرات الأسطر من أوامر sed - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

ربما ليس الحل الأمثل ولكنه يعمل مع الأخذ في الاعتبار أن docker-compose لا يدعم نسخ الملفات.

بالمناسبة ، فإن التثبيت والنسخ بالطبع ممكن ، لكنه يتعارض مع عروض إنشاء عامل تشغيل الأتمتة - إذا كنت أفضل القيام بكل شيء يدويًا ، فلن أستخدم إنشاء عامل ميناء ، أليس كذلك؟

كلما تعمقت في Docker ، يبدو أن الكثير من هذه الأدوات مفيدة لـ "hello world" / "انظر إلى مدى السرعة التي يمكنني بها تدوير هذا الشيء الرائع باستخدام \ shell \ commands \ like \ this \" على حالات استخدام نوع آلة واحدة (بما في ذلك عامل الإرساء). إذا تجاوز الأمر كثيرًا ، تبدأ الأشياء في التعقيد تمامًا وتنهار المنظمة البحرية الدولية قليلاً ، حيث يمكن لأدوات التزويد التقليدية أن تأتي وتنقذ اليوم عند استخدامها بشكل مناسب.

لقد اكتشفت أن استخدام Ansible لإعداد الأجهزة بطريقة مثالية ليكون سهلاً للغاية عندما يكون لدي مجلدات وملفات وملفات تهيئة نموذجية خاصة بالآلة يجب أن تكون موجودة حتى تبدأ صورة عامل الإرساء. ثم في النهاية يمكنني استخدام Ansible لاستدعاء docker-compse أو حتى استخدام وحدة Ansible docker التي يتطابق تركيبها تمامًا مع تكوين عامل الإرساء مع بعض الميزات الإضافية الرائعة.

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

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

مثال بسيط هو إنشاء حاوية ، ونسخ التكوين عبر المكان الصحيح ، وبدء الحاوية بمجرد نسخ التكوين.

يسمح هذا بإنشاء صور لا تتضمن التكوين الفعلي ونشر التكوين فقط عند بدء تشغيل الحاوية.

بالتأكيد سيكون مفيدًا جدًا. أنا أعمل مع صورة postgres كنهاية خلفية لقاعدة البيانات الآن ولا أريد إعادة بنائها ، فقط لتحديث برنامج نصي في مجلد /docker-entrypoint-initdb.d .

لماذا لا تعيدون فتح هذه المشكلة حتى يتم تنفيذ الميزة أو يتم العثور على حل عملي يحبه الأشخاص ، حيث لا أحد هنا يحب الخيارات المقترحة؟

يجب إعادة فتح هذه المشكلة ، كما ذكر ctindel .

+1 لإعادة فتح المشكلة

+1 للفتح أيضًا.

+1 لإعادة الفتح.

+1 لإعادة الفتح.

+1 لإعادة الفتح.

+1 لإعادة الفتح.

+1 لإعادة الفتح.

+1 لإعادة الفتح.

ما الخطأ في الحجم للقراءة فقط؟

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

michaelarnauts انظر هذا .

👍 لإعادة الفتح

+1 لإعادة الفتح.

+1 لإعادة الفتح.

+1 لإعادة الفتح

+1 لإعادة الفتح

+1 لإعادة الفتح

+1 لإعادة الفتح

+1 لإعادة الفتح

+1 لإعادة الفتح

هذا هو الأساس المنطقي للسماح بنسخة في Compose.

لدي تطبيق يعمل على العديد من الحاويات. من أجل الجدل ، لنفترض أنهم جميعًا يديرون Apache. لديهم جميعًا تعريفات DocumentRoot التي تشير إلى أشياء مثل "/ var / www / partX". لا يعرف Dockerfile أي شيء عن محتويات تكوين Apache ، ويحدد Compose مرجع وحدة التخزين لـ / var / www / partX. يعمل هذا بشكل رائع للتطوير ، لأنه يمكنني تصحيح الأخطاء وتعديل التعليمات البرمجية دون تعديل محتويات الحاوية.

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

أفضّل الاحتفاظ بمجموعة واحدة من Dockerfiles ، والقيام بالمزامنة في ملف Compose. سيكون الإنشاء هو المكان الذي أحدد فيه ما إذا كنت سأقوم بإعداد / var / www / partX كوحدة تخزين مشتركة أو إذا كنت أنسخ الملفات في الحاوية.

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

يبدو أنه يمكنني كتابة تغييرات على تعريفات Dockerfile لنسخ الملفات بشكل شرطي ، ولكن يبدو أنه من "المنطقي" التعامل مع كل منطق Docker الخاص بي في عالم Docker ، ويبدو إنشاء مكان منطقي للقيام بذلك.

+1 لإعادة الفتح.

+1. سيكون من المفيد جدًا نسخ ملف التكوين في ملف docker-compose.yml بدلاً من Dockerfile .

+1. ركضت للتو في محاولة توفير ملف تكوين للخدمة. يبدو حجم القراءة فقط كخيار ، ولكنه يفضل نسخه.

مجرد تركيب وحدة تخزين يمكن أن يفي بالغرض:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

raszi - ياه ، التكوين المركب هو الاتجاه الذي سنذهب إليه الآن. كان أحد الأشياء التي أحببتها حقًا في Docker هو فكرة الحاوية المستقلة التي يمكنني تشغيل اختبارات التكامل عليها ، دون أي قلق بشأن التبعيات الخارجية (مثل التكوين المرتبط). إذا كنت أقوم بعمليات نشر باللون الأزرق / الأخضر أو ​​A / B ، وكانت هناك اختلافات في التكوينات المستخدمة بواسطة إصدارات مختلفة من الحاويات ، فقد تصبح الأشياء هشة قليلاً. يمكنني التغلب على هذا عن طريق القيام بأشياء مثل تعيين إصدارات لملفات التكوين في وحدة تخزين مشتركة لكل من بيئاتي ، ولكن يبدو الأمر أكثر تعقيدًا أو هشاشة مما يمكن أن يكون.

"تقوم حاويات Docker بتغليف جزء من البرنامج في نظام ملفات كامل يحتوي على كل ما يلزم للتشغيل: التعليمات البرمجية ووقت التشغيل وأدوات النظام ومكتبات النظام - أي شيء يمكن تثبيته على الخادم. وهذا يضمن أن البرنامج سيعمل دائمًا بنفس الطريقة ، بغض النظر عن من بيئتها ". بالنسبة لي ، من المفترض أن يشمل ذلك التكوين. يعد Compose نوعًا من إجراء "إنشاء / تجميع وتشغيل" ، وأعتقد أن بعضًا منا يرغب في أن يتمكن Compose من إجراء "إنشاء / تجميع وربط وتشغيل". إنها ليست الطريقة التي يعمل بها اليوم ، ويمكنني أن أفهم عدم وجود الحماس لسير هذا الطريق ، ولكن مهلا ، إنه منتدى ، لا يضر السؤال ؛)

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

+1 لإعادة الفتح.

+1

+1 لإعادة الفتح أو حل مختلف بدون مجلدات.

تستخدم حاليًا متغيرات البيئة في docker-compose.yml و j2 في docker-entrypoint.sh لتحليلها إلى ملفات التكوين قبل تشغيل التطبيق الرئيسي للحاوية. يناسبني ، على الرغم من أنها صورة مخصصة ولا يمكن استخدامها خارج الصندوق مع الصور الكاملة المتوفرة بالفعل.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 لإعادة الفتح

لإضافة إمكانية وجود ملف yaml مختلف لكل حاوية بدلاً من تكوين بناءً على متغيرات البيئة

+1 ميزة مطلوبة للغاية

+1 ، من الجيد أن يكون لديك ميزة!

+1

+1

+1

+1

+1 إعادة فتح. مرجعية

+1 هذه ميزة مطلوبة بشدة.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 لإعادة الفتح لأنها ستكون ميزة مفيدة للغاية

ربما يمكن أن تساعد ميزة القالب الخاصة بـ https://github.com/jwilder/dockerize بعضًا منكم

+1

+1

+1

+1

+1

+1 لإعادة فتح المشكلة

+1

استخدم أسرار عامل الإرساء ، في هذا المثال يتم استخدام الأسرار مع صورة nginx لنسخ شهادة الخادم وملف التكوين
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

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

إنه يتفوق على المضيف المتصاعد لوحدة تخزين لكل ملف تكوين تريد تضمينه.

كما قيل مسبقا:

...
أحجام:
- ./nginx/default.conf:/etc/nginx/conf.d/default. أسيوط: ريال عماني
- ./nginx/nginx.conf:/etc/nginx/nginx. أسيوط: ريال عماني
...

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

أعتقد أنه يمكن تصميم النسخ بشكل مشابه لعملية docker build ، حيث يتم عادةً شحن Dockerfile في مستودع git ، جنبًا إلى جنب مع جميع الملفات التي يحتاجها لإرسالها إلى سياق الإنشاء. لا يُسمح لـ Dockerfile بإرسال أي شيء موجود خارج هيكل الدليل الخاص به ، حتى لو كان مرتبطًا بشكل صحيح. يمكن أن يكون لدينا شيء مشابه مع الإنشاء ، حيث يكون src مقيدًا بالدليل (وتلك الموجودة أدناه) الخاص بـ docker-compose.yml . بشكل أساسي ، سيكون سير العمل ، docker-compose ينشئ الحاوية ، ثم لكل زوج src:dst ، ابحث عن src تحت الدليل الحالي ، وانسخه في الحاوية التي لم تبدأ ، ثم ابدأ الحاوية.

حاليًا ، يمكن تحقيق تجنب عمليات تحميل المضيف عن طريق إضافة Dockerfiles وإنشاء ملفات conf في صور معدلة ، ولكن هذا يبدو وكأنه مبالغة بالنسبة لي ، لأنه يتضمن إعادة وضع علامات على صورة جديدة ، أو إجبار المستخدمين لاستخدام السمة docker-compose build بدلاً من السمة المفضلة (IMO) image . إذا كنت تستخدم بالفعل السمة build في تعريف الخدمة الخاص بك ، وتريد القيام بالأشياء بهذه الطريقة ، فأنت مجبر على تلويث منشئ الصور الحيادي الخاص بك بملف تكوين شديد الرأي يجب أن ينتمي فقط إلى الإنشاء وعملية النشر.

+1 لميزة نسخ عامل عامل الإرساء

+1

+1

+1

+1 للنسخ.

+1 لميزة نسخ عامل عامل الإرساء. أعتقد أن الحجج المؤيدة أعلاه مقنعة.

+1 للنسخ

+1 للنسخ.

على الرغم من وجوده في POV. يمكن أن يصبح مفيدًا ولكن يمكن أيضًا أن يصبح خارج نطاق السيطرة أو يسيء استخدامه للعديد من المستخدمين ويمكن أن يجعل الحجم قديمًا. إذا كنت تحتاج فقط إلى وضع الملفات على الحاوية خاصة للسرب ، فيمكنك فقط استخدام التكوينات أو الأسرار ؛ ولكن بالنسبة لحالتي مثل وضع مجلدات ثابتة في حاوية nginx ، يجب أن أستخدم تصميمات متعددة المراحل في Dockerfile الخاص بي لوضع تلك المجلدات الثابتة في الحاوية التي تستغرق الكثير من العمليات قبل تحقيق هدفي. لذلك أعتقد أن إضافة خيار نسخ قد يكون مفيدًا للغاية

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 لإعادة الفتح

+1

+1 لإعادة الفتح

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

+1 لإعادة الفتح. لا يعد تركيب الحجم خيارًا دائمًا. ولهذا السبب أنشر هنا اليوم. أحتاج إلى تعديل عدد كبير من الحاويات يدويًا لنسخ الملفات فيها بسبب سيناريو فريد حيث يُحظر تركيب وحدة التخزين.

+!

+1

+1 لميزة نسخ عامل عامل الإرساء

+1

+1

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

+1

stuaxo لمجرد أن الكثير من الأشخاص يطلبون بنادق ، لا يعني أننا يجب أن

في هذه الحالة ، يجب إما تخزين الملفات المطلوبة بواسطة خدمة للتشغيل في البنية (تم الإعلان عنها في Dockerfile) ، أو إتاحتها من خلال المجلدات ، أو (في حالة docker stack / وضع Swarm) موجودة على هيئة config أو الأشياء السرية. يعد نسخ الملفات إلى وجهات متعددة محتملة وقت التشغيل بطيئًا وعرضة للخطأ وليس مرنًا للفشل.

في صحتك ، اعتذر إذا كان ذلك غاضبًا.
عندما تقول "تشغيل خدمة" أعتقد أنك تعني شيئًا طويل الأمد مثل خدمة الويب ، فإن Docker يغطي هذا جيدًا.

طبقات الرصيف والتخزين المؤقت مفيدة لأشياء أخرى ؛

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

استغرق هذا القليل من العمل لاستخدام عامل إنشاء عامل الإرساء لفصل MySQL و Apache ، لكنني لا أهتم إذا كان كل منهما متماسكًا معًا.

يعد التخزين المؤقت في Dockers أمرًا ممتعًا عند تجربة بناء مكتبات سطح المكتب مثل القاهرة. لقد نسيت تفاصيل معظم الأشياء التي كنت أحاول القيام بها ، ولكني كنت أكثر في بناء جانب الأشياء بدلاً من أي شيء يتعلق بتشغيل الخدمات.

يجب إضافة نسخة +1 من عامل الإرساء. يسمح بتدفق أسهل لملفات التكوين والتحديثات للحاويات.

استخدم docker cp و docker config

في الجمعة ، 2 مارس 2018 الساعة 21:19 ، كتب James Hahn [email protected] :

يجب إضافة نسخة +1 من عامل الإرساء. يسمح بتدفق أسهل بكثير
من ملفات التكوين والتحديثات للحاويات.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

جيمس ميلز / برولوجيك

البريد الإلكتروني: [email protected]
W: prologic.shortcircuit.net.au

+1 لنسخة عامل الإرساء. الفكرة هي أن يكون لديك نسخ فقط للملفات كما هو موضح هنا

+1

+1

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

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

أنا أتفهم مخاوفك ، لكن مجرد إخبار الجميع بأن حاجتهم ليست حقيقية لن يؤدي إلا إلى إبعاد الناس عن مشروعك والمجتمع الذي يريد استخدامه ودعم عملك. نريد العمل معك هنا لإيجاد حل ناجح ، ولكن كل ما تريد قوله هو أننا لسنا بحاجة إلى ما نعتقد أننا بحاجة إليه.

واو لا أصدق أن هذا لم يتم بعد. اعتقدت أن هذه الوظيفة الأساسية ستكون في عامل البناء الآن. يا جمال مشاريع OSS ...

تم حلها باستخدام docker-compose --force-recreate --rebuild ، فهي تنسخ الملفات الجديدة إذا تم تغييرها (أو هكذا يبدو). ليس مثاليا، لكنه يعمل.

+1

+1

+1

+1

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

+1

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

https://docs.docker.com/compose/compose-file/#configs

ومع ذلك ، أعتقد أن ما يريده الناس هو طريقة لدمج الملفات من المضيف إلى دليل في الحاوية مع تفضيل overwrite if exists ، بالطريقة التي تتوقع أن تعمل بها نسخة.

من الغريب بالنسبة لي أن تكوين volumes في ملف الإنشاء يحتوي على خيار nocopy :

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

والذي يوصف على هذا النحو:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

لذلك فإنه يعطل بالضبط ما هو المطلوب؟

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

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

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

تعديل:

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

أعتقد في الواقع أن هذا هو الحل للنتيجة المرجوة.

مرحبًا ، يا رفاق ، لمعلوماتك فقط ، من الأفضل إبداء إعجابهم بالرسالة الرئيسية حول هذه المشكلة بدلاً من إضافة تعليق "+1" ، حيث يمكن فرز المشكلات حسب عدد ردود الفعل التي تلقوها.

+1

+1 يرجى فريق Docker ، والنظر في مجتمعك.

@ shin- المشكلة الآن هي أن ميزة وحدات التخزين تجعل من المستحيل توصيل ملف تكوين واحد من وحدة تخزين خارجية في حاوية.

لنفترض أنني أريد توصيل ملف تهيئة nginx في /etc/something/whatever.conf دون القضاء على كل شيء آخر موجود في هذا المجلد. لا يمكنك إنشاء مجلد مسمى لملف واحد (راجع moby / moby # 30310) ، ولا يمكنك أيضًا إنشاء مجلد مجلد يحتوي على ملف واحد ، ثم قم بتركيب هذا الملف المعين في الحاوية (انظر moby / moby # 32582).

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

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

FWIW لم أعد مشرفًا على Compose ، ولكن يبدو لي أنه من الأفضل تقديم حالة الاستخدام هذه عن طريق حقن ملف التكوين في وقت الإنشاء باستخدام Dockerfile.

@ shin- لسوء الحظ ، ملفات التكوين غير معروفة في وقت الإنشاء ، يتم إعداد الصور على خادم CI قبل وقت طويل من معرفة أين سنقوم بنشرها وبأي تكوين.

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

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

ب) الحاجة إلى إضافة بعض الأدوات الأخرى التي تتعامل مع جميع التكوينات الخاصة بنا (والتي تضيف قدرًا كبيرًا من النفقات العامة للمشاريع الصغيرة إلى متوسطة الحجم التي تحتاج حقًا إلى نسخ .conf و. env محددة لكل حاوية ، وهو شيء أنت لا ترغب في القيام به في وقت إنشاء الصورة ، وهذا يعادل القول أنه بدلاً من احتواء برنامجك على ملف تكوين ، يجب عليك ترميز جميع خياراتك في C ++ ، فهذا يؤدي إلى عشرات الصور الإضافية التي يجب صيانتها) ، أو

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