基于Alpine镜像运行自包含.NET API Docker容器时出现“文件或目录不存在”错误的求助

嗨，我最近在折腾一个要跑在Docker里的独立.NET API，没直接用官方的aspnet镜像，而是打算先编译成自包含可执行文件，再放到Alpine镜像上跑，结果碰到个头疼的问题：启动容器的时候一直报错说找不到可执行文件：

exec /app/api: no such file or directory

这是我的Dockerfile：

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS builder
WORKDIR /app
COPY . .
RUN dotnet publish "DotnetSandbox.MinimalApi/DotnetSandbox.MinimalApi.csproj" -c Release -o /app/publish

FROM alpine AS final
USER $APP_UID
EXPOSE 5000
WORKDIR /app
COPY --from=builder /app/publish .
RUN ls /app
ENTRYPOINT ["/app/api"]

我特意加了ls /app命令确认文件是否被正确复制，从构建日志里能看到api文件确实存在，但就是没法执行，这可把我搞懵了😅

问题原因 #

其实这个问题的核心是C库不兼容：Alpine Linux默认使用的是musl libc，而我们默认用.NET SDK编译的自包含程序是针对glibc（大多数主流Linux发行版用的C库）构建的。即使文件物理上存在，Alpine的musl系统也无法识别这种依赖glibc的可执行文件，所以才会抛出“文件不存在”的误导性错误。

解决办法 #

这里有两种靠谱的方案可以选：

方案1：直接针对Alpine的musl架构发布程序

修改builder阶段的dotnet publish命令，指定Alpine对应的运行时标识，让.NET直接编译出适配musl的可执行文件：

RUN dotnet publish "DotnetSandbox.MinimalApi/DotnetSandbox.MinimalApi.csproj" -c Release -o /app/publish -r linux-musl-x64 --self-contained true

• 如果你的机器是ARM64架构（比如M系列Mac），把linux-musl-x64换成linux-musl-arm64即可。
• --self-contained true明确指定编译为自包含程序，确保所有依赖都打包进去。

方案2：在Alpine镜像中安装glibc兼容包

如果不想修改发布命令，可以在final阶段安装gcompat包，让Alpine能够兼容glibc编译的程序：

FROM alpine AS final
USER $APP_UID
EXPOSE 5000
WORKDIR /app
COPY --from=builder /app/publish .
# 安装glibc兼容包
RUN apk add --no-cache gcompat
RUN ls /app
ENTRYPOINT ["/app/api"]

这种方式更快捷，但不如方案1干净，因为会额外引入兼容层的依赖。

小提示 #

如果是交叉编译（比如在x64机器上编译ARM64的程序），记得在dotnet publish命令后加上--no-restore和--no-build，或者确保SDK安装了对应的跨平台编译组件。

备注：内容来源于stack exchange，提问作者Slava Germonenko