VPN-container avslutas med 'exec format error': fel plattform

Containrar som avslutas direkt med exec format error inbjuder till den felaktiga instinkten: lägga till en kapabilitet, montera en enhet, redigera tunnelkonfigurationen. Inget av detta når problemet. Kärnan kunde inte köra binären alls, vilket i en container nästan alltid betyder att imagen riktar sig mot en annan CPU-arkitektur än värdens. Allt du skulle kunna ändra i routning, inloggningsuppgifter eller behörigheter sker efter att ett program har startat, och inget program startade.

Startmeddelandet som ser ut som ett konfigurationsfel

Ett exec-formatfel kommer från lastaren, innan programmet läser en enda inställning. Därför ger det inga konfigurationsvarningar och ingen tunnellogg, eftersom det inte finns någon levande process som kan skriva dem. Felet är också anmärkningsvärt snabbt, ofta innan det ens visas en rad i containerloggen. Samma korta meddelande visas oavsett om binären är för en annan arkitektur, för ett annat operativsystem eller skadad.

Anteckna körtidsmiljön och arkitekturen tillsammans med den exakta imagereferensen och kontrollera sedan vad den referensen faktiskt erbjuder. På Docker Desktop tillhör containerplattformen den virtuella Linux-maskinen och inte laptopen, så värdarkitekturen ensam kan vilseleda. Läs indexposterna för den här referensen i stället för marknadsföringstexten på dess tag-sida.

Läs imageindexet före körkommandot

När ett register publicerar en multi-plattformsreferens pekar taggen på ett index, och varje post namnger en plattform med sin egen digest. Granska referensen som är under utvärdering och inte en närliggande tagg, och läs indexet i stället för att anta vad det innehåller.

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

Det första kommandot listar de plattformar som referensen publicerar. Det andra rapporterar plattformen för den image som redan finns lokalt, och det är den som körtiden kommer att köra. En referens med bara en post betyder att varje värd får samma binär, och taggen kan inte hjälpa en maskin som den aldrig byggdes för.

Taggar väljer en variant; de skapar ingen

Ett multi-plattformsindex låter körtiden välja en matchande post, vilket är genuint praktiskt och ofta förväxlas med portabilitet. Valet är en uppslagning, inte en översättning: om varianten saknas finns inget att välja. Samma tagg kan därför på två värdar ge två olika binärer, och på en värd ger den inget användbart.

Fästning med digest tar bort tvetydigheten och gör också en senare granskning möjlig, eftersom digesten identifierar exakt de byte som testades. Spara den digesten tillsammans med distributionsposten i stället för att lita på taggen som råkade vara aktuell.

Emulering är en överenskommelse, inte ett översättningslager

Emulering via en stödd körtid kan köra vissa icke-inhemska arbetsbelastningar i användarutrymmet, så det absoluta påståendet att en arkitektur aldrig kan köra en annans image är fel. Det är inte heller en generell lösning. Emulerad körning har andra prestandaegenskaper, och en trivial process som startar säger ingenting om huruvida en tunnelarbetsbelastning beter sig acceptabelt.

Dockers guide för flera plattformar behandlar inhemska byggen, korskompilering och emulering som separata strategier, och det är rätt sätt att läsa alternativen. Välj en medvetet och kvalificera VPN-arbetsbelastningen under den i stället för att anta likvärdighet.

Behörigheter löser ett annat problem

Att ge en nätverksadministratörskapabilitet eller släppa igenom en TUN-enhet kan inte få en inkompatibel körbar fil att köras. Detta är körtidsbehörigheter som en körande process använder; de är osynliga för en lastare som redan har avvisat filen.

Det motsatta är lika sant. En inhemsk binär bevisar ingenting om privilegier, enhetsåtkomst, resolver-integration eller den omstartspolicy som en tunnel behöver, så en container som startar är ännu inte en container som fungerar. Fastställ plattformskontraktet först och gå sedan vidare till körtidskontraktet med dess dokumenterade alternativ.

Förvara image-digesten, det stödda målet och konfigurationen tillsammans i samma post. En tagguppdatering som tyst ändrar arkitekturen är lättare att fånga när den föregående digesten är nedskriven, än när det enda symptomet är ett känt fel och en ny eftermiddag med felsökning.