VPN-container avsluttes med 'exec format error': feil plattform

Containere som avsluttes umiddelbart med exec format error, innbyr til den gale instinkten: legg til en kapabilitet, monter en enhet, rediger tunnelkonfigurasjonen. Ingen av disse når problemet. Kjernen kunne ikke kjøre binæren i det hele tatt, noe som i en container nesten alltid betyr at imaget er rettet mot en annen CPU-arkitektur enn vertens. Alt du måtte endre på ruting, påloggingsinformasjon eller rettigheter skjer etter at et program har startet, og ingen programmer startet.

Oppstartsmeldingen som ser ut som en konfigurasjonsfeil

En exec-formatfeil kommer fra lasteren, før programmet leser en eneste innstilling. Derfor gir den ingen konfigurasjonsadvarsler og ingen tunnellogg, fordi det ikke finnes noen levende prosess som kan skrive dem. Feilen er også bemerkelsesverdig rask, ofte før det i det hele tatt vises en linje i containerloggen. Den samme korte meldingen vises enten binæren er for en annen arkitektur, for et annet operativsystem eller skadet.

Noter kjøretidsmiljøet og arkitekturen sammen med den nøyaktige imagereferansen, og sjekk deretter hva den referansen faktisk tilbyr. På Docker Desktop tilhører containerplattformen den virtuelle Linux-maskinen og ikke laptopen, så vertsarkitekturen alene kan villede. Les indeksoppføringene for denne referansen i stedet for markedsføringsteksten på tag-siden.

Les imageindeksen før kjørekommandoen

Når et register publiserer en multi-plattform-referanse, peker taggen på en indeks, og hver oppføring navngir en plattform med sin egen digest. Undersøk referansen som er under vurdering og ikke en nabotagg, og les indeksen i stedet for å anta hva den inneholder.

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

Den første kommandoen lister plattformene referansen publiserer. Den andre rapporterer plattformen til imaget som allerede finnes lokalt, og det er dette kjøretiden vil kjøre. En referanse med bare én oppføring betyr at hver vert mottar den samme binæren, og taggen kan ikke hjelpe en maskin den aldri ble bygget for.

Tagger velger en variant; de oppretter ikke en

En multi-plattform-indeks lar kjøretiden velge en passende oppføring, noe som er virkelig praktisk og ofte forveksles med portabilitet. Valget er et oppslag, ikke en oversettelse: hvis varianten mangler, er det ingenting å velge. Den samme taggen kan derfor på to verter gi to forskjellige binærer, og på én vert gir den ingenting brukbart.

Festing med digest fjerner tvetydigheten og gjør også en senere gjennomgang mulig, fordi digesten identifiserer nøyaktig bytene som ble testet. Ta vare på den digesten sammen med utrullingsposten i stedet for å stole på taggen som tilfeldigvis var aktuell.

Emulering er en ordning, ikke et oversettelseslag

Emulering gjennom en støttet kjøretid kan kjøre enkelte ikke-native brukerromsarbeidslaster, så den absolutte påstanden om at én arkitektur aldri kan kjøre en annens image, er feil. Det er heller ikke en generell løsning. Emulert kjøring har andre ytelsesegenskaper, og en triviell prosess som starter forteller deg ingenting om hvorvidt en tunnelarbeidslast oppfører seg akseptabelt.

Dockers veiledning for flere plattformer behandler native bygg, krysskompilering og emulering som separate strategier, og det er den riktige måten å lese alternativene på. Velg én bevisst, og kvalifiser VPN-arbeidslasten under den i stedet for å anta ekvivalens.

Tillatelser løser et annet problem

Å gi en nettverksadministrasjonskapabilitet eller å slippe gjennom en TUN-enhet kan ikke få en inkompatibel kjørbar fil til å kjøre. Dette er kjøretidstillatelser som en kjørende prosess bruker; de er usynlige for en laster som allerede har avvist filen.

Det motsatte er like sant. En native binær beviser ingenting om privilegier, enhetstilgang, resolver-integrasjon eller omstartspolicyen en tunnel trenger, så en container som starter er ennå ikke en container som virker. Etabler plattformkontrakten først, og gå deretter videre til kjøretidskontrakten med dens dokumenterte alternativer.

Oppbevar image-digesten, den støttede målplattformen og konfigurasjonen sammen i samme post. En taggoppdatering som stille endrer arkitekturen, er lettere å fange når den forrige digesten er skrevet ned, enn når det eneste symptomet er en kjent feil og en ny ettermiddag med feilsøking.