لست متأكدًا من فهمي ، docker-compose run --user هو أحد الخيارات ، و docker-compose.yml يدعم المفتاح user (http://docs.docker.com/compose/yml/ # working95dir-entrypoint-user-hostname-domainname-mem95limit- ذي امتياز-إعادة التشغيل-stdin95open-tty-cpu95shares).

أعتقد أننا سنحتاج إلى دعم الدقة المتغيرة للبيئة في الحقل user حتى تتمكن من تعيينه على $UID هل هذا صحيح؟ # 1377

أهلا. نعم ، التوسيع $UID سيفي بالغرض في هذه الحالة. ومع ذلك ، سيكون الخيار --user docker-compose up لأمر $ # $ 2 $ # $ (ليس فقط لـ docker-compose run ) مفيدًا لبدء المشروع بأكمله كمستخدم معين.

الهدف هو السماح بتحديد المستخدم دون لمس yml.

بدء المشروع بأكمله كمستخدم معين

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

لا تهتم ، لقد قمت بالتمرير لأعلى. هل أنا محق في التفكير في أنك تستخدم نظام Linux؟ عند استخدام boot2docker ، فإنه ينشئ ملفات ذات أذونات معقولة.

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

نعم ، على Linux.

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

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

قد يكون up --user خطيرًا إذا كانت بعض الحاويات / الخدمات تحدد مستخدمًا بالفعل.

mrzechonek لا أعتقد أن تعديل حاوية بسبب بيئتها هو ممارسة جيدة.

josephpage نعم ، قد يكون كذلك. توسيع UID $ سيفي بالغرض بالرغم من ذلك.

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

أنا أفضل في الواقع أن تكون هذه الميزة موجودة في Damon نفسه ، مثل aanand قال. أو ربما يكون خيارًا لتركيب وحدة تخزين في مثل هذا الوضع (ربما برنامج تشغيل تخزين؟).

mrzechonek ، هل وجدت حلاً؟

لا حقا لا. نقوم حاليًا بعمل docker-compose run --user ثم نعيد تسمية / إعادة تسمية الحاوية لجعل compose يعتقد أنه بدأ بواسطة الأمر up ، بحيث يكون stop و ps سيعمل.

1377 في المستوى الرئيسي وسيكون في الإصدار 1.5.0 ، لذلك ستتمكن من القيام بـ user: $UID في docker-compose.yml . إذا كنت مرتاحًا لاستخدام Master ، فيمكنك تجربته الآن ، وإلا فسيتم إصدار RC في الأسابيع القليلة المقبلة.

سأغلق هذه المشكلة نظرًا لأن الميزة نفسها تم تنفيذها كجزء من # 1377

ثم أعد تسمية / إعادة تسمية الحاوية لجعل الإنشاء يعتقد أنه بدأ بأمر up

هذه في الواقع ليست المرة الأولى التي أسمع فيها عن الحاجة إلى هذا (على الرغم من أنني أعتقد في هذه الحالة أنها مؤقتة فقط). لدي إصلاح مقترح له في # 2042

شكرا لك ، # 1377 يصلح هذا بلطف.

mrzechonek هل يمكنك توضيح كيف أدى ذلك إلى حل مشكلتك؟ لدي نفس حالة الاستخدام بالضبط: "أرغب في أن ينشئ التطبيق المرسي ​​ملفات مملوكة لي ، وليس الجذر"

حاولت إضافة user: $UID إلى الحاوية web وعندما أستخدم docker-compose run web touch foo أحصل على ما يلي:

WARNING: The UID variable is not set. Defaulting to a blank string.

تم إنشاء الملف foo ، لكنه لا يزال مملوكًا لـ root .

لقد استخدمت user: $USER ، لكن $UID يعمل أيضًا. لا أعرف لماذا يشكو الإعداد الخاص بك من المتغيرات المفقودة :(

تواجه نفس مشكلةmichaelmior.

عند استخدام $ USER بدلاً من ذلك ، أحصل على System error: Unable to find user Max . وهو أمر منطقي لأنه مستخدم مضيف.

ما الذي قد يتسبب في عدم توفر $ UID أثناء تنفيذ Docker-Compose؟

مرحبا نفس المشكلة هنا
أنا في Fedora 23 ، ولا يتم نشر متغير UID عند استدعاء الأمر env على المضيف.

الحل:
قم بإجراء export UID على المضيف أولاً ، ثم اتصل بـ docker-compose

سيكون من الرائع لو أن عامل الإرساء أتاح للتو $UID دون الحاجة إلى تصديره. ينتهي الأمر بالنمط المعياري.

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

لذا فإن الإنشاء ببساطة كتطبيق قيد التشغيل ليس لديه أي طريقة لاستنتاج المستخدم الذي يعمل به؟

بالتأكيد ، يمكنه قراءة متغير البيئة $USER ، ولكن يمكنك القيام بذلك أيضًا من ملف Compose! إذا لم يتم تصدير المتغير ، فلن يكون متاحًا للعمليات الفرعية. يبدو أن الحل السهل حقًا هو مجرد تصديره.

أنا أفكر أكثر في أنه إذا لم يتم الإعلان عن UID ، فيمكن للملف التنفيذي أن ينظر إلى معرف من قام بتشغيله وإتاحته على هذا النحو.

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

هل هناك مورد لطيف يوضح أي مشكلات أخرى مماثلة بين مضيفي Mac و Linux؟

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

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

mrzechonek هل يمكنك مشاركة كيفية استخدام التوجيه user: للتأكد من صحة أذونات الملف على المضيف والحاوية؟

أقوم ببساطة بإضافة user: $UID إلى ملف .yml . هذا موجود في Linux و Gentoo و Ubuntu 12.04.

تضمين التغريدة هل تقوم الحاوية الخاصة بك ببعض السحر وقت التشغيل؟ بقدر ما أفهم ، يعكس user: تعليمات Dockerfile. لكن هذا يعني ببساطة أن الأوامر الموجودة داخل الحاوية تعمل كـ user: $UID . لا أستطيع أن أفهم كيف يساعد ذلك مع أذونات الحجم = /.

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

فكر: _ " root في الحاوية يكتب كـ myuser مستخدم على المضيف" _.

في حالة الاستخدام لدينا ، دائمًا ما يقوم المستخدم نفسه ببناء الحاوية وتشغيلها ، لذلك لا توجد مشكلة.

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

لا أعتقد أن هذا شيء يمكن أن يفعله docker-compose .

يبدو أنني فاتني بعض الإصدارات: https://integratedcode.us/2015/10/13/user-namespaces-have-arrived-in-docker/

عذرًا ، لم أعد أستخدم Docker بعد الآن ، على الأقل ليس نشطًا في المشروع الحالي.

شكرا mrzechonek. في النهاية ، أحاول أن أفعل ما يحاول gkop القيام به - جعل الملفات التي تم إنشاؤها بواسطة الحاوية على وحدات التخزين المثبتة على المضيف مملوكة لبادئ الحاوية. هذه هي الطريقة التي تعمل بها على OS X مع أحدث إصدار تجريبي من Docker 1.12 (كيف؟) وهذه هي الطريقة التي أرغب في رؤيتها على نظام Linux أيضًا.

mrzechonek - تتطلب بعض التطبيقات تشغيلها كمستخدم معين ، أو تتطلب أن يكون المستخدم الذي يقومون بتشغيله بمثابة خريطة لمستخدم حقيقي في النظام. في هذه الحالات ، يكون من الأسهل تركها كجذر والقيام بالرسم فوق رأس الحاوية.

(هذا بدلاً من الكثير من الاختراقات القبيحة لتعيين مخطط مستخدم نظام التشغيل الحالي على الحاوية فقط للحصول على كل شيء مصطفًا)

@ dmitrym0 أعتقد أنه في ظل OSX ، تقوم بتشغيل boot2docker داخل ظاهرية OSX أصلية (https://github.com/mist64/xhyve/) ثم يتم إنشاء الحاويات داخل ذلك الجهاز الظاهري. هذا يعني أن الجهاز الافتراضي هو الذي يقوم بكل عمليات تعيين المستخدم ، وليس برنامج Docker daemon. الحاوية root لا تزال root للمضيف.

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

+1 لعامل الإرساء - تكوين - المستخدم أو المستخدم المنفذ ....

هل هناك حلول أو أخبار عن هذه المشكلة؟

كلا ، لقد فتحت هذه الميزة ضد محرك عامل الإرساء منذ فترة طويلة: https://github.com/docker/docker/issues/22415

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

إذا كان هذا شيئًا تهتم به ، أقترح مشاركة التذكرة التي ربطتها والتأييد لها.

هذا يعمل بالنسبة لي: user: "1000:1000"

jovanialferez FYI إذا قمت بتشفيرها على هذا النحو ، فستواجه مشكلة إذا شارك أشخاص آخرون في المشروع الذي لم يتم ضبط معرفهم الفريد ومعرفهم التعريفي على 1000. أعتقد أن OSX يبدأ في ترقيم المستخدمين العاديين على 500 ، وأي نظام Linux التثبيت مع عدة مستخدمين سينتهي به الأمر برقم UID أكبر من 1000.

jovanialferez الذي سيعمل فقط على Linux.

وأشار. nfmluispabon _

لقد انتقلت مؤخرًا من نظام Mac إلى Linux وتعرضت للتو لهذا ، لا أفهم حقًا كيف لم يتم حل هذا بعد

ذكر هذه المشكلة مرة أخرى حتى يراها القادمون الجدد: https://github.com/moby/moby/issues/22415

نحتاج حقًا إلى القدرة على تعيين عمليات عامل ميناء خارجيًا لمستخدم معين. التركيز على الخارج . لا تختار UID / GID للعملية في الحاوية. لكن قم بتعيين عملية الحاوية إلى UID / GID محلي من الخارج.

نعم فعلا. تعيين uid / gid للمستخدم الحالي في الحاوية يعمل فقط في Linux. يبدو وكأنه مشكلة عامل ميناء بالرغم من ذلك.

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

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

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

لا يتم تصدير UID $ على Linux افتراضيًا ، حسنًا؟ هذا يمنعنا من إنشاء عامل ميناء عام - وهو أمر غريب في حد ذاته حيث يُفترض أن يكون هذا البرنامج حلاً أماميًا ، أليس كذلك؟

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

services:
  web:
     ...
     host_command: export UID

أليس هذا واضحا؟

+1

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

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

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

@ darkguy2008 - تأكد من الترويج لهذا الأمر: https://github.com/moby/moby/issues/22415

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

لست متأكدًا من فهمي ، docker-compose run --user هو أحد الخيارات ، و docker-compose.yml يدعم المفتاح user (http://docs.docker.com/compose/yml/ # working95dir-entrypoint-user-hostname-domainname-mem95limit- ذي امتياز-إعادة التشغيل-stdin95open-tty-cpu95shares).

أعتقد أننا سنحتاج إلى دعم الدقة المتغيرة للبيئة في الحقل user حتى تتمكن من تعيينه على $UID هل هذا صحيح؟ # 1377

الارتباط معطل.

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

version: "3"
services:
  testapp:
    image: ubuntu:20.04
    entrypoint: /bin/bash -c "cd $PWD && touch tmp"
    user: ${CURRENT_UID:?"Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"}
    volumes:
      - $PWD:$PWD

سوف تظهر:

ERROR: Missing mandatory value for "user" option in service "testapp": "Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"

تحديد أن الملف يجب أن يتم تنفيذه على النحو التالي:

CURRENT_UID=$(id -u):$(id -g) docker-compose up

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

version: "3"
services:
  testapp:
    image: ubuntu:20.04
    entrypoint: /bin/bash -c "cd $PWD && touch tmp"
    user: ${CURRENT_UID:?"Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"}
    volumes:
      - $PWD:$PWD

سوف تظهر:

ERROR: Missing mandatory value for "user" option in service "testapp": "Please run as follows 'CURRENT_UID=$(id -u):$(id -g) docker-compose up'"

تحديد أن الملف يجب أن يتم تنفيذه على النحو التالي:

CURRENT_UID=$(id -u):$(id -g) docker-compose up

المشكلة هي أن خدماتي تتطلب وصولاً إلى root للبدء. على سبيل المثال:

app-php-fpm  | [14-Jun-2020 00:15:12] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
app-php-fpm  | [14-Jun-2020 00:15:12] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
app-redis    | 1:M 14 Jun 2020 00:15:12.710 * Ready to accept connections
app-php-fpm  | [14-Jun-2020 00:15:12] ERROR: Unable to create the PID file (/run/php-fpm.pid).: Permission denied (13)
app-php-fpm  | [14-Jun-2020 00:15:12] ERROR: FPM initialization failed
app-webserver exited with code 1
app-mysql exited with code 1
app-php-fpm exited with code 78