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

Question

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!

探测基于阿尔卑斯山的集装箱的内部结构显示：

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

所以，我真的不明白发生了什么。 python中有什么魔力：3.4图像？

Answer 1

  

exec用户进程导致“没有这样的文件或目录”

这通常会引起混淆，因为如果像你的情况那样二进制实际存在，那就有点误导了。通常这表示非静态二进制文件无法找到它链接的库，很可能是glibc，但显然取决于应用程序。运行ldd /app/hello应该会为您提供链接库列表。

  

python中有什么魔力：3.4图像？

“神奇”是python:3.4基于glibc，而alpine基于musl。链接的二进制文件与另一个不兼容。您有几个选择：

1. 为了快速测试FROM alpine-glibc，如果它有效，你肯定知道它是缺失的glibc，否则可能会有更多缺失 - ＆gt; ldd并在Dockerfile
中安装任何缺少的库
2. 在musl容器中构建二进制文件，如果要使用FROM alpine
，则将其链接到正确的标准库
3. 构建完全静态的二进制文件并使用任何图像，甚至是scratch

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

Answer 2

添加到@ ErikDannenberg的答案：

This blog post详细介绍了如何使用ldd和objdump来确定所有依赖项以及如何将它们添加到泊坞窗图像。

它还指向自动执行此操作的dockerize tool。