Lumabas ang VPN container na may 'exec format error': maling plataporma

Ang mga container na agad lumalabas na may exec format error ay nag-aanyaya sa maling instinct: magdagdag ng kakayahan, mag-mount ng device, i-edit ang configuration ng tunnel. Wala sa mga iyon ang umaabot sa problema. Hindi kayang patakbuhin ng kernel ang binary, na sa isang container ay halos palaging nangangahulugang ang image ay naka-target sa ibang arkitektura ng CPU kaysa sa host. Lahat ng maaari mong baguhin sa routing, kredensyal o pribilehiyo ay nangyayari pagkatapos magsimula ang program, at walang program na nagsimula.

Ang mensahe sa pagsisimula na mukhang error sa configuration

Ang pagkabigo sa format ng exec ay nagmumula sa loader, bago pa magbasa ang aplikasyon ng kahit isang setting. Kaya hindi ito gumagawa ng anumang babala sa configuration o log ng tunnel, dahil walang buhay na proseso na magsusulat ng mga iyon. Napakabilis din ng pagkabigo, kadalasan bago pa man lumitaw ang kahit isang linya sa log ng container. Ang parehong maikling mensahe ay lumilitaw kahit ang binary ay para sa ibang arkitektura, para sa ibang operating system, o sira.

Itala ang runtime environment at arkitektura kasama ng eksaktong reference ng image, pagkatapos ay tingnan kung ano talaga ang iniaalok ng reference na iyon. Sa Docker Desktop, ang plataporma ng container ay pag-aari ng Linux virtual machine at hindi ng laptop, kaya ang arkitektura ng host lamang ay maaaring makapagligaw. Basahin ang listahan ng mga entry sa index para sa reference na ito, hindi ang marketing text sa pahina ng tag nito.

Basahin ang index ng image bago ang command sa pagpapatakbo

Kapag naglathala ang isang registry ng multi-platform na reference, ang tag ay tumuturo sa isang index, at pinapangalanan ng bawat entry ang isang plataporma na may sariling digest. Siyasatin ang reference na sinusuri at hindi ang kalapit na tag, at basahin ang index sa halip na ipagpalagay kung ano ang laman nito.

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

Ang unang command ay naglilista ng mga platapormang inilathala ng reference. Ang pangalawa ay nag-uulat ng plataporma ng image na naroroon na nang lokal, at iyon ang patatakbuhin ng runtime. Ang reference na may isang entry lang ay nangangahulugang natatanggap ng bawat host ang parehong binary, at hindi matutulungan ng tag ang isang makinang hindi kailanman ginawan nito.

Pumipili ang mga tag ng variant; hindi sila gumagawa nito

Pinapayagan ng multi-platform na index ang runtime na pumili ng tugmang entry, na talagang maginhawa at madalas napagkakamalang portability. Ang pagpili ay isang paghahanap, hindi pagsasalin: kung wala ang variant, walang mapipili. Kaya ang parehong tag sa dalawang host ay maaaring humantong sa dalawang magkaibang binary, at sa isang host ay hindi humahantong sa anumang magagamit.

Ang pag-pin sa pamamagitan ng digest ay nag-aalis ng kalabuan at nagbibigay-daan din sa pagrepaso sa hinaharap, dahil eksaktong tinutukoy ng digest ang mga byte na sinubukan. Itago ang digest na iyon kasama ng talaan ng pag-deploy sa halip na umasa sa tag na nagkataong kasalukuyan.

Ang emulation ay isang kasunduan, hindi isang layer ng pagsasalin

Ang emulation sa pamamagitan ng sinusuportahang runtime ay maaaring magpatakbo ng ilang hindi native na user-space workload, kaya ang ganap na pag-aangkin na ang isang arkitektura ay hindi kailanman maaaring magpatakbo ng image ng iba ay mali. Hindi rin ito isang pangkalahatang solusyon. Ang emulated na pagpapatupad ay may iba't ibang katangian ng performance, at ang isang maliit na prosesong nagsisimula ay walang sinasabi tungkol sa kung kumikilos nang katanggap-tanggap ang isang tunnel workload.

Itinuturing ng multi-platform na gabay ng Docker ang native na build, cross-compilation at emulation bilang magkakahiwalay na estratehiya, at iyon ang tamang paraan ng pagbasa sa mga opsyon. Pumili ng isa nang sinasadya, at suriin ang VPN workload sa ilalim nito sa halip na ipagpalagay ang pagkakapareho.

Nilulutas ng mga pahintulot ang ibang problema

Ang pagbibigay ng kakayahan sa administrasyon ng network o pagpasa ng TUN device ay hindi makapagpapatakbo ng isang hindi compatible na executable. Ito ay mga pahintulot sa runtime na ginagamit ng isang tumatakbong proseso; hindi ito nakikita ng loader na tinanggihan na ang file.

Ang kabaligtaran ay kasing totoo. Ang native binary ay walang pinapatunayan tungkol sa mga pribilehiyo, pag-access sa device, integrasyon ng resolver o patakaran sa restart na kailangan ng tunnel, kaya ang container na nagsisimula ay hindi pa container na gumagana. Itatag muna ang kontrata ng plataporma, pagkatapos ay lumipat sa kontrata ng runtime kasama ang mga dokumentadong opsyon nito.

Panatilihing magkasama ang digest ng image, sinusuportahang target at configuration sa parehong talaan. Ang update ng tag na tahimik na nagbabago ng arkitektura ay mas madaling mahuli kapag nakasulat ang nakaraang digest, kaysa kapag ang tanging sintomas ay isang pamilyar na error at isang bagong hapon na ginugol sa pag-debug.