डॉकर इमेज रिडक्शन तकनीक

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



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

डॉकर छवि परतें

डॉकर कंटेनर की एक छवि अनिवार्य रूप से कई परतों में एक दूसरे के ऊपर खड़ी फाइलों का एक संग्रह है। एक काम करने वाले कंटेनर को इन फाइलों से इकट्ठा किया जाता है। डॉकर यूनियनएफएस फाइल सिस्टम का उपयोग करता है, जिसमें फाइलों को परतों में बांटा जाता है। एक परत में एक फ़ाइल या कई फाइलें हो सकती हैं, परतें एक-दूसरे को ओवरलैप करती हैं। कंटेनर के निष्पादन के दौरान, परतों की सामग्री संयुक्त होती है, जिसके परिणामस्वरूप कंटेनर का अंतिम उपयोगकर्ता एकल फ़ाइल सिस्टम के रूप में परतों में "रखी" सामग्री को मानता है।


सरलीकृत UnionFS देखें

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


रनिंग कंटेनर में रीड-ओनली लेयर के ऊपर स्थित रीड-राइट लेयर होता है

यदि कंटेनर को Layer 4 परत में नष्ट कर दिया जाता है तो योजनाबद्ध रूप से ऊपर प्रस्तुत किया गया है? यद्यपि यह फ़ाइल उस फ़ाइल सिस्टम में उपलब्ध नहीं होगी जिसे उपयोगकर्ता देखता है, वास्तव में, इस फ़ाइल का आकार अभी भी कंटेनर आकार के घटकों में से एक होगा, क्योंकि यह फ़ाइल केवल-पढ़ने वाली परतों में से एक में रहेगी।

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

उन सामग्रियों पर आधारित फ़ोल्डर पर पथ पर ध्यान दें, जिनमें छवियां एकत्र की जाती हैं

डॉकर छवियों को इकट्ठा करने का सबसे आम तरीका क्या है? जाहिरा तौर पर - इस तरह:

 docker build . 

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

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

एक ऐसी जगह की कल्पना करें जहां एक Dockerfile आमतौर पर रखा जाता है। यह शायद परियोजना की जड़ निर्देशिका है? यदि परियोजना की जड़ में एक Dockerfile , जिसका उपयोग छवि बनाने के लिए Dockerfile द्वारा docker build का उपयोग किया जाता है, तो यह पता चलता है कि परियोजना की सभी फाइलें छवि में मिल सकती हैं। यह इस तथ्य को जन्म दे सकता है कि हजारों जंक फाइल कई मेगाबाइट आकार में छवि विधानसभा के संदर्भ में प्राप्त कर सकते हैं। यदि आप Dockerfile में ADD और COPY कमांड का हल्के से उपयोग करते हैं, तो प्रोजेक्ट की सभी फाइलें अच्छी तरह से तैयार छवि का हिस्सा बन सकती हैं। सबसे अधिक बार, जो लोग छवियों को इकट्ठा करते हैं, उन्हें इसकी आवश्यकता नहीं होती है, क्योंकि अंतिम छवि में आमतौर पर केवल कुछ चयनित फाइलें शामिल होनी चाहिए।

हमेशा यह सुनिश्चित करें कि docker build कमांड docker build सही रास्ता मिले, और यह कि Dockerfile में कोई कमांड नहीं हैं जो इमेज में अनावश्यक फाइलों को जोड़ते हैं। यदि किसी कारण से आपको प्रोजेक्ट को रूट संदर्भ बनाने की आवश्यकता है, तो आप चुनिंदा फ़ाइलों को इसमें शामिल कर सकते हैं और उन्हें .dockerignore का उपयोग करके इसे बाहर कर .dockerignore ।

छवि परतों का अनुकूलन करें

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

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

 FROM alpine RUN wget http://xcal1.vodafone.co.uk/10MB.zip -P /tmp RUN rm /tmp/10MB.zip 

आइए छवि को इकट्ठा करें:


एक प्रयोगात्मक छवि की विधानसभा जिसमें तर्कहीन रूप से उपयोग की जाने वाली जगह है

गोता का उपयोग कर छवि का अन्वेषण करें:


छवि प्रदर्शन संकेतक 34% है

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

इस समस्या से कैसे छुटकारा पाएं? आइए कई विकल्पों पर विचार करें।

Ging मर्जिंग टीम काम के परिणाम

क्या आपने कभी Dockerfile को बहुत लंबे RUN निर्देशों से युक्त देखा है जिसमें कई शेल कमांड संयुक्त && का उपयोग कर रहे हैं? यह टीमों के परिणामों का विलय है।

इस पद्धति का उपयोग करके, हम एक ही लंबी टीम के परिणामों के आधार पर, केवल एक परत बनाते हैं। चूंकि निम्न परतों में हटाई गई फ़ाइलों वाली छवि में कोई परत नहीं होगी, इसलिए अंतिम छवि में ऐसी "भूत फ़ाइलें" शामिल नहीं होंगी। इस उदाहरण पर विचार करें, उपरोक्त Dockerfile को इस स्थिति में लाया गया है:

 FROM alpine RUN wget http://xcal1.vodafone.co.uk/10MB.zip -P /tmp && rm /tmp/10MB.zip 

उसके बाद, हम छवि का विश्लेषण करते हैं:


मर्जिंग टीमों ने आपको एक ऐसी छवि बनाने की अनुमति दी है जो 100% अनुकूलित है

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

Qu- theququash विकल्प चुनना

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

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

 docker build --squash . 

परिणामी छवि भी 100% अनुकूलित निकली:


असेंबली के दौरान --squash विकल्प का उपयोग करके एक ऐसी छवि बनाने की अनुमति दी गई जो 100% अनुकूलित थी

यहां आप एक दिलचस्प विवरण पर ध्यान दे सकते हैं। अर्थात्, Dockerfile में एक फ़ाइल को जोड़ने के लिए एक परत बनाई गई थी और इस फ़ाइल को हटाने के लिए एक और परत बनाई गई थी। --squash विकल्प यह समझने के लिए पर्याप्त बुद्धिमान है कि इस परिदृश्य में आपको अतिरिक्त परतें बनाने की आवश्यकता नहीं है (अंतिम छवि में केवल 9ccd9… परत है 9ccd9… हम जिस आधार छवि का उपयोग करते हैं)। सामान्य तौर पर, इसके लिए हम अतिरिक्त प्लस लगा सकते हैं। सच है, --squash का उपयोग करते --squash , आपको यह विचार करने की आवश्यकता है कि यह कैश्ड परतों के उपयोग में हस्तक्षेप कर सकता है।

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

कैश और अस्थायी फ़ाइलों को हटाएँ

अनुप्रयोगों को कंटेनरीकृत करते समय, एक स्थिति अक्सर उत्पन्न होती है जब आपको उनके साथ छवि में अतिरिक्त उपकरण, पुस्तकालय, उपयोगिताओं को रखने की आवश्यकता होती है। यह apk , yum , yum जैसे पैकेज प्रबंधकों का उपयोग करके किया जाता है।

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

तीन पूर्वोक्त लोकप्रिय पैकेज प्रबंधकों द्वारा बनाए गए कैश को निकालने के लिए, एक एकत्रित कमांड के अंत में (यानी, जो एक परत बनाने के लिए चलता है), आप निम्नलिखित जोड़ सकते हैं:

 APK: ... && rm -rf /etc/apk/cache YUM: ... && rm -rf /var/cache/yum APT: ... && rm -rf /var/cache/apt 

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

अपनी आधार छवि को ध्यान से चुनें

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

इसके बारे में डॉक्यूमेंट डॉक्यूमेंट क्या कहता है: “ FROM इंस्ट्रक्शन एक नए बिल्ड फेज को इनिशियलाइज़ करता है और जो फॉलो करता है उसके लिए बेस इमेज सेट करता है। नतीजतन, एक उचित रूप से रचित Dockerfile को FROM कथन FROM शुरू करना चाहिए। एक छवि किसी भी व्यावहारिक छवि हो सकती है। सार्वजनिक रिपॉजिटरी से एक छवि के रूप में अपनी खुद की छवि को इकट्ठा करना शुरू करना सबसे आसान है। "

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

जैसा कि आप उम्मीद कर सकते हैं, लोकप्रिय आधार छवियों के आकार में काफी भिन्नता है:


लोकप्रिय बुनियादी डोकर छवियों के आकार

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

यहां आप निम्नलिखित (पूरी तरह से तार्किक) निष्कर्ष पर आ सकते हैं: "तो - मैं हमेशा अल्पाइन का उपयोग करूंगा!"। लेकिन, दुर्भाग्य से, सॉफ्टवेयर विकास की दुनिया में, सब कुछ इतना सरल नहीं है।

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

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

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

एक ऐसी छवि बनाने पर विचार करें जिसमें एक मूल छवि नहीं है।

यदि आपका एप्लिकेशन मूल तरीके से प्रदान किए गए कुछ अतिरिक्त वातावरण के बिना चल सकता है, तो आप एक मूल छवि का उपयोग नहीं करने का निर्णय ले सकते हैं। बेशक, चूंकि Dockerfile में FROM निर्देश मौजूद होने चाहिए, आप इसके बिना नहीं कर सकते। इसके अलावा, उसे किसी प्रकार की छवि को इंगित करना चाहिए। ऐसी स्थिति में क्या छवि का उपयोग करें?

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

नतीजतन, यदि आपका आवेदन एक स्व-निहित निष्पादन योग्य है जो अपने आप पर काम कर सकता है, तो आधार scratch छवि को चुनने से आप कंटेनर के आकार को कम कर सकेंगे।

मल्टी-स्टेज बिल्ड का उपयोग करें

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

सामान्य शब्दों में, एक मल्टी-स्टेज असेंबली को कई Dockerfile संयोजन के रूप में, या Dockerfile के रूप में सोचा जा सकता है, जिसमें कई FROM निर्देश हैं।

मल्टी-स्टेज असेंबली के उद्भव से पहले, यदि आपको अपनी परियोजना की एक असेंबली बनानी थी और इसे Dockerfile का उपयोग करके एक कंटेनर में वितरित करना था, तो आपको संभवतः असेंबली प्रक्रिया करने की आवश्यकता होगी, जो कंटेनर की उपस्थिति की ओर ले जाएगी, जैसा कि नीचे दिखाया गया है:


मल्टी-स्टेज बिल्ड तकनीक का उपयोग किए बिना किसी एप्लिकेशन का निर्माण और वितरण करें

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

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


बहु-चरण विधानसभा, निष्पादन पर्यावरण से परियोजना सामग्री बनाने और तैयार करने की प्रक्रिया को अलग करना

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

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

परिणाम

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

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

PS हमने बाजार को RUVDS की वेबसाइट पर लॉन्च किया। बाज़ार में, डॉकर छवि एक क्लिक में स्थापित की जाती है, आप यह जांच सकते हैं कि कंटेनर VPS पर कैसे काम करते हैं, सभी नए ग्राहकों के लिए परीक्षण के लिए 3 दिन नि: शुल्क प्रदान किए जाते हैं।

प्रिय पाठकों! आप अपने डॉकर चित्रों के आकार को कैसे अनुकूलित करते हैं?