Distroless镜像EntryPoint无法用环境变量？求.NET多应用场景解决方案

问题原因 #

Docker的ENTRYPOINT ["命令", "参数"]是exec执行模式，不会通过shell解析环境变量；而你使用的runtime-deps:8.0-noble-chiseled这类精简镜像（Distroless）没有内置shell，也无法用ENTRYPOINT 命令 参数这种shell模式来解析变量，所以环境变量替换会失效。

替代方案 #

方案1：构建阶段重命名可执行文件（推荐）

在构建阶段将不同项目的可执行文件重命名为统一名称，这样ENTRYPOINT可以固定为该名称，完全适配无shell的精简镜像。修改后的Dockerfile如下：

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG csprojFileName
COPY . /home/src
RUN dotnet publish "$csprojFileName.csproj" -o /app/publish && \
    # 将项目生成的可执行文件重命名为统一的app
    mv /app/publish/$csprojFileName /app/publish/app

FROM mcr.microsoft.com/dotnet/runtime-deps:8.0-noble-chiseled
EXPOSE 8080
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["./app"]

构建时依然通过--build-arg传入项目名称：

docker build --build-arg csprojFileName=ProjectA -t app-a .
docker build --build-arg csprojFileName=ProjectB -t app-b .

这种方式既保持了镜像的精简性，又避免了环境变量解析的问题，是最优解。

方案2：构建时直接指定ENTRYPOINT

如果不想修改可执行文件名称，可以在构建镜像时通过--entrypoint参数直接指定入口程序，无需在Dockerfile中使用变量：

# 构建ProjectA镜像
docker build --build-arg csprojFileName=ProjectA --entrypoint "./ProjectA" -t app-a .
# 构建ProjectB镜像
docker build --build-arg csprojFileName=ProjectB --entrypoint "./ProjectB" -t app-b .

这种方式不需要修改原Dockerfile的ENTRYPOINT配置，但每次构建都要指定入口，适合场景简单的情况。

方案3：添加shell到镜像（不推荐）

如果一定要保留环境变量的使用方式，可以在镜像中安装shell（比如bash），然后用shell模式的ENTRYPOINT解析变量：

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG csprojFileName
COPY . /home/src
RUN dotnet publish "$csprojFileName.csproj"

FROM mcr.microsoft.com/dotnet/runtime-deps:8.0-noble-chiseled
ARG csprojFileName
ENV CSPROJFILENAME $csprojFileName
EXPOSE 8080
WORKDIR /app
COPY --from=build /app/publish .
# 安装bash，会增大镜像体积
RUN apt-get update && apt-get install -y bash && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ./$CSPROJFILENAME

但这种方式会破坏Distroless镜像的精简性，导致镜像体积大幅增加，仅作为特殊场景下的备选方案。

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