Greenbone-OpenVAS容器镜像在AWS ECS中运行失败求助

一、先解决日志缺失问题 #

没有日志就无法定位根因，优先处理这一步：

• 检查任务定义的日志配置：确认已启用CloudWatch日志，指定了合法的日志组（例如/ecs/greenbone-openvas），且任务执行角色拥有logs:CreateLogStream和logs:PutLogEvents权限。
• 本地镜像测试：在本地执行docker run -it greenbone/openvas-scanner，观察容器是否能正常启动、是否有日志输出。如果本地也出现退出码0，说明是镜像本身的启动逻辑问题；如果本地正常，再排查ECS配置。
• 网络连通性检查：若任务部署在私有子网，需确保子网能访问CloudWatch日志服务（可配置VPC端点com.amazonaws.<region>.logs），否则日志无法上传到CloudWatch。

二、分析退出码0的核心原因 #

退出码0表示容器进程正常执行完毕后退出，而非崩溃。大概率是Greenbone-OpenVAS Scanner镜像的默认启动逻辑是一次性任务，没有常驻进程：

• 查看镜像默认启动命令：执行docker inspect greenbone/openvas-scanner | grep -A 10 "Cmd"，确认默认启动的是一次性脚本还是常驻服务。
• 确认镜像依赖：OpenVAS Scanner是Greenbone栈的组件之一，单独运行可能需要配合Feed同步服务、数据库（Redis/PostgreSQL）等，缺少依赖时启动脚本执行完就会退出。
• 覆盖启动命令：在ECS任务定义中，将容器启动命令改为bash -c "tail -f /dev/null"，先让容器保持运行，再通过ecs-exec进入容器内部排查状态；或者尝试指定Scanner的常驻运行命令（例如openvasd --foreground，具体以官方文档为准）。

三、ECS任务配置优化 #

• 资源分配：Greenbone-OpenVAS对资源要求较高，至少分配2vCPU/4GB内存，避免资源不足导致启动脚本提前终止。
• 环境变量配置：检查官方镜像是否需要特定环境变量（如Feed同步地址、日志输出方式），确保配置正确以维持进程常驻。
• 重启策略：临时将任务重启策略设为Always，方便反复调试；问题解决后再调整为合适的策略（如OnFailure）。

四、调试流程总结 #

1. 本地验证：先在本地确认镜像本身的运行状态，排除镜像自身问题。
2. 日志修复：确保ECS任务能正常将日志上传到CloudWatch，获取调试依据。
3. 启动命令调整：替换默认启动命令为常驻命令，或补充必要的依赖服务。
4. 资源与依赖检查：确保任务资源充足，配套服务配置到位。

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