使用AWS Step Functions部署Shiny应用至shinyapps.io无报错但失败

核心差异分析 #

相同AMI在EC2手动启动成功，但Step Functions中失败，核心问题出在执行环境的权限、网络、资源或上下文差异，以下是具体排查方向：

1. IAM角色权限不足 #

EC2实例使用的IAM角色可能拥有完整的shinyapps.io部署权限（比如访问shinyapps API、必要的网络出站权限），但Step Functions的执行角色缺少对应权限：

• 检查Step Functions执行角色是否包含shinyapps:*相关权限，或至少允许访问shinyapps.io的API端点
• 确认角色是否有权限访问部署依赖的资源（比如存储R包的S3桶）

2. 环境变量缺失 #

deployApp依赖的认证信息（如SHINYAPPS_IO_TOKEN、SHINYAPPS_IO_ACCOUNT）或R环境变量，在EC2手动启动时已配置，但Step Functions执行时未传递：

• 在Step Functions任务中添加环境变量配置，同步EC2实例中已有的关键变量
• 可在部署前添加日志输出，打印当前环境变量列表，确认是否缺失

3. 网络访问受限 #

EC2实例所在的VPC/安全组允许出站访问shinyapps.io（443端口），但Step Functions的执行环境网络配置不同：

• 如果Step Functions使用Lambda集成，检查Lambda是否配置了VPC访问，且VPC有NAT网关允许出站HTTPS请求
• 测试Step Functions执行环境能否连通api.shinyapps.io，比如在任务中添加curl -v https://api.shinyapps.io命令并输出结果

4. 资源配额不足 #

部署过程中编译R包（如maps）需要足够的内存和时间，Step Functions的执行环境（如Lambda）默认资源配额可能低于EC2实例：

• 调整Lambda的内存配置到1024MB以上，超时时间延长至15分钟（R包编译耗时较长）
• 如果使用ECS任务，增加CPU和内存配额，避免资源耗尽导致进程被终止

5. 执行上下文差异 #

EC2手动操作时可能存在本地缓存（如已下载的R包、R会话配置），但Step Functions是无状态执行，每次都是全新环境：

• 在deployApp前添加步骤，初始化R的包缓存或renv环境，确保依赖包能快速获取
• 输出R的会话信息（如sessionInfo()），对比EC2和Step Functions环境的差异

诊断辅助建议 #

如果需要进一步定位，可在Step Functions的部署任务中添加以下操作：

• 打印当前执行环境的IAM角色信息：aws sts get-caller-identity
• 测试网络连通性：curl https://api.shinyapps.io/health
• 输出deployApp的详细日志：在调用deployApp()时添加参数verbose = TRUE，并捕获完整输出

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