VPN कंटेनर 'exec format error' के साथ बंद होता है: गलत प्लेटफ़ॉर्म

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

शुरुआती संदेश जो कॉन्फ़िगरेशन त्रुटि जैसा दिखता है

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

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

चलाने के कमांड से पहले इमेज इंडेक्स पढ़ें

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

docker buildx imagetools inspect ghcr.io/example/vpn:1.4
docker image inspect --format '{{.Os}}/{{.Architecture}}' ghcr.io/example/vpn:1.4

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

टैग एक प्रकार चुनते हैं; वे उसे बनाते नहीं

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

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

एमुलेशन एक व्यवस्था है, अनुवाद परत नहीं

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

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

अनुमतियाँ एक अलग समस्या हल करती हैं

नेटवर्क-प्रशासन क्षमता देना या TUN डिवाइस पास करना किसी असंगत निष्पादन योग्य फ़ाइल को चला नहीं सकता। ये रनटाइम अनुमतियाँ हैं जिनका उपयोग चल रही प्रक्रिया करती है; फ़ाइल को पहले ही अस्वीकार कर चुके लोडर के लिए ये अदृश्य हैं।

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

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