Moby: केवल निर्माण समय -v विकल्प

मैं इसी तरह के समाधान की तलाश में हूं।

संकट

हाल ही में जिस उद्यम में मैं काम करता हूं वह एसएसएल निरीक्षण के साथ Zscaler प्रॉक्सी को सक्षम करता है, जिसका अर्थ है कि प्रमाणपत्र स्थापित होना और निर्माण के दौरान कुछ पर्यावरण चर सेट करना।

एक अस्थायी समाधान प्रमाणपत्र और पर्यावरण चर सेट के साथ एक नया डॉकरफाइल बनाना था। लेकिन दीर्घकालिक दृष्टि से यह उचित नहीं लगता।

तो, मेरा पहला विचार HTTP और HTTPS के साथ एक पारदर्शी प्रॉक्सी सेट किया गया था, लेकिन फिर से मुझे निर्माण के दौरान एक प्रमाण पत्र पास करने की आवश्यकता है।

आदर्श परिदृश्य उसी Dockerfile के साथ है, मैं अपने लैपटॉप, घर और उद्यम पर अपनी छवि बनाने में सक्षम होऊंगा।

संभावित समाधान

# Enterprise
$ docker build -v /etc/ssl:/etc/ssl -t myimage .

# Home
$ docker build -t myimage .

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

अर्थात:

docker build -v /home/dokku/cache/dnx/packages:/opt/dnx/packages -t "dokku/aspnettest" .

@yngndrw जो आप प्रस्तावित करते हैं वह मेरे लिए भी ठीक होगा, यानी, हमें निर्माण समय पर अतिरिक्त संसाधनों को माउंट करने की आवश्यकता है जो कि रन टाइम पर आवश्यक नहीं होंगे क्योंकि वे कंटेनर में स्थापित किए गए हैं।

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

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

फिर से धन्यवाद

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

एक अन्य उदाहरण, सैटेलाइट/स्पेसवॉक होगा जो स्कीमा को अक्सर बदलता है और यहां तक ​​कि संस्करण 5.6 (IIRC) पर Oracle से Postgresql में डेटाबेस को भी बदल देता है।

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

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

सेकेंडिंग @yngndrw कैशिंग की ओर इशारा करते हुए: ठीक यही तर्क कई लोकप्रिय परियोजनाओं जैसे कि मावेन, npm, apt, rpm पर लागू होता है - एक साझा कैश की अनुमति देने से बिल्ड में नाटकीय रूप से तेजी आ सकती है, लेकिन इसे अंतिम छवि में नहीं बनाना चाहिए।

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

मुझे docker build द्वारा उपयोग किए जा सकने वाले वॉल्यूम का समर्थन करने के लिए $# docker run docker build का विस्तार करने के लिए लगातार प्रतिरोध से भी काट लिया गया है। मुझे 'होस्ट-इंडिपेंडेंट बिल्ड्स' मंत्र बहुत आश्वस्त करने वाला नहीं मिला है, क्योंकि यह केवल डॉकर छवियों पर विकास और पुनरावृत्ति को और अधिक कठिन और समय लेने वाला लगता है, जब आपको हर बार पुनर्निर्माण के लिए पूरे पैकेज रिपॉजिटरी को फिर से डाउनलोड करने की आवश्यकता होती है। एक छवि।

मेरा प्रारंभिक उपयोग मामला विकास पुनरावृत्ति को तेज करने के लिए ओएस पैकेज रिपॉजिटरी को कैश करने की इच्छा थी। कुछ सफलता के साथ मैं जिस वर्कअराउंड का उपयोग कर रहा हूं, वह @fatherlinux द्वारा सुझाए गए दृष्टिकोण के समान है, जो कि docker build और Dockerfile के साथ कुश्ती को पूरी तरह से छोड़ देना है, और docker run का उपयोग करके खरोंच से शुरू करना है। docker commit ।

एक छोटे से प्रयोग के रूप में, मैंने अपनी तकनीक को docker build के लिए POSIX शेल स्क्रिप्टिंग के एक बिट का उपयोग करके एक पूर्ण प्रतिस्थापन में विस्तारित किया: dockerize ।

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

FROM , RUNDIR , और VOLUME चर स्वचालित रूप से docker run के तर्क के रूप में पारित हो जाएंगे।
TAG , EXPOSE , और WORKDIR चर स्वचालित रूप से docker commit के तर्क के रूप में पारित हो जाएंगे।

अन्य सभी चरों का मूल्यांकन शेल में किया जाएगा और पर्यावरण तर्क के रूप में पारित किया जाएगा docker run , जिससे वे आपकी बिल्ड स्क्रिप्ट के भीतर उपलब्ध हो जाएंगे।

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

#!/usr/bin/env dockerize
FROM=alpine
TAG=${TAG:-wjordan/my-image}
WORKDIR=/var/cache/dockerize
CACHE=/var/cache/docker
EXPOSE=3001
VOLUME="${HOME}/.docker-cache:${CACHE} ${PWD}:${WORKDIR}:ro /tmp"
#!/bin/sh
ln -s ${CACHE}/apk /var/cache/apk
ln -s ${CACHE}/apk /etc/apk/cache
set -e
apk --update add gcc g++ make libc-dev python
[...etc etc build...]

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

मैं बिल्ड-टाइम -v फ्लैग जोड़ने के पक्ष में भी हूं ताकि उनके बीच कैश डायरेक्टरी साझा करके बिल्ड को गति दी जा सके।

@yngndrw मुझे समझ में नहीं आता कि आपने दो संबंधित मुद्दों को क्यों बंद कर दिया। मैंने आपका #59 अंक पढ़ा और मुझे नहीं पता कि यह इससे कैसे संबंधित है। कुछ मामलों में कंटेनर सुपर-ब्लोटेड हो जाते हैं जब रन-टाइम पर इसकी आवश्यकता नहीं होती है। कृपया पहली पोस्ट पढ़ें।
मुझे आशा है कि मैं यहाँ कुछ याद नहीं कर रहा हूँ ... क्योंकि यह एक लंबा दिन रहा है :-o

@zrml इश्यू https://github.com/aspnet/aspnet-docker/issues/59 बिल्ट-इन प्रति-लेयर कैशिंग से संबंधित था जो डॉकर सभी डॉकर फाइलों के निर्माण के दौरान प्रदान करता है, लेकिन यह वर्तमान मुद्दा सूक्ष्म रूप से अलग है हम डॉकफाइल-विशिष्ट कैशिंग प्रदान करने के लिए होस्ट वॉल्यूम का उपयोग करने के बारे में बात कर रहे हैं जो वॉल्यूम के विशेष उपयोग करने वाले डॉकरफाइल पर निर्भर है। मैंने समस्या https://github.com/aspnet/aspnet-docker/issues/59 को बंद कर दिया क्योंकि यह विशेष रूप से aspnet-docker प्रोजेक्ट/रिपॉजिटरी से संबंधित नहीं है।

दूसरा मुद्दा जो मुझे लगता है कि आप उल्लेख कर रहे हैं, वह है https://github.com/progrium/dokku/issues/1231 , जो कि Dokku प्रक्रियाओं के बारे में था जो अंतर्निहित docker लेयर कैशिंग को स्पष्ट रूप से अक्षम कर रहा था। माइकल ने इस व्यवहार को विन्यास योग्य बनाने की अनुमति देने के लिए डोक्कू में बदलाव किया और इसने डोक्कू परियोजना/रिपॉजिटरी के संबंध में इस मुद्दे को हल किया, जिससे कि मुद्दा भी बंद हो गया।

संभवतः अभी भी एक डॉकर-संबंधित समस्या है जो बकाया है (अर्थात डॉकर बिल्ट-इन लेयर कैशिंग को क्यों नहीं संभाल रहा था जैसा कि मुझे https://github.com/aspnet/aspnet-docker/issues/59 जारी करने में उम्मीद थी), लेकिन मुझे यह पता लगाने का मौका नहीं मिला है कि ऐसा क्यों है और पुष्टि करें कि क्या यह अभी भी हो रहा है। यदि यह अभी भी एक मुद्दा है, तो इसके लिए इस परियोजना/भंडार के लिए एक नया मुद्दा उठाया जाना चाहिए क्योंकि यह इस मौजूदा मुद्दे से अलग है।

@yngndrw बिल्कुल, इसलिए हम सहमत हैं कि यह अलग और ज्ञात है @ docker.com इसलिए यदि आपको कोई आपत्ति नहीं है तो मैं इसे फिर से खोल रहा हूं ... ठीक है, मैं नहीं कर सकता। क्या आपको कोई आपत्ति है, कृपया?
मैं इसे बंद करने से कम से कम एसएफ में अपने सहयोगियों से कुछ टिप्पणियां देखना चाहता हूं

BTW मुझे @ cpuguy83 ने लॉग #3156 . से एक यूजर केस खोलने और यह सब समझाने के लिए कहा था

@zrml मुझे यकीन नहीं है कि मैं अनुसरण करता हूं - क्या यह https://github.com/aspnet/aspnet-docker/issues/59 है जिसे आप फिर से खोलना चाहते हैं? यह एक /aspnet/aspnet-docker समस्या नहीं है, इसलिए मुझे नहीं लगता कि उस मुद्दे को फिर से खोलना सही है। यह वास्तव में/डॉकर/डॉकर पर एक नया मुद्दा होना चाहिए, लेकिन इसे सत्यापित करने की आवश्यकता होगी और पहले पुन: उत्पन्न करने योग्य चरणों की आवश्यकता होगी।

नहीं, नहीं.. यह #14080 जिसे आपने कल बंद किया था।

यह मुद्दा अभी भी खुला है?

@yngndrw मेरा मानना ​​​​है कि मैंने लाल "बंद" आइकन को गलत तरीके से पढ़ा है। क्षमा याचना।

दिल से सहमत हैं कि बिल्ड टाइम-वी एक बड़ी मदद होगी।

बिल्ड कैशिंग एक उपयोग का मामला है।

एक अन्य उपयोग का मामला निजी रेपो से निर्माण के लिए निर्माण समय पर ssh कुंजियों का उपयोग कर रहा है, उन्हें परत में संग्रहीत किए बिना, हैक की आवश्यकता को समाप्त करना (हालांकि अच्छी तरह से इंजीनियर) जैसे कि: https://github.com/dockito/vault

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

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

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

@btrepp एक और अच्छे उपयोग के मामले के लिए धन्यवाद।

मैं दूसरी स्थिति के बारे में सोच सकता हूं।

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

मेरे पास एक विचार है जो एक डॉकरफाइल निर्दिष्ट कर रहा है, जो इसके अंदर निर्माण करते समय एकाधिक डॉकर कमांड चलाता है। Psuedo-ish dockerfiles नीचे।

डॉकर फ़ाइल जो दूसरों का निर्माण करती है

FROM dockerbuilder
RUN docker build -t docker/builder myapp/builder/Dockerfile
RUN docker run -v /app:/app builder
RUN docker build -t btrepp/myapplication myapp/Dockerfile

btrep/myapplication dockerfile

FROM debian:jessie+sayrubyruntime
ADD . /app //(this is code thats been build using the builder dockerfile
ENTRYPOINT ["rails s"]

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

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

यह डॉकर छवियों को सुपर लाइट रखेगा।

यहां मुद्दा यह है कि अस्थायी बिल्डर कंटेनर अंत में चला जाएगा, जिसका अर्थ है कि यह कैश को लोड करने की क्षमता के बिना बहुत महंगा होगा, हम डेबियन को हथिया लेंगे: जेसी कई बार ढेर।

मैंने लोगों को इस तरह की कुछ तकनीकों में देखा है, लेकिन बिल्ड फ़ाइलों को जोड़ने के लिए बाहरी http सर्वर का उपयोग कर रहा हूं। मैं इसे सभी डॉकर द्वारा निर्मित रखना पसंद करूंगा। हालांकि इसे ठीक से करने के लिए संभवतः एक डॉकर छवि का उपयोग करने का एक तरीका है। रन का उपयोग करना और इस प्रकार वॉल्यूम माउंट करने में सक्षम होना।

यहाँ एक और उदाहरण है। मान लें कि मैं सिस्टमटैप के लिए एक कंटेनर बनाना चाहता हूं जिसमें कर्नेल के लिए सभी डिबग प्रतीक हैं (जो कि यूयूयूज हैं)। मुझे अंतर्निहित /lib/मॉड्यूल को माउंट करना होगा ताकि yum कमांड को पता चल सके कि कौन से RPM को स्थापित करना है।

इसके अलावा, हो सकता है कि मैं इन्हें 1.5GB छवि (डीबग प्रतीकों से) के अलावा कहीं और लाइव करूं

मैं एक डॉकरफाइल लिखने गया, फिर महसूस किया कि यह असंभव था :-(

docker run --privileged -v /lib/modules:/lib/modules --tty=true --interactive=true rhel7/rhel-tools /bin/bash
yum --enablerepo=rhel-7-server-debug-rpms install kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)
docker ps -a
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                        PORTS               NAMES
52dac30dc495        rhel7/rhel-tools:latest   "/bin/bash"         34 minutes ago      Exited (0) 15 minutes ago                         dreamy_thompson
docker commit dreamy_thompson stap:latest

https://access.redhat.com/solutions/1420883

मैं यहां #3949 से अपने उपयोग के मामले को दोहराना चाहूंगा क्योंकि उस बग को अन्य कारणों से बंद कर दिया गया है।

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

इस आवश्यक फीचर में कोई खबर?
धन्यवाद

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

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

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

@vad

इस सुविधा के लिए +1!

एक अन्य उपयोग का मामला निजी रेपो से निर्माण के लिए निर्माण समय पर ssh कुंजियों का उपयोग कर रहा है, उन्हें परत में संग्रहीत किए बिना, हैक की आवश्यकता को समाप्त करना (हालांकि अच्छी तरह से इंजीनियर) जैसे कि: https://github.com/dockito/vault

यह हमारा यूज़केस भी है (इस मामले में होस्ट पर tmpfs का उपयोग करके प्रदान की गई ssh कुंजियाँ)।

इसके लिए एक अन्य उपयोगकेस बिल्ड-टाइम को कम करने के लिए CI सर्वर पर node_modules निर्देशिका के स्थानीय कैश के लिए है।
npm install बहुत धीमा है और यहां तक ​​कि वर्तमान "सर्वश्रेष्ठ" मामले में भी जहां package.json छवि के लिए ADD एड है, npm install चलाया जाता है और उसके बाद ही package.json में किए गए परिवर्तनों पर जोड़े गए और बनाए गए वास्तविक परियोजना स्रोतों को सभी निर्भरताओं को फिर से डाउनलोड करना होगा।

नोड/एनपीएम पक्ष पर इस बारे में किसी समस्या के लिए npm/npm#8836 देखें।

संबंधित aspnet-docker समस्या धीमी पैकेज बहाली और परत में मौजूदा संकुल को कैशिंग करने के परिणामी छवि आकार के संबंध में है। पैकेज के कैशिंग के लिए माउंटेड वॉल्यूम का उपयोग करना बेहतर होगा।
https://github.com/aspnet/aspnet-docker/issues/123

यह कोई भाषा-विशिष्ट मुद्दा नहीं है, यह कई लोगों को प्रभावित करेगा क्योंकि पैकेज प्रबंधक अब एक स्वीकृत मानक हैं।

ओपी ने इस मुद्दे को सिर पर खींचा है, जिसमें "डॉकर बिल्ड-वी" रनटाइम पर्यावरण से निर्माण प्रक्रिया को कम करने में काफी मदद करेगा।

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

मैं इस बारे में सोच रहा हूं, और दूसरा विकल्प जो मैं सोच सकता हूं वह है परतों को "src" परतों के रूप में चिह्नित करने की क्षमता।

उन परतों की तर्ज पर कुछ केवल एक डॉकटर निर्माण के दौरान पहुँचा जा सकता है, लेकिन परिणामी छवि फ़ाइल में नहीं खींचा जाता है।

इस तरह डॉकर पहले की परतों/छवियों, अस्थायी निर्माण कलाकृतियों को कैश कर सकता है, लेकिन अंतिम छवि का उपयोग करने के लिए इनकी आवश्यकता नहीं होती है।

उदा.

FROM ubuntu
RUN apt-get install gcc
ADDPRIVATE . /tmp/src <--these can be cached by docker locally
RUNPRIVATE make     <-- basically these layers become scoped to the current build process/dockerfile
RUN make install <--result of this layer is required.

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

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

मैं बिल्ड टाइम वॉल्यूम का उपयोग करने के लिए एक नकारात्मक पहलू भी देख सकता हूं, dockerfiles प्रतिलिपि प्रस्तुत करने योग्य नहीं होगा, और इसके लिए docker build -t btrep/myapp के बाहर अतिरिक्त सेटअप की आवश्यकता होगी। यह dockerhub पर स्वचालित बिल्ड को भी मुश्किल बनाने वाला है।

@btrep : मुझे आपका सुझाव पसंद है। मैं हार्डकोड के साथ अपने उपयोग के मामलों के लिए भी जी सकता हूं (मुझे पता है कि यह आम तौर पर एक बुरी चीज है) टीएमपी डीआईआर जो डॉकर हमें बताता है ताकि वे जान सकें कि जब वे सभी परतों से अंतिम आर्टिफैक्ट बनाते हैं तो वे भूल सकते हैं/छोड़ सकते हैं /this_is_the_tmp_explosion_folder_that_will_be_removed_from_your_final_container_image पर आरोहित
काफी आसान....

@btrep मुझे आपका सोर्स लेयर आइडिया काफी पसंद है।

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

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

एक उपकरण व्याकरण/घुमावदार है जिसका उपयोग किया जा सकता है जबकि यह समस्या अभी तक ठीक नहीं हुई है।

@yngndrw

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

http(s) के माध्यम से नीचे खींचे जाने पर शून्य कारण "super_awesome_ruby_lib" को निजी होने की आवश्यकता है। रूबी रत्नों के लिए कीरिंग रखने का बेहतर तरीका होगा। या यहां तक ​​कि एक ज्ञात सार्वजनिक कुंजी, और इसके लिए संकुल पर हस्ताक्षर करने के लिए। यह कमोबेश apt-get कैसे काम करता है, और चीजों को कैश करने के लिए मानक http प्रॉक्सी की अनुमति देता है।

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

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

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

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

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

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

मेरे लिए मुझे भी चाहिए docker build -v ।

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

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

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

@thaJeztah ऐसा होने का कोई मौका?

Fwiw यही एकमात्र कारण है कि मैं docker . का उपयोग नहीं करता (या वास्तव में, नहीं कर सकता)

हम docker के Red Hat संस्करण में एक पैच रखते हैं जिसमें -v विकल्प शामिल है। लेकिन इसका सही समाधान ओसीआई कंटेनर इमेज बनाने के लिए नए और अलग-अलग तरीकों का निर्माण करना होगा, फिर डॉकर बिल्ड।

@rhatdan आरएचईएल या फेडोरा?

हमने docker के अपने आंतरिक संस्करण में रेजिन.io पर docker बिल्ड के -v विकल्प को भी लागू किया है। आप यहाँ अंतर पा सकते हैं https://github.com/resin-io/docker/commit/9d155107b06c7f96a8951cbbc18287eeab8f60cc

@rhatdan @petrosagg क्या आप इसके लिए पीआर बना सकते हैं?

@jeremyherbert पैच डॉकर डेमॉन में है जो आरएचईएल, सेंटोस और फेडोरा के सभी हाल के संस्करणों में आता है ...

@grangert हमने इसे अतीत में जमा किया है और इसे अस्वीकार कर दिया गया है।

@rhatdan क्या आपके पास इसका लिंक है?

@runcom क्या आपके पास लिंक है?

@thaJeztah क्या यह कुछ ऐसा है जिसे आप लोगों ने अस्वीकार कर दिया होगा?

यहां उन मौजूदा मुद्दों की सूची दी गई है जिन्हें बंद कर दिया गया है या जिनका जवाब नहीं दिया गया है:
https://github.com/docker/docker/issues/3949
https://github.com/docker/docker/issues/3156
https://github.com/docker/docker/issues/14251
https://github.com/docker/docker/issues/18603

आरएचईएल/सेंटोस/फेडोरा में प्रयुक्त प्रोजेक्ट परमाणु पैच के बारे में जानकारी यहां पाई जा सकती है:
http://www.projectatomic.io/blog/2016/08/docker-patches/

@daveisfera ऐसा लगता है कि वे केवल R वॉल्यूम जोड़ते हैं RW वॉल्यूम नहीं, इसलिए यह @yngndrw और मेरे उपयोग के मामले के लिए काम नहीं करेगा।

@grangert आपको RW वॉल्यूम की आवश्यकता क्यों है? मैं कुछ मामलों के लिए केवल-पढ़ने के लिए वर्कअराउंड के रूप में समझता हूं।

स्कीमा माइग्रेशन का परीक्षण एक अच्छा कारण होगा ...

11/01/2016 10:36 पूर्वाह्न को, ब्रायन गोफ ने लिखा:

@grangert https://github.com/grangert आपको RW वॉल्यूम की आवश्यकता क्यों है?
मैं कुछ मामलों के लिए केवल-पढ़ने के लिए वर्कअराउंड के रूप में समझता हूं।

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

स्कॉट मैककार्टी

स्कॉट [email protected]

http://crunchtools.com

@फादरलिनक्स

@ cpuguy83 RW के लिए एक और उपयोग-मामला ccache होगा

@ फादरलिनक्स मुझे यकीन नहीं है कि मैं अनुसरण करता हूं। इसके लिए आपको वॉल्यूम की आवश्यकता क्यों होगी? इसके अलावा निर्माण चरण के दौरान क्यों किया जाना चाहिए?

मेरे पास इस सुविधा के लिए थोड़ा अलग उपयोग का मामला है - कैशिंग पैकेज जो ASP.Net 5 पैकेज मैनेजर द्वारा डाउनलोड / अपडेट किए जाते हैं। पैकेज प्रबंधक अपने स्वयं के कैश फ़ोल्डर का प्रबंधन करता है, इसलिए अंततः मुझे केवल एक फ़ोल्डर की आवश्यकता होती है जिसे मैं बिल्ड के बीच पुन: उपयोग कर सकता हूं।

उदाहरण के लिए मैं माउंट बांधूंगा:

docker build -v /home/jenkins/pythonapp/cache/pip:/root/.cache/pip  -t pythonapp .
docker build -v /home/jenkins/scalaapp/cache/ivy2:/root/.ivy2  -t scalaapp .

क्योंकि कई बार ऐसा होता है कि स्कीमा माइग्रेशन तब करना पड़ता है जब
सॉफ्टवेयर स्थापित है। यदि आप केवल-पढ़ने के लिए कंटेनर चलाते हैं, तो आपको चाहिए
जब आप इसमें हों, तब के अलावा किसी भी समय सॉफ़्टवेयर इंस्टॉल न करें
निर्माण चरण .....

11/01/2016 10:42 AM पर, ब्रायन गोफ ने लिखा:

@ फादरलिनक्स https://github.com/fatherlinux मुझे यकीन नहीं है कि मैं अनुसरण करता हूं।
इसके लिए आपको वॉल्यूम की आवश्यकता क्यों होगी? साथ ही ऐसा क्यों करना चाहिए
निर्माण चरण?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/14080#issuecomment -257583693,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAHLZfhBG8RUWtqPD-6RaLC7uoCNc-3nks5q50_TgaJpZM4FIdOc।

स्कॉट मैककार्टी

स्कॉट [email protected]

http://crunchtools.com

@फादरलिनक्स

मुझे पता है कि इस निर्देशिका की सामग्री बिल्ड को होस्ट पर निर्भर नहीं करेगी (इन माउंट्स के गायब होने से बिल्ड वैसे भी काम करेगा, बस धीमा)

NFS ने इसे 30 साल पहले की तरह हल किया...

11/01/2016 को 10:45 पूर्वाह्न को, थॉमस ग्रिंगर ने लिखा:

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

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

स्कॉट मैककार्टी

स्कॉट [email protected]

http://crunchtools.com

@फादरलिनक्स

NFS ने इसे 30 साल पहले की तरह हल किया...

उपयोगी टिप्पणी नहीं

@grangert क्षमा करें, वह गंभीरता से गलत हो गया। मैं बहुत जल्दी प्रतिक्रिया देने की कोशिश कर रहा था और पर्याप्त संदर्भ नहीं दे रहा था। गंभीरता से, हम इस प्रकार की कुछ समस्याओं को हल करने के लिए एनएफएस को सीआरआईओ के संयोजन में देख रहे हैं।

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

इसलिए, यहां तक ​​​​कि -v बिल्ड टाइम विकल्प के साथ, एक बिल्ड को केवल एक होस्ट पर लॉक करने की आवश्यकता नहीं है। यह इंटरनेट पैमाने पर स्वतंत्र नहीं हो सकता है, लेकिन यह बहुत से लोगों के लिए पर्याप्त है जो एक ही साइट या स्थान पर अपने निर्माण वातावरण को नियंत्रित करते हैं।

@ फादरलिनक्स मैं कैश निर्देशिका लेने और एस 3 में अपलोड/डाउनलोड करने के लिए गिटलैब या ट्रैविस कैशिंग का उपयोग करता हूं

@grangert हाँ, लेकिन यह केवल कुछ प्रकार के डेटा/ऐप्स पर काम करता है, वह भी केवल बाल्टी स्तर पर, पॉज़िक्स मेटा डेटा और ब्लॉक स्तर पर नहीं। प्रमाणित प्रकार के फ्रंट एंड और मिडलवेयर ऐप्स के लिए, कोई समस्या नहीं है। डेटाबेस स्कीमा माइग्रेशन के लिए, आपको समय से पहले परीक्षण करने की आवश्यकता है और कैश को गति के लिए स्थानीय होना चाहिए और इसे आमतौर पर पॉज़िक्स होना चाहिए।

कल्पना कीजिए कि मेरे पास 1TB डेटा के साथ एक MySQL गैलेरा क्लस्टर था और मैं एक अपग्रेड करना चाहता हूं और वे सभी कंटेनरों में हैं। कंटेनरीकृत/ऑर्केस्ट्रेटेड मल्टी-नोड, शार्ड गैलेरा वास्तव में सुविधाजनक है। मैं प्रत्येक अपग्रेड के दौरान मैन्युअल रूप से स्कीमा माइग्रेशन का परीक्षण नहीं करना चाहता हूं।

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

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

@ फादरलिनक्स मुझे लगता है कि यह एक ऑर्थोगोनल उपयोग का मामला है ...

@grangert उपयोगी टिप्पणी नहीं है। क्या करने के लिए ओर्थोगोनल? निर्माण के दौरान -v के अनुरोध के लिए ऑर्थोगोनल, जिसे मैंने इस बातचीत के बारे में समझा है?

इस ध्वज के लिए मुझे कुछ भिन्न उपयोग दिखाई दे रहे हैं।

• एक कैश, डॉकटर बिल्ड सर्वर के बीच साझा करें
• एक ADD जैसा कीवर्ड जो केवल एक Dockerfile के 'निर्माण के दौरान' लागू होता है। उदाहरण के लिए एक बड़ी फ़ाइल जोड़ें, फिर इसे छवियों से बाहर कर दें।
• एक ADD+RUN जैसे कीवर्ड जो सभी आउटपुट को अनदेखा करता है। उदाहरण के लिए एक बड़ी फ़ाइल जोड़ें, फिर एक चरण चलाएं और छवि में किसी भी बदलाव को अनदेखा करें - एक चरण में ADD+RUN फिर एक परत छोड़ें।

बाद के दो उपयोग मामलों को दो नए खोजशब्दों के साथ अधिक सफाई से हल किया जा सकता है।

BUILDCONSTFILE <path>

प्रत्येक रन से पहले COPY <path> चलाएगा, और बाद में छवि से <path> हटा देगा।

TEST <cmd> WITH <paths>

जो पथों को कॉपी करेगा, कमांड चलाएगा, फिर 0 निकास स्थिति के साथ मूल छवि से निर्माण जारी रखेगा, अन्यथा निर्माण को रोक देगा

व्यक्तिगत रूप से मुझे लगता है कि परीक्षण ... के साथ एक और सीआई चरण में बेहतर तरीके से संभाला जाता है जो आपके कंटेनर का समग्र रूप से परीक्षण करता है

मुझे इसके साथ प्रस्तावना दें: मैं _थिंक_ मैं निर्माण के लिए --mount जोड़ने के साथ ठीक हूं ("-v" शायद इतना अधिक नहीं)। कार्यान्वयन पर 100% निश्चित नहीं है, कैशिंग को कैसे संभाला जाता है (या संभाला नहीं जाता है), आदि।

डॉकर प्रोजेक्ट के लिए हम जो करते हैं वह एक बिल्डर इमेज बनाता है।
इसमें मूल रूप से वह सब कुछ है जो हमें चाहिए, कोड को कॉपी करता है, लेकिन वास्तव में डॉकर का निर्माण नहीं करता है।
हमारे पास एक Makefile है जो इसे व्यवस्थित करता है। तो make build छवि बनाता है, make binary निर्भरता के रूप में build के साथ बाइनरी बनाता है, आदि।

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

@ cpuguy83 मुझे लगता है कि यह मेरे अधिकांश उपयोग के मामलों को खत्म कर देगा। बस इतना मैं समझता हूँ, क्या आपका मतलब --mount का मतलब केवल पढ़ने के लिए है? और -v पढ़ने/लिखने के लिए?

@ cpuguy83 हम ज्यादातर "बिल्डर" चित्र भी बना रहे हैं जो IMHO एक अधिक से अधिक सामान्य पैटर्न बन रहा है ...

@ फादरलिनक्स झुंड सेवाएं और अब (1.13 के लिए) docker run --mount $ का समर्थन करता है जो बहुत अधिक सटीक और लचीला है: https://docs.docker.com/engine/reference/commandline/service_create/# /जोड़ें -बाइंड-माउंट-या-वॉल्यूम

ऐसा लगता है कि डॉक्स में तीसरे प्रकार का माउंट गायब है, tmpfs ।

आह, बहुत बढ़िया, धन्यवाद ...

11/01/2016 02:20 अपराह्न को, ब्रायन गोफ ने लिखा:

@फादरलिनक्स https://github.com/fatherlinux झुंड सेवाएं और अब
(1.13 के लिए) |डॉकर रन| समर्थन करता है |--माउंट| जो बहुत अधिक सटीक है
और लचीला:
https://docs.docker.com/engine/reference/commandline/service_create/#/add -bind-mounts-or-volumes

ऐसा लगता है कि डॉक्स में तीसरे प्रकार का माउंट नहीं है, |tmpfs|।

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

स्कॉट मैककार्टी

स्कॉट [email protected]

http://crunchtools.com

@फादरलिनक्स

@ cpuguy83 हम बिल्डर पैटर्न का भी बहुत उपयोग कर रहे हैं और हमें कैशिंग की आवश्यकता है जो छवि में कायम नहीं है और परत के अमान्य होने से भी बचता है।

हम Yocto इमेज बनाते हैं और हमारे पास NFS स्टोरेज पर एक साझा स्टेट कैश है। एक अन्य उपयोगकेस एनपीएम कैश है ताकि आप पूरी RUN npm install परत को अमान्य कर सकें लेकिन कैश्ड पैकेज के कारण इसे तेजी से फिर से गणना करें।

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

मुझे यह भी लगता है कि कोई भी विचार जिसके लिए विशाल फ़ाइल की _copying_ की आवश्यकता होती है, वह आदर्श से कम है। जिन फ़ाइल आकारों का उपयोग करने में मेरी रुचि है, वे 10-40GB के क्रम में हैं, और यहां तक ​​कि एक अच्छे ssd के साथ जो कम से कम एक या दो मिनट की नकल के लायक है। यह पहले से ही डोकर में जोड़ें निर्देश के साथ मेरी समस्या है; मैं हर बार अपनी छवि बनाने के लिए 30GB नहीं जोड़ना चाहता और उस अतिरिक्त खाली स्थान के साथ-साथ छवियों को स्क्वैश करने की आवश्यकता से निपटना पड़ता है।

हम इसके लिए जो उपयोग कर रहे हैं उसके लिए यह काम नहीं करेगा। हमारे पास एक वॉल्यूम है जिसमें yocto बिल्ड सिस्टम से sstate caches शामिल हैं जो कि बिल्ड में RW बाइंड-माउंटेड है क्योंकि किसी भी कैश मिस की गणना बिल्ड के दौरान की जाएगी और भविष्य के लिए sstate में सेव की जाएगी। हमारी निर्देशिकाएं भी ~ 30GB पर हैं इसलिए हैश की गणना करने में भी कुछ समय लगेगा।

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

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

@petrosagg @zrml @thaJeztah हम जो जानते हैं वह है:

• यदि हम #7115 #3156 के माध्यम से परिमार्जन करते हैं तो हम उन मुद्दों की एक लंबी सूची पा सकते हैं जो इसी समस्या पर चर्चा करते हुए कई वर्ष पुराने हैं।
• अधिकांश या तो पुनरुत्पादन कारण (या पुरानी Dockerfile syntax is frozen टिप्पणी के साथ बंद कर दिए गए थे, और फिर HEALTHCHECK निर्देश जोड़े जाने के बाद, फ्रीज हटा दिया गया था लेकिन मुद्दे बंद रहे)
• इस मुद्दे ने कई टीमों को कई वर्षों से दैनिक विकास में अच्छी कंटेनर उपयोगिता/उत्पादकता रखने से रोक दिया है। जैसा कि @btrep ने कहा कि यह नरक है
• डॉकर लोग इस मुद्दे से अवगत हैं, लेकिन इससे ओह माय डॉकर बिल्ड टूट जाएगा! साझा कैश के कारण समस्याएं जो अच्छी नहीं हैं
• लेकिन डिस्क कैश से नेटवर्क कैश में जाने से किसी भी तरह से बिल्ड विश्वसनीयता में सुधार नहीं होता है, यह एक महिमामंडित कैश-ओवर-http के रूप में कार्य करता है, और यह चीजों को बदतर बनाने के लिए पाया गया है (हर बिल्ड के लिए इंटरनेट डाउनलोड करना, HTTPS, फ़ाइलों का आकार, कंटेनर बनाते समय डिस्क थ्रैशिंग, लेयर कैशिंग, जटिल बिल्ड ऑर्केस्ट्रेशन, आदि)

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

हमारी कंपनी एक अज्ञेय कंटेनर रनटाइम में चली गई है, और जल्द ही एक अज्ञेय छवि निर्माण अनुभव में भी जाना होगा। लेकिन इस पर चर्चा करने के लिए यह सही जगह नहीं होगी क्योंकि नकारात्मकता मदद नहीं करती है। यह एक अलग पद होना चाहिए।

@rdsubhas काम पूरा होने पर लिंक साझा करना चाहते हैं?

@rdsubhas यह एक अच्छा सारांश है। ऐसा नहीं लगता कि यह धागा डुप्ली/वोंटफिक्स के रूप में बंद हो जाएगा क्योंकि @ cpuguy83 सोचता है कि वह निर्माण के दौरान --mount जोड़ने के साथ ठीक है जिसमें अधिकांश उपयोगकेस शामिल हैं।

मैं जो जानना चाहता हूं वह यह है कि वर्तमान प्रस्ताव दिया गया है:

1. डॉकरफाइल सिंटैक्स को नहीं बदलता है
2. बिल्ड को अधिक होस्ट पर निर्भर नहीं बनाता है कि वे वर्तमान में हैं

विचार के संबंध में कौन से प्रतिवाद शेष हैं? यदि कोई नहीं है तो हमें --mount तंत्र के कार्यान्वयन विवरण पर चर्चा शुरू करनी चाहिए।

उस तर्क को फिर से लागू करने के लिए जो बनाता है पहले से ही निर्भर और गैर-प्रतिलिपि प्रस्तुत करने योग्य है, मैं इस संपत्ति के साथ डॉकरफाइल टुकड़ों की एक सूची प्रदान करता हूं:

# Install different software depending on the kernel version of the host
RUN wget http://example.com/$(uname -r)/some_resource

# example.intranet is only accessible from specific hosts
RUN wget http://example.intranet/some_resource

# get something from localhost
RUN wget http://localhost/some_resource

# gcc will enable optimizations supported by the host's CPU
RUN gcc -march=native .....

# node:latest changes as time goes by
FROM node

# ubuntu package lists change as time goes by
RUN apt-get update

# install different software depending on the docker storage driver
RUN if [ $(mount | head -n 1 | awk '{print $5}') == "zfs" ]; then .....; fi

ईमानदारी से, अगर हम सिर्फ --mount जोड़ते हैं और उपयोगकर्ता को कैश अमान्यता ( --no-cache ) को संभालने देते हैं, तो मुझे लगता है कि हम ठीक हो जाएंगे। हम सीएलआई से सभी या कुछ भी नहीं से बेहतर कैश नियंत्रण देखना चाहते हैं, लेकिन यह एक अलग विषय है।

मेरा उपयोग मामला

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

शर्तेँ

1. सर्किलसीआई में निर्माण के दौरान सभी आंतरिक निर्भरताओं को डाउनलोड करने के लिए एसएसएच कुंजी है
2. GitHub आंतरिक निर्भरता को होस्ट करता है और अन्य निर्माण के दौरान छवि के भीतर से डाउनलोड करने योग्य होते हैं

विकल्प

1. निर्माण के दौरान टोकन पास करने के लिए --build-arg का उपयोग करें (दृढ़ता से निराश)। यह एक बहुत ही आकर्षक और आसान विकल्प है क्योंकि "यह सिर्फ काम करता है" बिना किसी अतिरिक्त कदम के।
2. सभी निर्भरताओं को डाउनलोड करें और उन्हें बिल्ड संदर्भ में जोड़ें। दुर्भाग्य से, ADD और COPY को अलग-अलग परतों में निष्पादित किया जाता है, इसलिए मैं पिछली परतों के डेटा के साथ फंस गया हूं।

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

@misakwa हम 1.14 में निर्माण पर रहस्यों का समर्थन करेंगे।

@cpuguy83 को सुनकर बहुत अच्छा लगा। मैं इस पर नजर रखूंगा कि यह कब रिलीज होगी। यह निश्चित रूप से मेरे कुछ कार्यप्रवाहों को सरल बना देगा।

हम संभावित रूप से 1.14 में बिल्ड पर रहस्यों का समर्थन करेंगे।

क्या यह अन्य प्रकार के संस्करणों के बिल्ड-टाइम मैपिंग के मानचित्रण के लिए भी काम करेगा जैसे उदाहरण के लिए yarn-cache ?

BTW docker-compose का उपयोग करके प्रोडक्शन इमेज बनाने का एक इंटरस्टिंग तरीका है, मैंने इसे काम किया और काफी प्रभावी पाया:

तो आपने फ़ाइल docker-compose.build.yml कुछ इस तरह से लिखी है:

services: 
  my-app:
    image: mhart/alpine-node:7.1.0
    container_name: my-app-build-container # to have fixed name
    volumes:
    - ${YARN_CACHE}:/root/.cache/yarn # attach yarn cache from host
    - ${HOME}/.ssh:/.ssh:ro    # attach secrets
    - ./:/source
    environment: # set any vars you need
     TEST_VAR: "some value"    
    ports:
    - "3000"
    working_dir: /app/my-app # set needed correct working dir even if if doesn't exist in container while build type
    command: sh /source/my-app.docker.build.sh # build script

1) आप डॉकटर कंपोज़ का उपयोग करके कंटेनर बनाते हैं:

$ docker-compose -f docker-compose.build.yml up --force-recreate my-app

यह कंटेनर बनाता है और शेल बिल्ड स्क्रिप्ट चलाता है my-app.docker.build.sh , मैं Dockerfile का उपयोग नहीं करता और बिल्ड स्क्रिप्ट में सब कुछ करता हूं:

• आवश्यक ओएस पैकेज स्थापित करें
• आवश्यक स्रोत कोड की प्रतिलिपि बनाएँ (मैप किए गए /source फ़ोल्डर से)
• निर्भरता स्थापित करें
• यदि आवश्यक हो तो निर्माण/संकलन/परीक्षण करें
• लक्ष्य env के काम करने के लिए आवश्यक पैकेज और सामान को हटा दें (अंतिम छवि आकार को कम करने के लिए)

फिर आप कंटेनर से छवि बनाते हैं, इसके लिए सीएमडी की जगह लक्ष्य एनवी में चलाने की जरूरत है:

docker commit -c "CMD npm run serve" my-app-build-container my-app-build-image:tag

तो आपकी छवि तैयार है, बाहरी यार्न कैश और बाहरी गुप्त कुंजियों का उपयोग किया जाता है, जहां केवल निर्माण समय के दौरान उपलब्ध होता है।

@whitecolor हाँ जो काम करता है :) एक चीज़ को छोड़कर: docker build बिल्ड संदर्भ अपलोड करने में वास्तव में प्रभावी है। माउंटेड सोर्स वॉल्यूम दुर्भाग्य से रिमोट डॉकर डेमॉन के साथ काम नहीं करते हैं (उदाहरण के लिए लो-पावर/बैंडविड्थ लैपटॉप के लिए क्लाउड पर डॉकर-मशीन)। उसके लिए हमें बोझिल docker run , docker cp , docker run , आदि docker कमांड की श्रृंखला करनी होगी और फिर अंतिम छवि को स्नैपशॉट करना होगा, लेकिन यह वास्तव में हैकी है।

यह वास्तव में आधिकारिक तौर पर डॉकटर बिल्ड का हिस्सा होने में मदद करता है, और लेयरिंग का उपयोग करता है और संदर्भ का निर्माण करता है

@rdsubhas हाँ आप सही कह रहे हैं

@whitecolor यह वास्तव में सरल और प्रभावी उपाय है। मैंने सिर्फ एक परियोजना पर 30-40 मिनट के निर्माण को लगभग 5 मिनट तक काट दिया। मैं निर्माण सुविधा पर --mount होने की संभावना के लिए तत्पर हूं लेकिन अभी के लिए यह समाधान वास्तव में मेरी पाइपलाइन को अनब्लॉक करता है।

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

मेरे मामले में, जहां यह उपयोगी होगा, वह डेबियन सिस्टम पर होगा: /var/cache/apt को वॉल्यूम के रूप में बढ़ाना, इसलिए आप एक ही .deb फ़ाइलों को बार-बार डाउनलोड नहीं कर रहे हैं। (वास्तव में "असीमित" इंटरनेट कोटा मौजूद नहीं है, विशेष रूप से यहां ऑस्ट्रेलिया में, और यहां तक ​​​​कि अगर वहां था, तो डाउनलोड के इंतजार में समय बर्बाद हो गया।)

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

या आज रात, मैं अपने लिए कुछ Gentoo-आधारित चित्र बना रहा हूं, मैं होस्ट से /usr/portage माउंट करना चाहता हूं। Dockerfile के लिए यह महसूस करना कठिन नहीं है, "अरे, /usr/portage (कंटेनर में) खाली है, कोई समस्या नहीं है कि मैं इसे पकड़ लूंगा" जब वॉल्यूम माउंट किए बिना चल रहा हो, या, यह सिर्फ वॉल्यूम का उपयोग करता है, एक नई प्रति लाने में समय की बचत करता है।

बॉर्न शेल स्क्रिप्ट में उन स्मार्ट को जोड़ना एक मामूली if स्टेटमेंट है ... यदि वॉल्यूम माउंट करने के लिए अंतर्निहित तर्क पहले स्थान पर मौजूद है। अभी मेरी जेनेटू छवियों के लिए, मुझे हर बार निर्माण करने के लिए /usr/portage खींचना पड़ रहा है (सौभाग्य से दर्पण मेरे लैन पर है) जिसका अर्थ है कि उस एक कदम को पूरा करने के लिए कुछ मिनट इंतजार करना अच्छा है।

इतने सारे कारण हैं कि यह एक सार्थक प्रस्ताव क्यों है, और मुझे संदेह है कि # 7115 में प्रस्तावित नेस्टेड बिल्ड उपरोक्त उदाहरणों में मदद करने जा रहे हैं।

@whitecolor का एक दिलचस्प दृष्टिकोण है, लेकिन अगर ऐसा कर रहा है, तो मैं बिल्ड को प्राप्त करने के लिए डॉकर सिस्टम के लिए पूरी तरह से बाहरी Makefile का उपयोग कर सकता हूं।

@sjlongland मैं आप पर चिल्ला नहीं रहा था, मैं एक बड़ा "रिज़ॉल्व्ड डुप्लीकेट" नोटिस पॉली-फिलिंग कर रहा था

मैं अपने बुनियादी ढांचे के लिए कई कंटेनर बनाने के लिए docker और docker-compose का उपयोग कर रहा हूं। कंटेनर माइक्रोसर्विसेज हैं, जो ज्यादातर नोडजेएस में लिखे गए हैं, लेकिन जावा में मावेन फ्रेमवर्क का उपयोग करते हुए एक माइक्रोसर्विस है।
हर बार जब हम जावा कंटेनर का पुनर्निर्माण करते हैं, तो मावेन से दसियों निर्भरताएँ डाउनलोड की जाती हैं; इसमें कई मिनट लगते हैं। फिर कोड लगभग 15 सेकंड में बन जाता है।

यह बहुत बदसूरत है और यह हमारी सीआई रणनीति को काफी प्रभावित करता है।

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

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

@stepps docker -compose के बजाय https://pypi.python.org/pypi/shipwright देखें

मैं थोड़ी देर के लिए इस धागे का पालन कर रहा हूं, अपने लिए एक अच्छा समाधान ढूंढ रहा हूं। न्यूनतम प्रयास के साथ लचीले तरीके से न्यूनतम कंटेनर बनाने के लिए मुझे @edannenberg द्वारा https://github.com/edannenberg/gentoo-bb वास्तव में पसंद है।

• यह बिल्ड-टाइम निर्भरता को रन-टाइम निर्भरता से अलग करता है
• निर्माण कंटेनरों में किया जाता है और अलग, साफ और दोहराने योग्य होता है
• छवियों के बीच निर्भरता को संभालता है और ऑर्डरिंग बनाता है

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

figlet के लिए एक सरल उदाहरण है: -

बिल्ड.कॉन्फ़:

IMAGE_PARENT="gentoobb/glibc"

डॉकरफाइल.टेम्पलेट:

FROM ${IMAGE_PARENT}
ADD rootfs.tar /
USER figlet
CMD ["gentoo-bb"]
ENTRYPOINT ["figlet"]

Build.sh

PACKAGES="app-misc/figlet"

configure_rootfs_build() {
        useradd figlet
}

मुझे @whitecolor का समाधान पसंद है, यह केवल डॉकर तकनीक का उपयोग करना आसान है और फिर सरल शैल स्क्रिप्ट या कुछ और जिसे आप उपयोग करना चाहते हैं। मैं gentoo-bb का उपयोग कर रहा हूं क्योंकि यह अधिक पूर्ण है। अधिक डेवलपर केंद्रित सुविधाओं जैसे शाखाओं से निपटने के साथ शिपराइट अच्छा दिखता है। https://github.com/grammarly/rocker भी दिलचस्प लगता है। सभी को साझा करने के लिए धन्यवाद।

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

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

एक और उपयोग का मामला .. मैं एक मालिकाना ओएस बनाने के लिए डॉकर छवियों का निर्माण करना चाहता हूं जो विभिन्न संस्करणों के 10s के रूप में हैं। इंस्टॉल मीडिया> 80GB है, इसलिए मैं इसे केवल docker बिल्ड वातावरण में कॉपी नहीं कर सकता। एक बाइंड माउंट अधिक बेहतर होगा।

एक और: मेरा प्रोजेक्ट उपयोग कंटेनर में स्रोतों से निर्माण के लिए भंडार में डॉकरफाइल वितरित करता है। वर्तमान में, हम जीथब से कंटेनर में एक और गिट क्लोन खींचते हैं। उथले क्लोन और सभी हैं, लेकिन फिर भी ...

इसलिए, मैंने अभी एक rhel7 बिल्ड होस्ट पर [1] का परीक्षण किया है, और Red Hat के docker daemon DOES में बिल्ड के लिए -v विकल्प है। मैंने CentOS/Fedora पर परीक्षण नहीं किया है, लेकिन कोई कल्पना करेगा कि Fedora/CentOS के पास शायद यह भी है। यह परीक्षण के लायक है। इसके अलावा, आरएचईएल डेवलपर सब्सक्रिप्शन अब मुफ्त हैं [2]:

@ फादरलिनक्स फेडोरा के तहत 'डॉकर बिल्ड-वी' भी उपलब्ध है।

@fatherlinux CentOS 7 संस्करण में यह शामिल है।

+1 मुझे लगता है कि आधिकारिक डॉकर में जोड़ने के लिए यह वास्तव में उपयोगी सुविधा होगी।

सेंटोस और लिनक्समिंट (अब 17.03.1-सीई चल रहा है) दोनों पर अपडेट किया गया है, क्या मुझे यहां कुछ याद आ रहा है? मुझे विकल्प -v . दिखाई नहीं दे रहा है

टकसाल पर

$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18
DISTRIB_CODENAME=sarah
DISTRIB_DESCRIPTION="Linux Mint 18 Sarah"
$ docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

सेंटोस 7 . पर

# docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
# docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:05:44 2017
 OS/Arch:      linux/amd64
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core) 

@wilfriedroset CentOS 7 में, गैर-आधिकारिक डॉकर पैकेज विकल्प प्रदान करते हैं। मुझे लगता है कि यह ईपीईएल भंडार का हिस्सा है।

धन्यवाद @नाथनजैकसन। क्या हमारे पास आधिकारिक रिलीज में इस सुविधा के लिए ईटीए है?

@wilfriedroset AFAIK, कोई ईटीए नहीं है क्योंकि यह निर्णय लिया गया था (कई बार) कि यह सुविधा "पोर्टेबिलिटी बनाने" को संरक्षित करने के लिए आधिकारिक डॉकर में नहीं होनी चाहिए। उर्फ आपके Dockerfiles को Docker बिल्ड सेवा सहित कहीं भी चलाने की अनुमति देता है।

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

उदाहरण के लिए, यदि आप NFS माउंट का उपयोग करते हैं, तो सुनिश्चित करें कि सभी बिल्ड सर्वरों के पास उनके fstabs में माउंट है और आप फ़ार्म में कहीं भी बिना किसी समस्या के निर्माण करेंगे।

आरएचईएल 7.3 . पर
````
[ रूट@rhel7 ~]# डॉकर बिल्ड --help

उपयोग: डोकर बिल्ड [विकल्प] पथ | यूआरएल | -

Dockerfile से एक छवि बनाएँ

विकल्प:
--बिल्ड-आर्ग वैल्यू बिल्ड-टाइम वैरिएबल सेट करें (डिफ़ॉल्ट [])
--cgroup-पैरेंट स्ट्रिंग कंटेनर के लिए वैकल्पिक पैरेंट cgroup
--cpu-अवधि int CPU CFS (पूरी तरह से उचित अनुसूचक) अवधि को सीमित करें
--cpu-quota int CPU CFS (पूरी तरह से उचित अनुसूचक) कोटा को सीमित करें
-c, --cpu-shares int CPU शेयर (सापेक्ष भार)
--cpuset-cpus स्ट्रिंग सीपीयू जिसमें निष्पादन की अनुमति है (0-3, 0,1)
--cpuset-mems स्ट्रिंग MEMs जिसमें निष्पादन की अनुमति है (0-3, 0,1)
--disable-content-trust छवि सत्यापन छोड़ें (डिफ़ॉल्ट सत्य)
-f, --file string Dockerfile का नाम (डिफ़ॉल्ट 'PATH/Dockerfile' है)
--force-rm हमेशा मध्यवर्ती कंटेनरों को हटा दें
--सहायता प्रिंट उपयोग
--आइसोलेशन स्ट्रिंग कंटेनर आइसोलेशन टेक्नोलॉजी
--लेबल मान छवि के लिए मेटाडेटा सेट करें (डिफ़ॉल्ट [])
-एम, --मेमोरी स्ट्रिंग मेमोरी लिमिट
--मेमोरी-स्वैप स्ट्रिंग स्वैप सीमा मेमोरी प्लस स्वैप के बराबर: असीमित स्वैप को सक्षम करने के लिए '-1'
--no-cache छवि बनाते समय कैश का उपयोग न करें
--pull हमेशा छवि के नए संस्करण को खींचने का प्रयास करें
-q, --quiet बिल्ड आउटपुट को रोकें और सफलता पर छवि आईडी प्रिंट करें
--rm सफल निर्माण के बाद मध्यवर्ती कंटेनरों को हटा दें (डिफ़ॉल्ट सत्य)
--shm- आकार स्ट्रिंग /dev/shm का आकार, डिफ़ॉल्ट मान 64MB . है
-t, --tag मान नाम और वैकल्पिक रूप से ' नाम: टैग ' प्रारूप में एक टैग (डिफ़ॉल्ट [])
--ulimit मान Ulimit विकल्प (डिफ़ॉल्ट [])
-v, --volume मान बिल्ड-टाइम बाइंड माउंट सेट करें (डिफ़ॉल्ट [])
```

सीआई बिल्डिंग नोड प्रोजेक्ट्स पर एक और उपयोग केस सभी छवियों को बनाते समय सीआई के yarn कैश को साझा करना है।

+1: नोड_मॉड्यूल्स को बार-बार स्थापित करना वास्तव में भयानक है, खासकर नोडज माइक्रो सेवाओं के लिए
मैं इस समस्या को nfs के साथ हल करने का प्रयास कर रहा हूं, मुझे लगता है कि "दोहराने योग्य" इस सुविधा को लागू नहीं करने का एक अच्छा कारण नहीं है ...

ऐसा लगता है कि #31257 और #32063 के विलय के साथ यह और भी महत्वपूर्ण हो जाएगा।

#32507 . पर एक नज़र डालें

@ फादरलिनक्स क्या आप बता सकते हैं कि जब आप Dockerfile के भीतर COPY कमांड रख सकते हैं तो पोर्टेबिलिटी कैसे काम करती है? मेरे पास एक समस्या है जहां मैं एक बड़ी फ़ाइल (समय जटिलता कारणों से) की प्रतियों की संख्या से बचना चाहता हूं और कंटेनर के साथ फ़ाइल साझा करने के लिए बिल्ड-टाइम रीड-ओनली विकल्प की तलाश कर रहा हूं।

@arunmk देखें https://github.com/moby/moby/issues/32507

@arunmk @cpuguy83 बिल्कुल। विचार यह है कि आप वास्तव में निर्माण पर कंटेनर में डेटा कॉपी नहीं करना चाहते हैं। यह इसे बहुत बड़ा बना सकता है। हम केवल निर्माण समय पर उपलब्ध डेटा चाहते हैं। ऊपर के अनुसार, आप डॉकर डेमॉन के Red Hat के संस्करण में -v बाइंड माउंट कर सकते हैं जो आपको डेटा उपलब्ध कराने की अनुमति देता है, लेकिन यह अभी केवल पढ़ा जाता है (पिछले सप्ताह मुझे जला दिया)।

इसलिए, यदि आपको आज इसकी आवश्यकता है, तो फेडोरा, सेंटोस, या आरएचईएल देखें और आप बिल्ड समय पर डेटा की रीड ओनली कॉपी में माउंट कर सकते हैं ...

और, अगर आपको बिल्ड फार्म के भीतर पोर्टेबिलिटी की आवश्यकता है, तो मैं एनएफएस या कुछ ऐसे सुझाव दूंगा ....

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

एक काल्पनिक उदाहरण:

FROM fatImage AS build
COPY bigData /data
RUN some_stoff /data

FROM tinyImage
COPY --from=build /data/result

स्पष्टीकरण के लिए धन्यवाद @ फादरलिनक्स
@ cpuguy83 विस्तार के लिए धन्यवाद। मुझे अपने मुद्दे में और विवरण जोड़ने दें जो असामान्य हो सकता है: मेरे पास एक बिल्ड सिस्टम है जो 3.3GB फ़ाइल उत्पन्न करता है। इसे एक RPM में जोड़ा जाता है जो एक डॉकटर कंटेनर के भीतर बनाया जाता है। इसलिए दो प्रतियां बनाई जाती हैं: एक बिल्ड सिस्टम से डॉकटर कंटेनर में, एक डॉक कंटेनर के भीतर से आरपीएम के भीतर। अब, मैं दूसरी प्रति से बच नहीं सकता। मैं पहली प्रति से बचने के बारे में सोच रहा था लेकिन ऐसा लगता है कि मल्टी-स्टेज बिल्ड के साथ भी यह संभव नहीं है।
मैं समझ सकता हूँ कि, यदि बड़ी फ़ाइल का बार-बार उपयोग किया जाता, तो बहु-चरणीय प्रतिलिपि प्रतिलिपि के चलने की संख्या को '1' तक कम कर देती। मैं इसे एक बार उपयोग करता हूं और संख्या को '0' तक कम करना चाहता हूं। क्या मैं यह समझने में सही हूँ कि यह संभव नहीं होगा?

@arunmk कोई फर्क नहीं पड़ता कि इसे क्लाइंट से बिल्ड इंस्टेंस में कॉपी करना होगा।

@ cpuguy83 स्पष्टीकरण के लिए धन्यवाद। ऐसा लगता है कि मुझे अभी के लिए ओवरहेड लेना है। क्या यह परमाणु होना है?

@फादरलिनक्स

मैंने कोशिश की कि आपने क्या कहा, RHEL7 पर -v का उपयोग करके निर्माण के दौरान निर्देशिका को पढ़ने और पढ़ने के लिए, लेकिन यह त्रुटि प्राप्त करें:

डोकर बिल्ड में वॉल्यूम समर्थित नहीं हैं। कृपया केवल बाइंड माउंट का उपयोग करें।

यह केवल आरएचईएल के डॉकटर पैकेज के साथ काम करेगा न कि डॉकर के पैकेज के साथ। पैच अपस्ट्रीम स्वीकार नहीं किया गया था।

@फादरलिनक्स

मैंने कोशिश की कि आपने क्या कहा, RHEL7 पर -v का उपयोग करके निर्माण के दौरान निर्देशिका को पढ़ने और पढ़ने के लिए, लेकिन यह त्रुटि प्राप्त करें:

डोकर बिल्ड में वॉल्यूम समर्थित नहीं हैं। कृपया केवल बाइंड माउंट का उपयोग करें।

@fcntl

त्रुटि के अनुसार आपको बाइंड का उपयोग करने की आवश्यकता है, आपने शायद -v /something /hostsomething:/containersomething किया है

@thebigb और शायद अन्य, हमने docker बिल्ड के दौरान ccache का उपयोग करने में सक्षम होने के लिए एक बुनियादी ढांचा स्थापित किया है। हमने इसे https://github.com/WebHare/ccache-memcached-server पर प्रकाशित किया है यदि यह आपकी मदद करता है, हालांकि आदर्श रूप से इस मुद्दे को हल करने से शायद यह अप्रचलित हो जाएगा।

मैं बस जोड़ने वाला था, एक उपयोग केस जिसकी मुझे वास्तव में आवश्यकता है वह है ccache। मैं एक डोकर छवि निर्माण के दौरान अपने ccache कैश को माउंट करने में सक्षम होना चाहता हूं - छवि में ही इसका कोई मतलब नहीं है। @unilynx मैं आपके कामकाज पर एक नज़र डालेगा - अच्छा समय!

एक और आवाज जूस।

मेरा उपयोग मामला: वर्तमान में मैं /root/.cache और /var/cache/apk निर्देशिकाओं को साझा करने के लिए रॉकर के MOUNT कमांड का उपयोग करता हूं।

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

@embray @roxma पर एक नज़र डालें https://github.com/moby/moby/issues/32507 यदि वह आपके उपयोग के मामले को संबोधित करेगा; प्रतिक्रिया का स्वागत है

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

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

@ gim913 विभिन्न वितरणों में डॉकटर एकीकरण के इस चरण में, बदलते परिवेश (यानी डॉकटर को पूरी तरह से छोड़ना) आपके 'ओएस' को बदलने की तुलना में बहुत अधिक विघटनकारी लगता है (मुझे लगता है कि आपका मतलब रेडहैट बिल्ड की ओर एक अलग लिनक्स वितरण से स्विच करना है जिसमें स्पष्ट रूप से शामिल है -वी?)

क्या RedHat के डॉकर के संस्करण को लेना आसान नहीं होगा? शायद यहां कोई आपको निर्माण में '-v' विकल्प प्राप्त करने के लिए प्रासंगिक पैच/कांटे/प्रतिबद्धता की ओर इशारा कर सकता है।

@unilynx यहाँ तुम जाओ

मैं कुछ उदाहरण देख रहा था जो wget का उपयोग करते थे और यहां आए ... मेरा उपयोग मामला समान है ... मैं एक बड़े टैरबॉल को खोलना चाहता हूं और बस इसे चलाना चाहता हूं। मैं docker फ़ाइल w/टारबॉल या स्थानीय वेब सर्वर से wget करने में समय बर्बाद नहीं करना चाहता हूं। माउंटिंग जैसे आप कर सकते हैं w/docker कंपोज़ बिल्ड समय पर करने के लिए एक उचित चीज़ की तरह लगता है। कृपया पुनीत के परिवर्तन को मर्ज करें यदि यह ठीक लगे :-)

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

यह जोड़ना आसान होगा और बेहद उपयोगी (या एक माउंट कमांड, rocker फिर से देखें)। कितना समय (समुदाय में) इस या इसी तरह की लापता सुविधाओं के आसपास स्क्रिप्टिंग में खर्च किया जाता है?

@awbacker मल्टी-स्टैग बिल्ड इसे बहुत अच्छी तरह से हल करता है जहाँ आप कुछ ऐसा कर सकते हैं

FROM something AS my_wheels
RUN compile_all_the_things

FROM something
COPY --from my_wheels /wherever
RUN do_stuff_with_wheels

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

एक प्रस्ताव भी है जो RUN --mount की अनुमति देगा जहां माउंट स्पेक इसे कॉपी करने के बजाय my_wheels बिल्ड लक्ष्य से किसी चीज़ को माउंट करने के लिए कहेगा।

@kenyee की तरह, यह बिल्ड संदर्भ से कुछ माउंट कर सकता है, जिसे 17.07-प्रयोगात्मक में केवल आवश्यकतानुसार ही भेजा जाता है।

@ cpuguy83 यह व्यवहार में काम नहीं करता है - कम से कम ग्रैडल जावा बिल्ड के लिए। मेरे पास एक आधार डॉकर छवि है जिसमें ग्रैडल जार फाइलें पूर्व-कैश्ड हैं, लेकिन आपके स्रोत का ग्रैडल बिल्ड वह है जो आपकी सभी निर्भरताओं को कैश में डाउनलोड करता है।

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

@BryanHunt तो आपकी बिल्ड प्रक्रिया का हिस्सा डिप्स डाउनलोड कर रहा है? यह सुनिश्चित करने के लिए कि ग्रैडल को बिना और वास्तव में निर्माण किए बिना इन्हें कैश करने का एक तरीका प्रदान करना चाहिए?

@ cpuguy83 हां, डिप्स को बिल्ड के हिस्से के रूप में डाउनलोड किया जाता है। मूल रूप से मेवेन के समान ही। संदर्भ के लिए: https://github.com/gradle/gradle/issues/1049

क्या माउंट बनाने के लिए कहीं कोई जनसंपर्क था?

@grangert यहाँ

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

डॉकर बिल्ड पर A -v विकल्प हमें CI सर्वर से माउंट किए गए फ़ोल्डर में परीक्षण परिणामों को संग्रहीत करने और वर्तमान 2-चरणीय प्रक्रिया की आवश्यकता को दूर करने की अनुमति देगा।

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

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

@BryanHunt @stepps @yngndrw अन्य भी @awhitford
बिल्ड डिपेंडेंसीज को कैश करने का एक तरीका यह है कि आप अपने बिल्ड वर्क को उदाहरण के लिए मल्टी-स्टेज गो बिल्ड इन डॉक्यूमेंटेशन या पायथन ऑनबिल्ड डॉकरफाइल बनाएं ।
यहां एक उदाहरण दिया गया है जो मैंने मेवेन के लिए काम करता प्रतीत होता है। मैं इसे यहाँ कॉपी करूँगा।

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

FROM openjdk
COPY --from=0 /usr/src/app/target/*.jar ./

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

@sixcorners जो ग्रैडल के लिए काम नहीं करता है

@BryanHunt यह डॉकरफाइल या यह दृष्टिकोण धीरे-धीरे काम नहीं करता है? cpuguy83 ने पूछा कि क्या वास्तव में निर्माण किए बिना निर्भरता डाउनलोड करने का कोई तरीका है। आपने समाधान निर्भरता कार्य से लिंक किया है। क्या आप केवल build.gradle फ़ाइल नहीं जोड़ सकते थे और उस कार्य को चला सकते थे?

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

@Sixcorners द्वारा मल्टीस्टेज एक दिलचस्प ट्रिक है और मैंने इसे विभिन्न पैकेज मैनेजरों (जैसे npm, कंपोज़र) के लिए उपयोग करते देखा है।

हालांकि एक समस्या है, जब भी चरण 0 छवि में निर्भरता की सूची COPY pom.xml बदली जाती है तो परत को हटा दिया जाता है और इस प्रकार पूरा कैश चला जाता है। इसका मतलब है कि जब भी कोई डेवलपर पोम (एक टिप्पणी, 1kBytes निर्भरता) में कुछ भी बदलता है तो पूरे कैश को फिर से डाउनलोड किया जाना चाहिए।

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

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

मल्टीस्टेज एक अच्छा समाधान है, लेकिन यह आदर्श नहीं है।

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

हालाँकि, एक समस्या है, जब भी निर्भरता की सूची बदली जाती है, तो चरण 0 छवि में pom.xml कॉपी करें, जिससे परत बाहर निकल जाती है और इस प्रकार पूरा कैश चला जाता है। इसका मतलब है कि जब भी कोई डेवलपर पोम (एक टिप्पणी, 1kBytes निर्भरता) में कुछ भी बदलता है तो पूरे कैश को फिर से डाउनलोड किया जाना चाहिए।

@ हशर ध्यान दें कि COPY --from सुविधा बिल्ड-स्टेज तक सीमित नहीं है; डॉकरफाइल संदर्भ से:

वैकल्पिक रूप से COPY एक ध्वज स्वीकार करता है --from=<name|index> जिसका उपयोग स्रोत स्थान को पिछले निर्माण चरण ( FROM .. AS <name> के साथ बनाया गया) पर सेट करने के लिए किया जा सकता है जिसका उपयोग भेजे गए निर्माण संदर्भ के बजाय किया जाएगा उपयोगकर्ता द्वारा। ध्वज FROM निर्देश के साथ शुरू किए गए सभी पिछले निर्माण चरणों के लिए असाइन किए गए एक संख्यात्मक सूचकांक को भी स्वीकार करता है। _ यदि किसी निर्दिष्ट नाम के साथ एक बिल्ड चरण नहीं मिल पाता है तो उसी नाम के साथ एक छवि का उपयोग करने का प्रयास किया जाता है। _

यह आपको अपनी निर्भरताओं के लिए एक छवि _build_ करने, उसे टैग करने और अपनी निर्भरताओं की प्रतिलिपि बनाने के लिए इसका उपयोग करने की अनुमति देता है। उदाहरण के लिए:

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

docker build -t dependencies:1.0.0 .

और अपनी निर्भरता के लिए dependencies:1.0.0 छवि का उपयोग करके निर्दिष्ट करें;

FROM openjdk
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar ./

या (परीक्षण करने के लिए सिर्फ एक बहुत ही बुनियादी उदाहरण);

$ mkdir example && cd example
$ touch dep-one.jar dep-two.jar dep-three.jar

$ docker build -t dependencies:1.0.0 . -f -<<'EOF'
FROM scratch
COPY . /usr/src/app/target/
EOF

$ docker build -t myimage -<<'EOF'
FROM busybox
RUN mkdir /foo
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar /foo/
RUN ls -la /foo/
EOF

बिल्ड के आउटपुट में, आप देखेंगे:

Step 4/4 : RUN ls -la /foo/
 ---> Running in 012a8dbef91d
total 8
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 .
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 ..
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-one.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-three.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-two.jar
 ---> 71fc7f4b8802

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

बिल्डकिट को गिट के लिए मूल समर्थन है
https://github.com/moby/buildkit

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

#!/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 . चलाएं

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

पायथन के मामले में, जब हम pip install package इसे और इसकी निर्भरता को कैश फ़ोल्डर में डाउनलोड किया जाता है और फिर साइट-पैकेज में स्थापित किया जाता है।
एक अच्छे अभ्यास के रूप में हम pip --no-cache-dir install package का उपयोग वर्तमान परत में कचरा/कैश स्टोर नहीं करने के लिए करते हैं। लेकिन सर्वोत्तम अभ्यास के लिए कैश फ़ोल्डर को बिल्ड संदर्भ से बाहर रखना वांछित है। तो निर्माण समय -v मदद करेगा।
ऊपर उल्लिखित कुछ उपयोगकर्ता COPY . /somewhere/in/container/ का उपयोग करते हैं यह उपयोगकर्ता ऐप या फ़ाइलों के लिए ठीक है लेकिन कैश के लिए नहीं। क्योंकि COPY स्वयं के रूप में एक और परत बनाता है और बाद की परतों में कैश निकालना उपयोगी नहीं होगा। अन्य बुरा साइड इफेक्ट यह है कि जब हम COPY का उपयोग करते हैं तो कैश बदल जाता है, संदर्भ बदल जाता है और निम्नलिखित परतें अमान्य हो जाएंगी और पुनर्निर्माण के लिए मजबूर हो जाएंगी।

@wtayyeb यदि आपके पास Dockerfile है जो pip install ... केवल तभी चलता है जब आवश्यकताएं फ़ाइल बदलती हैं तो बिल्ड टाइम -v इतना महत्वपूर्ण नहीं लगता क्योंकि आवश्यकताएं उतनी बार नहीं बदलती हैं जितनी बार एप्लिकेशन बिल्डिंग करते समय बदलते हैं।

@wtayyeb आप कैश और लीन इमेज दोनों के लिए मल्टी-स्टेज Dockerfile का उपयोग कर सकते हैं। यही है, किसी निर्देशिका में अजगर को स्थापित करने के लिए एक इंस्टॉलर छवि का उपयोग करें और फिर अपनी अंतिम छवि के लिए COPY --from का उपयोग बिना किसी इंस्टॉलेशन कलाकृतियों के केवल आवश्यक पायथन फ़ाइलों को स्थानांतरित करने के लिए या यहां तक ​​​​कि खुद को पाइप करने के लिए करें।

@manishtomar , धन्यवाद, हाँ और नहीं! स्वच्छ मामले में सभी निर्भरताएं फिर से डाउनलोड की जाती हैं और निर्माण और पहियों में परिवर्तित हो जाती हैं और कैश की जाती हैं, फिर गंतव्य वातावरण में स्थापित हो जाती हैं। तो अगर कोई वहाँ आवश्यकताओं को रखता है तो वह एक बार का काम है। लेकिन अगर एक छोटी निर्भरता को अद्यतन किया जाता है, तो सभी निर्भरताओं को पुन: डाउनलोड, पुन: निर्माण और पुन: व्हील किया जाना चाहिए और उपयोग योग्य होने के लिए फिर से कैश किया जाना चाहिए।
कई नौकरियों के मैट्रिक्स में अपने पुस्तकालयों और अपने अनुप्रयोगों के निर्माण और परीक्षण के लिए सीआई का उपयोग करते समय, अपने सीआई सर्वर में समवर्ती नौकरियों की संख्या में काम से ऊपर गुणा करें और iowait को 3s से अधिक और SSDs के साथ भी 15 से ऊपर लोड औसत प्राप्त होगा। (ये नंबर 2 समवर्ती बिल्ड और ~ 20 निर्भरता वाले ऐप के लिए वास्तविक हैं) मुझे लगता है कि पीपी कैश इसे सही तरीके से कर रहा है, फिर से डाउनलोड करने, फिर से बनाने और तैयार पैकेजों को फिर से चलाने से बच रहा है। और बिना बाइंड-वी के हम समय और सर्वर संसाधनों को खो देते हैं।

@ibukanov , धन्यवाद। मैं अपने ऐप्स पैकेज बनाने और बाद में उनका उपयोग करने के लिए मल्टी-स्टेज डॉकरफाइल का उपयोग कर रहा हूं। यह मदद करेगा अगर मेरे पास केवल एक डॉकरफाइल है और इसे कई बार बनाना चाहते हैं, लेकिन क्या होगा यदि कई डॉकरफाइल हों और प्रत्येक एक पायथन संस्करण (अभी के लिए 2.7,3.6) के खिलाफ बनाया गया हो और इसमें कई सी-एक्सटेंशन भी हों जिन्हें करने की आवश्यकता है चयनित आधार छवि के लिए निर्माण किया जा सकता है? उपरोक्त पैराग्राफ के बारे में क्या?

@thaJeztah आपका सुझाव बहुत अच्छा है और यह हमें कुछ समय बचाएगा, हालांकि बिल्ड कैश के मामले में हम वास्तव में दूसरी छवि से कुछ भी कॉपी नहीं करना चाहते हैं।
हम किसी अन्य छवि को कॉपी किए बिना एक्सेस क्यों नहीं कर सकते?

@thedrow मेरा उदाहरण उन विशेषताओं के साथ था जो वर्तमान में हैं; RUN --mount प्रस्ताव (https://github.com/moby/moby/issues/32507) पर एक नज़र डालें, जो आपके उपयोग के मामले में अधिक उपयुक्त हो सकता है

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

मैं एक जेंटू कंटेनर उपयोगकर्ता भी हूं और https://github.com/moby/moby/issues/3156 से पुनर्निर्देशित किया गया था जो इस लापता कार्यक्षमता के लिए पूरी तरह से वैध उपयोग का मामला है।

मैं वास्तव में बिल्ड-टाइम पर किसी अन्य छवि की सामग्री को माउंट करने की क्षमता चाहता हूं ताकि मैं अपनी छवियों को ब्लोट न करूं।

@kbaegis https://github.com/moby/moby/issues/32507 में प्रस्तावित सुविधा के साथ एक सटीक मिलान की तरह लगता है

ज़रूर। वह केवल 3 वर्षों के बजाय एक वर्ष के लिए बैकलॉग में एक लागू नहीं किया गया P3 है।

ऐसा लगता है कि https://github.com/projectatomic/buildah वास्तव में इस बुनियादी कार्यक्षमता के लिए डॉकटर बिल्ड को बहुत जल्दी बनाने जा रहा है। मुझे लगता है कि ऐसा होने पर मैं बस अपनी पाइपलाइन को स्विच करने जा रहा हूं।

@kbaegis इस चर्चा में जोड़ने के लिए आप यहां क्या आए थे? आपने एक उपयोग-मामले का वर्णन किया है जो _exactly_ किसी भिन्न प्रस्ताव से मेल खाता है;

मैं वास्तव में बिल्ड-टाइम पर किसी अन्य छवि की सामग्री को माउंट करने की क्षमता चाहता हूं ताकि मैं अपनी छवियों को ब्लोट न करूं।

यह खुला स्रोत है, चीजें जादुई रूप से अस्तित्व में नहीं आती हैं।

मैं चर्चा में क्या जोड़ना चाह रहा हूँ?

संक्षेप में मैं इस टूलसेट से आगे बढ़ रहा हूं। मुझे यकीन है कि विकास टीम के लिए यह मूल्यवान जानकारी है क्योंकि मुझे यकीन है कि मैं वहां अकेला नहीं हूं।

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

मेरे पास जोड़ने के लिए एक (rehash, मुझे यकीन है) उपयोग केस मिला है। #32507 यह बेहतर सूट कर सकता है।

मैं कुछ जैव सूचना विज्ञान पाइपलाइनों के लिए एक डोकर छवि बना रहा हूँ। कुछ उपकरणों के लिए उनके संकलन/स्थापना से पहले कुछ डेटाबेस मौजूद होने की आवश्यकता होती है (कृपया यह न पूछें, यह मेरा कोड नहीं है )। इन डेटाबेसों का वजन कम से कम 30GB है।

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

@draeath https://github.com/grammarly/rocker पर एक नज़र डालें। यह पहले से ही एक सुंदर MOUNT निर्देश का समर्थन करता है।

@draeath भी, बिल्डह देखें, यह डिफ़ॉल्ट रूप से माउंट का समर्थन करता है क्योंकि यह एक प्रोग्रामिंग टूल की तरह अधिक स्थापित है। Dockerfile के साथ माउंट का भी समर्थन करता है:

https://github.com/projectatomic/buildah

@फादरलिनक्स और @ लिग दोनों को धन्यवाद - इससे मुझे अपना काम पूरा करने में मदद मिलेगी। मुझे अभी भी लगता है कि मुझे इसे करने के लिए परियोजना से बाहर नहीं भटकना चाहिए, और फिर भी इसे देखना पसंद करेंगे और # 32507 लागू किया जाएगा;)

मैं यहां कुछ गुगलिंग के माध्यम से एक ही सुविधा के लिए पूछने के लिए आया हूं, 'डॉकर बिल्ड' समय पर वॉल्यूम, 'डॉकर रन' समय नहीं।

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

मैं एक डॉकर छवि बनाना चाहता हूं जो पहली बार "फर्मवेयर छवि बनाएं" पास करता है, और फिर उन कंटेनरों को स्पॉन करने में सक्षम होता है जो फर्मवेयर छवि को ताजा-ऑफ-द-लाइन पीसीबी पर धक्का देते हैं। एक डॉकरफाइल ऐसा दिख सकता है:
----------[ यहां से काटे ]----------
आधार-छवि से निर्माता के रूप में
स्रोत स्रोत कॉपी करें
रन बिल्ड-src

फ्लैशर के रूप में बेस-इमेज से
कॉपी --from=बिल्डर निर्माण-कलाकृतियों
रन सीपीयू-बिल्ड-एंड-फ्लैश --बिल्ड-ओनली
----------[ यहां से काटे ]----------
दुर्भाग्य से, सीपीयू-बिल्ड-एंड-फ्लैश चरण को यूएसबी बस के माध्यम से लक्ष्य डिवाइस तक पहुंच की आवश्यकता होती है, भले ही यह फर्मवेयर छवि को डिवाइस पर धक्का न दे। इस प्रकार मुझे 'डॉकर रन' कमांड से '-v/dev/usb/bus:/dev/usb/bus' लेने की जरूरत है और इसके बजाय इसे बिल्ड में रखना होगा।

यह स्पष्ट है कि यह वर्तमान में संभव नहीं है।

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

रुचि रखने वाले किसी भी व्यक्ति के लिए अपडेट करें: मैंने हाल ही में बिल्डह के साथ अपने पूरे पाइप को सफलतापूर्वक पुनर्निर्माण किया है। मुझे वर्तमान में समानांतर में चलने वाली दो बिल्ड पाइपलाइन मिल गई हैं और ओसीआई/बिल्डह पाइपलाइन छोटी छवियां उत्पन्न कर रही है (विशेष रूप से मेरे मामले में इसे किसी अन्य माउंट के साथ मास्क करके/usr/portage को हटा रही है)।

और अंत में यह सुविधा यहाँ है: https://github.com/docker/docker-py/issues/1498

लेकिन मुझे बिल्ड कैश के लिए RW वॉल्यूम चाहिए

शनिवार, 28 अप्रैल 2018, 17:29 को оренберг арк , [email protected] ने लिखा:

और अंत में यह सुविधा यहाँ है: docker/docker-py#1498
https://github.com/docker/docker-py/issues/1498

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/14080#issuecomment-385188262 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAZQTJodLCCzyDdPFtNiIUZ_z85YvLWbks5ttJjagaJpZM4FIdOc
.

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

आदर्श लक्ष्य एक बार निर्माण करना है, एक बार परीक्षण करना है, और अभी भी मेजबान सिस्टम को परिणाम फ़ाइल दी गई है, यहां तक ​​​​कि घटना में (और विशेष रूप से घटना में) जो परीक्षण विफल हो जाते हैं, निर्माण को रोकते हैं।

हाँ कृपया। पूरे दिन।

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

docker build -t x .
ID=$(docker create x)
docker cp $ID:/package.deb .
docker rm $ID

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

क्या हमें उन लोगों के लिए एक अलग मुद्दा बनाना चाहिए जो बिल्ड कैश के लिए बिल्ड-टाइम वॉल्यूम चाहते हैं/चाहते हैं?

@ajbouh हाँ, शायद https://github.com/moby/buildkit/issues . पर

देखें https://github.com/moby/moby/issues/32507#issuecomment -391685221

बुधवार, 23 मई, 2018, 19:22 को अकिहिरो सूडा नोटिफिकेशन @github.com ने लिखा:

@ajbouh https://github.com/ajbouh हाँ, शायद पर
https://github.com/moby/buildkit/issues

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/14080#issuecomment-391566368 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAAcnSqNoVc4j34ElECy53gIfPecQFKfks5t1hlkgaJpZM4FIdOc
.

जब आप बिल्ड-टाइम पर वॉल्यूम नहीं जोड़ सकते हैं, तो आप होस्ट जोड़ सकते हैं, इसलिए अब मैं अपनी सभी डॉकर छवियों को --add-host yum-mirror:$MIRROR_IP जैसी किसी चीज़ के साथ बनाता हूं जो एक यम दर्पण की सेवा करता है जो मेरी छवियों का निर्माण तब एक रैपर के माध्यम से पता लगाता है यम। आसान जब मेरी परियोजना दिन में कई बार निर्भरता बदलती है और मैं ऑफ़लाइन हूं या खराब कनेक्शन पर हूं (परियोजना के हिस्से में इसके कई डिपो को अपडेट करना और साफ करना शामिल है)।

मुझे इस समस्या को हल करने के लिए डॉकर के प्रतिरोध को क्रुद्ध करने वाला लगता है।

बिल्डकिट के लिए प्रायोगिक समर्थन को हाल ही में विलय कर दिया गया था, इसके साथ RUN --mount=<opts> <command> के विकल्प के साथ आता है।

@cpuguy83 नोट का लिंक: https://github.com/moby/buildkit/pull/442

@glensc @cpuguy83 हम इस मर्ज किए गए फीचर के रिलीज की उम्मीद कब कर सकते हैं?

+1

RUN --mount में वॉल्यूम सपोर्ट नहीं है, इसलिए https://github.com/avsm/docker-ssh-agent-forward जैसी चीजें निर्माण के समय असंभव रहती हैं, इसका समाधान क्या है?

@ पीटर-एज https://github.com/moby/buildkit/pull/655

docker build --secret अंततः डॉकर 18.09 में उपलब्ध है https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

क्या हम इस मुद्दे को बंद कर सकते हैं?

कैशिंग उपयोग के मामले में --secret उपयोग करने योग्य नहीं है, जो मैं बता सकता हूं।

@AkihiroSuda RUN --mount सामान्य रूप से ऐसा लगता है कि इस मुद्दे के समाधान के रूप में संभवतः कुछ उपयुक्त है।

हां, मुझे लगता है कि RUN --mount=type=cache (कैश वॉल्यूम के लिए) और --mount=type=secret के साथ docker build --secret (गुप्त मात्रा के लिए) लगभग इस मुद्दे को कवर करता है।

@AkihiroSuda तो, मूल मुद्दे को हल करने वाला एक कामकाजी उदाहरण देखना अच्छा होगा

@AkihiroSuda लेख से (https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066) मैंने बिल्ड के दौरान माउंट का उपयोग करने के 2 उपयोग के मामले देखे: गुप्त और एसएसएच

[गुप्त]

docker build --secret id=mysite.key,src=path/to/mysite.key .
RUN --mount=type=secret,id=mysite.key,required <command-to-run>

[एसएसएच]

RUN --mount=type=ssh git clone [email protected]:myorg/myproject.git myproject

2 अन्य उपयोग के मामले हैं (जो मुझे याद हैं) जिन्हें लेख में उपयोग करने के तरीके के बारे में नहीं बताया गया है और न ही इस अंक में:

1) [कैश] RUN --mount=type=cache
2) सामान्य रूप से वॉल्यूम (उदाहरण के लिए, एसएसएल प्रमाणपत्र माउंट करने के लिए, या बड़े वॉल्यूम के मामले में जो निर्माण के दौरान उपयोग किया जाना चाहिए, लेकिन जेनरेट की गई छवि में शामिल नहीं है, और इसी तरह ...)

webpack चलाने से पहले एक बार उपयोग का मामला yarn कार्यक्षेत्र बढ़ रहा है

आप यह सब कर सकते हैं..

RUN --mount=type=cache,from=<some image>,source=<path in from image>,target=<target>

आप from=<some image> को from=<some build stage> . में भी बदल सकते हैं

यहाँ एक काल्पनिक उदाहरण है:

# syntax=docker/dockerfile:1.0.0-experimental
FROM busybox as hello
RUN  echo hello > /hello.txt

FROM scratch
RUN --mount=type=cache,from=busybox,source=/bin,target=/bin --mount=type=cache,from=hello,source=/hello.txt,target=/tmp/hello.txt echo /tmp/hello.txt

यहां इस पर कुछ दस्तावेज दिए गए हैं: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md

मैं @AkihiroSuda से सहमत हूं, यह सभी मामलों को संभालना चाहिए ... लेकिन कृपया हमें बताएं कि क्या ऐसा नहीं है।

@AkihiroSuda @ cpuguy83 : दुर्भाग्य से, वर्तमान कार्यान्वयन (डॉकर 18.09 में बिल्डकिट) में निजी रजिस्ट्रियों के साथ समस्याएँ हैं। अब तक, इन नई सुविधाओं का उपयोग नहीं किया जा सकता है यदि आपको अपनी छवियों को एक निजी रजिस्ट्री के माध्यम से लाना है। मेरे परीक्षण https://github.com/moby/moby/issues/38303 में देखें।

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

यह बहुत उपयोगी होगा। मुझे वास्तव में --experimental को RUN --mount=type=cache /user/.cache/pip pip install $ का समर्थन करने के लिए जोड़ने की आवश्यकता नहीं होगी (पैकेज इंडेक्स बैंडविड्थ को बचाने के लिए)।

buildah bud ( buildah build-using-dockerfile ) में --volume / -v विकल्प है:
https://github.com/containers/buildah/blob/master/docs/buildah-bud.md

buildah बिना डॉक सॉकेट के गैर-रूट के रूप में बिल्ड चला सकता है।

क्योंकि नेटवर्क से पैकेज डाउनलोड अधिक प्रतिलिपि प्रस्तुत करने योग्य हैं?

क्लाइंट पर "--experimental", केवल "DOCKER_BUILDKIT=1" जोड़ने की आवश्यकता नहीं है।

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

ध्यान दें कि आप एक छवि को बिल्ड में भी माउंट कर सकते हैं।

हां, नेटवर्क बिल्ड अधिक प्रतिलिपि प्रस्तुत करने योग्य हैं क्योंकि संदर्भ सभी डॉकरफाइल में है।

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

यदि आपको निर्माण कार्य करने के लिए होस्ट से संदर्भ माउंट करना है तो यह एक बुरा अनुभव है।

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

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

RUN apt-get update

docker build -t aptupdate-20190417

और वास्तविक छवि में:

FROM aptupdate-20190417
FROM somebaseimage

COPY --from=aptupdate-20190417 /var/apt /var/apt

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

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

मेरा मतलब है, RUN --mount=type=cache इसके लिए बिल्कुल सही है।
या आप रजिस्ट्री से किसी अन्य छवि से भी माउंट कर सकते हैं और इसे प्राप्त किया जाएगा।

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

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

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

मैं जोरदार असहमत हूं। नेटवर्क डाउन या समझौता हो सकता है; जिस स्थिति में एक स्थानीय कैश इंटरनेट के डाउन होने पर पूरे निर्माण को विफल होने से रोकता है।

मैं अपने docker-compose.yml में एक बार volumes: निर्दिष्ट कर सकता हूं; लेकिन इसके बजाय DOCKER_BUILDKIT=1 करने की आवश्यकता है और Dockerfiles प्रबंधित अपस्ट्रीम में RUN --mount=type=cache जोड़ें? क्यों?

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

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

कृपया केवल --volume जोड़ें ताकि मेरा docker-compose.yml काम करे।

कृपया केवल --volume जोड़ें ताकि मेरा docker-compose.yml काम करे।

अपना "डॉकर-कंपोज़" बनाना बस काम पीछे की ओर है।
docker-compose उपभोक्ताओं को यह परियोजना, दूसरी तरफ नहीं।

docker-compose docker सॉकेट के साथ इंटरैक्ट करता है। docker-compose YAML कंटेनर विकल्पों को संग्रहीत करने का एक समेकित तरीका है (जिसे k8s pod defs में बदला जा सकता है (जो पॉडमैन एक हद तक समर्थन करता है))। मुझे प्रतिलिपि प्रस्तुत करने योग्य तरीके से DOCKER_BUILDKIT=1 कैसे निर्दिष्ट करना चाहिए? मैं एक docker-compose.yml में एक प्रतिलिपि प्रस्तुत करने योग्य तरीके से build_volumes: निर्दिष्ट कर सकता था।

जब मैं - मेरी सीआई बिल्ड स्क्रिप्ट में जो दिन में n बार चलती है - उदाहरण के लिए docker-compose build (जैसे ansible के साथ) या packer (बिल्डाह और पॉडमैन के बजाय) को कॉल करके एक छवि बनाएं, मैं कुछ उद्देश्य हैं:

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

अगर मुझे कैश वॉल्यूम फ्लश करने की ज़रूरत है, तो मैं कैश वॉल्यूम फ्लश कर सकता हूं।

0. यथास्थिति

RUN pip install app && rm -rf /root/.cache

• आज संभव है
• O(n_builds): बैंडविड्थ उपयोग
• ऑफलाइन काम नहीं करेगा: नेटवर्क पर निर्भर करता है
• धीमी पुनर्निर्माण

ए प्रतियां

COPY . /app/src/app
COPY .cache/pip /app/.cache/pip
RUN pip install /app/src/app \
    && rm -rf /app/.cache/pip

• आज संभव है
• ~ओ(1) पैकेज इंडेक्स बैंडविड्थ
• ओ (एन): प्रत्येक निर्माण पर (* ONBUILD )
  
  
  
  • कैश कॉपी करता है
  
  
  • अनारकली पैकेज
  
  
  • कैशे हटाता है
  
  
• ऑफ़लाइन काम करता है
• धीमी पुनर्निर्माण

B. RUN --mount=type=cache जोड़ने के लिए अपस्ट्रीम से प्रत्येक Dockerfile को फोर्क और संशोधित करें और एक पर्यावरण चर सेट करें

# Fork by copying to modify every pip install line
RUN --mount=type=cache /app/.cache/pip pip install /app/src/pip

$ DOCKER_BUILDKIT=1 docker build . [...]

• आज संभव है
• यह पहले से ही अनुत्पादकता का परिचय देता है: एक अतिरिक्त- Dockerfile, extra-docker-compose.yml पैरामीटर है जो आउटपुट में भिन्नता का परिचय देता है: नामित निर्मित छवि।
• डॉक्स: --mount=type=cache कैश फ्लश कैसे करें (?)
• ~ओ(1) पैकेज इंडेक्स बैंडविड्थ
• ऑफ़लाइन काम करता है
• तेजी से पुनर्निर्माण

सी. एक वॉल्यूम निर्दिष्ट करें जो बिल्ड समय पर माउंट हो जाता है

सी.1 बिल्डाह:

$ buildah bud -v .cache/pip:/app/.cache.pip

• आज संभव है
• साथ ही अनुत्पादकता का परिचय देता है
• डॉक्स: कैश को कैसे फ्लश करें
• ~ओ(1) पैकेज इंडेक्स बैंडविड्थ
• ऑफ़लाइन काम करता है
• तेजी से पुनर्निर्माण

सी.2. docker (यह समस्या क्या पूछ रही है)

C.2.1 डॉकर सीएलआई

$ docker build -v .cache/pip:/app/.cache.pip

• आज संभव नहीं है
• साथ ही अनुत्पादकता का परिचय देता है
• डॉक्स: कैश को कैसे फ्लश करें
• ~ओ(1) पैकेज इंडेक्स बैंडविड्थ
• ऑफलाइन काम करेगा
• तेजी से पुनर्निर्माण

C.2.2 डॉकर लिखें

services:
  app:
    image: imgname:latest
    build: .
    build_volumes:  # "build_volumes" ?
    - ./.cache/pip:/app/.cache/pip

$ docker-compose build

• आज संभव नहीं है
• साथ ही अनुत्पादकता का परिचय देता है
• डॉक्स: कैश को कैसे फ्लश करें
• डॉकर-लिखें स्कीमा संशोधन की आवश्यकता होगी
• ~ओ(1) पैकेज इंडेक्स बैंडविड्थ
• ऑफलाइन काम करेगा
• तेजी से पुनर्निर्माण

...

• कॉपी || REMOTE_FETCH || पढ़ना()
  
  
  
  • इनमें से कौन सबसे अधिक प्रतिलिपि प्रस्तुत करने योग्य हैं?
  
  

:point_up: बस एक रिमाइंडर। आप डाउनलोड की गई फ़ाइल का चेकसम चेक करके उसे पिन कर सकते हैं। कुछ पैकेज मैनेजर, जैसे कि पाइप, भी इसका समर्थन करते हैं।

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

मुझे लगता है कि निम्नलिखित आपके केस बी के समान होगा, लेकिन आप कैश को साफ़ कर सकते हैं और यह आपके केस सी 2 की तरह खत्म हो जाएगा (जो आप मांग रहे हैं, मुझे लगता है):

_docker-compose.yml:_

services:
  my-cache:
    build: ./my-cache
    image: local/my-cache

  my-image:
    build: ./my-image

_my-cache/डॉकरफाइल:_

FROM python

RUN pip install app

_माय-इमेज/डॉकरफाइल:_

FROM my-repo/my-image

RUN --mount=target=/export,type=bind,from=local/my-cache

RUN pip install /app/src/app

(https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache)

आप इसके साथ कैशे इमेज बना सकते हैं:

docker-compose build my-cache

आदेश RUN --mount=target=/export,type=bind,from=local/my-cache छवि से जुड़ना चाहिए। यदि आप कैश को रीफ्रेश करना चाहते हैं तो आप कैश छवि को हटा और पुनर्निर्माण कर सकते हैं।

यदि यह अभी भी RUN --mount... में कैश का उपयोग करता है तो आप एक संस्करण के साथ .env फ़ाइल का उपयोग कर सकते हैं, संस्करण को image: local/my-cache:$MY_VERSION और from=local/my-cache:$MY_VERSION में शामिल करें (यह होना चाहिए एक बिल्ड तर्क के रूप में शामिल)।

आप my-cache सेवा को किसी अन्य docker-compose फ़ाइल में शामिल कर सकते हैं यदि आप नहीं चाहते कि यह आपकी मुख्य सेवाओं के समान फ़ाइल में हो।

आपको अभी भी DOCKER_BUILDKIT=1 का उपयोग करने की आवश्यकता होगी (जैसे आपके बी मामले में, लेकिन मुझे लगता है कि यह भविष्य के संस्करणों में आवश्यक नहीं होगा) और यह अभी भी प्रतिलिपि प्रस्तुत करने योग्य नहीं होगा (लेकिन आपका सी 2 केस या तो नहीं है)।

यदि यह प्रतिलिपि प्रस्तुत करने योग्य नहीं है तो आप क्या दंड देखेंगे? यदि आप कैश इमेज local/my-cache को डॉक हब (एक अलग रेपो नाम के साथ) या एक निजी रजिस्ट्री में डालते हैं और प्रत्येक बिल्ड के लिए संस्करणों का उपयोग करते हैं (जो एक अलग कैश बनाएगा), एक ही संस्करण के साथ हमेशा समान होता है कैश, क्या यह इसे पुन: उत्पन्न नहीं करेगा? आपको docker-compose फ़ाइल में सेवा को शामिल करने और बिल्ड कमांड को कॉल करने की भी आवश्यकता नहीं होगी। (डॉकर हब को नेटवर्क से एक्सेस किया जाना चाहिए, लेकिन यह आपकी अन्य छवियों के लिए समान है, मुझे लगता है, और एक बार डाउनलोड करने के बाद, इसकी आवश्यकता नहीं होनी चाहिए, जब तक कि आप एक नए कैश के साथ एक नया संस्करण उत्पन्न नहीं करते हैं)

अस्वीकरण: मैंने उपरोक्त कोड का परीक्षण नहीं किया है।

@Yajo पाइप में चेकसम समर्थन मूल रूप से 'पीप' में लागू किया गया था और फिर पाइप में विलय कर दिया गया था। आप पाइप आवश्यकता फ़ाइल प्रविष्टियों में URL फ़्रैगमेंट के रूप में ज्ञात अच्छे हैश जोड़ सकते हैं। (इस साल PyPA प्रोजेक्ट में सुरक्षा सुधार के लिए फंडिंग है; TUF (द अपडेट फ्रेमवर्क; बिल्कुल डॉकर नोटरी की तरह) PyPI में सपोर्ट इस साल के अंत में करने की योजना है।) docker इमेज में pip और PyPI (की और ट्रस्ट के साथ) को सही ढंग से बूटस्ट्रैप करना संभवत: इस वर्ष के अंत में एक विषय होगा।
(संपादित करें; थोड़ा ओटी लेकिन संबंधित के लिए) https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/

@lucasbasquerotto आपकी मदद के लिए धन्यवाद। यह निर्माण समय पर केवल --volume निर्दिष्ट करने से कहीं अधिक जटिल है। अर्थात्, ऐसा लगता है कि इसकी आवश्यकता है:

• DOCKER_BUILDKIT=1 को docker build शेल एनवी में निर्दिष्ट करना
• RUN --mount=type=cache और args के साथ किसी भी/हर अपस्ट्रीम Dockerfile RUN निर्देश को संशोधित करना (संपादित करें)
• किसी अन्य छवि में पहुंच पढ़ें/लिखें? परिवर्तनशीलता! या कहा जाता है कि कैश शायद-बासी संस्करणों के साथ जमे हुए हैं?

अगर मैं होस्ट से फाइल कॉपी कर सकता हूं, या बिल्ड-टाइम पैरामीटर निर्दिष्ट कर सकता हूं जो कहीं और संग्रहीत नहीं हैं, तो मुझे नहीं लगता कि बिल्ड समय पर वॉल्यूम बढ़ाना कितना कम प्रतिलिपि प्रस्तुत करने योग्य है?

कॉपी || REMOTE_FETCH || पढ़ना()

• इनमें से कौन सबसे अधिक प्रतिलिपि प्रस्तुत करने योग्य हैं?

@वेस्टर्नर

डॉकटर बिल्ड शेल env में DOCKER_BUILDKIT=1 निर्दिष्ट करना

यदि आप docker-compose का उपयोग करते हैं, जैसा कि मैंने आपकी अन्य पोस्ट में देखा है, और यदि आप इसे किसी कंटेनर से चला रहे हैं, जैसे:

$ sudo curl -L --fail https://github.com/docker/compose/releases/download/1.24.0/run.sh -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

फिर आप उस env वैरिएबल का उपयोग करने के लिए डाउनलोड की गई फ़ाइल को /usr/local/bin/docker-compose में संपादित कर सकते हैं। से बदलें:

exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" $IMAGE "$@"

प्रति

DOCKER_BUILDKIT=1
exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" --env DOCKER_BUILDKIT=$DOCKER_BUILDKIT $IMAGE "$@"

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

_(यदि आप एक कंटेनर के रूप में नहीं चलते हैं, तो उपरोक्त लागू नहीं होता है)_

RUN --cache और args . के साथ किसी भी / हर अपस्ट्रीम Dockerfile RUN निर्देश को संशोधित करना

यदि मैंने खुलासा किया है, तो यह RUN --mount=type=bind... होगा, लेकिन किसी भी मामले में, Dockerfile को बदलना भी खराब आईएमओ है। एक -v विकल्प वास्तव में बहुत बेहतर और अधिक पारदर्शी होगा।

किसी अन्य छवि में पहुंच पढ़ें/लिखें? परिवर्तनशीलता! या कहा जाता है कि कैश शायद-बासी संस्करणों के साथ जमे हुए हैं?

जब आप छवि को बांधते हैं तो यह संभवतः एक कंटेनर (या जो भी नाम होगा, एक प्रतिकृति फाइल सिस्टम के साथ) बनाएगा, और निर्माण के दौरान वहां किए गए परिवर्तनों से मूल छवि नहीं बदलनी चाहिए (इसका कोई मतलब नहीं होगा)। इसलिए यदि आप किसी बिल्ड में my-repo/my-cache:my-version नाम की कैश इमेज का उपयोग करके निर्माण करते हैं, तो अगले बिल्ड में यह बिल्कुल वैसा ही (अपरिवर्तनीयता) होगा। यदि आप अधिक अप-टू-डेट कैश का उपयोग करना चाहते हैं, तो आप एक नए संस्करण के साथ एक नई छवि बना सकते हैं और इसका उपयोग कर सकते हैं, जैसे my-repo/my-cache:my-new-version ।

इनमें से कौन सबसे अधिक प्रतिलिपि प्रस्तुत करने योग्य हैं?

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

यदि COPY कमांड आपके मशीन कैश की प्रतिलिपि बना रहा है, तो मैं इसे प्रतिलिपि प्रस्तुत करने योग्य नहीं मानता क्योंकि यदि आप किसी अन्य मशीन में pip install (या apt-get , या जो भी) चलाते हैं, तो क्या आप गारंटी दे सकते हैं कैश की सामग्री वही होगी? शायद यह आपके लिए चिंता का विषय हो सकता है। शायद नहीं।

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

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

कुछ प्रकार का डॉकर नेटवर्किंग बग है जो एक कंटेनर के अंदर go mod download अविश्वसनीय बनाता है, (कम से कम हमारे आकार के अनुप्रयोगों के लिए), तो बस इसे हर बार मेरे सभी GOPATH/pkg/mod को फिर से डाउनलोड करने के लिए चलाना है न केवल बेकार, बल्कि टूटा हुआ। ‍

यदि मैं --volume !

@kevincantu RUN --mount=type=cache आपके उपयोग के मामले को कवर करना चाहिए

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

https://github.com/moby/moby/issues/14080#issuecomment -484314314 @westurner द्वारा एक बहुत अच्छा अवलोकन है लेकिन मुझे काम करने के लिए buildkit नहीं मिला:

$ sudo docker -v
Docker version 19.03.1, build 74b1e89

$ sudo DOCKER_BUILDKIT=1 docker build .
Ä+Ü Building 0.1s (2/2) FINISHED                                                                                                                
 => ÄinternalÜ load build definition from Dockerfile                                                                                       0.0s
 => => transferring dockerfile: 407B                                                                                                       0.0s
 => ÄinternalÜ load .dockerignore                                                                                                          0.0s
 => => transferring context: 2B                                                                                                            0.0s
failed to create LLB definition: Dockerfile parse error line 8: Unknown flag: mount

मेरा Dockerfile # syntax=docker/dockerfile:experimental से शुरू होता है।

मैं वास्तव में इसे docker-compose के माध्यम से उपयोग करना चाहता हूं। ENV DOCKER_BUILDKIT 1 में Dockerfile की कोशिश की और इसे docker-compose.yml से ARG DOCKER_BUILDKIT $ के माध्यम से भी पास कर दिया लेकिन यह वही है:

$ sudo docker-compose up --build
Building web
ERROR: Dockerfile parse error line 10: Unknown flag: mount

@lucasbasquerotto https://github.com/moby/moby/issues/14080#issuecomment -484639378 में आपने जो प्रस्तावित किया है, उसका अनुवाद डॉकर-कंपोज़ के स्थापित संस्करण में कैसे किया जाएगा?

अंत में, मुझे यह भी यकीन नहीं है कि यह मेरे उपयोग के मामले को कवर करेगा, शायद आप में से कुछ मुझे बता सकते हैं कि मुझे इसका पीछा करना चाहिए या नहीं। मैं स्थानीय विकास के लिए बिल्ड-टाइम कैश का उपयोग करना चाहता हूं जो बिल्ड के बीच जीवित रहता है ताकि निर्भरताओं को अद्यतन करने पर केवल नए लोगों को डाउनलोड करना पड़े। इसलिए मैं RUN --mount=type=cache,target=/deps को Dockerfile में जोड़ूंगा और निर्भरता प्रबंधक के कैशे को /deps पर सेट करूंगा।

डॉकर कंपोज़ के लिए https://github.com/docker/compose/pull/6865 देखें , जो कि कंपोज़ के आगामी रिलीज़ उम्मीदवार में होगा

मेरे पास एक और उपयोग का मामला है ... मैं कॉन्फ़िगर किए गए binfmt के साथ x86_64 होस्ट पर आर्म के लिए कंटेनर बनाना चाहता हूं। इसके लिए आवश्यक है कि मेरे पास /usr/bin में आर्किटेक्चर विशिष्ट स्थिर qemu cpu एमुलेटर हो।

मेरा वर्तमान समाधान कंटेनर में qemu-arm-static को फ़ाइल के रूप में जोड़ना है:

FROM arm32v7/alpine:3.10
COPY qemu-arm-static /usr/bin/qemu-arm-static
RUN apk update && apk upgrade
RUN apk add alpine-sdk cmake
...

आसान उपाय यह होगा कि मेरी फाइल को केवल तभी माउंट किया जाए जब कंटेनर के अंदर जरूरत हो:
docker build -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static -t test:arm32v7 .
यह डॉकर रन के लिए बहुत अच्छा काम करता है, लेकिन मुझे कंटेनर बनाने के लिए यह कार्यक्षमता याद आती है।

क्या कोई अन्य समाधान है कि मैं x86_64 होस्ट्स पर आर्म कंटेनर कैसे बना सकता हूं या क्या हम कम से कम इस मामले के लिए बिल्ड टाइम पर वॉल्यूम की अनुमति दे सकते हैं?

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

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

@aleha क्या आपको अभी भी कंटेनर के भीतर स्थिर क्यूमू एमुलेटर बाइनरी की आवश्यकता नहीं है?

@cybe अब इसकी आवश्यकता नहीं है, यदि F -flag का उपयोग किया जाता है (जो कि linuxkit/binfmt पैकेज करता है)। आप इसके बारे में अधिक जानकारी यहाँ पा सकते हैं।

क्या कोई बिल्डकिट को आजमाने के लिए एक कामकाजी सेटअप प्रदान कर सकता है? मैं इसे उबंटू पर काम नहीं कर सकता। मेरा सेटअप इस प्रकार है:

cat /etc/docker/daemon.json

{
  "experimental": true
}

Dockerfile

# syntax=docker/dockerfile:experimental

FROM ruby:2.6.3

RUN --mount=type=cache,target=/bundle/vendor

sudo docker -v

डॉकर संस्करण 19.03.1, बिल्ड 74b1e89

DOCKER_BUILDKIT=1 sudo docker build .

डेमॉन से त्रुटि प्रतिक्रिया: डॉकरफाइल पार्स त्रुटि पंक्ति 12: अज्ञात ध्वज: माउंट

sudo इसके साथ env vars नहीं ले जाता है जब तक कि आप इसे sudo -E के साथ नहीं बताते या सुडो के भीतर चर घोषित नहीं करते।

मैंने इस सुविधा के बारे में कुछ शब्द लिखे और कैश करने का तरीका दिखाते हुए कुछ न्यूनतम उदाहरण बनाए

• bundler निर्भरता docker का उपयोग कर
• NPM निर्भरता docker-compose का उपयोग कर

संपादित करें: नीचे देखें

@ cpuguy83 धन्यवाद!

@thisismydesign आपके उत्साह को बर्बाद करने के लिए खेद है, लेकिन आप --cache node_modules नहीं कर सकते, यह अंतिम छवि में मौजूद नहीं होगा, इसलिए आपका ऐप टूट गया है।

@glensc अरे तुम सही हो .. क्या अंतिम छवि का बिल्ड-टाइम कैश हिस्सा बनाने का कोई तरीका है?

ईमानदारी से, मैंने सोचा था कि इसे विज्ञापित सुविधा के लिए माना जाएगा

बिल्ड कंटेनर को कंपाइलर और पैकेज मैनेजर के लिए निर्देशिका कैश करने की अनुमति देता है।

आपको इसके बजाय ~/.npm मैप करने में सक्षम होना चाहिए… https://docs.npmjs.com/files/folders.html#cache

@यह मेरी डिजाईन है

आप किसी अन्य छवि को कैश के रूप में उपयोग कर सकते हैं, हालांकि, या तो इसे अपने Dockerfile में बनाकर या किसी रजिस्ट्री में संग्रहीत एक शाब्दिक छवि और COPY --from का उपयोग करें

FROM example/my_node_modules:latest AS node_modules

FROM nodejs AS build
COPY --from=/node_modules node_modules 
...

यह सिर्फ एक उदाहरण है जिसका उपयोग आप कई अलग-अलग चीजों के लिए कर सकते हैं।

उह मुझे इसे लाने और यहां शामिल होने से नफरत है (हाय दोस्तों भी)

लेकिन हमारे पास इसके लिए उपयोग का मामला है।

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

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

TLDR क्या मैं इसे कृपया कोड कर सकता हूँ? क्या कोई है जिससे मैं इस बारे में बात कर सकता हूं?

_TLDR_ क्या मैं इसे कृपया कोड कर सकता हूं? क्या कोई है जिससे मैं इस बारे में बात कर सकता हूं?

मैं डॉकर के लिए बात नहीं कर सकता, लेकिन मेरी धारणा यह है कि वे बिल्ड में वॉल्यूम माउंटिंग जोड़ने के लिए खुले नहीं हैं (और उन्हें शायद इस मुद्दे को बंद कर देना चाहिए)

बिल्डटाइम -v के लिए बहुत सारे उपयोग के मामले अब बिल्डकिट द्वारा कवर किए गए हैं। इसने कम से कम मेरे लिए इसे हल कर लिया है।

मैं बिल्डकिट की जांच करूंगा - मेरे पास कुछ हैकी बैश भी है जो किसी को दिलचस्पी लेने पर काम पूरा कर लेता है।

धन्यवाद @unilynx

+1 से @unilynx इस मुद्दे को बंद करने पर, बिल्डकिट ने मेरे लिए बिल्ड टाइम वॉल्यूम के मुद्दों को भी हल किया।

मैं शर्त लगाता हूं कि अगर किसी ने कुछ लिंक छोड़े और एक उदाहरण हम अपने दोस्तों को चमकदार क्लोज बटन दबाने के लिए मना सकते हैं।

(मुझे भी उनसे लाभ होगा)

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

इसलिए मैं अपने सभी निर्माण कलाकृतियों को build समय पर उपयोग किए जाने वाले अस्थायी वॉल्यूम से बाहर निकालने में सक्षम था और ऊपर बताए गए इस बैश का उपयोग करके पिछले कैश के साथ छवि को फिर से संगठित करता हूं।

मैं अपनी छवि को खुद के ऊपर पुनर्निर्माण करने में सक्षम था जैसे कि ओवरले फाइल सिस्टम ने केवल एक छोटा डेल्टा पकड़ा।

मैं निर्माण समय पर अन्य छवियों के लिए वॉल्यूम का पुन: उपयोग करने में भी सक्षम था।

क्या अन्य लोग ऐसा करने में सक्षम नहीं हैं?

(कैश) माउंट "प्रयोगात्मक" फ़्रंट-एंड में हैं; https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md में वर्णित (एक बैठक में जाने के बारे में, लेकिन मैं अधिक विस्तारित उदाहरणों को लिंक कर सकता हूं)

धन्यवाद @thaJeztah LMK अगर मैं यहाँ किसी भी तरह से मदद कर सकता हूँ :)

https://github.com/moby/moby/issues/14080#issuecomment -547662701

@thisismydesign आपके उत्साह को बर्बाद करने के लिए खेद है, लेकिन आप --cache node_modules नहीं कर सकते, यह अंतिम छवि में मौजूद नहीं होगा, इसलिए आपका ऐप टूट गया है।

@thaJeztah मुझे विश्वास नहीं है कि उपरोक्त समस्या हल हो गई है। कुछ उदाहरणों पर एक नज़र डालना पसंद करेंगे जहाँ कैश करना संभव है जैसे npm install निर्माण समय के दौरान जो परिणामी छवि को कैश्ड इंस्टॉलेशन का उपयोग करने की अनुमति देगा।

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

@thaJeztah कैश माउंट का उपयोग करते हुए कुछ उदाहरण यहां दिए गए हैं जो दिखाते हैं कि अंतिम छवि में माउंट कैसे नहीं होगा और इसमें बिल्ड-टाइम कैशिंग के कई उपयोग मामलों को शामिल नहीं किया गया है:

• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-build-cache
• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-compose-build-cache

एनपीएम के लिए: क्या कोई एनपीएम कैश निर्देशिका के लिए कैश माउंट का उपयोग नहीं करेगा (देखें https://docs.npmjs.com/cli-commands/cache.html, आमतौर पर ~/.npm )?

@ankon यह काम कर सकता है, धन्यवाद, मैं इसे आज़मा दूंगा। एक और उपयोग मामला मुझे यकीन नहीं है कि बंडलर और रूबी है।

इसलिए मुझे लगता है (अभी तक परीक्षण नहीं किया गया है) बंडलर के लिए आप कम से कम $BUNDLE_PATH पर बिल्ड वॉल्यूम का उपयोग करके और फिर निर्माण के दौरान नेटवर्क निर्भरता से छुटकारा पा सकते हैं

bundle install
bundle package
bundle install --standalone --local

इसका मूल रूप से मतलब है कि आपके पास कैश्ड बंडल इंस्टॉल निर्देशिका है, वहां से आप रत्नों को ./vendor/cache में पैकेज करते हैं और ./bundle में पुनः इंस्टॉल करते हैं। लेकिन यह रत्नों को स्थापित करने और बनाने में समय नहीं लगाता है, यह वास्तव में बिल्ड चरण को लंबा कर सकता है।

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

धन्यवाद, हालांकि, यह अभी भी एक कामकाज है क्योंकि

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

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

@thisismydesign ऐसा लगता है कि आप जो चाहते हैं वह बिल्ड और रन के बीच कैश साझा करने में सक्षम होना है?

बिल्डकिट केवल एक लिनक्स समाधान है, हम विंडोज़ पर क्या करते हैं?

@thisismydesign मुझे यकीन नहीं है कि आप अंतिम छवि में रहने के लिए (कैश) माउंट की अपेक्षा क्यों करते हैं। मुझे इसकी उम्मीद नहीं थी और मैं सिर्फ डाउनलोड कैश माउंट का उपयोग करने के कारण अपनी छवि में ~ 1 जीबी नहीं रखना चाहता।

बिल्डकिट केवल एक लिनक्स समाधान है, हम विंडोज़ पर क्या करते हैं?

आप विंडोज़ पर बिल्डकिट का उपयोग कर सकते हैं।

https://docs.docker.com/develop/develop-images/build_enhancements/

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

आपके लिंक के शीर्ष पर @nigelgbanks :

Only supported for building Linux containers

ओह क्षमा करें, मुझे लगता है कि आप विंडोज़ पर लिनक्स कंटेनर बना रहे थे।

@thisismydesign ऐसा लगता है कि आप जो चाहते हैं वह बिल्ड और रन के बीच कैश साझा करने में सक्षम होना है?

यह कैशिंग के आसपास मेरे उपयोग के मामले को हल करेगा, हां।

इसे आसान बनाने से CI में पैकेजों के लाखों पुन: डाउनलोड को बचाया जा सकता है
प्रति वर्ष बनाता है।

क्या कोई सीआई सेवाएं प्रयोगात्मक बिल्डकिट सुविधाओं का समर्थन करती हैं?

शनिवार, 13 जून, 2020, दोपहर 2:08 बजे Csaba Apagyi [email protected] ने लिखा:

@thisismydesign https://github.com/thisismydesign ऐसा लगता है क्या
आप बिल्ड और रन के बीच कैश साझा करने में सक्षम होना चाहते हैं?

यह कैशिंग के आसपास मेरे उपयोग के मामले को हल करेगा, हां।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/14080#issuecomment-643657987 , या
सदस्यता समाप्त
https://github.com/notifications/unsubscribe-auth/AAAMNS6IEQDCO5F3LNHJK5TRWO6AJANCNFSM4BJB2OOA
.

क्या कोई सीआई सेवाएं प्रयोगात्मक बिल्डकिट सुविधाओं का समर्थन करती हैं?

क्या उन्हें स्पष्ट रूप से इसका समर्थन करना है? मैं बिल्डकिट के साथ गिटलैब-सीआई का उपयोग कर रहा हूं और यह सिर्फ काम करता है। आखिरकार, यह 'डॉकर बिल्ड' को लागू करने का एक अलग तरीका है।

बेशक, जब तक आप अपने स्वयं के धावकों को गिटलैब में नहीं लाते हैं, तब तक बिल्ड के दौरान कैश हिट होने की संभावना कम होती है।

मल्टी-स्टेज बिल्ड के नामित चरण से कॉपी करना एक और समाधान है

FROM golang:1.7.3 AS builder
COPY --from=builder

लेकिन फिर सीआई जॉब शेड्यूलिंग के लिए कंटेनर इमेज लोकैलिटी अभी भी एक अनसुलझी समस्या है

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

मैंने अभी-अभी buildkit की कोशिश की है, लेकिन यह केवल मेरे वर्कफ़्लो में मामूली सुधार करता है, जो कि "वास्तविक" वॉल्यूम या होस्ट को बाइंड माउंट द्वारा 100% मदद करेगा।

मैं पुराने glibc संस्करणों को क्रॉस-कंपाइल करने के लिए docker build का उपयोग कर रहा हूं, जो तब नए बिल्ड कंटेनरों का हिस्सा होना चाहिए जो इन glibc s को अंडर और लिंक बनाने के लिए प्रदान करते हैं।

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

साथ ही, मैं यह देखने में असफल रहा कि मुझे अपने बिल्ड डीआईआर से छुटकारा पाने के लिए पुराने से एक नया कंटेनर बनाने जैसे हुप्स के माध्यम से क्यों कूदना चाहिए, जहां बिल्ड डीआईआर पहले स्थान पर एक माउंट होता, तो यह होता इतना आसान। (बिल्ड के बाद बस make install करें और मेरे पास बिना बिल्ड डीआईआर और डाउनलोड किए गए स्रोतों के बिना एक साफ कंटेनर है)।

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

लेकिन असफल निर्माण के बाद विश्लेषण के लिए बिल्ड डीआईआर तक पहुंचने का मेरे पास कोई तरीका नहीं है

बिल्डकिट के लिए फीचर अनुरोध की तरह लगता है। यह निश्चित रूप से एक ज्ञात लापता टुकड़ा है।

"बिल्ड डीआईआर" लाने का लक्ष्य बनाकर आज कोई ऐसा कर सकता है। आप बस यह चलाएंगे कि एक असफल रन के बाद, सब कुछ अभी भी कैश किया जाना चाहिए, डेटा को हथियाने के लिए बस अंतिम चरण की आवश्यकता है।
समझें कि यह एक कामकाज का थोड़ा सा है, हालांकि।

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

क्या आप यहां जो चाहते हैं/उम्मीद कर रहे हैं उसे और समझा सकते हैं?

क्या आप यहां जो चाहते हैं/उम्मीद कर रहे हैं उसे और समझा सकते हैं?

इस मामले में यह सिर्फ 2 पक्षियों को 1 पत्थर से मारना चाहता है:

• मेजबान से मध्यवर्ती परिणामों तक पहुंचने का एक आसान तरीका है (यहां "डीआईआर विश्लेषण बनाएं")
• सुनिश्चित करें कि यह संग्रहण स्थान नवनिर्मित छवि को प्रदूषित नहीं कर रहा है

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

क्या आप यहां जो चाहते हैं/उम्मीद कर रहे हैं उसे और समझा सकते हैं?

मैं एक बहु-चरण निर्माण प्रक्रिया का उपयोग कर रहा हूं, जहां निर्माण पर्यावरण स्वयं कंटेनरीकृत है, और अंतिम परिणाम एक छवि है जिसमें केवल एप्लिकेशन और रनटाइम पर्यावरण (बिना निर्माण उपकरण के) होता है।

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

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

यह कहने में कोई अपराध नहीं है कि कोई अन्य उपकरण आपकी आवश्यकताओं के अनुरूप बेहतर है।

अगर कुछ आपके लिए काम करता है, तो यह बहुत अच्छा है।

डॉकर और बिल्डकिट बिल्डर दोनों में v1 बिल्डर की कमियों को इस संदर्भ में बहुत अच्छी तरह से समझा जाता है, और यह देख रहे हैं कि क्लाइंट से बाइंड माउंट का सहारा लिए बिना, उन्हें कैसे संबोधित किया जाए।
GitHub सूचनाएं @github.com ने लिखा:
"@mcattle
वास्तव में बहुत समान (कार्यक्षमताओं में से एक) मुझे चाहिए।
कुछ दिनों पहले बिल्डह में जाने के बाद से मुझे वह हर फंक्शन मिला जिसकी मुझे जरूरत थी और भी बहुत कुछ। मेरे बिल्ड कंटेनर को डिबग करना पूरी तरह से असंभव होता, बिना लचीले ढंग से बाहर निकलने वाले कंटेनर और होस्ट के लिंक में प्रवेश करने की संभावना के बिना। अब मैं एक खुश टूरिस्ट हूं। (मुझे "प्रतियोगी" के साथ पार्टी को क्रैश करने के लिए खेद है, अगर अपराध किया जाता है तो मैं खुशी से इस टिप्पणी को हटा दूंगा, लेकिन यह इस धागे में प्रस्तुत उपयोग के मामलों के लिए इतना प्रभावी समाधान था कि मैंने सोचा कि मुझे इसका उल्लेख करना चाहिए) ।"

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

क्लाइंट से बाइंड माउंट का सहारा लिए बिना।

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

https://github.com/moby/moby/issues/14080#issuecomment -484314314 :

कॉपी || REMOTE_FETCH || पढ़ना()

• इनमें से कौन सबसे अधिक प्रतिलिपि प्रस्तुत करने योग्य हैं?

मैं बिल्डह के साथ बिल्ड टाइम -v (और cgroupsv2) के लिए भी जा रहा हूं।

@mcattle मुझे एक ही आवश्यकता है। मैंने इसे लेबलिंग के साथ हल किया।

मैं बिल्डह के साथ बिल्ड टाइम -v (और cgroupsv2) के लिए भी जा रहा हूं।

मैं "-v" समर्थन के कारण हमारे बिल्ड सर्वर पर उबंटू (जिसमें सिर्फ डॉकटर है) से फेडोरा (जो पॉडमैन/बिल्डाह के साथ डॉक को बदल दिया है) पर स्विच करने पर गंभीरता से विचार कर रहा हूं।

बीटीडब्ल्यू। पॉडमैन रूटलेस मोड का भी समर्थन करता है, और अब तक यह पूरी तरह से डॉकर संगत लग रहा है (--user/USER प्रभाव और छवि कैशिंग में अंतर को छोड़कर, जो रूटलेस मोड का उपयोग करने से आता है, जैसे कि डॉकर डेमन करता है)।

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

संपादित करें: उबंटू में ग्रोवी में पॉडमैन/बिल्डह/आदि है, बस नवीनतम 20.04 एलटीएस में नहीं, मुझे लगता है कि डेबियन अस्थिर से आयात किया गया है। इसे एलटीएस में बैकपोर्ट नहीं किया गया है, कम से कम अभी तक तो नहीं। जबकि मुझे लगता है कि यह 2018 से फेडोरा में है।

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