CodeBuild+Beanstalk+Tomcat多ebextensions配置冲突问题求助

我来帮你分析下这个问题——我之前也碰到过类似的Elastic Beanstalk部署挂起的情况，大概率是.ebextensions里的命令执行顺序不对，或者某个命令阻塞了部署流程导致的。给你几个具体的解决思路和实操步骤：

先搞懂Beanstalk的配置执行逻辑 #

首先得明确.ebextensions里两种命令的执行阶段，这是解决问题的关键：

• commands：在应用代码部署到实例之前运行，是操作系统层面的命令，这时候你部署的war包还没出现在Tomcat的webapps目录里呢。
• container_commands：在应用代码部署完成后、Tomcat容器启动之前运行，这时候能直接访问到Beanstalk放置的war包和应用文件。

你的fix-path.config是用来解压war包的，显然应该放在container_commands阶段；而Filebeat的配置操作，必须等war包解压完成后再执行，所以也要放在container_commands里，还要明确执行顺序。

调整配置文件的结构和顺序 #

把两个配置合并成一个文件（或者保持分开，但给命令加数字前缀排序），确保解压war的命令先执行，再配置Filebeat。比如下面这个combined.config的示例：

container_commands:
  01_unpack_war:
    command: |
      cd /var/lib/tomcat8/webapps/ROOT
      unzip -o ROOT.war
    test: "[ -f /var/lib/tomcat8/webapps/ROOT/ROOT.war ]"
  02_configure_filebeat:
    command: |
      # 替换成你实际的Filebeat配置命令
      cp /var/app/current/.ebextensions/filebeat.yml /etc/filebeat/filebeat.yml
      systemctl restart filebeat
    test: "[ -f /var/app/current/.ebextensions/filebeat.yml ]"

• 数字前缀01_、02_是强制指定执行顺序的关键，Beanstalk会按前缀数字从小到大执行命令。
• test条件是为了避免重复执行命令（比如实例重启时），只有当目标文件存在时才执行，减少不必要的操作。

排查命令是否阻塞了流程 #

部署挂起最常见的原因就是某个命令没有自动退出，比如：

• 你在Filebeat配置里用了filebeat run（前台运行）而不是后台启动，这会让命令一直占着终端，导致部署流程卡住。
• 命令需要交互式输入（比如sudo没有免密），但Beanstalk的部署是无人值守的，会一直等待输入。

解决方法：

• 所有container_commands默认以root身份执行，不需要加sudo。
• 启动Filebeat用systemctl restart filebeat或者service filebeat restart，确保是后台运行。
• 避免用tail -f这类持续运行的命令，如果需要验证服务状态，可以用systemctl is-active --quiet filebeat来做检查。

加日志调试，定位卡住的环节 #

给每个命令加上日志输出，方便你事后排查哪个步骤出了问题：

container_commands:
  01_unpack_war:
    command: |
      echo "开始解压war包: $(date)" >> /var/log/eb_deploy_debug.log
      cd /var/lib/tomcat8/webapps/ROOT
      unzip -o ROOT.war >> /var/log/eb_deploy_debug.log 2>&1
      echo "war包解压完成: $(date)" >> /var/log/eb_deploy_debug.log
    test: "[ -f /var/lib/tomcat8/webapps/ROOT/ROOT.war ]"
  02_configure_filebeat:
    command: |
      echo "开始配置Filebeat: $(date)" >> /var/log/eb_deploy_debug.log
      cp /var/app/current/.ebextensions/filebeat.yml /etc/filebeat/filebeat.yml >> /var/log/eb_deploy_debug.log 2>&1
      systemctl restart filebeat >> /var/log/eb_deploy_debug.log 2>&1
      echo "Filebeat配置完成: $(date)" >> /var/log/eb_deploy_debug.log
    test: "[ -f /var/app/current/.ebextensions/filebeat.yml ]"

部署后登录EC2实例，查看/var/log/eb_deploy_debug.log就能知道每个步骤的执行时间和结果，很快就能定位到卡住的地方。

检查Beanstalk的官方日志 #

如果上面的方法还没找到问题，就去AWS控制台的Elastic Beanstalk环境里，打开日志选项卡，下载全量日志。重点看这两个文件：

• /var/log/cfn-init.log：记录.ebextensions里所有命令的执行细节，包括错误信息和超时情况。
• /var/log/eb-activity.log：记录整个Beanstalk部署流程的步骤，能看到哪个阶段开始挂起。

从根源避免war包解压的问题 #

最后提个小建议：你的war包为什么需要手动解压？是不是CodeBuild的输出配置有问题？检查下CodeBuild的buildspec.yml，确保artifacts配置正确，直接输出war包而不是压缩包：

artifacts:
  files:
    - target/your-spring-app.war
  discard-paths: yes

这样Beanstalk会自动把war包部署到Tomcat的webapps目录，Tomcat本身会自动解压war包，你就不需要手动写解压命令了，从根源上减少出错的可能。

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