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 લખેલું હોય, ત્યારે કે જ્યારે એકમાત્ર લક્ષણ પરિચિત ભૂલ અને ડિબગિંગમાં ગાળેલી નવી બપોર હોય.