AWS Elastic Beanstalk部署初始化无限循环故障排查

根因说明 #

日志中触发失败的Infra-EmbeddedPreBuild配置集不属于你上传的应用包内.ebextensions范畴，是EB平台持久化存储在实例本地、或保存在环境配置中的嵌入式初始化逻辑，和当前部署的应用版本无关。这也是为什么回滚旧版本、删除应用包内配置、清空staging目录、甚至重建环境都无法解决问题——错误的01_mount命令配置根本不在应用包里，而是被写在了平台级的部署缓存、或环境的自定义配置元数据中，eb-engine守护进程每5秒重试失败的初始化阶段，就会重新生成/tmp/mount-efs.sh文件。

SSH登录实例后紧急修复步骤（无需重新触发部署） #

• 先终止无限重试循环：
  根据操作系统版本执行对应命令停止EB引擎守护进程：

  • Amazon Linux 1: sudo stop eb-engine
  • Amazon Linux 2/2023: sudo systemctl stop eb-engine
    进程停止后就不会再自动重跑失败的初始化步骤、反复生成异常脚本。

• 定位脚本生成的真实源配置：
  不要在/tmp或/var/app/staging目录下排查，直接查平台级配置缓存：

  1. 先查EB嵌入式配置目录，执行sudo grep -r "mount-efs.sh" /opt/elasticbeanstalk/deployment/embedded/，这个目录存的就是Infra-EmbeddedPreBuild阶段加载的所有独立于应用包的配置，找到定义01_mount命令的配置段，直接注释或删除整个命令块。
  2. 如果上述目录没找到匹配结果，查CloudFormation初始化元数据缓存：执行sudo grep -r "mount-efs.sh" /var/lib/cfn-init/data/metadata/，这里存了AWSEBAutoScalingGroup资源的所有初始化命令定义，找到错误的01_mount段删除即可。

• 清理残留异常文件：
  先执行sudo chattr -i /tmp/mount-efs.sh /tmp/mount-efs.sh.bak移除文件可能被加的不可修改锁，再执行sudo rm -f /tmp/mount-efs.sh /tmp/mount-efs.sh.bak删除残留文件。

• 清除失败阶段标记：
  进入/opt/elasticbeanstalk/deployment/pending/目录，删除所有和PreBuildEbExtension相关的待执行标记文件，避免重启引擎后再次触发失败步骤。

• 恢复EB服务：
  对应操作系统执行启动命令：

  • Amazon Linux 1: sudo start eb-engine
  • Amazon Linux 2/2023: sudo systemctl start eb-engine
    服务启动后会跳过已处理的阶段，直接进入正常运行状态，环境部署能力恢复。

后续彻底修复注意事项 #

• 实例恢复后，重建环境时不要复用之前异常环境保存的配置模板，选择对应平台的默认干净配置，应用版本选择确认无异常EFS挂载逻辑的历史版本，避免错误的嵌入式配置被再次带入新实例。
• 检查EB控制台环境配置页的所有自定义配置项，尤其是「软件」「实例配置」「自定义挂载」相关的自定义脚本、环境属性，彻底移除所有手动配置的EFS挂载相关逻辑，如果需要挂载EFS，使用EB官方原生的EFS挂载配置项，不要通过自定义ebextension脚本实现。
• 后续排查EB部署故障时，不要仅排查应用包内的.ebextensions，/opt/elasticbeanstalk/目录下的平台级缓存、环境级配置是优先级更高的排查点。

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