अगर हम इसके लिए जाते हैं, तो मैं इसके बजाय RUNP विकल्प के पक्ष में हूं
सभी कंटेनर -विशेषाधिकार मोड में चल रहे हैं।

बुधवार को, सितंबर 18, 2013 अपराह्न 1:07, बेंजामिन पॉड्सज़ुन
नोटिफिकेशन@github.comलिखा :

वर्तमान में ऐसा लगता है कि के बाहर विशेषाधिकार प्राप्त संचालन चलाने का कोई तरीका नहीं है
डॉकर रन-विशेषाधिकार प्राप्त।

इसका मतलब है कि मैं एक ही काम Dockerfile में नहीं कर सकता। मेरा हाल
मुद्दा: मैं एक कंटेनर के अंदर फ्यूज (एनसीएफ के लिए) चलाना चाहता हूं। स्थापित कर रहा है
फ्यूज पहले से ही हैक्स और बदसूरत वर्कअराउंड के साथ एक गड़बड़ है (देखें [1] और [2]),
क्योंकि mknod एक विशेषाधिकार प्राप्त बिल्ड चरण के बिना विफल/समर्थित नहीं है।

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

इसलिए मैं या तो जोड़ने का सुझाव दूंगा

• एक डॉकटर बिल्ड-विशेषाधिकार प्राप्त
  यह वही काम करना चाहिए जो रन-विशेषाधिकार प्राप्त है, यानी सभी को हटा रहा है
  कैप्स सीमाएं

या

• डॉकरफाइल में एक RUNP कमांड
  यह होना चाहिए .. ठीक है .. भागो, लेकिन _P_rivileges . के साथ

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

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (टिप्पणी) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHubhttps://github.com/dotcloud/docker/issues/1916 पर देखें
.

विक्टर व्यू
http://vvieux.com

असल में, हमें दोनों करना पड़ सकता है - यानी, RUNP + को "-विशेषाधिकार प्राप्त" की आवश्यकता होती है
झंडा।

यदि हम केवल RUNP ("-विशेषाधिकार प्राप्त" की आवश्यकता के बिना) पर भरोसा करते हैं, तो हम
हमें आश्चर्य होगा कि जब हम एक निर्माण करते हैं "क्या यह निर्माण सुरक्षित है?"।
अगर हम केवल "-विशेषाधिकार प्राप्त" पर भरोसा करते हैं, तो हम जानकारी को याद करते हैं (में)
Dockerfile) कि "इस क्रिया के लिए विस्तारित विशेषाधिकारों की आवश्यकता है"।

मुझे लगता है कि दोनों का संयोजन सबसे सुरक्षित तरीका है।

बुधवार, 18 सितंबर, 2013 को सुबह 4:07 बजे, बेंजामिन पॉड्सज़ुन
नोटिफिकेशन@github.comलिखा :

वर्तमान में ऐसा लगता है कि के बाहर विशेषाधिकार प्राप्त संचालन चलाने का कोई तरीका नहीं है
डॉकर रन-विशेषाधिकार प्राप्त।

इसका मतलब है कि मैं एक ही काम Dockerfile में नहीं कर सकता। मेरा हाल
मुद्दा: मैं एक कंटेनर के अंदर फ्यूज (एनसीएफ के लिए) चलाना चाहता हूं। स्थापित कर रहा है
फ्यूज पहले से ही हैक्स और बदसूरत वर्कअराउंड के साथ एक गड़बड़ है (देखें [1] और [2]),
क्योंकि mknod एक विशेषाधिकार प्राप्त बिल्ड चरण के बिना विफल/समर्थित नहीं है।

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

इसलिए मैं या तो जोड़ने का सुझाव दूंगा

• एक डॉकटर बिल्ड-विशेषाधिकार प्राप्त
  यह वही काम करना चाहिए जो रन-विशेषाधिकार प्राप्त है, यानी सभी को हटा रहा है
  कैप्स सीमाएं

या

• डॉकरफाइल में एक RUNP कमांड
  यह होना चाहिए .. ठीक है .. भागो, लेकिन _P_rivileges . के साथ

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

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (टिप्पणी) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHubhttps://github.com/dotcloud/docker/issues/1916 पर देखें
.

@jpetazzo https://twitter.com/jpetazzo
नवीनतम ब्लॉग पोस्ट: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

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

मेरा सुझाव है कि RUNP + build -privileged ।

@shykes की पकड़ ध्यान करने के लिए कुछ धुआं संकेत _lights, @crosbymichael_

... और फिर हमें इसे लागू करने के लिए किसी को ढूंढना होगा, निश्चित रूप से
क्या ऐसा कुछ होगा जिसे आप आजमाना चाहेंगे (निश्चित रूप से कोर टीम से उचित मार्गदर्शन और प्रतिक्रिया के साथ)?

अगर आखिरी हिस्से पर मुझ पर निशाना साधा गया था: ज़रूर, क्यों नहीं। मैं पहले से ही गो कोड के साथ खिलवाड़ कर रहा हूं (ऐसी भाषा नहीं जिससे मैं परिचित हूं, लेकिन ऊपर देखें: मैं यह पता लगाने की कोशिश कर रहा हूं कि वैसे भी क्या हो रहा है)।

कुछ प्रश्नों के लिए पिंग करने के लिए कुछ पॉइंटर्स/किसी के साथ मैं निश्चित रूप से इसे आज़मा दूंगा।

मुझे RUNP या बिल्ड-विशेषाधिकार पर बेचा नहीं गया है।

मैं

आम तौर पर मुझे ऐसा कुछ भी पसंद नहीं है जो एक ही इनपुट के विभिन्न संभावित निर्माणों का परिचय देता हो। इसलिए आप किसी बिल्ड में तर्क या env चर पारित नहीं कर सकते।

विशेष रूप से मुझे सभी जगहों पर "विशेषाधिकार प्राप्त" पर निर्भरता शुरू करना पसंद नहीं है, क्योंकि यह क्षमताओं का एक सेट निर्दिष्ट करता है जो ए) बहुत बड़ा है और बी) स्पष्ट रूप से स्पेक-एड या परिभाषित नहीं है। यह sysadmins के लिए एक मोटे तंत्र के रूप में सभी या कुछ भी नहीं में सुरक्षा को बायपास करने के लिए ठीक है - एक "एस्केप हैच" जब मानक डॉकटर निष्पादन वातावरण पर्याप्त नहीं होता है। यह बाइंड-माउंट और कस्टम lxc-conf के समान है।

-
@सोलोमोनस्ट्रे
@getdocker

शुक्र, 20 सितंबर, 2013 को दोपहर 3:18 बजे, बेंजामिन पॉड्सज़ुन
सूचनाएं @

अगर आखिरी हिस्से पर मुझ पर निशाना साधा गया था: ज़रूर, क्यों नहीं। मैं पहले से ही गो कोड के साथ खिलवाड़ कर रहा हूं (ऐसी भाषा नहीं जिससे मैं परिचित हूं, लेकिन ऊपर देखें: मैं यह पता लगाने की कोशिश कर रहा हूं कि वैसे भी क्या हो रहा है)।

कुछ प्रश्नों के लिए पिंग करने के लिए कुछ पॉइंटर्स/किसी के साथ मैं निश्चित रूप से इसे आज़मा दूंगा।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

ठीक है, क्या आप सहमत हैं कि डॉकर छवि बनाना संभव होना चाहिए - उदाहरण के लिए - फ्यूज चलाता है?
उसके लिए हमें mknod करने की आवश्यकता होगी।

जिस तरह से मैं इसे देखता हूं, पैरामीटर के आधार पर ये बिल्ड अलग-अलग नहीं हो सकते हैं: बिल्ड काम करेगा (कैप्स अब से कम / कम प्रतिबंधित नहीं हैं) या असफल (यथास्थिति)। एक ही बिल्ड फ़ाइल के विभिन्न 'संस्करणों' का कोई जोखिम नहीं है, है ना?

मैं अब इस मुद्दे में भाग रहा हूँ। मुझे जिस छवि की आवश्यकता है, उसे बनाने के लिए, मुझे run -privileged चरणों + एक commit चरण की एक श्रृंखला का प्रदर्शन करना होगा, बजाय build एक Dockerfile में। आदर्श रूप से, Dockerfile में छवि निर्माण चरणों को व्यक्त करना अच्छा होगा।

क्या यह mknod संचालन से भी संबंधित है?
यदि आप उन क्रियाओं का ठीक-ठीक वर्णन कर सकते हैं जिनके लिए विशेषाधिकार प्राप्त मोड की आवश्यकता होती है
आपका मामला, यह बहुत मददगार होगा!
धन्यवाद,

अरे @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 वह जगह है जहां से मैं डीबी 2 शुरू करने की कोशिश कर रहा हूं।

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

इसके लिए भी +1।

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

आइए "विशेषाधिकार प्राप्त" के साथ चलने / निर्माण की बात आने पर चिंताओं को अलग करने का प्रयास करें: यह केवल निर्माण के दौरान, docker run या दोनों के माध्यम से निष्पादन के दौरान आवश्यक हो सकता है।

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

हालाँकि, हमें डिफ़ॉल्ट रूप से विशेषाधिकार प्राप्त मोड में नहीं जाना चाहिए ताकि हम कुछ सेटिंग्स को बदलने के लिए sysctl का उपयोग कर सकें। यह छवि विन्यास के माध्यम से या कमांड लाइन तर्कों के माध्यम से docker run को पारित किया जाना चाहिए।

सही। @orikremer , क्या आपके पास उन मापदंडों के बारे में विवरण है जिन्हें वर्टिका डीबी और वेबस्फेयर एमक्यू बदलने की कोशिश कर रहे थे?

यदि यह सामान /sys या /proc में है, तो सबसे अच्छा उपाय यह हो सकता है कि विशेषाधिकार प्राप्त मोड पर स्विच करने के बजाय कुछ नकली ऊपर रखा जाए (चूंकि परिवर्तन वैसे भी जारी नहीं रहेंगे)।

लंबे समय में, एक नकली फाइल सिस्टम परिवर्तन को पकड़ सकता है और उन्हें डॉकरफाइल निर्देशों में परिवर्तित कर सकता है, रनटाइम को निर्देश देता है कि "अरे, इस कंटेनर को ऐसे या इस तरह के ट्वीक की आवश्यकता है"।

@jpetazzo मुझे छवि बनाए हुए कुछ दिन हो गए हैं। AFAIR वर्टिका शिकायत कर रही थी कि इसमें पर्याप्त मेमोरी नहीं है और दोनों अधिकतम खुली फाइलों को बदलने की कोशिश कर रहे थे।
मैं डॉकरफाइल का उपयोग करके छवि को फिर से बनाने और वापस रिपोर्ट करने का प्रयास करूंगा।

नोटिंग अंक #2080 जैसा कि यह संबंधित है।

@jpetazzo ने बिना विशेषाधिकार के छवि को फिर से

• Limits.conf में अच्छा: वर्टिका /etc/security/limits.conf में "dbadmin - अच्छा 0" जोड़ता है। गैर-विशेषाधिकार प्राप्त कंटेनर में चलते समय उस उपयोगकर्ता पर स्विच करने का प्रयास करते समय मुझे "सत्र नहीं खोल सका" त्रुटि मिलती है। एक विशेषाधिकार प्राप्त कंटेनर स्विच में उपयोगकर्ता बिना किसी त्रुटि के काम करता है।
• अधिकतम खुली फ़ाइलें: चूंकि कंटेनर में आवश्यक अधिकतम होस्ट में एक सेट से अधिक था, इसलिए मुझे होस्ट पर /etc/init/docker.conf बदलना पड़ा और कंटेनर में "लिमिट नोफाइल" और फिर ulimit -n सेट करना पड़ा। क्या यह सही तरीका है?

उस उपयोगकर्ता पर स्विच करने का प्रयास करते समय,

स्विच कैसे होता है? मुझे समझ में नहीं आता कि कैसे -privileged उपयोगकर्ता-स्विचिंग में मदद करेगा; मुझे शायद यहाँ कुछ याद आ रहा है :-)

अधिकतम खुली फ़ाइलें

अगर मैं सही ढंग से समझूं, तो वर्टिकल इंस्टॉलर खुली फाइलों की अधिकतम संख्या को बहुत अधिक संख्या में सेट करने का प्रयास करता है, और यह केवल तभी काम करता है जब डॉकर को इतनी अधिक संख्या _or_ के साथ -privileged ध्वज के साथ शुरू किया गया था; अधिकार?

स्विचिंग उपयोगकर्ता - su dbadmin उस त्रुटि के साथ विफल हो जाता है।
मैं इसके द्वारा पुन: पेश करने में सक्षम था:

• एक नई छवि खींचें (सेंटोस-6.4-x86_64) और गैर-विशेषाधिकार प्राप्त चलाएं
• useradd testuser
• संपादित करें /etc/security/limits.conf, "testuser - अच्छा 0" जोड़ें
• su testuser -> "सत्र नहीं खोल सका" के साथ विफल होना चाहिए
  एक विशेषाधिकार प्राप्त कंटेनर में su testuser ठीक काम करता है।

अधिकतम खुली फ़ाइलें - सही। इंस्टॉलर होस्ट की तुलना में अधिक संख्या पर सेट करने का प्रयास करता है। केवल मेजबानों की सेटिंग बढ़ाकर या -विशेषाधिकार शुरू करके ही यह काम करता है।

मैंने अभी निम्नलिखित 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$

मैं पीएएम मॉड्यूल के लिए डिबगिंग (जोड़कर चालू debug करने के लिए pam_limits.so में लाइन /etc/pam.d/system-auth ), स्थापित syslog , करने की कोशिश की su फिर से, और यहाँ मुझे /var/log/secure में क्या मिला:

7 अक्टूबर 14:12:23 8be1e7bc5590 सु: pam_limits(su:session): '/etc/security/limits.conf' से सेटिंग पढ़ना
7 अक्टूबर 14:12:23 8be1e7bc5590 सु: pam_limits(su:session): process_limit: प्रसंस्करण - उपयोगकर्ता के लिए अच्छा 0
7 अक्टूबर 14:12:23 8be1e7bc5590 सु: pam_limits(su:session): '/etc/security/limits.d/90-nproc.conf' से सेटिंग पढ़ना
अक्टूबर 7 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: DEFAULT के लिए सॉफ्ट nproc 1024 को संसाधित करना
अक्टूबर 7 14:12:23 8be1e7bc5590 सु: pam_limits(su:session): 'नाइस' के लिए सीमा निर्धारित नहीं कर सका: ऑपरेशन की अनुमति नहीं है

फिर मैंने strace d su प्रक्रिया, और पाया कि निम्न सिस्टम कॉल विफल हो रहा था:

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

यह, बदले में, pam_limits मॉड्यूल को विफलता की रिपोर्ट करने का कारण बनता है; और यह su को जारी रहने से रोकता है।
दिलचस्प बात यह है कि उबंटू पर, pam_limits डिफ़ॉल्ट रूप से su लिए सक्षम नहीं है; और यदि आप इसे सक्षम भी करते हैं, तो भी setrlimit कॉल विफल हो जाती है, लेकिन su जारी रहता है और वैसे भी काम करता है।
यह ऑडिट कोड से संबंधित हो सकता है, मुझे यकीन नहीं है।

अब, setrlimit विफल क्यों हो रहा है? क्योंकि कंटेनर में sys_resource क्षमता नहीं है, जो किसी भी प्रकार की सीमा बढ़ाने के लिए आवश्यक है।

मुझे लगता है कि मैं सिर्फ उस limits.conf निर्देश पर टिप्पणी करूंगा।
(वैसे, सामान को सीधे limits.conf जोड़ना बुरा व्यवहार है; मुझे लगता है कि इसे limits.d में एक अलग फ़ाइल में जाना चाहिए।)

नोट: चूंकि आपने पहले ही डॉकर के लिए खुली फाइलों की संख्या की सीमा बढ़ा दी है, आप अधिकतम प्राथमिकता के लिए सीमा भी बढ़ा सकते हैं; यह भी काम करना चाहिए!

आशा है कि ये आपकी मदद करेगा।

उस डॉकरफाइल में, आपको निम्न पंक्ति स्वयं ही मिल गई है:

RUN su testuser

इसके साथ जाने के लिए कोई आदेश नहीं है (और यह किसी भी परिणामी शेल को बाद के RUN कमांड पर लागू नहीं करेगा), इसलिए मुझे आश्चर्य नहीं होगा यदि यह वास्तव में एक शेल खोलने की कोशिश में विफल हो रहा है और कहीं इंटरैक्टिव नहीं है जो ऐसा करने से समझ में आता है (चूंकि docker build एक इंटरैक्टिव प्रक्रिया नहीं है)। मेरे पास पुष्टि करने के लिए अभी समय नहीं है, लेकिन su को पास किए जाने वाले वास्तविक आदेश के साथ शायद यह एक कोशिश के लायक है।

@jpetazzo विस्तृत विवरण के लिए धन्यवाद। मैं डॉकर के लिए अधिकतम प्राथमिकता बढ़ाने की कोशिश करूंगा और देख सकता हूं कि इससे मदद मिलती है या नहीं।

(वैसे, लिमिट्स.कॉन्फ़ में सीधे सामान जोड़ना बुरा व्यवहार है; इसे लिमिट्स में एक अलग फ़ाइल में जाना चाहिए। डी, मुझे लगता है।)

सहमत हूं, लेकिन चूंकि यह वर्टिका इंस्टॉलर कोड है जो इसे वहां डाल रहा है, मैं इसके आसपास काम करने की कोशिश कर रहा हूं।

@tianon ऐसा ही होता है अगर मैं इसे एक इंटरेक्टिव शेल (/bin/bash) में चलाता हूं।

क्षमा करें, मुझे लगता है कि यह अभी भी एक कोशिश के काबिल था।

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

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

@tianon आप सही कह रहे हैं, इसका कोई मतलब नहीं है। यह केवल यह प्रदर्शित करने के लिए था कि सु स्वयं विफल हो जाता है।

मूल चर्चा करने के लिए वापस पाने के लिए: मेरा मानना है कि यह एक सुरक्षा के दृष्टिकोण से ठीक है अनुमति देने के लिए (और उपयोगी!) setfcap और mknod निर्माण प्रक्रिया में क्षमताओं (और शायद के रूप में नियमित रूप से कंटेनर निष्पादन में कुंआ)। क्या किसी को कोई समस्या दिखाई देती है जो इससे उत्पन्न हो सकती है?

@jpetazzo बिल्कुल विपरीत! यह मेरे सामने आने वाली कई समस्याओं का समाधान करेगा। मुझे लगता है कि यह उन लोगों के लिए जरूरी है जो डॉकर कंटेनर चलाना चाहते हैं जो वास्तविक मशीन की तरह कार्य/दिखते हैं।

ठीक है! अगर यह आपके साथ ठीक है, तो मैं इस मुद्दे को # 2191 के पक्ष में बंद कर रहा हूं, "सभी कंटेनरों में mknod और setfcap क्षमताओं को सक्षम करें" :-)

क्या हम ऐसे परिदृश्यों के बारे में जानते हैं?

13 अक्टूबर, 2013 को दोपहर 12:22 बजे, अंकलजैक नोटिफिकेशन @github.com ने लिखा:

2191 https://github.com/dotcloud/docker/issues/2191 इसका समाधान नहीं करता है

सभी परिदृश्यों के लिए समस्या जिसके लिए डॉकर बिल्ड-विशेषाधिकार की आवश्यकता होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://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 का उपयोग करना चाहते हैं।

मैंने अपनी टिप्पणी को संपादित करते समय गलती से हटा दिया है।

कृपया एक नज़र डालें कि डॉकरफाइल में सब कुछ किए बिना यह कैसा दिखेगा:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/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

यह मुझे Dockerfile या docker build -privileged में runp की कमी के आसपास काम करने के लिए मजबूर कर रहा है, इस प्रकार Dockerfiles को बेकार कर देता है और मुझे Dockerfile जैसी कार्यक्षमता को डुप्लिकेट करने के लिए एक टूल लिखने के लिए मजबूर करता है।

जाहिर है, डॉकरफाइल runp या docker build -privileged साथ अधिक उपयोगी होगा:
रनप उदाहरण:

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 का उपयोग करने के लिए -विशेषाधिकार मोड केवल उन आदेशों के लिए जिन्हें वास्तव में इसकी आवश्यकता है) उपयोगी होगा।

आह, माउंट निश्चित रूप से एक बड़ा है। यह एक बहुत ही मान्य उपयोग-मामला है, और हम _probably_ उन्हें सामान्य स्थिति में अनुमति नहीं देना चाहते हैं। मैं इस मुद्दे को फिर से खोल रहा हूं।

@jpetazzo आरई: पीएएम मॉड्यूल (मैं वर्टिका भी स्थापित कर रहा हूं) क्या आप sys_resource को lxc.cap.drop से बाहर निकालने के बाद संकलित करने का सुझाव देंगे?

हो सकता है कि इनमें से कुछ सीमाएँ docker.conf फ़ाइल के माध्यम से सेट की जा सकती हैं?

यह माना जाना चाहिए कि डॉकर स्वयं क्षमताओं के सीमित सेट में चल रहा हो सकता है, जिससे डॉकर को अपने कंटेनरों को सौंपने के लिए ये विशेषाधिकार उपलब्ध नहीं हो सकते हैं। नेस्टेड डॉकर परिदृश्य में यह विशेष रूप से सच होगा # 2080 भूमि जारी करनी चाहिए - यह गैर-विशेषाधिकार प्राप्त नेस्टेड डॉकर को अनुमति दे सकती है।

ऐसा नहीं है कि यह कुछ भी बदलता है, सिवाय इसके कि 'रनप' या '-प्राइवेल्ड' जैसे समाधान सभी डॉकर वातावरण में सफलता की गारंटी नहीं दे सकते हैं। इस तरह के आदेशों को जोड़ते समय और उनका दस्तावेजीकरण करते समय इस पर विचार किया जाना चाहिए।

@ramarnat @jpetazzo सिर्फ वर्टिका इंस्टाल और अच्छे स्तर के मुद्दे पर लूप को बंद करने के लिए,
मैंने docker.conf में अच्छी सीमा निर्धारित करने का प्रयास किया, लेकिन यह मेरे काम नहीं आया और मुझे बैश विशेषाधिकार चलाने और इसे मैन्युअल रूप से स्थापित करने के लिए मजबूर होना पड़ा।

@orikremer @jpetazzo मैं lxc_template.go से sys_resource को हटाकर और docker को पुन: संकलित करके इंस्टॉल को चलाने में सक्षम था। मैं वहां एक पुल अनुरोध कर सकता हूं, लेकिन मैं एलएक्ससी कॉन्फ़िगरेशन से इसे हटाने के सुरक्षा प्रभावों के बारे में दूसरों के विचार के लिए प्रतीक्षा करूंगा।

@ramarnat : परिदृश्य के आधार पर, कुछ लोग सोचेंगे कि sys_resource को हटाना ठीक है; कुछ अन्य लोगों के लिए यह एक समस्या होगी।

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

यह माउंट/लूप परिदृश्य को ठीक नहीं करता है, हालांकि (मैं अभी भी इस पर सो रहा हूं)।

@jpetazzo शायद

खैर, यह एक संभावना है, लेकिन यह विभिन्न कंटेनरीकरण प्रणालियों में भविष्य की अनुकूलता को तोड़ने का भी एक अच्छा तरीका है :-) हम देखेंगे कि क्या हमें कुछ भी बेहतर नहीं मिल रहा है।

क्या हम गैर-विशेषाधिकार प्राप्त मोड में श्वेतसूची/देव/लूप* कर सकते हैं? मुझे लगता है कि समस्या यह है कि यह मुझे अन्य कंटेनर के लूप माउंटेड फाइलों तक पहुंच प्रदान कर सकता है, या यहां तक ​​​​कि मेजबान की भी ...

@सोलोमोनस्ट्रे
@docker

गुरु, अक्टूबर 17, 2013 को शाम 6:09 बजे, जेरोम पेटाज़ोनी
सूचनाएं @

खैर, यह एक संभावना है, लेकिन यह विभिन्न कंटेनरीकरण प्रणालियों में भविष्य की अनुकूलता को तोड़ने का भी एक अच्छा तरीका है :-) हम देखेंगे कि क्या हमें कुछ भी बेहतर नहीं मिल रहा है।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo यह सच है, लेकिन मुझे लगता है कि डॉकर को अंतर्निहित कंटेनरीकरण सिस्टम कॉन्फ़िगरेशन को ओवरराइड करने के मानक तरीके की आवश्यकता होगी यदि इसकी अनुमति है - मुझे लगता है कि निर्माण विशेषाधिकार प्राप्त विचार पर वापस!

@solomonstre मुद्दा यह है कि docker build को विशेषाधिकार प्राप्त मोड में बनाने की अनुमति देने का एक तरीका होना चाहिए। /dev/loop* तक पहुंच की अनुमति देने से मुझे मेरे विशेष उपयोग के मामले में मदद नहीं मिलेगी।

@ सोलोमोनस्ट्रे : श्वेतसूची/देव/लूप,

मैं समझता/समझती हूं कि कुछ बिल्ड के लिए लूप डिवाइस, माउंट और अन्य चीज़ों की आवश्यकता होगी। आइए हमारे विकल्पों की समीक्षा करें:

1. docker build -privileged
   सुविधाजनक, लेकिन "सामान्य बिल्ड" और "विशेषाधिकार प्राप्त बिल्ड" के बीच की रेखा खींचता है। यदि आपके पास एक बहुत ही उपयोगी छवि होती है जिसके लिए एक विशेषाधिकार प्राप्त बिल्डर की आवश्यकता होती है, तो इसे सार्वजनिक बिल्डरों पर बनाना मुश्किल होगा। उदाहरण के लिए, यदि कोई बिल्ड को स्वचालित करने के लिए एक सेवा शुरू करता है, तो वे शायद विशेषाधिकार प्राप्त बिल्ड की पेशकश नहीं करेंगे (या उन्हें अतिरिक्त सुरक्षा उपायों का उपयोग करना होगा)।
2. बिल्डर में अनुमतियों को थोड़ा आराम दें
   इसका मतलब है (कम से कम) cap_sysadmin को सक्षम करना (यह मुझे थोड़ा सा पागल बनाता है), और शायद प्रत्येक बिल्डर को एक या दो लूप डिवाइस दे रहा है। यह समानांतर में चल रहे बिल्डरों की कुल संख्या को सीमित कर देगा; लेकिन यह कोई बड़ी बात नहीं है क्योंकि बिल्ड को तेज़ और अधिक महत्वपूर्ण रूप से सक्रिय प्रक्रियाओं के रूप में माना जाता है। IE यदि आपके पास समानांतर में 50 बिल्ड चल रहे हैं, जब तक कि आपके पास किकस I/O सबसिस्टम वाली मशीन न हो, वे बिल्ड ज्यादा प्रगति नहीं करेंगे।
3. बिल्ड को वर्चुअलाइजेशन/आइसोलेशन की दूसरी परत में लपेटें।
   सीधे डॉकर के भीतर बिल्ड चलाने के बजाय, क्यूईएमयू-इन-डॉकर, या यूएमएल-इन-डॉकर जैसे कुछ चलाएं। डॉकर डेवलपर के दृष्टिकोण से यह एक अच्छा समाधान है, क्योंकि इसका मतलब कोई अतिरिक्त काम नहीं है; यह DOcker उपयोगकर्ता के दृष्टिकोण से एक खराब समाधान है, क्योंकि इसका अर्थ है जटिलता की एक और परत से निपटना।

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

तुम लोग क्या सोचते हो?

@backjlack , क्या मैं पूछ सकता हूं कि एक बार
तब होता है जब आप इसे "डॉकर रन" करते हैं, तो एप्लिकेशन क्या है? अभी - अभी
इसके लिए उपयोग के मामलों की समझ पाने की कोशिश कर रहा है।

शुक्र, 18 अक्टूबर, 2013 को सुबह 9:59 बजे, जेरोम पेटाज़ोनी
नोटिफिकेशन@github.comलिखा :

@solomonstre https://github.com/solomonstre : श्वेतसूची/देव/लूप है,
आईएमएचओ, एक बड़ी संख्या नहीं, क्योंकि डीएम शाखा के साथ, यह पढ़ने/लिखने देगा
सब कुछ तक पहुंच (चूंकि डीएम शाखा का डिफ़ॉल्ट व्यवहार उपयोग करना है
पूल को स्टोर करने के लिए लूप डिवाइस)।

मैं समझता हूं कि कुछ बिल्ड के लिए लूप डिवाइस, माउंट और अन्य की आवश्यकता होगी
चीज़ें। आइए हमारे विकल्पों की समीक्षा करें:

1. डॉकर बिल्ड-विशेषाधिकार सुविधाजनक है, लेकिन बीच की रेखा खींचता है
   "सामान्य बिल्ड" और "विशेषाधिकार प्राप्त बिल्ड"। यदि आपके पास बहुत होता है
   उपयोगी छवि जिसके लिए एक विशेषाधिकार प्राप्त निर्माता की आवश्यकता होती है, यह मुश्किल होगा
   इसे सार्वजनिक बिल्डरों पर बनाएं। उदाहरण के लिए अगर कोई स्वचालित करने के लिए सेवा शुरू करता है
   बनाता है, वे शायद विशेषाधिकार प्राप्त बिल्ड की पेशकश नहीं करेंगे (या उनके पास होगा
   अतिरिक्त सुरक्षा उपायों का उपयोग करने के लिए)।
2. बिल्डर में अनुमतियों को थोड़ा आराम दें इसका मतलब है (कम से कम)
   Cap_sysadmin को सक्षम करना (यह पागल मुझे थोड़ा कांपता है), और शायद
   प्रत्येक बिल्डर को एक या दो लूप डिवाइस देना। यह कुल को सीमित करेगा
   समानांतर में चल रहे बिल्डरों की संख्या; लेकिन यह कोई बड़ी बात नहीं है
   बिल्ड को तेज़ और अधिक महत्वपूर्ण रूप से सक्रिय प्रक्रिया माना जाता है।
   IE यदि आपके पास समानांतर में 50 बिल्ड चल रहे हैं, जब तक कि आपके पास मशीन न हो
   किकस I/O सबसिस्टम के साथ, वे बिल्ड ज्यादा प्रगति नहीं करेंगे।
3. बिल्ड को वर्चुअलाइजेशन/आइसोलेशन की दूसरी परत में लपेटें।
   बिल्ड को सीधे डॉकर के भीतर चलाने के बजाय, कुछ इस तरह चलाएं
   क्यूईएमयू-इन-डॉकर, या यूएमएल-इन-डॉकर। यह एक डॉकर से एक अच्छा समाधान है
   डेवलपर का दृष्टिकोण, क्योंकि इसका मतलब कोई अतिरिक्त काम नहीं है; यह एक गरीब है
   DOcker उपयोगकर्ता के दृष्टिकोण से समाधान, क्योंकि इसका अर्थ है व्यवहार करना
   जटिलता की एक और परत।

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

तुम लोग क्या सोचते हो?

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - मैं फ़्यूज़ स्थापित करने के लिए mknode क्षमताओं (S3 बाल्टी को माउंट करने के लिए) या Dockerfiles में विशेषाधिकार प्राप्त रन निष्पादित करने की क्षमता देखना चाहूंगा। सुनिश्चित नहीं है कि सबसे अच्छा समाधान क्या है, फिर भी।

+1। इस मुद्दे पर कोई अपडेट?

+1
नवंबर 17, 2013 11:31 pm पर, "yukw777" [email protected] लिखा है:

+1। इस मुद्दे पर कोई अपडेट?

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

मैंने जावा को स्थापित करने की कोशिश में फ्यूज मुद्दे को भी मारा है और मुझे समाधान में दिलचस्पी है। मैंने यहां सुझाए गए वर्कअराउंड की कोशिश की https://gist.github.com/henrik-muehe/6155333 लेकिन यह मेरे लिए रास्पबेरी पाई पर डॉकटर पर काम नहीं करता है।

@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 के लिए जाऊंगा क्योंकि डिवाइस एक्सेस को अलग करना _is_ जटिलता की एक और परत है और इसे कहीं न कहीं प्रबंधित किया जाना है।

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

यदि आपको फाइल सिस्टम छवि या फ्यूज fs को माउंट करने की आवश्यकता है, तो आप इसे कंटेनर के बाहर माउंट कर सकते हैं और इसे वॉल्यूम/बाइंड माउंट के रूप में उपयोग कर सकते हैं। हालाँकि यह डॉकर में ही दूरस्थ फाइल सिस्टम का समर्थन और प्रबंधन करने के लिए एक अच्छी सुविधा हो सकती है। शायद एक dockerfile MOUNT/माउंट पॉइंट।

@discordianfish 3) काफी गैर-समाधान है।

क्या #2979 इस समस्या से निपटने में मदद करेगा?

मैं इसके लिए भी एक संकल्प की प्रतीक्षा कर रहा हूं, लेकिन mknod के कारण नहीं। हम rpms के साथ सेंटो कंटेनर चला रहे हैं जो /etc/security/limits.d/ का उपयोग करने वाले उपयोगकर्ताओं के लिए सीमा निर्धारित करता है और मैं वर्तमान में एक स्लेजहैमर वर्कअराउंड का उपयोग कर रहा हूं जिसमें शामिल हैं:

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

मेरे Dockerfile के शीर्ष पर। (हम सिर्फ प्रोटोटाइप कर रहे हैं, चिंता न करें :))

हाय @jpetazzo मैंने आपके द्वारा सुझाए गए दोनों विकल्पों की कोशिश की। मैं एक छवि "oracle_xe" का उपयोग कर बनाने की कोशिश कर रहा हूँ

sudo docker बिल्ड - विशेषाधिकार प्राप्त -t oracle_xe क्योंकि मेरे Dockerfile में मैं इन 2 कमांडों को चलाना चाहता हूँ

भागो माउंट -ओ रिमाउंट, आकार = 3 जी / देव / शम
भागो माउंट -a

लेकिन यह काम नहीं करता है, मुझे नहीं पता कि मैंने जो सिंटैक्स इस्तेमाल किया है वह गलत है, मुझे जो त्रुटि मिलती है वह है
ध्वज प्रदान किया गया लेकिन परिभाषित नहीं: -विशेषाधिकार प्राप्त

मैंने RUNP का उपयोग करने के लिए दूसरी पसंद की भी कोशिश की, लेकिन वह भी काम नहीं किया, जब मैं छवि बनाता हूं तो यह उस चरण को कहते हुए छोड़ देता है

अज्ञात निर्देश RUNP छोड़ना। मैं आपको डॉकरफाइल भेज सकता हूं जिसे मैं बनाने की कोशिश कर रहा हूं। कृपया इस मुद्दे को हल करने में मेरी मदद करें।

धन्यवाद।

मुझे लगता है कि न तो RUNP और न ही "बिल्ड --विशेषाधिकार प्राप्त" लागू किए गए थे।
यदि संभव हो, तो Dockerfile को साझा करने में संकोच न करें; यह उपयोगी हो सकता है तो
हम आपको "कम से कम बदतर" समाधान दे सकते हैं :-)

बुधवार, 9 अप्रैल, 2014 को सुबह 7:44 बजे, मनोज7 नोटिफिकेशन @github.com ने लिखा:

हाय jpetazzo मैंने आपके द्वारा सुझाए गए दोनों विकल्पों की कोशिश की। मैं निर्माण करने की कोशिश कर रहा हूँ
एक छवि "oracle_xe" का उपयोग कर

sudo docker बिल्ड - विशेषाधिकार प्राप्त -t oracle_xe क्योंकि मेरे Dockerfile i . में
इन 2 आदेशों को चलाना चाहते हैं

भागो माउंट -ओ रिमाउंट, आकार = 3 जी / देव / शम
भागो माउंट -a

लेकिन मैं यह काम नहीं करता, मुझे नहीं पता कि मैंने जिस वाक्य रचना का उपयोग किया है वह है
गलत। मैंने RUNP का उपयोग करने के लिए दूसरी पसंद की भी कोशिश की लेकिन वह भी नहीं हुआ
काम, जब मैं छवि का निर्माण करता हूं तो यह उस चरण को कहते हुए छोड़ देता है
अज्ञात निर्देश RUNP छोड़ना। मैं आपको डॉकरफाइल भेज सकता हूं जो मैं हूं
बनाने की कोशिश कर रहा है। कृपया इस मुद्दे को हल करने में मेरी मदद करें।

धन्यवाद।

इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://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 , मैं अपने Dockerfile में "RUN sudo umount/etc/hosts" करना चाहता हूं - क्या इसके लिए "कम से कम बदतर" समाधान है? ;)

@jpetazzo

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 जोड़ें
भागो माउंट -ओ रिमाउंट, आकार = 3 जी / देव / शम
भागो माउंट -a
cd /appl/oracle/xe && अनज़िप करें oracle-xe-11.2.0-1.0.x86_64.rpm.zip चलाएँ
cd /appl/oracle/xe/Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm चलाएं
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
ईएनवी ORACLE_SID XE

मैंने कोशिश की पहली चीज थी

sudo docker बिल्ड-विशेषाधिकार प्राप्त -t oracle_xe।

यह काम नहीं किया और फिर मैंने RUNP . का उपयोग करने की कोशिश की
RUNP माउंट -ओ रिमाउंट, आकार = 3G / देव / shm
RUNP माउंट -a
यह भी काम नहीं किया, इन दो चरणों को छोड़ दिया गया।

@gatoravi : दुर्भाग्य से, अनमाउंटिंग /etc/hosts आसानी से काम नहीं करेगा। आपको ऐसा करने की आवश्यकता क्यों है? (मैं समझता हूं कि आपके पास बहुत ही वैध कारण हो सकते हैं, लेकिन मुझे आपको सबसे अच्छा समाधान देने के लिए उन्हें सुनना अच्छा लगेगा ...)

@ भगत 7 : ठीक है! प्रश्न: क्या आपको रन टाइम _और_ इंस्टाल टाइम, या केवल रन टाइम पर बड़े /dev/shm की आवश्यकता है? यदि यह निर्माण समय पर है, तो कौन सा चरण विफल हो रहा है और कैसे?

@jpetazzo मैं अपने टूल की निर्माण प्रक्रिया के एक भाग के रूप में /etc/hosts में एक नया और IP पता जोड़ना चाहूंगा।
echo $IP $HOST >> /etc/hosts जैसा कुछ।

यदि मैं docker run --privileged उपयोग करता हूं और फिर sudo umount \etc\hosts उपयोग करता हूं तो मैं यह ठीक कर सकता हूं लेकिन ऐसा लगता है कि मैं docker commit का उपयोग करने में असमर्थ हूं इसलिए मुझे umount दोहराना होगा

मैं किसी तरह \etc\hosts लिखने योग्य बनाना चाहता हूं और इसे लगातार बनाना चाहता हूं, ऐसा कोई तरीका नहीं मिल रहा है या तो इसे docker commit या डॉकरफाइल के साथ करें।

@jpetazzo

मुझे यह समस्या थी

bash-4.1#/etc/init.d/oracle-xe कॉन्फ़िगर करें
Oracle एप्लिकेशन एक्सप्रेस [8080] के लिए उपयोग किए जाने वाले HTTP पोर्ट को निर्दिष्ट करें:

एक पोर्ट निर्दिष्ट करें जो डेटाबेस श्रोता के लिए उपयोग किया जाएगा [1521]: 1521

डेटाबेस खातों के लिए उपयोग किया जाने वाला पासवर्ड निर्दिष्ट करें। ध्यान दें कि वही
पासवर्ड का उपयोग सिस्टम और सिस्टम के लिए किया जाएगा। Oracle के उपयोग की अनुशंसा करता है
प्रत्येक डेटाबेस खाते के लिए अलग पासवर्ड। इसके बाद किया जा सकता है
प्रारंभिक विन्यास:
पासवर्ड की पुष्टि करें:

क्या आप चाहते हैं कि Oracle डेटाबेस 11g एक्सप्रेस संस्करण बूट (y/n) [y]:y . पर प्रारंभ हो

Oracle नेट श्रोता शुरू कर रहा है...हो गया
डेटाबेस को कॉन्फ़िगर करना...हो गया
Oracle डाटाबेस 11g एक्सप्रेस संस्करण इंस्टेंस शुरू कर रहा है...हो गया
स्थापना सफलतापूर्वक पूर्ण हुई।
bash-4.1#cd /u01/app/oracle/product/11.2.0/xe/bin
बेस-4.1#एसक्लप्लस
उपयोगकर्ता नाम दर्ज करें: सिस्टम
पासवर्ड दर्ज करें: * **
लेकिन मुझे यह त्रुटि मिलती है
ORA-01034: ORACLE उपलब्ध नहीं है
ORA-27101: साझा स्मृति क्षेत्र मौजूद नहीं है
Linux-x86_64 त्रुटि: 2: ऐसी कोई फ़ाइल या निर्देशिका नहीं
प्रक्रिया आईडी: 0
सत्र आईडी: 0 क्रमांक: 0
df -h कंटेनर के अंदर वापस आ गया
फ़ाइल सिस्टम का आकार उपयोग किया गया उपयोग करें% माउंटेड का उपयोग करें
tmpfs 64M 0 64M 0% /dev/shm

इसलिए जब मैंने tmpfs का आकार बढ़ाकर 3G कर दिया तो मुझे यह त्रुटि नहीं मिली। मैंने इसे कंटेनर के रूप में चलाकर हल किया
sudo docker रन -विशेषाधिकार प्राप्त -i -t oracle_xe /bin/bash. मैंने कंटेनर के अंदर 2 माउंट कमांड चलाए। लेकिन मैं इसे इस तरह से नहीं करना चाहता, इसके बजाय मैं उन्हें अपने डॉकरफाइल में रखना चाहता हूं और इसे बनाना चाहता हूं।

@gatoravi : ठीक है, समझ गया। फिर दो और प्रश्न: क्या आपको उस अतिरिक्त होस्ट की आवश्यकता है /etc/hosts निर्माण के दौरान, या केवल रन के दौरान? और आपको इसकी आवश्यकता क्यों है?

@ भगत 7 : क्षमा करें, मेरे पास इसके लिए अभी तक एक सुंदर समाधान नहीं है :-( मैं दो डॉकरफाइल रखने का सुझाव दूंगा:

• पहला वाला जो सभी चरणों को पूरा करता है (उसके अलावा जिसे बड़े / देव / एसएचएम की आवश्यकता होती है), और एक सीएमडी को परिभाषित करता है जो जांच करेगा कि कंटेनर विशेषाधिकार प्राप्त मोड में चल रहा है या नहीं, बड़ा / देव / एसएचएम माउंट करें, और विशेष चलाएं आदेश;
• आगे के चरणों को करने के लिए एक दूसरा Dockerfile (जब तक कि आपको रनटाइम पर /dev/shm की भी आवश्यकता न हो, तो अभी के लिए आपको एक विशेषाधिकार प्राप्त चीज़ की आवश्यकता है)।

@jpetazzo हम अपने उपयोगकर्ताओं को एक संपादन योग्य /etc/hosts/ के साथ एक छवि (/कंटेनर) प्रदान करना चाहते हैं ताकि वे हमारे कोड का निर्माण कर सकें जो उस फ़ाइल को संशोधित करता है :) जैसे कि हमें होस्ट को जोड़ने की आवश्यकता क्यों है, I' मैं वास्तव में ईमानदार होने के लिए निश्चित नहीं हूं, हम इसे कुछ होस्ट-नामों को आईपी पते पर इंगित करने में सहायता के लिए हमारे इंस्टॉल के हिस्से के रूप में करते हैं।

@ भगत 7 मैं एक संयोजन का उपयोग करके 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 के शीर्ष पर बनाया है। लेकिन मैं इसे सेंटोस पर बनाने की कोशिश कर रहा हूं।

@jpetazzo आपके सुझाव के लिए बहुत बहुत धन्यवाद

हाय दोस्तों,

मैं google-chrome का उपयोग कर रहा हूं जिसे /dev/shm पर लिखने की आवश्यकता है जो आमतौर पर 777 लगता है और यहां 755 है। मैंने अपने /etc/fstab एक विशिष्ट कॉन्फ़िगरेशन जोड़ने का प्रयास किया लेकिन बिल्ड पर संशोधनों को लागू करने के लिए mout -a नहीं चला सकता। बेशक मैंने मूल chmod या chown लेकिन न तो इसे बनाने पर ऐसा नहीं कर सकता।

अगर मैं --privileged मोड में लॉग इन करते समय अपने आदेशों का उपयोग करता हूं, तो सब कुछ ठीक है। लेकिन मुझे जरूरत है, जैसा कि अन्य लोगों ने समझाया, इसे निर्माण पर करने के लिए।

कोई उपाय?

धन्यवाद।

@tomav "/ dev/shm" अनुमति समस्या वास्तव में # 5126 है, जिसे # 5131 में तय किया गया था और पहले से ही मास्टर में विलय कर दिया गया है (और अगली रिलीज में होगा)

धन्यवाद @tianon।

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

मैंने इस लेख में कंटेनरों को डालने के लिए एक क्रिप्टफ बनाने के बारे में खूबसूरती से प्रलेखित कुछ चरणों का पालन किया: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

ध्यान दें, कि मैं _not_ ऐसा करने की कोशिश कर रहा हूं, लेकिन वास्तव में एक माउंटेड क्रिप्टफ के साथ एक कंटेनर है:
इसलिए एक एन्क्रिप्टेड फाइल सिस्टम को डॉकर के माध्यम से निर्माण के दौरान बनाया, घुड़सवार, स्वरूपित किया जाना चाहिए।

जो विफल रहता है:

• जब मैं लूप डिवाइस खोजने का प्रयास करता हूं:

+ 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'.)

• अजीब तरह से वही dockerfile _sometime_ एक लूप डिवाइस खोजने में सफल होता है, फिर:

+ 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 : हालांकि, ध्यान दें कि यदि आप RUN में iptables नियम सेट कर सकते हैं, तो यह तुरंत खो जाएगा, क्योंकि एक छवि केवल फाइल सिस्टम की स्थिति रखती है। यह चल रही प्रक्रियाओं, नेटवर्क मार्गों, iptables नियमों आदि के बारे में नहीं जानता है।

यह मेरे लिए ठीक है, क्योंकि कंटेनर में केवल विशिष्ट पोर्ट होंगे
अग्रेषित, मुझे फ़ायरवॉल से कोई सरोकार नहीं है, मैं ज्यादातर बस यही चाहता हूँ
इंस्टॉलर बिल्कुल भी सफल होने में सक्षम होने के लिए

एंड्रयू मेलो

@PerilousApricot मैं देख रहा हूँ! उस स्थिति में, iptables से /bin/true सिमलिंक करने के बारे में क्या? इससे इंस्टॉलर को भी खुश होना चाहिए। (या इंस्टॉलर को बेवकूफ बनाने के लिए कुछ इसी तरह की तरकीब?)

मैंने कोशिश की, लेकिन इंस्टॉलर को आउटपुट को पार्स करने की भी आवश्यकता है
iptables, तो यह इतना आसान नहीं है :)

ठीक है, मुझे पता है कि यह हैकिश हो रहा है, लेकिन - इसके बजाय नकली iptables डालने के बारे में क्या? जो कुछ डमी आउटपुट उत्पन्न करेगा?

मैं पूरी तरह से समझता हूं कि यह बहुत अच्छा नहीं है; लेकिन गंभीरता से, उस तरह के इंस्टॉलर को पहले स्थान पर तय किया जाना चाहिए :)

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

मैं इसे डॉकर में डॉकर के लिए भी चाहता हूं। एक छवि है जिसे एप्लिकेशन चलाने से पहले खींचने की आवश्यकता है, जो कि काफी बड़ी है, और मैं इसे बार-बार खींचने और/या प्रतिबद्ध करने की आवश्यकता के बजाय docker build हिस्से के रूप में खींचा और कैश करना चाहता हूं कंटेनर जो इसे खींच लिया है।

यह सुविधा एक आवश्यक IMHO है, RUNP के साथ build-privileged संयोजन बहुत अच्छा होगा।

वास्तविक जीवन/उत्पादन परिदृश्य जिसके खिलाफ मैं आया हूं, एक मध्यवर्ती कंटेनर में कठपुतली प्रावधान के साथ निर्मित डॉकर छवियां हैं। कुछ सेवाओं पर जिन्हें उन्नत क्षमताओं की आवश्यकता होती है, निर्माण में विफलताओं के कारण कंटेनर को -privileged तहत ENTRYPOINT या CMD साथ चलाने की आवश्यकता होती है जो कठपुतली स्क्रिप्ट को फिर से लागू करता है।

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

मुझे आशा है कि उपरोक्त समझ में आता है।

@jpetazzo मैं @PerilousApricot के मुद्दे के समान है।

बीटीडब्ल्यू: मैं नकली iptables जैसे हैक्स को लागू करने के लिए नहीं हूं।

@pmoust : क्या आपके पास विवरण है कि किस निर्माण संचालन के लिए उन्नत विशेषाधिकारों की आवश्यकता है? मैं शायद इस मुद्दे को चकमा देने की सिफारिश करूंगा, और मुझे पूरी तरह से एहसास है कि यह आपके लिए संतोषजनक नहीं हो सकता है; लेकिन फिर भी, मुझे यह समझने में खुशी होगी कि किस प्रकार के इंस्टॉलर/बिल्डर को उन विशेषाधिकारों की आवश्यकता हो सकती है ...

@ Passion4aix : ध्यान दें कि यदि आप Dockerfile में iptables नियम सेट करते हैं, तो वे सहेजे नहीं जाएंगे। डॉकर केवल फाइल सिस्टम स्थिति को बचाता है, रूटिंग/फ़िल्टरिंग/रनिंग प्रक्रियाओं को नहीं ... "साइडकिक" कंटेनरों के साथ iptables नियमों को सेटअप करने के तरीके हैं। क्या ऐसा कुछ है जो आपके लिए दिलचस्प हो सकता है?

@jpetazzo Bitrock इंस्टालर एक उदाहरण है। इसे /tmp को tmpfs के रूप में माउंट करने की आवश्यकता है। आप http://answers.bitrock.com/questions/3092/running-installer-inside-docker पर एक नज़र डालना चाहेंगे

@jpetazzo या मूल रूप से कोई ओपनस्टैक इंस्टॉलर

जब मैं TokuMX को Docker कंटेनर में चलाने का प्रयास कर रहा था, तब भी मैं भी इसी तरह की समस्या में भाग गया था, क्योंकि TokuMX को अक्षम करने के लिए 'transparent_hugepage' कर्नेल विकल्प की आवश्यकता होती है।

क्या इस मुद्दे पर कोई प्रगति हुई है? यह पहले से ही एक वर्ष से अधिक पुराना है और टिप्पणियों को देखते हुए, अधिकांश लोगों ने डॉकरफाइल से विशेषाधिकार प्राप्त कार्यों को चलाने के लिए उपयोग किया है।

व्यक्तिगत रूप से मैं '--विशेषाधिकार प्राप्त' समाधान के साथ निर्माण का विकल्प नहीं चुनूंगा। RUNP समाधान तब से बेहतर है जब से आप संपूर्ण स्थापना को विशेषाधिकार के रूप में चलाने के बजाय केवल विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में कुछ क्रियाएं चला सकते हैं। इस तरह आपको कम से कम यह सोचना होगा कि RUNP का उपयोग कब करना है और आवश्यकता पड़ने पर ही इसका उपयोग करना है।

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

@diversit उन्हें युग्मित करना होगा। तो कमांड लाइन पर --privileged उपयोग करने की क्षमता को सक्षम करेगा RUNP , अन्यथा यह अविश्वसनीय कोड (डॉकरहब सहित) का निर्माण करने वाले लोगों के लिए एक सुरक्षा दुःस्वप्न होगा।

लेकिन यह भी ध्यान रखें, आप इसे डॉकरफाइल सिंटैक्स के बाहर मैन्युअल रूप से कर सकते हैं। निर्माण प्रक्रिया डॉकरफाइल को पढ़ रही है, इससे एक कंटेनर बना रही है, और इसे एक छवि पर वापस भेज रही है।

@deas : मुझे लगता है कि इसे VOLUME /tmp करके हल किया जा सकता है।

@PerilousApricot : क्या आप थोड़ा विस्तार कर सकते हैं? मुझे समझ में नहीं आता कि किसी भी प्रकार के इंस्टॉलर को विशेष विशेषाधिकारों की आवश्यकता क्यों होगी। (हाँ, मैं एक पुराना जिद्दी यूनिक्स लड़का हूं, यह मेरी खामियों में से एक है: डी)

@diversit : उस विशिष्ट मामले के लिए, मुझे लगता है कि मशीन के व्यवस्थापक को निर्माण से पहले पारदर्शी विशाल पृष्ठों को अक्षम करना चाहिए। क्योंकि अगर बिल्डर को ऐसा करने की अनुमति दी जाती है, तो वह इसे विश्व स्तर पर (दाएं?) क्या तुमने देखा कि मेरा क्या मतलब है? यह बुरा होगा यदि कंटेनर X का निर्माण चल रहे कंटेनर Y को तोड़ देता है ...

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

@jpetazzo कई/अधिकांश ओपनस्टैक परिनियोजन उपकरण (उदा. https://openstack.redhat.com/Main_Page) iptables नियम सेट करता है। मैं एप्लिकेशन के कंटेनरीकृत संस्करणों को रोल/तैनाती करने में सक्षम होना चाहता हूं, इसलिए डॉकरफाइल बनाने और इसे एक बार में करने में सक्षम होना मेरे लिए महत्वपूर्ण है। मुझे पता है कि iptables नियम मूल रूप से कंटेनरीकरण प्रक्रिया के माध्यम से संरक्षित नहीं हैं, लेकिन वे iptables-save के माध्यम से बने रहते हैं, इसलिए CMD प्रक्रिया में एक साधारण iptables-restore नियमों को फिर से लोड करने का कारण बनेगा। यह सिर्फ "स्टब आउट" iptables के लिए बहुत अधिक जटिल है क्योंकि बहुत से परिनियोजन उपकरण वास्तविक परिनियोजन करने के लिए कठपुतली या शेफ जैसे सीआई उपकरण का उपयोग करते हैं, इसलिए आपको किसी भी तरह एक संगत स्टब बनाने की आवश्यकता होगी जो सभी का अनुकरण करेगा "असली" iptables कमांड में इनपुट/आउटपुट।

इसके अलावा, मुझे लगता है कि यह कहना उचित है, "यदि आपके पास एक डॉकरफाइल है जिसे विशेषाधिकार प्राप्त बिल्ड की आवश्यकता है, तो आप एक्स, वाई, जेड सुविधाओं को खो देते हैं"

Oracle xe पर्याप्त साझा मेम स्थान के बिना नहीं चलेगा। सभी खाते हैं कि enuf स्पेस के साथ tmpfs को रिमाउंट करना Oracle xe को स्टार्टअप के लिए खुश करता है और इसके कॉन्फ़िगरेशन को पूरा करता है। माउंट का आकार बढ़ाकर काबू पाने की अफवाह)

एक निर्माण के दौरान
रन अनमाउंट tmpfs
के साथ विफल
umount: /proc/kcore: umount करने के लिए सुपरयूज़र होना चाहिए

मुझे RUNP दो या मुझे मौत दो .... या .... मुझे दिखाओ कि अलग तरीके से क्या किया जा सकता है :)

मेरा उदाहरण अमान्य है; @jpefazzo अभी भी खड़ा है :) मेरी Oracle सेटिंग्स परेशानी पैदा कर रही थीं और ऐसा प्रतीत होता है कि tmpfs आकार को समायोजित करने की कोई आवश्यकता नहीं है ... कम से कम प्रारंभिक स्थापना के लिए।

मैं CentOS 7.0 में एक iptables मुद्दे में चल रहा हूं जो केवल run साथ --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 मुझे विश्वास है कि #8299 में जोड़े गए security-opts साथ --privileged बिना ऐसा करना संभव होगा

@jpetazzo मैं नहीं देखता कि VOLUME /tmp का उपयोग करने से Bitrock Installers की समस्या कैसे हल हो जाती है। यह निर्माण के लिए काम कर सकता है, लेकिन यह उस छवि के आधार पर सभी कंटेनरों के लिए /tmp बायपास AUFS लेयरिंग भी करेगा, है ना? दिन के अंत में, ऐसा लगता है कि AUFS में मूल कारण तय किया जाना चाहिए।

यहां मेरा उपयोग मामला है: मैं एक डोकर कंटेनर के अंदर एक चेरोट वातावरण बनाना चाहता हूं। समस्या यह है कि debootstrap नहीं चल सकता, क्योंकि यह chroot में proc को माउंट नहीं कर सकता है:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
अगर मैं कंटेनर run --privileged हूं, तो यह (बेशक) काम करता है ...
मैं वास्तव में वास्तव में डॉकरफाइल (बहुत अधिक क्लीनर) में चेरोट को डीबूटस्ट्रैप करना चाहता हूं। क्या कोई तरीका है जिससे मैं इसे काम पर ला सकता हूं, बिना RUNP या बिल्ड --विशेषाधिकार की प्रतीक्षा किए?

बहुत - बहुत धन्यवाद!

+1 के लिए --विशेषाधिकार प्राप्त या माउंटिंग। Glusterfs के निर्माण को स्वचालित करने की आवश्यकता

यह बिटनामी टॉमकैट इंस्टॉलर से एक छवि बनाने के मेरे प्रयासों को प्रभावित कर रहा है। स्थापना प्रक्रिया का 99% बिना किसी समस्या के चलता है, लेकिन जब यह पहली बार टॉमकैट शुरू करने का प्रयास करता है, तो यह catalina-daemon.out में निम्न आउटपुट के साथ विफल हो जाता है:

set_caps: क्षमताओं को सेट करने में विफल
जांचें कि आपका कर्नेल क्षमताओं का समर्थन करता है
उपयोगकर्ता 'टोमकैट' के लिए set_caps (CAPS) विफल
4 . के वापसी मूल्य के साथ सेवा से बाहर निकलें

मैं सफलतापूर्वक टॉमकैट इंस्टॉलर को एक कंटेनर में मैन्युअल रूप से चला सकता हूं जिसे मैं "--cap-add ALL" के साथ बनाता हूं। यह अजीब लगता है कि मैं एक छवि बनाने के लिए 'डॉकर बिल्ड' का उपयोग नहीं कर सकता जिसे मैं 'डॉकर रन' और फिर 'डॉकर कमिट' का उपयोग करके मैन्युअल रूप से बना सकता हूं। निर्माण प्रक्रिया के दौरान उपयोग किए जाने वाले कंटेनरों में सभी कार्यक्षमता होनी चाहिए क्योंकि कंटेनर आप 'डॉकर रन' का उपयोग करके बना सकते हैं।

@gilbertpilz निर्माण पोर्टेबिलिटी और सुरक्षा सुनिश्चित करने के लिए वे बहुत स्पष्ट रूप से ऐसा नहीं कर सकते हैं।

@ cpuguy83 - इसका कोई मतलब नहीं है। यदि मैं ऐसा करूं, तो मैं हाथ से अपनी मनचाही छवि बना सकता हूं:

docker run --cap-add ALL .... /bin/bash
बिटनामी-टॉमकैटस्टैक-7.0.56-0-लिनक्स-x64-इंस्टालर.रन ...
बाहर जाएं
डॉकर प्रतिबद्ध ....

मैं केवल वही काम करने के लिए "डॉकर बिल्ड" का उपयोग करने की क्षमता मांग रहा हूं जो मैं यहां मैन्युअल रूप से कर रहा हूं। मैं यह देखने में विफल रहता हूं कि कैसे "पोर्टेबिलिटी और सुरक्षा" को "सुनिश्चित" किया जा रहा है यदि मैं छवि को एक तरह से बना सकता हूं लेकिन दूसरा नहीं।

ठीक है, मैं आपको एक डॉकरफाइल देता हूं जो मेजबान के /etc/passwd को बिल्डर में माउंट करता है और बस इसे मेरे पास भेजने के लिए होता है।

यह सामान खतरनाक हो सकता है।
यह भी ध्यान दें कि --विशेषाधिकार प्राप्त (और --cap-add ALL) उपयोगकर्ता को कंटेनर में होस्ट का पूर्ण नियंत्रण देता है।

इन चीजों को अनुमति देने से DockerHub की संपूर्णता से समझौता हो जाएगा

@ cpuguy83 - आपको

लेकिन आप किसी को सुडो नहीं देंगे कि आप राज्य की चाबियों के साथ अजीब तरह से भरोसा नहीं करते हैं।
बिल्ड को यथासंभव सुरक्षित रूप से अविश्वसनीय कोड चलाने में सक्षम होना चाहिए।

बिल्ड पर अतिरिक्त सुविधाओं को सक्षम करने के लिए CLI फ़्लैग्स का परिचय बिल्ड की पोर्टेबिलिटी को तोड़ता है, और इसीलिए इसे अभी तक जोड़ा नहीं गया है।

उस ने कहा, इंस्टॉलर लगभग निश्चित रूप से गलत है, यहां उन चीजों का अनुरोध करना है जिनके पास खुद तक पहुंच नहीं होनी चाहिए।

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

आप बड़ी तस्वीर नहीं देख रहे हैं।

इस पारिस्थितिकी तंत्र में आपके सर्वर और मेरे सर्वर से कहीं अधिक है। उदाहरण के लिए, डॉकरहब हर समय अविश्वसनीय कोड बनाता है।

तब DockerHub को निश्चित रूप से _not_ इसके निर्माण के लिए क्षमताओं को जोड़ने में सक्षम होना चाहिए। अगर इसका मतलब है कि मैं अपने डॉकटर बिल्ड को डॉकरहब तक नहीं बढ़ा सकता, तो मैं इसके साथ ठीक हूं।

@cpuguy83 @tianon @jpetazzo -- जब FUD शुरू होता है, तो मुझे बोलने के लिए मजबूर होना

इन चीजों को अनुमति देने से DockerHub की संपूर्णता से समझौता हो जाएगा

सरसली?
इस सुविधा को लागू करना == TEOTWAWKI ?

बेशक डॉकरहब कभी भी अनुरोधित --privileged ध्वज के साथ docker build नहीं चलाएगा।
बहुत अधिक विचार किए बिना, इसे लागू करने के कम से कम दो स्पष्ट तरीके हैं:

• ध्वज केवल तभी काम करता है जब आप docker -d को कुछ नए ध्वज के साथ लॉन्च करते हैं जैसे: --i-want-a-broken-security-model
• एक संकलन-समय ध्वज बनाएं जो कोड पथ को सक्षम करता है।

कुल मिलाकर कार्यान्वयन के खिलाफ इंजीनियरिंग-आधारित-कारणों के दांतों को पीसने का अनुपात वास्तव में यहां बहुत अधिक लगता है।

@tamsky और फिर हमारे पास ऐसी स्थिति है जहां एक जगह काम करता है लेकिन दूसरी जगह नहीं।
मैं समझा रहा हूं कि चीजें वैसी क्यों हैं जैसी वे हैं, न कि किसी एक मामले या दूसरे पर बहस करना।

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

@cpuguy83

और फिर हमारे पास एक ऐसी स्थिति है जहां निर्माण एक जगह पर काम करता है लेकिन दूसरी जगह नहीं।

कृपया एक पल के लिए कल्पना करें कि हमें जादुई रूप से एक ऐसी दुनिया में ले जाया गया है जहां _policy_ अलग है, और कुछ एक जगह पर काम करते हैं लेकिन दूसरी जगह नहीं...

यह इतनी बड़ी बात क्यों है?
वास्तव में कौन परवाह करता है?

क्या डॉकर इंक ने माना है कि "सभी बिल्डों को हर जगह काम करना चाहिए" की उनकी सबसे कम-सामान्य-भाजक-मंत्र/आवश्यकता वास्तव में वास्तविक ग्राहक आवश्यकता को अनदेखा कर रही है?

वर्तमान में नीति ग्राहकों के लिए "डॉकर में निर्माण करने के लिए एक्स प्राप्त करने" के लिए इंजीनियरिंग लागत को बाहरी कर रही है:

डॉकर में इस सुविधा को प्रदान करने के बजाय, आप दुनिया में हर तीसरे पक्ष की परियोजना को मजबूर कर रहे हैं जिसे "किसी भी प्रकार की विशेषाधिकार प्राप्त पहुंच की आवश्यकता नहीं है" (लेकिन वास्तव में करता है), पहले डॉकर बिल्ड केस को संभालने के लिए अद्यतन या बंदरपैच किया जाना चाहिए।

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

यह कहना है, @ cpuguy83 , हम हमेशा यह नहीं मान सकते कि Dockerfiles सार्वभौमिक रहेगा। हालांकि, मैं मानता हूं कि हमें उनके बीच कितना अंतर है, इसे कम करने की जरूरत है। यह उन उपयोगकर्ताओं के लिए विचार करने योग्य हो सकता है जो इस सुविधा को चाहते हैं, जो कि खतरनाक है, बातचीत में जो अंततः मल्टी-आर्क / मल्टी-प्लेटफ़ॉर्म समर्थन के आसपास होने की आवश्यकता होती है।

बिल्ड हर जगह काम नहीं कर रहे हैं क्योंकि उदाहरण के लिए लोड किए गए ऐप आर्मर प्रोफाइल।
इसके अलावा आप एक छवि में बेक किए गए पूर्व कैश्ड डॉकटर कंटेनरों के मामले को कैसे करेंगे?

18. 11. 2014, 2:53 पर पर, tamsky [email protected] लिखा है:

@cpuguy83

और फिर हमारे पास एक ऐसी स्थिति है जहां निर्माण एक जगह पर काम करता है लेकिन दूसरी जगह नहीं।

कृपया एक पल के लिए कल्पना करें कि हमें जादुई रूप से ऐसी दुनिया में ले जाया गया है जहां नीति अलग है, और कुछ एक जगह काम करते हैं लेकिन दूसरी जगह नहीं ...

यह इतनी बड़ी बात क्यों है?
वास्तव में कौन परवाह करता है?

क्या डॉकर इंक ने माना है कि "सभी बिल्डों को हर जगह काम करना चाहिए" की उनकी सबसे कम-सामान्य-भाजक-मंत्र/आवश्यकता वास्तव में वास्तविक ग्राहक आवश्यकता को अनदेखा कर रही है?

वर्तमान में नीति ग्राहकों के लिए "डॉकर में निर्माण करने के लिए एक्स प्राप्त करने" के लिए इंजीनियरिंग लागत को बाहरी कर रही है:

डॉकर में इस सुविधा को प्रदान करने के बजाय, आप दुनिया में हर तीसरे पक्ष की परियोजना को मजबूर कर रहे हैं जिसे "किसी भी प्रकार की विशेषाधिकार प्राप्त पहुंच की आवश्यकता नहीं है" (लेकिन वास्तव में करता है), पहले डॉकर बिल्ड केस को संभालने के लिए अद्यतन या बंदरपैच किया जाना चाहिए।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

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

+1
मैं अपनी शेफ भूमिकाओं को डॉकटर में पोर्ट नहीं कर सकता क्योंकि वे सभी बंदरगाहों को खोलने के लिए ufw का उपयोग करना शामिल करते हैं।
जोड़ने के लिए --विशेषाधिकार प्राप्त करने से यह ठीक हो जाएगा।

+1। मेरे Dockerfiles में एक कदम के रूप में डीबूटस्ट्रैप नहीं हो सकता।

+1। मेरे Dockerfiles में एक कदम के रूप में डीबूटस्ट्रैप नहीं हो सकता।

डॉकरफाइल/बिल्ड के माध्यम से मेरे चेरोट का निर्माण करना स्वाभाविक लग रहा था लेकिन @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

RUNP बजाय क्या होगा, एक बिल्ड फ्लैग --insecure ।
सभी RUN कमांड के लिए, अगला कंटेनर --add-cap=all साथ चलाया जाएगा। विशेषाधिकार प्राप्त होने के बजाय यह विशेषाधिकार प्राप्त कुछ अन्य चीजें भी करता है ...
लेकिन वास्तव में यह ध्वज को संशोधित किए बिना किसी बिंदु पर आवश्यक होने पर पूर्ण privileged सेटिंग्स को लागू करने के लिए बदल सकता है।

@cpuguy83
मुझे डॉकर बिल्ड में पारित ध्वज का उपयोग करने में कोई फर्क नहीं पड़ता है जो रन कमांड को विशेषाधिकार प्राप्त करने में सक्षम बनाता है या आरयूएनपी कमांड को सक्षम बनाता है। 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

कौन सा सही उत्तर हो सकता है, लेकिन यदि एप्लिकेशन कंटेनर एक बाइंड माउंट निष्पादित कर सकता है तो आप एप्लिकेशन डेटा के लिए एक और कंटेनर बनाने के लिए समाप्त कर सकते हैं।

मैं आज कंटेनर को विशेषाधिकार प्राप्त मोड में चलाकर इसे प्राप्त कर सकता हूं और फिर माउंट बाइंड निष्पादित कर सकता हूं, लेकिन जैसा कि आप नीचे देखेंगे, उस माउंट बाइंड को बनाए रखने का कोई तरीका नहीं है और इसे हर बार कंटेनर शुरू करने पर रीसेट करना होगा . सिम्लिंक कमिट्स पर बने रहते हैं।

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

सुनिश्चित नहीं है कि यह संबंधित या अधिक बाइंड माउंट विशिष्ट समस्या है, लेकिन जब आप डॉकर कमिट करते हैं तो विशेषाधिकार प्राप्त कमांड के परिणाम बने रहते हैं, जिससे आप डॉकर छवि के निर्माण और डॉकर छवि के चलने को अलग कर सकते हैं। आप उस क्षेत्र को नियंत्रित कर सकते हैं जहां आप डॉकर बिल्ड करते हैं और अंतिम उपयोगकर्ताओं को केवल प्रतिबद्ध कंटेनर मिलता है जिसे वे अनपेक्षित मोड में चला सकते हैं। यह वर्तमान में कारण नहीं है जब आप एक बाइंड माउंट और कमिट निष्पादित करते हैं। हालांकि यह /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

सभी 3 निर्देशिकाओं से शो फ़ाइल देखी जाती है

[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

सिमलिंक बच गया, लेकिन माउंट को बांध नहीं पाया

[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 और फिर कंटेनर को कमिट करें

कंटेनर को नई छवि के रूप में प्रतिबद्ध करें, गैर-निजी मोड में छवि से नया कंटेनर प्रारंभ करें

[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, बस, 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

सिमलिंक बच गया

[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' चलाने के लिए करता हूं, ताकि मेरी प्रक्रियाओं के लिए क्षमताओं को बारीक रूप से सेट किया जा सके।

मैं यह नहीं कह सकता कि यह विशेषाधिकार प्राप्त बिल्ड के लिए सभी उपयोगकर्ता-मामलों को हल करेगा, लेकिन इससे आप में से कुछ की मदद करनी चाहिए।

मैं सहमत हूं कि यह खुद डॉकर का हिस्सा बन जाना चाहिए, और उपयोगकर्ता नामस्थानों का एकीकरण प्रगति पर है।

@saulshanabrook आप एक बिल्ड में डॉकर इमेज नहीं चला सकते, बिल्कुल नहीं। मुझे उम्मीद है कि एक दिन जल्द ही यह संभव होगा। मैंने इसकी कुछ जांच की है और पाया है कि जब तक आप वीएफएस स्टोरेज का उपयोग करते हैं, तब तक आप बिल्ड के भीतर से 'डॉकर पुल' कर सकते हैं। सुविधाजनक रूप से, 'डॉकर सेव' भी काम करता है।

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

RUNP . के माध्यम से डॉकर पुल के लिए +1

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

+1 यह किसी भी समय पर प्रतिलिपि प्रस्तुत करने योग्य डॉकटर कंटेनर बनाता है (केवल dockerfile को अकेले ले जाने की आवश्यकता है)

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

@lsjommer आपको किस तरह की चीजों के आसपास काम करना है? --विशेषाधिकार प्राप्त कंटेनर को चलाने का एक पूरी तरह से असुरक्षित तरीका है और कंटेनर में उपयोगकर्ता को होस्ट तक पूर्ण रूट एक्सेस देता है।

मैं यह नहीं कह रहा हूं कि आइए इसे लागू न करें, लेकिन हम जो बात कर रहे हैं उसके बारे में वास्तविक जानकारी प्राप्त करें।

इसके अलावा अगर कोई इसके लिए जाना चाहता है तो इसे लागू करना अपेक्षाकृत आसान होगा ...

@ cpuguy83 यह हमारी मानक "नंगे धातु" आधारभूत भूमिका से है जिसे मैं सभी libs स्थापित करने के लिए डॉकर कंटेनर में अपनाने की कोशिश कर रहा हूं, और यह साझा स्मृति से संबंधित है लेकिन शायद मुझे कंटेनर निर्माण पर इससे परेशान होने की भी आवश्यकता नहीं है और इसे केवल कंटेनर होस्ट पर चलाने की आवश्यकता है?
http://pastebin.com/P3QQxjNQ

मैं मानता हूं कि मैं पूरी तरह से नहीं समझता कि डॉकर संसाधन साझाकरण को कैसे संभालता है।

@ljsommer तो shm सेट करना एक साथ एक अलग जानवर है और वैसे भी RUN कमांड (या जब आप वास्तव में docker run ) के बीच जारी नहीं रहेगा।

@ cpuguy83 हाँ, मुझे लगता है कि इस संबंध में ज्यादातर मेरी गलती थी कि मैंने जो सोचा था वह एक मुद्दा था जिसे मैं केवल कंटेनर होस्ट के लिए बेसलाइन पर स्थानांतरित कर सकता हूं।
जवाब देने के लिए समय निकालने के लिए धन्यवाद और शिकायत करने से पहले खुद को उचित रूप से शिक्षित न करने के लिए क्षमा याचना।
;)

निर्माण प्रक्रिया के दौरान RUNP/-विशेषाधिकार प्राप्त पर कोई विचार?
निर्दिष्ट आईपी-पते तक डॉक एक्सेस को सीमित करने के लिए आईपी टेबल सेट करना बहुत अच्छा होगा

मुझे 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

यह डॉकरफाइल निम्नलिखित त्रुटि के कारण काम नहीं करता है, लेकिन "डॉकर रन --विशेषाधिकार प्राप्त" के साथ काम करता है ...

getsockopt failed strangely: Operation not permitted

@malcm , @ sakurai-youhei: भले ही आपके पास RUNP जैसा कुछ हो, यह इस परिदृश्य में काम नहीं करेगा, क्योंकि फाइल सिस्टम में iptables नियम कायम नहीं हैं।

मुझे समझाएं: जब आप RUN x , तो डॉकर x निष्पादित करता है और फिर फाइल सिस्टम का एक स्नैपशॉट लेता है। फाइल सिस्टम के बाहर की चीजें (चल रही प्रक्रियाएं, रूटिंग टेबल, iptables नियम, sysctl सेटिंग्स ...) डॉकर छवियों में संग्रहीत नहीं हैं।

यदि आप कस्टम iptables नियम चाहते हैं, तो एक विधि है:

• अपना कंटेनर शुरू करें जैसे --name myapp
• iptables नियम स्थापित करने के लिए एक और कंटेनर, विशेषाधिकार प्राप्त, एक-शॉट शुरू करें, उदाहरण के लिए docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

क्या इसका कोई मतलब है?

@jpetazzo : आपकी प्रतिक्रिया के लिए धन्यवाद। मेरे मामले में, मैंने iptables नियम को फ़ाइल सिस्टम पर डेटा के रूप में नीचे के रूप में जारी रखने के लिए दूसरा आदेश दिया। यह मुझे --विशेषाधिकार प्राप्त विकल्प के साथ कंटेनर शुरू करने के बाद iptables नियम लोड करने में सक्षम बनाना चाहिए।

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

RUNP के बिना और न ही "बिल्ड --विशेषाधिकार प्राप्त", मुझे इस तरह लिखने के लिए मजबूर किया जाता है:

ADD iptables.rules /etc/

हां, यह पर्याप्त हो सकता है, हालांकि, मुझे अपने रेपो में डॉकरफाइल के बगल में iptables.rules जोड़ने की जरूरत है।

इसलिए मैं चाहता हूं (या धीरे से करना चाहता हूं) RUNP। :)

@jpetazzo @strib
iptables मुद्दों, आरोह और अन्य विशेषाधिकार प्राप्त संचालन से परे, मुझे लगता है कि एक निर्माण परिदृश्य है जिसे हमें संबोधित करना चाहिए।

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

मेरे पास एक समस्या थी, जहां RHEL7 होस्ट पर चलते समय, su विफल हो जाएगा यदि वर्तमान उपयोगकर्ता रूट था। अजीब तरह से, यदि वर्तमान उपयोगकर्ता कुछ और था, तो su ने ठीक काम किया। भले ही, वर्कअराउंड रन कमांड को फ्लैग --add-cap=SYS_RESOURCE ; हालाँकि, इस समस्या के कारण, बिल्ड चरण के दौरान ऐसा करना संभव नहीं था।

+1 docker run और docker commit साथ Dockerfiles के आसपास स्क्रिप्टिंग हास्यास्पद है। कृपया इस कार्यक्षमता को शामिल करें।

+1 इस सुविधा की आवश्यकता पर। मुझे लगता है कि एक वैश्विक "सुरक्षा स्तर" को एक कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगर किया जा सकता है जो एक कंटेनर को दी जा सकने वाली क्षमताओं को सीमित करता है। एक सुरक्षित डिफ़ॉल्ट होना चाहिए (आज की तरह) और एक sysadmin कंटेनरों को अधिक विशेषाधिकारों के साथ चलाने की अनुमति देने के लिए इसे बदल सकता है। इस तरह के एक RUNP निर्देश के साथ dockerfiles एक संदेश के साथ चलने में विफल हो सकता है जैसे कि "इस डॉकरफाइल को निम्नलिखित क्षमताओं की आवश्यकता है .... निर्माण करने के लिए" एक ऐसी प्रणाली पर जिसकी ऐसी वैश्विक सीमाएँ हैं।

मुझे लगता है कि यह सुरक्षा और उपयोगिता के बीच संतुलन की अनुमति देता है।

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

हमारा वर्तमान वर्कअराउंड एक रन --विशेषाधिकार प्राप्त चरण और अलग प्रतिबद्ध चरण के साथ 2 चरणों का निर्माण है।

हो सकता है कि हम स्मृति आवंटन को किसी अन्य तरीके से अनुमति देने के लिए डॉकर को कॉन्फ़िगर कर सकें। यह पता लगाना थोड़ा मुश्किल है कि डीबी वास्तव में क्या करना चाहता है क्योंकि इसका स्वामित्व है।

+1
इस सुविधा के लिए।
ऐतिहासिक और उपयोग के मामले के उदाहरण के लिए यह डुप्ली देखें
https://github.com/docker/docker/issues/12138#issuecomment -90536998
धन्यवाद @ cpuguy83 डुप्ली को इंगित करने के लिए

मेरे पास भी यह समस्या है, डॉकर बिल्ड के दौरान एक सीआईएफ शेयर में शामिल होने की कोशिश करने की अनुमति नहीं है जब तक कि विशेषाधिकार प्राप्त ध्वज की आपूर्ति नहीं की जाती है, इसके आसपास किसी भी तरह से?

अब एक पुल अनुरोध है जो इसे लागू करता है; आप वहां प्रगति की जांच कर सकते हैं; https://github.com/docker/docker/issues/12261

अगर किसी चीज़ को विशेषाधिकार प्राप्त मोड की आवश्यकता होती है तो यह संभवतः किसी तरह से होस्ट को संशोधित कर रहा है, जिसका अर्थ है कि छवि पोर्टेबल नहीं हो सकती है क्योंकि इन संशोधनों को छवि का उपभोग करने की कोशिश कर रहे अन्य मेजबानों पर चलाने की आवश्यकता होगी।

एक बार #13171 विलय हो जाने के बाद, मुझे लगता है कि हमें इसे बंद कर देना चाहिए क्योंकि यह आपके स्वयं के निर्माता को छोटा कर देगा, और इस तरह अनुमति - विशेषाधिकार प्राप्त होगा।
मुझे नहीं लगता कि अंतर्निहित docker build को इसकी अनुमति देनी चाहिए।

तो @ cpuguy83 , अगर मैं सही समझता हूं, तो इस मुद्दे का समर्थन करने का तरीका docker build को पूरी तरह से लागू करना होगा लेकिन एक अतिरिक्त पैरामीटर के साथ?

मुझे लगता है कि, एक बार दूसरे पैच के माध्यम से धकेलने के बाद, मुझे अतिरिक्त कार्यक्षमता को भरने के लिए docker build (शायद docker pbuild ?) का अपना संस्करण एक साथ रखना होगा?

क्या इस मुद्दे पर कोई प्रगति हुई है? मैंने ऊपर उल्लिखित पीआर की जाँच की और वे सभी विफल रहे।
क्या BUILD --privileged/--granted विकल्प को अधिक विस्तृत बनाना संभव है और केवल छवि निर्माता/स्वामी तक सीमित होस्ट संसाधनों के एक विशिष्ट समूह तक पहुंच प्रदान करना संभव है?

+1 किसी भी समाधान के लिए जो मुझे डॉकरफाइल में RUN docker pull करने की अनुमति देता है।

केस का उपयोग करें: मुझे छवि रूपांतरण और प्रलेखन निर्माण के लिए उपकरणों का एक समूह चाहिए, हालांकि, इन सभी उपकरणों को परस्पर विरोधी पुस्तकालयों के कारण एक ही छवि में स्थापित नहीं किया जा सकता है। इसलिए मैं इनमें से कुछ टूल्स को एक अलग इमेज में अलग करता हूं और मैं सभी टूल्स को एक इमेज में वितरित करना चाहता हूं, यानी इमेज में इमेज। इसलिए मैं अपने Dockerfile में RUN docker pull चाहता हूं।

@ cpuguy83 ऐसा नहीं लगता कि इस मुद्दे को किसी की संतुष्टि के लिए हल किया गया था। मैं पूरी तरह से, 100%, एक निर्माण के दौरान /proc/sys/kernel/core_pattern लिखने के समान नीरस कुछ करने में सक्षम होने की आवश्यकता है।

वर्तमान दुनिया में, मैं इस विशेषाधिकार प्राप्त ऑपरेशन को run वर्कअराउंड के माध्यम से कर सकता हूं और वैसे भी उस छवि को हब में धकेल सकता हूं। इसके अतिरिक्त, नहीं Dockerfile मेरे पास _ever_ उत्पादित सख्ती से प्रतिलिपि प्रस्तुत करने योग्य है, क्योंकि वे यादृच्छिक रूप से लगातार बदलते सार्वजनिक रेपो से खींचते हैं। मुझे नहीं पता था कि

1. मेरी छवियों का सार्वजनिक उपभोग प्राथमिकता थी।
2. उन्हें कभी भी, प्रतिलिपि प्रस्तुत करने योग्य होने की कोई आवश्यकता थी।

निर्माण में privileged प्राप्त करने के लिए लोग _going_ कर रहे हैं। मुझे लगता है कि आपको निश्चित रूप से जाना चाहिए जहां आपके उपयोगकर्ता हैं और इसे कोर बिल्ड टूल में अनुमति दें। यदि आवश्यक हो तो एक भयानक संदेश जोड़ें।

cc @thaJeztah , जो इस पद के प्रति सहानुभूति रखते हैं

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

ऐसा लग रहा था कि आपने अंतिम कॉल कर दी है। मैं तब पीआर थ्रेड में ही आंदोलन करूंगा।

CentOS के तहत पुराने JDK 1.6 पैकेजों को स्थापित करने के लिए इसकी आवश्यकता है क्योंकि इसके RPM को पंजीकृत करने का प्रयास binmft_misc है जो बिना - विशेषाधिकार के चलने में विफल रहता है।

इसके साथ कंटेनर बनाने के लिए डॉकरबिल्ड एक गैर-स्टेटर है।

नकल बनाना

सेंटोस5.11 . से
रन यम intall -y jre-1.6.0_29-fcs

हमें वैकल्पिक ध्वज के रूप में बिल्ड के विशेषाधिकार प्राप्त कमांड भाग की आवश्यकता है। मैं अपने आवेदन में से एक को पीओसी के रूप में डॉक करने के लिए पोर्ट करने की कोशिश कर रहा हूं और यह हमारे एक घटक के लिए विफल रहता है क्योंकि इसमें आईपीटेबल्स सेटिंग्स हैं जिन्हें लागू नहीं किया जा रहा है और निर्माण विफल हो जाता है। मैं आवश्यक परिवर्तन मैन्युअल रूप से कर सकता हूं और इसे प्रतिबद्ध कर सकता हूं लेकिन फिर डॉकर बिल्ड का मजा क्या है। यह निर्माण का सिर्फ एक हिस्सा है और इसे पोर्ट करना आसान होना चाहिए क्योंकि यह पहले से ही मुख्य रिलीज का हिस्सा है।

डॉकर आसानी से विशेषाधिकार प्राप्त विकल्प सेट के साथ मध्यवर्ती कंटेनर चलाने में सक्षम होना चाहिए।

@shubhamrajvanshi हम "बिल्डर" को डेमॉन (और क्लाइंट के लिए) से बाहर ले जाने की प्रक्रिया में हैं, इससे बिल्ड प्रक्रिया (कस्टम बिल्डरों को लागू करने में सक्षम होने सहित) के लिए और अधिक अनुकूलन के लिए दरवाजा खोलना चाहिए। संभवतः "विशेषाधिकार प्राप्त" बिल्ड की अनुमति पर विचार किया जा सकता है, लेकिन यह एक ऐसा निर्णय है जिसे रिफैक्टरिंग के बाद किया जा सकता है। (देखें https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@ शुभमराजवंशी आप एक अच्छे कारण के लिए निर्माण में iptables में बदलाव नहीं कर सकते, सेटिंग्स कभी नहीं

बहुत कम चीजें हैं जो कोई कर सकता है --विशेषाधिकार प्राप्त जो निर्माण में भी समझ में आता है।

@thaJeztah धन्यवाद यह मददगार होगा।
@ cpuguy83 क्या ऐसा होगा, भले ही मैं छवि पर iptables-persistent package का उपयोग कर रहा हूं।

यह नियमों को डिस्क पर सहेज लेगा, फिर भी उन्हें दुर्भाग्य से पुनः लोड करना होगा।

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

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

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

@karelstriegel

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

डिफ़ॉल्ट रूप से हमेशा बिल्ड पर विशेषाधिकार प्राप्त मोड का समर्थन क्यों नहीं करते?

+1
मैं Centos7 के लिए Dockerfile में mysql कमांड का उपयोग करना चाहता हूं।
बेशक हम entrypoint.sh का उपयोग कर सकते हैं लेकिन यह अधिक उपयोगी है यदि हम निर्माण और चलाने दोनों के लिए -विशेषाधिकार का उपयोग कर सकते हैं।

MySQL कमांड को चलाने के लिए --विशेषाधिकार प्राप्त करने की कोई आवश्यकता नहीं है।

इस मुद्दे को बंद कर दिया जाना चाहिए क्योंकि ऐसा नहीं लगता कि ऐसा होने वाला है (या होना भी चाहिए)।
बिल्ड में विशेषाधिकार देने का मतलब है कि बिल्डर को मेजबान पर चीजों को बदलने की इजाजत देता है जो बदले में ऐसा करता है कि छवि केवल उस होस्ट पर काम करती है (या मेजबान जिनके समान संशोधन होते हैं)।

बिल्ड में विशेषाधिकार देने का मतलब है कि बिल्डर को मेजबान पर चीजों को बदलने की इजाजत देता है जो बदले में ऐसा करता है कि छवि केवल उस होस्ट पर काम करती है (या मेजबान जिनके समान संशोधन होते हैं)।

क्या यह चेरोट उपयोगकर्ता मामले पर लागू होता है?

मैं इस तरह से कुछ के बिना dpkg-depcheck -d ./configure कैसे करना है यह जानने की कोशिश कर रहा हूं।

निर्माण के दौरान (या बिना --privedged के चलाएँ) मुझे नीचे त्रुटि मिलती है - मुझे नहीं पता कि इसे किस अनुमति की आवश्यकता है या इसे कैसे सक्षम किया जाए।

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 टिप्पणियों के बाद, मुझे लगता है कि इसे करने के लिए पर्याप्त रुचि है। एक विशेषाधिकार प्राप्त मोड के बारे में टिप्पणियां अधिकांश उद्धृत मामलों के लिए आवश्यक नहीं हैं, यहां तक ​​​​कि मेरी भी हैं; लेकिन स्थानीय, अस्थायी, खोजपूर्ण, और/या समीचीन निर्माण के लिए क्या उपयोगी हो सकता है, इसके खिलाफ मुकदमा चलाने के लिए उपयोग नहीं किया जाना चाहिए। तब तक चेतावनियाँ प्रकाशित करें जब तक कि गायों में सामंजस्य न हो, कमांड लाइन चेतावनियों का प्रिंट आउट लें, इसके उपयोग की निंदा और निंदा करें, लेकिन लोगों को लचीलापन दें। पोर्टेबिलिटी हमेशा हर किसी का प्राथमिक हित नहीं होता है।

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

_अपडेट की सूचना पाने का सबसे अच्छा तरीका इस पेज पर _सदस्यता लें_बटन का उपयोग करना है।

कृपया मुद्दों पर "+1" या "मेरे पास यह भी है" टिप्पणियों का उपयोग न करें। हम स्वचालित रूप से
सूत्र को छोटा रखने के लिए उन टिप्पणियों को एकत्रित करें।

नीचे सूचीबद्ध लोगों ने +1 टिप्पणी देकर इस मुद्दे को ऊपर उठाया है:

@robeferre

+1

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

+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

मैं निर्माण के दौरान डोकर में gentoo प्रणाली में gobject-आत्मनिरीक्षण स्थापित करने की कोशिश कर रहा हूँ, लेकिन यह इस त्रुटि के साथ विफल रहता है:

• ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): ऑपरेशन की अनुमति नहीं है

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

वही समस्या जब मैं ग्लिबक स्थापित करने का प्रयास करता हूं।

इसलिए मुझे निर्माण के दौरान विशेषाधिकार प्राप्त कमांड को चलाने का एक तरीका भी चाहिए।

मैं डोकर संस्करण 1.10.1 का उपयोग कर रहा हूँ और glibc के साथ समस्या 1.9 . में प्रकट नहीं होता है

संस्करण 1.10 में कुछ टूटा हुआ है, हम 32 बिट कंटेनर नहीं बना सकते, क्योंकि नेटवर्किंग अनुपलब्ध है
--विशेषाधिकार प्राप्त या --security-opt seccomp:unconfined for BUILD - वास्तव में आवश्यक है।
या Dockerfile में संबंधित निर्देश

मेरी ओर से बड़ा +1

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

मेरे उपयोग के मामले में मुझे छवि में कुछ सामग्री को बिल्ड संदर्भ में कॉपी किए बिना स्थापित करने और इसे स्थापित करने से पहले इसे जोड़ने की आवश्यकता है।

ऐसा लगता है कि मेरे पास कोई विकल्प नहीं बचा है।

thaJeztah ने 10 मार्च को इस मुद्दे का हवाला दिया
1.10.2 #20818 में अपग्रेड करने के बाद LTTng व्यवहार में प्रतिगमन बंद

नहीं, यह बंद नहीं है, हम 1.11.0-0 ~ विली का उपयोग कर रहे हैं और 32 बिट कंटेनरों में 1.10.0 के बाद से काम नहीं कर रहा है, लेकिन 1.9.x ने अच्छा काम किया है।
केवल-विशेषाधिकार प्राप्त ही हमें कंटेनर शुरू करने में मदद कर सकते हैं। लेकिन हम नया नहीं बना सकते

मुझे आश्चर्य है कि इतने सारे लोगों द्वारा स्पष्ट रूप से आवश्यक कुछ को लागू नहीं किया गया है, भले ही लोग 2.5 साल से इसके लिए अकेले इस धागे में भीख मांग रहे हैं और यह देखते हुए कि लोगों ने इस कार्यक्षमता को लागू करने के लिए पीआर जमा कर दिए हैं।

सहमत @ctindel , यह समस्या एक कारण है कि मैं rkt पर माइग्रेट कर रहा हूं।

@ctindel यह ऐसा कुछ है जिसे हम लागू करने या समर्थन करने के लिए तैयार नहीं हैं। कार्यान्वयन स्वयं ही सरल है (मैंने इसे स्वयं भी लागू किया ताकि हम चर्चा कर सकें), यह मुद्दा नहीं है।

--privileged एक टैंक है, और इसे निर्माण पर अनुमति देना खतरनाक है, और छवि पोर्टेबिलिटी को बहुत प्रभावित करता है।

ब्रायन,

यदि आपके पास कोई कामकाज है तो क्या आप कृपया इसे मेरे साथ भी साझा कर सकते हैं। मैं करूँगा
की सराहना करे।

धन्यवाद
शुभम राजवंशी
669-300-8346

सोम, 2 मई 2016 को दोपहर 2:30 बजे, ब्रायन गोफ नोटिफिकेशन @github.com ने लिखा:

@ctindel https://github.com/ctindel यह कुछ ऐसा है जिसके लिए हम तैयार नहीं हैं
लागू करना या समर्थन करना। कार्यान्वयन स्वयं ही सरल है (मैं भी
इसे स्वयं लागू किया ताकि हम चर्चा कर सकें), यह मुद्दा नहीं है।

--विशेषाधिकार प्राप्त एक टैंक है, और इसे निर्माण पर अनुमति देना खतरनाक है, और
छवि पोर्टेबिलिटी को बहुत प्रभावित करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/1916#issuecomment -216369957

मैं सुवाह्यता पर प्रभाव को नहीं समझता। बिल्ड समय पर विशेषाधिकार प्राप्त संचालन पोर्टेबिलिटी को कैसे प्रभावित करते हैं? मेरा मतलब है, गैर-पोर्टेबल छवियों को विशेषाधिकार के साथ या बिना विभिन्न तरीकों से बनाना मुश्किल नहीं है, लेकिन क्या कोई तरीका है कि विशेषाधिकार प्राप्त संचालन के साथ बनाई गई छवियां अनिवार्य रूप से गैर पोर्टेबल हैं?

मुझे विश्वास नहीं है कि प्रत्येक कंटेनर पोर्टेबल होना चाहिए। कुछ कंटेनर समुदाय के साथ साझा करने के लिए बनाए गए हैं और कुछ आंतरिक अनुप्रयोगों को परिनियोजित करने के लिए बनाए जा सकते हैं।

एक ऐप के साथ पोर्टेबिलिटी की समस्या जिसके लिए विशेषाधिकार प्राप्त मोड में चलने की आवश्यकता होती है, ऐप में ही निहित है।

विशेषाधिकार मोड उन्हें बिना कोड परिवर्तन के ऐप को काम करने के लिए अंतिम उपाय का साधन है।

मेरा मानना ​​​​है कि एक छवि निर्माता जिसे विशेषाधिकार प्राप्त मोड निर्माण की आवश्यकता होती है, वह समझता है कि ऐसे कंटेनर को विशेषाधिकार प्राप्त मोड में चलाने की भी आवश्यकता हो सकती है।

यह स्पष्ट रूप से प्रलेखित किया जाना चाहिए कि विशेषाधिकार प्राप्त मोड में निर्माण को हतोत्साहित किया जाता है क्योंकि यह पोर्टेबिलिटी की समस्या पैदा कर सकता है।

आउटलुक मो बाइलhttps://aka.ms/blhgte . से भेजा गया

सोम, 2 मई, 2016 को 2:53 PM पर -0700 पर, "ट्रेवर ब्लैकवेल" < [email protected] [email protected] > ने लिखा:

मैं सुवाह्यता पर प्रभाव को नहीं समझता। बिल्ड समय पर विशेषाधिकार प्राप्त संचालन पोर्टेबिलिटी को कैसे प्रभावित करते हैं? मेरा मतलब है, गैर-पोर्टेबल छवियों को विशेषाधिकार के साथ या बिना विभिन्न तरीकों से बनाना मुश्किल नहीं है, लेकिन क्या कोई तरीका है कि विशेषाधिकार प्राप्त संचालन के साथ बनाई गई छवियां अनिवार्य रूप से गैर पोर्टेबल हैं?

आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/docker/docker/issues/1916#issuecomment -216375159

@tlbtlbtlb क्योंकि विशेषाधिकार प्राप्त मोड आपको होस्ट तक पूर्ण पहुंच प्रदान करता है। हो सकता है कि मैंने कुछ सरल जैसे शममैक्स या कुछ और भी बदतर सेट किया हो।
मैं गारंटी देता हूं कि ये चीजें 1 दिन पर होंगी कि यह उपलब्ध है।

@ davidl-zend "पोर्टेबल" का मतलब समुदाय के साथ साझा करना नहीं है। इसका अर्थ है एक मशीन से दूसरी मशीन में जाना।

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

विभिन्न मंचों पर मैंने जो टिप्पणियां देखी हैं, उन्हें देखते हुए मैं शर्त लगाने को तैयार हूं कि बहुत से लोग पहले से मौजूद डॉकर सीमा के आसपास काम करने के लिए पहले से ही ऐसा कर रहे हैं।

एक बार जब आपके पास एक आर्किटेक्चर होता है जहां छवि पोर्टेबिलिटी दर्जनों अन्य तरीकों से टूट जाती है, तो इस विशिष्ट पवनचक्की के खिलाफ झुकाव का क्या मतलब है?

स्पष्ट रूप से आप अब अपनी छवि बनाने के लिए डॉक हब या ट्रैविस-सीआई नहीं कर पाएंगे, लेकिन जिन लोगों को इसे विशेषाधिकार मोड के साथ बनाने की आवश्यकता है, वे वैसे भी इसे समझेंगे।

@ctindel मुझे छवि पोर्टेबिलिटी के टूटने के कुछ उदाहरण देखना अच्छा लगेगा

पहली बार कंटेनर शुरू होने पर इस तरह की चीजें करना _exactly_ जाने का सही तरीका है।
यह एक रनटाइम कॉन्फ़िगरेशन है जो छवि में नहीं होना चाहिए।

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

मैं टेस्टी होने की कोशिश नहीं कर रहा हूं, मैं सिर्फ इतना कह रहा हूं कि यह प्लेटफॉर्म पर एक गंभीर सीमा है कि लोग अजीब तरीके से काम कर रहे हैं।

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

@ctindel मैं इस पर बिल्कुल भी बहस नहीं कर रहा हूं। अंतर व्यवहार का समर्थन कर रहा है। यदि कोई अंतर नहीं होता, तो हम यह चर्चा नहीं करते।

मेरे लिए, मैं एक सहमति देने वाला वयस्क हूं और नोड्स के एक समूह में एक पैकस्टैक छवि को रोल करने में सक्षम होना चाहता

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

सिवाय इसके कि एक तरीका लोगों के लिए एक भयावह PITA है और एक तरह से Dockerfile के साथ निर्माण के मौजूदा तंत्र में बहुत अच्छी तरह से स्लॉट है।

साथ ही, आपने मेरे प्रश्न का उत्तर नहीं दिया। आप तृतीय पक्ष डेबियन पैकेज (या पैकस्टैक) की साधारण स्थापना को "रनटाइम कॉन्फ़िगरेशन" क्यों मानते हैं?

@ctindel पोर्टेबिलिटी। सिर्फ इसलिए कि कुछ किया जा सकता है इसका मतलब यह नहीं है कि यह समर्थित है, और इसे build करना, इसे सभी के लिए करना सुविधाजनक बनाता है, इसका मतलब है कि यह समर्थित है।
हम _will_ मेजबानों के बीच काम नहीं करने वाली छवियों के मुद्दों से भर जाएंगे ... जो मूल रूप से डॉकर के पूरे कारण को हरा देता है।

यदि किसी पैकेज को स्थापित करने के लिए --privileged की आवश्यकता है, तो उसे पैकेज के साथ संबोधित किया जाना चाहिए। स्थापना के लिए --privileged आवश्यकता नहीं होनी चाहिए ... और यदि इसे वास्तव में इसकी आवश्यकता है, तो यह एक संकेत है कि स्थापना स्वयं पोर्टेबल नहीं है (होस्ट पर चीजों को बदलने की आवश्यकता है) ... मैं यहां तक ​​कि डॉकटर को --privileged बिना एक कंटेनर में चलाने योग्य देखें (ध्यान दें कि यह चलने योग्य है, आप इसे बिना किसी समस्या के - बिना किसी समस्या के स्थापित कर सकते हैं)।

लेकिन इसे डॉकर कमिट के माध्यम से करने की अनुमति देने का मतलब है कि यह भी समर्थित है!

मुझे समझ में नहीं आ रहा है, आप इस उत्पाद में बहुत सारे लोगों को सीमाओं के आसपास काम कर रहे हैं क्योंकि आप चिंतित हैं कि कोई व्यक्ति आप लोगों से व्यक्तिगत रूप से किसी प्रकार की असमर्थित छवि के बारे में शिकायत करने जा रहा है?

आपने अभी भी मेरे प्रश्न का उत्तर नहीं दिया है कि पैकेज स्थापित करने का कार्य (मैं इसे यहां कॉन्फ़िगर करने के बारे में भी बात नहीं कर रहा हूं) "रनटाइम कॉन्फ़िगरेशन" का एक कार्य है। सिर्फ "पोर्टेबिलिटी" कहने का कोई मतलब नहीं है।

वहाँ कुछ x86_64 डोकर के बारे में विशिष्ट है? क्या अंततः डॉकर छवियां नहीं होंगी जो एक विशिष्ट CPU आर्किटेक्चर के लिए बनाई गई हैं? क्या यह उन्हें गैर-पोर्टेबल भी नहीं बनाता है? मेरा मतलब इस पूरे विचार से है कि किसी भी तरह आप हमेशा किसी भी डॉकर छवि को लेने में सक्षम होंगे और इसे दुनिया में किसी भी डॉक होस्ट पर चला सकते हैं, भले ही अन्य चर के टन के बावजूद असंभव लगता है, इसलिए मुझे सुपर मजबूत आवश्यकता को समझ में नहीं आता धक्का देना इस विशेष सुविधा पर वापस जो लोग मांग रहे हैं।

BTW, मैं यहां आपके उत्तरों और निरंतर जुड़ाव के लिए आपको धन्यवाद देता हूं। कई अन्य गीथब परियोजनाएं जहां मुद्दे धागे को नजरअंदाज कर दिया जाता है!

मैं docker run --privileged साथ docker commit का उपयोग करके इसके आसपास काम करने वाले लोगों की बात से सहमत हूं। मैंने अब तक दो कंपनियों के लिए ऐसा ही एक समाधान बनाया है। लोग इस तरह की तस्वीरें बनाएंगे और अभिनय करने का कोई मतलब नहीं है जैसे कि ऐसा करना कोई भयानक, भयानक चीज है।

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

@PerilousApricot क्या वास्तव में पैकस्टैक के साथ समस्या पैदा कर रहा है? हम विशिष्ट समस्याओं को ठीक करने में प्रसन्न हैं, या उन्हें ठीक करने में अपस्ट्रीम में मदद करते हैं, लेकिन यह नहीं सोचते कि केवल --privileged जोड़ना जो आपके होस्ट सर्वर को पूर्ण निरंकुश रूट एक्सेस देता है, ऐसा करने का सही तरीका है। सभी मामलों के बारे में मुझे पता है कि लोगों ने विशिष्ट बिल्ड मुद्दों को कहां उठाया है, आमतौर पर तय किया जा सकता है, क्योंकि अधिकांश चीजों को वास्तव में होस्ट मशीन पर रूट एक्सेस की आवश्यकता नहीं होती है ताकि वास्तव में निर्माण किया जा सके।

@justincormack एक तृतीय पक्ष पैकेज (यानी बदला नहीं जा सकता) के लिए समाधान क्या है जो अपनी स्वयं की सेवा शुरू करता है जहां init स्क्रिप्ट को tmpfs फाइल सिस्टम को माउंट करने की आवश्यकता होती है? मेरा मतलब है कि अनदेखा करना भी - अभी के लिए विशेषाधिकार प्राप्त करने का कोई तरीका नहीं है - कैप-ऐड या - सुरक्षा-ऑप्ट एपर्मर: बिल्ड के दौरान

@ctindel इसे इंस्टॉलेशन पर tmpfs माउंट करने की कोशिश नहीं करनी चाहिए। यदि इसे रनटाइम पर tmpfs की आवश्यकता है तो बढ़िया है, लेकिन इंस्टॉल समय पर यह निश्चित रूप से सही नहीं है।

@ cpuguy83 आप किसी ऐसी चीज़ पर वास्तु और कार्यान्वयन दर्शन थोप रहे हैं जो अपरिवर्तनीय है क्योंकि यह एक व्यावसायिक तृतीय पक्ष से आ रहा है। सब कुछ "अपस्ट्रीम" तय नहीं होने जा रहा है, भले ही वे .deb या .rpm के नए संस्करण को ठीक कर दें, इसका मतलब यह नहीं है कि वे वापस जाएंगे और पुराने संस्करण को दोबारा पोस्ट करेंगे, जो कि आपको डॉकर छवि में आवश्यकता हो सकती है।

इस पूरी चर्चा का यही बिंदु है, आप मनमाने प्रतिबंध लगा रहे हैं जो इसे "गलत करते हैं" लोगों से समर्थन के अनुरोधों के बारे में कुछ दार्शनिक चिंताओं के कारण डॉकर का उपयोग करना अधिक कठिन बना देता है।

यह कहने जैसा है कि ऑपरेटिंग सिस्टम को लोगों को प्रक्रिया शेड्यूलिंग कक्षाओं को बदलने की अनुमति नहीं देनी चाहिए क्योंकि यदि आप इसे गलत करते हैं तो इससे प्राथमिकता उलटा हो सकता है। या, कि किसी को हथौड़ा नहीं बनाना चाहिए क्योंकि यदि आप इसे गलत तरीके से इस्तेमाल करते हैं तो आपके अंगूठे को मारना संभव है।

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

@ctindel अधिक नहीं की तरह, आप इस परमाणु बम को नहीं संभाल सकते क्योंकि आप 50 किमी के दायरे में सभी को मार सकते हैं।

इस पैकेज के बारे में ऐसा क्या है कि इसे स्थापना के दौरान tmpfs लोड करने की आवश्यकता है? इंस्टालेशन वस्तुतः फाइलों को कुछ आर्काइव फॉर्मेट से रूटफ्स में एक्सट्रैक्ट कर रहा है।

कुछ भी बदला जा सकता है।
स्थापना के समय tmpfs को माउंट न करने के लिए अपस्ट्रीम किया जाना कहीं अधिक सरल और सुरक्षित परिवर्तन है, क्योंकि यह बिल्ड पर विशेषाधिकार प्राप्त करने के लिए है।

डॉकर वर्कलोड पोर्टेबिलिटी के बारे में है। बिल्ड (या अतिरिक्त विशेषाधिकार, या सुरक्षा प्रोफाइल, आदि) पर विशेषाधिकार को सक्षम करने से यह मौलिक रूप से टूट जाता है और ऐसा कुछ नहीं है जिसे हम आज स्वीकार कर सकते हैं।

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। ऐसे इंस्टॉलर को आसानी से ठीक किया जा सकता है (लेकिन निकट भविष्य में नहीं हो सकता है)।

इस मामले में, डॉकर के लिए खराब व्यवहार करने वाले इंस्टॉलरों को पीछे धकेलना एक वैध दर्शन है। अधिकांश इंस्टॉलरों के पास किसी प्रकार का वर्कअराउंड होता है जो डॉकरीफाइल को थोड़ा लंबा बनाता है।

1. इंस्टॉलर जो मौलिक रूप से विशेषाधिकार प्राप्त संचालन पर निर्भर करते हैं, जैसे GPU ड्राइवरों के लिए कर्नेल मॉड्यूल स्थापित करना। ये मौलिक रूप से गैर पोर्टेबल भी हैं। उदाहरण के लिए, वे मैक के लिए डॉकर-मशीन पर काम नहीं करेंगे।

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

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

@tlbtlbtlb मुझे समझ में नहीं आता कि आप किस "पुण्य" का जिक्र कर रहे हैं। किसी ऐसी चीज़ पर विचार करें जो तुच्छ नहीं है, लेकिन बहुत सारे डॉकटर चित्र हैं जो एक वातावरण में चलेंगे लेकिन दूसरे में नहीं। उदाहरण के लिए, आप linux->linux से जाने वाले एक mongodb कंटेनर में एक होस्ट वॉल्यूम माउंट कर सकते हैं क्योंकि और mmapv1 स्टोरेज ड्राइवर ठीक काम करेगा, लेकिन आप अपने लैपटॉप पर एक mongodb कंटेनर में वर्चुअलबॉक्स के माध्यम से एक मैक ओएसएक्स डायरेक्टरी पास नहीं कर सकते क्योंकि उस मामले में एमएमएपी सामान ठीक से काम नहीं करेगा।

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

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

डॉकर में पोर्टेबल कॉन्फ़िगरेशन और गैर-पोर्टेबल कॉन्फ़िगरेशन का एक बहुत ही विशिष्ट और आंतों का पृथक्करण है।

इस बारे में कैसा है ?
मुझे अपने nginx कॉन्फ़िगरेशन चेक पास के लिए कंटेनर के अंदर अपने असली ips की आवश्यकता है।

यह मेरा डॉकरफाइल है:

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

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

@ cpuguy83 मैं 20 लाइनों की या तो के बारे में है iptable प्रविष्टियों मैं करना चाहते हैं RUN मेरी में Dockderfile लेकिन नहीं के बाद से मैं की जरूरत है सकते हैं --cap-add=NET_ADMIN । ये आदेश इस पर ध्यान दिए बिना होना चाहिए कि कंटेनर कौन चला रहा है और वे इसे किस मशीन पर चलाते हैं (कंटेनर एक आंतरिक ऐप चलाता है)। आप ऊपर जो चर्चा करते हैं, उसके आधार पर आप कहां/कैसे सुझाव देंगे कि मैं ऐसा करूं?

@MatthewHerbst दुर्भाग्य से iptables नियम छवि के साथ नहीं रहेंगे/नहीं रह सकते हैं।

@ cpuguy83 मैं एक centos:6 छवि का उपयोग कर रहा हूं और फाइल सिस्टम के नियमों को बनाए रखने के लिए /sbin/service iptables save चला सकता हूं। मेरा मानना ​​​​है कि iptables-persistent package के माध्यम से उबंटू और अन्य पर उनकी समान क्षमता है।

आप बस उस फ़ाइल के लिए iptables नियम बना सकते हैं, इसकी कोई आवश्यकता नहीं है
वास्तव में उन्हें लागू करें। नेटवर्क स्थिति जहां कंटेनर चलाया जा सकता है
बहुत अलग हो इसलिए आपको केवल रन टाइम पर नियम लागू करने चाहिए (यदि ऐसा है, तो आप
मेजबान उन्हें उत्पन्न करने के साथ बेहतर हो सकता है)।

16 मई 2016 16:03 को, "मैथ्यू हर्बस्ट" नोटिफिकेशन @github.com ने लिखा:

@ cpuguy83 मैं CentOS पर हूँ और रन /sbin/service iptables सेव टू . चला सकता हूँ
फाइल सिस्टम के नियमों को बनाए रखें। मेरा मानना ​​​​है कि उनका एक समान है
उबंटू और अन्य पर iptables-persistent पैकेज के माध्यम से क्षमता।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें

@justincormack नहीं जानता कि मैंने ऐसा क्यों नहीं सोचा! धन्यवाद!

docker service का उपयोग करते समय आपको उन आदेशों को कैसे निष्पादित करना चाहिए जिनके लिए विशेषाधिकार की आवश्यकता होती है? मुझे अपनी कुछ मशीनों पर होस्टनाम सेट करने की आवश्यकता है, लेकिन दुर्भाग्य से इसके लिए विशेषाधिकार की आवश्यकता है।

@nostrebor जो इस खुले मुद्दे से बहुत अधिक असंबंधित है।
हम मूल्यांकन कर रहे हैं कि सेवाओं के लिए कौन से विकल्प मौजूद होने चाहिए बजाय इसके कि उन्हें 1-टू-1 कॉपी किया जाए। विशेषाधिकार मोड शायद सेवाओं के लिए 1.12 में नहीं होगा।

मैं डॉकर बिल्ड की कोशिश कर रहा हूं जो इंस्टॉलेशन के लिए कुछ संकलित करता है, लेकिन इसे सीवीएमएफएस नेटवर्क फाइल सिस्टम पर मौजूद पुस्तकालयों के खिलाफ संकलित करना चाहिए। बेशक, मैं बिना --विशेषाधिकार चलाए CVMFS को माउंट नहीं कर सकता, इसलिए मैं इसे Dockerfile का उपयोग करके बिल्कुल भी नहीं कर सकता।

@ cpuguy83 @tlbtlbtlb यह एक 'इंस्टॉलर' का मामला है जो मौलिक रूप से विशेषाधिकार प्राप्त कार्रवाई पर निर्भर करता है। लेकिन यह वह नहीं है जिसे मैं 'तुच्छ उपयोग' कहूंगा, मुझे केवल नेटवर्क फाइल सिस्टम पर साझा पुस्तकालयों तक पहुंच की आवश्यकता है। फिर भी, इस मामले में स्थापना केवल कुछ संग्रह से फ़ाइलें निकालने के लिए नहीं है।

मुझे समझ में नहीं आता कि कैसे एक नेटवर्क फाइल सिस्टम को माउंट करना एक पोर्टेबिलिटी समस्या है। (हमारे सभी लक्षित वातावरणों की इस फाइल सिस्टम तक पहुंच होगी। उनकी आवश्यकता है क्योंकि वे अन्य कोड बनाते हैं जो नेटवर्क फाइल सिस्टम पर बाइनरी कोड से भी लिंक होना चाहिए।)

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

मैं डॉकरफाइल के साथ ऐसा करने के लिए उत्साहित था, लेकिन ऐसा लगता है कि मुझे docker run --privileged साथ कुछ स्क्रिप्ट का उपयोग करके इसे कठिन तरीके से करना होगा, या डॉकर के बजाय कुछ और उपयोग करना होगा। क्या एक कंटेनर में फाइल सिस्टम को माउंट करने का कोई तरीका है _बिना _ विशेषाधिकार प्राप्त पहुंच वाले?

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

@drstapletron , CERN cvmfs प्रलेखन के अनुसार, आपके पास अभी के लिए दो विकल्प हैं, या तो होस्ट से कंटेनर में cvmfs माउंट करें या एक विशेषाधिकार प्राप्त कंटेनर के अंदर cvmfs स्थापित करें।

सेकंड के मामले के लिए, मैंने यहां cmssw लोगों के लिए एक डॉकर-फाइल लिखी है:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

इसलिए इस फ़ाइल का उपयोग करके, आप बस एक छवि बना सकते हैं (या हो सकता है कि आप इसे cmssw dockerhub से पकड़ लें), और इसे P मोड में चलाएँ, और सब कुछ पहले से ही कंटेनर (ls /cvmfs/*) के अंदर होगा।

सुनिश्चित नहीं है कि यह ऊपर कवर किया गया था क्योंकि यह इस मुद्दे पर प्रतिक्रिया की एक लंबी सूची है। मैं भी --विशेषाधिकार प्राप्त बिल्ड कमांड रखना चाहूंगा। मेरा वर्तमान उपयोग मामला एक ऐसे मुद्दे के आसपास काम करना है जिसमें मैं एक जेंटू स्टेज 3 पर गो ईबिल्ड के निर्माण के साथ भाग गया। यदि मैं एक कंटेनर का उपयोग नहीं करता हूं, तो जेंटू हैंडबुक में वर्तमान निर्देश सिस्टमड को गलत तरीके से व्यवहार करने का कारण बनते हैं जब मैं 'umount -l /mnt/gentoo/dev{/shm,pts,} && umount -l /mnt/gentoo/{ proc, sys}' सिस्टमड के साथ बूट किए गए सिस्टम से ... जब मैं अपने स्टेज 3 बिल्ड को डॉक कंटेनर में ले जाता हूं तो सब कुछ ठीक काम करता है जब तक कि किसी बिल्ड को ptrace, या कुछ अन्य प्रतिबंधित फीचर की आवश्यकता नहीं होती है ... जो कि -1.7.1 है। ईबिल्ड की आवश्यकता प्रतीत होती है।

अभी के लिए मैं केवल डॉक रन कमांड के भीतर बिल्ड चला रहा हूं, कमिट कर रहा हूं और फिर वहां से जारी रख रहा हूं, लेकिन मैन्युअल चरणों से बचने के लिए डॉकर बिल्ड कमांड के भीतर ही ptrace को सक्षम करना बेहतर होगा।

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

विशेष रूप से:

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

पूरी तरह से उचित उपयोग-मामले की तरह लगता है।

@seltzy मैं सुझाव docker से किसी के लिए भी अपनी सांस रोककर प्रतीक्षा न करें।

जब वास्तुकला और फीचर-समावेश की बात आती है, तो वे बहुत भारी, व्यावहारिक, अलग होते हैं, और किसी भी और सभी उपयोग के मामलों को अनदेखा करते हैं जो _their_ रोडमैप में फिट नहीं होते हैं।

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

बेशक, वे इस तरह से अपने इंजीनियरिंग संसाधनों को आवंटित करने के लिए स्वतंत्र हैं।
लेकिन यह एक ट्रैक रिकॉर्ड प्रदान करता है जो कल्पना को भीख देगा यदि कंपनी को कभी भी "उपयोगकर्ता की जरूरतों को गंभीरता से लेने" के रूप में वर्णित किया गया था।

@tamsky आपने इसे

@tamsky मैं समझ सकता हूं कि आप ऐसा क्यों सोचेंगे, क्योंकि प्रोजेक्ट ने ऐसी सुविधा स्वीकार नहीं की है जिसे आप स्पष्ट रूप से चाहते हैं।

मैं आपको आश्वस्त कर सकता हूं कि इसका किसी भी प्रकार के व्यावसायिक निर्णय से कोई लेना-देना नहीं है। तथ्य यह है कि, निर्माण पर --privileged गैर-पोर्टेबल छवियों को प्राप्त करेगा।
बिल्ड वातावरण में modprobe जैसी चीजें मददगार नहीं होती हैं और यहां तक ​​कि दो बिल्ड से पूरी तरह से अलग परिणाम भी मिल सकते हैं।

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

उस ने कहा, यह मुद्दा अभी भी एक कारण से खुला है। ऐसा इसलिए है क्योंकि लोग सुन रहे हैं।

आपके विचार के लिए धन्यवाद।

@ cpuguy83 स्पष्टीकरण के लिए धन्यवाद। मुझे नहीं पता था कि यह एक पोर्टेबिलिटी समस्या थी। मुझे लगता है कि इसके लिए मेरी इच्छा गलतफहमी से प्रेरित है।

विशेषाधिकार प्राप्त निर्माण के प्रलोभन का सामना करते समय सामान्य दार्शनिक दृष्टिकोण क्या है?

@seltzy इतना सुनिश्चित नहीं है कि आपका उपयोग मामला इस सुविधा की आवश्यकता का उचित उदाहरण नहीं है

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

@ cpuguy83 PS आपने एक कस्टम बिल्डर का उल्लेख किया है। मुझे इसके बारे में जानकारी कहां मिल सकती है? धन्यवाद!

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

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

@drstapletron एक फाइल सिस्टम को माउंट करना जरूरी नहीं है जो पोर्टेबिलिटी को तोड़ सकता है (जब तक कि कोई यह उम्मीद नहीं कर रहा था कि छवि में आरोहित किया जाएगा)।
यहां समस्या यह है कि फाइल सिस्टम को माउंट करने की क्षमता का मतलब अन्य खराब चीजों का एक गुच्छा करने में सक्षम होना भी है।

@ctindel हां, आप अपने द्वारा बनाए गए कंटेनरों में कुछ भी कर सकते हैं। तथ्य यह है कि docker build छवियों के निर्माण की "समर्थित" विधि है, हालांकि, इसका मतलब है कि हमें यह सुनिश्चित करने की आवश्यकता है कि इसके साथ निर्मित छवियां _are_ पोर्टेबल हैं।

पोर्टेबल छवियां लाल हेरिंग नहीं हैं। वर्कलोड पोर्टेबिलिटी डॉकर का प्राथमिक डिजाइन लक्ष्य है। हमारा प्रमुख निर्देश, जैसा कि यह था।

@seltzy अधिकांश चीजें जिन्हें अतिरिक्त विशेषाधिकारों की आवश्यकता होती है, वे रनटाइम पर होती हैं, क्योंकि अधिकांश समय मेजबान को संशोधित करने के लिए उन्नत विशेषाधिकारों का उपयोग किया जाता है।
यही कारण है कि कहा कि मैं निश्चित रूप से समझ सकते हैं कि कुछ चीजें निर्माण समय (एनएफएस ऊपर माउंट जैसे) पर आवश्यक हैं .... लेकिन फिर भी एनएफएस के मामले के साथ और मैन्युअल रूप से छवि (नहीं के साथ निर्माण docker build ), मैं कंटेनर को --privileged या कोई अतिरिक्त क्षमता बिल्कुल नहीं देगा, इसके बजाय मैं nfs निर्यात को वॉल्यूम के रूप में माउंट करूंगा।

@drstapletron mount को --privileged आवश्यकता नहीं है, केवल एक अधिक प्रतिबंधित क्षमता सेट है और एक पूर्ण विशेषाधिकार मोड की तुलना में जल्द ही होने की अधिक संभावना है, क्योंकि यह होस्ट को पूर्ण रूट एक्सेस देता है जो अधिकांश लोग करते हैं नहीं चाहता। (इसमें अभी भी सुरक्षा मुद्दे हैं लेकिन वे अधिक प्रबंधनीय हैं)।

तो मेरे पास पूरी तरह से पोर्टेबल, गैर-होस्ट-संशोधित उपयोग केस है। यह ओपन सोर्स भी है और आप इसे यहां देख सकते हैं।

मूल रूप से, मैं एक अनुकूलित CentOS ISO छवि बनाने के लिए Mock को पोर्टेबल Docker कंटेनर में चलाना चाहता हूँ। नकली, उन लोगों के लिए जो नहीं जानते हैं, एक कंटेनरीकृत आरपीएम बिल्डर है। समस्या यह है, क्योंकि यह कंटेनरों का उपयोग करता है, मुझे --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-स्टेज बिल्ड, रन, कमिट प्रोसेस करने की जरूरत के साथ फंस गया हूं।

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

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

इसके लिए +1। हमारी निर्माण प्रक्रिया में /proc और /dev को माउंट करना आवश्यक है। आदर्श रूप से हमें dockerfile के भाग के रूप में माउंट चरण प्राप्त करने में सक्षम होना चाहिए।

@ सैमसन387 आपकी निर्माण प्रक्रिया को इसकी आवश्यकता क्यों है?

@skshandilya setfacl पोर्टेबल नहीं है और मुझे आश्चर्य होगा अगर acl को किसी छवि के लिए जारी रखा जा सकता है।

@robhaswell "एक विशेषाधिकार प्राप्त कंटेनर की आवश्यकता है" ज्यादा मदद नहीं करता है। वास्तव में इंस्टॉल पर क्या उपयोग किया जा रहा है?

+1। मॉक इनिट को इसकी जरूरत है।
लगभग पूरा मामला पढ़ा। समझ में नहीं आता कि लोग लगातार 3 साल तक "आपको इसकी आवश्यकता क्यों है" पूछते रहते हैं।

@Betriebsrat क्योंकि "X को इसकी आवश्यकता है" वास्तव में वह सब मददगार नहीं है।
"एक्स" क्या कर रहा है? निर्माण चरण के दौरान "X" को इसकी आवश्यकता क्यों है?

उदाहरण के लिए, उपरोक्त मामला /proc और /dev को माउंट करने की क्षमताओं के साथ वास्तव में बिल्ड चरण के लिए सही जगह की तरह प्रतीत नहीं होता है, और यहां तक ​​​​कि ऐसा लगता है कि छवि मेजबान से जुड़ी होगी एक मामला।

"विशेषाधिकार प्राप्त" भी एक टैंक है। यह पूरी तरह से सब कुछ खोलता है, सभी सुरक्षा सुविधाओं को अक्षम करता है, आम तौर पर केवल-पढ़ने वाले स्थानों पर लेखन पहुंच प्रदान करता है ... जहां किसी को शायद एक बहुत ही विशिष्ट काम करने में सक्षम होने की आवश्यकता होती है।

ये प्रश्न इसलिए पूछे जाते हैं ताकि हमें वास्तविक उपयोग का मामला मिल सके और हम इस तरह के मामले को कैसे संतुष्ट कर सकें।

वैसे, जब मैं "सुरक्षा सुविधाएँ" कहता हूँ तो मेरा मतलब दो चीज़ों से है:

1. हैकिंग से बचने के उपाय
2. मेजबान चिंताओं से आवेदन चिंताओं का अलगाव (यानी, छवि निर्माण को छवि को उस होस्ट से नहीं जोड़ना चाहिए जिस पर इसे बनाया गया है)।

ऐसा लगता है कि मेरा 21051 तक हल हो गया था, मैं अभी के लिए बाहर हूं :)

@shykes ने 28 नवंबर, 2013 को कहा @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

क्षमा करें, वर्तमान डिज़ाइन '1 स्रोत, 1 बिल्ड' को लागू करने के लिए है, यही कारण है कि हम स्रोत निर्देशिका के अलावा किसी भी तर्क को docker निर्माण की अनुमति नहीं देते हैं।

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

@ cpuguy83 , क्या डिज़ाइन लागू करने से बिल्कुल बदल गया है: "1 स्रोत, 1 बिल्ड"?
क्या डॉकर प्रोजेक्ट उस डिज़ाइन को बदलने और इस समुदाय-अनुरोधित सुविधा को अनुमति देने के लिए तैयार है?

ऊपर श्येक्स की टिप्पणी यह ​​बताती है कि इसे संभालने के लिए "हमें क्या करने की आवश्यकता हो सकती है"। साथ ही, इस्तेमाल की जाने वाली भाषा ("हो सकता है") इस डिज़ाइन परिवर्तन को अस्वीकार करने के लिए अतिरिक्त कारणों के साथ आने के लिए डॉकर प्रोजेक्ट को बहुत सी जगह प्रदान करती प्रतीत होती है।

आ NEEDS_PRIVILEGED घोषणा जोड़ना समझ में आता है लेकिन यह सब सामान निर्माण को रोकने के बारे में है? बस एक त्रुटि के साथ विफल हो जाएं और ऑपरेटर को --विशेषाधिकार प्राप्त विकल्प पास करने दें यदि वे वास्तव में विशेषाधिकार प्राप्त निर्माण की अनुमति देना चाहते हैं।

@ cpuguy83 बात यह है कि जिन लोगों को कभी भी निर्माण में विशेषाधिकार प्राप्त मोड की आवश्यकता होती है, वे आमतौर पर बिजली उपयोगकर्ता होते हैं जो पूरी तरह से जानते हैं कि इसका उपयोग करने के जोखिम क्या हैं। और उनमें से अधिकांश इसे स्वीकार करते हैं और केवल docker commit का उपयोग करके उस चरण के लिए अपने निर्माण के हिस्से के रूप में काम करते हैं जिसकी आवश्यकता होती है।

आप किसी भी तरह से लोगों को बिल्ड में विशेषाधिकार प्राप्त मोड का उपयोग करने से नहीं रोक रहे हैं, आप बस इसे करने के लिए परेशान कर रहे हैं।

यदि आपका लक्ष्य इसे करने में परेशानी पैदा कर रहा है तो बस इतना ही कहो और इस मुद्दे को सालों और सालों तक चलने देने के बजाय बंद कर दो।

कहें "हम इसे ठीक नहीं करेंगे क्योंकि हम चाहते हैं कि ऐसा करना कष्टप्रद हो" और इस समस्या को बंद कर दें।

/धागा

@ cpuguy83 , मेरी समझ से, मॉक unshare(2) का उपयोग CLONE_NEWNS ध्वज के साथ करता है-- और संभवतः अन्य-- जब यह अपना चेरोट/कंटेनर वातावरण बनाता है। इसके लिए कम से कम CAP_SYS_ADMIN ।

"एक्स" क्या कर रहा है? निर्माण चरण के दौरान "X" को इसकी आवश्यकता क्यों है?

हमारे उपयोग के मामले में, हम नहीं जानते। यह कुछ स्वामित्व वाली बकवास है जिसे हम बदल नहीं सकते। बात यह है कि, हमारा व्यवसाय "सुरक्षा" (इस संदर्भ में) या पोर्टेबिलिटी, या सूचीबद्ध की गई किसी भी चिंता की परवाह नहीं करता है। हम बस इस बकवास के टुकड़े को एक कंटेनर में रखना चाहते हैं और कुछ मूल्यवान करने के लिए आगे बढ़ना चाहते हैं।

जैसा कि @PonderingGrower कहते हैं, हम इसे वैसे भी करने जा रहे हैं, यह केवल इस बात की बात है कि हम इसे करते समय कितना समय बर्बाद करते हैं।

जिन लोगों को कभी भी निर्माण में विशेषाधिकार प्राप्त मोड की आवश्यकता होती है, वे आमतौर पर बिजली के उपयोगकर्ता होते हैं जो अच्छी तरह से जानते हैं कि इसका उपयोग करने के जोखिम क्या हैं

मैं उस धारणा से पूरी तरह असहमत हूं। कुल मिलाकर, जो लोग --privileged उपयोग करते हैं, वे उसी श्रेणी के उपयोगकर्ता हैं जो आँख बंद करके chmod -r 777 चलाते हैं "क्योंकि किसी ने लिखा है कि इसने समस्या को ठीक कर दिया है"

हमारे उपयोग के मामले में, हम नहीं जानते। यह कुछ स्वामित्व वाली बकवास है जिसे हम बदल नहीं सकते। बात यह है कि, हमारा व्यवसाय "सुरक्षा" (इस संदर्भ में) या पोर्टेबिलिटी, या सूचीबद्ध की गई किसी भी चिंता की परवाह नहीं करता है।

"इस संदर्भ में" यहाँ, जिसका अर्थ है: "बकवास का कुछ मालिकाना टुकड़ा" अपने मेजबान पर रूट एक्सेस देना।

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

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

आप यहां 3 साल से क्या चर्चा कर रहे हैं?

docker run में --cap-add , --cap-drop और अन्य विकल्प हैं। तो RUN कमांड में Dockerfile समान विकल्प रखना चाहते हैं। तो Dockerfile मूल मशीन को अनुरोध भेजना चाहते हैं और इसे कुछ विशेषाधिकार जोड़ने/छोड़ने के लिए कहते हैं।

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

बड़ी संख्या में डॉकर उपयोगकर्ता बिल्ड कमांड में --cap-add या --विशेषाधिकार प्राप्त करने की क्षमता चाहते हैं, ताकि रन कमांड में मौजूद चीजों की नकल की जा सके।

यही कारण है कि यह टिकट 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 का लोगों के स्वाद से कोई लेना-देना नहीं है। हम किसका इंतज़ार कर रहे हैं?

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

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

@ctindel मेरी अंग्रेजी बहुत अच्छी नहीं है, क्षमा करें।

मैं जानता हूँ। मैंने ग्लिबक उभरने की कोशिश की है और मुझे 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 ने कहा

कुल मिलाकर, -- विशेषाधिकार का उपयोग करने वाले लोग उसी श्रेणी के उपयोगकर्ता हैं जो आँख बंद करके chmod -r 777 . चलाते हैं

यह व्यक्ति केवल log :info, requested_cap; return privileged? तुलना में सत्यापन आवश्यक क्षमताओं का अधिक लचीला तरीका चाहता है।

@ctindel आपने कहा

आ NEEDS_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 साल बीत गए!

@ एंड्रयू-अलादेव मैं मान रहा हूं कि किसी ने भी उस वाक्यविन्यास के लिए तर्क नहीं दिया है क्योंकि यह स्पष्ट कर दिया गया है कि जब तक बिल्डर को मुख्य इंजन से फिर से लिखा/पुन: सक्रिय/विघटित नहीं किया जाता है तब तक डॉकरफाइल सिंटैक्स जमे हुए है। https://github.com/docker/docker/issues/29719#issuecomment -269342554

अधिक विशेष रूप से, समस्या का शीर्षक और ओपी अनुरोध कर रहे हैं --विशेषाधिकार प्राप्त बिल्ड

यह एक फोन्ज़ी थम्स अप हो जाता है: .

strace को build चरण में चलाने में सक्षम होने से बहुत मदद मिलती है।
वर्तमान में, मैं run चरण में डीबग करने के लिए आवश्यक सभी चीजों को स्थानांतरित करके इसके आसपास काम करता हूं - आदर्श नहीं।

क्या किसी को पता है कि यह run में क्यों काम करेगा न कि build चरण में? यानी, ऐतिहासिक कारण।
क्या strace कोई विकल्प है जो बिना किसी अनुमति या कॉन्फिग के काम करता है?

इसके लिए एक प्रस्तावित समाधान/समाधान है
https://github.com/docker/docker/issues/6800#issuecomment -50494871 :

यदि आपको डॉकटर बिल्ड में समस्या है, तो आप "बिल्डर कंटेनर" का उपयोग कर सकते हैं:
docker run --cap-add [...] mybuilder | docker build -t myimage -

क्या कोई (संभवतः @tiborvass) इस पर विस्तार से बता सकता है? यहां mybuilder किस प्रकार का है?
कुछ ENTRYPOINT के साथ छवि का नाम? या [...] का छवि हिस्सा है और mybuilder संदर्भित करता है
एक खोल स्क्रिप्ट के लिए? और मैं docker run को संदर्भ.tar.gz को docker build - में पास करने के लिए कैसे मनाऊं
अगर वास्तव में यहाँ क्या हो रहा है। अग्रिम धन्यवाद, स्टीफन

@sneumann mybuilder एक छवि नाम होगा और वास्तव में कुछ CMD या ENTRYPOINT । काम करने के लिए उस वर्कअराउंड का अनुबंध यह है कि mybuilder को कंटेनर के भीतर से संदर्भ tar करना होगा और इसे स्टडआउट पर जाने देना होगा। इसे docker build के स्टड पर पास किया जाता है, शेल पाइप | के लिए धन्यवाद और इसे संदर्भ माना जाता है क्योंकि 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 देशी विंडोज कंटेनरों के लिए है, जो "क्रेडेंशियलस्पेक" का समर्थन करते हैं https://github.com/docker/docker/pull/23389

क्या इसे संशोधित करना और इसे जारी रखना संभव है ताकि भविष्य में build सक्षम हो सके ptrace ?

यहां रुचि रखने वाले किसी भी व्यक्ति के लिए कुछ अच्छे लिंक दिए गए हैं:

• http://www.projectatomic.io/docs/docker-build-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 मुझे यकीन नहीं है कि इस मामले में क्या हो रहा है, लेकिन विलय होने के बाद मैं इसे एक शॉट दूंगा। धन्यवाद!

नमस्ते, मैं अपना नाम कृपया-कार्यान्वयन-इस टोपी में डालना चाहता हूं। या हो सकता है कि मेरी समस्या का एक अलग समाधान हो (डॉकर नोब यहां) कि कोई मुझे इंगित कर सके?

मैं आधिकारिक सेंटोस/ सिस्टमड छवि के आधार पर एक छवि बनाने और इसे साल्टस्टैक के साथ प्रावधान करने की कोशिश कर रहा हूं। इसके लिए सिस्टमड के साथ नमक-मिनियन डेमॉन को शुरू करने (और शायद फिर से शुरू करने) की आवश्यकता होती है जो कि विशेषाधिकार प्राप्त मोड के बिना (AFAIK) नहीं किया जा सकता है।

@onlyanegg मुझे लगता है कि उस स्थिति में, साल्टस्टैक बड़े पैमाने पर बिल्डर की कार्यक्षमता को बदल देता है; ध्यान रखें कि प्रत्येक RUN स्टेटमेंट को एक नए कंटेनर में निष्पादित किया जाता है, जिस बिंदु पर पिछले बिल्ड कंटेनर को रोक दिया जाता है, और एक छवि / परत के लिए प्रतिबद्ध होता है।

क्या आपने एक कंटेनर चलाकर और परिणाम ( docker commit ) करके निर्माण करने पर विचार किया है?

प्रतिक्रिया देने के लिए धन्यवाद, @thaJeztah। मुझे नहीं पता था कि RUN निर्देश ने यही किया है। मैंने इस मुद्दे में से अधिकांश को पढ़ा है, इसलिए मुझे docker build -> docker run -> docker commit वर्कअराउंड के बारे में पता है, जो कि मैं संभवतः कर रहा हूं। मैं अपनी छवि का वर्णन करने वाली एक फ़ाइल के पक्ष में बस अधिक हूं - नटखट लगता है। हो सकता है कि मैं उन सभी चरणों को पैकर पोस्ट-प्रोसेसर में रख सकूं और फिर मेरे पास वह होगा।

इसकी इतनी अनदेखी क्यों की जाती है? कंटेनरों, कुबेरनेट्स और मिनीक्यूब के समय, और सीआई और विकास पर्यावरण एकीकरण में डॉकर के उपयोग के समय, यह कार्यक्षमता वास्तव में महत्वपूर्ण है।

@onlyanegg आपको RUN कमांड काम नहीं करता है क्योंकि इसे विशेषाधिकार प्राप्त मोड की आवश्यकता होती है") मुझे एक नज़र डालने में खुशी होगी!

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

शुक्रिया!

@jpetazzo इसके अंदर docker छवि प्राप्त करने का प्रयास करें:

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

अब इसे बनाएं और इसे शुरू करें। docker deamon शुरू करने के लिए service docker start रन शुरू करने के बाद। फिर सेवा की स्थिति जांचें service docker status :

• विशेषाधिकार प्राप्त ध्वज स्थिति के साथ ठीक है और आप बिना मुद्दों के कंटेनर शुरू कर सकते हैं
• झंडे के बिना, यह कभी शुरू नहीं होता है

@jpetazzo ech, अभी आपने देखा है कि आप https://github.com/jpetazzo/dind के निर्माता हैं :)

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

तो, क्या अभी तक docker build में NFS या SMB शेयर माउंट करने का कोई तरीका है?

@derberg वे कदम काम नहीं करेंगे, भले ही बिल्ड कंटेनर चल रहा हो --privileged ; डॉकर पैकेज (और स्क्रिप्ट स्थापित करें) (उदाहरण के लिए) उबंटू 16.04 पर कर्नेल पैकेज स्थापित कर रहे हैं।
यही कारण है --privileged के लिए एक बुरा विचार है docker build , क्योंकि यह _host_ पर परिवर्तन करने के लिए सक्षम होगा।

भले ही docker को विशेषाधिकार की आवश्यकता होगी जब _running_, स्थापना को स्वयं इसकी आवश्यकता नहीं होती है; उदाहरण के लिए, यहां वे चरण हैं जिन्हें आप अपनी छवि में docker स्थापित करने के लिए चलाएंगे;

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 फ़ाइल और एक शेल स्क्रिप्ट की आवश्यकता होती है।

डॉकरफाइल

यह वैसा ही है जैसा आपको छवि बनाने की आवश्यकता होगी। एकमात्र अंतर, जहां आपको विशेषाधिकार प्राप्त संचालन करने की आवश्यकता है, वहां रुकें, उन्हें शामिल न करें। उन्हें एक स्क्रिप्ट के रूप में docker-compose द्वारा चलाने की आवश्यकता है। उदाहरण के लिए:

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 । इसे छवि में शामिल किया गया है और बाद में निर्माण प्रक्रिया को समाप्त करने के लिए डॉकर संगीतकार द्वारा चलाया जाएगा।

डॉकर फ़ाइल लिखें

लिखें फ़ाइल कुंजी है। यह पहले 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 में जोड़ें और आप देखेंगे कि docker सेवा कभी नहीं उठती है

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg ठीक है, मैं देखता हूँ! _व्यक्तिगत रूप से, अगर मैं dind कंटेनर में छवियों को शामिल करना चाहता हूं, तो मैं उन्हें डाउनलोड करूंगा (उदाहरण के लिए reg ) और मैं उन्हें पहली बार कंटेनर शुरू होने पर लोड करूंगा। क्यों? क्योंकि अगर आप निर्माण के दौरान छवियों को खींचते हैं, तो छवि _केवल तभी काम करेगी जब dind को उसी स्टोरेज ड्राइवर_ के साथ शुरू किया गया हो। दूसरे शब्दों में, आपकी छवि अन्य मशीन पर काम कर भी सकती है और नहीं भी।

इसके अलावा-यदि आपकी छवियां बड़ी हैं (अर्थात, busybox या alpine अलावा और कुछ भी) तो आप वास्तव में एक बड़ी डिनडी छवि के साथ समाप्त हो जाएंगे ...

मुझे आपके अंतिम उपयोग-मामले के बारे में और जानना अच्छा लगेगा - क्योंकि मुझे यकीन है कि हम एक विशाल डीआईएनडी छवि बनाने की तुलना में अधिक कुशल तरीका खोजने में आपकी सहायता कर सकते हैं :-)

(अन्यथा, @kraml द्वारा प्रस्तावित समाधान बल्कि सुरुचिपूर्ण है!)

यह भी देखें https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
केवल बैश+कर्ल+टार का उपयोग करके छवियों को डाउनलोड करता है।
हम इसे यहां उपयोग करते हैं: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo हम पहले से ही इस तरह के वर्कअराउंड बिल्ड-रन-प्रतिबद्ध के साथ चलते हैं, लेकिन हाँ, यह अभी भी मेरे दृष्टिकोण से एक समाधान है। उपयोग का मामला कुबेरनेट्स और मिनीक्यूब पर्यावरण से संबंधित बहुत विशिष्ट है और ऐसा कुछ भी नहीं है जो हम अभी कर सकते हैं। अभी के लिए हम डॉकटर में मिनीक्यूब को डेमॉन के रूप में केवल डॉकटर के साथ शुरू करने में सक्षम थे, वर्चुअलबॉक्स या अन्य वीएम ड्राइवरों का उपयोग करने से काम नहीं चला, इसलिए हम dind दृष्टिकोण पर निर्भर हैं

इस समस्या में एक विरासत एप्लिकेशन (काफी सामान्य उपयोग-मामला) वाली छवि बनाने की कोशिश कर रहा था, जहां इंस्टॉलर ने sysctl कमांड चलाने की कोशिश की और असफल रहा।

इस सूत्र पर वापस आकर और डॉकर बिल्ड कमांड में किसी प्रकार की विशेषाधिकार प्राप्त क्षमताओं को कैसे जोड़ा जाए, इस मुद्दे पर आगे और पीछे के पूरे 4 वर्षों (!!!) की समीक्षा करते हुए, ऐसा प्रतीत होता है कि इस स्थिति में उपलब्ध विकल्प या तो एक हैं sysctl कॉल को हटाने के लिए इंस्टॉलर को संशोधित करने के लिए sed कमांड का गंदा गुच्छा, या एक मल्टी-स्टेज बिल्ड -> रन -> कमिट पाइपलाइन। मैं @derberg से सहमत docker build कमांड के साथ विभिन्न एप्लिकेशन और डेटाबेस इंस्टॉलेशन के साथ समस्याओं की रिपोर्ट करते देखा है।

इस बिंदु पर, डॉकर रन कमांड व्यापक 'विशेषाधिकार प्राप्त' विकल्पों का समर्थन करता है, साथ ही "-कैप-ऐड और --कैप-ड्रॉप का उपयोग कर क्षमताओं पर ठीक अनाज नियंत्रण" के साथ। और इसलिए, मुझे लगता है कि सुरक्षा या तकनीकी आधार पर आपत्तियां विवादास्पद हैं। यदि विशेषाधिकार प्राप्त रन विकल्प को '--cap-add' और '--cap-drop' के साथ जोड़ा जाता है, तो एक सुरक्षा-जागरूक इंजीनियर एक विशेषाधिकार प्राप्त बिल्ड को केवल उनके निर्माण के लिए आवश्यक विशिष्ट क्षमताओं को शामिल करने के लिए सीमित करना चुन सकता है।

नमस्ते ,

मैंने पहले ही इसकी सूचना दी है, वही समस्या।

उन लोगों के बारे में क्या जो वीएम और कंटेनर पर एक ही यूजर आईडी के साथ प्रति वीएम प्रति कंटेनर चलाना चाहते हैं, डॉकटर का उपयोग केवल पैकेजिंग टूल के रूप में करते हैं?

क्‍या इस संबंध में अभी भी सुरक्षा संबंधी कोई चिंता है?

इस समस्या में भाग गया। वास्तव में निर्माण के लिए क्षमताओं का उपयोग कर सकता है।

इस मामले में भी भागे।
डॉकर को सीआई/सीडी दास के रूप में उपयोग करते समय यह बहुत उपयोगी होता है जिसे दास डॉकर छवि बनाते समय सीआई/सीडी बिल्ड/टेस्ट टूलचेन स्थापित करने के लिए docker build पर विशेषाधिकार प्राप्त अनुमति की आवश्यकता हो सकती है।
मैं वर्षों से इस सुविधा की प्रतीक्षा कर रहा हूं और वास्तव में आशा करता हूं कि भविष्य में इसका समर्थन किया जा सकता है।

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

आज तक, यह सुविधा भी अभी तक लागू नहीं की गई है:
रन --कैप-ऐड=SYS_PTRACE
जो कई उपयोगकर्ताओं की आवश्यकताओं के अनुरूप होगा ..

क्या आप कृपया सुझाव दे सकते हैं कि मैं Gentoo Linux होस्ट पर इस Dockerfile को कैसे बना सकता हूं:

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

क्योंकि मुझे यह त्रुटि तब मिल रही है जब उभरती हुई देव-लैंग/गो:

##### 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/

मैं इसे एंट्रीपॉइंट में एक अलग बैश फ़ाइल के साथ कर सकता हूं, लेकिन मुझे सिंगल डॉकरफाइल की जरूरत है

@ amd-nick निर्माण के दौरान RUN unionfs-fuse ... लाइन से आपकी क्या अपेक्षा है? यहां तक ​​​​कि अगर वह काम करता है, तो उसके पास केवल उस एकल RUN दौरान फाइल सिस्टम आरोहित होगा, और अगले चरण में चला जाएगा।

@thaJeztah मेरे लिए समझाना मुश्किल है। मैं इस रेपो को संशोधित करने की कोशिश कर रहा हूँ। क्या मैं इस लाइन को इमारत पर छोड़ सकता हूँ?

नमस्ते

यादृच्छिक रूप से डॉकर बिल्ड शून्य '0' से शुरू होने वाला होस्टनाम चुनते हैं जो हमारे एप्लिकेशन को तोड़ देता है, मैंने अपने डॉकरफाइल के अंदर ऐसे मामले में "होस्टनाम" चलाने की कोशिश की लेकिन उसी मुद्दे का सामना करना पड़ा।

मैं RUNP के साथ डॉकर बिल्ड को चलाने या बिल्ड के दौरान होस्टनाम चुनने का विकल्प प्राप्त करने का विकल्प भी प्राप्त करना चाहता हूं।

क्या किसी ने कनिको के साथ इस तरह के चित्र बनाने की कोशिश की है? मैंने इसे मैक के लिए डॉकर पर @maneamarius के डॉकरफाइल के साथ किया था और ऐसा लगता है कि जब आप कनिको के docker run "बिल्ड" कमांड को --cap-add=SYS_PTRACE साथ कॉल करते हैं तो यह सफलतापूर्वक निर्माण होता है। हालाँकि, मुझे परिणामी टारबॉल को स्थानीय रूप से लोड करने में थोड़ी परेशानी हो रही है, RAM का उपयोग थोड़ा अधिक है क्योंकि यह ओवरलेफ़ का उपयोग नहीं कर सकता है, और परत कैशिंग अभी भी WIP है। अगर मैं एक रजिस्ट्री को धक्का देता हूं तो चीजें बस काम कर सकती हैं लेकिन मैंने अभी तक इसकी कोशिश नहीं की है।

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

इस सुविधा के होने से Redhat/CentOS आधार छवियों पर कठपुतली के माध्यम से डॉकर छवियों को बनाने के प्रयासों में बहुत मदद मिलेगी।

जब से मैंने पिछली बार पोस्ट किया था, मैंने कनिको में परिवर्तनों के साथ बैक अप RUN पुनरावृति नहीं है और काम को बचाती है लेकिन हम कैश कर सकते हैं alpine , ubuntu , और जो भी लोकप्रिय आधार हैं)।

यह एक ऐसी स्थिति में है जहां मैं @maneamarius की हूं जो इस प्रोजेक्ट/डेमो गोलंग को उभरता है ( संपादित करें: मैंने तब से जेंटू आधार छवि को उस संस्करण में पिन करने के लिए Dockerfile को संशोधित करना पड़ा जो इस पोस्ट के समय latest था। अन्यथा, यह अभी भी अपरिवर्तित है। ):

https://github.com/nelsonjchen/kaniko-विशेषाधिकार प्राप्त-maneamarius-moby-1916

मैंने कनिको के साथ --cap-add=SYS_PTRACE साथ एक छवि में डॉकरफाइल बनाने के लिए Azure पाइपलाइनों को भी कॉन्फ़िगर किया है, कनिको के आउटपुट टैरबॉल को लोड करें, और जेनरेट की गई छवि में go version चलाएं। मुझे लगा कि कुछ संवादात्मक "जीवन का प्रमाण" दिलचस्प होगा। यहां पहले की कुछ टिप्पणियां सीआई सिस्टम के बारे में भी चिंतित थीं इसलिए मुझे लगा कि मैं एक सार्वजनिक सीआई सिस्टम को भी काम करने के लिए कॉन्फ़िगर करूंगा। BTW, ट्रैविस CI पर विचार किया गया था, लेकिन बिल्ड आउटपुट बहुत लंबा था और इसे समाप्त कर दिया गया और Azure आउटपुट की 166k लाइनों के साथ पूरी तरह से खुश है। यदि Dockerfile लगभग 70k कम आउटपुट लाइनों के साथ निर्मित होता है, तो यह संभवतः ट्रैविस CI पर सफल होता। एज़्योर पाइपलाइन बिल्ड आउटपुट का लिंक रीडमे के शीर्ष पर है।

बिल्डाह ल्यूक का प्रयोग करें

मैं इस मुद्दे को बंद कर रहा हूं, क्योंकि यह सुविधा अब 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 आज़माने के लिए अपने डॉकटर को संस्करण 19.03 में अपडेट किया है। जब मैं आपके द्वारा बताए गए आदेश का प्रयास कर रहा था, तो यह मुझे एक त्रुटि दे रहा था

$ 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

बिल्डएक्स डॉक्स: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

धन्यवाद @AkihiroSuda । यह अब काम किया।

बस एक और उपयोग केस जोड़ने के लिए।
मैं एक परीक्षण डेटाबेस के साथ एक ibmdb2 कंटेनर के dockerfile निर्माण को ठीक करने का प्रयास कर रहा हूँ
IBM ने हब से v10 छवि को हटा दिया। लेकिन v11 DB छवि केवल --विशेषाधिकार से शुरू होती है।
इसलिए डॉकरफाइल में डेटाबेस को स्थापित करने वाला सभी कोड अब अप्रभावी है क्योंकि डीबी 2 विशेषाधिकार के बिना शुरू नहीं होता है। :(
डॉकर रन और डॉकर कमिट का उपयोग करने के साथ एक जटिल समाधान प्रतीत होता है।
एक उत्पादक निर्माण पाइपलाइन में यह बहुत अधिक अतिरिक्त जटिलता पैदा करता है।

मुझे https://github.com/maneamarius की तरह https://github.com/moby/moby/issues/1916#issuecomment -361173550 में पूछना है

इसका समर्थन करना इतनी बड़ी बात क्यों है? बिल्ड हुड के नीचे एक रन निष्पादित करता है।

इस विशिष्ट उपयोग के मामले में एक विशेषाधिकार प्राप्त बिल्ड विकल्प एक प्रकार की "पिछड़ी संगतता" का समर्थन करेगा और मुझे पता है कि मैं अकेला नहीं हूं जिसके पास मेरे वेब शोध के बाद यह समस्या थी।

@uvwild मुझे यकीन नहीं है कि यह आपके उपयोग के मामले में मदद करता है, लेकिन आप कनिको के साथ निर्माण करने का प्रयास कर सकते हैं आपकी छवि एक --privileged या --cap-add <capability which is needed> कर सकते हैं जो आपकी समस्या का समाधान कर सकता है।

मैं स्वीकार करता हूं कि यह एक पूर्ण समाधान नहीं है जिसकी आप अपेक्षा कर रहे थे बल्कि एक आसान समाधान जो आपके निर्माण पाइपलाइन में फिट हो सकता है।

संपादित करें: जैसा कि @ एलेक्सी-वोस्त्रिकोव ने कहा था कि buildah उन मामलों के उपयोग के लिए एक अधिक व्यवहार्य समाधान हो सकता है जिन्हें छवि बनाने के लिए --privileged होती है