Moby: साझा वॉल्यूम के लिए uid और gid को कॉन्फ़िगर करने योग्य बनाएं

मुझे नहीं पता _how_ उन्होंने इसे लागू किया है, और यदि एक तुलनीय सुविधा लिनक्स पर मौजूद है, लेकिन ओएस एक्स पर, वॉल्यूम पर 'स्वामित्व को अनदेखा' करने के लिए एक सुविधा मौजूद है। प्रभावी रूप से यह _any_ उपयोगकर्ता को फाइलों/निर्देशिकाओं को इस तरह देखेगा जैसे कि वे मालिक थे।

हालांकि यह सभी मामलों में काम नहीं करेगा, यह एक अच्छा जोड़ हो सकता है

+1

संबंधित: http://stackoverflow.com/questions/23544282/what-is-the-best-way-to-manage-permissions-for-docker-shared-volumes

gh#5910 इसे SELinux की ओर से हैंडल करता है।

लिंक: #5910;)

SELinux परिवर्तन वास्तव में सामग्री पर लेबल बदल रहा है। संभावित रूप से आप मेजबान पर बदलाव कर सकते हैं। मैं यूआईडी/जीआईडी ​​के लिए ऐसा करने का कोई अन्य तरीका नहीं जानता। लेकिन माउंट पॉइंट पर chown -R $UID:$GID करना।

या आप एसीएल का उपयोग करके इस प्रकार की पहुंच जोड़ सकते हैं। लेकिन मुझे लगता है कि आपको आरोह बिंदु पर प्रत्येक INODE को बदलना होगा।

मुझे भी यह सुविधा चाहिए।

उदाहरण के लिए, मैं वेब कंटेनर बनाना चाहता हूं, और वेबसाइटों और कॉन्फ़िगरेशन के साथ वॉल्यूम संलग्न करना चाहता हूं, ताकि कंटेनर किसी भी वेबसाइट के लिए पूरी तरह से सार्वभौमिक हो।

हालाँकि, मुझे वेबसाइट रिपॉजिटरी में कोड पुश करने के लिए git एक्सेस की आवश्यकता है। चूंकि मैं अपने ऐप्स को अलग रखना चाहता हूं - मैं चाहता हूं कि प्रत्येक वेबसाइट निर्देशिका अलग उपयोगकर्ता/समूह के स्वामित्व में हो, और यह बहुत अच्छा होगा यदि डॉकर कंटेनर द्वारा वॉल्यूम में लिखी गई फाइलें उस अलग उपयोगकर्ता/समूह के स्वामित्व में होंगी।

इस सुविधा के लिए +1।
मुझे समझ में नहीं आता कि इसके बिना पढ़ने/लिखने की मात्रा कैसे काम कर सकती है। छवि और होस्ट पर guid/uid के समान होने की अपेक्षा करना डॉकर के अलगाव सिद्धांतों के साथ असंगत एक मजबूत आवश्यकता है।

मैं व्यक्तिगत रूप से अपने डॉकराइज्ड डेवलपमेंट टूल्स के लिए बदसूरत और धीमे यूजरएड/ग्रुपएड कमांड के साथ काम कर रहा हूं: https://github.com/ndless-nspire/Ndless/blob/master/ndless-sdk/bin-docker/nspire-docker

मैं पूरी तरह से बिंदु खो रहा हूँ। लेकिन मैं इसी तरह के मुद्दे से जूझ रहा था जहां मैं यह सुनिश्चित करना चाहता हूं कि http उपयोगकर्ता के पास/var/log पर लिखने की अनुमति है, जो एक वॉल्यूम है और रूट के साथ मेजबान से होने की संभावना है रूट ।

मैंने इसे एक एंट्रीपॉइंट सेट करके हल किया है जो सुनिश्चित करता है कि लॉगडायरेक्टरी बनाई गई हैं और सही अनुमतियां हैं। मुझे लगता है कि यह काम करता है क्योंकि एंट्रीपॉइंट स्क्रिप्ट रूट के रूप में चलती है।

(हटाई गई टिप्पणी -- गलत टैब, क्षमा करें)

मैंने इसे डॉकर के बाहर उबंटू में हैक किया। पैकेज बाइंडफ्स स्थापित करें और कंटेनर के अंदर उपयोग किए गए यूआईडी और जीआईडी ​​​​मैपिंग करते समय वॉल्यूम सामग्री के साथ निर्देशिका को दूसरे पथ पर बांधें:

सुडो बाइंडफ्स -यू यूआईडी-जी जीआईडी ​​ओल्डपाथ न्यूपाथ

फिर डॉकर वॉल्यूम के रूप में न्यूपाथ का उपयोग करें। Oldpath अभी भी मेज़बान के लिए सही स्वामित्व दिखाता है, अतिथि के लिए newpath।

@jjv समस्या बाइंडफ्स वास्तव में वास्तव में धीमी है।

@ cpuguy83 हाँ यह इष्टतम से बहुत दूर है, लेकिन शायद इसी तरह की स्थिति में किसी की मदद करता है। यह एक विकास वर्चुअल मशीन के अंदर काम करने वाली चीजों को प्राप्त करना था (vmhgfs यूआईडी/जीआईडी ​​सेट करने की अनुमति नहीं देता है) जबकि उत्पादन में यूआईडी और जीआईडी ​​​​को अभी भी मेजबान और अतिथि के बीच मेल खाना है ...

यह वास्तव में अच्छा होगा यदि docker इसे लागू करते समय एक प्रकार की bindfs कार्यक्षमता का उपयोग किया गया था, यह मानते हुए कि यह बहुत अधिक प्रदर्शन हिट का कारण नहीं बनता है। इस तरह, आपको यह सुनिश्चित करने की ज़रूरत नहीं होगी कि कंटेनर को सही उपयोगकर्ता के रूप में चलाया जा रहा है। शाब्दिक uid/gid के बजाय तार्किक नामों का उपयोग करना भी संभव होना चाहिए।

@jsternberg यह एक जबरदस्त प्रदर्शन हिट है। vbox साझा किए गए फ़ोल्डरों का उपयोग करने के समान ही।

+1

स्थानीय विकास के उपयोग के मामलों के लिए, मुझे लगता है कि डॉकर को निश्चित रूप से इस सुविधा की आवश्यकता है। और ऐसे मामले में, मैं चाहता हूं कि यह सुविधा विंडोज और ओएसएक्स दोनों का समर्थन करे।

वैग्रांट मेजबान उपयोगकर्ता के यूआईडी/पीआईडी ​​​​को आवारा उपयोगकर्ता के लिए मैप करके इसका समर्थन करता प्रतीत होता है। लेकिन विकासशील उद्देश्य के लिए, मैं वास्तव में वैग्रांट के बजाय डॉकर का उपयोग करना चाहता हूं, क्योंकि यह वैग्रांट की तुलना में मल्टी-होस्ट एप्लिकेशन चलाने के लिए बहुत हल्का है।

कृपया मुझे बताएं कि मैं यहां क्या खो रहा हूं (मुझे गो के साथ कोई अनुभव नहीं है), लेकिन क्या गो माउंट() फ़ंक्शन झंडे स्वीकार नहीं करता है? क्या हम जैसे कमांड की अनुमति नहीं दे सकते
-v host/folder:container/folder -mount-as user:group
क्या आप लुकअप के साथ uid/gid प्राप्त नहीं कर सकते (https://golang.org/src/os/user/lookup_unix.go)
और फिर उन्हें (यूआईडी = 1, जीआईडी ​​= 1) को माउंट () में झंडे के रूप में पास करें? (https://golang.org/src/syscall/syscall_linux.go?s=19154:19249#L754)

@krisgraham बाइंड माउंट्स इस तरह से uid/gid सेट करने का समर्थन नहीं करते हैं।

साथ ही -v विकल्प को --mount-as विकल्प से अलग करने से कई -v विकल्प होने पर भ्रम पैदा होता है

इसके लिए एक अच्छा उपाय क्या है? मैं सक्रिय विकास के लिए डॉकर का उपयोग करना पसंद करूंगा, और किसी प्रकार का माउंटेड वॉल्यूम नहीं होना वास्तव में एक विकल्प नहीं है क्योंकि मुझे हर बार अपने कोड में बदलाव करने के लिए पुनर्निर्माण करना होगा।

सक्रिय विकास के लिए मैं डॉकर का उपयोग करने का कारण यह है कि यह मेरे उत्पादन वातावरण के अनुरूप है।

@berfarah मैं हर दिन सक्रिय विकास के लिए करता हूं।
शायद ही कभी ऐसा होता है जब मुझे परमिट के साथ खिलवाड़ करने की आवश्यकता होती है।
यदि आप OSX पर boot2docker का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपका काम करने वाला dir /Users के भीतर रहता है और आपको ठीक होना चाहिए।

@ cpuguy83 त्वरित उत्तर के लिए धन्यवाद। मुझे रेल पर्यावरण के साथ अनुमति समस्याएं आ रही हैं जहां लॉग नहीं लिखे जा सकते हैं, और कभी-कभी अनुमतियों के कारण विफलता के बिंदु होते हैं। यह मेरी सेवाओं के कारण फाइलों में से एक के लिए एक अलग यूआईडी है।

@berfarah मेरा वर्कअराउंड मेरे dockerfiles को लिखना है जैसे कि कंटेनर-उपयोगकर्ता/समूह जिनके पास कोड है, मेरे होस्ट उपयोगकर्ता के समान UID/GUID है। उदाहरण के लिए, चूंकि मेरा होस्ट उपयोगकर्ता यूआईडी 1000 है:

RUN \
    groupadd code_executor_group && \
    useradd code_executor_user -g code_executor_group -u 1000

@berfarah RAILS_ENV = विकास के लिए stdout/stderr जाने के लिए लॉग हैं?

@ cpuguy83 यह समस्या OSX को प्रभावित नहीं करती है; thaJeztah ने २४ जुलाई २०१४ को टिप्पणी की:

ओएस एक्स पर, वॉल्यूम पर 'स्वामित्व को अनदेखा' करने के लिए एक सुविधा मौजूद है। प्रभावी रूप से यह किसी भी उपयोगकर्ता को फाइलों / निर्देशिकाओं को देखने के लिए देगा जैसे कि वे मालिक थे।

@ncjones वास्तव में, OS X पर भी यही लागू होता है। मैं जिस "वॉल्यूम" के बारे में बात कर रहा था, वह OS X पर ही उपयोग किए जाने वाले हार्डडिस्क/पार्टीशन (वॉल्यूम) हैं। मुझे संदेह है कि Boot2Docker के साथ काम करने से फर्क पड़ता है, लेकिन मुझे यकीन नहीं है।

मेरी टिप्पणी यह ​​सूचित करने के लिए थी कि क्या लिनक्स में कुछ _similar_ संभव था (इस प्रकार Boot2Docker VM के अंदर)

वहां भ्रम के लिए खेद है।

@ryneeverett धन्यवाद, यह मददगार है। क्या आप तब अनुमतियों को क्रमशः 755 से 775 और क्रमशः 644 से 664 में संशोधित करते हैं, जहां आपको आवश्यकता होती है? संपादित करें: पठन कौशल!

@cpuguy83 धन्यवाद! यह @ryneeverett के समाधान की तुलना में अधिक सीमित फिक्स की तरह लगता है, क्योंकि यह काफी कुछ नहीं है जिसे मैं सभी परियोजनाओं के लिए आगे बढ़ा सकता हूं।

@berfarah खुशी है कि आपको यह मददगार लगा। हाँ, मैं सिर्फ यह सुनिश्चित करता हूँ कि मेरी होस्ट फ़ाइलों के पास सही अनुमतियाँ हों और डॉकर उन्हें वॉल्यूम में सुरक्षित रखता है।

+1

यह ऐसा कुछ है जो डोकर के माध्यम से साझा वॉल्यूम के लिए बेहद उपयोगी होगा, और मेरे पास एक सुरक्षा चिंता का समाधान है:

• साझा वॉल्यूम जहां कंटेनर यूआईडी और जीआईडी ​​गलती से होस्ट पर एक विशेषाधिकार प्राप्त गैर-रूट उपयोगकर्ता के लिए मैप करते हैं। (उदाहरण के लिए, होस्ट पर कंटेनर द्वारा बनाई गई फाइलें एक उपयोगकर्ता के लिए मैपिंग कर रही हैं जो पासवार्ड को सुडो कर सकती है, अन्यथा प्रतिबंधित सामग्री तक पहुंच सकती है, आदि)

इसे ठीक करना उद्यम के लोगों के लिए बहुत सुविधाजनक होगा जो एक टन कंटेनर w/अपाचे या कुछ मिडलवेयर चला रहे हैं और लॉगिंग वॉल्यूम और/या विभिन्न सामग्री/अपलोड निर्देशिका साझा कर रहे हैं। लिनक्स में एंड-यूज़र ऐप्स को कंटेनरीकृत करते समय मुझे व्यक्तिगत रूप से इन अनुमतियों के साथ कुछ सिरदर्द भी हुए हैं (जैसे सिंकॉम/स्पॉटिफाइ)। आज के कई कामकाज स्वयं समस्याग्रस्त हैं। आखिरकार, इसे डॉकर के अंदर तय किया जाना है। मैं विशेष रूप से एक एंट्रीपॉइंट के रूप में रूट शेल स्क्रिप्ट चलाने में सहज महसूस नहीं करता, खासकर जब यह समस्या इस बात पर प्रकाश डालती है कि कंटेनर में 0:0 uid/gid मेरे होस्ट पर रूट करने के लिए कैसे मैप करेगा। मुझे प्रारंभिक प्रस्ताव पसंद है "डॉकर रन -v /var/lib/docker:/var/lib/ docker:ro :$user:$group"।

@synccomm मैं बिल्कुल विपरीत दृष्टिकोण
डॉकर आपके डेटा के स्वामित्व के बारे में अनुमान नहीं लगा सकता है।

आप अपनी टिप्पणी के निचले भाग में जिस दृष्टिकोण पर प्रकाश डालते हैं, वह संभव होगा यदि हम इन वास्तविक फ़ाइलों को फ़्यूज़-आधारित fs पर स्वचालित रूप से मैप करें जहाँ हम uids/gids बदल सकते हैं ... और इससे एक महत्वपूर्ण प्रदर्शन प्रभाव पड़ेगा।

और जल्द ही कंटेनर में uid 0 होस्ट पर uid 0 नहीं होगा ... जो फ़ाइल के स्वामित्व को और भी पेचीदा बना देता है।

क्या यह #2259 का डुप्लीकेट है?

@ cpuguy83 प्रतिक्रिया के लिए धन्यवाद, हालांकि मुझे यकीन नहीं है कि सटीक विपरीत दृष्टिकोण से आपका क्या मतलब है। बादल तुम समझाओ? मैं इस बात से सहमत हूं कि डेटा के स्वामित्व को डॉकर द्वारा ग्रहण नहीं किया जाना चाहिए, लेकिन मेरा मानना ​​​​है कि कंटेनर से होस्ट करने के लिए लगातार मैपिंग प्रदान करना निश्चित रूप से डोकर उपभोक्ताओं के लिए इस डेटा को बहुत आसान बनाने का काम करता है।

मैं सहमत हूं, कि बाइंडफ्स वर्कअराउंड की तरह, इसे फ्यूज रैपर बनाने से कुछ गहरा ओवरहेड होगा। हालांकि, भारी दंड के बिना इस पहेली से बाहर निकलने का रास्ता निकालना होगा। अनिवार्य रूप से कंटेनर सही ढंग से व्यवहार कर रहा है (जैसे कि यह मेजबान से एक अलग अनूठी मशीन थी), और जब हम एक मेजबान की निर्देशिका को वॉल्यूम के रूप में माउंट करते हैं तो यह (सही ढंग से) POSIX फाइल सिस्टम, अनुमतियों और सभी को देख रहा है। दुर्भाग्य से, इससे दो "होस्ट" के बीच डेटा को लगातार तरीके से साझा करना वाकई मुश्किल हो जाता है। एनएफएस, सीआईएफ, आदि जैसी चीजें इसके लिए उपयोग की जाती हैं और यूआईडी और जीआईडी ​​मैपिंग का समर्थन करती हैं - मुझे लगता है कि समस्या को हल करने में यहां समानांतर हो सकता है। ईमानदारी से, मुझे यह पता लगाने के लिए रेपो में और अधिक खुदाई करने की आवश्यकता है कि यह कोड में कहां हो रहा है और इसे बेहतर ढंग से समझें।

स्वामित्व दर्ज करने के लिए आपने जिन परिवर्तनों का उल्लेख किया है, वे कब गिरेंगे? यूआईडी 0 कंटेनर और होस्ट के लिए समान नहीं होने से वास्तव में मुझे रूट शेल स्क्रिप्ट का प्रवेश बिंदु बनाने में बहुत अधिक सहज महसूस होगा। फिर यह एक env के रूप में सही uid/gid पास करने और कंटेनर लॉन्च पर एक एड्यूसर करने के सुझाए गए वर्कअराउंड को करने की बात है।

@synccomm दुर्भाग्य से, मेरा ज्ञान भी नहीं, उन्हें किसी अन्य प्रकार के फाइल सिस्टम में लपेटे बिना नहीं, जिसे uid/gid सेटिंग्स के साथ रखा जा सकता है।

अंतत: यह कुछ ऐसा दिखता है जिसके लिए यूआईडी और जीआईडी ​​के पूर्ण द्विदिश रीमैपिंग के लिए कर्नेल समर्थन की आवश्यकता होती है, और इसे प्रबंधित करना भी आसान नहीं लगता है।

गैर-प्रदर्शन-संवेदनशील परिदृश्यों के लिए शायद FUSE का उपयोग करके कुछ किया जा सकता है।

विकास के उपयोग के मामलों के लिए अभी भी +1, क्योंकि मैं अपने घर में रूट-स्वामित्व वाली फाइलों के साथ समाप्त होता हूं।

मेरे उपयोग के मामले के लिए यह पर्याप्त होगा यदि डॉकर केवल कस्टम यूआईडी/जीआईडी ​​​​और सेलिनक्स लेबल को होस्ट वॉल्यूम पर लागू कर सकता है, जब यह निर्देशिका को पहले से मौजूद होने पर अनुमति और लेबल को अकेला छोड़ देता है। वर्तमान में मैं वर्कअराउंड करता हूं कि वॉल्यूम अनुमति को ठीक करने के लिए रूट के रूप में चलने वाली छवि के लिए एक अलग प्रवेश बिंदु होने से।

@ibukanov यह uid/gid लागू नहीं कर सकता है, लेकिन selinux लेबल आ रहा है।

@ cpuguy83 होस्ट वॉल्यूम निर्देशिका बनाते समय कस्टम uid/gid लागू करने में असमर्थता का तकनीकी कारण क्या है?

@ibukanov उपरोक्त टिप्पणियां देखें।

@ cpuguy83 मैं सिर्फ टिप्पणियों से नहीं देखता कि मुद्दा क्या है। मेरे उपयोगकर्ता मामले के लिए मुझे यूआईडी/जीआईडी ​​के किसी भी रीमैपिंग की आवश्यकता नहीं है। वर्तमान में कंटेनर के अंदर रूट के रूप में चलते समय मैं chown uid:gid /host_volume && chmod 770 /host_volume कर सकता हूं। क्या अच्छा होगा यदि डॉकटर इसे अपने आप कर सकता है जब वह /host_volume के पीछे होस्ट पर निर्देशिका बनाता है। इस तरह मुझे कंटेनर में एक अतिरिक्त प्रवेश बिंदु प्रदान करने की हैक की आवश्यकता नहीं होगी, केवल उपरोक्त ऑपरेशन को कंटेनर रूट के रूप में करने के लिए और हमेशा गैर-रूट खाते का उपयोग करके कोड चला सकता है।

@ibukanov आह, यह एक अलग बात है।
डॉकर, काफी उद्देश्य से, होस्ट डायर में परिवर्तन नहीं करता है।
यदि हम # 9092 करते हैं, तो यदि डॉकर ने डीआईआर बनाया है, तो यह इसे एक सामान्य वॉल्यूम की तरह व्यवहार करेगा (यानी, कंटेनर में वॉल्यूम पथ पर सब कुछ होस्ट पर कॉपी करें और chmod/chown जैसा कि कंटेनर में था)।

@ cpuguy83 - ठीक है,

@ cpuguy83 ने लिखा:

और जल्द ही कंटेनर में uid 0 होस्ट पर uid 0 नहीं होगा ... जो फ़ाइल के स्वामित्व को और भी पेचीदा बना देता है।

क्या इसे ट्रैक करने के लिए कोई मौजूदा समस्या है? मैं एक खोजने में असमर्थ था।

धन्यवाद!

क्या इसे ट्रैक करने के लिए कोई मौजूदा समस्या है? मैं एक खोजने में असमर्थ था।

@dato "उपयोगकर्ता नाम स्थान" की तलाश करें; एक प्रारंभिक कार्यान्वयन यहां पाया जा सकता है: https://github.com/docker/docker/pull/12648 और यहां https://github.com/docker/docker/pull/11253

लेकिन इससे पहले की विभिन्न चर्चाएं/मुद्दे हैं :)

+1

बस इतना मुझे पता है कि मैं सभी की तरह एक ही नाव में हूँ:

मैं nginx छवि का उपयोग कर रहा हूं और स्थानीय विकास के लिए वॉल्यूम को /usr/shared/nginx/html पर बढ़ा रहा हूं। Nginx www-data रूप में चलता है, लेकिन वॉल्यूम 1000:staff रूप में आरोहित हो जाता है और इसलिए मुझे 403 forbidden ।

@MrMMorris मुझे नहीं लगता कि यह वही नाव है - यह समस्या तब होती है जब कंटेनर के भीतर बनाई गई फ़ाइलें (माउंटेड वॉल्यूम पर) सुडो एक्सेस के बिना कंटेनर के बाहर पढ़ने योग्य नहीं होती हैं। आपके www-डेटा उपयोगकर्ता को केवल माउंटेड फ़ाइलों तक पठन पहुंच की आवश्यकता है ताकि आप अपनी फ़ाइलों पर केवल chmod a+r सक्षम हो सकें।

@ncjones chmod/chown का कंटेनर में अनुमतियों पर कोई प्रभाव नहीं पड़ता है

मैं बहुत भ्रमित हूं क्योंकि मैं कसम खाता हूं कि यह मेरे उपयोग के दौरान कई बिंदुओं पर काम करता है ...

ठीक है यह शर्मनाक है ...

ऐसा लगता है कि या तो 1.3.0rc-1 (शायद नहीं) बनाने के लिए अपग्रेड करने के बाद या मेरे सभी कंटेनर/छवियों को हटाने और docker-compose up चलाने से सब कुछ ठीक हो गया है .... और नहीं 403 forbidden

मुझे पता था कि यह किसी भी तरह से पहले काम कर रहा था इसलिए मैंने ol' rm -rf * दृष्टिकोण अपनाया।

मुझे भी इस मुद्दे को किसी तरह हल करने की जरूरत है। मेरे पास एक डॉकटर छवि है जिसका उपयोग मैं कुछ भारी संकलन कार्य को निष्पादित करने के लिए करता हूं जिसे अलग किया जाना चाहिए। तो कंटेनर को ऊपर जाना चाहिए, कुछ बाहरी इनपुट प्राप्त करें, प्रक्रिया करें, फिर यह बायनेरिज़ (आउटपुट) का उत्पादन करेगा। उचित अनुमति प्रबंधन के बिना इसे काम करने की कोशिश करना एक दुःस्वप्न बन गया है। मेरी छवियां पोर्टेबल होनी चाहिए ताकि मैं मेजबान के बारे में ज्यादा अनुमान न लगा सकूं।

@alercunha आपके मामले में

@alercunha
हमने डॉकर कंटेनर द्वारा बिल्ड आउटपुट को चुनकर बिल्ड सेटिंग में इस समस्या के आसपास काम किया है। हमारे Dockerfile में कुछ ऐसा होगा:

env USER_ID 1000
env GROUP_ID 1000
cmd bash -lc '\
  build.sh && \
  chown -R $USER_ID:$GROUP_ID build \
'

डॉकर होस्ट के उपयोगकर्ता का वास्तविक यूआईडी/जीआईडी ​​​​चलाने पर कंटेनर को प्रदान किया जा सकता है। उदाहरण के लिए, जेनकींस बिल्ड कमांड कुछ इस तरह उपयोग करेगा:

docker run \
  -e USER_ID=`id -u` \
  -e GROUP_ID=`id -g` \
  -v $basedir:/workspace

@motin बिल्डिंग रूट के रूप में एक ऐसी चीज है

@ncjones धन्यवाद! यह वास्तव में एक अच्छा विचार है, मेरे विशेष मामले में समाधान के रूप में अच्छी तरह से काम कर सकता है।

@alercunha उस स्थिति में प्रत्येक तृतीय पक्ष प्रोजेक्ट के लिए अलग-अलग छवियों/कंटेनरों का उपयोग करने पर विचार करना उचित हो सकता है। इससे ओपन सोर्स समुदाय को भी बेहतर लाभ हो सकता है, उदाहरण के लिए यदि आपने उन तृतीय-पक्ष परियोजनाओं में से प्रत्येक के निर्माण के लिए आधिकारिक docker-images सबमिट किया है।

www-data को सभी विशेषाधिकार प्रदान करने के लिए आप इसका उपयोग कर सकते हैं:

RUN usermod -u 1000 www-data

माउंटेड वॉल्यूम पर डॉकटर में नौकरी चलाते समय एक समस्या का सामना करना पड़ा। परिणामी फाइलें रूट के स्वामित्व में थीं और डॉकर कमांड चलाने वाले उपयोगकर्ता द्वारा प्रबंधित नहीं की जा सकती थीं। अनुमतियों को ठीक करने के लिए कार्य के बाद निम्नलिखित को चलाना वर्तमान समाधान है।

docker run -t --rm \
    -v $PWD:/usr/src/app \
    -w /usr/src/app \
    debian:wheezy chown -R $(id -u):$(id -g) ./

क्या डॉकर फ़ाइल के USER कमांड में निर्दिष्ट उपयोगकर्ता के स्वामित्व के लिए होस्ट आधारित माउंटेड वॉल्यूम की अनुमति को बदलना संभव है? स्पष्ट रूप से अनुमतियों को विन्यास योग्य होना चाहिए लेकिन हमारे पास इसका डिफ़ॉल्ट व्यवहार हो सकता है।

@मिग-फॉक्सबैट
मेरे उद्देश्यों के लिए यह पर्याप्त होगा यदि डॉकर पहली बार होस्ट निर्देशिका बनाए जाने पर छवि में माउंट पॉइंट से होस्ट निर्देशिका पर स्वामित्व और अनुमति सेट करता है। यदि होस्ट निर्देशिका पहले से मौजूद है, तो डॉकर इसे अकेला छोड़ सकता है।

@ मिग-फॉक्सबैट और @ibukanov मेरे लिए अनिवार्य शर्त है, इस मुद्दे को खोलते समय, यह था कि मेजबान फाइल सिस्टम पर अनुमतियां नहीं बदली जाती हैं (जैसा कि कंटेनर मैपिंग में कुछ वर्चुअल है जो कोई _NFS_ के साथ कर सकता है)।

आप जो करने का प्रयास कर रहे हैं वह आज आपके कंटेनर में कुछ स्टार्टअप स्क्रिप्ट में _chown_ चलाकर आसानी से किया जा सकता है।

मुझे आने वाले वॉल्यूम प्लग-इन आर्किटेक्चर से प्यार है, लेकिन मैं इसके बजाय डॉकर टीम इस सुविधा को जोड़ना चाहूंगा। जब तक आप अपने कंटेनर में गैर-रूट उपयोगकर्ता के साथ वॉल्यूम का उपयोग नहीं करते हैं, तब तक डॉकर अच्छी तरह से काम करता है। फिर जब चीजें (जैसे, लॉगिंग) काम नहीं करती हैं तो आप या तो अपने लैपटॉप को स्टारबक्स विंडो के माध्यम से फेंक देते हैं या आपको ऊपर संदर्भित स्टैक ओवरफ्लो आइटम मिल जाता है।

+1 मैं चाहता हूं कि कंटेनर गैर-रूट उपयोगकर्ता के रूप में एप्लिकेशन चला रहे हों, जो इस मुद्दे के कारण जटिल हो जाता है।

LXC की id_map क्षमता का उपयोग करके इस सुविधा को लागू क्यों नहीं किया गया?

मैंने अभी देखा है कि "id_map" (उर्फ उपयोगकर्ता नामस्थान समर्थन) का उत्तर पहले से ही @thaJeztah द्वारा उल्लिखित है

जबकि अनुमतियों को सेट करने में थोड़ा अतिरिक्त काम लगता है, हम दर्जनों कंटेनरों को गैर-रूट के रूप में चला रहे हैं और अनुमति की समस्याओं से बच रहे हैं। हमारे अधिकांश डेटा कंटेनर कुछ इस तरह से शुरू होते हैं:
ENV CONTAINER_USER कौंसुल
ईएनवी CONTAINER_UID 312312
रन एड्यूसर -D $CONTAINER_USER -u $CONTAINER_UID
रन mkdir -p /var/consul/
सीएमडी ने $CONTAINER_USER चुना।$CONTAINER_USER /var/consul/

UID/useradd जानकारी सेट करने के मामले में वास्तविक रन कंटेनर समान होने के साथ। यह कुछ डुप्लिकेट काम है (डेटा कंटेनर और रन कंटेनर दोनों पर यूआईडी सेट करना है) हालांकि यह काफी मामूली है। डॉकर परिवर्तन अनुमतियाँ या मक्खी पर मानचित्र अनुमतियाँ होने से कुछ अच्छी जटिलताएँ आएंगी और उपयोगकर्ताओं को सुरक्षा के दृष्टिकोण से अधिक सावधान रहना होगा। मैं कमांड लाइन की जटिलता को कम करने में जो कुछ भी मदद करता हूं, उसके लिए भी हूं, इसलिए यदि सब कुछ dockerfile में स्वयं निहित है तो यह थोड़ा और सीधा है कि क्या हो रहा है।

अब एक कंटेनर में किसी प्रकार की मैपिंग के साथ होस्ट फ़ाइलों तक पहुंचने का प्रयास करने के ऊपर नोट है। मुझे लगता है कि यह निश्चित रूप से एक जोखिम भरा प्रस्ताव है। अक्सर सीधे होस्ट मैपिंग के बिना फ़ाइलों को साझा करने का प्रयास करना शायद सबसे अच्छा समाधान है, अन्यथा आप कुछ हद तक डॉकर सुरक्षा को बदल रहे हैं। कंटेनर की तुलना में कम अनुमति वाले कंटेनर के बजाय अन्यथा आप एक कंटेनर के बारे में बात कर रहे हैं जो गैर-रूट के रूप में चल रहा है जिसमें रूट स्तर तक पहुंच है (माना जाता है कि अक्सर केस का उपयोग होता है) फाइलों को होस्ट करने के लिए। समूह अनुमतियाँ या अन्य समाधान जो मुझे लगता है कि ज्यादातर स्थितियों में जीतना चाहिए।

मैंने इसके आसपास एक एंट्रीपॉइंट शेल स्क्रिप्ट के साथ काम किया, जो माउंटेड डायरेक्टरी को चोदता है और उपकमांड को सु के माध्यम से निष्पादित करता है।

सोलर कंटेनर में एक उदाहरण जहां होस्ट से वॉल्यूम के रूप में /data निर्देशिका आरोहित है:

#!/bin/bash

chown -R $SOLR_USER:$SOLR_USER /data

su -c "$@" -m $SOLR_USER

_उपयोगकर्ता मतदान_

_इस चर्चा में परिवर्तन होने पर सूचना प्राप्त करने का सबसे अच्छा तरीका ऊपर दाईं ओर सदस्यता लें बटन पर क्लिक करना है।_

नीचे सूचीबद्ध लोगों ने यादृच्छिक +1 के साथ आपकी सार्थक चर्चा की सराहना की है:

@jcercurati
@iangelov
@scue
@razvanphp
@भूत
@andrerocker
@anandnaly
@dopson
@पर है
@ हदीम
@iyn
@cgrantcharovtp
@sandytrinh
@gomex
@ डॉ बेंटन
@tehmaspc
@segphault
@avaz
@edavism
@ayeo
@stanislavb
@smebberson
@tony-kerz
@msierks
@pdonorio
@सैमसंग8610
@qm78
@joshughes
@roelvanduijnhoven
@व्लादिमिरब्राइट
@ava-dylang

इन थ्रेड्स पर कुछ भी कहना एक उपयोगकर्ता को स्वचालित रूप से सदस्यता देता है, इसलिए हाँ उन सभी लोगों को सदस्यता दी जाती है जब तक कि उन्होंने अतिरिक्त रूप से, जानबूझकर सदस्यता समाप्त नहीं की हो। (यह भी सुनिश्चित नहीं है कि _who_ आप your रूप में बात कर रहे हैं)

यह निश्चित रूप से जरूरी है। डॉकर को यूआईडी को ठीक से रीमैप करना चाहिए। अन्यथा कंटेनर से होस्ट OS वॉल्यूम के लिए बनाई गई हर चीज़ रूट के स्वामित्व में है। वर्कअराउंड भयानक है - कंटेनर के अंदर उपयोगकर्ताओं को बदलना जो सभी प्रकार की जटिलताओं की ओर जाता है, हर जगह चांस होने के कारण, डॉकरफाइल कुरूपता के साथ बढ़ता है। और सभी हार्डकोडिंग यूआईडी में से सबसे खराब कंटेनरों को गैर-पोर्टेबल बना देता है!

+1 इस सुविधा की अत्यधिक सराहना की जाएगी, क्योंकि मैं फाइलों पर उपयोगकर्ता आईडी को ओवरराइट करने से बचने के लिए, डॉकर कंटेनर और मेरे होस्ट सिस्टम के बीच स्विचिंग से बचना चाहता हूं।

यूआईडी अनुकूलन प्राप्त करना अभी संभव है, लेकिन निम्नलिखित बाधाओं के भीतर:

• कंटेनर को पर्यावरण चर के माध्यम से आवश्यक यूआईडी (ओं) को स्वीकार करने के द्वारा यूआईडी अनुकूलन संभव है। यह मेजबान को कंटेनर द्वारा उपयोग किए जाने वाले यूआईडी (ओं) पर पूर्ण नियंत्रण देता है, और इसका एक अतिरिक्त लाभ है: एक ही यूआईडी मान पर कई चर सेट किए जा सकते हैं। यूआईडी रीमैपिंग एकल होस्ट यूआईडी में एकाधिक कंटेनर यूआईडी मैपिंग का समर्थन करने में असमर्थ है, क्योंकि मैपिंग 1:1 होनी चाहिए। उदाहरण के लिए, यदि वांछित मैपिंग वास्तव में थी कि एप्लिकेशन को uid = 0 के रूप में चलाना चाहिए, तो आप चर के साथ इंजेक्शन लगाकर ऐसा कर सकते हैं, लेकिन uid रीमैपिंग के माध्यम से नहीं। ऊपर @ncjones और @mitchcapper समाधान देखें।
• रूट यूआईडी = 0 विशेष रूप से हालांकि रीमैपिंग को छोड़कर, एक अलग मूल्य में नहीं बदला जा सकता है: # 12648।

लगभग सभी आधुनिक वेब विकास ढांचे में एक लॉग फ़ोल्डर और एक कैश फ़ोल्डर होता है जो प्रोजेक्ट के अंदर होता है, जिसे प्रोजेक्ट कॉन्फ़िगरेशन में परिभाषित किया जाता है और माउंटेड वॉल्यूम के माध्यम से साझा किया जाता है। मैंने पहले vboxfs का उपयोग किया था लेकिन यह बहुत धीमा था। मुझे एनएफएस माउंट बनाने के लिए डॉकर-मशीन- एनएफएस मिला और यह तेज़ है, लेकिन अब कंटेनरों में मेरी वेब फाइलें 502: डायलआउट के स्वामित्व में हैं और इसे chmod या chown नहीं किया जा सकता है, इसलिए मेरा वेब ऐप नहीं चलेगा। मैंने डॉकर योनि बॉक्स की कोशिश की लेकिन इसे सभी अलग-अलग एनवी वर्र्स और कॉन्फ़िगरेशन के साथ योनि की आवश्यकता है, और अभी तक डॉकर-मशीन के साथ काम नहीं करता है। भले ही यह अल्पावधि के लिए मैन्युअल प्रक्रिया हो, क्या उपयोगकर्ता 502 को www-data या कुछ और जोड़ने के लिए कोई समाधान है? मुझे व्यवसाय में बस इतना ही चाहिए!

+1

इसका पालन करने वालों के लिए; वर्तमान में एक प्रयोगात्मक सुविधा के लिए एक पीआर है जो बाइंड-माउंटेड फ़ाइलों के स्वामित्व को बार-बार बदल देगा। हालांकि इसका उपयोग सावधानी से किया जाना चाहिए, क्योंकि यह सुविधा होस्ट पर फ़ाइलों को बदल देगी (जो कि सभी मामलों में आप जो चाहते हैं वह नहीं हो सकता है); देखें https://github.com/docker/docker/pull/14632 (और https://github.com/docker/docker/pull/16767)

+1

वैसे, मैंने ACL . का उपयोग करके इस समस्या को हल किया

@kvaps , विस्तृत करने की देखभाल?

@posita , मेरी शर्त है @kvaps पॉज़िक्स एसीएल के बारे में बात कर रहा है। अगर मैं सही हूं, तो यह ओपी अनुरोध जैसा नहीं है।

@posita , @denydias , लंबे उत्तर के लिए खेद है। हाँ, मैं इस बारे में बात कर रहा हूँ।
मेरे पास ओनक्लाउड, सांबा और मिनीडलना जैसे कई कंटेनर हैं। हर कोई अलग-अलग यूआईडी और जीआईडी ​​से काम करता है।
वे सभी एक ही फाइल के साथ काम करते हैं। हर कोई फाइलों को पढ़ और लिख सकता है, मैंने फाइल सिस्टम को होस्ट मशीन में acl विकल्प के साथ माउंट किया है, और इस फाइल के लिए सभी को uid और gid अधिकार दिए हैं, जैसे chown कमांड:

# give access for owncloud (apache uid 33):
setfacl -R -m "u:33:rwx" /data
# give access for samba (uid 1000):
setfacl -R -m "u:1000:rwx" /data
# give access for minidlna (uid 997):
setfacl -R -m "u:997:r-x" /data
# preserve this permissions for new files and folders:
setfacl -R -d -m "u:33:rwx" /data
setfacl -R -d -m "u:1000:rwx" /data
setfacl -R -d -m "u:997:r-x" /data

@kvaps , कमांड setfacl Dockerfile में काम नहीं करता है। उदाहरण:

FROM nginx

ADD data/conf /etc/nginx

RUN mkdir -p /etc/nginx/sites-enabled

VOLUME /etc/nginx

RUN setfacl -dR -m u:1000:rwx /etc/nginx && setfacl -R -m u:1000:rwx /etc/nginx

नतीजा:

root<strong i="12">@3975ac4fba98</strong>:/etc/nginx# getfacl sites-enabled/
# file: sites-enabled/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

होस्ट मशीन पर माउंट होने के बाद ही ACL काम करता है और setfacl चलाता है। डॉकर संस्करण:

Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

यह सही करना बहुत आसान है, और पेंच करना भी बहुत आसान है। तो इसे खराब मत करो!
ऐसा करने का सही तरीका है: पहली बार जब कंटेनर चलाया जाता है, तो मेजबान इंजेक्ट करता है कि कंटेनर को किस यूआईडी का उपयोग करना चाहिए (जैसा कि पहले ही ऊपर वर्णित है)।
ऐसा करने का सबसे खराब तरीका यह है: कंटेनर से मेजबान पर अपनी यूआईडी आवश्यकताओं को लागू करने की अपेक्षा करें। यह गलत है, गलत है, गलत है। उदाहरण के लिए, दो कंटेनरों पर विचार करें जो एक सामान्य माउंट साझा करते हैं: एक कंटेनर सेवा के लिए फाइलें लिखता है, और दूसरा कंटेनर फाइलों की सेवा के लिए httpd चलाता है। अब, यदि इन दोनों कंटेनरों में यूआईडी के लिए प्रतिस्पर्धी परिभाषाएं हैं, तो यह प्रणाली सबसे खराब स्थिति में टूट जाएगी, या सबसे अच्छी कमी होगी। सेट किए जा रहे ACL से होस्ट को कोई मतलब नहीं होगा, और वे संभवतः आवश्यकता से अधिक व्यापक होंगे, जिसका अर्थ है कि यह अब एक सुरक्षा समस्या है। कृपया ऐसा मत करो!! इसे सही तरीके से करें।

माना। यूआईडी के बीच मैपिंग को कंटेनर में छोड़ना एक अच्छा पर्याप्त समाधान है। बस चाहता था कि डॉकर उदाहरण के द्वारा आगे बढ़े, और आधिकारिक डॉकटर छवियों में ऐसे यूआईडी/जीआईडी ​​मैपिंग का समर्थन करता है।

chown बिना, रन टाइम पर हल किया गया।

मैंने @ncjones 'समाधान के करीब कुछ उपयोग किया है, लेकिन मैं chown फ़ाइलों को नहीं चाहता क्योंकि मैं नहीं चाहता कि उन्हें होस्ट पर संशोधित किया जाए। इसलिए मैंने कंटेनर स्टार्टअप पर यूआईडी को बदलना चुना।

मैं अपने Dockerfile में एक समर्पित उपयोगकर्ता बनाता हूं:

RUN adduser --no-create-home --disabled-login --gecos "" username --uid 1000

मैं अपने Dockerfile में स्टार्टअप स्क्रिप्ट को परिभाषित करता हूं:

CMD ["/run.sh"]

मेरे पास यह पंक्ति मेरी /run.sh स्क्रिप्ट में है:

usermod -u $USER_ID username

कंटेनर शुरू होने पर अब मैं USER_ID चुन सकता हूं:

docker run -e USER_ID=$(id -u)

नए dockerfile args का उपयोग करके इसे हल करने में कामयाब रहे। कंटेनर बनने के बाद इसे कुछ खास करने की आवश्यकता नहीं है, इसलिए मैंने सोचा कि मैं साझा करूंगा। (डॉकर 1.9 की आवश्यकता है)

डॉकरफाइल में:

# Setup User to match Host User, and give superuser permissions
ARG USER_ID=0
RUN useradd code_executor -u ${USER_ID} -g sudo
RUN echo 'code_executor ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
USER ${USER_ID} 

फिर निर्माण करने के लिए:

docker build --build-arg USER_ID=$(id -u)

बाकी सब कुछ सामान्य है :)

संपादित करें:
मैंने इस पोस्ट को गलत मुद्दे पर लिखा था (यह boot2docker से संबंधित एक और था)।
माफ़ करना।

@pa-de-solminihac usermod -u $USER_ID username username की उपयोगकर्ता आईडी को बदल देगा और username के HOME में फ़ाइलों के स्वामित्व परिवर्तन को ट्रिगर करेगा, लेकिन प्रत्येक फ़ाइल जो पहले स्वामित्व में थी username उसके घर के बाहर शायद अपठनीय/अलेखनीय हो जाएगा क्योंकि वे अब एक अलग उपयोगकर्ता से संबंधित हैं

@riquito मैं इसे Dockerfile में बनाए गए एक समर्पित उपयोगकर्ता के साथ उपयोग करता हूं:

adduser --no-create-home --disabled-login --gecos "" username --uid 1000

इसलिए पहले username स्वामित्व वाली कोई फ़ाइल नहीं है। तो मुझे लगता है कि कोई समस्या नहीं है;)

FYI करें, setfacl OS X पर वापस आने वाले संस्करणों पर _not_ काम करता है:

root<strong i="7">@0da3c867240d</strong>:~# setfacl --default --recursive --modify u:500:rwx --modify g:500:rwx /opt/test
setfacl: /opt/test: Operation not supported

(इस मामले में, /opt/test को OS X से Docker मशीन और Boot2Docker के माध्यम से होस्ट किया जाता है। boot2docker/boot2docker#581 भी देखें।)

@posita क्या आप अपनी boottodocker छवि को होस्ट करने के लिए वर्चुअलबॉक्स का उपयोग कर रहे हैं? यदि ऐसा है तो वास्तव में वर्चुअलबॉक्स साझा किए गए फ़ोल्डरों के साथ एक सीमा हो सकती है। वर्चुअल बॉक्स साझा फ़ोल्डर के बावजूद मुझे किसी भी प्रकार की नियमित पारगम्यता करने में बहुत परेशानी हुई है।

@ अवा-डिलैंग, यह एक अच्छी बात है। उपरोक्त डॉकर मशीन के माध्यम से समानताएं ड्राइवर के साथ है , जो समानताएं के मूल साझा फ़ोल्डर कार्यान्वयन का उपयोग करता है, जो समान रूप से सीमित प्रतीत होता है। (यह भी देखें https://github.com/docker/machine/issues/13#issuecomment-164320881 उन प्रकार के वातावरण के लिए एक प्रस्ताव के बारे में।)

FWIW, मुझे अपनी उपयोगिता, Scuba में फ़ाइल के स्वामित्व में समस्या हो रही थी।

मैंने एक "इनिट" स्क्रिप्ट जोड़कर इस मुद्दे के आसपास काम किया है जो एक ही यूआईडी/जीआईडी ​​​​के साथ कंटेनर में एक उपयोगकर्ता बनाता है जो मेजबान में लागू करने वाले उपयोगकर्ता के रूप में होता है। देखें जोनाथन रेनहार्ट/स्कूबा#11 और जोनाथन रेनहार्ट/स्कूबा#13।

अब कंटेनर में बनाई गई फ़ाइलें बिल्कुल वैसी ही दिखती हैं, जैसी वे होस्ट पर बनाई गई थीं.

_अपडेट करें:_ इससे समस्याएं पैदा हुईं (जोनाथन रेनहार्ट/स्कूबा#22)। इसके बजाय मैंने मेजबान उपयोगकर्ता के यूआईडी/जीआईडी ​​के आधार पर अपना खुद का /etc/passwd और दोस्तों को उत्पन्न करके इसे ठीक किया, और इसे कंटेनर में इंजेक्ट किया (देखें जोनाथन रेनहार्ट/स्कूबा#24)।

+1

जब होस्ट मल्टी-टेनेंट मोड में चलता है तो इसे अधिक रखरखाव योग्य और सुरक्षित बनाने के लिए।

जब आप होस्ट से लेकर कंटेनर तक वॉल्यूम के साथ संपूर्ण Wordpress को साझा करते हैं, तो मुझे ऐसे Wordpress इंस्टाल के साथ अनुमति समस्याएँ थीं।

मेरे स्टैक में, मेरे पास एक आधार छवि है, जो मेरे मूल संशोधनों के साथ एक डेबियन है और हर दूसरी छवि इस छवि से बनाई जाएगी।

मूल छवि में, मेरे पास यह हिस्सा है:

### Start of Nginx WEBSERVER setup
RUN mkdir -p /var/www
# Modify www-data user and set UID, GID to 500
# https://muffinresearch.co.uk/linux-changing-uids-and-gids-for-user/
RUN groupmod -g 500 www-data \
    && usermod -u 500 www-data \
    #&& `find / -user 33 -exec chown -h 500 {} \;` \
    #&& `find / -group 33 -exec chgrp -h 500 {} \;` \
    && usermod -g 500 www-data \
    && chown -R www-data:www-data /var/www \
    && chmod g+s /var/www
### End of Nginx WEBSERVER setup

www-data php या nginx इंस्टॉल द्वारा नहीं बनाया गया है। यह डेबियन और शायद अन्य डिस्ट्रोस में एक डिफ़ॉल्ट परिभाषित उपयोगकर्ता/समूह है। कुछ PHP, Nginx इंस्टाल इस उपयोगकर्ता को अपनी कॉन्फ़िग फ़ाइलों में उपयोग करने का सुझाव देते हैं।

यदि आपके होस्ट उपयोगकर्ता का UID/GID 500 है (सबसे डिफ़ॉल्ट linux पहले गैर-रूट उपयोगकर्ता का UID/GID 500 या 1000 है), तो इस स्क्रिप्ट से www-data उपयोगकर्ता के UID/GID को 33 से 500 में बदलें। इस तरह यदि आप होस्ट से कुछ भी साझा करते हैं, डॉकर उन फ़ाइलों और फ़ोल्डरों के बारे में सोचता है जो www-data उपयोगकर्ता के स्वामित्व में हैं!

आपकी PHP-FPM सेटिंग फाइलों में उपयोगकर्ता और समूह को www-data भी सेट करें।

अपने nginx Dockerfile में, आपको इसे भी सेट करना होगा:

# Allow Nginx to access /var/run/php-fpm/php-fpm.sock
RUN usermod -aG www-data nginx

इस तरह nginx उपयोगकर्ता www-data स्वामित्व वाली फ़ाइलों तक पहुंच सकता है (आप nginx के उपयोगकर्ता नाम को nginx कॉन्फ़िगरेशन फ़ाइलों में परिभाषित कर सकते हैं)।

इस हैक के बाद, मेरे वर्डप्रेस इंस्टाल में कोई अनुमति समस्या नहीं है! सभी फ़ाइलें होस्ट पर रहती हैं + Wordpress को अपडेट करना त्रुटिपूर्ण रूप से काम करता है!

@DJviolin मुझे यकीन नहीं है कि इस तरह का एक मुद्दा वर्डप्रेस ट्यूटोरियल के लिए उचित जगह है, और मैं यहां पर इसका विस्तार करने में संकोच करता हूं। हालाँकि, उन असहाय नौसिखियों के लिए जो किसी तरह इस पर ठोकर खा सकते हैं:

1. आपने जो पोस्ट किया है वह स्थापना के बारे में बहुत सी धारणाएं बनाता है - यानी यूआईडी/जीआईडी ​​​​मान, उपयोगकर्ता और समूह नाम इत्यादि। यह वितरण में बहुत पोर्टेबल नहीं है।
2. इससे भी महत्वपूर्ण बात यह है कि विश्व-लेखन योग्य (0777) आपके संपूर्ण वर्डप्रेस इंस्टॉलेशन तक पहुंच बेहद खतरनाक है, और स्पष्ट रूप से आधिकारिक WP दस्तावेज़ीकरण के खिलाफ अनुशंसित है। इसके अलावा, यह सब होस्ट से माउंट किए जाने के साथ, आपने इंटरनेट से मनमाने ढंग से अपलोड को _host_ फाइल सिस्टम पर लिखने की अनुमति दी है।

@jantman क्षमा करें, मेरा बुरा। ऐसा लगता है कि पहला हैक अनुमति के मुद्दों को भी हल करता है। किसी भी डिफ़ॉल्ट अनुमति को बदलने की कोई आवश्यकता नहीं है।

जाहिर है कि हर किसी को अपने मेजबान उपयोगकर्ता यूआईडी: जीआईडी ​​का पता लगाना होगा और इसके अनुसार कॉन्फ़िगरेशन बदलना होगा। साथ ही खोज में पहले से मौजूद या नए उपयोगकर्ता से जुड़ें। मेरा एक जीवित ढेर के लिए एक कामकाजी उदाहरण है।

जब तक डॉकर इस समस्या का समाधान नहीं देते, तब तक धारणाएं बनी रहेंगी।

मेरा समाधान @JonathonReinhart या @ pa-de-solminihac वाले जैसा ही है।

आप स्थानीय वॉल्यूम बनाकर ऐसा कर सकते हैं, यह सिर्फ मास्टर https://github.com/docker/docker/pull/20262 में उतरा है

इसे तय के रूप में बंद करना।

नमस्ते, मुझे अपने डॉकरीफाइल में वर्कअराउंड भी करना पड़ा:

...
COPY start.sh /root/start.sh
CMD /root/start.sh

और फिर start.sh . में

usermod -u $USER_ID www-data
exec php-fpm

चूंकि $USER_ID को पर्यावरण पैरामीटर के रूप में इंजेक्ट किया जा सकता है, इसलिए बिना किसी संशोधन के उस डॉकर छवि का उपयोग करना संभव है।

वैसे भी मुझे लगता है कि उस तरह की सामग्री के लिए कार्यक्षमता में और अधिक बनाया जाना चाहिए और मैं सोच रहा हूं कि @calavera द्वारा सुझाए गए स्थानीय संस्करणों का उपयोग कैसे करें, क्या कोई उदाहरण प्रदान कर सकता है?

@ keywan-ghadami मैं स्थानीय संस्करणों पर भी उलझन में था। समस्या यह है कि आपको पहले फाइल सिस्टम बनाना होगा (या tmpfs का उपयोग करें)। तो यह /var/lib/docker का उपयोग नहीं करता है। वास्तव में आप _any_ मौजूदा FS की उप-निर्देशिका का उपयोग नहीं कर सकते क्योंकि बाइंड माउंट uid विकल्प का समर्थन नहीं करते हैं। मुझे नहीं पता कि स्थानीय संस्करण किस लिए हैं; आप समान रूप से FS को स्वयं बना और माउंट कर सकते हैं और फिर एक सामान्य होस्ट वॉल्यूम ( -v my-created-fs:container-mount-point ) का उपयोग कर सकते हैं।

मुझे इस धागे में काफी देर हो चुकी है लेकिन क्या यह समस्या हल हो गई है? यहां संदर्भित सभी विभिन्न मुद्दों से यह 100% स्पष्ट नहीं है। ऐसा लगता है कि

मेरे लिए, हार्ड-कोडिंग यूआईडी और जीआईडी ​​वातावरण के बीच पोर्टेबिलिटी के लिए एक बुरा विचार है और जब भी मैं एक कंटेनर को बूट करता हूं या एक छवि बनाता हूं तो मुझे हर बार कमांड लाइन तर्क जोड़ने की आवश्यकता नहीं होती है, जब यह एक आसान विकल्प हो सकता है। डॉकरफाइल। क्या Dockerfile में या शायद docker-compose.yml के माध्यम से कोई आसान विकल्प नहीं हो सकता है जहाँ आप किसी प्रकार का "मेजबान uid फ्रॉम होस्ट" विकल्प निर्दिष्ट कर सकते हैं?

वहाँ पहले से ही एक अच्छा समाधान हो सकता है लेकिन मैं वास्तव में इसे दस्तावेज़ीकरण या इस धागे से नहीं समझ सकता।

धन्यवाद @alvinchevolleaux मैं पुष्टि कर सकता हूं कि हम सीआई में ऊपर पोस्ट किए गए समाधान का उपयोग https://github.com/dotnet/cli के लिए सफलतापूर्वक महीनों से कर रहे हैं।

इसकी अनुशंसा करें!

@brthor हाँ, मैं इसके साथ गया हूँ, मैंने अपने export USER_ID=$(id -u) जोड़ा है, इसलिए यह मेरे विभिन्न वातावरणों के लिए स्वचालित है। बहुत धन्यवाद।

जैसा कि ऊपर चर्चा की गई है, अपने होम फोल्डर से सामग्री को कंटेनर में साझा करते समय, उसी यूआईडी के साथ एक उपयोगकर्ता खाता जोड़ें जो आपका है। यदि आपका यूआईडी 1000 नहीं है, तो इसका सामना करने के लिए यहां एक ट्रिक दी गई है। मुझे लगता है कि प्रत्येक उपयोगकर्ता डॉकरफाइल से अपनी खुद की डॉकर छवि बनाता है।

आपके Dockerfile होना चाहिए:

RUN useradd --uid 1000 -m vagrant
USER vagrant

निरंतर 1000 को _git फ़िल्टर_ का उपयोग करके आपके वास्तविक UID के लिए प्रतिस्थापित किया जाता है। अपने होस्ट पर निम्नलिखित चलाएँ:

git config filter.uidfix.smudge "sed s/1000/$UID/g"
git config filter.uidfix.clean "sed s/$UID/1000/g"

अंत में, git फ़िल्टर लागू करने के लिए .gitattributes फ़ाइल जोड़ें:

Dockerfile filter=uidfix

यह आपके वास्तविक यूआईडी के साथ 1000 को बदलकर काम करता है जब आप डॉकरफाइल को _smudding_ फ़ाइल द्वारा चेकआउट करते हैं। जब आप प्रतिबद्ध होते हैं तो गिट _clean_ फ़ाइल ( 1000 वापस डाल देगा)। कंटेनर में चलने वाली कोई भी कमांड सही यूआईडी के साथ vagrant उपयोगकर्ता के रूप में चलती है।

इस टिकट को फिर से खोल दिया जाना चाहिए क्योंकि यहां दिए गए सभी समाधान केवल समाधान हैं
मुझे https://github.com/rocker-org/rocker/blob/master/rstudio/userconf.sh में एक अच्छा प्रलेखित और अधिक संपूर्ण समाधान मिला।
यह रनटाइम तर्कों का उपयोग करता है जो प्रीबिल्ड छवियों का उपयोग करना संभव बनाता है जो गिट फ़िल्टर के साथ संभव नहीं है

@calavera मैं आपका समाधान नहीं समझता।

जैसे

$ mkdir /tmp/test
$ sudo docker volume create --name=test -d local --opt type=nfs --opt device=/tmp/test:/data --opt o=notime,nosuid,uid=11459,git=11459
$ sudo docker run -t -i -v test:/tmp fedora bash -i
[.. $] touch /tmp/foo.txt
[.. $] exit
$ ls -la /tmp/test

जब मैं /tmp/test निर्देशिका में देखता हूं तो कोई फाइल नहीं होती है। ऐसा नहीं लगता कि /tmp/test फ़ोल्डर कंटेनर में भी आरोहित हो रहा है... बल्कि यह एक कंटेनर वॉल्यूम बना रहा है। जो वास्तव में मैं चाहता हूं वह नहीं है।

मुझे कोई दस्तावेज नहीं मिल रहा है जो मुझे बताता है कि वैध --opt विकल्प क्या हैं। तो मैं वास्तव में अनुमान लगा रहा हूं कि यह कैसे काम करता है।

कृपया इस मुद्दे को फिर से खोलें। नया स्थानीय ड्राइवर चयनित उपयोगकर्ता आईडी के साथ स्थानीय होस्ट निर्देशिकाओं को माउंट करने के मुद्दे को बिल्कुल भी संबोधित नहीं करता है।

@calavera
क्या आप कृपया टिप्पणी कर सकते हैं कि हम स्थानीय होस्ट वॉल्यूम के साथ रूट के रूप में छोड़ी जा रही फ़ाइलों के मुद्दे को कैसे हल कर सकते हैं? मैं इस मुद्दे को अक्सर फसल देख रहा हूं, खासकर सीआई परिदृश्यों के लिए डॉकर का उपयोग करते समय।

लिंक किए गए पीआर को देखते हुए मुझे तुरंत कुछ भी स्पष्ट नहीं दिख रहा है, लेकिन मुझे यकीन है कि मुझे कुछ याद आ रहा है

मैं अपने कंटेनरों में इस वर्कअराउंड की विविधताओं का उपयोग कर रहा हूं, जैसे कि docbill/docker-force । हालांकि, यह मेरे लिए होता है एक क्लीनर समाधान एक कंटेनर है जो केवल स्क्वैशरूट करने के लिए ज़िम्मेदार है ...

स्थानीय के लिए bindfs जैसी किसी चीज़ का उपयोग करने से मदद मिलनी चाहिए। आप इसे -o map=$(id -u)/root:@$(id -g)/ @root (कोई उपयोगकर्ता नाम स्थान नहीं मानते हुए) के साथ चला सकते हैं और आपको फ़ाइलों को कंटेनर के बाहर अपने रूप में देखना चाहिए, जबकि वे स्वामित्व में हैं इसके अंदर जड़।

@ktosiek धन्यवाद, ऐसा लगता है कि इसमें क्षमता है। क्या आप एक पूर्ण उदाहरण docker run कमांड या कंसोल सत्र पोस्ट कर सकते हैं?

क्या कोई कृपया इस मुद्दे पर एक स्थिति अद्यतन पोस्ट कर सकता है: क्या इसे "ठीक नहीं होगा" के रूप में बंद कर दिया गया था या इसे वास्तव में लागू किया गया है? धागा काफी लंबा है, इसलिए कृपया मुझे क्षमा करें क्योंकि एक नज़र से नहीं देख सकता कि संकल्प क्या है।

@quinncomendant देखें https://github.com/docker/docker/issues/7198#issuecomment -191990887
काम नहीं करने पर रिपोर्ट करें।

धन्यवाद @LK4D4।

संक्षेप में, समस्या को एक सुधार के साथ बंद कर दिया गया था जो local वॉल्यूम ड्राइवर के लिए माउंट ऑप्ट की अनुमति देता है।

जहां तक ​​​​मैं बता सकता हूं, उपयोगकर्ता को सेट करने के लिए कोई विकल्प नहीं हैं समूह वॉल्यूम_ के रूप में आरोहित है (कृपया मुझे सही करें यदि वह विकल्प मौजूद है-यही वह है जो मैं यहां सीखने आया था)।

@quinncomendant सही; जब एक होस्ट-डायरेक्टरी को बाइंड-माउंट करते हैं तो आप चाहते हैं कि कंटेनर उन फाइलों का उपयोग करे जो जैसी हैं, जिसमें अनुमतियां शामिल हैं। यदि आप उन अनुमतियों को बदलना चाहते हैं, तो आपको उन्हें बाइंड-माउंट करने से पहले होस्ट पर ऐसा करना होगा

@quinncomendant या सरल शब्दों में यह ठीक नहीं होगा.... चूंकि
प्रदान किया गया समाधान वास्तव में समस्या के समाधान के लिए कुछ नहीं करता है
रिपोर्ट की गई है, न ही उस मुद्दे को हल करने की कोई योजना है।

६ जुलाई २०१६ को १७:२० बजे, सेबस्टियन वैन स्टिजन नोटिफिकेशन @github.com
लिखा था:

@quinncomendant https://github.com/quinncomendant सही; कब
एक होस्ट-निर्देशिका को बाइंड-माउंट करना आप चाहते हैं कि कंटेनर उन फ़ाइलों का उपयोग करे जो
जैसे हैं, वैसे ही हैं, जिसमें अनुमतियां शामिल हैं। यदि आप उन्हें बदलना चाहते हैं
अनुमतियाँ, आपको उन्हें बाइंड-माउंट करने से पहले, होस्ट पर ऐसा करने की आवश्यकता है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/7198#issuecomment -230909967, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe/ADBcWLihVjI1FoSMLKu7DyhwFOpGX0KKks5qTBwMgaJpZM4CQMjR
.

यह एक WON'T FIX समस्या प्रतीत होती है। ऐसा हमेशा लगता है कि कंटेनरीकरण के _विकास_ पहलुओं की अनदेखी की जा रही है और अभी भी हमें हैक्स लिखने की आवश्यकता है।

मैं विशेष रूप से इस मुद्दे पर आया क्योंकि जिन डेवलपर्स का मैं समर्थन कर रहा हूं, वे एक कंटेनर के अंदर और बाहर से होस्ट माउंटेड वॉल्यूम के लिए प्रोजेक्ट फाइल जनरेटिंग कमांड चला रहे हैं (होस्ट पर इन टूल्स को इंस्टॉल करने से कंटेनर का उपयोग करने का उद्देश्य पूरी तरह से विफल हो जाता है, है ना?)

वे इन फ़ाइलों पर जल्दी से पुनरावृति करना चाहते हैं, फिर भी जैसा कि इस धागे में अन्य लोगों ने बताया है कि वे कंटेनर के रूप में चल रहे यूआईडी / जीआईडी ​​​​के रूप में लिखे जाते हैं, जिसके लिए उन्हें आगे हेरफेर करने के लिए मेजबान पर सही ढंग से चोदने की आवश्यकता होती है (एक द्वारा) उदाहरण के लिए आईडीई)।

इस प्रकार के मामलों में अस्थायी यूआईडी/जीआईडी ​​में शिम करने के लिए वास्तव में एक _docker विशिष्ट_ तरीका होना चाहिए।

@boj यह सटीक परिदृश्य है जिसे मैंने स्कूबा विकसित करते समय चलाया था। मेरा वर्तमान समाधान, स्टार्टअप के दौरान, कंटेनर में एक उपयोगकर्ता को होस्ट उपयोगकर्ता के समान uid/gid के साथ बनाता है। यह सबसे आसान समाधान नहीं है, लेकिन यह अच्छी तरह से काम करता है।

@JonathonReinhart धन्यवाद, आपने मुझे थोड़ी प्रेरणा दी।

मैंने इस तरह मेजबान से बुलाए गए एक स्क्रिप्ट रैपर को लिखना समाप्त कर दिया (वे इस मामले में django का उपयोग करते हैं):

# bin/manage.py
#!/bin/sh

docker run -v $(pwd):/usr/local/prj -it --entrypoint="/usr/bin/python3.4" -w /usr/local/prj -u $(id -u):$(id -g) prj src/prj/manage.py $@

@boj उस समाधान ( -u $(id -u):$(id -g) ) के साथ संभावित समस्या यह है कि कंटेनर में उस uid/gid के लिए /etc/passwd या /etc/group में कोई प्रविष्टि नहीं है: https://github .com/JonathonReinhart/scuba/issues/11

@JonathonReinhart ने नोट किया। इस विशेष मामले में मुझे केवल डेवलपर के होस्ट को लिखी गई फाइलों की परवाह है और उनके पास होस्ट उपयोगकर्ता के समान अनुमतियां हैं।

रनटाइम पर वास्तव में क्या होता है, इसके बारे में कोई चिंता नहीं है, मुझे वास्तव में यही चाहिए था।

@JonathonReinhart

यदि कंटेनर में सॉफ़्टवेयर को /etc/passwd या /etc/group में एक प्रविष्टि की आवश्यकता है, तो उन्हें छवि में विश्व-लेखन योग्य बनाएं और फिर स्टार्टअप पर आवश्यक प्रविष्टियां जोड़ें।

तो @JonathonReinhart (uid/gid मैपिंग) द्वारा उल्लिखित समाधान इसे हल करता है।

ऐसा लगता है कि यह पहले से ही रनक (https://github.com/opencontainers/runc/blob/8c9db3a7a5145f6b26c8051af319eee6f72c9ca8/libcontainer/configs/config.go#L19-24) में समर्थित है। डॉकर में डीमन के लिए userns-remap कॉन्फ़िगरेशन है, यहां हमें मूल रूप से इसे और अधिक बढ़िया (डीमन स्तर के बजाय कंटेनर स्तर) की आवश्यकता होगी, क्या इसका समर्थन करने के लिए कोई रुचि/योजना है?

यह docker-compose.yml काम नहीं करता है:

version: '2'

services:
  app:
    build: ./app
    container_name: myapp
    volumes:
      #- "../app:/root/www/myapp:rw"
      - myapp:/root/www/myapp:rw

volumes:
  myapp:
    driver: local
    driver_opts:
      o: uid=500
      device: ../app

कोई मुझे बता सकता है क्यों? मैं आधिकारिक दिशानिर्देशों का पालन करता हूं: https://docs.docker.com/engine/reference/commandline/volume_create/#/driver -specific-options

क्या होस्ट से नामित वॉल्यूम संलग्न करना संभव है? driver_opts आप uid (और शायद gid ?) को परिभाषित कर सकते हैं।

+1

+1

@lazyuser @xiaods कृपया +1 के साथ रुकें । यह उन सभी ---> प्रतिभागियों को स्पैम करने के अलावा कुछ नहीं करता है।

@bamarni हां, मुझे लगता है कि नई उपयोगकर्ता-नामस्थान सुविधा इसे हल कर सकती है, लेकिन जैसा कि आपने कहा था, इसे प्रति कंटेनर लागू करने की आवश्यकता होगी। अंतिम परिणाम यह होगा: एक कंटेनर चल रहा है जैसा कि वह सोचता है कि "रूट" है, लेकिन वास्तव में यूआईडी/जीआईडी docker run कमांड लाइन पर पारित किया गया है। तब उपयुक्त उपयोगकर्ता के स्वामित्व वाले कंटेनर से फ़ाइलें "बाहर" आएंगी।

@lazyuser @xiaods @JonathonReinhart आपको समस्या विवरण के तहत +1 बटन पर क्लिक करना चाहिए

या यदि आप केवल सूचनाएं चाहते हैं तो दाईं ओर सदस्यता लें पर क्लिक करें...

@JonathonReinhart : निश्चित रूप से, मैं फिर से डॉक्टर के माध्यम से चला गया हूं, लेकिन दुर्भाग्य से प्रति-कंटेनर के बजाय मैपिंग डेमॉन-वाइड एक सीमा के कारण एक सचेत निर्णय था:

नोट: एकल मैपिंग प्रति-डेमॉन प्रतिबंध अभी के लिए लागू है क्योंकि डॉकर अपने स्थानीय कैश से छवि परतों को इंजन इंस्टेंस पर चलने वाले सभी कंटेनरों में साझा करता है। चूंकि फ़ाइल का स्वामित्व समान परत सामग्री साझा करने वाले सभी कंटेनरों के लिए समान होना चाहिए, इसलिए निर्णय लिया गया कि फ़ाइल स्वामित्व को डॉकटर पुल पर डेमन के उपयोगकर्ता और समूह मैपिंग में मैप किया जाए ताकि सामग्री डाउनलोड होने के बाद कंटेनर चलाने में कोई देरी न हो। यह डिज़ाइन डॉकर पुल, डॉकर पुश और कंटेनर स्टार्टअप के लिए उसी प्रदर्शन को बरकरार रखता है जैसा कि उपयोगकर्ता उपयोगकर्ता नामस्थान अक्षम होने की अपेक्षा करते हैं।

_(https://docs.docker.com/engine/reference/commandline/dockerd/#/daemon-user-namespace-options)_

प्रिय @JonathonReinhart , @pa-de-solminihac और @nalipaz ,
मुझे और दूसरों को इस मुद्दे से असंबंधित टिप्पणी न छोड़ने के लिए शिक्षित करने के आपके प्रयास के लिए धन्यवाद! FYI करें, Github कम से कम उन पर टिप्पणी किए बिना उन मुद्दों की खोज करने की अनुमति नहीं देता है जिनकी सदस्यता ली गई है। अधिक जानकारी के लिए https://github.com/isaacs/github/issues/283 देखें। विडंबना यह है कि जीथब का मुद्दा डॉकर की उम्र के लगभग समान है, और दोनों को समान रूप से प्राथमिकता दी जाती है।

सभी के लिए, स्पैमिंग के लिए खेद है। पहली बार यह उपरोक्त जीथब बग के लिए एक समाधान था, और इस बार मैं स्थिति की विडंबना देने का विरोध नहीं कर सका।

मैंने इसे inotifywait का उपयोग करके हल किया। आपको इसे अपनी डॉकटर छवि के अंदर चलाने के लिए inotify-tools स्थापित करने की आवश्यकता होगी। इसके बजाय इसे आपके होस्ट सिस्टम पर चलाना संभव है, लेकिन मुझे एक पोर्टेबल समाधान चाहिए था।

RUN export DEBIAN_FRONTEND=noninteractive \
  && apt -y update \
  && apt -y install inotify-tools \
  && inotifywait -m -r /mount -e create --format '%w%f' \
    | while read f; do chown $(stat -c '%u' /mount):$(stat -c '%g' /mount) $f; done

यह निर्देशिका / माउंट में बनाई गई किसी भी नई फ़ाइल या निर्देशिका को देखने के लिए inotifywait को निर्देश देकर काम करता है। जब यह एक को नोटिस करता है, तो यह स्वामित्व को उसी उपयोगकर्ता और समूह में / माउंट फ़ोल्डर के रूप में बदल देता है। मेजबान उपयोगकर्ता/समूह कंटेनर में मौजूद नहीं है, तो मैंने दोनों के पूर्णांक प्रतिनिधित्व का उपयोग किया। कंटेनर के अंदर इससे कोई फर्क नहीं पड़ता कि इसका मालिक कौन है, क्योंकि सब कुछ रूट के रूप में चलता है। कंटेनर के बाहर, होस्ट फाइल सिस्टम उसी स्वामित्व को दिखाता है जैसा कि किसी भी निर्देशिका को माउंट किया गया था।

मैंने जानबूझकर इसे केवल नई बनाई गई फ़ाइलों और निर्देशिकाओं के स्वामित्व को निर्धारित करने के लिए डिज़ाइन किया है, ताकि पहले से मौजूद फ़ाइलों और निर्देशिकाओं के स्वामित्व को संरक्षित किया जा सके। यह हर बार फाइल सिस्टम के माउंट होने पर chown -R स्टेटमेंट के साथ सभी को उड़ाने से ज्यादा सुरक्षित है। यदि आपकी परियोजना के लिए समान अनुमतियाँ काम करती हैं और आप एक सरल समाधान चाहते हैं जो अधिक कुशलता से चलता है, तो inotify-hookable देखें ।

चेतावनी: चूंकि प्रति उपनिर्देशिका में एक इनोटिफाई घड़ी स्थापित की जाएगी, इसलिए यह संभव है कि प्रति उपयोगकर्ता इनोटिफाई घड़ियों की अधिकतम मात्रा तक पहुंच जाए। डिफ़ॉल्ट अधिकतम ८१९२ है; इसे /proc/sys/fs/inotify/max_user_watches पर लिखकर बढ़ाया जा सकता है।

@ codekitchen-ws एक और चेतावनी: निर्माण के बाद और मालिक बदलने से पहले एक फ़ाइल को स्थानांतरित किया जा सकता है। शेल के आधार पर आप "$f" (पथ में शब्द-विभाजन को रोकने के लिए) उद्धृत करना चाहेंगे।

+1

@briansrepo यह एक दिलचस्प तरीका है। यदि यह Dockerfile RUN स्टेटमेंट में है, जो बिल्ड समय पर निष्पादित होता है। निष्पादन समय पर यह docker run उपयोगकर्ता को कैसे जान सकता है?

@btiernay धन्यवाद! यह उस उपयोगकर्ता के यूआईडी का उपयोग नहीं करता है जिसने छवि को सक्रिय किया है। यह विशेष रूप से होस्ट उपयोगकर्ता और होस्ट समूह की प्रतिलिपि बनाता है जो भी होस्ट निर्देशिका/माउंट पर आरोहित है। यह किसी अन्य फाइल या उपनिर्देशिका को नहीं देखता है। यह सुनिश्चित करने के लिए उपयोगकर्ता पर निर्भर है कि अनुमतियाँ उस चीज़ पर सेट हैं जिसे वे होस्ट सिस्टम पर लिख सकते हैं।

उदाहरण: मान लें कि होस्ट निर्देशिका /var/www/html का स्वामित्व ब्रायन:www-डेटा के पास है। आप एक छवि लॉन्च करते हैं जो छवि निर्देशिका / माउंट पर होस्ट सिस्टम निर्देशिका /var/www/html को माउंट करता है। फिर आप इमेज के अंदर से /mount/index.html बनाते हैं। यदि आप मेजबान सिस्टम पर /var/www/html/index.html के स्वामित्व की जांच करते हैं तो यह ब्रायन: www-डेटा के स्वामित्व में होगा

उस उदाहरण के आधार पर, मान लें कि आपके पास www-data:www-data के स्वामित्व वाली एक होस्ट निर्देशिका /var/www/html/upload है ब्रायन के स्वामित्व में है ब्रायन: www-डेटा , नहीं www- डेटा: www-डेटा , क्योंकि घुड़सवार मेजबान निर्देशिका / var / www / html है ब्रायन के स्वामित्व में

टीएल; डीआर: आप उपयोगकर्ता को पास करते हैं उपयोगकर्ता: समूह में उपयोग करके उपयोग करना चाहते हैं

@briansrepo स्पष्टीकरण के लिए धन्यवाद। यह सब समझ में आता है लेकिन फिर भी यह समझ में नहीं आता कि यह RUN अंदर कैसे काम कर सकता है। मुझे लगता है कि कंटेनर निष्पादित होने पर इसे पृष्ठभूमि में निष्पादित करने की आवश्यकता होगी (यानी docker run )।

@btiernay मुझे यह विचार भी पसंद है।
@briansrepo कम से कम यह कवर करता है कि कंटेनरों से क्या होता है।
निर्माण प्रक्रिया को अभी भी कुछ इस तरह से संबोधित किया जा सकता है

RUN usermod -u 1000 www-data

हालांकि ये अभी भी वर्कअराउंड हैं।

मेरे LEMP स्टैक में मेरे पास मेरे आधार Dockerfile में यह Nginx पूर्व-कॉन्फ़िगरेशन है:

### Start of Nginx WEBSERVER setup
RUN mkdir -p /var/www
# Modify www-data user and set UID, GID to 500
# https://muffinresearch.co.uk/linux-changing-uids-and-gids-for-user/
RUN groupmod -g 500 www-data \
    && usermod -u 500 www-data \
    && usermod -g 500 www-data \
    && chown -R www-data:www-data /var/www \
    && chmod g+s /var/www
### End of Nginx WEBSERVER setup

यह एक हैक है जहां होस्ट एसएसएच सत्र से प्रत्येक नई बनाई गई फाइलें यूआईडी, 500 की जीआईडी ​​​​और nginx प्राप्त करने के बाद अंततः उन फाइलों तक पहुंच नहीं पाएंगी (क्योंकि 500 ​​की आईडी वाला उपयोगकर्ता या समूह कंटेनर में मौजूद नहीं था)। जब आप ssh सत्र से होस्ट पर साझा वॉल्यूम में नई फ़ाइलों की प्रतिलिपि बनाते हैं और बाद में आप इस कंटेनर में docker exec प्रतिलिपि बनाते हैं, तो आप अपने www-data उपयोगकर्ता के लिए कौन सा uid, gid नंबर बनाना चाहते हैं, इसकी जांच कर सकते हैं और फाइलों को देखकर यूआईडी, जीआईडी।

मुझे जो समस्या मिली, अगर मैंने होस्ट मशीन पर साझा फ़ोल्डर में नई फ़ाइलों की प्रतिलिपि बनाई (जिसे आपने ssh सत्र द्वारा एक्सेस किया, जैसे DigitalOcean पर CoreOS उदाहरण में), Nginx की उन नई बनाई गई फ़ाइलों तक पहुंच नहीं है। इसलिए यदि आप विशेषाधिकारों के साथ पूर्ण संगतता चाहते हैं, तो आपको कंटेनरों के निर्माण पर अपनी वेबसर्वर फ़ाइलों को डॉकर कंटेनर में साझा करना होगा (कम से कम 1 साल पहले यह मामला था, जब मैं इन यूआईडी में चला, साझा संस्करणों के साथ जीआईडी ​​मुद्दे) .

या आप डॉकर कंटेनर में एसएसएच सेवा भी स्थापित कर सकते हैं जो फाइलों को nginx कंटेनर में साझा करता है, इस तरह यदि आप फाइलों को कॉपी/संशोधित करते हैं तो उन्हें सही यूआईडी, जीआईडी ​​​​मिलती है। लेकिन यह डॉकर सर्वोत्तम प्रथाओं के खिलाफ है कि आपको एसएसएच सत्रों के बजाय docker inspect उपयोग करना चाहिए, क्योंकि "डॉकर वीएम नहीं है" (यह बहुत आसान समाधान होगा, है ना?)

मेरी सोच में, एक डॉकर कंटेनर को एक सेवा या निष्पादन योग्य के रूप में कार्य करना चाहिए और अगर मैं नहीं चाहता तो मेरी वेबसर्वर फ़ाइलों को बंधक नहीं बनाना चाहिए। डेटाबेस एक अलग तरह की चीज है (कभी-कभी), लेकिन मुझे नहीं लगता कि एक ही पवित्र ग्रिल कंटेनर इंफ्रास्ट्रक्चर हासिल करना क्यों संभव नहीं होगा, जहां आपके सभी स्थिर, वेबसर्वर, कंटेनर के बाहर रहने वाली डेटाबेस फाइलें (लेकिन कंटेनर कर सकते हैं उन्हें संशोधित करें (जैसे हटाएं, बनाएं, संशोधित करें) और आप उन्हें होस्ट से बिना किसी विशेष समस्या के संशोधित भी कर सकते हैं।

docker volume create --opt आप uid, gid को परिभाषित कर सकते हैं, लेकिन यह docker-compose लिए सही नहीं है: https://github.com/docker/compose/issues/3715

यूआईडी/जीआईडी ​​​​मैप करने के लिए हमें वास्तव में एक क्रॉस-प्लेटफ़ॉर्म गो-टू (गोसु नहीं) समाधान की आवश्यकता है। नौसिखियों द्वारा डॉकटर को कैसे माना जाता है, इस समस्या से अकेले ही भारी नुकसान होता है।

हमने इस समस्या के लिए एक वर्कअराउंड बनाया है जो एक डॉकर कंटेनर के उपयोगकर्ता/समूह और फ़ाइल अनुमतियों को बदलता है जो कि यूआईडी/जीआईडी ​​​​के निर्माण के समय सेट किए गए थे जो कंटेनर को रनटाइम पर शुरू किया गया था।

परियोजना और स्थापना निर्देश यहां हैं: https://github.com/boxboat/fixuid

उदाहरण: डॉकर कंटेनर उपयोगकर्ता/समूह dockeruser:dockergroup UID/GID 1000:1000 । होस्ट यूआईडी/जीआईडी 1001:1002 रूप में चल रहा है। छवि docker run -u 1001:1002 साथ चलती है। fixuid होगा:

• dockeruser यूआईडी को 1001 में बदलें
• dockergroup GID को 1002 . में बदलें
• पुराने dockeruser:dockergroup लिए सभी फ़ाइल अनुमतियों को 1001:1002 में बदलें
• कंटेनर के अंदर $HOME को dockeruser $HOME . में अपडेट करें
• अब कंटेनर और होस्ट UID/GID मैच और होस्ट माउंट पर कंटेनर में बनाई गई फ़ाइलें मेल खाएँगी

यह ENTRYPOINT रूप में या स्टार्टअप स्क्रिप्ट के भाग के रूप में चल सकता है। यह कंटेनर में सेटुइड बिट के साथ root स्वामित्व वाले बाइनरी के रूप में स्थापित है, और उपयुक्त परिवर्तन करने के लिए विशेषाधिकारों को बढ़ाता है । इसका उपयोग केवल विकास कंटेनरों में किया जाना चाहिए।

यदि यह उपयोगी साबित होता है, तो डॉकर इंजन docker run में झंडे के माध्यम से कुछ या सभी तर्कों को शामिल करने में सक्षम हो सकता है।

docker volume का उपयोग करके हल किया गया।

@हशर कैसे? क्या आप एक उदाहरण दे सकते हैं pls

तो क्या gosu और एक एंट्रीपॉइंट स्क्रिप्ट का उपयोग करने के अलावा इसका कोई समाधान नहीं है ?!

अभी के लिए, ऐसा लगता है कि इसके लिए वर्कअराउंड के रूप में 2 विकल्प हैं, जब तक कि डॉकर टीम इस बारे में आधिकारिक अपडेट नहीं करती।

• https://github.com/mhart/alpine-node/issues/48#issuecomment -430902787
• बॉक्सबोट/फिक्स्यूइड

इतनी शर्म की बात है कि यह अभी भी एक मुद्दा है। सिद्धांत रूप में उपयोगकर्ता-रीमैप है लेकिन यह उपयोगकर्ता के अनुकूल नहीं है।