GCP Cloud Functions部署Docker化.NET Core 2.1应用遇TCP启动探针失败

你的Docker配置存在几个关键问题，导致GCP的启动TCP探测失败：

1. 错误使用SDK镜像执行开发模式命令 #

当前Dockerfile基于mcr.microsoft.com/dotnet/core/sdk:2.1-bionic（包含编译工具的SDK镜像），并使用dotnet run启动应用。dotnet run是开发环境命令，会额外执行代码编译、文件监听等操作，启动速度极慢——哪怕日志显示"正在监听8080"，实际可能只是开发服务器初始化完成，但还没真正对外提供服务，直接错过GCP的启动探测超时窗口。

正确做法是采用多阶段构建，编译阶段用SDK，运行阶段切换到轻量的Runtime镜像，直接启动发布后的程序：

# 编译阶段：用SDK完成编译发布
FROM mcr.microsoft.com/dotnet/core/sdk:2.1-bionic AS build
WORKDIR /app

COPY WebAPI ./WebAPI
COPY Core ./Core
COPY Server.sln .

RUN dotnet restore
RUN dotnet publish -c Release -o out WebAPI/WebAPI.csproj

# 运行阶段：用Runtime镜像启动已发布的程序
FROM mcr.microsoft.com/dotnet/core/aspnet:2.1-bionic
WORKDIR /app
COPY --from=build /app/WebAPI/out .

ENV ASPNETCORE_URLS=http://*:8080
ENV ASPNETCORE_hostBuilder__reloadConfigOnChange=false

EXPOSE 8080

CMD ["dotnet", "WebAPI.dll"]

2. 发布文件路径与启动命令不匹配 #

你在WORKDIR /app/WebAPI下执行dotnet run，但发布后的文件实际在/app/WebAPI/out目录中。dotnet run会尝试重新编译当前目录的源代码，而非运行已发布的dll，这会额外消耗启动时间，甚至可能因环境差异编译失败，导致启动超时。

3. 端口绑定的环境变量缺失 #

虽然你在dotnet run中指定了--urls参数，但切换到Runtime镜像后，需要通过ASPNETCORE_URLS环境变量确保程序监听所有网卡（http://*:8080），否则程序可能仅监听localhost，导致GCP的外部探测无法访问端口8080。

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