Início / coding / Perguntas / 77599776
Accepted
whatf0xx
Asked: 2023-12-04 21:25:17 +0800 CST

Por que uma imagem Docker baseada em Alpine Linux não consegue encontrar comandos para executar em um caminho absoluto?

  • 772

Eu sou novo no Docker. Quero colocar em contêiner um ambiente pequeno para poder executar executáveis, mas estou preso porque não consigo nem executar um executável.

Minha estrutura de pastas é assim:

example/
|-Dockerfile
|-hello_world

Meu Dockerfilefica assim:

# Use Alpine Linux as the base image
FROM alpine:latest

# Set the working directory inside the container
WORKDIR /app

# Copy the executable to the container
COPY hello_world /app/

# Set the permissions for the executable
RUN chmod +x /app/hello_world

# Define the command to run your server when the container starts
ENTRYPOINT ["/app/hello_world"]

Então eu corro:

> sudo docker build -t example .

> sudo docker run --name example_container example

O resultado disso é este:

exec /app/hello_world: no such file or directory

Eu tentei tantas variações quanto posso imaginar, tentando usar CMD, RUNe ENTRYPOINTno Dockerfile mas todas tiveram o mesmo resultado da imagem não conseguir encontrar o programa hello_world na pasta app que existe na raiz.

Estou realmente confuso porque tentei isso no meu sistema operacional Ubuntu vanilla, coloquei uma pasta de teste na raiz e depois uma hello_worldlá, e pareceu funcionar bem, pois eu poderia executá-lo de qualquer lugar com esse caminho absoluto.

/app/hello_worldé um executável, é um trecho compilado de código Rust. Quando executo /app/hello_worldo shell na minha máquina Ubuntu, ele funciona bem.

conjunto de ferramentas stable-x86_64-unknown-linux-gnu/rustc 1.71.0

Alguém poderia me dizer o que estou fazendo de errado?

docker

2 respostas

  1. Best Answer

    A razão pela qual você vê o erro “nenhum arquivo ou diretório” é porque o sistema está procurando o caminho incorporado na .interpseção do binário ELF. Para um binário compilado sob glibc, isso se parece com:

    $ objdump -j .interp -s hello

hello:     file format elf64-x86-64

Contents of section .interp:
 400318 2f6c6962 36342f6c 642d6c69 6e75782d  /lib64/ld-linux-
 400328 7838362d 36342e73 6f2e3200           x86-64.so.2.

    Na sua imagem Alpine, não há /lib64/ld-linux-x86-64.so.2, o que leva à mensagem de erro.

    Usando um binário C como exemplo, se eu começar com:

    #include <stdio.h>

int main() {
    printf("Hello world.\n");
    return 0;
}

    E compile-o no meu sistema glibc e tente executá-lo no Alpine, vemos:

    $ podman run -it --rm -v $PWD:/src  -w /src alpine
/src # ./hello
/bin/sh: ./hello: not found

    Se disponibilizarmos o intérprete esperado, assim:

    $ podman run -it --rm -v $PWD:/src -w /src \
  -v /lib64/ld-linux-x86-64.so.2:/lib64/ld-linux-x86-64.so.2  alpine

    Recebemos um novo erro:

    /src # ./hello
./hello: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

    Se disponibilizarmos a biblioteca compartilhada necessária:

    $ podman run -it --rm -v $PWD:/src -w /src \
  -v /lib64/ld-linux-x86-64.so.2:/lib64/ld-linux-x86-64.so.2 \
  -v /lib64/libc.so.6:/lib64/libc.so.6  alpine

    Então o comando funciona conforme o esperado:

    /src # ./hello
Hello world.
    • 6

  2. Com base nos comentários que recebi, aqui está uma resposta para quem deseja fazer isso com Rust e Alpine.

    Conforme apontado, o problema surge ao tentar usar o padrão x86_64-unknown-linux-gnupara compilar o binário Rust. Em vez disso, compile x86_64-unknown-linux-musle use em particular:

    rustup target add x86_64-unknown-linux-musl

    Seguido pela:

    cargo build --release --target=x86_64-unknown-linux-musl

    Em seguida, adicione este novo binário ao projeto em vez do antigo, e agora o Alpine irá executá-lo perfeitamente.

    • 2

relate perguntas