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 उपकरण पास करणे विसंगत अंमलबजावणीयोग्य फाइल चालवू शकत नाही। या चालू प्रक्रियेने वापरल्या जाणाऱ्या रनटाइम परवानग्या आहेत; फाइल आधीच नाकारलेल्या लोडरला त्या अदृश्य आहेत।

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

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