Il container VPN esce con 'exec format error': piattaforma sbagliata

I container che escono subito con exec format error invitano all'istinto sbagliato: aggiungere una capability, montare un dispositivo, modificare la configurazione del tunnel. Nessuna di queste azioni arriva al problema. Il kernel non è riuscito a eseguire affatto il binario, il che in un container significa quasi sempre che l'immagine punta a un'architettura della CPU diversa da quella dell'host. Tutto ciò che potreste cambiare in instradamento, credenziali o privilegi avviene dopo che un programma è partito, e nessun programma è partito.

Il messaggio di avvio che sembra un errore di configurazione

Un errore di formato exec viene dal loader, prima che l'applicazione legga una sola impostazione. Per questo non produce avvisi di configurazione né log del tunnel, perché non c'è alcun processo vivo che li scriva. L'errore è anche straordinariamente rapido, spesso prima che compaia una qualsiasi riga nel log del container. Lo stesso breve messaggio compare sia che il binario sia per un'altra architettura, sia per un altro sistema operativo, sia danneggiato.

Registra l'ambiente di esecuzione e l'architettura accanto al riferimento esatto dell'immagine, poi controlla cosa offre davvero quel riferimento. Su Docker Desktop la piattaforma del container appartiene alla macchina virtuale Linux e non al laptop, quindi l'architettura dell'host da sola può trarre in inganno. Leggi l'elenco delle voci dell'indice per questo riferimento invece del testo di marketing sulla sua pagina di tag.

Leggi l'indice dell'immagine prima del comando di esecuzione

Quando un registro pubblica un riferimento multi-piattaforma, il tag punta a un indice e ogni voce nomina una piattaforma con il proprio digest. Ispeziona il riferimento in esame e non un tag vicino, e leggi l'indice invece di presumere cosa contiene.

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

Il primo comando elenca le piattaforme pubblicate dal riferimento. Il secondo riporta la piattaforma dell'immagine già presente localmente, ed è quella che il runtime eseguirà. Un riferimento con una sola voce significa che ogni host riceve lo stesso binario, e il tag non può aiutare una macchina per cui non è mai stato compilato.

I tag selezionano una variante; non la creano

Un indice multi-piattaforma permette al runtime di scegliere una voce corrispondente, cosa davvero comoda e spesso confusa con la portabilità. La selezione è una ricerca, non una traduzione: se la variante manca, non c'è nulla da selezionare. Lo stesso tag su due host può quindi risolversi in due binari diversi, e su un host non si risolve in nulla di utilizzabile.

Il pin tramite digest elimina l'ambiguità e rende possibile anche una revisione successiva, perché il digest identifica esattamente i byte testati. Conserva quel digest con il record di distribuzione invece di affidarti al tag che risultava corrente.

L'emulazione è un accordo, non uno strato di traduzione

L'emulazione tramite un runtime supportato può eseguire alcuni carichi di lavoro non nativi nello spazio utente, quindi l'affermazione assoluta che un'architettura non potrà mai eseguire l'immagine di un'altra è sbagliata. Non è nemmeno una soluzione generale. L'esecuzione emulata ha caratteristiche di prestazioni diverse, e un processo banale che parte non dice nulla sul fatto che un carico di tunnel si comporti in modo accettabile.

La guida multi-piattaforma di Docker tratta build native, compilazione incrociata ed emulazione come strategie separate, ed è il modo giusto di leggere le opzioni. Scegline una deliberatamente e qualifica il carico VPN sotto di essa invece di presumere equivalenza.

I permessi risolvono un problema diverso

Concedere una capability di amministrazione di rete o passare un dispositivo TUN non può far funzionare un eseguibile incompatibile. Sono permessi di esecuzione che usa un processo in corso; sono invisibili a un loader che ha già rifiutato il file.

È altrettanto vero il contrario. Un binario nativo non dimostra nulla su privilegi, accesso ai dispositivi, integrazione del resolver o la politica di riavvio di cui un tunnel ha bisogno, quindi un container che parte non è ancora un container che funziona. Stabilisci prima il contratto di piattaforma, poi passa al contratto di esecuzione con le sue opzioni documentate.

Tieni insieme il digest dell'immagine, il target supportato e la configurazione nello stesso record. Un aggiornamento di tag che cambia silenziosamente l'architettura è più facile da individuare quando il digest precedente è annotato che quando l'unico sintomo è un errore familiare e un nuovo pomeriggio di debug.