إذا ذهبنا إلى هذا ، فأنا أفضل خيار RUNP ، بدلاً من امتلاكه
كل الحاوية تعمل في وضع الامتياز.

يوم الأربعاء 18 سبتمبر 2013 الساعة 1:07 مساءً ، بنيامين بودسون
إخطاراتgithub.com

في الوقت الحالي ، يبدو أنه لا توجد طريقة لتشغيل العمليات المميزة خارج نطاق
تشغيل عامل ميناء بامتياز.

هذا يعني أنه لا يمكنني فعل نفس الأشياء في Dockerfile. حديثي
المشكلة: أود تشغيل المصهر (لـ encfs) داخل الحاوية. التثبيت
المصهر هو بالفعل فوضى مع الاختراقات والحلول القبيحة (انظر [1] و [2]) ،
بسبب فشل mknod / عدم دعمه بدون خطوة إنشاء مميزة.

الحل الوحيد الآن هو إجراء التثبيت يدويًا باستخدام
run -privileged ، وإنشاء "صورة قاعدة الصمامات" الجديدة. مما يعني أنني
لا يمكن وصف الحاوية بأكملها ، من الصورة الأساسية الرسمية حتى النهاية ،
في ملف Dockerfile واحد.

لذلك أقترح إضافة أي منهما

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

أو

• أمر RUNP في Dockerfile
  يجب أن .. حسنًا .. RUN ، ولكن مع _P_rivileges

حاولت النظر إلى المصدر ، لكنني عديم الفائدة مع go ولم أتمكن من العثور على ملف
نقطة دخول لائقة لإرفاق دليل على المفهوم ، للأسف. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (تعليق) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/1916
.

فيكتور فيوكس
http://vvieux.com

في الواقع ، قد نضطر إلى القيام بالأمرين معًا - على سبيل المثال ، تتطلب RUNP + علامة "ذات امتياز"
علم.

إذا كنا نعتمد فقط على RUNP (دون الحاجة إلى "الامتياز") ، فإننا سنفعل ذلك
يجب أن نتساءل عندما نقوم بإنشاء "هل هذا البناء آمن؟".
إذا كنا نعتمد فقط على "-privileged" ، فإننا نفقد المعلومات (في
Dockerfile) أن "هذا الإجراء يتطلب امتيازات موسعة".

أعتقد أن الجمع بين الاثنين هو الطريقة الأكثر أمانًا.

يوم الأربعاء 18 سبتمبر 2013 الساعة 4:07 صباحًا ، بنيامين بودزون
إخطاراتgithub.com

في الوقت الحالي ، يبدو أنه لا توجد طريقة لتشغيل العمليات المميزة خارج نطاق
تشغيل عامل ميناء بامتياز.

هذا يعني أنه لا يمكنني فعل نفس الأشياء في Dockerfile. حديثي
المشكلة: أود تشغيل المصهر (لـ encfs) داخل الحاوية. التثبيت
المصهر هو بالفعل فوضى مع الاختراقات والحلول القبيحة (انظر [1] و [2]) ،
بسبب فشل mknod / عدم دعمه بدون خطوة إنشاء مميزة.

الحل الوحيد الآن هو إجراء التثبيت يدويًا باستخدام
run -privileged ، وإنشاء "صورة قاعدة الصمامات" الجديدة. مما يعني أنني
لا يمكن وصف الحاوية بأكملها ، من الصورة الأساسية الرسمية حتى النهاية ،
في ملف Dockerfile واحد.

لذلك أقترح إضافة أي منهما

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

أو

• أمر RUNP في Dockerfile
  يجب أن .. حسنًا .. RUN ، ولكن مع _P_rivileges

حاولت النظر إلى المصدر ، لكنني عديم الفائدة مع go ولم أتمكن من العثور على ملف
نقطة دخول لائقة لإرفاق دليل على المفهوم ، للأسف. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: # 514 (تعليق) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/1916
.

jpetazzo https://twitter.com/jpetazzo
آخر مشاركة مدونة: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

يبدو معقولا. بالنسبة لي ، فإن هذه الميزة (القدرة على إنشاء عقد الجهاز) تجعل أو توقف القدرة على إنشاء النشر في Docker. إذا كان بإمكاني المساعدة (الاختبار في الغالب ، فقد حاولت النظر إلى المصدر ولكن فشلت حتى الآن. يبدو أن الأوامر المتاحة في ملف البناء تم العثور عليها من خلال الانعكاس ، أضفت أمر runp الذي عيّن config.privileged إلى true ، لكنني حتى الآن أنا غير قادر على البناء والاختبار -> عالق) سأستثمر بعض الوقت بكل سرور.

أقترح RUNP + build -privileged .

_ يسلط الضوء على بعض إشارات الدخان لجذب انتباه shykes ،crosbymichael_

... وبعد ذلك علينا أن نجد من ينفذه بالطبع ☺
هل سيكون هذا شيئًا تريد تجربته (مع التوجيه المناسب وردود الفعل من الفريق الأساسي ، بالطبع)؟

إذا كان الجزء الأخير موجهاً إلي: بالتأكيد ، لم لا. أنا بالفعل أعبث برمز go (ليست لغة أعرفها جيدًا ، لكن انظر أعلاه: أحاول معرفة ما يحدث على أي حال).

مع وجود اثنين من المؤشرات / شخص ما لإجراء اختبار اتصال لبعض الأسئلة ، سأجربه بالتأكيد.

أنا لا أبيع على RUNP أو امتياز البناء.

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

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

-
تضمين التغريدة
تضمين التغريدة

يوم الجمعة ، 20 سبتمبر 2013 الساعة 3:18 مساءً ، بنيامين بودسون
كتب [email protected] :

إذا كان الجزء الأخير موجهاً إلي: بالتأكيد ، لم لا. أنا بالفعل أعبث برمز go (ليست لغة أعرفها جيدًا ، لكن انظر أعلاه: أحاول معرفة ما يحدث على أي حال).

مع وجود اثنين من المؤشرات / شخص ما لإجراء اختبار اتصال لبعض الأسئلة ، سأجربه بالتأكيد.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

حسنًا ، هل توافق على أنه يجب أن يكون من الممكن إنشاء صورة عامل إرساء تعمل - على سبيل المثال - على فتيل؟
لذلك نحن بحاجة إلى mknod.

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

أنا أواجه هذه المشكلة الآن. لإنشاء الصورة التي أحتاجها ، يجب أن أقوم بتنفيذ سلسلة من الخطوات run -privileged + خطوة commit ، بدلاً من build ing a Dockerfile. من الناحية المثالية ، سيكون من الجيد التعبير عن خطوات بناء الصورة في Dockerfile.

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

مرحبًا jpetazzo ، من القائمة البريدية ، ها هي المشكلة التي أواجهها: https://groups.google.com/forum/#!topic/docker -user / 1pFhqlfbqQI

أحاول أن أقوم بإنشاء mount a fs (تم إنشاؤه للعمل حول aufs وشيء عن تسجيل دفتر اليومية ) داخل الحاوية. الأمر المحدد الذي أقوم بتشغيله هو mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 ، حيث تم إنشاء /db/disk-image باستخدام dd if=/dev/zero of=disk-image count=409600 و home/db2inst1 حيث أحاول البدء من db2.

إذا فهمت بشكل صحيح ، أثناء عملية التثبيت ، فأنت بحاجة إلى دليل غير AUFS - أو بالأحرى شيء يدعم O_DIRECT . إذا كان الأمر كذلك ، فيجب أن يحل Docker 0.7 المشكلة ، لأنه سيستخدم ext4 (واللقطات على مستوى الكتلة) بدلاً من AUFS.

+1 لهذا أيضًا.

تركيب الحزم التي تتطلب تغيير إعدادات الذاكرة وتوصيف kernel (مثل Vertica DB ، WebSphere MQ) يمكن أن يتم فقط في الوضع المميز.

دعنا نحاول فصل الاهتمامات عندما يتعلق الأمر بالتشغيل / البناء باستخدام "الامتياز": يمكن أن يكون مطلوبًا فقط أثناء الإنشاء ، فقط أثناء التنفيذ عبر docker run أو كليهما.

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

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

حق. orikremer ، هل لديك تفاصيل عن المعامِلات التي يحاول كل من Vertica DB و WebSphere MQ تغييرها؟

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

على المدى الطويل ، قد يقوم نظام ملفات وهمي بالتقاط التغيير وتحويله إلى توجيهات Dockerfile ، وإرشاد وقت التشغيل إلى أن "هذه الحاوية تحتاج مثل هذا التعديل أو ذاك".

jpetazzo لقد مرت يومين منذ أن أنشأت الصورة. كان AFAIR Vertica يشكو من أنه لا يحتوي على ذاكرة كافية وكان كلاهما يحاول تغيير الحد الأقصى من الملفات المفتوحة.
سأحاول إعادة إنشاء الصورة باستخدام Dockerfile والإبلاغ عنها مرة أخرى.

مع ملاحظة أن المشكلة رقم 2080 مرتبطة بها.

jpetazzo بدأ

• لطيف في limits.conf: يضيف Vertica "dbadmin - لطيف 0" إلى /etc/security/limits.conf. عند محاولة التبديل إلى هذا المستخدم عند التشغيل في حاوية غير مميزة ، يظهر لي الخطأ "تعذر فتح الجلسة". في تبديل الحاويات ذي الامتيازات ، يعمل المستخدم بدون أخطاء.
• max open files: نظرًا لأن الحد الأقصى المطلوب في الحاوية كان أعلى من المجموعة الموجودة في المضيف ، فقد اضطررت إلى تغيير /etc/init/docker.conf على المضيف وتعيين "ملف تعريف محدود" ثم ulimit -n في الحاوية. هل هذا هو النهج الصحيح؟

عند محاولة التبديل إلى هذا المستخدم ،

كيف يحدث التبديل؟ لا أفهم كيف يمكن أن يساعد -privileged في التبديل بين المستخدمين ؛ ربما أفتقد شيئًا ما هنا :-)

ماكس الملفات المفتوحة

إذا فهمت بشكل صحيح ، يحاول المثبت الرأسي تعيين الحد الأقصى لعدد الملفات المفتوحة إلى عدد كبير جدًا ، وهذا لا يعمل إلا إذا بدأ Docker بهذا الرقم الكبير _or_ بعلامة -privileged ؛ حق؟

تبديل المستخدم - su dbadmin فشل بسبب هذا الخطأ.
تمكنت من التكاثر عن طريق:

• اسحب صورة جديدة (centos-6.4-x86_64) وقم بتشغيل بدون امتياز
• useradd testuser
• تحرير /etc/security/limits.conf ، إضافة "testuser - لطيف 0"
• المحاولة su testuser -> يجب أن تفشل مع "تعذر فتح الجلسة"
  في حاوية ذات امتيازات ، يعمل su testuser بشكل جيد.

max open files - صحيح. يحاول المثبت التعيين إلى رقم أعلى من رقم المضيف. فقط من خلال زيادة إعداد المضيفين أو البدء بامتياز يقوم بهذا العمل.

لقد حاولت للتو باستخدام Dockerfile التالي:

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

وهو يعمل بشكل جيد. ما هو الاسم الدقيق للصورة التي تستخدمها؟
(جربت centos-6.4-x86_64 لكن يبدو أنني لا أستطيع سحبه!)

lukewpatterson هل يمكنك مشاركة كيفية تشغيل نظام ملفات الحلقة داخل الحاوية الخاصة بك؟

jpetazzo تشغيل ملف عامل

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

فشل مع:

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

لقد قمت بتشغيل تصحيح الأخطاء لوحدة PAM (عن طريق إضافة debug إلى السطر pam_limits.so في /etc/pam.d/system-auth ) ، تثبيت syslog ، حاول su مرة أخرى ، وهذا ما وجدته في /var/log/secure :

7 أكتوبر 14:12:23 8be1e7bc5590 su: pam_limits (su: session): إعدادات القراءة من "/etc/security/limits.conf"
7 أكتوبر 14:12:23 8be1e7bc5590 su: pam_limits (su: session): process_limit: Processing - nice 0 for USER
7 أكتوبر 14:12:23 8be1e7bc5590 su: pam_limits (su: session): إعدادات القراءة من "/etc/security/limits.d/90-nproc.conf"
7 أكتوبر 14:12:23 8be1e7bc5590 su: pam_limits (su: session): process_limit: معالجة soft nproc 1024 للإعداد الافتراضي
أكتوبر 7 14:12:23 8be1e7bc5590 su: pam_limits (su: session): تعذر تعيين حد لـ "nice": العملية غير مسموح بها

ثم أنا strace d عملية su ، واكتشفت فشل استدعاء النظام التالي:

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

وهذا بدوره يتسبب في قيام الوحدة النمطية pam_limits بالإبلاغ عن فشل ؛ وهذا يمنع su من المتابعة.
من المثير للاهتمام ، أنه على Ubuntu ، لم يتم تمكين pam_limits لـ su افتراضيًا ؛ وحتى إذا قمت بتمكينه ، فستفشل المكالمة setrlimit ، لكن su يستمر ويعمل على أي حال.
قد يكون مرتبطًا برمز التدقيق ، لست متأكدًا.

الآن ، لماذا فشل setrlimit ؟ لأن الحاوية تفتقد إلى القدرة sys_resource ، وهي مطلوبة لرفع أي نوع من الحد.

أعتقد أنني سأعلق فقط على التوجيه limits.conf .
(بالمناسبة ، من الممارسات السيئة إضافة أشياء مباشرة إلى limits.conf ؛ يجب أن تنتقل إلى ملف منفصل في limits.d ، على ما أعتقد.)

ملاحظة: نظرًا لأنك قمت بالفعل بزيادة الحد الأقصى لعدد الملفات المفتوحة لـ Docker ، يمكنك أيضًا رفع الحد الأقصى للأولوية ؛ يجب أن يعمل كذلك!

آمل أن يساعد هذا.

في ملف Dockerfile هذا ، لديك السطر التالي بمفرده:

RUN su testuser

لا يوجد أمر يتماشى مع هذا (ولن يتم تطبيق أي غلاف ناتج على أوامر RUN اللاحقة) ، لذلك لن أتفاجأ إذا فشلت حقًا في محاولة فتح قذيفة وعدم التفاعل في مكان ما ، وهذا أمر منطقي. (بما أن docker build ليس عملية تفاعلية). ليس لدي الوقت الآن للتأكيد ، ولكن من المحتمل أن يكون الأمر يستحق المحاولة مع تمرير أمر فعلي إلى su .

jpetazzo شكرا على الوصف التفصيلي. سأحاول رفع الأولوية القصوى لـ Docker ومعرفة ما إذا كان ذلك يساعد.

(بالمناسبة ، إضافة أشياء مباشرة إلى limits.conf ممارسة سيئة ؛ يجب أن تذهب إلى ملف منفصل في limits.d ، على ما أعتقد.)

متفق عليه ، ولكن نظرًا لأن هذا هو رمز مثبت Vertica الذي وضعه هناك ، فأنا أحاول حل هذا الأمر.

tianon يحدث الشيء نفسه إذا قمت بتشغيل هذا في صدفة تفاعلية (/ bin / bash).

اعتذاري ، أعتقد أنه كان لا يزال يستحق المحاولة.

لا تزال النقطة حول هذا السطر غير منطقية في Dockerfile سارية على الرغم من ذلك. ربما أردت شيئًا أكثر مثل هذا (بعد أن تكتشف المشكلات المتعلقة بالحدود):

RUN su testuser -c 'echo test > ~/test.txt'

tianon أنت على حق ، لا معنى له كثيرًا. كان هذا فقط لإثبات أن su نفسها تفشل.

للرجوع إلى المناقشة الأصلية: أعتقد أنه لا بأس من وجهة نظر الأمان (ومفيد!) للسماح بإمكانيات setfcap و mknod في عملية الإنشاء (وربما في تنفيذ الحاوية العادي مثل حسنا). هل يرى أحد أي مشكلة يمكن أن تنجم عن ذلك؟

jpetazzo على العكس تماما! من شأنه أن يحل العديد من المشاكل التي أواجهها. أعتقد أن هذا ضروري للأشخاص الذين يرغبون في تشغيل حاويات Docker التي تعمل / تبدو وكأنها آلة حقيقية.

نعم! إذا كان هذا مناسبًا لك ، فأنا أغلق هذه المشكلة لصالح # 2191 ، "تمكين إمكانيات mknod و setfcap في جميع الحاويات" ثم :-)

هل نعرف عن مثل هذه السيناريوهات؟

يوم الأحد ، 13 أكتوبر 2013 الساعة 12:22 مساءً ، unclejack [email protected]

2191 https://github.com/dotcloud/docker/issues/2191 لا يحل هذا

مشكلة لجميع السيناريوهات التي قد تتطلب امتياز بناء عامل ميناء.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -26224788
.

jpetazzo https://twitter.com/jpetazzo
أحدث منشور على المدونة:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

jpetazzo هذا مطلوب عندما تريد استخدام Dockerfile لإنشاء صورة نظام تشغيل.

لقد حذفت تعليقي عن طريق الخطأ عند تحريره.

يرجى إلقاء نظرة على الشكل الذي سيبدو عليه هذا بدون القيام بكل شيء في Dockerfile:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

هذا يجبرني فقط على التغلب على نقص runp في Dockerfile أو docker build -privileged ، مما يجعل Dockerfiles عديمة الفائدة ويجبرني على كتابة أداة لتكرار وظيفة تشبه Dockerfile.

من الواضح أن Dockerfile سيكون أكثر فائدة مع runp أو docker build -privileged :
مثال runp:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

مثال: docker build -privileged

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

unclejack : آسف ، سؤالي لم يكن دقيقًا بما يكفي!
ما قصدته هو "أي إذن تحتاجه بالضبط (أعلى mknod و setfcap)؟"

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

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

أعتقد أن وجود docker build -privileged (أو runp لاستخدام الوضع المميز فقط للأوامر التي تحتاجه حقًا) سيكون مفيدًا.

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

jpetazzo RE: وحدة PAM (أقوم بتثبيت Vertica أيضًا) هل تقترح إعادة تجميع عامل الإرساء بعد إخراج sys_resource من lxc.cap.drop؟

ربما يمكن تعيين بعض هذه الحدود عبر ملف docker.conf؟

يجب اعتبار أن Docker نفسه قد يعمل في مجموعة محدودة من القدرات حيث قد لا تكون هذه الامتيازات متاحة لـ Docker لتفويض حاوياته. سيكون هذا صحيحًا بشكل خاص في سيناريو Docker المتداخل الذي يجب أن يصدر # 2080 أرضًا - قد يسمح هذا بـ Docker المتداخلة غير المميزة.

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

jpetazzoramarnat فقط لإغلاق حلقة على Vertica تثبيت وقضية مستوى لطيفة،
لقد حاولت تعيين الحد الجميل في docker.conf لكن ذلك لم ينجح بالنسبة لي واضطررت إلى تشغيل امتياز bash وتثبيته يدويًا.

orikremerjpetazzo وكنت قادرا على تشغيل التثبيت عن طريق إزالة sys_resource من lxc_template.go، واعادة تجميع عامل ميناء. يمكنني تقديم طلب سحب هناك ، لكنني سأنتظر حتى يعرب الآخرون عن آرائهم حول الآثار الأمنية لإزالة ذلك من تكوين lxc.

ramarnat : اعتمادًا على السيناريو ، يعتقد بعض الأشخاص أن إزالة sys_resource أمر جيد ؛ بالنسبة للبعض الآخر ، ستكون مشكلة.

قد يكون هناك احتمال لزيادة الحدود الأساسية لشيء أعلى (واصفات الملفات هي أيضًا مشكلة في Elastic Search). سيكون هذا بمثابة التأكيد على أن "الحد الأدنى من وقت تشغيل Docker يجب أن يكون قادرًا على التعامل مع واصف ملف 1،000،000". إذا لم يتمكن Docker من رفع الحد عند بدء تشغيله ، فسيصدر تحذيرًا ويستمر (كما يفعل لمجموعة التحكم في الذاكرة / المبادلة).

هذا لا يصلح سيناريو التركيب / الحلقة ، رغم ذلك (ما زلت أنام على هذا السيناريو).

jpetazzo ربما يوفر طريقة لتجاوز القيم المشفرة الثابتة في lxc_template.go. يوجد بالفعل شيء ما للسيناريو بسطر الأوامر -lxc_conf ، لكنه لا يعمل مع طبيعة .drop لتوجيهات تكوين lxc هذه - لقد حاولت!

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

هل يمكننا إضافة / dev / loop * إلى القائمة البيضاء في الوضع غير المميز؟ أفترض أن المشكلة هي أنه قد يمنحني الوصول إلى الملفات المثبتة في حلقة الحاوية الأخرى ، أو حتى ملفات المضيف ...

تضمين التغريدة
@عامل ميناء

يوم الخميس ، 17 أكتوبر 2013 الساعة 6:09 مساءً ، جيروم بيتازوني
كتب [email protected] :

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

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

jpetazzo هذا صحيح ، لكنني أعتقد أن عامل الإرساء سيحتاج إلى طريقة قياسية

solomonstre النقطة هي أنه يجب أن تكون هناك طريقة للسماح لـ docker build بالبناء في الوضع المميز. لن يساعدني السماح بالوصول إلى / dev / loop * في حالة الاستخدام الخاصة بي.

solomonstre : القائمة البيضاء / dev / loop هي ، IMHO ، رقم كبير ، لأنه مع فرع DM ، فإنه يمنح حق الوصول للقراءة / الكتابة إلى كل شيء (نظرًا لأن السلوك الافتراضي لفرع DM هو استخدام أجهزة الحلقة لتخزين حمامات).

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

1. docker build -privileged
   ملائم ، لكنه يرسم الخط الفاصل بين "الإنشاءات العادية" و "الإنشاءات المتميزة". إذا كان لديك صورة مفيدة للغاية تتطلب منشئًا متميزًا ، فسيكون من الصعب بناؤها على منشئي المحتوى العامين. على سبيل المثال ، إذا بدأ شخص ما خدمة لأتمتة الإنشاءات ، فمن المحتمل ألا يقدم بنيات مميزة (أو سيتعين عليه استخدام وسائل حماية إضافية).
2. أذونات الاسترخاء قليلا في البناء
   هذا يعني (على الأقل) تمكين cap_sysadmin (هذا يجعلني أشعر بجنون العظمة أرتجف قليلاً) ، وربما إعطاء جهاز أو جهازين حلقيين لكل منشئ. هذا من شأنه أن يحد من العدد الإجمالي للبناة الذين يعملون بالتوازي ؛ لكنها ليست مشكلة كبيرة نظرًا لأنه من المفترض أن تكون الإنشاءات عمليات سريعة ، والأهم من ذلك أنها نشطة. إذا كان لديك 50 إصدارًا يعمل بالتوازي ، إلا إذا كان لديك جهاز بنظام إدخال / إخراج فرعي كيكاس ، فلن تتقدم هذه الإنشاءات كثيرًا.
3. لف البناء داخل طبقة أخرى من المحاكاة الافتراضية / العزلة.
   بدلاً من تشغيل الإنشاء مباشرة داخل Docker ، قم بتشغيل شيء مثل QEMU-in -Docker أو UML-in-Docker. هذا حل رائع من وجهة نظر مطور Docker ، لأنه لا يعني أي عمل إضافي ؛ هذا حل ضعيف من وجهة نظر مستخدم DOcker ، لأنه يعني التعامل مع طبقة أخرى من التعقيد.

أتساءل عما إذا كان الحل الصحيح هو السماح بـ docker build -privileged` ، وفي نفس الوقت ، فكر في الخطافات التي تسمح بالتنفيذ الشفاف للخيار 3. لنفترض أنني "موفر إنشاء عامل ميناء": إذا شخص ما يطلب تصميمًا مميزًا ، كل ما علي فعله هو إدخال شيء ما في مكان ما لتشغيل عملية البناء الخاصة به داخل بيئة وضع الحماية (QEMU و UML مرشحان واضحان ، لكن قد يعمل الآخرون أيضًا ؛ إنها مجرد أمثلة ملائمة).

ماذا تظنون يا جماعة؟

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

يوم الجمعة 18 أكتوبر 2013 الساعة 9:59 صباحًا ، جيروم بيتازوني
إخطاراتgithub.com

solomonstre https://github.com/solomonstre : القائمة البيضاء / dev / الحلقة هي ،
IMHO ، كبير لا ، لأنه مع فرع DM ، فإنه يعطي القراءة / الكتابة
الوصول إلى كل شيء (نظرًا لأن السلوك الافتراضي لفرع DM هو استخدام
أجهزة حلقة لتخزين المجمعات).

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

1. docker build -privileged مناسبًا ، لكنه يرسم الخط الفاصل بينهما
   "البناء العادي" و "البناء المتميز". إذا كان لديك جدا
   صورة مفيدة تتطلب منشئًا متميزًا ، سيكون من الصعب
   بنائه على بناة العامة. على سبيل المثال ، إذا بدأ شخص ما خدمة لأتمتة
   يبني ، ربما لن يقدموا بنيات مميزة (أو سيكون لديهم
   لاستخدام ضمانات إضافية).
2. أذونات الاسترخاء قليلا في البناء وهذا يعني (على الأقل)
   تمكين cap_sysadmin (هذا يجعلني أشعر بجنون العظمة أرتجف قليلاً) ، وربما
   إعطاء جهاز حلقي واحد أو جهازين لكل عامل بناء. هذا من شأنه أن يحد من المجموع
   عدد البناة الذين يعملون بالتوازي ؛ لكنها ليست مشكلة كبيرة منذ ذلك الحين
   من المفترض أن تكون عمليات الإنشاء سريعة ، والأهم من ذلك أنها عمليات نشطة.
   أي إذا كان لديك 50 بناءًا تعمل بالتوازي ، إلا إذا كان لديك آلة
   مع نظام إدخال / إخراج فرعي ، لن تتقدم هذه الإنشاءات كثيرًا.
3. لف البناء داخل طبقة أخرى من المحاكاة الافتراضية / العزلة.
   بدلاً من تشغيل الإنشاء مباشرة داخل Docker ، قم بتشغيل شيء مثل
   QEMU-in -Docker أو UML-in-Docker. هذا حل رائع من Docker
   وجهة نظر المطور ، لأنها تعني عدم وجود عمل إضافي ؛ هذا فقير
   الحل من وجهة نظر مستخدم DOcker ، لأنه يعني التعامل مع ملفات
   طبقة أخرى من التعقيد.

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

ماذا تظنون يا جماعة؟

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - أرغب في رؤية إمكانيات mknode لتثبيت الصمامات (لتركيب حاويات S3) أو القدرة على تنفيذ عمليات التشغيل المميزة في Dockerfiles. غير متأكد ما هو الحل الأفضل ، حتى الآن.

+1. أي تحديثات بشأن هذه المسألة؟

+1
في 17 تشرين الثاني (نوفمبر) 2013 ، الساعة 11:31 مساءً ، كتب "yukw777" [email protected] :

+1. أي تحديثات بشأن هذه المسألة؟

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

لقد واجهت أيضًا مشكلة Fuse في محاولة تثبيت Java وأنا مهتم بالحل. لقد جربت الحل البديل المقترح هنا https://gist.github.com/henrik-muehe/6155333 لكنه لا يعمل بالنسبة لي على عامل ميناء على Raspberry Pi.

jpetazzo : تعجبني الإستراتيجية العامة لتطبيق العلامة ذات الامتيازات أثناء استكشاف حل طويل المدى في الوقت نفسه. تحقيقا لهذه الغاية ، لقد قدمت طلب سحب لتنفيذ هذه الميزة. لاحظ أنه اعتبارًا من الآن ، فإنه لا يقوم بتنفيذ الأمر "RUNP" كما تمت مناقشته مسبقًا في مؤشر الترابط هذا.

(اسمح لي "بنشر" هذا ، حيث قد ينتهي الأمر بالناس هنا للبحث عن حل بديل)

إذا كنت لا تستخدم ملف الجهاز فعليًا (ولكنه مجرد جزء من برنامج نصي لما بعد التثبيت كما في حالة حزمة المصهر) ، فيمكنك القيام بما يلي:

fakeroot apt-get ...

أو:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

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

المشكلة الحقيقية هي "أحتاج إلى استدعاء mknod" (أو أكثر عمومية: أحتاج إلى عمليات مميزة تفشل حتى الآن).

jpetazzo هذا يمكن أن يصلح ذلك ، أليس كذلك؟ https://lwn.net/Articles/564977/ - حتى ذلك الحين ، سأختار 3) لأن عزل الوصول إلى الجهاز _ هو طبقة أخرى من التعقيد ويجب إدارتها في مكان ما.

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

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

discordianfish 3) إلى حد كبير غير حل.

هل سيساعد # 2979 في هذه المشكلة؟

أنا أنتظر حلاً لهذا أيضًا ، لكن ليس بسبب مكود. نحن نشغل حاويات centos مع rpms التي تضع حدودًا للمستخدمين باستخدام /etc/security/limits.d/ وأنا أستخدم حاليًا حلًا بديلًا للمطرقة يتكون من:

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

أعلى ملف Dockerfile الخاص بي. (نحن مجرد نماذج أولية ، لا تقلق :))

مرحبًا jpetazzo ، لقد جربت كلا الخيارين اللذين

sudo docker build - امتياز -t oracle_xe لأنني في Dockerfile الخاص بي أريد تشغيل هذين الأمرين

RUN mount -o remount ، الحجم = 3G / dev / shm
تشغيل جبل -a

لكن هذا لا يعمل ، لا أعرف ما إذا كانت البنية التي استخدمتها غير صحيحة ، والخطأ الذي أحصل عليه هو
تم تقديم العلم ولكن لم يتم تعريفه: -privileged

لقد جربت أيضًا الخيار الثاني لاستخدام RUNP ولكن هذا أيضًا لم ينجح ، عندما أقوم ببناء الصورة تتخطى هذه الخطوة قائلة

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

شكرا.

أعتقد أنه لم يتم تنفيذ RUNP ولا "build --privileged".
إذا كان ذلك ممكنًا ، فلا تتردد في مشاركة Dockerfile ؛ يمكن أن يكون مفيدا جدا
يمكننا أن نقدم لك الحل البديل "الأقل سوءًا" :-)

في الأربعاء 9 أبريل 2014 الساعة 7:44 صباحًا ، كتب Manoj7 [email protected] :

مرحبًا jpetazzo ، لقد جربت كلا الخيارين اللذين اقترحتهما. أحاول البناء
صورة "oracle_xe" باستخدام

sudo docker build - امتياز -t oracle_xe لأنه في Dockerfile i
تريد تشغيل هذين الأمرين

RUN mount -o remount ، الحجم = 3G / dev / shm
تشغيل جبل -a

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

شكرا.

قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/dotcloud/docker/issues/1916#issuecomment -39972199
.

jpetazzo https://twitter.com/jpetazzo
أحدث منشور على المدونة:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

مرحبًا jpetazzo ، أرغب في إجراء "RUN sudo umount / etc / hosts" في Dockerfile الخاص بي - هل هناك حل بديل "الأقل سوءًا" لهذا؟ ؛)

تضمين التغريدة

ملف Dockerfile الذي استخدمته لبناء صورة oracle_xe

من *

الصيانة * * * * * * *

إضافة oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN mount -o remount ، الحجم = 3G / dev / shm
تشغيل جبل -a
RUN cd / appl / oracle / xe && unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN cd / appl / oracle / xe / Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
RUN cd / appl / oracle / xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

أول شيء جربته كان

sudo docker build -privileged -t oracle_xe.

هذا لم ينجح ثم حاولت استخدام RUNP
RUNP mount -o remount ، الحجم = 3G / dev / shm
RUNP جبل -a
هذا أيضًا لم ينجح ، تم تخطي هاتين الخطوتين.

gatoravi : لسوء الحظ ، لن يعمل

@ Bhagat7 : صحيح! سؤال: هل تحتاج إلى أكبر / dev / shm في وقت التشغيل _ و_ وقت التثبيت ، أم وقت التشغيل فقط؟ إذا كان في وقت الإنشاء ، فما هي الخطوة التي تفشل وكيف؟

jpetazzo أود إضافة عنوان IP جديد إلى / etc / hosts كجزء من عملية إنشاء الأداة.
شيء مثل echo $IP $HOST >> / etc / hosts.

يمكنني القيام بذلك بشكل جيد إذا استخدمت docker run --privileged ثم قمت بعمل sudo umount \etc\hosts ولكن يبدو أنني غير قادر على الالتزام بذلك باستخدام docker commit ومن ثم يتعين عليّ تكرار umount step كل مرة يدويًا عند تشغيل حاوية.

أرغب بطريقة ما في جعل \etc\hosts قابلًا للكتابة وجعله ثابتًا ، ولا يبدو أنني أجد طريقة للقيام بذلك باستخدام docker commit أو باستخدام ملف Dockerfile.

تضمين التغريدة

كانت لدي هذه المشكلة

bash-4.1 # / etc / init.d / oracle-xe
حدد منفذ HTTP الذي سيتم استخدامه في Oracle Application Express [8080]:

حدد المنفذ الذي سيتم استخدامه لمستمع قاعدة البيانات [1521]: 1521

حدد كلمة مرور لاستخدامها في حسابات قاعدة البيانات. لاحظ أن نفس الشيء
سيتم استخدام كلمة المرور لـ SYS و SYSTEM. توصي Oracle باستخدام
كلمات مرور مختلفة لكل حساب قاعدة بيانات. يمكن القيام بذلك بعد
الترتيب الأولي:
قم بتأكيد كلمة المرور:

هل تريد أن يبدأ Oracle Database 11g Express Edition في التمهيد (y / n) [y]: y

بدء تشغيل Oracle Net Listener ... انتهى
جاري تكوين قاعدة البيانات ...
بدء مثيل Oracle Database 11g Express Edition ... تم
اكتمل التثبيت بنجاح.
bash-4.1 # cd /u01/app/oracle/product/11.2.0/xe/bin
قاعدة 4.1 # sqlplus
أدخل اسم المستخدم: النظام
أدخل كلمة المرور: * **
لكني حصلت على هذا الخطأ
ORA-01034: ORACLE غير متوفر
ORA-27101: عالم الذاكرة المشتركة غير موجود
Linux-x86_64 Error: 2: لا يوجد مثل هذا الملف أو الدليل
معرف العملية: 0
معرف الجلسة: 0 الرقم التسلسلي: 0
تم إرجاع df -h داخل الحاوية
حجم نظام الملفات المستخدم متوفر استخدم٪ Mounted on
tmpfs 64M 0 64M 0٪ / dev / shm

لذلك عندما قمت بزيادة حجم tmpfs إلى 3G ، لم أحصل على هذا الخطأ. لقد قمت بحلها عن طريق تشغيل الحاوية كـ
sudo docker run -privileged -i -t oracle_xe / bin / bash. قمت بتشغيل أمري التحميل داخل الحاوية. لكنني لا أريد أن أفعل ذلك بهذه الطريقة بدلاً من ذلك أريد وضعها في Dockerfile الخاص بي وإنشائه.

gatoravi : حسنًا ، مفهوم. سؤالان آخران بعد ذلك: هل تحتاج إلى مضيفين إضافيين في / etc / hosts أثناء الإنشاء أم أثناء التشغيل فقط؟ ولماذا تحتاجها؟

@ Bhagat7 : عذرًا ، ليس لدي حل أنيق لهذا حتى الآن :- (أقترح أن يكون لديك ملفان Dockerfiles:

• أول واحد يقوم بجميع الخطوات (باستثناء تلك التي تتطلب أكبر / dev / shm) ، ويحدد CMD الذي سيتحقق مما إذا كانت الحاوية تعمل في وضع الامتياز ، قم بتركيب أكبر / dev / shm ، وتشغيل الخاص أمر؛
• Dockerfile آخر لتنفيذ خطوات إضافية (إلا إذا كنت بحاجة أيضًا إلى / dev / shm في وقت التشغيل ، فأنت بحاجة الآن إلى شيء مميز).

jpetazzo نود تزويد مستخدمينا بصورة (/ حاوية) مع / etc / hosts / قابل للتحرير حتى يتمكنوا من بناء الكود الخاص بنا الذي يعدل هذا الملف :) لماذا نحتاج إلى إضافة المضيف ، أنا ' لست متأكدًا حقًا من أن نكون صادقين ، فنحن نقوم بذلك كجزء من التثبيت الخاص بنا للمساعدة في توجيه أسماء مضيف معينة إلى عناوين IP.

@ Bhagat7 لقد تمكنت من تشغيل أوراكل XE في حاوية رصيف 0.9 باستخدام مزيج من:

1. https://github.com/wnameless/docker-oracle-xe-11g
   و
2. على المضيف ...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

mikewaters شكرا جزيلا على الرد. أعتقد أنك صممت Oracle XE فوق نظام Ubuntu. لكني أحاول بنائه على Centos.

jpetazzo شكرا جزيلا على اقتراحك

اهلا ياجماعة،

أنا أستخدم google-chrome الذي يحتاج إلى الكتابة إلى /dev/shm والذي يبدو أنه عادةً 777 وهو 755 هنا. حاولت إضافة تكوين محدد إلى /etc/fstab ولكن لا يمكنني تشغيل mout -a لتطبيق التعديلات على إصدار. بالطبع جربت chmod أو chown لكن لا يمكنني فعل ذلك على البناء أيضًا.

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

أي اقتراح؟

شكرا لك.

tomav ،

شكرا لك @ تيانون.

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

لقد اتبعت بعض الخطوات الموثقة بشكل جميل في هذه المقالة حول إنشاء cryptfs لوضع الحاويات فيها: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

لاحظ ، أنني لا _أحاول القيام بذلك ، ولكن في الواقع لدي حاوية بها cryptfs مُثبتة:
لذلك يجب إنشاء نظام ملفات مشفر وتثبيته وتنسيقه أثناء الإنشاء عبر عامل الإرساء.

الذي فشل:

• عندما أحاول العثور على جهاز حلقي:

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• بشكل غريب ، ينجح ملف عامل الإرساء نفسه _ أحيانًا _ في العثور على جهاز حلقة ، ثم:

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

هل هناك طريقة للتغلب على هذا حتى الآن؟ (بخلاف نقل خطوات تحميل / تنسيق القرص إلى run )

+1 سيكون مفيدًا بشكل خاص لبيئات "عامل الإرساء"

+1 على هذا ، لا يعمل iptables في وضع عدم الامتياز ، مما يتسبب في فشل أي شيء يحاول إعداد قواعد جدار الحماية.

PerilousApricot : لاحظ ، مع ذلك ، أنه حتى لو تمكّنت من تعيين قاعدة iptables في RUN ، فستفقد على الفور ، لأن الصورة تحمل حالة نظام الملفات فقط. لا يعرف عن العمليات الجارية ومسارات الشبكة وقواعد iptables وما إلى ذلك.

هذا جيد بالنسبة لي ، لأن الحاوية سيكون لها منافذ محددة فقط
إعادة التوجيه ، لست مهتمًا بجدار الحماية ، فأنا في الغالب أريد فقط
المثبت ليكون قادرًا على النجاح على الإطلاق

أندرو ميلو

تضمين التغريدة في هذه الحالة ، ماذا عن الربط الرمزي iptables بـ /bin/true ؟ يجب أن يجعل المثبت سعيدًا أيضًا. (أو بعض الحيل المماثلة لخداع المثبت؟)

لقد جربت ذلك ، لكن المثبت يحتاج أيضًا إلى تحليل الإخراج من
iptables ، لذا فالأمر ليس بهذه السهولة :)

حسنًا ، أعلم أن هذا أصبح اختراقًا ، ولكن - ماذا عن وضع iptables مزيف بدلاً من ذلك؟ الذي من شأنه أن يولد بعض الإخراج الوهمي؟

أنا أفهم تمامًا أنه ليس رائعًا ؛ ولكن بجدية ، يجب إصلاح هذا النوع من المثبت في المقام الأول :)

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

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

هذه الميزة هي IMHO لا غنى عنها ، مزيج من RUNP مع build-privileged سيكون رائعًا.

سيناريو الحياة الواقعية / الإنتاج الذي أواجهه هو صور Docker التي تم إنشاؤها باستخدام توفير Puppet في حاوية وسيطة. في بعض الخدمات التي تتطلب إمكانات عالية ، هناك إخفاقات في الإنشاء تتطلب تشغيل الحاوية بأقل من -privileged مع ENTRYPOINT أو CMD الذي يعيد تطبيق النص الدمية.

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

آمل أن يكون ما ورد أعلاه منطقيًا.

jpetazzo أحاول إنشاء خادم ويب أعلى centos6. لقد تقطعت بهم السبل في تكوين قواعد iptable عبر ملف عامل التحميل. إنه مشابه لقضيةPerilousApricot .

راجع للشغل: أنا لست من أجل تنفيذ الاختراقات مثل iptables المزيفة.

pmoust : هل لديك تفاصيل حول عمليات البناء التي تتطلب امتيازات عالية؟ من المحتمل أن أوصي بتجنب المشكلة ، وأدرك تمامًا أن هذا قد لا يكون مرضيًا لك ؛ ولكن مع ذلك ، سأكون سعيدًا لفهم نوع المثبت / المنشئ الذي قد يتطلب هذه الامتيازات ...

@ passion4aix : لاحظ أنه إذا قمت بتعيين قواعد iptables في Dockerfile ، فلن يتم حفظها. يحفظ Docker حالة نظام الملفات فقط ، وليس عمليات التوجيه / التصفية / التشغيل ... هناك طرق لإعداد قواعد iptables مع حاويات "sidekick". هل هذا شيء يمكن أن يكون ممتعًا بالنسبة لك؟

jpetazzo مُثبِّت Bitrock هو أحد الأمثلة. يتطلب / tmp ليتم تثبيته على أنه tmpfs. قد ترغب في إلقاء نظرة على http://answers.bitrock.com/questions/3092/running-installer-inside-docker

jpetazzo أو بشكل أساسي أي برنامج تثبيت Openstack

لقد واجهت أيضًا مشكلة مماثلة عند محاولة تشغيل TokuMX في حاوية Docker نظرًا لأن TokuMX يتطلب تعطيل خيار kernel 'transparent_hugepage'.

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

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

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

diversit يجب أن يقترن. لذا فإن --privileged في سطر الأوامر سيمكّن القدرة على استخدام RUNP ، وإلا فسيكون هذا بمثابة كابوس أمني للأشخاص الذين يقومون ببناء كود غير موثوق به (بما في ذلك DockerHub).

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

deas : أعتقد أنه يمكن حل هذا عن طريق القيام بـ VOLUME /tmp .

PerilousApricot : هل يمكنك التفصيل قليلاً؟ لا أفهم لماذا يتطلب أي نوع من المثبت امتيازات خاصة. (نعم ، أنا رجل عجوز عنيد في نظام Unix ، وهذا أحد عيوبي: D)

diversit : بالنسبة لهذه الحالة المحددة ، أعتقد أنه يجب على مشرف الجهاز تعطيل hugepages الشفافة قبل البناء. لأنه إذا سُمح للمُنشئ بالقيام بذلك ، فسوف يقوم بذلك عالميًا (أليس كذلك؟) وقد يكسر الحاويات الأخرى التي قد تتطلب الميزة. هل ترى ما اعني؟ سيكون أمرًا سيئًا إذا كسرت حاوية البناء X الحاوية Y ...

الجميع: أتفهم تمامًا أنه أمر محبط للغاية عندما لا يعمل Dockerfile ، وكل ما تحتاجه هو علامة --privileged / RUNP . ولكن إذا بدأنا في الحصول على تصميمات مميزة ، فسيؤدي ذلك إلى كسر الكثير من الأشياء (على سبيل المثال ، الإنشاءات الآلية على Docker Hub!) ، لذلك نشعر بالسوء حيال ذلك. ولما يستحق الأمر ، فأنا على استعداد للتحقيق في جميع السيناريوهات التي تتطلب تصميمات مميزة والمساعدة في إصلاحها :-) (نظرًا لأن اقتناعي الشخصي هو أن هؤلاء المثبتين معطّلون!)

jpetazzo العديد / معظم أدوات النشر المفتوحة (مثل https://openstack.redhat.com/Main_Page) تضع قواعد iptables. أرغب في أن أكون قادرًا على نشر / نشر إصدارات حاوية من التطبيق ، لذا فإن القدرة على إنشاء ملف عامل ميناء والقيام بذلك دفعة واحدة أمر مهم بالنسبة لي. أعلم أن قواعد iptables لا يتم الاحتفاظ بها من خلال عملية الحاوية بشكل أصلي ، لكنها تستمر من خلال iptables-save ، لذا فإن استعادة iptables البسيطة في عملية CMD ستؤدي إلى إعادة تحميل القواعد. يعتبر "إيقاف" iptables أكثر تعقيدًا لأن الكثير من أدوات النشر تستخدم أدوات CI مثل الدمية أو الطاهي لأداء النشر الفعلي ، لذلك ستحتاج بطريقة ما إلى إنشاء كعب متوافق سينتهي بك الأمر بمحاكاة كل المدخلات / المخرجات لأمر iptables "الحقيقي".

علاوة على ذلك ، أعتقد أنه من العدل أن نقول ، "إذا كان لديك Dockerfile يتطلب تصميمات مميزة ، فستفقد الميزات X و Y و Z"

لن يتم تشغيل Oracle xe بدون مساحة ذاكرة مشتركة كافية. جميع الحسابات هي أن remountimg tmpfs مع مساحة enuf تجعل Oracle xe سعيدًا ببدء التشغيل وإكمال التكوين .. (بالنسبة لأولئك الذين يتمتعون برؤية ثاقبة ، فإن الخطوة "/etc/init.d/oracle-xe config" هي التي تشكو من قيود الذاكرة الهدف يشاع أن يكون البيض عن طريق زيادة حجم التثبيت)

أثناء البناء
قم بتشغيل unmount tmpfs
فشل مع
umount: / proc / kcore: يجب أن يكون مستخدمًا متميزًا لإلغاء العدد

أعطني RUNP أو أعطني الموت .... أو .... أرني ما الذي يمكن أن أفعله بشكل مختلف :)

المثال الخاص بي غير صالح. jpefazzo لا يزال قائمًا :) كانت إعدادات Oracle الخاصة بي تسبب المشكلة ويبدو أنه لا توجد حاجة لضبط حجم tmpfs ... على الأقل للتثبيت الأولي.

أواجه مشكلة iptables في CentOS 7.0 والتي يتم حلها فقط عند run ning مع --privileged https://github.com/docker/docker/issues/3416

بدون دعم البناء المتميز ، لست متأكدًا من كيفية حل المشكلة

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

buley أعتقد أنه مع إضافة security-opts في # 8299 ، سيكون من الممكن القيام بذلك بدون --privileged

jpetazzo لا أرى كيف يحل استخدام VOLUME /tmp مشكلة مثبتات Bitrock. قد ينجح ذلك في الإنشاء ، ولكنه سيجعل أيضًا /tmp يتجاوز طبقات AUFS لجميع الحاويات بناءً على تلك الصورة ، أليس كذلك؟ في نهاية اليوم ، يبدو أنه يجب إصلاح السبب الجذري في AUFS.

إليك حالة الاستخدام الخاصة بي: أريد إنشاء بيئة chroot داخل حاوية عامل إرساء. تكمن المشكلة في أنه لا يمكن تشغيل debootstrap ، لأنه لا يمكن تحميل proc في chroot:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
إذا أنا run --privileged الحاوية ، فإنها تعمل (بالطبع) ...
أود حقًا حقًا إزالة الجذر في Dockerfile (أكثر نظافة). هل هناك طريقة يمكنني من خلالها تشغيله ، دون انتظار RUNP أو إنشاء امتياز؟

شكرا جزيلا!

+1 لـ - مميزة أو متصاعدة. الحاجة لأتمتة بناء glusterfs

هذا يؤثر على جهودي لبناء صورة من مثبّت Bitnami Tomcat. 99٪ من عملية التثبيت تعمل بدون أي مشكلة ، ولكن عندما تحاول بدء تشغيل tomcat لأول مرة ، فإن ذلك يفشل مع الإخراج التالي في catalina-daemon.out:

set_caps: فشل في تعيين القدرات
تحقق من أن النواة الخاصة بك تدعم القدرات
set_caps (CAPS) فشل للمستخدم 'tomcat'
الخروج من الخدمة بقيمة إرجاع تبلغ 4

يمكنني بنجاح تشغيل مثبت Tomcat يدويًا في حاوية أنشأتها باستخدام "--cap-add ALL". يبدو من الغريب أنني لا أستطيع استخدام "بناء عامل الإرساء" لإنشاء صورة يمكنني إنشاؤها يدويًا باستخدام "تشغيل عامل الإرساء" ثم "التزام عامل الإرساء". يجب أن تحتوي الحاويات المستخدمة أثناء عملية الإنشاء على جميع الوظائف مثل الحاويات التي يمكنك إنشاؤها باستخدام "تشغيل عامل الإرساء".

gilbertpilz لا يمكنهم فعل ذلك بشكل صريح لضمان توفير إمكانية النقل والأمان.

@ cpuguy83 - هذا لا معنى له. يمكنني بناء الصورة التي أريدها يدويًا ، إذا قمت بما يلي:

تشغيل عامل ميناء --cap-add ALL .... / bin / bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
خروج
التزام عامل ميناء ...

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

حسنًا ، دعني أعطيك ملف Dockerfile الذي يقوم بتركيب ملف المضيف / etc / passwd في المنشئ ويصادف إرسال ذلك إليّ.

يمكن أن تكون هذه الأشياء خطيرة.
لاحظ أيضًا أن --privileged (و --cap-add ALL) يمنح المستخدم في الحاوية تحكمًا كاملاً في المضيف.

قد يؤدي السماح بهذه الأشياء إلى تعريض DockerHub بالكامل للخطر

@ cpuguy83 - ليس عليك وضع التحكم في Dockerfile. يمكنك إضافة خيار "--cap-add" (أو شيء مشابه) إلى أمر "docker build". إذا اتبعنا منطقك ، فينبغي ألا تسمح برامج شل النصية باستخدام الأمر "sudo" لأن شخصًا ما يمكن أن يكتب نصًا يقوم بأشياء سيئة.

لكنك لن تعطي شخصًا ما لا تثق به كثيرًا بمفاتيح المملكة.
يجب أن يكون Build قادرًا على تشغيل تعليمات برمجية غير موثوق بها بأمان قدر الإمكان.

يؤدي تقديم علامات CLI لتمكين ميزات إضافية في الإنشاء إلى كسر قابلية نقل الإصدار ، ولهذا السبب لم تتم إضافته بعد.

ومع ذلك ، من شبه المؤكد أن المثبِّت مخطئ هنا حيث يطلب أشياء لا ينبغي له هو نفسه الوصول إليها.

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

أنت لا ترى الصورة الأكبر.

هناك ما هو أكثر في هذا النظام البيئي من خادمك وخادمي. DockerHub ، على سبيل المثال ، يقوم ببناء كود غير موثوق به طوال الوقت.

ثم يجب على DockerHub بالتأكيد _not_ تمكين إضافة إمكانيات لبنياته. إذا كان هذا يعني أنني لا أستطيع دفع بناء عامل الإرساء الخاص بي إلى DockerHub ، فأنا على ما يرام مع ذلك.

@ cpuguy83tianonjpetazzo - عندما يبدأ FUD، وأنا مضطر للتحدث:

قد يؤدي السماح بهذه الأشياء إلى تعريض DockerHub بالكامل للخطر

سرسلي؟
تنفيذ هذه الميزة == TEOTWAWKI؟

بالطبع لن يقوم DockerHub مطلقًا بتشغيل docker build مع العلم المطلوب --privileged .
بدون الكثير من التفكير ، هناك طريقتان واضحتان على الأقل لتنفيذه:

• تعمل العلامة فقط إذا قمت أيضًا بتشغيل docker -d مع علامة جديدة مثل: --i-want-a-broken-security-model
• قم بإنشاء علامة وقت الترجمة والتي تمكن مسار الكود.

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

tamsky ثم لدينا موقف حيث تعمل
أنا أشرح لماذا تبدو الأشياء على ما هي عليه ، ولا أجادل في حالة أو أخرى.

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

يارب احفظها

ثم لدينا موقف حيث تعمل المباني في مكان واحد دون مكان آخر.

من فضلك تخيل للحظة أننا قد انتقلنا بطريقة سحرية إلى عالم تختلف فيه _السياسة_ ، وبعض المباني تعمل في مكان واحد ولكن ليس في مكان آخر ...

لماذا هذه الصفقة الكبيرة؟
بالضبط من يهتم؟

هل اعتبرت شركة Docker Inc أن المانترا / المتطلب الأدنى في القاسم المشترك "يجب أن تعمل جميع الإنشاءات في كل مكان" قد يتجاهل في الواقع حاجة العميل الفعلية؟

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

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

في النهاية ، إذا كان Docker سيعمل على منصات متعددة ، فلن يعمل 'docker build' بنفس الطريقة على جميع الأنظمة. أي أن إنشاء حاوية Windows أو حاوية Solaris أو حتى حاوية ARM Linux لن يكون هو نفسه الموجود في x86-64 Linux. سيختلف سياق الأمان لهذه أيضًا ، بما يتناسب مع أنظمة التشغيل الخاصة بهم.

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

البنيات لا تعمل في كل مكان لأنه على سبيل المثال تم تحميل ملفات تعريف درع التطبيق.
أيضًا كيف ستفعل الحالة مع حاويات عامل الإرساء المخزنة مؤقتًا والمخبأة في صورة؟

في 18. 11. 2014 ، في الساعة 2:53 ، كتب tamsky [email protected] :

يارب احفظها

ثم لدينا موقف حيث تعمل المباني في مكان واحد دون مكان آخر.

من فضلك تخيل للحظة أننا قد انتقلنا بطريقة سحرية إلى عالم تختلف فيه السياسة ، وبعضها يعمل في مكان واحد ولكن ليس في مكان آخر ...

لماذا هذه الصفقة الكبيرة؟
بالضبط من يهتم؟

هل اعتبرت شركة Docker Inc أن المانترا / المتطلب الأدنى في القاسم المشترك "يجب أن تعمل جميع الإنشاءات في كل مكان" قد يتجاهل في الواقع حاجة العميل الفعلية؟

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

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

ليس "المثبت" هو الذي "معطل" في هذه الحالة ، إنه Tomcat 7. أنا أستخدم حزمة Tomcat الخاصة ببيتنامي التي تدمج Tomcat مع Apache و MySQL. يوجد Docker في نهاية سلسلة التوريد لخدمات المصدر والتكوين والتكامل والاختبار والتعبئة والتغليف. مطالبتي بـ "إصلاح" Tomcat يمنعني من الاستفادة من سلسلة التوريد هذه. من الأسهل بناء الصورة التي أريدها يدويًا (ابدأ حاوية بـ "--privileged" ، قم بتشغيل المثبت ، أخذ لقطة للحاوية ، وما إلى ذلك) من "إصلاح" Tomcat.

+1
لا يمكنني نقل أدوار الشيف الخاصة بي إلى عامل ميناء لأنها تتضمن جميعًا استخدام ufw لفتح المنافذ.
إضافة - ذات الامتياز للبناء من شأنه إصلاح هذا.

+1. لا يمكن الحصول على debootstrap كخطوة في Dockerfiles الخاص بي.

+1. لا يمكن الحصول على debootstrap كخطوة في Dockerfiles الخاص بي.

بدا من الطبيعي أن أقوم ببناء chroot من خلال Dockerfile / build لكن واجهت نفس المشكلات التي ذكرها fbrusch .

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

فشل مع:

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

ماذا عن أن يكون لديك علامة بناء --insecure بدلاً من RUNP --insecure .
لجميع أوامر RUN ، سيتم تشغيل الحاوية التالية بـ --add-cap=all . هذا بدلاً من الامتياز لأن الامتياز يقوم ببعض الأشياء الأخرى أيضًا ...
ولكن في الواقع قد يتغير هذا لتنفيذ إعدادات privileged الكاملة إذا لزم الأمر في مرحلة ما دون الحاجة إلى تعديل العلم.

يارب احفظها
لا أمانع في الاضطرار إلى استخدام علامة تم تمريرها إلى بناء عامل الإرساء والتي تمكن أوامر RUN من الحصول على امتيازات أو تمكين أوامر RUNP. هناك قيمة في أن تكون قادرًا على إلقاء نظرة على Dockerfile والإخبار بالأوامر أو أي شيء بداخله ، أنه سيتطلب وصولاً مميزًا ، وفي وقت التشغيل بدلاً من الوصول إلى الخطوة 10 والخطأ ، سيكون قد اختصر في البداية أن Dockerfile يحتوي على أوامر تتطلب امتياز.

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

سيكون من الجيد أن يكون لديك فقط في Dockerfile:

RUN mount --bind /dir1 /dir2

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

على سبيل المثال

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

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

تتيح القدرة على القيام بذلك أ -> ب -> ج الاحتفاظ بحاويات البيانات عامة وتوفر المرونة في المجموعات المختلفة التي يمكنك تحقيقها باستخدام --volumes-from مع حاويات التطبيقات والبيانات.

يمكنك تحقيق ذلك أيضًا من خلال امتلاك سلسلة من الحاويات بـ --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

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

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

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

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

اليك مثال بسيط

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

قم بإنشاء مثال ربط ربط ، وقم أيضًا بإنشاء مثال ارتباط رمزي

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

شوهد الملف من جميع الدلائل الثلاثة

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

تم تحديث إظهار /proc/mounts

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

اخرج من الحاوية التي توقفها ، ثم ابدأ من جديد

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

ينقص /proc/mounts رابط الربط

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

نجا Symlink ، ولكن لا ربط جبل

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

إعادة ربط ربط جبل

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

بدلاً من الخروج من الحاوية ، افصل بـ ctrl+p ctrl+q ثم قم بتثبيت الحاوية

قم بتنفيذ الحاوية كصورة جديدة ، وابدأ حاوية جديدة من الصورة في الوضع nonpriv

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

تحقق من /proc/mounts
تحميل الربط مفقود ، لست متأكدًا مما أدى إلى تحميل / proc / [sys، sysrq-Trigger، irq، bus، kcore]

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

نجا Symlink

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

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

الجميع ، إذا كنت ترغب في ذلك ، جرب '/ usr / bin / unshare -f -m -u -i -n -p -U -r - / path / to / binary'. سيؤدي هذا إلى إنشاء حاوية داخل التصميم الخاص بك مع مساحة اسم مستخدم. يمكنك تعديل الخيارات لإلغاء المشاركة حسب الضرورة. أنا في الواقع أستخدم هذا لتشغيل '/ sbin / capsh' ، لتعيين إمكانات عملياتي بشكل دقيق.

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

أوافق على أن يصبح هذا جزءًا من Docker نفسه ، ويبدو أن تكامل مساحات أسماء المستخدمين قيد التقدم.

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

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

+1 لسحب عامل الإرساء عبر RUNP

يؤدي عدم القدرة على تشغيل docker build ذي الامتياز إلى تعزيز البناء يدويًا باستخدام shell و docker ، مما يجعل Dockerfiles بلا فائدة. لا أعتقد أن إضافة علامة مميزة إلى بناء عامل الإرساء من شأنه أن يرسم خطًا بين الإنشاءات والبنيات المميزة ؛ تم رسم هذا الخط بالفعل عندما تمت إضافة العلم للتشغيل ويحتاج إلى دعم.

+1 هذا يجعل حاوية عامل الإرساء قابلة لإعادة الإنتاج في أي نقطة زمنية محددة (تحتاج فقط إلى حمل ملف عامل الإرساء بمفرده)

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

lsjommer ما نوع الأشياء التي يجب عليك

أنا لا أقول دعونا لا ننفذ هذا ، ولكن دعونا نتحدث عن حقيقة ما نتحدث عنه.

سيكون هذا أيضًا سهل التنفيذ نسبيًا إذا أراد شخص ما القيام به ...

@ cpuguy83 هذا من دورنا الأساسي القياسي "bare metal" الذي أحاول اعتماده في حاويات Docker لتثبيت جميع libs ، وهو يتعامل مع الذاكرة المشتركة ولكن ربما لا أحتاج حتى إلى الاهتمام بها في بناء الحاوية وتحتاج فقط تشغيله على مضيف الحاوية؟
http://pastebin.com/P3QQxjNQ

أعترف أنني لا أفهم تمامًا كيف يتعامل Docker مع مشاركة الموارد.

ljsommer لذا فإن إعداد shm هو وحش مختلف تمامًا ولن يستمر بين أوامر RUN (أو عندما تكون في الواقع docker run ) على أي حال.

@ cpuguy83 نعم ، أعتقد أن هذا كان خطئي في الغالب فيما يتعلق بأني
نشكرك على الوقت الذي استغرقته في الرد والاعتذار لعدم تثقيف نفسي بشكل مناسب قبل الشكوى.
؛)

أي فكرة عن RUNP / -privileged أثناء عملية البناء؟
سيكون من الرائع وضع جداول IP للحد من وصول عامل الميناء إلى عناوين IP المحددة

أريد أيضًا RUNP و / أو "بناء عامل ميناء - مميز".

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

لا يعمل Dockerfile هذا بسبب الخطأ التالي ولكنه يعمل إذا كان يعمل مع "docker run --privileged" ...

getsockopt failed strangely: Operation not permitted

malcm ، @ RUNP ، فلن يعمل في هذا السيناريو ، لأن قواعد iptables ليست ثابتة في نظام الملفات.

اسمحوا لي أن أشرح: عندما تفعل RUN x ، ينفذ Docker x ثم يأخذ لقطة من نظام الملفات. لا يتم تخزين الأشياء خارج نظام الملفات (العمليات الجارية ، وجداول التوجيه ، وقواعد iptables ، وإعدادات sysctl ...) في صور Docker.

إذا كنت تريد قواعد iptables مخصصة ، فإحدى الطرق هي:

• ابدأ الحاوية الخاصة بك على سبيل المثال بـ --name myapp
• ابدأ حاوية أخرى ، ذات امتياز ، لقطة واحدة ، لإعداد قاعدة iptables ، على سبيل المثال docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

هل هذا منطقي؟

jpetazzo : شكرا لك على ردك. في حالتي ، أضع الأمر الثاني لجعل قاعدة iptables تستمر كبيانات على نظام الملفات على النحو التالي. يجب أن يمكّنني هذا من تحميل قاعدة iptables بعد بدء الحاوية بخيار --privileged.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

بدون RUNP ولا "build --privileged" ، أنا مجبر على كتابة مثل:

ADD iptables.rules /etc/

نعم ، قد يكون هذا كافيًا ، ومع ذلك ، فأنا بحاجة إلى إضافة iptables.rules بجانب Dockerfile في الريبو الخاص بي.

لهذا السبب أريد (أو أود أن أحصل على) RUNP. :)

تضمين التغريدة
بعيدًا عن مشكلات iptables ، وعمليات التحميل والعمليات المميزة الأخرى ، أعتقد أن هناك سيناريو بناء واحدًا يجب أن نتناوله.

نشحن الأجهزة للنشر في الأجهزة الظاهرية والتركيب المعدني. ومع ذلك ، للاختبار نستخدم بيئات الحاويات. في المقابل ، داخل هذه الأجهزة نقوم بتشغيل الحاويات. لذلك يجب أن تعتمد حاويات الاختبار على عامل الإرساء. تخيل الآن أن لدينا صورة خدمة يجب تحميلها مسبقًا في صورة الاختبار (بحيث لا يتم تنزيل صور الخدمة من السجل في وقت الاختبار). في الوقت الحالي ، لا يمكننا فعل ذلك نظرًا لأنه لا يمكننا تشغيل حاوية d-in-d في الوضع المميز أثناء إنشاء Dockerfile الذي يستخدم d-in-d كقاعدة: لن يبدأ docker daemon ، "docker pull أو "تحميل عامل الإرساء" لن يعمل.

واجهت مشكلة حيث ، عند التشغيل على مضيف RHEL7 ، سيفشل su إذا كان المستخدم الحالي هو الجذر. بغرابة ، إذا كان المستخدم الحالي شيئًا آخر ، فإن su يعمل بشكل جيد. بغض النظر ، كان الحل هو تمرير أمر التشغيل العلم --add-cap=SYS_RESOURCE ؛ بسبب هذه المشكلة ، ومع ذلك ، لم يكن من الممكن القيام بذلك أثناء خطوة الإنشاء.

إجراء +1 لملفات Dockerfiles باستخدام docker run و docker commit أمر مثير للسخرية. يرجى تضمين هذه الوظيفة.

+1 على ضرورة هذه الميزة. أعتقد أنه يمكن تكوين "مستوى أمان" عالمي في ملف تكوين مما يحد من القدرات التي يمكن منحها للحاوية. يجب أن يكون هناك افتراضي آمن (مثل اليوم) ويمكن لمسؤول النظام تغييره للسماح بتشغيل الحاويات بمزيد من الامتيازات. قد تفشل ملفات dockerfiles التي تحتوي على تعليمات RUNP في التشغيل مع رسالة مثل "يتطلب Dockerfile هذا القدرات التالية .... للبناء" على نظام له مثل هذه الحدود العامة.

أعتقد أن هذا يسمح بالتوازن بين الأمان وسهولة الاستخدام.

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

الحل الحالي لدينا هو بناء على مرحلتين مع خطوة امتياز التشغيل وخطوة الالتزام المنفصلة.

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

+1
لهذه الميزة.
للحصول على مثال تاريخي وحالة استخدام انظر هذا الخداع
https://github.com/docker/docker/issues/12138#issuecomment -90536998
شكرا @ cpuguy83 للإشارة إلى الخداع

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

يوجد الآن طلب سحب ينفذ هذا ؛ يمكنك التحقق من التقدم هناك ؛ https://github.com/docker/docker/issues/12261

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

بمجرد دمج # 13171 ، أعتقد أننا يجب أن نغلق هذا لأنه سيجعل طرح المنشئ الخاص بك أمرًا تافهًا ، وبالتالي يسمح بامتياز.
لا أعتقد أن docker build المدمج يجب أن يسمح بذلك.

لذا @ cpuguy83 ، إذا فهمت بشكل صحيح ، فإن طريقة دعم هذه المشكلة ستكون إعادة تطبيق docker build بالكامل ولكن مع معلمة إضافية؟

أعتقد أنه بمجرد دفع التصحيح الآخر ، سأحتاج إلى تجميع الإصدار الخاص بي من docker build (ربما docker pbuild ؟) لملء الوظيفة الإضافية؟

هل هناك أي تقدم في هذه القضية؟ لقد راجعت PRs المذكورة أعلاه وفشلوا جميعًا.
هل من الممكن جعل الخيار BUILD --privileged/--granted أكثر دقة وجعل الوصول الممنوح لمجموعة معينة من موارد المضيف يقتصر فقط على منشئ / مالك الصور؟

+1 لأي ​​حل يسمح لي بعمل RUN docker pull في ملف Dockerfile.

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

@ cpuguy83 لا يبدو أنه تم حل هذه المشكلة بما يرضي أي شخص. أحتاج تمامًا ، 100٪ ، إلى أن أكون قادرًا على القيام بشيء ممل مثل الكتابة إلى /proc/sys/kernel/core_pattern أثناء الإنشاء.

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

1. كان الاستهلاك العام لصوري أولوية.
2. كانت لديهم أي حاجة ، على الإطلاق ، لتكون قابلة للتكاثر.

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

ccthaJeztah ، الذي يبدو متعاطفًا مع هذا الموقف

انظر ، لقد أنشأت PR لتمكين هذا وتم رفضه.
لا أرى هذا يحدث مع المنشئ بأي شكل من الأشكال.

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

هذا ضروري لتثبيت حزم JDK 1.6 الأقدم ضمن CentOS حيث إن محاولات RPMs الخاصة بها للتسجيل هي binmft_misc الذي يفشل دون تشغيل بامتياز.

Dockerbuild هي مادة غير ثابتة لبناء الحاويات معها.

يقلد

من Centos5.11
قم بتشغيل yum intall -y jre-1.6.0_29-fcs

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

يجب أن يكون Docker قادرًا على تشغيل الحاويات الوسيطة بسهولة مع مجموعة خيارات مميزة.

shubhamrajvanshi نحن بصدد نقل "الباني" من البرنامج الخفي (وإلى العميل) ، وهذا من

shubhamrajvanshi ، لا يمكنك إجراء تغيير على iptables في

هناك عدد قليل جدًا من الأشياء التي يمكن للمرء أن يفعلها - ذات الامتيازات التي يكون لها معنى حتى في البناء.

thaJeztah بفضل ذلك سيكون مفيدًا.
@ cpuguy83 هل سيكون هذا هو الحال حتى لو كنت أستخدم حزمة iptables-persistent على الصورة.

سيؤدي هذا إلى حفظ القواعد على القرص ، ثم لا يزال يتعين إعادة تحميلها ، لسوء الحظ.

_USER POLL_

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

قدّر الأشخاص المدرجون أدناه مناقشتك الكاملة مع إجراء +1 عشوائي:

تضمين التغريدة

أود حقًا هذا أيضًا ، للسماح باستخدام برامج تشغيل CUDA الخاصة بـ nVidia من Docker على CoreOS. يقوم المثبت الذي يقدمونه ببناء وحدة kernel مقابل مصدر kernel ، ثم يقوم بتثبيتها باستخدام modprobe. لا أستطيع أن أرى كيف أجعله يعمل بدون نوع من الخيارات المميزة للبناء.

لماذا لا تدعم دائمًا الوضع المميز عند الإنشاء افتراضيًا؟

+1
أريد استخدام الأمر mysql في Dockerfile لـ centos7.
بالطبع يمكننا استخدام Entrypoint.sh ، لكنه أكثر فائدة إذا استطعنا استخدام -privileged لكل من الإنشاء والتشغيل.

ليست هناك حاجة لـ --privileged لتشغيل أمر MySQL.

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

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

هل هذا ينطبق على حالة مستخدم chroot؟

أحاول معرفة كيفية القيام بـ dpkg-depcheck -d ./configure بدون شيء كهذا.

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

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

بعد حوالي 3 سنوات و 162 تعليقًا ، أعتقد أن الأمر يستحق الاهتمام. التعليقات حول الوضع المميز ليس ضروريًا لمعظم الحالات المذكورة صحيحة ، حتى أنا ؛ ولكن لا ينبغي استخدامها لحظر ما قد يكون مفيدًا للبنى المحلية والمؤقتة والاستكشافية و / أو الملائمة. انشر التحذيرات حتى تطلق الأبقار انسجامًا ، وطبع تحذيرات سطر الأوامر ، وشتم واستنكر استخدامه ، ولكن امنح الناس المرونة. قابلية النقل ليست دائمًا المصلحة الأساسية للجميع.

_USER POLL_

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

الرجاء عدم استخدام تعليقات "+1" أو "لدي هذا أيضًا" على المشكلات. نحن تلقائيا
اجمع تلك التعليقات لإبقاء الموضوع قصيرًا.

صوّت الأشخاص المدرجون أدناه لصالح هذه المشكلة من خلال ترك تعليق +1:

تضمين التغريدة

+1

أحتاج حقًا إلى تحميل وحدة تخزين NFS داخل حاوية عامل إرساء ، حتى الآن لم أتمكن من إنشاء مشاركة NFS بدون علامة "--privileged = true". أفضل حالة في رأيي هي بناء الصورة باستخدام الأمر ذي الامتياز. كيف يكون هذا ممكنا؟

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

أحاول تثبيت gobject-introspection في نظام gentoo في Docker أثناء الإنشاء ولكنه فشل مع هذا الخطأ:

• ISE: _do_ptrace: ptrace (PTRACE_TRACEME، ...، 0x0000000000000000، 0x0000000000000000): العملية غير مسموح بها

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

نفس المشكلة عندما أحاول تثبيت glibc.

لذلك أحتاج أيضًا إلى طريقة كيفية تشغيل الأمر ذي الامتيازات أثناء الإنشاء.

أنا أستخدم إصدار docker 1.10.1 ولا تظهر مشكلة glibc في الإصدار 1.9

في الإصدار 1.10 ، هناك شيء معطل لا يمكننا بناء حاويات 32 بت ، لأن الشبكات غير متوفرة
- مميز أو - Security-opt seccomp: غير مقيد لـ BUILD - ضروري حقًا.
أو التوجيهات المقابلة في Dockerfile

+1 كبيرة مني

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

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

أشعر وكأنني تركت دون خيارات.

أشار thaJeztah إلى هذه المشكلة في 10 مارس
تراجع في سلوك LTTng بعد الترقية إلى 1.10.2 # 20818 مغلق

لا ، لم يتم إغلاقه ، فنحن نستخدم 1.11.0-0 ~ ذكي وفي حاويات 32 بت ، لا تعمل neworking منذ 1.10.0 ، ولكن 1.9.x عملت بشكل جيد.
يمكن للمتميزين فقط مساعدتنا في بدء تشغيل الحاويات. لكن لا يمكننا بناء جديد

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

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

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

--privileged عبارة عن خزان ، والسماح به في الإنشاء أمر خطير ، ويؤثر بشكل كبير على إمكانية نقل الصور.

بريان ،

إذا كان لديك عمل حول يمكنك مشاركته معي أيضًا. أود
أقدر ذلك.

شكرا
شوبهام راجوانشي
669-300-8346

في يوم الإثنين 2 مايو 2016 الساعة 2:30 ظهرًا ، كتب Brian Goff [email protected] :

ctindel https://github.com/ctindel إنه شيء لسنا مستعدين له
تنفيذ أو دعم. التنفيذ في حد ذاته بسيط إلى حد ما (حتى أنا
نفذته بنفسي حتى نتمكن من مناقشته) ، هذه ليست المشكلة.

- الامتياز دبابة ، والسماح لها بالبناء أمر خطير ، و
يؤثر بشكل كبير على إمكانية نقل الصورة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/1916#issuecomment -216369957

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

لا أعتقد أن كل حاوية يجب أن تكون محمولة. يتم إنشاء بعض الحاويات لمشاركتها مع المجتمع وقد يتم إنشاء البعض الآخر لنشر التطبيقات الداخلية.

تكمن مشكلة قابلية النقل في التطبيق الذي يتطلب التشغيل في وضع الامتياز في التطبيق نفسه.

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

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

يجب أن يكون موثقًا بوضوح أن البناء في الوضع المميز غير محبذ لأنه قد يؤدي إلى مشاكل في قابلية النقل.

مرسل من Outlook Mo bilehttps: //aka.ms/blhgte

في يوم الإثنين 2 مايو 2016 الساعة 2:53 مساءً -0700 ، كتب "تريفور بلاكويل" < [email protected] [email protected] >:

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

أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/docker/docker/issues/1916#issuecomment -216375159

tlbtlbtlb لأن الوضع المميز يمنحك وصولاً كاملاً إلى المضيف. ربما أضع شيئًا بسيطًا مثل shmmax أو شيء أسوأ من ذلك بكثير.
أنا أضمن أن هذه الأشياء ستحدث في اليوم الأول إذا كان هذا متاحًا.

@ davidl-zend "portable" لا تعني المشاركة مع المجتمع. إنه يعني الانتقال من آلة إلى أخرى.

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

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

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

من الواضح أنك لن تتمكن بعد الآن من الحصول على محور عامل ميناء أو travis-ci لبناء صورتك ، لكن الأشخاص الذين يحتاجون إليها مبنيًا بوضع الامتياز سيفهمون ذلك على أي حال.

ctindel أود أن أرى بعض الأمثلة على تعطل قابلية نقل الصور

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

@ cpuguy83 هل تناقش حقيقة أن شخصًا ما يمكن أن يقوم ببناء جزئي من Dockerfile ، أو تدوير حاوية في الوضع المميز ، أو إجراء المزيد من التغييرات ، ثم هل يلتزم عامل الرصيف؟ كيف يختلف ذلك عن عمل بناء في الوضع المميز؟ لأن هذا ما يفعله الآخرون اليوم.

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

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

ctindel أنا لا

بالنسبة لي ، أنا شخص بالغ موافق وأريد أن أكون قادرًا على

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

ما عدا أن إحدى الطرق هي PITA الرائعة للأشخاص وفتحات طريقة واحدة في الآلية الحالية للبناء باستخدام Dockerfile بشكل جيد للغاية.

أيضا ، أنت لم تجب على سؤالي. لماذا تعتبر التثبيت البسيط لحزمة دبيان (أو حزمة حزم) "تهيئة وقت التشغيل"؟

ctindel قابلية. فقط لأن شيئًا ما يمكن القيام به لا يعني أنه مدعوم ، وإدراجه في build ، مما يجعله مناسبًا للجميع ، فهذا يعني أنه مدعوم.
_سوف يتم إغراقنا بمشكلات الصور التي لا تعمل بين المضيفين ... الأمر الذي يهزم أساسًا السبب الكامل لـ Docker.

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

لكن السماح بالقيام بذلك عبر التزام عامل الإرساء يعني أنه مدعوم أيضًا!

لا أفهم ، أنت تجعل الكثير من الأشخاص يتعاملون مع القيود في هذا المنتج لأنك قلق من أن شخصًا ما سوف يشتكي إليكم شخصيًا يا رفاق حول نوع من الصور غير المدعومة؟

ما زلت لم تجب على سؤالي حول سبب كون عملية تثبيت حزمة (لا أتحدث حتى عن تكوينها هنا) هي فعل "تكوين وقت التشغيل". مجرد قول "قابلية النقل" لا يعني شيئًا.

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

راجع للشغل ، اسمحوا لي أن أشكركم هنا على ردودكم والمشاركة المستمرة. الكثير من مشاريع جيثب الأخرى حيث يتم تجاهل مواضيع المشكلة!

أنا أتفق مع النقطة حول الأشخاص الذين يعملون حول هذا باستخدام docker run --privileged مع docker commit . لقد قدمت حلاً كهذا لشركتين حتى الآن. سوف يصنع الناس صورًا كهذه وليس هناك فائدة من التصرف كما لو كان القيام بذلك أمرًا فظيعًا ورهيبًا.

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

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

justincormack ما الحل لحزمة طرف ثالث (أي لا يمكن تغييرها) تبدأ خدمتها الخاصة حيث يحتاج البرنامج النصي init لتحميل نظام ملفات tmpfs؟ أعني حتى تجاهل - مميزة في الوقت الحالي ، لا توجد أيضًا طريقة للقيام --cap-add أو --security-opt apparmor: غير محصور أثناء البناء (لا أعتقد؟)

ctindel لا يجب محاولة تحميل ملف tmpfs عند التثبيت. إذا كان يحتاج إلى tmpfs في وقت التشغيل فهذا رائع ، ولكن في وقت التثبيت بالتأكيد ليس صحيحًا.

@ cpuguy83 أنت تفرض فلسفة معمارية

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

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

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

ctindel أكثر مثل لا ، لا يمكنك التعامل مع هذه القنبلة النووية لأنك يمكن أن تقتل الجميع في دائرة نصف قطرها 50 كم.

ما الذي تحتاجه هذه الحزمة لتحميل ملف tmpfs أثناء التثبيت؟ التثبيت هو حرفياً استخراج الملفات من بعض تنسيقات الأرشيف إلى ملفات rootf.

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

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

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

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

لا توجد امتيازات مطلوبة.

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

إذا قسمناها إلى حالتين:

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

في هذه الحالة ، من الصالح أن يقوم Docker بالتراجع عن المثبِّتات سيئة التصرف. لدى معظم المثبتات نوعًا من الحل البديل الذي يجعل Dockerfile أطول قليلاً.

1. أدوات التثبيت التي تعتمد بشكل أساسي على العمليات المميزة ، مثل تثبيت وحدات kernel لبرامج تشغيل GPU. هذه أيضًا غير محمولة بشكل أساسي. لن يعملوا على آلة الإرساء لنظام التشغيل Mac ، على سبيل المثال.

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

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

tlbtlbtlb أنا لا أفهم ما هي "الفضيلة" التي تشير إليها. ضع في اعتبارك شيئًا ليس تافهاً ، ولكن هناك الكثير من صور عامل الميناء التي سيتم تشغيلها في بيئة ما دون أخرى. على سبيل المثال ، يمكنك تحميل وحدة تخزين مضيفة في حاوية mongodb من لينكس-> لينكس لأن برنامج تشغيل التخزين mmapv1 سيعمل بشكل جيد ، ولكن لا يمكنك تمرير دليل mac osx من خلال Virtualbox إلى حاوية mongodb على الكمبيوتر المحمول الخاص بك لأن لن تعمل أشياء mmap بشكل صحيح في هذه الحالة.

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

النقطة المهمة هي أن صورة mongodb تعمل في كل مكان. يعد تقديم تكوين وقت تشغيل غير صالح أمرًا مختلفًا.

يحتوي Docker على فصل محدد جدًا ومعوي للتكوين المحمول والتكوين غير المحمول.

وماذا عن هذا ؟
أحتاج إلى الحصول على ips الحقيقي الخاص بي داخل الحاوية لمرور فحص تكوين nginx.

هذا هو ملف Docker الخاص بي:

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

السبب إذا قمت بتشغيل حاوية مع خيار الامتيازات يمكنني تسوية ip إلى واجهة الاسترجاع. ولكن هناك نص آخر يجب إضافته.

@ cpuguy83 لدي حوالي 20 سطرًا أو نحو ذلك من iptable إدخالات أريد RUN في Dockderfile لكن لا يمكنني ذلك لأنني بحاجة إلى --cap-add=NET_ADMIN . يجب أن تحدث هذه الأوامر بغض النظر عن الشخص الذي يقوم بتشغيل الحاوية وبغض النظر عن الجهاز الذي يتم تشغيلها عليه (تقوم الحاوية بتشغيل تطبيق داخلي). أين / كيف تقترح أن أفعل ذلك بناءً على ما ناقشته أعلاه؟

MatthewHerbst للأسف قواعد iptables لن تستمر / لا يمكنها الاستمرار مع الصورة.

@ cpuguy83 أنا أستخدم صورة centos:6 ويمكن تشغيل /sbin/service iptables save لاستمرار القواعد في نظام الملفات. أعتقد أن لديهم قدرة مماثلة على Ubuntu والآخرين عبر حزمة iptables-persistent .

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

في 16 مايو 2016 الساعة 16:03 ، كتب "Matthew Herbst" [email protected] :

@ cpuguy83 أنا على CentOS ويمكنني تشغيل / sbin / service iptables حفظ إلى
استمر في قواعد نظام الملفات. أعتقد أنهم مشابهون
القدرة على Ubuntu وغيرها عبر الحزمة iptables-persistent.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub

@ justincormack لا أعرف لماذا لم أفكر في ذلك! شكرا!

كيف يفترض أن تنفذ الأوامر التي تتطلب امتيازًا عند استخدام docker service ؟ أحتاج إلى تعيين اسم المضيف على عدد قليل من أجهزتي ، لكن للأسف هذا يتطلب امتيازًا.

nostrebor الذي لا علاقة له إلى حد كبير بهذه المشكلة المفتوحة.
نحن نقوم بتقييم الخيارات التي يجب أن توجد للخدمات بدلاً من نسخها 1 إلى 1. من المحتمل ألا يكون الوضع المميز في 1.12 للخدمات.

أحاول إنشاءات docker التي تجمع شيئًا ما للتثبيت ، ولكن يجب أن يتم تجميعها مقابل المكتبات الموجودة على نظام ملفات شبكة CVMFS. بالطبع ، لا يمكنني تحميل CVMFS بدون تشغيل - امتياز ، لذلك لا يمكنني القيام بذلك على الإطلاق باستخدام Dockerfile.

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

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

هل يجب أن أجرب نهجًا مختلفًا؟ هل يجب علي تحميل CVMFS على المضيف ومشاركة هذا الدليل مع الحاوية أو شيء من هذا القبيل؟ لا أريد أن أضطر إلى إعداد نظام بناء خارجي فقط لعمل هذه الصورة - فالصورة التي يعتمد عليها لديها بالفعل نظام بناء كامل يقوم بالمهمة. أنا فقط بحاجة إلى أن أكون قادرًا على تحميل CVMFS.

لقد كنت متحمسًا للقيام بذلك باستخدام Dockerfile ، ولكن يبدو أنه سيتعين علي القيام بذلك بالطريقة الصعبة باستخدام بعض البرامج النصية مع docker run --privileged ، أو استخدام شيء آخر بدلاً من عامل الإرساء. هل هناك طريقة لتركيب نظام ملفات في حاوية _ بدون _ لها وصول مميز؟

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

drstapletron ، وفقًا لوثائق CERN cvmfs ، لديك خياران في الوقت الحالي ، إما تحميل cvmfs من مضيف إلى حاوية أو تثبيت cvmfs داخل حاوية مميزة.

بالنسبة لحالة الثواني ، لقد قمت للتو بكتابة ملف عامل ميناء لرجال cmssw ، هنا:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

باستخدام هذا الملف ، يمكنك فقط إنشاء صورة (أو يمكنك الحصول عليها من cmssw dockerhub) وتشغيلها في الوضع P ، وسيكون كل شيء موجودًا بالفعل داخل الحاوية (ls / cvmfs / *)

لست متأكدًا مما إذا كان هذا قد تم تناوله أعلاه لأنه قائمة طويلة إلى حد ما من التعليقات حول هذه المشكلة. أنا أيضا أود أن يكون لدي - أوامر بناء مميزة. حالة الاستخدام الحالية الخاصة بي هي العمل على حل مشكلة واجهتها مع إنشاء go ebuild في مرحلة جينتو 3. إذا لم أستخدم حاوية ، فإن التعليمات الحالية في كتيب gentoo تتسبب في أن يتصرف systemd بشكل خاطئ بمجرد أن أكون umount -l / mnt / gentoo / dev {/ shm، pts،} && umount -l / mnt / gentoo / { proc، sys} 'من نظام تم تمهيده باستخدام systemd ... عندما أقوم بنقل بناء stage3 الخاص بي إلى حاوية عامل إرساء ، كل شيء يعمل بشكل جيد حتى يتطلب البناء ptrace ، أو بعض الميزات المقيدة الأخرى ... وهي go-1.7.1. يبدو أن ebuild يتطلب.

في الوقت الحالي ، أقوم ببساطة بتشغيل الإنشاء داخل أمر Docker run ، والالتزام ثم المتابعة من هناك ، ولكن سيكون من الأفضل تمكين ptrace داخل أمر docker build نفسه لتجنب الخطوات اليدوية.

أود هذه الميزة أيضًا. أريد إنشاء بيئة بناء ، لكنها تتطلب وحدة kernel ولن يتعاون modprobe معي عندما أقوم بالبناء. هل هناك حلول لهذا؟

خاصة:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

يبدو أنه حالة استخدام معقولة تمامًا.

seltzy ، أقترح ألا تحبس أنفاسك في انتظار أي شخص من docker للاعتراف بمعقولية حالة الاستخدام الخاصة بك.

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

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

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

tamsky لقد

tamsky يمكنني أن أفهم لماذا تعتقد ذلك ، لأن المشروع لم يقبل ميزة تريدها بوضوح.

يمكنني أن أؤكد لكم أن هذا لا علاقة له بأي نوع من قرارات العمل. الحقيقة هي ، --privileged عند الإنشاء سينتج عن الصور غير المحمولة.
أشياء مثل modprobe في بيئة الإنشاء ليست مفيدة ويمكن أن تتسبب في أن ينتج عن بنائين نتائج مختلفة تمامًا.

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

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

شكرا لاهتمامكم.

@ cpuguy83 شكرا لك على التوضيح. لم أكن أدرك أنها كانت مشكلة في قابلية النقل. أفترض أن رغبتي في ذلك يغذيها سوء الفهم.

ما هو النهج الفلسفي العام الذي يجب اتباعه عند مواجهة إغراء امتلاك امتياز البناء؟

seltzy لا تكن متأكدًا تمامًا من أن حالة الاستخدام الخاصة بك ليست مثالًا معقولًا على الحاجة إلى هذه الميزة

@ cpuguy83 ما زلت أنتظر ردًا حول حالة الاستخدام الخاصة بي. يتم توزيع نظام إنشاء مؤسستنا عبر نظام ملفات الشبكة الذي يجب أن أقوم بتركيبه في الحاوية الخاصة بي. يتطلب هذا تشغيل الحاوية في الوضع المميز. قرار مؤسستي باستخدام نظام ملفات الشبكة لتوزيع البرامج ليس بالأمر غير المعتاد لفيزياء الجسيمات. أنت تدعي أن إنشاء صور غير محمولة على --privileged on build لكن هذا لا علاقة له تمامًا بحالة الاستخدام الخاصة بي. لقد تخلى نموذج التطوير لدينا بالفعل عن أي قابلية نقل قد نفقدها بسبب استخدامنا لنظام ملفات الشبكة (حقًا؟). نحتاج فقط إلى أن تكون آلة التطوير على وشك تركيبها.

@ cpuguy83 PS لقد ذكرت منشئ مخصص. أين يمكنني العثور على معلومات حول هذا؟ شكرا!

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

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

drstapletron إن تركيب نظام ملفات ليس بالضرورة شيئًا يمكن أن يكسر قابلية النقل (إلا إذا كان شخص ما يتوقع أن يتم تركيبه في الصورة).
تكمن المشكلة هنا في القدرة على تركيب نظام ملفات يعني أيضًا أن تكون قادرًا على القيام بمجموعة من الأشياء السيئة الأخرى.

ctindel نعم ، يمكنك فعل أي شيء تريده في الحاويات التي تنشئها. ومع ذلك ، فإن حقيقة أن docker build هي "" الطريقة المدعومة لبناء الصور ، مما يعني أننا بحاجة إلى التأكد من أن الصور المبنية بها _are_ محمولة.

الصور المحمولة ليست رنجة حمراء. قابلية حمل العمل هي هدف التصميم الأساسي لـ Docker. توجيهاتنا الرئيسية ، كما كانت.

seltzy معظم الأشياء التي تتطلب امتيازات إضافية تنتمي إلى وقت التشغيل ، لأنه في معظم الأحيان تُستخدم الامتيازات المرتفعة لتعديل المضيف بطريقة ما.
ومع ذلك ، يمكنني بالتأكيد أن أفهم أن بعض الأشياء مطلوبة في وقت الإنشاء (مثل nfs mount أعلاه) .... ولكن حتى مع حالة NFS وبناء الصورة يدويًا (ليس باستخدام docker build ) ، أنا لن أعطي الحاوية --privileged أو أي إمكانيات إضافية على الإطلاق ، وبدلاً من ذلك سأقوم بتركيب تصدير nfs كوحدة تخزين.

drstapletron mount لا يتطلب --privileged فقط مجموعة إمكانيات أكثر تقييدًا ومن المرجح أن يحدث في وقت أقرب بكثير من وضع الامتياز الكامل ، حيث يتيح ذلك الوصول الكامل إلى الجذر للمضيف وهو ما يفعله معظم الأشخاص لا اريد. (لا تزال بها مشكلات أمنية ولكن يمكن التحكم فيها بشكل أكبر).

لذلك لدي حالة استخدام محمولة بالكامل وغير معدلة للمضيف. إنه حتى مفتوح المصدر ويمكنك رؤيته هنا .

في الأساس ، أريد تشغيل Mock في حاوية Docker محمولة لإنشاء صورة CentOS ISO مخصصة. Mock ، لأولئك الذين لا يعرفون ، هو منشئ RPM حاويات. المشكلة هي أنه نظرًا لأنه يستخدم الحاويات ، فأنا بحاجة إلى --privileged أو --cap-add . من الناحية المثالية ، أعتقد أن docker build ستعمل كدالة ، مع أخذ بعض الحجج وإرجاع نتيجتها النهائية. لكن بدون هذه الأعلام ، لا يمكنني فعل ذلك.

كذلك هنا ! استخدام الزخارف داخل عامل الرصيف كابوس بسبب ذلك:

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

كتب @ cpuguy83 :

الحقيقة هي أن - الامتياز في البناء سينتج عنه الصور غير المحمولة.

لماذا لا تسمح --privileged لمن لا يحتاجون إلى إمكانية نقل بعيدة المدى؟
قد تكون ملاحظة بسيطة في الوثائق الرسمية بمثابة حل وسط معقول (على سبيل المثال _ تحذير: قد يؤدي تمرير --privilege إلى الأمر build إلى صورة أقل قابلية للحمل! _). هذا من شأنه أن يحل متطلبات الجميع تقريبًا ؛ لا يحتاج بعض المستخدمين إلى قابلية النقل ، والبعض الآخر يحتاج إلى ذلك ، وسيكون التحذير كافيًا لتلبية احتياجات الجميع.

أنا متأكد من أن عدم وجود build --privileged يعقد حالة الاستخدام الحالية بشكل كبير.

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

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

لا تعني قابلية نقل الحاويات أي شيء بالنسبة لي أو لعملي ، في الحقيقة سأراهن على أنها لا تعني شيئًا للغالبية العظمى من الشركات. المهم هو أنني أرغب في الاحتفاظ ببرامج أقل ، لذلك أعتقد أن اختيار قابلية النقل على سهولة الاستخدام في هذه المشكلة يضر بـ Docker.

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

+1 لهذا. في عملية البناء لدينا ، من الضروري تحميل / proc و / dev. من الناحية المثالية ، يجب أن نكون قادرين على الحصول على خطوة التحميل كجزء من ملف dockerfile.

@ samsun387 لماذا تتطلب عملية البناء هذا؟

skshandilya setfacl ليست محمولة وسأكون مندهشًا إذا كان من الممكن استمرار قائمة التحكم في الوصول إلى صورة.

robhaswell "يتطلب حاوية مميزة" لا يساعد كثيرًا. ما الذي يتم استخدامه بالفعل عند التثبيت؟

+1. الحرف الأول يحتاج هذا.
تقرأ تقريبا القضية برمتها. لا تفهم لماذا يستمر الناس في التساؤل "لماذا تحتاج هذا" لمدة 3 سنوات متتالية.

Betriebsrat لأن "X يحتاج هذا" ليس مفيدًا حقًا.
ماذا تفعل "X"؟ لماذا يحتاج "X" إلى هذا أثناء مرحلة البناء؟

على سبيل المثال ، الحالة المذكورة أعلاه مع إمكانات تحميل /proc و /dev لا تبدو حقًا المكان المناسب لمرحلة الإنشاء ، وحتى يبدو أن الصورة ستكون مرتبطة بالمضيف في مثل حالة.

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

يتم طرح هذه الأسئلة حتى نتمكن من الحصول على حالة الاستخدام الحقيقية وكيف يمكننا تلبية مثل هذه الحالة.

بالمناسبة ، عندما أقول "ميزات الأمان" ، فإنني أعني شيئين:

1. أشياء لمنع القرصنة
2. عزل اهتمامات التطبيق عن مخاوف المضيف (على سبيل المثال ، يجب ألا يربط بناء الصورة الصورة بالمضيف الذي بنيت عليه).

يبدو أنه تم حل لي بحلول عام 21051 ، أنا بالخارج الآن :)

shykes قال في 28 نوفمبر 2013 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

عذرًا ، التصميم الحالي هو فرض "مصدر واحد ، بناء واحد" وهذا هو السبب في أننا لا نسمح لأي وسيطات ببناء عامل الإرساء بخلاف دليل المصدر.

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

@ cpuguy83 ، هل تغير التصميم على الإطلاق من
هل مشروع Docker على استعداد لتغيير هذا التصميم والسماح بهذه الميزة التي يطلبها المجتمع؟

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

إن إضافة إعلان aa NEEDS_PRIVILEGED أمر منطقي ولكن كل هذه الأشياء المتعلقة بإيقاف الإنشاء مؤقتًا؟ ما عليك سوى الفشل مع ظهور خطأ والسماح للمشغل بتمرير الخيار --privileged إذا كان يريد بالفعل السماح للبناء ذي الامتيازات.

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

أنت لا تمنع الأشخاص بأي شكل من الأشكال من استخدام الوضع المميز في الإنشاء ، فأنت تجعل القيام بذلك أمرًا مزعجًا.

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

قل "لن نصلح هذا لأننا نريد أن يكون الأمر مزعجًا" وأغلق هذه المشكلة.

/مسلك

@ cpuguy83 ، من unshare(2) مع علامة CLONE_NEWNS وربما أخرى - عندما تنشئ بيئة chroot / Container الخاصة بها. هذا يتطلب على الأقل CAP_SYS_ADMIN .

ماذا تفعل "X"؟ لماذا يحتاج "X" إلى هذا أثناء مرحلة البناء؟

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

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

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

أنا أعارض بشدة هذا الافتراض. بشكل عام ، الأشخاص الذين يستخدمون --privileged هم نفس فئة المستخدمين الذين يديرون chmod -r 777 بشكل أعمى "لأن أحدهم كتب أنه أصلح المشكلة"

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

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

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

نحتاج إلى هذه الميزة لاستخدام العجينة أثناء البناء لتهيئة بعض الحاويات مسبقًا داخل الحاوية التي نبنيها.

ما الذي تناقشه هنا لمدة 3 سنوات؟

docker run لديه خيارات --cap-add و --cap-drop وغيرها. لذا فإن الأمر RUN في Dockerfile يريد أن يكون لديك نفس الخيارات. لذا فإن Dockerfile تريد إرسال الطلبات إلى الجهاز الأم واطلب منه إضافة / إسقاط بعض الامتيازات.

يمكن للآلة الأم أن تفعل ما تريد مع هذه الطلبات. يمكنك جعل shell تفاعليًا ، ويمكنك إنشاء مربع حوار لتأكيد واجهة المستخدم الرسومية ، وما إلى ذلك. لماذا تناقش حل هذه الطلبات في هذه المشكلة؟

يريد عدد كبير من مستخدمي عامل الإرساء القدرة على --cap-add أو --privileged في أمر build ، لتقليد ما هو موجود في أمر التشغيل.

لهذا السبب تم فتح هذه التذكرة لمدة 3 سنوات مع أشخاص يتناغمون باستمرار على الرغم من أن المشرفين ليسوا مهتمين بمنح المستخدمين ما يريدون في هذه الحالة المحددة.

ctindel هذه بالتأكيد مشكلة هذه المشكلة. هناك فجوة بين docker build --cap-add و RUN --cap-add .

يرغب بعض الأشخاص في حل طلبات الامتيازات من الجهاز التابع docker build --cap-add=caps_array . ما هذا؟ هذا فقط: caps_array.include? requested_cap .

بعض الناس يريدون pre_requested_caps.include? requested_cap . بعض الناس يريدون stdout << requested_cap, stdin.gets == 'y' بعض الناس يريدون gui_confirm requested_cap . بعض الناس يريدون بالتأكيد UAC_fullscreen_dialog requested_cap .

تعتمد طريقة الدقة requested_cap على ذوق المستخدم وأعتقد أن هذا السؤال لن يتم حله أبدًا.

لكن RUN --cap-add لا علاقة له بأذواق الناس. ما الذي ننتظره؟

@ andrew-aladev أنا لا أفهم حقًا ما تقوله رسالتك. النقطة المهمة هي أن الأشخاص لديهم برامج تابعة لجهات خارجية (RPMs ، DEBs ، أيًا كان) ليست تحت سيطرتهم ، والتي يريدون تثبيتها في صورة في وقت "إنشاء عامل الإرساء" ، والتي تتطلب قدرات إضافية من أجل التثبيت بشكل صحيح. نظرًا لأنها آليات RPM لطرف ثالث ، فلا توجد طريقة لحل متطلبات الامتيازات المتزايدة أثناء مرحلة التثبيت.

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

ctindel لغتي الإنجليزية ليست جيدة جدًا ، آسف.

أنا أعرف. لقد حاولت الظهور glibc وتلقيت ptrace not permitted .

docker تشغيل الحاوية بقدرات متزايدة / منخفضة بنفسه. RUN في Dockerfile يجب أن يدعم --cap-add ، --cap-drop ، إلخ.

لنتخيل أن لدينا Dockerfile سيحصل على RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . كيف ستعمل؟

1. ترسل آلة الطفل طلبًا إلى ولي الأمر وتطلب SYS_PTRACE .
2. الأصل يسمح بإمكانيات موسعة.
3. الأصل ينشئ حاوية جديدة مع SYS_PTRACE المسموح بها.

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

thaJeztah قال

بشكل عام ، الأشخاص الذين يستخدمون --privileged هم نفس فئة المستخدمين الذين يقومون بتشغيل chmod -r 777 بشكل أعمى

هذا الرجل يريد طريقة أكثر مرونة من التحقق من صحة يتطلب قدرات من مجرد log :info, requested_cap; return privileged? .

ctindel قلته

إن إضافة إعلان aa NEEDS_PRIVILEGED أمر منطقي ولكن كل هذه الأشياء المتعلقة بإيقاف الإنشاء مؤقتًا؟ ما عليك سوى الفشل مع ظهور خطأ والسماح للمشغل بتمرير الخيار --privileged إذا كان يريد بالفعل السماح للبناء ذي الامتيازات.

تريد أن تجعل قذيفة تفاعلية. تريد stdout << requested_cap, stdin.gets == 'y' . هذه هي طريقة أخرى للتحقق من القدرات المطلوبة.

@ cpuguy83 قال

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

هذا الرجل يريد docker build --cap-add=caps_array caps_array.include? requested_cap . هذه هي طريقة أخرى للتحقق من القدرات المطلوبة.

لذا فإنني أسأل: لماذا لا يزال لا يدعم RUN في Dockerfile --cap-add ، --cap-drop ، إلخ؟ لا أحد يجادل في ذلك. مرت 3 سنوات!

@ andrew-aladev أفترض أن أحداً لم يجادل في بناء الجملة هذا لأنه تم توضيح أن بناء جملة dockerfile مجمدة حتى تتم إعادة كتابة / إعادة تشكيل / فصل المنشئ عن المحرك الرئيسي. https://github.com/docker/docker/issues/29719#issuecomment -269342554

وبشكل أكثر تحديدًا ، يطلب عنوان المشكلة و OP - إنشاء متميز

هذا يحصل على إبهام فونزي: .

القدرة على تشغيل strace في الخطوة build تساعد كثيرًا.
حاليًا ، أعمل على حل هذه المشكلة عن طريق نقل كل الأشياء التي أحتاج إلى تصحيحها إلى الخطوة run - ليست مثالية.

هل يعرف أحد سبب نجاحه في run وليس في build الخطوة؟ أي الأسباب التاريخية.
هل هناك بديل لـ strace يعمل بدون الكثير من الأذونات أو التهيئة؟

يوجد حل / حل بديل مقترح لهذا في
https://github.com/docker/docker/issues/6800#issuecomment -50494871:

إذا كانت لديك مشكلات في إصدار docker ، فيمكنك استخدام "حاوية Builder":
docker run --cap-add [...] mybuilder | docker build -t myimage -

هل يمكن لشخص ما (ربماtiborvass) أن يوضح هذا بالتفصيل؟ ما هو نوع mybuilder هنا؟
اسم الصورة مع بعض نقطة الدخول؟ أو جزء الصورة من [...] و mybuilder يشير
إلى برنامج نصي شل؟ وكيف أقنع docker run بتمرير السياق .tar.gz إلى docker build -
إذا كان هذا هو ما يحدث هنا حقًا. شكرا مقدما ، ستيفن

sneumann mybuilder سيكون اسم صورة وله بعض CMD أو ENTRYPOINT بالفعل. عقد هذا الحل للعمل هو أن mybuilder سيتعين عليه tar السياق من داخل الحاوية والسماح له بالانتقال إلى stdout. يتم تمرير ذلك إلى docker build s stdin ، بفضل أنبوب الصدفة | ويعتبر السياق لأن مسار السياق لـ docker build -t myimage - هو - .

غريب بعض الشيء عند النظر إلى الكود ، يبدو أن هذا الخيار متاح في الأمر build :

• run : أفترض أن container هنا يعني run - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go # L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

هل لدى أي شخص آخر فكرة عن سبب عدم تطبيقه؟

mbana ، --security-opt مخصص لحاويات Windows الأصلية ، والتي تدعم "بيانات الاعتماد" https://github.com/docker/docker/pull/23389

هل من الممكن تعديل هذا وجعله مستمرًا بحيث يُمكّن build ptrace ؟

لأي شخص مهتم ، إليك بعض الروابط الجيدة:

• http://www.projectatomic.io/docs/docker-building-images/ - كيفية إنشاء الصورة باستخدام التقنية الموضحة أعلاه. على سبيل المثال ، استخدم run إلى build للصورة.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - متفرقات

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

في الوقت الحالي ، سأعمل على حل هذا الأمر باستخدام docker run و docker commit ولكن سيكون من الرائع أن يدعم docker build حالة الاستخدام هذه.

scjody يبدو وكأنك تريد # 31257

@ cpuguy83 لست متأكدًا من تغطية ما يحدث في هذه الحالة ، لكنني

مرحبًا ، أود إلقاء اسمي في قبعة الرجاء تنفيذ هذه. أو ربما هناك حل مختلف لمشكلتي (docker noob هنا) يمكن لأي شخص أن يوجهني إليه؟

أحاول إنشاء صورة بناءً على صورة centos / systemd الرسمية

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

هل فكرت في تنفيذ الإنشاء عن طريق تشغيل حاوية وتنفيذ النتائج ( docker commit )؟

شكرا لاستجابتكthaJeztah. لم أكن أدرك أن هذا ما فعله التوجيه RUN . لقد قرأت معظم هذه المشكلة ، لذا فأنا على دراية بالحل البديل docker build -> docker run -> docker commit ، وهو ما سأفعله على الأرجح. أنا فقط أؤيد وجود ملف واحد يصف صورتي - يبدو أكثر إتقانًا. ربما يمكنني وضع كل هذه الخطوات في المعالجات اللاحقة للرازم وبعد ذلك سأحصل عليها.

لماذا هذا واحد تم تجاهله كثيرا؟ في أوقات الحاويات و kubernetes و minikube ، واستخدام عامل الإرساء في CI وتوحيد بيئة التطوير ، تعد هذه الوظيفة مهمة حقًا.

onlyanegg ، يجب أن تكون قادرًا على إعادة تشغيل الخدمات RUN في السطر 8 من Dockerfile هذا لا يعمل لأنه يتطلب وضعًا متميزًا") سأكون أكثر من سعيد لإلقاء نظرة!

@ ديربيرغ على وجه التحديد! في أوقات الحاويات ، CI ، CD ، من المهم احتواء أدوات البناء (بالمعنى الأمني). إذا سمحت بالوضع المتميز ، فسيتعين عليك تغيير طريقة استخدامك لأدوات CI بشكل كبير مثل Jenkins و Travis و Codeship وما إلى ذلك. نفس السؤال: إذا كان لديك Dockerfile يتطلب وضعًا متميزًا ، فسيسعدني إلقاء نظرة لاقتراح البدائل.

شكرا لك!

jpetazzo حاول الحصول على صورة عامل ميناء بداخلها عامل ميناء:

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

الآن قم ببنائه وابدأ. بعد البدء ، قم بتشغيل service docker start لبدء docker deamon. ثم تحقق من حالة الخدمة service docker status :

• مع حالة العلم المميز على ما يرام ويمكنك بدء الحاوية دون مشاكل
• بدون العلم ، لن يبدأ أبدًا

jpetazzo ech ، لقد لاحظت للتو أنك منشئ https://github.com/jpetazzo/dind :) لذا فأنت على دراية بمفهوم عامل المرفأ :)

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

إذن ، هل هناك طريقة لتركيب مشاركة NFS أو SMB في docker build حتى الآن؟

derberg لن تعمل هذه الخطوات ، حتى لو كانت حاوية --privileged ؛ حزم docker (وتثبيت البرنامج النصي) هي (على سبيل المثال) تثبيت حزم kernel على Ubuntu 16.04.
هذا هو بالضبط السبب في أن --privileged فكرة سيئة لـ docker build ، لأنه سيكون قادرًا على إجراء تغييرات على _host_.

على الرغم من أن عامل الإرساء سيحتاج إلى امتياز عند التشغيل ، فإن التثبيت نفسه لا يحتاج إلى ذلك ؛ على سبيل المثال ، إليك الخطوات التي ستنفذها لتثبيت عامل الإرساء في صورتك ؛

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

ويمكنك تشغيله على ما يرام (أنا أستخدم --privileged هنا ، ولكن ربما تكون الأذونات الأكثر دقة ممكنة):

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

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

تحتاج هذه الطريقة إلى Dockerfile ، وملف docker-compse ، و shell script.

ملف Dockerfile

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

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

تلك الأوامر التي تحتاج إلى أن يتم تشغيلها في وضع الامتياز هي الآن في further-commands-to-run-in-privileged-mode.sh . تم تضمينه في الصورة وسيتم تشغيله لاحقًا بواسطة docker composer لإنهاء عملية الإنشاء.

يقوم عامل التحميل بإنشاء ملف

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

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

بناء الصورة

يمكن أيضًا حفظ الخطوات أدناه في نص برمجي.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

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

أضف البرنامج النصي التالي إلى Dockerfile الخاص بك وسترى أن خدمة عامل التحميل لا تعمل أبدًا

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

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

أيضًا - إذا كانت صورك كبيرة (على سبيل المثال ، أي شيء آخر غير ، على سبيل المثال ، busybox أو alpine ) فسوف ينتهي بك الأمر مع صورة DinD كبيرة جدًا ...

أرغب في معرفة المزيد عن حالة الاستخدام النهائية - لأنني متأكد من أنه يمكننا مساعدتك في العثور على طريقة أكثر فاعلية من إعداد صورة DinD ضخمة :-)

(بخلاف ذلك ، فإن الحل الذي اقترحه kraml أنيق إلى حد ما!)

راجع أيضًا https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
يقوم بتنزيل الصور باستخدام bash + curl + tar فقط.
نستخدمه هنا: https://github.com/moby/moby/blob/master/Dockerfile#L171

jpetazzo ، لقد قمنا بالفعل بتشغيل مثل هذا الحل ، build- dind

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

بالعودة إلى هذا الموضوع ومراجعة السنوات الأربع (!!!) كاملة من ذهابًا وإيابًا حول مسألة كيفية إضافة نوع من القدرات المميزة إلى أمر إنشاء عامل ميناء ، يبدو أن الخيارات المتاحة في هذه الحالة إما مجموعة سيئة من أوامر sed لتعديل المثبت لإزالة استدعاءات sysctl ، أو بناء متعدد المراحل -> تشغيل -> خط أنابيب الالتزام. أتفق مع derberg على أن "build -> run -> الالتزام" يبدو أنه حل بديل (imo حل إجمالي / اختراق) ولا أعتقد أن حالة الاستخدام الخاصة بي فريدة من نوعها. التحقق من سلاسل الرسائل الأخرى رأيت الكثير من الأشخاص يبلغون عن مشكلات مع العديد من عمليات تثبيت التطبيقات وقاعدة البيانات مع أوامر docker build الفاشلة بسبب نقص الامتيازات.

في هذه المرحلة ، يدعم أمر Docker run خيارات "مميزة" واسعة النطاق ، جنبًا إلى جنب مع "التحكم الدقيق في الحبوب على القدرات باستخدام --cap-add و-cap-drop". وهكذا ، أعتقد أن الاعتراضات على أسس أمنية أو تقنية هي موضع نقاش. إذا تمت إضافة خيار التشغيل ذي الامتياز مع "--cap-add" و "--cap-drop" ، فيمكن للمهندس الواعي بالأمان أن يختار تقييد بناء ذي امتياز ليشمل فقط القدرات المحددة المطلوبة لبنيته.

أهلا ،

لقد سبق أن أبلغت عن هذا من قبل ، نفس المشكلة.

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

هل لا يزال هناك قلق أمني يتعلق بهذا؟

ركض في هذه المشكلة. يمكن حقا استخدام القدرات للبناء.

ركض في هذه القضية أيضا.
إنه مفيد جدًا عند استخدام عامل الإرساء كعبيد CI / CD والذي قد يتطلب إذنًا مميزًا على docker build لتثبيت سلاسل أدوات إنشاء / اختبار CI / CD عند إنشاء صورة عامل إرساء الرقيق.
أنا في انتظار هذه الميزة لسنوات وآمل حقًا أن يتم دعمها في المستقبل.

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

اعتبارًا من اليوم ، لم يتم تنفيذ هذه الميزة حتى الآن:
RUN --cap-add = SYS_PTRACE
والتي من شأنها أن تناسب احتياجات العديد من المستخدمين ..

هل يمكنك اقتراح كيف يمكنني إنشاء Dockerfile هذا على مضيف Gentoo Linux:

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

لأنني أتلقى هذا الخطأ عند ظهور dev-lang / go:

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

كيف يمكنني تشغيله بدون --cap-add=SYS_ADMIN --device /dev/fuse أو --privileged ؟

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

يمكنني القيام بذلك باستخدام ملف bash منفصل في نقطة الدخول ، لكنني بحاجة إلى ملف Dockerfile واحد

@ amd-nick ما هو توقعك لخط RUN unionfs-fuse ... أثناء الإنشاء؟ حتى لو نجح ذلك ، فسيتم تثبيت نظام الملفات فقط خلال هذا RUN ، وسيختفي في الخطوة التالية.

thaJeztah من الصعب أن أشرح لي. أحاول تعديل هذا الريبو . هل يمكنني فقط تخطي هذا الخط في المبنى؟

أهلا

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

أرغب أيضًا في الحصول على خيار لتشغيل docker build باستخدام RUNP أو الحصول على خيار لاختيار اسم المضيف أثناء الإنشاء.

هل حاول أي شخص بناء هذه الأنواع من الصور مع كانيكو ؟ لقد قمت بذلك للتو باستخدام ملف Dockerfile الخاص بـmaneamarius على Docker لنظام التشغيل Mac ويبدو أنه قد تم إنشاؤه بنجاح بمجرد استدعاء أمر Kaniko docker run "build" باستخدام --cap-add=SYS_PTRACE . على الرغم من ذلك ، أواجه مشكلة صغيرة في تحميل كرة القطر الناتجة محليًا ، إلا أن استخدام ذاكرة الوصول العشوائي مرتفع بعض الشيء نظرًا لأنه لا يمكنه استخدام التراكبات ، ولا يزال التخزين المؤقت للطبقة قيد العمل قيد التقدم. قد تعمل الأشياء فقط إذا دفعت إلى التسجيل ولكني لم أحاول ذلك بعد.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

سيساعد الحصول على هذه الميزة بشكل كبير في الجهود المبذولة لبناء صور Docker عبر Puppet على صور قاعدة Redhat / CentOS.

منذ أن نشرت آخر مرة ، تابعت التغييرات في Kaniko احتياطيًا. لم تعد تتأرجح في الذاكرة وتتطاير على القرص مما يعني دعم ملفات Dockerfiles التي تصف الصور الكبيرة. لا يزال التخزين المؤقت للطبقة قيد العمل قيد التقدم ، لكن لديهم خيارًا للتخزين المؤقت للصور الأساسية في الوقت الحالي (هذا يعني عدم وجود تكرار سريع في الوقت الحالي RUN حفظ وتشغيل نوع من العمل ولكن يمكننا تخزين alpine ، ubuntu ، ومهما كانت القواعد الشعبية الموجودة هناك).

إنها في حالة نجحت فيها في بناء ملف Dockerfilemaneamarius والذي يظهر Golang في صورة Gentoo في هذا المشروع / العرض التوضيحي دون تعديل ملف Dockerfilemaneamarius أو تقطيعه بأي شكل من الأشكال ( تحرير: لقد قمت بذلك منذ ذلك الحين اضطررت إلى تعديل Dockerfile لتثبيت الصورة الأساسية لـ gentoo بالإصدار الذي كان latest في وقت هذا المنشور. وإلا فإنها لا تزال غير معدلة. ):

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

لقد قمت أيضًا بتكوين Azure Pipelines لإنشاء Dockerfile في صورة مع Kaniko بـ --cap-add=SYS_PTRACE ، قم بتحميل tarball الناتج Kaniko ، وقم بتشغيل go version في الصورة التي تم إنشاؤها. اعتقدت أن بعض "دليل الحياة" التفاعلي سيكون ممتعًا. كانت بعض التعليقات السابقة هنا أيضًا مهتمة بأنظمة CI لذلك اكتشفت أنني سأقوم بتهيئة نظام CI عام للعمل أيضًا. راجع للشغل ، تم النظر في Travis CI ولكن ناتج البناء كان طويلاً للغاية وتم إنهاؤه و Azure سعيد تمامًا بـ 166 ألف سطر من الإنتاج. إذا تم إنشاء Dockerfile بحوالي 70 ألف سطر أقل من الناتج ، فمن المحتمل أن يكون قد نجح في Travis CI. يوجد ارتباط إلى مخرجات بناء Azure Pipeline في الجزء العلوي من README.

استخدم buildah Luke

أقوم بإغلاق هذه المشكلة ، لأن الميزة متاحة الآن كـ docker buildx build --allow security.insecure

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run - securityinsecuresandbox

AkihiroSuda لقد قمت بتحديث عامل buildx . عندما كنت أحاول الأمر الذي ذكرته ، فقد أعطاني خطأ

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

مستندات buildx: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

AkihiroSuda شكرا. عملت الآن.

فقط لإضافة حالة استخدام أخرى.
أحاول إصلاح ملف عامل بناء حاوية ibmdb2 بقاعدة بيانات اختبار
أزالت IBM الصورة v10 من المحور. لكن صورة v11 DB تبدأ فقط بـ --privileged.
لذا فإن جميع التعليمات البرمجية التي تقوم بإعداد قاعدة البيانات في Dockerfile لا تعمل الآن لأن db2 لا يبدأ بدون امتياز. :(
يبدو أن هناك حلًا معقدًا باستخدام تشغيل عامل الإرساء والتزام عامل الإرساء.
في خط أنابيب البناء المنتج ، يخلق هذا الكثير من التعقيد الإضافي.

يجب أن أسأل مثل https://github.com/maneamarius في https://github.com/moby/moby/issues/1916#issuecomment -361173550

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

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

uvwild لست متأكدًا مما إذا كان هذا يساعد في حالة الاستخدام الخاصة بك ولكن يمكنك محاولة البناء باستخدام kaniko سيتم إنشاء صورتك بدون docker deamon ويمكنك استخراج الصورة بمجرد الانتهاء منها واستخدام kaniko يشبه تشغيل حاوية يمكنك استخدام --privileged أو --cap-add <capability which is needed> مما قد يحل مشكلتك.

أوافق على أنه ليس حلاً كاملاً كنت تتوقعه ولكنه حل بديل أسهل قد يتناسب مع خط أنابيب البناء الخاص بك.

تحرير: كما قال @ alexey-vostrikov إن buildah يمكن أن يكون حلاً أكثر جدوى لحالات الاستخدام التي تحتاج --privileged لبناء الصورة