VPN-container afslutter med 'exec format error': forkert platform

Containere, der afslutter med det samme med exec format error, indbyder til den forkerte tilgang: tilføj en kapabilitet, montér en enhed, rediger tunnelkonfigurationen. Ingen af disse når problemet. Kernen kunne slet ikke køre binæren, hvilket i en container næsten altid betyder, at imaget er målrettet en anden CPU-arkitektur end værten. Alt, du måtte ændre vedrørende routing, legitimationsoplysninger eller privilegier, sker efter, at et program er startet, og intet program startede.

Startmeddelelsen, der ligner en konfigurationsfejl

En exec-formatfejl kommer fra loaderen, før programmet læser en eneste indstilling. Derfor giver den ingen konfigurationsadvarsler og ingen tunnellog, fordi der ikke er nogen levende proces til at skrive dem. Fejlen er også bemærkelsesværdigt hurtig, ofte før der overhovedet vises en linje i containerloggen. Den samme korte meddelelse vises, uanset om binæren er til en anden arkitektur, til et andet styresystem eller beskadiget.

Registrér kørselsmiljøet og arkitekturen sammen med den præcise imagereference, og kontrollér derefter, hvad den reference faktisk tilbyder. I Docker Desktop tilhører containerplatformen den virtuelle Linux-maskine og ikke laptops, så værtsarkitekturen alene kan vildlede. Læs indekspostlisten for denne reference i stedet for marketingteksten på dens tag-side.

Læs imageindekset før kørselskommandoen

Når et register udgiver en multiplatform-reference, peger tagget på et indeks, og hver post angiver en platform med sit eget digest. Undersøg den reference, der er under behandling, i stedet for et nabotag, og læs indekset i stedet for at antage, hvad det indeholder.

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 kommando viser de platforme, som referencen udgiver. Den anden rapporterer platformen for det image, der allerede findes lokalt, og det er det, kørselsmiljøet vil køre. En reference med kun én post betyder, at hver vært modtager den samme binær, og tagget kan ikke hjælpe en maskine, som det aldrig blev bygget til.

Tags vælger en variant; de opretter ikke en

Et multiplatform-indeks lader kørselsmiljøet vælge en matchende post, hvilket er virkelig bekvemt og ofte forveksles med portabilitet. Valget er et opslag, ikke en oversættelse: hvis varianten mangler, er der intet at vælge. Det samme tag kan derfor på to værter give to forskellige binærer, og på én vært giver det intet brugbart.

Fastgørelse via digest fjerner tvetydigheden og gør også en senere gennemgang mulig, fordi digestet identificerer præcis de bytes, der blev testet. Gem det digest sammen med udrulningsposten i stedet for at stole på det tag, der tilfældigvis var aktuelt.

Emulering er en ordning, ikke et oversættelseslag

Emulering gennem et understøttet kørselsmiljø kan køre visse ikke-native brugerrumsarbejdsbelastninger, så den absolutte påstand om, at én arkitektur aldrig kan køre en andens image, er forkert. Det er heller ikke en generel løsning. Emuleret kørsel har andre ydelsesegenskaber, og en triviel proces, der starter, fortæller intet om, hvorvidt en tunnelarbejdsbelastning opfører sig acceptabelt.

Dockers guide til flere platforme behandler native builds, krydskompilering og emulering som separate strategier, og det er den rigtige måde at læse mulighederne på. Vælg én bevidst, og kvalificér VPN-arbejdsbelastningen under den i stedet for at antage ækvivalens.

Tilladelser løser et andet problem

At give en netværksadministrationskapabilitet eller sende en TUN-enhed igennem kan ikke få en inkompatibel eksekverbar fil til at køre. Det er kørselstilladelser, som en kørende proces bruger; de er usynlige for en loader, der allerede har afvist filen.

Det omvendte er lige så sandt. En native binær beviser intet om privilegier, enhedsadgang, resolver-integration eller den genstartsprofil, en tunnel har brug for, så en container, der starter, er endnu ikke en container, der virker. Fastlæg først platformskontrakten, og gå derefter videre til kørselkontrakten med dens dokumenterede muligheder.

Opbevar image-digestet, det understøttede mål og konfigurationen sammen i samme post. En tag-opdatering, der stille ændrer arkitekturen, er lettere at fange, når det forrige digest er skrevet ned, end når det eneste symptom er en velkendt fejl og en ny eftermiddag med fejlfinding.