Azure容器实例中.NET Core 5.0应用优雅停止时无法触发退出事件的解决方法

容器停止时的信号传递机制差异是导致现象不一致的根本原因：

• 容器运行时停止容器的标准流程是：先向容器主进程发送SIGTERM终止信号，等待默认宽限期（ACI为30秒、本地Docker Desktop为10秒），如果进程未退出则强制发送SIGKILL杀掉进程。
• 本地Docker Desktop新版本默认给容器注入轻量init进程（Tini）作为PID 1，负责把终止信号转发给应用主进程，因此你的.NET应用能正常收到信号、触发退出事件。
• Azure容器实例默认不会给容器注入任何init代理，你的Dockerfile中dotnet gracefullApp.dll会直接成为容器的PID 1。而Linux内核的规则是：如果PID 1进程没有显式注册信号处理逻辑，发给它的终止信号会被内核直接忽略，直到宽限期结束被强制杀掉，自然无法触发应用的退出事件。

方案1：在Dockerfile中内置Tini作为信号代理（最通用，无平台依赖） #

你当前使用的Debian slim基础镜像可以直接安装Tini实现信号转发，修改后的Dockerfile关键段落如下：

1. 在基础镜像阶段安装Tini：

FROM mcr.microsoft.com/dotnet/runtime:5.0-buster-slim AS base
# 安装Tini，清理缓存减少镜像体积
RUN apt-get update && apt-get install -y --no-install-recommends tini \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /app

2. 调整启动入口，让Tini作为PID 1运行：

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
#  --为Tini参数分隔符，后面的内容作为子进程启动
ENTRYPOINT ["/usr/bin/tini", "--", "dotnet", "gracefullApp.dll"]

配置完成后，Tini会作为PID 1运行，接收到SIGTERM信号后直接转发给dotnet主进程，.NET运行时就能正常走退出流程，触发AssemblyLoadContext.Default.Unloading和AppDomain.CurrentDomain.ProcessExit事件，和本地行为完全一致。

方案2：部署ACI时开启平台侧init注入 #

如果你不想修改原有Docker镜像，可以在创建Azure容器实例时开启平台内置的init进程注入，让ACI平台自动给容器部署Tini作为PID 1转发信号，无需修改镜像内容即可实现相同效果。

• 保持当前的exec形式ENTRYPOINT写法，不要改成shell形式（比如ENTRYPOINT dotnet gracefullApp.dll），否则会由sh作为PID 1，默认不会转发终止信号给dotnet子进程。
• 退出事件中的业务逻辑不要超过ACI的30秒宽限期，超时后平台会强制发送SIGKILL终止进程，未执行完的逻辑会被直接打断。
• 无需额外修改.NET代码的事件注册逻辑，只要信号能正常传递到进程，对应的退出事件就会正常触发。

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