मुझे आश्चर्य है कि क्या #6075 आपको वह देगा जो आपको चाहिए

एक गुप्त कंटेनर इसे थोड़ा सुरक्षित बना सकता है, लेकिन उल्लिखित सभी बिंदु अभी भी खड़े हैं।

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

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

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

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

यहां कुछ अन्य लोग हैं जिनका उपयोग-मामला समान है: https://twitter.com/damncabbage/status/453347012184784896

कृपया, SSH_AUTH_SOCK को अपनाएं, यह बहुत उपयोगी है।

धन्यवाद

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

+1, SSH_AUTH_SOCK का उपयोग करने में सक्षम होना अति उपयोगी होगा!

मैं जीथब के साथ प्रमाणित करने के लिए एसएसएच कुंजी का उपयोग करता हूं, चाहे वह निजी भंडार हो या सार्वजनिक।

इसका मतलब है कि मेरा git clone कमांड इस तरह दिखता है: git clone [email protected]:razic/my-repo.git ।

मैं मात्रा मेरी मेजबान माउंट कर सकते हैं ~/.ssh एक के दौरान मेरी कंटेनर में निर्देशिका docker run और ssh सब अच्छा है। हालांकि मैं अपने ~/.ssh docker build दौरान माउंट नहीं कर सकता।

:+1: निर्माण के दौरान ssh अग्रेषण के लिए।

जैसा कि मैं समझता हूं कि यह गलत तरीका है। सही तरीका है देव मशीन में डॉकर इमेज बनाना, और इसे डॉकर सर्वर पर कॉपी करना।

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

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

यह विचार पहले ही उठाया जा चुका है (टिप्पणी 2 देखें)। इससे मसला हल नहीं होता।

बिल्ड के दौरान ssh अग्रेषण के लिए +1।

docker build पर SSH एजेंट अग्रेषण पर +1

एनपीएम इंस्टॉल या इसी तरह की पसंद के लिए निर्माण के दौरान एसएसएच अग्रेषण के लिए +1।

क्या ओएसएक्स पर चलने के दौरान किसी को एसएसएच अग्रेषण काम कर रहा है? मैंने यहां एक प्रश्न रखा है: http://stackoverflow.com/questions/27036936/using-ssh-agent-with-docker/27044586?noredirect=1#comment42633776_27044586 ऐसा लगता है कि OSX के साथ यह संभव नहीं है...

+1 =(

बस इस रोडब्लॉक को भी हिट करें। एक निजी रेपो पर इंगित npm install चलाने की कोशिश कर रहा है। सेटअप जैसा दिखता है:
host -> vagrant -> docker एसएसएच-एजेंट अग्रेषित कर सकते हैं host -> vagrant -! docker

+1
'डॉकर बिल्ड' के दौरान काम करने वाले ssh एजेंट को कैसे प्राप्त करें, यह जानने की कोशिश करते हुए बस इसे हिट करें।

+1 पिछले लोगों की तरह ही। डॉकर छवि बनाते समय एक या अधिक निजी गिट रिपॉजिटरी (उदाहरण के लिए bundle install और npm install ) तक पहुंचने की आवश्यकता होने पर इस मुद्दे का सबसे अच्छा समाधान लगता है।

मैं अपने होस्ट ~/.ssh डायरेक्टरी को डॉक रन के दौरान अपने कंटेनर में वॉल्यूम माउंट कर सकता हूं और ssh सब अच्छा है।

@razic क्या आप साझा कर सकते हैं कि आप इसे कैसे काम करते हैं? क्योंकि जब मैंने कोशिश की कि इससे पहले "खराब मालिक या अनुमतियां" के बारे में शिकायत की जाए

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

+1 से SSH_AUTH_SOCK

@tonivdv इस मुद्दे पर प्रारंभिक टिप्पणी में docker run कमांड पर एक नज़र डालें। यह बाइंड कंटेनर के अंदर SSH_AUTH_SOCK से /tmp/ssh_auth_sock द्वारा निर्दिष्ट पथ को माउंट करता है, फिर कंटेनर में SSH_AUTH_SOCK को उस पथ पर सेट करता है।

@ md5 मुझे लगता है कि @razic और @tonivdv इस तरह से माउंटिंग के बारे में बात कर रहे हैं: -v ~/.ssh:/root/.ssh:ro , लेकिन जब आप ऐसा करते हैं तो .ssh फाइलें रूट के स्वामित्व में नहीं होती हैं और इसलिए सुरक्षा जांच में विफल हो जाती हैं।

@KyleJamesWalker हाँ, मैं @razic से हूं और जो कुछ समय पहले मेरे प्रयासों में से एक था, इसलिए जब मैंने पढ़ा तो @razic इसे काम करने में सक्षम था, मैं सोच रहा था कि कैसे :)

@tonivdv मुझे यह जानना अच्छा लगेगा कि क्या यह संभव है, जब मैंने आखिरी बार कोशिश की तो मुझे कुछ भी नहीं मिला।

+1 मुझे डॉकर का उपयोग करके डिस्पोजेबल देव वातावरण बनाने में दिलचस्पी है लेकिन मैं इसे काफी काम नहीं कर सकता। इससे इस संबंध में काफी मदद मिलेगी।

अस्थायी समाधान की तलाश करने वाले किसी भी व्यक्ति के लिए, मेरे पास एक फिक्स है जिसका उपयोग मैं करता हूं कि कौन सी जानवर चीजों को बल देता है:

https://github.com/atrauzzi/docker-laravel/blob/master/images/php-cli/entrypoint.sh

यह किसी भी तरह से एक वांछनीय समाधान नहीं है क्योंकि इसके लिए संपूर्ण एंट्रीपॉइंट स्क्रिप्ट की आवश्यकता होती है, लेकिन यह काम करता है।

@atrauzzi दिलचस्प दृष्टिकोण। हमारे देव env के लिए हम एक आधार छवि बनाते हैं और उसमें सीधे ssh कुंजी को कॉपी करते हैं। प्रत्येक रन पर इसे प्रदान करने की आवश्यकता नहीं होने का इसका लाभ है। और डिफ़ॉल्ट रूप से उस दाना से विरासत में मिली प्रत्येक छवि में भी कुंजी होती है। हालाँकि हमारे तरीके से आप इसे सार्वजनिक रूप से स्पष्ट रूप से साझा नहीं कर सकते ;p

+1 यह बहुत अच्छा होगा

@tonivdv जिस कंटेनर के लिए स्क्रिप्ट है, उसे अक्सर बनाया और नष्ट किया जाता है क्योंकि यह CLI टूल के लिए सिर्फ एक होस्ट है। आप निश्चित रूप से केवल एक बार ऑपरेशन करने के लिए स्वतंत्र हैं। लेकिन अगर कोई अपनी सेटिंग्स बदलता है और कंटेनर के माध्यम से कमांड को फिर से चलाता है, तो उसे हर बार एक नई कॉपी बनानी होगी।

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

:+1: बिल्ड के माध्यम से ssh अग्रेषण के लिए

यहाँ भी होना चाहिए!

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

docker run -ti --volumes-from ssh-data ...

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

उस कंटेनर को बनाने के लिए मैं निम्नलिखित कार्य करता हूं:

docker run \
  --name ssh-data \
  -v /root/.ssh \
  -v ${USER_PRIVATE_KEY}:/root/.ssh/id_rsa \
  busybox \
  sh -c 'chown -R root:root ~/.ssh && chmod -R 400 ~/.ssh'

उम्मीद है कि यह दूसरों की मदद कर सकता है :)

चियर्स

@tonivdv - मैंने अपना दृष्टिकोण लिया क्योंकि अगर किसी को SSH सेटिंग्स को जोड़ना या अपडेट करना है, तो उन्हें फिर से आयात करना होगा। मैं जिस विशिष्ट कंटेनर का उपयोग कर रहा हूं वह वह है जो एकल कमांड चलाने के लिए बनाया गया है, इसलिए हर बार जब यह चलता है, तो यह सुनिश्चित करने के लिए प्रतिलिपि लेता है कि यह अद्यतित है।

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

मैं इसे एक आवश्यकता नहीं बनाऊंगा कि आपके कंटेनर चलाने वाले लोग एसएसएच कुंजी से भरा डेटा-केवल कंटेनर बनाए रखें। शामिल लगता है।

@atrauzzi यह सच है कि वॉल्यूम कंटेनर होना चाहिए, लेकिन आपके तरीके से उपयोगकर्ता को सही चलने पर इसकी ssh कुंजी साझा करनी चाहिए? तो एक ssh वॉल्यूम कंटेनर की आवश्यकता के अलावा, दोनों समाधानों में एक चल रहे दृष्टिकोण से एकमात्र अंतर है:

docker run ... --volumes-from ssh-data ... php-cli ...

तथा

docker run ... -v ~/.ssh:/path/.host-ssh ... php-cli ..

अधिकार? या क्या मुझे कुछ और याद आ रहा है :)

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

जैसा कि मैंने कहा, दोनों एक काम के आसपास हैं और दोनों के पक्ष और विपक्ष हैं।

चियर्स

इस सुविधा की स्थिति के बारे में डॉकर टीम से अपडेट प्राप्त करना वास्तव में बहुत अच्छा होगा। विशेष रूप से, SSH प्रमाणीकरण docker build ।

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

एक अद्यतन की अत्यधिक सराहना की जाएगी। कृपया और धन्यवाद।

/सीसी @ फेमर

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

@jfrazelle

मुझे पता है कि आप लोग हमें अनदेखा नहीं कर रहे हैं :)

तो स्थिति है:

अगर कोई स्वीकृत प्रस्ताव है तो हम इसे लागू करने पर विचार करेंगे
और इंजीनियरिंग बैंडविड्थ।

क्या यह आपको सही लगता है?

साथ ही, क्या वर्तमान में कोई खुला प्रस्ताव है जो इस मुद्दे का समाधान करता है?

मंगलवार, 7 अप्रैल, 2015 को, जेसी फ्रैज़ेल नोटिफिकेशन @github.com ने लिखा:

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

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

अगर कोई स्वीकृत प्रस्ताव है तो हम इसे लागू करने पर विचार करेंगे
और इंजीनियरिंग बैंडविड्थ।

हां

और मैं नहीं समझता कि इसके लिए कोई खुला प्रस्ताव है।

मंगलवार, 7 अप्रैल, 2015 दोपहर 2:36 बजे, ज़ाचरी एडम कपलान <
सूचनाएं@github.com> ने लिखा:

@jfrazelle

मुझे पता है कि आप लोग हमें अनदेखा नहीं कर रहे हैं :)

तो स्थिति है:

अगर कोई स्वीकृत प्रस्ताव है तो हम इसे लागू करने पर विचार करेंगे
और इंजीनियरिंग बैंडविड्थ।

क्या यह आपको सही लगता है?

साथ ही, क्या वर्तमान में कोई खुला प्रस्ताव है जो इस मुद्दे का समाधान करता है?

मंगलवार, 7 अप्रैल, 2015 को, जेसी फ्रैज़ेल नोटिफिकेशन @github.com
लिखा था:

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

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

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

मुझे नहीं पता कि मैं चीजों को सरल बना रहा हूं या नहीं, लेकिन यह मेरा प्रस्ताव है:

SSHAGENT: फॉरवर्ड # डिफॉल्ट्स को अनदेखा करने के लिए

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

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

महान। मैं कहां पता लगा सकता हूं कि प्रस्ताव कैसे प्रस्तुत किया जाए? वहां एक
विशिष्ट दिशानिर्देश या क्या मुझे सिर्फ एक मुद्दा खोलना चाहिए?

मंगलवार, 7 अप्रैल, 2015 को, जेसी फ्रैज़ेल नोटिफिकेशन @github.com ने लिखा:

यह कुछ ऐसा है जिसे हम लागू करने पर विचार करेंगे यदि कोई स्वीकृत है
प्रस्ताव
और इंजीनियरिंग बैंडविड्थ।

हां

और मैं नहीं समझता कि इसके लिए कोई खुला प्रस्ताव है।

मंगलवार, 7 अप्रैल, 2015 दोपहर 2:36 बजे, ज़ाचरी एडम कपलान <
सूचनाएं@github.com
<_e मैं="18">

@jfrazelle

मुझे पता है कि आप लोग हमें अनदेखा नहीं कर रहे हैं :)

तो स्थिति है:

यह कुछ ऐसा है जिसे हम लागू करने पर विचार करेंगे यदि कोई स्वीकृत है
प्रस्ताव
और इंजीनियरिंग बैंडविड्थ।

क्या यह आपको सही लगता है?

साथ ही, क्या वर्तमान में कोई खुला प्रस्ताव है जो इस मुद्दे का समाधान करता है?

मंगलवार, 7 अप्रैल, 2015 को, जेसी फ्रैज़ेल < सूचनाएं @github.com
<_e i="31"/> ने लिखा:

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

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

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

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

मेरा मतलब एक डिजाइन प्रस्ताव की तरह है
https://docs.docker.com/project/advanced-contributing/#design -proposal

मंगलवार, 7 अप्रैल, 2015 दोपहर 2:39 बजे, डेनियल स्टॉडिगेल नोटिफिकेशन @github.com
लिखा था:

मुझे नहीं पता कि मैं चीजों को सरल बना रहा हूं या नहीं, लेकिन यह मेरा प्रस्ताव है:

SSHAGENT: फॉरवर्ड # डिफॉल्ट्स को अनदेखा करने के लिए

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

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

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

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

इसका उपयोग कई मुद्दों को हल करने के लिए किया जा सकता है।

• यह डेमॉन PID 1 होगा, और मुख्य कंटेनर प्रक्रिया PID 2 होगी। यह PID 1 के संकेतों और कंटेनरों को ठीक से बंद नहीं करने के साथ सभी मुद्दों को हल करेगा। (#3793)
• यह SSH कुंजी एजेंट को स्पष्ट रूप से अग्रेषित करने की अनुमति देगा। (#6396)
• यह डेमॉन नेमस्पेस को खुला रख सकता है (#12035)
• डेमॉन द्वारा एक TTY बनाया जाएगा (#11462)
• ... और शायद कई अन्य मुद्दे जो मैं भूल रहा हूँ।

आप इसके बारे में https://github.com/docker/docker/issues/11529 देखना
पहली गोली बिंदु

मंगलवार, 7 अप्रैल, 2015 दोपहर 2:46 बजे, पैट्रिक हेमर सूचनाएं @github.com
लिखा था:

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

इसका उपयोग कई मुद्दों को हल करने के लिए किया जा सकता है।

• यह डेमॉन PID 1 होगा, और मुख्य कंटेनर प्रक्रिया होगी
  पीआईडी ​​2। यह पीआईडी ​​1 के साथ सभी मुद्दों को हल करेगा और संकेतों की अनदेखी करेगा
  कंटेनर ठीक से बंद नहीं हो रहे हैं। (#3793
  https://github.com/docker/docker/issues/3793
• यह SSH कुंजी एजेंट को स्पष्ट रूप से अग्रेषित करने की अनुमति देगा। (#6396
  https://github.com/docker/docker/issues/6396
• यह डेमॉन नेमस्पेस को खुला रख सकता है (#12035
  https://github.com/docker/docker/issues/12035)
• डेमॉन द्वारा एक TTY बनाया जाएगा (#11462
  https://github.com/docker/docker/issues/11462)
• ... और शायद कई अन्य मुद्दे जो मैं भूल रहा हूँ।

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

11529 पीआईडी ​​1 मुद्दे से पूरी तरह से असंबंधित है।

प्रभावशाली कॉपी पेस्ट शूट करें, अब मुझे फिर से दूसरा ढूंढना होगा

नहीं, यह वह है, यह पीआईडी ​​​​1 ज़ोंबी चीजों को ठीक करता है, जो मैंने सोचा था कि आप इसका जिक्र कर रहे थे, लेकिन परवाह किए बिना मैं सिर्फ पोस्ट कर रहा था क्योंकि यह सब कुछ है

@phemmer ऐसा लगता है कि आपके पास कार्यान्वयन के लिए एक बुद्धिमान प्रस्ताव बनाने में हमारा मार्गदर्शन करने की विशेषज्ञता है।

यह भी @dts जैसा दिखता है और मैं इस पर काम करने के लिए समय बिताने को तैयार हूं।

@phemmer और @dts क्या कोई संभावित तरीका है

@phemmer ऐसा लगता है कि आपके पास कार्यान्वयन के लिए एक बुद्धिमान प्रस्ताव बनाने में हमारा मार्गदर्शन करने की विशेषज्ञता है

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

यहाँ पहले से ही कुछ प्रस्ताव हैं:

@phemmer ने सुझाव दिया

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

@dts ने सुझाव दिया

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

@razic ने सुझाव दिया

docker build लिए वॉल्यूम बाइंडिंग सक्षम करें।

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

@jfrazelle कोई विचार है कि हम अगले चरण पर कैसे

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

@dts ने सुझाव दिया

SSHAGENT: फॉरवर्ड # डिफॉल्ट्स को अनदेखा करने के लिए

यह सिर्फ एक विचार है कि इसका उपभोग कैसे किया जाएगा, लागू नहीं किया जाएगा। "init/ssh daemon" एक विचार है कि इसे कैसे कार्यान्वित किया जाएगा। दोनों मौजूद हो सकते हैं।

@razic ने सुझाव दिया

डोकर रन के लिए वॉल्यूम बाइंडिंग सक्षम करें।

दुर्भाग्य से यह काम नहीं करेगा। यह मानते हुए कि इसका मतलब है docker build , न कि docker run , जो पहले से ही वॉल्यूम माउंट का समर्थन करता है, वहां क्लाइंट रिमोट हो सकता है (boot2docker एक प्रमुख उदाहरण है)। वॉल्यूम बाइंड केवल तभी काम करता है जब क्लाइंट उसी होस्ट पर होता है जिस पर डॉकर डेमॉन होता है।

@razic कृपया डिज़ाइन प्रस्ताव के बारे में यह लिंक देखें... वे प्रस्ताव नहीं हैं https://docs.docker.com/project/advanced-contributing/#design -proposal

@ फेमर

मैं ठीक से समझ नहीं पा रहा हूं कि यह काम क्यों नहीं कर सकता। docker-compose एक swarm क्लस्टर के मुकाबले वॉल्यूम माउंट के साथ काम करता है। यदि फ़ाइल/फ़ोल्डर होस्ट सिस्टम पर नहीं है, तो यह वैसा ही व्यवहार करता है जैसे कि आपने -v को ऐसे पथ के साथ चलाया जो मौजूद नहीं है।

@jfrazelle समझ गया।

यदि फ़ाइल/फ़ोल्डर होस्ट सिस्टम पर नहीं है, तो यह उसी तरह का व्यवहार करता है जैसे कि आप -v उस पथ के साथ चलते हैं जो स्थानीय डॉकर पर मौजूद नहीं है।

मुझे यकीन नहीं है कि मैं आपकी बात का पालन करता हूं। वह व्यवहार इस मुद्दे में कैसे मदद करता है?
अगर मेरे पास एक एसएसएच कुंजी एजेंट है जो मेरी स्थानीय मशीन पर /tmp/ssh-UPg6h0 सुन रहा है, और मेरे पास रिमोट मशीन पर चलने वाला डॉकर है, और docker build कॉल करें, तो स्थानीय एसएसएच कुंजी एजेंट तक पहुंच योग्य नहीं है डोकर डेमन। वॉल्यूम माउंट इसे प्राप्त नहीं करेगा, और docker build कंटेनरों के पास ssh कुंजी तक पहुंच नहीं होगी।

उच्च स्तर से, मुझे इसे हल करने के केवल 2 तरीके दिखाई देते हैं:

1. एसएसएच कुंजी एजेंट सॉकेट प्रॉक्सी करें:

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

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

हालाँकि अब जब डॉकर रिमोट एपीआई वेबसोकेट का समर्थन करता है (यह उस समय नहीं था जब यह मुद्दा बनाया गया था), यह बहुत कठिन नहीं हो सकता है।

2. एक वास्तविक SSH डेमॉन प्रारंभ करें

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

तो अंततः बहुत बड़े पैमाने पर परिवर्तन होता है, लेकिन यह एक अधिक उचित समाधान हो सकता है।
हालांकि वास्तविक रूप से, पैमाने के कारण, मुझे संदेह है कि ऐसा होगा।

@ फेमर

मुझे यकीन नहीं है कि मैं आपकी बात का पालन करता हूं। वह व्यवहार इस मुद्दे में कैसे मदद करता है?

क्योंकि इसके लिए सबसे आम उपयोग का मामला उन लोगों के साथ छवियों का निर्माण करना है जो निजी रिपॉजिटरी में होस्ट किए जाते हैं जिन्हें एसएसएच प्रमाणीकरण की आवश्यकता होती है।

आप छवि को उस मशीन पर बनाते हैं जिसमें SSH कुंजी होती है। यह सरल है।

अगर मेरे पास एक ssh कुंजी एजेंट है जो मेरी स्थानीय मशीन पर /tmp/ssh-UPg6h0 सुन रहा है, और मेरे पास रिमोट मशीन पर चलने वाला डॉकर है, और डॉकर बिल्ड को कॉल करता है, तो स्थानीय एसएसएच कुंजी एजेंट डॉकर डेमॉन तक पहुंच योग्य नहीं है।

मैं जानता हूँ। किसे पड़ी है? मैं उस मशीन पर docker build चला रहा हूँ, जिसके पास ऑथ सॉकेट तक पहुँच है।

मैं जो कहने की कोशिश कर रहा हूं वह है... docker-compose आपको वॉल्यूम कमांड का उपयोग swarm क्लस्टर के खिलाफ करने की अनुमति देता है, भले ही फ़ाइल वास्तव में होस्ट पर हो या नहीं! .

हमें डोकर बिल्ड पर वॉल्यूम माउंट के लिए भी यही काम करना चाहिए।

| फाइल सिस्टम पर है | एक्शन |
| :-- | :-- |
| हाँ | माउंट |
| नहीं | कोई नहीं (वास्तव में यह माउंट करने की कोशिश करता है लेकिन एक खाली फ़ोल्डर बनाता है यदि फ़ाइल/फ़ोल्डर मौजूद नहीं है, तो आप docker run -v /DOES_NOT_EXIST:/DOES_NOT_EXIST ubuntu ls -la /DOES_NOT_EXIST चलाकर इसे सत्यापित कर सकते हैं) |

swarm पीछे एक अवधारणा बहु-होस्ट मॉडल को पारदर्शी बनाना है।

यह अच्छा है कि हम रिमोट डॉकटर के बारे में सोच रहे हैं, लेकिन यह वास्तव में मायने नहीं रखना चाहिए।

हमें docker build लिए वॉल्यूम माउंटिंग के व्यवहार को ठीक उसी तरह कॉपी करना चाहिए जैसे हम docker run ।

https://github.com/docker/compose/blob/master/SWARM.md से :

मल्टी-कंटेनर ऐप्स को झुंड पर मूल रूप से काम करने से रोकने वाली प्राथमिक बात उन्हें एक दूसरे से बात करने के लिए मिल रही है: विभिन्न मेजबानों पर कंटेनरों के बीच निजी संचार को सक्षम करना गैर-हैकी तरीके से हल नहीं किया गया है।

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

@phemmer मुझे लगता है कि लोग शायद आपके द्वारा वर्णित समस्या के समाधान के बारे में सोच रहे हैं। आप जिस समस्या का वर्णन कर रहे हैं वह https://github.com/docker/docker/issues/7249 जैसी लगती है जो अलग है।

यदि हम अपना दृष्टिकोण लेते हैं: बस डॉक बिल्ड में वॉल्यूम माउंटिंग की अनुमति देना (भले ही आप जिस फ़ाइल को माउंट करने का प्रयास कर रहे हैं वह वास्तव में सिस्टम पर है , तो हम इस मुद्दे को बंद कर सकते हैं। और https://github.com/ पर काम करना शुरू

@ cpuguy83 प्रस्ताव बनाने से पहले, मैं #7133 देख रहा था और देखा कि यह सीधे संबंधित दिखता है।

क्या आप यहाँ कुछ शब्द जोड़ सकते हैं? क्या #7133 वास्तव में इस मुद्दे को ठीक करने के मेरे सुझाव से संबंधित है, जो कि वॉल्यूम का समर्थन करने के लिए docker build अनुमति देना है।

@razic यह इस तथ्य के संबंध में है कि VOLUME /foo वास्तव में एक वॉल्यूम बनाता है और इसे निर्माण के दौरान कंटेनर में माउंट करता है, जो आमतौर पर अवांछनीय है।

मैं यह भी कहूंगा कि बिल्ड कंटेनरों में फाइलें प्राप्त करने के लिए बाइंड-माउंट का उपयोग करने के आधार पर एक प्रस्ताव शायद उड़ने वाला नहीं है।
देखें #6697

रनिंग -v डॉकटर बिल्ड के साथ एक अलग कोड निष्पादन पथ हो सकता है।
वॉल्यूम बनाने और बिल्ड के दौरान इसे माउंट करने के बजाय हम इसे बरकरार रख सकते हैं
वर्तमान व्यवहार जो dockerfiles में वॉल्यूम को संदर्भित नहीं करता है। और
इसके बजाय केवल -v पर कार्य करें जब सीएलआई को तर्कों का उपयोग करके चलाया जाए।

बुधवार, 8 अप्रैल, 2015 को, ब्रायन गोफ नोटिफिकेशन @github.com ने लिखा:

@razic https://github.com/razic यह इस तथ्य के संबंध में है कि VOLUME
/foo वास्तव में एक वॉल्यूम बनाता है और इसे कंटेनर में माउंट करता है
निर्माण, जो आम तौर पर अवांछनीय है।

मैं फाइलों को प्राप्त करने के लिए बाइंड-माउंट का उपयोग करने के आधार पर एक प्रस्ताव भी कहूंगा
बिल्ड कंटेनर शायद उड़ने वाला नहीं है।
देखें #6697 https://github.com/docker/docker/pull/6697

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

@ cpuguy83 स्पष्टीकरण के लिए धन्यवाद।

6697 भी उड़ान भरने वाला नहीं है क्योंकि यह पहले से ही बंद है और #10310 व्यावहारिक रूप से #6697 का एक धोखा है।

+1, मैंने रेल ऐप के लिए एक छवि बनाने की कोशिश करते समय आज इसे मारा जो क्लाइंटसाइड निर्भरताओं को स्थापित करने के लिए बोवर का उपयोग करता है। ऐसा होता है कि निर्भरताओं में से एक [email protected]:angular/bower-angular-i18n.git को इंगित करता है और चूंकि गिट वहां विफल रहता है, बोवर विफल हो जाता है, और छवि निर्माण भी विफल हो जाता है।

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

इसके अलावा, एक अतिरिक्त नोट के रूप में, इस छवि का निर्माण हो रहा है। क्या किसी को मौजूदा कामकाज के बारे में पता है?

मेरा कामकाज, एक नया आरएसए कीपेयर उत्पन्न करना था, जीथब पर पब कुंजी सेट करना (फिंगरप्रिंट जोड़ें), और डॉकर छवि में निजी कुंजी जोड़ें:

ADD keys/docker_rsa /srv/.ssh/id_rsa

मुझे इससे बचना अच्छा लगेगा, लेकिन मुझे लगता है कि यह अभी के लिए स्वीकार्य है। किसी अन्य सुझाव की सराहना की!

मुझे यकीन नहीं है कि किसने अधिक पिल्लों को मार डाला है। आप ऐसा करने के लिए, या डॉकर आपको अभी तक एक बेहतर तरीका प्रदान नहीं करने के लिए।

किसी भी मामले में मैं शायद इस सप्ताह के अंत में एक प्रस्ताव प्रस्तुत करने जा रहा हूँ। @cpuguy83 सही है कि लोग कम से कम इस बारे में सोच रहे हैं और संभावित समाधानों पर चर्चा कर रहे हैं। तो इस समय यह केवल हमारे लिए किसी बात पर सहमत होने और किसी को उस पर काम करने की बात है। मैं इस पर काम करने के लिए पूरी तरह से तैयार हूं क्योंकि यह वास्तव में वर्तमान में डॉकर के साथ मेरी सबसे बड़ी पकड़ है।

@razic यह काफी सामान्य उपयोग-मामला है, इसलिए इसे देखने के लिए भी धन्यवाद। कामकाज के लिए, यह काम करता है। संभवत: उपयोग के बाद छवि से कुंजी को हटाया जा सकता है, आखिरकार, इसका उपयोग केवल जीथब से एप्लिकेशन का कोड प्राप्त करने के लिए किया जाता है।

@fullofcaffeine मुझे 100% यकीन नहीं है कि डॉकर आंतरिक रूप से कैसे काम करता है, लेकिन मुझे लगता है कि जब तक यह एक एकल RUN कमांड (जो आपके वर्कअराउंड के साथ असंभव है) में नहीं किया जाता है, तब तक छवि का इतिहास SSH कुंजी को बनाए रखता है।

@razic अच्छा बिंदु।

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

चूंकि हम यह सब एक ही RUN ,

RUN ONVAULT npm install --unsafe-perm

इस अवधारणा के आसपास हमारा पहला कार्यान्वयन https://github.com/dockito/vault . पर उपलब्ध है

एकमात्र दोष HTTP सर्वर को चलाने की आवश्यकता है, इसलिए कोई डॉकर हब नहीं बनाता है।

आप क्या सोचते हैं मुझे बताओ :)

+1
इसे लागू होते हुए देखना अच्छा लगेगा, इससे विकास के माहौल के लिए कंटेनर स्थापित करने में मदद मिलेगी

+1, बस ssh-agent को boot2dock के साथ अग्रेषित करने की आवश्यकता है

हमने इस सीमा को पार करने के लिए 3 चरणों की प्रक्रिया पूरी की है:

1. एसएसएच-आवश्यक निर्भरता के बिना डॉकटर कंटेनर बनाएं, अंतिम चरण में स्रोत जोड़ें
2. साझा वॉल्यूम के माध्यम से स्रोत माउंट करें, साथ ही साझा वॉल्यूम के माध्यम से SSH_AUTH_SOCK और बिल्ड चरण चलाएं, ssh-आवश्यक आउटपुट (कहते हैं, github होस्ट किए गए रूबी रत्न) को साझा वॉल्यूम में वापस लिखें
3. डॉकर बिल्ड को फिर से चलाएं, जो सोर्स ऐड को फिर से ट्रिगर करेगा, क्योंकि रत्न अब सोर्स डायरेक्टरी में बैठे हैं

परिणाम SSH-auth के माध्यम से खींची गई निर्भरता के साथ एक डॉकटर छवि है जिसमें कभी भी SSH कुंजी नहीं थी।

मैंने कम से कम परेशानी के साथ OSX पर एक boot2docker वातावरण में docker run लिए ssh एजेंट अग्रेषण को सक्षम करने के लिए एक स्क्रिप्ट बनाई। मुझे पता है कि यह बिल्ड समस्या को हल नहीं करता है, लेकिन कुछ के लिए उपयोगी हो सकता है:

https://gist.github.com/rcoup/53e8dee9f5ea27a51855

क्या फॉरवर्ड एसएसएच कुंजी एजेंट अमेज़ॅन ईसी 2 कंटेनर सेवा जैसी सेवाओं के साथ काम करता है? मुझे ऐसा लगता है कि इसके लिए एक विशिष्ट सॉफ़्टवेयर की आवश्यकता होगी जो सभी प्लेटफ़ॉर्म या PaS पर उपलब्ध नहीं हो सकता है जिसका उपयोग आप अपने कंटेनरों को तैनात करने के लिए कर रहे हैं।

एक अधिक सामान्य, सभी के लिए काम करने वाला, समाधान आवश्यक है।

वर्तमान में, मैं पर्यावरण चर का उपयोग कर रहा हूँ। एक बैश स्क्रिप्ट निजी कुंजी (और ज्ञात होस्ट) चर प्राप्त करती है और इसे id_rsa और ज्ञात_होस्ट फ़ाइलों पर प्रिंट करती है। यह काम करता है, लेकिन मुझे अभी तक इस तरह के समाधान के सुरक्षा प्रभावों का मूल्यांकन करना है।

एफडब्ल्यूआईडब्ल्यू, मैंने पाया है कि एक कंटेनरीकृत एसएसएच-एजेंट और वॉल्यूम साझाकरण न्यूनतम नासमझी के साथ अच्छी तरह से काम करता है:

https://github.com/whilp/ssh-agent

हालाँकि, इसके लिए प्रथम श्रेणी का समर्थन प्राप्त करना बहुत अच्छा होगा।

यह अंतर करना महत्वपूर्ण है कि _run_ बनाम _build_ में क्या काम करता है। @whilp का समाधान _run_ में आश्चर्यजनक रूप से काम करता है लेकिन _build_ में काम नहीं करता है क्योंकि आप _build_ के दौरान अन्य डॉकर के वॉल्यूम तक नहीं पहुंच सकते हैं। इसलिए क्यों यह टिकट अभी भी एक दर्द, खुला दर्द है।

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

क्या कंटेनर चलाने के लिए IP निर्माण के दौरान /etc/hosts में शामिल हैं? यदि ऐसा है, तो एक समाधान एक कंटेनर शुरू करना हो सकता है जो चाबियों की सेवा करता है, फिर निर्माण के दौरान इसे कर्ल करें।

आप सभी को यह जानने में दिलचस्पी हो सकती है कि मैंने docker build दौरान आपके SSH एजेंट का उपयोग करने के तरीके के बारे में ब्लॉग किया है - http://aidanhs.com/blog/post/2015-10-07-dockerfiles-reproducibility- ट्रिकरी/#_स्ट्रीमलाइनिंग_आपका_अनुभव_का उपयोग करना_an_ssh_agent

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

कुछ चेतावनी: आपको डॉकर> = 1.8 की आवश्यकता है, और यह डॉकर हब स्वचालित निर्माण (जाहिर है) पर काम नहीं करेगा। कृपया सुरक्षा पर नोट भी पढ़ें! sshagent github रिपॉजिटरी में मुद्दों को उठाने के लिए स्वतंत्र महसूस करें, यदि आपको कोई समस्या है तो मैं पोस्ट में लिंक करता हूं।

मैंने इस समस्या को @aidanhs के समान तरीके से
https://github.com/mdsol/docker-ssh-exec

क्या इसे संभव बनाने में कोई प्रगति हुई है? मैं होस्ट की ~/.ssh निर्देशिका को बाइंड-माउंट करने में असमर्थ हूं क्योंकि अनुमतियां और स्वामित्व गड़बड़ हो जाते हैं।

क्या यह विशिष्ट uid/gid और अनुमतियों को बाध्य करने के लिए बाइंड माउंट की अनुमति देकर हल करने योग्य नहीं होगा?

@atrauzzi बाइंड-माउंट यूआईडी/जीआईडी/अनुमतियों को बाध्य नहीं कर सकता है।
इसे FUSE (जैसे बाइंडफ़्स) के माध्यम से कर सकते हैं, लेकिन केवल सामान्य बाइंड माउंट के साथ नहीं।

@ cpuguy83 वह वास्तव में मुझे उन सड़कों पर ले जाना शुरू कर देता है

क्या यहां कोई उपयोगकर्ता के अनुकूल विकल्प नहीं है? मुझे ऐसा लग रहा है कि यहाँ कोई समस्या है जिसे अभी टाला जा रहा है।

@atrauzzi वास्तव में, तत्काल अवधि में हल करना आसान समस्या नहीं है (वैसे भी मूल रूप से नहीं)।

+1 यह अन्यथा सरल Node.js ऐप Dockerfile के लिए एक बड़ा अवरोधक है। मैंने कई नोड ऐप्स पर काम किया है, और मैंने शायद ही कभी ऐसा देखा है जिसमें एनपीएम निर्भरता के रूप में निजी जीथब रेपो नहीं है।

वर्कअराउंड @apeace के रूप में , आप उन्हें अपने git रेपो में git .git फ़ाइल को हटा दें या अनदेखा करें। डॉकर बिल्ड में, उन्हें केवल स्थानीय निर्देशिका का उपयोग करके स्थापित किया जा सकता है। अगर उन्हें किसी कारण से पूर्ण गिट रेपो होने की आवश्यकता है, तो सुनिश्चित करें कि .git फ़ाइल डॉकर बिल्ड में मौजूद नहीं है और .git/modules/<repo> को <path>/<repo>/.git । यह सुनिश्चित करेगा कि वे सामान्य रेपो हैं जैसे कि उन्हें क्लोन किया गया था।

उस सुझाव के लिए धन्यवाद @jakirkham , लेकिन हम इतने लंबे समय से एनपीएम निर्भरता के रूप में निजी रेपो का उपयोग कर रहे हैं, मैं सामान्य npm install वर्कफ़्लो को तोड़ना नहीं चाहता।

अभी के लिए, हमारे पास एक समाधान है जो काम करता है लेकिन बस मुश्किल है। हमारे पास है:

• एक जीथब उपयोगकर्ता और टीम बनाई, जिसके पास एनपीएम निर्भरता के रूप में हमारे द्वारा उपयोग किए जाने वाले रेपो तक केवल-पढ़ने की पहुंच है
• उस उपयोगकर्ता की निजी कुंजी को हमारे रेपो के लिए प्रतिबद्ध किया जहां हमारे पास हमारी डॉकरफाइल है
• Dockerfile में, RUN npm install बजाय हम RUN GIT_SSH='/code/.docker/git_ssh.sh' npm install

जहां git_ssh.sh इस तरह की एक स्क्रिप्ट है:

#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /code/.docker/deploy_rsa "$@"

यह काम करता है, लेकिन एसएसएच कुंजी एजेंट को अग्रेषित करना इतना अच्छा होगा, और बहुत कम सेटअप काम होगा!

:+1:
विश्वास नहीं हो रहा है कि यह सुविधा अनुरोध अभी भी लागू नहीं किया गया है क्योंकि यहां बहुत सारे उपयोग के मामले हैं जहां लोगों को निर्माण समय के दौरान निजी रेपो से पहुंच की आवश्यकता होती है।

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

:+1:

:+1: हमेशा से इसकी आवश्यकता रही है।

हाय @apeace , मुझे नहीं पता कि आपने इसे देखा है, लेकिन मैंने पहले इस समस्या के समाधान के बारे में टिप्पणी की है।

यह एक स्क्रिप्ट और एक वेब सर्वर का संयोजन है। आपको क्या लगता है https://github.com/dockito/vault ?

@pirelenito वह कुंजी अभी भी निर्माण की एक परत के भीतर उपलब्ध नहीं

@apeace ONVAULT स्क्रिप्ट चाबियों को

@apeace मेडिडेटा में, हम एक छोटे से टूल का उपयोग कर रहे हैं जिसे हमने docker -ssh-exec कहा है । यह परिणामी निर्माण छवि में केवल docker-ssh-exec बाइनरी छोड़ता है - कोई रहस्य नहीं। और इसके लिए Dockerfile केवल एक-शब्द परिवर्तन की आवश्यकता है, इसलिए यह बहुत "निम्न-पदचिह्न" है।

लेकिन अगर आपको _really_ एक docker-native-only समाधान का उपयोग करने की आवश्यकता है, तो ऐसा करने के लिए अब एक अंतर्निहित तरीका है, जैसा कि कंपनी ब्लॉग पोस्ट में बताया गया है। डॉकर 1.9 आपको निर्माण प्रक्रिया में क्षणिक मूल्यों को पारित करने के लिए --build-arg पैरामीटर का उपयोग करने की अनुमति देता है। आप एक निजी SSH कुंजी को ARG रूप में पास करने में सक्षम होना चाहिए, इसे फाइल सिस्टम में लिखें, एक git checkout निष्पादित करें, और फिर _delete_ कुंजी, सभी एक RUN के दायरे में docker-ssh-exec क्लाइंट करता है)। यह एक बदसूरत Dockerfile , लेकिन किसी बाहरी टूलिंग की आवश्यकता नहीं होनी चाहिए।

उम्मीद है की यह मदद करेगा।

@ बेंटन हम एक समान समाधान लेकर आए हैं। :)

धन्यवाद @pirelenito और @benton , मैं आपके सभी सुझावों की जांच करूंगा!

संपादित करें : निम्नलिखित _NOT_ सुरक्षित है, वास्तव में:

रिकॉर्ड के लिए, यहां बताया गया है कि आप परिणामी छवि में अपनी SSH कुंजी को छोड़े बिना जीथब से एक निजी रेपो की जांच कैसे करते हैं।

सबसे पहले, user/repo-name को निम्नलिखित Dockerfile अपने निजी रेपो के पथ से बदलें (सुनिश्चित करें कि आप [email protected] उपसर्ग रखें ताकि चेकआउट के लिए ssh का उपयोग किया जा सके):

FROM ubuntu:latest

ARG SSH_KEY
ENV MY_REPO [email protected]:user/repo-name.git

RUN apt-get update && apt-get -y install openssh-client git-core &&\
    mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
    ssh-keyscan github.com >/root/.ssh/known_hosts

RUN echo "$SSH_KEY" >/root/.ssh/id_rsa &&\
    chmod 0600 /root/.ssh/id_rsa &&\
    git clone "${MY_REPO}" &&\
    rm -f /root/.ssh/id_rsa

फिर कमांड के साथ निर्माण करें

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

आपकी निजी SSH कुंजी के लिए सही रास्ता तय करना।

^ डॉकर 1.9 . के साथ

@ बेंटन आप docker inspect sshtest और docker history sshtest के आउटपुट को करीब से देखना चाहेंगे। मुझे लगता है कि आप पाएंगे कि अंतिम छवि में मेटाडेटा में आपका रहस्य है, भले ही वह कंटेनर संदर्भ में ही उपलब्ध न हो ...

@ljrittle गुड VAR । मुझे लगता है कि यहां अभी भी बाहरी कामकाज की आवश्यकता है।

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

दस्तावेज़ों से...

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

( https://docs.docker.com/engine/reference/builder/#arg )

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

मैं @jcrombez को फॉलो नहीं करता। उदाहरण ARG माध्यम से ssh कुंजी को एक चर के रूप में पास करना था। तो, यह लागू होता है।

सुरक्षा जोखिम के संदर्भ में यह बहुत अलग है:

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

उसके बाद यह :

docker build --tag=sshtest --build-arg SSH_KEY="mykeyisthis" .

अगर किसी को आपका टर्मिनल लॉग मिल जाता है, तो परिणाम समान नहीं होते हैं।
लेकिन मैं सुरक्षा विशेषज्ञ नहीं हूं, यह अभी भी कुछ अन्य कारणों से खतरनाक हो सकता है जिनके बारे में मुझे जानकारी नहीं है।

कमांड लाइन पर, मुझे लगता है।

हालांकि, जैसा कि @ljrittle ने बताया और @benton ने स्वीकार किया, किसी भी तरह से आप --build-arg / ARG का उपयोग बिल्ड में किया जाएगा। इसलिए इसके निरीक्षण से चाबी के बारे में जानकारी सामने आएगी। दोनों राज्य को अंतिम डॉकटर कंटेनर में छोड़ देते हैं और दोनों उस छोर पर समान भेद्यता का सामना करते हैं। इसलिए, डॉकर ऐसा करने के खिलाफ सिफारिश क्यों करता है।

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

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

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

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

@ फ्लेचर91
@बेनलेमासुरियर
@dmuso
@probepark
@ सादा
@ianAndrewClark
@jakirkham
@galindro
@luisguilherme
@अकुर्किन
@allardhoeve
@SevaUA
@sankethkatta
@kouk
@cliffxuan
@ kotlas92
@taion

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

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

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

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

@पार्कनिकर
@दुर्स्क
@adambiggs

सुरक्षा जोखिम के संदर्भ में यह बहुत अलग है:

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

आपके बैश इतिहास के अलावा, वे बिल्कुल वही हैं; ऐसे कई स्थान हैं जहां वह जानकारी समाप्त हो सकती है।

उदाहरण के लिए, मान लें कि सर्वर पर API अनुरोध लॉग किए जा सकते हैं;

यहाँ docker build --tag=sshtest --build-arg SSH_KEY="fooobar" . लिए एक डेमॉन लॉग है

DEBU[0090] Calling POST /v1.22/build
DEBU[0090] POST /v1.22/build?buildargs=%7B%22SSH_KEY%22%3A%22fooobar%22%7D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&shmsize=0&t=sshtest&ulimits=null
DEBU[0090] [BUILDER] Cache miss: &{[/bin/sh -c #(nop) ARG SSH_KEY]}
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] Skipping excluded path: .wh..wh.aufs
DEBU[0090] Skipping excluded path: .wh..wh.orph
DEBU[0090] Applied tar sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef to 91f79150f57d6945351b21c9d5519809e2d1584fd6e29a75349b5f1fe257777e, size: 0
INFO[0090] Layer sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef cleaned up

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

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

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

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

@ सीजे2

मैं एक साधारण रूबी/रैक एप्लिकेशन को कंटेनरीकृत करने की कोशिश कर रहा हूं। जेमफाइल कई निजी रत्नों का संदर्भ देता है। जिस क्षण bundle install शुरू होता है और निजी रेपो तक पहुंचने का प्रयास करता है, मुझे यह त्रुटि मिलनी शुरू हो जाती है

Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

मैं इसे हल करने में सक्षम था लेकिन मेरी निजी कुंजी को उजागर किए बिना नहीं। ऐसा नहीं चलेगा। कृपया एसएसएच प्रमाणीकरण अग्रेषण सक्षम करें।

बिल्ड के दौरान ssh अग्रेषण के लिए +1। इसकी वजह से निजी रेपो के साथ go get उपयोग नहीं कर सकते ;(

इस उपयोग के मामले को सुरक्षित तरीके से सक्षम करने के लिए +1

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

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

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

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

@lukad

बस इस बहुत ही रोचक चर्चा को पढ़कर, मैं सोच रहा हूं कि क्या एक साधारण समाधान इन मुद्दों को हल कर सकता है। मेरे सिर के ऊपर से मैं सोच रहा हूं, डॉकरफाइल में एक विकल्प स्नैपशॉट लेते समय विशिष्ट आंतरिक निर्देशिकाओं/फ़ाइलों को बाहर/अनदेखा करने में सक्षम होना चाहिए। वह कितना मुश्किल हो सकता है?

अर्थात

बहिष्कृत करें .ssh

मैं सोच रहा हूं कि यह सभी चरणों में लागू होगा, इसलिए यदि आपने इसे FROM के बाद रखा है तो आप अपनी चाबियाँ जितनी चाहें जोड़ सकते हैं और सामान्य रूप से बना सकते हैं और कभी भी आपकी छवि में गलती से समाप्त होने वाली चाबियों के बारे में चिंता करने की आवश्यकता नहीं है (दी गई) आपको उन्हें हर कदम पर जोड़ने की आवश्यकता हो सकती है, लेकिन आपको उनके बारे में चिंता करने की ज़रूरत नहीं होगी कि वे एक छवि में समाप्त हो जाएंगे)

@benton का सुझाव ठीक काम करता है, और

निर्माण के दौरान अपनी कुंजी को उजागर करने का एक समान तरीका है:

# Dockerfile
ARG SSH_KEY
RUN eval `ssh-agent -s` > /dev/null \
    && echo "$SSH_KEY" | ssh-add - \
    && git clone [email protected]:private/repository.git

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" .

हा, हालांकि यह वास्तव में वहीं बैठा है यदि आप docker inspect my_tag ..

और, यदि आपके पास id_rsa कुंजी पर पासवर्ड है, तो मुझे लगता है कि आप एक बुरे इंसान हो सकते हैं और करें:

# Dockerfile
ARG SSH_KEY
ARG SSH_PASS
RUN eval `ssh-agent -s` > /dev/null \
    && echo "echo $SSH_PASS" > /tmp/echo_ps && chmod 700 /tmp/echo_ps \
    && echo "$SSH_KEY" | SSH_ASKPASS=/tmp/echo_ps DISPLAY= ssh-add - \
    && git clone [email protected]:private/repository.git
    && rm /tmp/echo_ps

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" --build-arg SSH_PASS=<bad_idea> .

बेशक, यह तर्क देना मुश्किल है कि दूर से भी एक अच्छा विचार है .. लेकिन हम सभी इंसान हैं, मुझे लगता है।

दी, ऐसा करने के सभी सबसे बड़े कारण एक निर्माण के दौरान निजी रिपॉजिटरी के खिलाफ "बंडल इंस्टॉल" या "गो गेट" करने वाले लोगों के लिए प्रतीत होते हैं।

मैं कहूंगा कि केवल विक्रेता आपकी निर्भरता और पूरी परियोजना जोड़ें .. लेकिन, कभी-कभी चीजों को अभी करने की आवश्यकता होती है।

@SvenDowideit @thaJeztah क्या इस समस्या का कोई समाधान है? मैंने धागे का पालन करने की कोशिश की लेकिन एक और धागे को बंद करने और खोलने के बीच और बहुत सारी राय मुझे नहीं पता कि डॉकर टीम क्या करेगी या कब करेगी।

सबसे अच्छा, लेकिन कार्यान्वयन की आवश्यकता है?

डॉकर बिल्ड आपके होस्ट के ssh को प्रॉक्सी करने के लिए बिल्ड के भीतर ssh-agent का उपयोग करता है और फिर उन्हें जाने बिना आपकी कुंजियों का उपयोग करता है!

एसएसएच-एजेंट प्रॉक्सीइंग के बारे में सीखने वाले किसी के लिए: बचाव के लिए जीथब

@phemmer का मूल विचार।

@yordis मुझे नहीं लगता कि धागे में एक "महान" समाधान है जो अभी तक स्वतंत्र रूप से उपलब्ध है।

docker/docker-py#980 की यह टिप्पणी इंगित करती है कि यदि आप अपने होस्ट सिस्टम पर अपने ssh कुंजियों को अपने रूट उपयोगकर्ता की कुंजी निर्देशिका में कॉपी करते हैं तो डेमॉन उन कुंजियों का उपयोग करेगा। हालांकि मैं इस संबंध में पागल नौसिखिया हूं इसलिए कोई और स्पष्ट करने में सक्षम हो सकता है।

ठीक है, लेकिन सबसे अच्छा नहीं

डोकर 1.8 के बिल्ड आर्ग्स के साथ कुंजी पास करना।
चेतावनियाँ ।

निश्चित रूप से एक बुरा विचार

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

यह अभी तक कहीं क्यों नहीं गया?

इसे एक डिजाइन प्रस्ताव की जरूरत है, यह मुद्दा _cah_- _luttered_ है और इस समय विचार केवल अस्पष्ट हैं। वास्तविक कार्यान्वयन विवरण "क्या हुआ अगर हमने x किया" और +1 की धुंध में खोया जा रहा है। संगठित होने और इस अति आवश्यक विशेषता पर आगे बढ़ने के लिए, जिनके पास संभावित समाधान हैं, उन्हें एक . . .

डिजाइन प्रस्ताव

और फिर इस मुद्दे का संदर्भ लें।

मेरे पास इस मुद्दे पर कुछ खबर है।

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

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

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

@ बेंटन मैं इस विषय में वर्णित चीजों को करने के लिए docker-compose.yaml के निम्नलिखित विन्यास का उपयोग करता हूं:

version: '2'
services:
  serviceName:
     volumes:
      - "${SSH_AUTH_SOCK}:/tmp/ssh-agent"
    environment:
      SSH_AUTH_SOCK: /tmp/ssh-agent

सुनिश्चित करें कि ssh- एजेंट होस्ट मशीन पर शुरू हुआ है और कुंजी के बारे में जानता है (आप इसे ssh-add -L कमांड से देख सकते हैं)।

कृपया ध्यान दें कि आपको जोड़ने की आवश्यकता हो सकती है

Host *
  StrictHostKeyChecking no

कंटेनर के .ssh/config.

हाय @WoZ! आपके उत्तर के लिए धन्यवाद, काफी आसान लग रहा है इसलिए मैं इसे आज़मा दूंगा :)

हालांकि, मेरे पास एक प्रश्न है, आप इसे डॉकर हब में स्वचालित बिल्ड के साथ कैसे उपयोग कर सकते हैं? जहां तक ​​​​मैं अब वहां एक कंपोज़ फ़ाइल का उपयोग करने का कोई तरीका नहीं है :(

@garcianavalon अच्छी तरह से काम करता है, लेकिन यह केवल run , न कि build । मैक के लिए डॉकर के साथ अभी तक काम नहीं कर रहा है, हालांकि यह स्पष्ट रूप से टूडू सूची में है।

संपादित करें: https://github.com/docker/for-mac/issues/410

हम अपनी विशिष्ट आवश्यकताओं के लिए 2 और समाधान लेकर आए हैं:

1) हमारे वीपीएन के पीछे एनपीएम, पीपीआई, आदि के लिए अपना खुद का पैकेज मिरर सेट करें, इस तरह हमें एसएसएच की आवश्यकता नहीं है।

2) सभी होस्ट मशीन हमारे पास पहले से ही निजी रेपो तक पहुंच है, इसलिए हम स्थानीय रूप से होस्ट मशीन पर निजी पैकेज को क्लोन / डाउनलोड करते हैं, इसे डाउनलोड करने के लिए इसके पैकेज इंस्टॉलेशन को चलाते हैं, फिर -v का उपयोग करके वॉल्यूम को डॉकर में मैप करते हैं, फिर डॉकर का निर्माण करते हैं।

हम वर्तमान में विकल्प 2 का उपयोग कर रहे हैं)।

जहां तक docker run , docker-ssh-agent-forward एक सुरुचिपूर्ण समाधान प्रदान करता है और मैक/लिनक्स के लिए डॉकर में काम करता है।

यह अभी भी एक अच्छा विचार हो सकता है कि होस्ट से known_hosts फ़ाइल को कंटेनर (कम सुरक्षित) में बनाने के बजाय कॉपी करें, यह देखते हुए कि ssh-agent ज्ञात होस्ट को अग्रेषित नहीं करता है।

लेकिन डॉक रन चरण के दौरान निजी निर्भरता को खींचने के साथ मूलभूत समस्या डॉक बिल्ड कैश को दरकिनार कर रही है, जो कि निर्माण समय की अवधि में बहुत महत्वपूर्ण हो सकता है।

इस सीमा को पार करने का एक तरीका यह है कि अपनी बिल्ड निर्भरता घोषणाओं (जैसे package.json ) को md5/date करें, परिणाम को एक छवि पर धकेलें और यदि फ़ाइल नहीं बदली है तो उसी छवि का पुन: उपयोग करें। छवि के नाम में हैश का उपयोग करने से कई राज्यों को कैशिंग करने की अनुमति मिल जाएगी। इसे प्री-इंस्टॉल इमेज डाइजेस्ट के साथ भी जोड़ना होगा।

यह सर्वर बनाने के लिए @aidanhs के समाधान से अधिक मजबूत होना चाहिए, हालांकि मुझे अभी भी इसे बड़े पैमाने पर परीक्षण करना है।

यह सर्वर बनाने के लिए @aidanhs के समाधान से अधिक मजबूत होना चाहिए, हालांकि मुझे अभी भी इसे बड़े पैमाने पर परीक्षण करना है।

मेरे विशिष्ट समाधान ने 1.9.0 के बाद से काम नहीं किया है - यह पता चला है कि 1.8.0 में पेश की गई सुविधा जिस पर मैं भरोसा कर रहा था वह जानबूझकर नहीं थी और इसलिए इसे हटा दिया गया था।

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

अतिरिक्त जानकारी के लिए धन्यवाद @aidanhs!

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

मैंने नोड/एनपीएम के लिए पूरा समाधान लागू किया है और इसे विस्तृत दस्तावेज और उदाहरणों के साथ यहां पाया जा सकता है: https://github.com/iheartradio/docker-node

बेशक, सिद्धांतों को अन्य ढांचे के लिए बढ़ाया जा सकता है।

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

https://github.com/bibendi/dip#dip -ssh

हम 2-चरणीय निर्माण प्रक्रिया के द्वारा इसे हल करते हैं। स्रोत/कुंजी/बिल्ड निर्भरता वाली एक "बिल्ड" छवि बनाई जाती है। एक बार जब यह बन जाता है तो इसे बिल्ड परिणामों को एक टैरफाइल में निकालने के लिए चलाया जाता है जिसे बाद में "तैनाती" छवि में जोड़ा जाता है। बिल्ड छवि को तब हटा दिया जाता है और जो कुछ भी प्रकाशित होता है वह "तैनाती" छवि है। कंटेनर/परत के आकार को कम रखने का इसका अच्छा दुष्प्रभाव है।

@ बाइनरीटेम्पल-बेट365 एक एंड-टू-एंड उदाहरण के लिए https://github.com/iheartradio/docker-node देखें जो वास्तव में ऐसा कर रहा है। मैं दो से अधिक चरणों का उपयोग करता हूं क्योंकि मैं एक एसएसएच सेवा कंटेनर का उपयोग करता हूं, प्री-इंस्टॉल (निजी निर्भरता स्थापित करने से पहले तक आधार छवि), इंस्टॉल (निजी निर्भरताओं की रनटाइम स्थापना के बाद कंटेनर स्थिति) और पोस्ट-इंस्टॉल (कमांड जोड़ता है जो आपके पास था स्थापना के बाद निजी निर्भरता की) गति और चिंता को अलग करने का अनुकूलन करने के लिए।

रॉकर देखें , यह एक साफ समाधान है।

@ सोडकी मैंने आपकी सलाह ली। हां, घुमाव एक साफ और सुविचारित समाधान है। अधिक शर्म की बात है कि डॉकर टीम उस परियोजना को अपने विंग के तहत नहीं लेगी और docker build हटा देगी। शुक्रिया।

अभी भी कोई बेहतर तरीका नहीं है? :(

क्या किसी ने इस नई स्क्वैश चीज़ की कोशिश की है? https://github.com/docker/docker/pull/22641 हम जिस डॉकटर मूल समाधान की तलाश कर रहे हैं वह हो सकता है। अब इसे आजमाने जा रहे हैं और यह देखने के लिए वापस रिपोर्ट करें कि यह कैसा चल रहा है।

2+ वर्षों के बाद यह अभी तक ठीक नहीं हुआ है कृपया डॉकर टीम इसके बारे में कुछ करें

ऐसा लगता है कि 1.13 में नया --squash विकल्प मेरे लिए काम करता है:
http://g.recordit.co/oSuMulfelK.gif

मैं इसे इसके साथ बनाता हूं: docker build -t report-server --squash --build-arg SSH_KEY="$(cat ~/.ssh/github_private_key)" .

तो जब मैं docker history या docker inspect करता हूं, तो कुंजी दिखाई नहीं देती है।

मेरा डॉकरफाइल इस तरह दिखता है:

FROM node:6.9.2-alpine

ARG SSH_KEY

RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* &&\
  mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
  ssh-keyscan github.com > /root/.ssh/known_hosts

RUN echo "$SSH_KEY" > /root/.ssh/id_rsa &&\
  chmod 0600 /root/.ssh/id_rsa

COPY package.json .

RUN npm install
RUN rm -f /root/.ssh/id_rsa

# Bundle app source
COPY . .

EXPOSE 3000

CMD ["npm","start"]

@ kienpham2000 , आपका स्क्रीनशॉट ऐसा लगता है कि इसमें अभी भी कुंजियाँ हैं - क्या आप कृपया docker history के आउटपुट को --no-trunc ध्वज के साथ जाँच सकते हैं और गीलेर पर वापस रिपोर्ट कर सकते हैं या नहीं, निजी कुंजियाँ डॉकटर में प्रदर्शित होती हैं इतिहास?

@ryanschwartz आप सही कह रहे हैं, --no-trunc पूरी लानत दिखाता है, यह उड़ता नहीं है।

@ kienpham2000
1.13 रिलीज में उन्होंने एक और चीज पेश की:

रहस्य बनाएँ
• -बिल्ड-सीक्रेट फ्लैग . का उपयोग करके बिल्ड टाइम सीक्रेट्स को सक्षम बनाता है
• निर्माण के दौरान tmpfs बनाता है, और रहस्यों को उजागर करता है
निर्माण के दौरान उपयोग किए जाने वाले कंटेनर बनाएं।
• https://github.com/docker/docker/pull/28079

शायद यह काम कर सके?

बिल्ड सीक्रेट्स ने इसे 1.13 में नहीं बनाया, लेकिन उम्मीद है कि 1.14 में करेंगे।

15 दिसंबर 2016 को सुबह 9:45 बजे, "एलेक्स" नोटिफिकेशन @github.com ने लिखा:

@ kienpham2000 https://github.com/kienpham2000
1.13 रिलीज में उन्होंने एक और चीज पेश की:

रहस्य बनाएँ
• -बिल्ड-सीक्रेट फ्लैग . का उपयोग करके बिल्ड टाइम सीक्रेट्स को सक्षम बनाता है
• निर्माण के दौरान tmpfs बनाता है, और रहस्यों को उजागर करता है
निर्माण के दौरान उपयोग किए जाने वाले कंटेनर बनाएं।
• #28079 https://github.com/docker/docker/pull/28079

शायद यह काम कर सके?

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

तो एक साल बाद: नहीं, यह एक बुरा विचार है। तुम्हें वह नहीं करना चाहिए। कई अन्य समाधान हैं। उदाहरण के लिए, Github एक्सेस टोकन प्रदान कर सकता है। आप उन्हें कम जोखिम वाले कॉन्फ़िगरेशन फ़ाइलों/पर्यावरण चर में उपयोग कर सकते हैं क्योंकि आप निर्दिष्ट कर सकते हैं कि प्रत्येक टोकन के लिए कौन सी क्रियाओं की अनुमति है।

समाधान एसएसएच अग्रेषण को लागू करना है। जैसे वैग्रांट उदाहरण के लिए करता है।

क्या कोई मुझे समझा सकता है कि इसे लागू करने के लिए इतना जटिल क्यों है?

@omarabid - क्या आप Dockerfile के भीतर उपयोग की जाने वाली निजी कुंजियों को पास करने के लिए पर्यावरण चर का उपयोग करने के अपने मूल प्रस्ताव का उत्तर दे रहे हैं? कोई सवाल ही नहीं है, यह एक खराब सुरक्षा अभ्यास है।

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

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

डेवलपर्स/सीआई सिस्टम के लिए गिट/बिल्ड ऑपरेशंस के दौरान एसएसएच एजेंट का उपयोग करना स्वाभाविक है। यह एक प्लेनटेक्स्ट, पासवर्ड-रहित निजी कुंजी की तुलना में कहीं अधिक सुरक्षित है जिसे विभिन्न प्रणालियों में सामूहिक रूप से निरस्त/प्रतिस्थापित किया जाना चाहिए। साथ ही, SSH एजेंटों के साथ किसी छवि के लिए निजी कुंजी डेटा के प्रतिबद्ध होने की कोई संभावना नहीं है। कम से कम एक पर्यावरण चर/SSH_AUTH_SOCK अवशेष छवि में पीछे रह जाएगा।

मुझे गुप्त कुंजी सामग्री दिखाए बिना या अतिरिक्त तृतीय पक्ष डॉकर टूल का उपयोग किए बिना यह नवीनतम समाधान मिला (उम्मीद है कि निर्मित पीआर के दौरान गुप्त वॉल्ट जल्द ही विलय हो जाएगा)।

मैं होस्ट वर्तमान रेपो में एस 3 से साझा निजी कुंजी डाउनलोड करने के लिए एडब्ल्यूएस क्ली का उपयोग कर रहा हूं। यह कुंजी KMS का उपयोग करके आराम से एन्क्रिप्ट की गई है। एक बार कुंजी डाउनलोड हो जाने के बाद, Dockerfile केवल निर्माण प्रक्रिया के दौरान उस कुंजी को कॉपी करेगा और बाद में उसे हटा देगा, सामग्री docker inspect या docker history --no-trunc

पहले S3 से होस्ट मशीन में github निजी कुंजी डाउनलोड करें:

# build.sh
s3_key="s3://my-company/shared-github-private-key"
aws configure set s3.signature_version s3v4
aws s3 cp $s3_key id_rsa --region us-west-2 && chmod 0600 id_rsa

docker build -t app_name .

डॉकरफाइल इस तरह दिखता है:

FROM node:6.9.2-alpine

ENV id_rsa /root/.ssh/id_rsa
ENV app_dir /usr/src/app

RUN mkdir -p $app_dir
RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* && mkdir -p /root/.ssh && ssh-keyscan github.com > /root/.ssh/known_hosts

WORKDIR $app_dir

COPY package.json .
COPY id_rsa $id_rsa
RUN npm install && npm install -g gulp && rm -rf $id_rsa

COPY . $app_dir
RUN rm -rf $app_dir/id_rsa

CMD ["start"]

ENTRYPOINT ["npm"]

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

• हम aws s3 cli के साथ कुंजी तक पहुंचने के लिए एक पूर्व-हस्ताक्षर URL उत्पन्न करते हैं, और लगभग 5 मिनट तक पहुंच को सीमित करते हैं, हम इस पूर्व-हस्ताक्षर URL को रेपो निर्देशिका में एक फ़ाइल में सहेजते हैं, फिर dockerfile में हम इसे छवि में जोड़ते हैं।
• डॉकरफाइल में हमारे पास एक रन कमांड है जो इन सभी चरणों को करता है: एसएसएच कुंजी प्राप्त करने के लिए प्री-सिंग यूआरएल का उपयोग करें, एनपीएम इंस्टॉल चलाएं, और एसएसएच कुंजी को हटा दें।
  एक सिंगल कमांड में ऐसा करने से ssh key किसी भी लेयर में स्टोर नहीं होगी, लेकिन प्री-साइन URL स्टोर हो जाएगा, और यह कोई समस्या नहीं है क्योंकि URL 5 मिनट के बाद मान्य नहीं होगा।

बिल्ड स्क्रिप्ट इस तरह दिखती है:

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

डॉकरफाइल इस तरह दिखता है:

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no [email protected] || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

@diegocsandrim यह इंगित करने के लिए धन्यवाद, मुझे वास्तव में आपका समाधान पसंद है, यहां हमारे सामान को अपडेट करने जा रहा है। साझा करने के लिए धन्यवाद!

मैं धागे के लिए थोड़ा नया हूं, लेकिन मूल रूप से ऐसा लगता है कि लोग पीकेआई द्वारा बेहतर तरीके से हल की गई समस्या को हल करने की कोशिश कर रहे हैं। जरूरी नहीं कि हर कोई उसी समस्या को बचाने की कोशिश कर रहा हो जहां पीकेआई बेहतर समाधान होगा, लेकिन पर्याप्त संदर्भों से संकेत मिलता है कि यह कुछ ऐसा हो सकता है जिस पर विचार किया जाना चाहिए।

यह कष्टप्रद लगता है, लेकिन मौलिक रूप से संभव है

• एक स्थानीय प्रमाणपत्र प्राधिकरण बनाएँ
• एक प्रमाणपत्र उत्पन्न करने की एक प्रक्रिया है
• प्रमाणपत्र जारी करने की एक प्रक्रिया है
• उक्त प्रमाणपत्र को रद्द करने की एक प्रक्रिया है
• ssh daemons PKI का उपयोग करें

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

https://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

@mehmetcodes : PKI होने से वास्तव में समस्या का समाधान नहीं होता है। पीकेआई-आधारित एसएसएच प्रमाणीकरण काम करने के लिए, आपको अभी भी छवि के लिए निजी कुंजी लोड करने की आवश्यकता होगी।

जब तक आपका स्थानीय प्रमाणपत्र प्राधिकारी बहुत कम समय के लिए प्रमाणपत्र जारी नहीं करता है (उदाहरण के लिए एक घंटे से कम), और आप एक सफल निर्माण के तुरंत बाद प्रमाणपत्र को रद्द नहीं करते हैं, तो यह असुरक्षित है।

यदि आप अल्पकालिक प्रमाणपत्र प्रक्रिया बनाने का प्रबंधन करते हैं, तो यह केवल एक नई SSH कुंजी का उपयोग करने से बहुत अलग नहीं है जिसे आप निर्माण समाप्त होने के तुरंत बाद रद्द कर देते हैं।

ओह, यह उससे भी अधिक कष्टप्रद है, लेकिन मुझे किसी चीज़ पर होना चाहिए या यह जंगली में क्यों मौजूद होगा?

https://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule/
https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/

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

आप http://blog.cloud66.com/using-ssh-private-keys-securely-in-docker-build/ के बारे में क्या सोचते हैं

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

कौन f.. मोबाइल है?

@सफेद रंग

मैकोज़ पर मुझे यह मिल गया है:

bash-3.2$ docker run -t -i -v "$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
docker: Error response from daemon: Mounts denied:
The path /var/folders/yb/880w03m501z89p0bx7nsxt580000gn/T//ssh-DcwJrLqQ0Vu1/agent.10466
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.

/var/ एक उपनाम है, जिसके साथ डॉकर संघर्ष करता प्रतीत होता है। लेकिन अगर मैं $SSH_AUTH_SOCK पथ को /private (यानी हल किए गए उपनाम पथ) के साथ उपसर्ग करता हूं, तो डॉकर फ़ाइल को पढ़ सकता है, लेकिन मुझे मिलता है:

bash-3.2$ docker run -t -i -v "/private$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
Could not open a connection to your authentication agent.

इस बिंदु पर मैं सोच रहा हूँ कि यह कितना बुरा है ...

docker run -v ~/.ssh:/root/.ssh python:3.6 bash

?

docker build  --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa_no_pass)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

और फिर डॉकर फ़ाइल के अंदर:

ARG ssh_prv_key
ARG ssh_pub_key

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

और शामिल करना न भूलें

RUN rm -f /root/.ssh/id_rsa /root/.ssh/id_rsa.pub

अंतिम चरण के रूप में।

यहां पकड़ यह है कि आपकी निजी कुंजी पासवर्ड से सुरक्षित नहीं होनी चाहिए।

पिछली टिप्पणी के साथ समस्या यह है कि चाबियाँ परतों में समाप्त होती हैं ... आरएम पिछली परत से नहीं हटेगी, क्योंकि डॉक फ़ाइल में प्रत्येक पंक्ति एक परत है।

क्या docker secret इस समस्या का समाधान नहीं करता है?
WDYT @thaJeztah

डोकर रहस्य निर्माण के दौरान (अभी तक) उपलब्ध नहीं है, और केवल सेवाओं में उपलब्ध है (इसलिए अभी तक docker run )

मल्टी स्टेज का उपयोग करते समय कुछ ऐसा बनाता है जो हालांकि काम कर सकता है (मेरे फोन पर टाइप करना, तो मुझे कुछ समय पहले बनाया गया एक सार लिंक करने दें); https://gist.github.com/thaJeztah/836c4220ec024cf6dd48ffa850f07770

मैं अब डॉकर के साथ शामिल नहीं हूं, लेकिन, यह कैसे संभव है कि यह मुद्दा इतने लंबे समय तक मौजूद रहे। मैं कॉल करने की कोशिश नहीं कर रहा हूं बल्कि यह समझने की बजाय कि इसे ठीक करने के लिए क्या प्रयास की आवश्यकता है क्योंकि जब मैं इससे निपट रहा था तो यह किसी भी कंपनी के लिए वास्तव में एक आम मुद्दा लगता है जो निजी पैकेज जैसे ruby gems को एक से खींचता है निजी रेपो।

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

लगभग 3 साल हो गए हैं

@yordis docker Builder एक या दो साल के लिए जमी हुई थी। डॉकर टीम ने कहा कि बिल्डर काफी अच्छा है और वे अपने प्रयासों को कहीं और केंद्रित करते हैं। लेकिन यह चला गया और तब से बिल्डर में दो बदलाव हुए। स्क्वैश और मुस्टली स्टेज बिल्ड। तो बिल्डटाइम रहस्य उनके रास्ते में हो सकते हैं।

एसएसएच-एजेंट के रनटाइम अग्रेषण के लिए, मैं https://github.com/uber-common/docker-ssh-agent-forward की अनुशंसा करता हूं

किसी ऐसी चीज़ के लिए इतना कठिन क्यों होना चाहिए जो मुझे लगता है कि इतना बड़ा सौदा नहीं है।

@yordis इस मुद्दे के शीर्ष विवरण को पढ़ना, इसे लागू करना तुच्छ से बहुत दूर है; यह कहते हुए कि, यदि किसी के पास इसके लिए कोई तकनीकी डिजाइन प्रस्ताव है, तो बेझिझक किसी मुद्दे या पीआर को चर्चा के लिए खोल सकते हैं। यह भी ध्यान दें कि _build_ भाग के लिए, एक buildkit प्रोजेक्ट को भविष्य में बिल्डर के लिए एन्हांसमेंट के लिए शुरू किया गया था; https://github.com/moby/buildkit

@thaJeztah काश मेरे पास आवश्यक कौशल होते लेकिन मैं नहीं करता।

@villlem क्या आप डॉकर टीम से कोई रोडमैप जानते हैं?

बिल्डर के लिए साप्ताहिक रिपोर्ट यहां पाई जा सकती है; https://github.com/moby/moby/tree/master/reports/builder बिल्ड टाइम सीक्रेट्स अभी भी नवीनतम रिपोर्ट में सूचीबद्ध है, लेकिन मदद का उपयोग कर सकता है

हम @diegocsandrim के समाधान का उपयोग कर रहे हैं, लेकिन S3 में एक अनएन्क्रिप्टेड SSH कुंजी को छोड़ने से बचने के लिए एक मध्यवर्ती एन्क्रिप्शन चरण के साथ।

इस अतिरिक्त कदम का मतलब है कि कुंजी को डॉकर छवि से पुनर्प्राप्त नहीं किया जा सकता है (इसे डाउनलोड करने के लिए यूआरएल पांच मिनट के बाद समाप्त हो जाता है) और एडब्ल्यूएस से पुनर्प्राप्त नहीं किया जा सकता है (क्योंकि यह केवल डोकर छवि के लिए जाने वाले घूर्णन पासवर्ड से एन्क्रिप्ट किया गया है) .

बिल्ड.श में:

BUCKET_NAME=my_bucket
KEY_FILE=my_unencrypted_key
openssl rand -base64 -out passfile 64
openssl enc -aes-256-cbc -salt -in $KEY_FILE -kfile passfile | aws s3 cp - s3://$BUCKET_NAME/$(hostname).enc_key
aws s3 presign s3://$BUCKET_NAME/$(hostname).enc_key --expires-in 300 > ./pre_sign_url
docker build -t my_service

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

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - | openssl enc -aes-256-cbc -d -kfile passfile > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    mkdir /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts && \
    [commands that require SSH access to Github] && \
    rm ./my_key && \
    rm ./passfile && \
    rm -rf /root/.ssh/

यदि आप docker run का उपयोग कर रहे हैं तो आपको अपने .ssh को --mount type=bind,source="${HOME}/.ssh/",target="/root/.ssh/",readonly साथ माउंट करना चाहिए। रीडोनली जादू है, यह सामान्य अनुमतियों को मास्क करता है और ssh मूल रूप से 0600 अनुमतियों को देखता है जिससे यह खुश है। आप -u root:$(id -u $USER) साथ भी खेल सकते हैं ताकि कंटेनर में रूट उपयोगकर्ता आपके उपयोगकर्ता के समान समूह के साथ बनाई गई किसी भी फाइल को लिख सके, इसलिए उम्मीद है कि आप कम से कम उन्हें पढ़ सकते हैं यदि उन्हें पूरी तरह से chmod/chown के बिना नहीं लिखा है .

आखिरकार।

मेरा मानना ​​है कि इस समस्या को अब केवल docker build का उपयोग करके, मल्टी-स्टेज बिल्ड का उपयोग करके हल किया जा सकता
बस COPY या ADD एसएसएच कुंजी या अन्य रहस्य जहां भी आपको इसकी आवश्यकता हो, और इसे RUN स्टेटमेंट में उपयोग करें, हालांकि आप इसे पसंद करते हैं।

फिर, एक नया फाइल सिस्टम शुरू करने के लिए दूसरे FROM स्टेटमेंट का उपयोग करें, और निर्देशिकाओं के कुछ सबसेट को आयात करने के लिए COPY --from=builder करें जिसमें सीक्रेट शामिल नहीं है ।

(मैंने वास्तव में अभी तक यह कोशिश नहीं की है, लेकिन अगर यह सुविधा वर्णित के अनुसार काम करती है ...)

@ बेंटन मल्टी-स्टेज वर्णित के रूप में काम करता है, हम इसका इस्तेमाल करते हैं। यह इस सहित कई अलग-अलग समस्याओं के लिए अब तक का सबसे अच्छा विकल्प है।

मैंने निम्नलिखित तकनीक का सत्यापन किया है:

1. एक निजी कुंजी के _स्थान को एक बिल्ड तर्क के रूप में पास करें, जैसे कि GITHUB_SSH_KEY , बहु-चरण निर्माण के पहले चरण में
2. प्रमाणीकरण के लिए जहां कहीं भी कुंजी की आवश्यकता हो, वहां कुंजी लिखने के लिए ADD या COPY करें। ध्यान दें कि यदि मुख्य स्थान स्थानीय फाइल सिस्टम पथ है (और यूआरएल नहीं), तो इसे _not_ .dockerignore फ़ाइल में होना चाहिए, या COPY निर्देश काम नहीं करेगा। अंतिम छवि के लिए इसके निहितार्थ हैं, जैसा कि आप चरण 4 में देखेंगे...
3. आवश्यकतानुसार चाबी का प्रयोग करें। नीचे दिए गए उदाहरण में, कुंजी का उपयोग GitHub को प्रमाणित करने के लिए किया जाता है। यह रूबी के bundler और निजी जेम रिपॉजिटरी के लिए भी काम करता है। इस बिंदु पर आपको कितना कोडबेस शामिल करने की आवश्यकता है, इस पर निर्भर करते हुए, आप COPY . या ADD . का उपयोग करने के दुष्प्रभाव के रूप में फिर से कुंजी जोड़ सकते हैं।
4. यदि आवश्यक हो तो कुंजी हटा दें । यदि मुख्य स्थान एक स्थानीय फाइल सिस्टम पथ है (और यूआरएल नहीं), तो यह संभावना है कि इसे कोडबेस के साथ जोड़ा गया था जब आपने ADD . या COPY . यह शायद _सटीक रूप से निर्देशिका_ है अंतिम रनटाइम छवि में कॉपी किया जा रहा है, इसलिए कुंजी का उपयोग करने के बाद आप शायद RUN rm -vf ${GITHUB_SSH_KEY} स्टेटमेंट भी शामिल करना चाहते हैं।
5. एक बार जब आपका ऐप पूरी तरह से इसके WORKDIR , तो दूसरा बिल्ड चरण एक नए FROM स्टेटमेंट के साथ शुरू करें, जो आपकी वांछित रनटाइम छवि को दर्शाता है। किसी भी आवश्यक रनटाइम निर्भरता को स्थापित करें, और फिर पहले चरण से WORKDIR विरुद्ध COPY --from=builder स्थापित करें।

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

########################################################################
# BUILD STAGE 1 - Start with the same image that will be used at runtime
FROM ubuntu:latest as builder

# ssh is used to test GitHub access
RUN apt-get update && apt-get -y install ssh

# The GITHUB_SSH_KEY Build Argument must be a path or URL
# If it's a path, it MUST be in the docker build dir, and NOT in .dockerignore!
ARG GITHUB_SSH_KEY=/path/to/.ssh/key

  # Set up root user SSH access for GitHub
ADD ${GITHUB_SSH_KEY} /root/.ssh/id_rsa

# Add the full application codebase dir, minus the .dockerignore contents...
# WARNING! - if the GITHUB_SSH_KEY is a file and not a URL, it will be added!
COPY . /app
WORKDIR /app

# Build app dependencies that require SSH access here (bundle install, etc.)
# Test SSH access (this returns false even when successful, but prints results)
RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1 | grep -i auth

# Finally, remove the $GITHUB_SSH_KEY if it was a file, so it's not in /app!
# It can also be removed from /root/.ssh/id_rsa, but you're probably not going
# to COPY that directory into the runtime image.
RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id*

########################################################################
# BUILD STAGE 2 - copy the compiled app dir into a fresh runtime image
FROM ubuntu:latest as runtime
COPY --from=builder /app /app

कुंजी डेटा के _स्थान_ के बजाय GITHUB_SSH_KEY बिल्ड तर्क में ही कुंजी डेटा को पास करना _माइट_ सुरक्षित हो सकता है। यदि कुंजी डेटा को स्थानीय फ़ाइल में संग्रहीत किया जाता है और फिर COPY . साथ जोड़ा जाता है, तो यह आकस्मिक समावेशन को रोक देगा। हालाँकि, इसके लिए फ़ाइल सिस्टम में डेटा लिखने के लिए echo और शेल पुनर्निर्देशन का उपयोग करने की आवश्यकता होगी, जो सभी मूल छवियों में काम नहीं कर सकता है। आधार छवियों के अपने सेट के लिए जो भी तकनीक सबसे सुरक्षित और सबसे व्यवहार्य है उसका उपयोग करें।

@jbiel एक और वर्ष, और मुझे जो समाधान मिला वह वॉल्ट जैसी किसी चीज़ का उपयोग करना है।

यहां 2 विधियों के साथ एक लिंक दिया गया है (स्क्वैश और इंटरमीडिएट कंटेनर जिसे पहले @benton द्वारा वर्णित किया गया है)

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

हल करना।
बैश स्क्रिप्ट बनाएं (~/बिन/डॉकर-लिखें या पसंद करें):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

और Dockerfile में socat का उपयोग करते हुए:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

फिर docker-compose build चलाएं

@ बेंटन आप RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id* उपयोग क्यों करते हैं? क्या यह सिर्फ RUN rm -vf /root/.ssh/id* नहीं होना चाहिए? या हो सकता है कि मैंने यहाँ के इरादे को गलत समझा।

@ बेंटन और यह भी करना सुरक्षित नहीं है:

RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1

आपको फिंगरप्रिंट की जांच करनी होगी

मैंने इस समस्या को इस तरह से हल किया

ARGS USERNAME
ARGS PASSWORD
RUN git config --global url."https://${USERNAME}:${PASSWORD}@github.com".insteadOf "ssh://[email protected]"

फिर साथ बनाएँ

docker build --build-arg USERNAME=use --build-arg PASSWORD=pwd. -t service

लेकिन सबसे पहले, आपके निजी गिट सर्वर को username:password क्लोन रेपो का समर्थन करना चाहिए।

@zeayes RUN कमांड कंटेनर इतिहास में संग्रहीत है। तो आपका पासवर्ड दूसरे को दिखाई देता है।

सही; --build-arg / ARG , वे मान बिल्ड इतिहास में दिखाई देंगे। यदि आप मल्टी-स्टेज बिल्ड का उपयोग करते हैं तो इस तकनीक का उपयोग करना _is_ संभव है _और_ उस होस्ट पर भरोसा करें जिस पर छवियां बनाई गई हैं (यानी, किसी भी अविश्वसनीय उपयोगकर्ता की स्थानीय बिल्ड इतिहास तक पहुंच नहीं है), _और_ इंटरमीडिएट बिल्ड-स्टेज को रजिस्ट्री में धकेला नहीं जाता है।

उदाहरण के लिए, निम्नलिखित उदाहरण में, USERNAME और PASSWORD केवल पहले चरण ("बिल्डर") के इतिहास में होंगे, लेकिन अंतिम चरण के इतिहास में नहीं होंगे;

FROM something AS builder
ARG USERNAME
ARG PASSWORD
RUN something that uses $USERNAME and $PASSWORD

FROM something AS finalstage
COPY --from= builder /the/build-artefacts /usr/bin/something

यदि केवल अंतिम छवि ("अंतिम चरण" द्वारा निर्मित) को रजिस्ट्री में धकेला जाता है, तो उस छवि में USERNAME और PASSWORD नहीं होंगे।

_हालाँकि_, स्थानीय बिल्ड कैश इतिहास में, वे चर अभी भी रहेंगे (और सादे पाठ में डिस्क पर संग्रहीत)।

अगली पीढ़ी के निर्माता ( बिल्डकिट का उपयोग

@kinnalru @thaJeztah thx, मैं मल्टी-स्टेज बिल्ड का उपयोग करता हूं, लेकिन पासवर्ड कैश कंटेनर के इतिहास में देखा जा सकता है, thx!

@zeayes ओह! मैं देख रहा हूं कि मैंने कॉपी/पेस्ट त्रुटि की है; अंतिम चरण में FROM builder .. उपयोग नहीं करना चाहिए। यहाँ एक पूर्ण उदाहरण है; https://gist.github.com/thaJeztah/af1c1e3da76d7ad6ce2abab891506e50

@kinnalru की यह टिप्पणी ऐसा करने का सही तरीका है https://github.com/moby/moby/issues/6396#issuecomment -348103398

इस पद्धति के साथ, docker कभी भी आपकी निजी कुंजियों को हैंडल नहीं करता है। और यह आज भी काम करता है, बिना किसी नई सुविधाओं को जोड़े।

मुझे इसे समझने में थोड़ा समय लगा, इसलिए यहां एक और स्पष्ट और बेहतर स्पष्टीकरण दिया गया है। मैंने --network=host और localhost का उपयोग करने के लिए @kinnalru कोड बदल दिया है, इसलिए आपको अपना आईपी पता जानने की आवश्यकता नहीं है। ( यहाँ सार )

यह docker_with_host_ssh.sh , यह डॉकटर को लपेटता है और SSH_AUTH_SOCK को लोकलहोस्ट पर एक पोर्ट पर अग्रेषित करता है:

#!/usr/bin/env bash

# ensure the processes get killed when we're done
trap 'kill $(jobs -p)' EXIT

# create a connection from port 56789 to the unix socket SSH_AUTH_SOCK (which is used by ssh-agent)
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &
# Run docker
# Pass it all the command line args ($@)
# set the network to "host" so docker can talk to localhost
docker $@ --network='host'

Dockerfile में हम लोकलहोस्ट को होस्ट्स ssh-agent से कनेक्ट करते हैं:

FROM python:3-stretch

COPY . /app
WORKDIR /app

RUN mkdir -p /tmp

# install socat and ssh to talk to the host ssh-agent
RUN  apt-get update && apt-get install git socat openssh-client \
  # create variable called SSH_AUTH_SOCK, ssh will use this automatically
  && export SSH_AUTH_SOCK=/tmp/auth.sock \
  # make SSH_AUTH_SOCK useful by connecting it to hosts ssh-agent over localhost:56789
  && /bin/sh -c "socat UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:localhost:56789 &" \
  # stuff I needed my ssh keys for
  && mkdir -p ~/.ssh \
  && ssh-keyscan gitlab.com > ~/.ssh/known_hosts \
  && pip install -r requirements.txt

फिर आप स्क्रिप्ट को लागू करके अपनी छवि बना सकते हैं:

$ docker_with_host_ssh.sh build -f ../docker/Dockerfile .

@cowlicks आपको इस पुल अनुरोध में रुचि हो सकती है, जो निर्माण के दौरान SSH एजेंट को अग्रेषित करने के लिए docker build --ssh लिए समर्थन जोड़ता है; https://github.com/docker/cli/pull/1419। Dockerfile सिंटैक्स अभी भी आधिकारिक विनिर्देशों में नहीं है, लेकिन आप अपने Dockerfile में एक syntax=.. निर्देश का उपयोग कर सकते हैं जो इसका समर्थन करने वाले फ़्रंटएंड का उपयोग करता है (पुल अनुरोध में उदाहरण/निर्देश देखें)।

वह पुल अनुरोध आगामी 18.09 रिलीज का हिस्सा होगा।

ऐसा लगता है कि यह अब 18.09 रिलीज़ में उपलब्ध है। चूंकि यह धागा रिलीज नोट्स और मध्यम पोस्ट से पहले आता है, इसलिए मैं यहां क्रॉस-पोस्ट करूंगा।

रिलीज नोट्स:
https://docs.docker.com/develop/develop-images/build_enhancements/#using -ssh-to-access-private-data-in-builds

मध्यम पद:
https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

बहुत ही रोमांचक।

@kalenp https://github.com/moby/buildkit/issues/760 और https://github.com/moby/buildkit/issues/825 भी

मुझे लगता है कि हम इसे बंद कर सकते हैं क्योंकि हमारे पास अभी docker build --ssh है

संबंधित कंपोज़ इश्यू यहाँ: docker/compose#6865. अगले रिलीज उम्मीदवार, 1.25.0-आरसी3 ( रिलीज ) में उतरने के लिए नोट किए गए कंटेनरों के लिए एसएसएच एजेंट सॉकेट लिखें और उजागर करने के लिए कार्यक्षमता।