使用Azure Pipelines部署.NET Core Docker容器至Elastic Beanstalk时容器无法正常停止

DevOps 小满

2026-5-13

解决Azure Pipelines部署Elastic Beanstalk时ECS任务显示STOPPED但容器仍运行的问题

我之前帮不少开发者处理过类似的头疼问题——ECS任务明明标记成STOPPED了，可容器还在硬跑，导致部署卡壳、服务停机时间超长。结合你的场景（用Azure Pipelines部署.NET Core Docker到Elastic Beanstalk），我整理了几个针对性的排查和解决步骤：

先搞清楚为啥会出现这种情况

本质上这是ECS Agent和Docker容器运行时的状态同步出了问题，常见的触发点有这几个：

ECS Agent本身资源不够（CPU/内存吃紧），没法及时把容器的实际状态同步给ECS服务端，导致任务状态显示停了，但容器还在跑
.NET Core应用没处理好停机信号（SIGTERM），进程僵死了，Docker没法正常停止容器，ECS Agent只能先把任务标记为STOPPED
Elastic Beanstalk的部署脚本等不及容器真正停止，提前把任务状态改成了STOPPED，留下了“孤儿”容器

一步步解决问题

1. 给ECS Agent“加个餐”——提升资源预留

ECS Agent是管理容器的核心，如果它资源不够，状态同步肯定会出问题。你可以在Elastic Beanstalk控制台调整：

找到你的ECS环境，进入配置 -> 容器（或ECS集群配置）
把ECS Agent的CPU预留从默认的0.1vCPU提到0.2-0.3vCPU，内存预留从128MB提到256-512MB
这样Agent就有足够的资源处理容器启停事件，不会因为卡壳导致状态不同步

2. 给.NET Core应用加个“优雅停机”的逻辑

很多时候容器停不掉，是因为应用没接住Docker发的SIGTERM信号，进程僵死了。给你的.NET Core应用加个优雅停机处理：

在项目里加个托管服务来处理停机事件：

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureServices(services =>
        {
            services.AddHostedService<GracefulShutdownService>();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

public class GracefulShutdownService : IHostedService
{
    private readonly IHostApplicationLifetime _appLifetime;

    public GracefulShutdownService(IHostApplicationLifetime appLifetime)
    {
        _appLifetime = appLifetime;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        // 注册停机回调
        _appLifetime.ApplicationStopping.Register(OnShutdown);
        return Task.CompletedTask;
    }

    private void OnShutdown()
    {
        // 这里写你的清理逻辑：比如关闭数据库连接、等待正在处理的请求完成
        Console.WriteLine("应用正在优雅停机，处理剩余请求...");
        Thread.Sleep(5000); // 留5秒缓冲，根据你的业务调整时长
    }

    public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
}

同时，Dockerfile里要用ENTRYPOINT启动应用，确保信号能正确传递到.NET进程：
```
ENTRYPOINT ["dotnet", "YourApplication.dll"]
```

3. 延长Elastic Beanstalk的任务停止超时时间

默认的超时时间可能太短，还没等容器真正停掉，EB就把任务标记成STOPPED了。可以通过配置文件调整：

在项目根目录创建.ebextensions/ecs-timeout.config，内容如下：

option_settings:
  aws:elasticbeanstalk:application:environment:
    # 把超时设为5分钟（300秒），根据你的应用停机时长调整
    ECS_TASK_STOP_TIMEOUT: "300"

下次部署时，EB就会用这个更长的超时时间等待容器停止

4. 在Azure Pipelines里加个“强制清理”步骤

如果偶尔还是会出现残留容器，可以在部署前加个脚本，强制清理掉状态异常的容器：

在Azure Pipelines的YAML里加个Shell任务：

- task: ShellScript@2
  displayName: '清理残留的异常容器'
  inputs:
    scriptPath: './scripts/clean-stale-containers.sh'
    args: '--cluster $(ECS_CLUSTER_NAME) --task-arn $(ECS_TASK_ARN)'

对应的clean-stale-containers.sh脚本：

#!/bin/bash
CLUSTER_NAME=$2
TASK_ARN=$4

# 获取任务对应的容器ID
CONTAINER_ID=$(aws ecs describe-tasks --tasks $TASK_ARN --cluster $CLUSTER_NAME --query 'tasks[0].containers[0].runtimeId' --output text)

if [ ! -z "$CONTAINER_ID" ]; then
    echo "发现残留容器：$CONTAINER_ID，正在强制停止..."
    # 给容器60秒时间优雅停止，不行就强制kill
    docker stop -t 60 $CONTAINER_ID
    docker rm $CONTAINER_ID
    echo "已成功清理残留容器"
else
    echo "未发现需要清理的容器"
fi

注意：要确保Azure Pipelines的服务角色有执行aws ecs describe-tasks和Docker命令的权限

5. 加个监控提前预警

为了避免问题发生了才发现，可以在CloudWatch里加个告警：

监控ECS的TaskStateChange事件，当任务状态为STOPPED但容器状态仍为RUNNING时，触发告警
同时监控ECS集群的CPU和内存使用率，避免资源不足导致Agent异常

最后总结

这个问题的核心就是状态同步+资源不足，按照上面的步骤一步步优化，应该能大幅降低问题发生的频率。如果还是不行，可以试试升级ECS Agent到最新稳定版，或者排查下是不是你的.NET应用里有特定的进程导致僵死的情况。

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