在最小Docker容器中运行二进制文件启动失败的问题咨询

嘿，我来帮你搞定这个头疼的问题！你遇到的报错其实是个很常见的坑——/usr/bin/hello是动态链接的二进制文件，而你选的基础镜像根本没有它需要的依赖库：

• scratch镜像完全是空的，连最基础的系统库都没有；
• alpine用的是musl libc，和你宿主机（大概率是Debian/Ubuntu这类用glibc的系统）里的hello依赖的库不兼容。

先确认问题根源 #

你可以在宿主机上跑个命令，看看hello的依赖情况：

ldd /usr/bin/hello

如果输出里有libc.so.6这类条目，那肯定就是动态链接的问题没跑了。

给你三个可行的解决方案 #

1. 用匹配libc的基础镜像（最简单） #

如果你的宿主机是基于glibc的发行版，直接换用debian:stable-slim或者ubuntu:latest这类轻量但带完整依赖的镜像就行：

FROM debian:stable-slim
COPY hello /app/hello
ENTRYPOINT ["/app/hello","-g","OMGITWORKS!"]

构建运行后应该就能正常输出了。

2. 编译静态链接版本（最轻量化） #

要是你非要用scratch追求极致小巧，那就把hello重新编译成静态链接的版本。如果是GNU hello的话，编译时加个参数就行：

./configure --enable-static
make

生成的二进制会把所有依赖库打包进去，这时你原来的scratch Dockerfile就能完美运行了。

3. 给alpine装glibc兼容包（不推荐，仅供应急） #

如果死磕alpine，也可以安装兼容包来支持glibc，但这种方式容易出兼容性问题，慎选：

FROM alpine:latest
RUN apk add --no-cache libc6-compat
COPY hello /app/hello
ENTRYPOINT ["/app/hello","-g","OMGITWORKS!"]

额外验证技巧 #

要是还是有问题，你可以临时切换容器的入口命令到shell，进去排查：

docker run --entrypoint sh hello -c "ldd /app/hello && ls -l /app/hello"

这样能确认文件是否存在，以及依赖库能不能找到。

内容的提问来源于stack exchange，提问作者xenoid