docker - 尝试在尽可能小的容器中运行二进制文件

Dockerfile:

FROM scratch
COPY hello /app/hello
ENTRYPOINT ["/app/hello","-g","OMGITWORKS!"]

其中hello是/usr/bin/hello的副本。命令:

docker build -t hello .
docker run hello

使用FROM scratch或FROM alpine我得到:

standard_init_linux.go:185: exec user process caused "no such file or directory"

docker inspect似乎暗示该容器在没有 shell 的情况下运行二进制文件:

"Path": "/app/hello",
"Args": [
    "-g",
    "OMGITWORKS!"
],

和

"Entrypoint": [
    "/app/hello",
    "-g",
    "OMGITWORKS!"
],

但是，令人惊讶的是FROM python:3.4:

OMGITWORKS!

探测基于 Alpine 的容器的内部结构显示:

/ # ls -al /app/hello
-rwxr-xr-x    1 root     root         23112 Mar 21 15:25 /app/hello

因此，我不太了解发生了什么。 python:3.4图像的魔力是什么？

最佳答案

这通常会引起混乱，因为如果二进制文件确实存在，则可能会引起误解。通常，这表明非静态二进制文件找不到与它链接的库，很可能是glibc，但显然取决于应用程序。运行ldd /app/hello应该会为您提供链接库的列表。



“魔术”是python:3.4基于glibc，而alpine基于musl。链接到任何一个的二进制文件与另一个不兼容。您有几种选择:

要进行快速测试，请使用FROM alpine-glibc，如果可以正常工作，则可以确定它是缺少的glibc，否则可能会有更多的丢失-> ldd并在Dockerfile

中安装所有缺少的库

在musl容器中构建二进制文件，以便在您要使用FROM alpine

时将其链接到正确的标准库

构建一个完全静态的二进制文件并使用任何图像，甚至scratch

最近添加的Docker multistage功能在最后两个选项中派上用场。

关于docker - 尝试在尽可能小的容器中运行二进制文件，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/49412771/