बड़े कंटेनर इमेज के कारण परिनियोजन धीमा हो जाता है, रजिस्ट्री स्टोरेज का व्यय बढ़ता है और सुरक्षा जोखिम (अटैक सरफेस) में वृद्धि होती है। यदि आपकी उत्पादन इमेज में अब भी कंपाइलर, परीक्षण टूल और बिल्ड टूलिंग शामिल हैं, तो आप अनावश्यक भार बढ़ा रहे हैं।
मल्टी-स्टेज बिल्ड पैकेजिंग से जुड़ी इस समस्या का समाधान करते हैं। पहले एक निर्माण चरण (बिल्डर स्टेज) में निर्माण करें, फिर केवल रनटाइम आर्टिफैक्ट को एक छोटी अंतिम इमेज में कॉपी करें।
मैंने इस प्रक्रिया को दो अन्य विकल्पों (सिंगल-स्टेज और प्री-बिल्ट बेस) की तुलना में चार अलग-अलग प्रौद्योगिकियों पर मापा है। संपूर्ण परीक्षण कोड, डॉकरफाइल्स और मूल आंकड़े यहां उपलब्ध हैं:
- गिटहब रिपॉजिटरी: [मल्टी-स्टेज डॉकर बेंचमार्किंग](P३१)
समस्या: अत्यधिक भारी इमेज
एक सामान्य गो एप्लिकेशन को निर्माण के समय कंपाइलर, मॉड्यूल कैश और सिस्टम टूल की आवश्यकता होती है। एक सामान्य सिंगल-स्टेज डॉकरफाइल अंतिम इमेज में यह सब कुछ छोड़ देता है:
P०
लेकिन निष्पादन (रनटाइम) के समय केवल बाइनरी फ़ाइल की आवश्यकता होती है। नोड, जावा और पायथन में भी यही पैटर्न दिखाई देता है: निर्माण समाप्त होने के बाद भी पूरी एसडीके तकनीक इमेज में बनी रहती है।
तीन निर्माण रणनीतियाँ
परीक्षण में प्रत्येक भाषा के एक छोटे P८ एचटीटीपी सेवा पर तीन पैकेजिंग रणनीतियों की तुलना की गई है:
१. सिंगल-स्टेज: एक ही इमेज इंस्टॉल, बिल्ड और रन का कार्य करती है। २. प्री-बिल्ट बेस: निर्भरताएँ एक कस्टम बेस में रहती हैं। एप्लिकेशन बिल्ड इसके ऊपर स्रोत कोड कॉपी करता है। अंतिम इमेज भारी बनी रहती है। ३. मल्टी-स्टेज: बिल्डर में एसडीके रहता है; अंतिम चरण में केवल आवश्यक आर्टिफैक्ट (बाइनरी, P९, जार फ़ाइल या वातावरण का आवश्यक भाग) जाता है।
प्रत्येक डॉकरफाइल में लेयर क्रम निश्चित है (मैनिफेस्ट → निर्भरताएँ → स्रोत → बिल्ड), ताकि निष्पक्ष तुलना रणनीतियों की हो सके।
परीक्षण के परिणाम
अंतिम परीक्षण आंकड़े: २१ जुलाई २०२६, P१० द्वारा प्राप्त अनकंप्रेस्ड आकार।
इमेज का आकार (मल्टी-स्टेज की जीत)
| स्टैक | सिंगल-स्टेज | प्री-बिल्ट | मल्टी-स्टेज | सिंगल के मुकाबले गिरावट |
|---|---|---|---|---|
| गो | ६९.२ एमबी | ६९.२ एमबी | ५.४ एमबी | ~९२% |
| नोड.जेएस (टाइपस्क्रिप्ट) | ६४.३ एमबी | ६४.३ एमबी | ४७.४ एमबी | ~२६% |
| जावा (फैट जार) | २३१.७ एमबी | २३१.७ एमबी | ६९.९ एमबी | ~७०% |
| पायथन (कॉन्डा) | ३५५.१ एमबी | ३५५.१ एमबी | ८५.७ एमबी | ~७६% |
इन एप्लिकेशन्स पर मल्टी-स्टेज तकनीक ने अंतिम आकार में २६% से ९२% तक की कमी की। प्री-बिल्ट का आकार सिंगल-स्टेज जितना ही रहता है क्योंकि उसमें संपूर्ण टूलचेन शामिल होती है।
गो में सबसे बड़ा अंतर दिखा: अल्पाइन अथवा P११ जैसे न्यूनतम रनर पर केवल स्टेटिक बाइनरी रखने से बाकी सब हट जाता है। नोड में कमी थोड़ी कम होती है क्योंकि उत्पादन में नोड रनटाइम और P१२ की आवश्यकता बनी रहती है।
पुनर्निर्माण गति (केवल कोड बदलने पर प्री-बिल्ट की गति)
जब केवल एप्लिकेशन स्रोत कोड बदलता है:
| स्टैक | सिंगल (सेकंड) | प्री-बिल्ट (सेकंड) | मल्टी-स्टेज (सेकंड) |
|---|---|---|---|
| गो | १.०५ | ०.६८ | १.२२ |
| नोड | १.५५ | १.०९ | २.०८ |
| जावा | २.२६ | १.५० | १.९२ |
| पायथन (कॉन्डा) | १.२५ | ०.३१ | ०.९८ |
प्री-बिल्ट विधि कोड में बदलाव के पुनर्निर्माण पर सबसे तेज़ रही क्योंकि निर्भरताएँ बेस में पहले से मौजूद रहती हैं।
व्यावहारिक निष्कर्ष
- उत्पादन आकार और सुरक्षा जोखिम कम करने के लिए मल्टी-स्टेज का उपयोग करें।
- जब केवल कोड संशोधन की पुनर्निर्माण गति प्राथमिकता हो (विकास पर्यावरण या कुछ सीआई पथ), तब प्री-बिल्ट बेस का उपयोग करें।
- सिंगल-स्टेज केवल एक सामान्य आधार रेखा प्रदान करता है।
परीक्षण दोहराने के लिए:
P१
मल्टी-स्टेज डॉकरफाइल्स के उदाहरण
गो
P२
मुख्य बिंदु:
- P१३ को P१४ से अलग रखा गया है ताकि स्रोत कोड बदलने पर निर्भरताएँ पुनः डाउनलोड न हों।
- P१५ डिबग प्रतीकों को हटाता है।
- P१६ न्यूनतम इमेज में एचटीटीपीएस समर्थन बनाए रखता है।
नोड.जेएस / टाइपस्क्रिप्ट
नोड को उत्पादन रनटाइम की आवश्यकता रहती है; मल्टी-स्टेज डेव-निर्भरताएँ और अनपेक्षित फ़ाइलों को हटाकर सहायता करता है:
P३
P१७ फ़ाइल का उपयोग
मल्टी-स्टेज यह निर्धारित करता है कि अंतिम इमेज में क्या जाएगा, जबकि P१८ यह तय करता है कि डॉकर डेमन को क्या नहीं भेजा जाना चाहिए। इसके बिना डॉकर P१९, स्थानीय P२० और वातावरण फ़ाइलों को अपलोड कर सकता है।
P४
सुरक्षा सुदृढ़ीकरण
केवल छोटा आकार ही सब कुछ नहीं है, सुरक्षा भी महत्वपूर्ण है।
अ-रूट उपयोगकर्ता से चलाएँ
P५
P२१ अथवा डिस्ट्रोलेस का उपयोग
स्टेटिक बाइनरी के लिए:
P६
| बेस इमेज | आकार | शेल | पैकेज प्रबंधक | उपयोग का सर्वोत्तम समय |
|---|---|---|---|---|
| P२२ | ~७ एमबी | ✅ | ✅ (P२३) | सामान्य उपयोग, डिबगिंग |
| P२४ | ~२ एमबी | ❌ | ❌ | उत्पादन गो, रस्ट, सी++ |
| P२५ | ० एमबी | ❌ | ❌ | अधिकतम सुरक्षा, स्टेटिक बाइनरी |
उत्पादन हेतु डॉकरफाइल का मानक प्रारूप
मल्टी-स्टेज, नॉन-रूट, हेल्थ चेक तथा लेबल का संपूर्ण उदाहरण:
P७
निष्कर्ष
उत्पादन इमेजों के लिए मल्टी-स्टेज निर्माण सर्वोत्तम अभ्यास है। आंकड़े यह स्पष्ट करते हैं कि प्रौद्योगिकी के अनुसार इमेज का आकार २६% से लेकर ९२% तक घट जाता है।
सुरक्षा, गति और दक्षता के लिए मल्टी-स्टेज, P२६, अ-रूट उपयोगकर्ता तथा उचित स्वास्थ्य जाँच का प्रयोग करें।