AWS Elastic Beanstalk中Tomcat WAR包更新后仍运行旧版本问题咨询

这种情况我之前帮同事排查过好几次，通常是部署流程里某个环节没走通，下面是几个常见的原因和对应的解决步骤，你可以逐一验证：

1. 部署流程其实没真正完成 #

别只盯着上传成功的提示就放松，去Elastic Beanstalk控制台的Events标签看看详细日志——有时候WAR包上传成功了，但实例更新时因为健康检查失败、资源不足或者配置错误，导致部署中途卡住了。如果看到类似"Instance deployment failed"的提示，那就是核心问题所在。

解决办法：

• 尝试在控制台点击「重新部署此版本」，强制触发一次完整的部署流程；
• 如果用EB CLI的话，执行eb deploy --staged来重新部署本地的WAR包。

2. Tomcat缓存或未彻底重启 #

Elastic Beanstalk的Tomcat环境偶尔会出现缓存旧WAR包的情况，或者Tomcat进程没完全重启，导致旧应用还在占用端口运行。

解决办法：

• 通过SSH登录到EC2实例（控制台里能找到实例的连接方式），检查Tomcat的webapps目录（通常是/var/lib/tomcat8/webapps/或/var/lib/tomcat9/webapps/，根据你的Tomcat版本调整），看新WAR包是否已经解压，旧的应用文件夹是不是还存在；
• 如果旧文件还在，手动删除旧的WAR包和对应的解压文件夹，然后重启Tomcat服务：sudo service tomcat8 restart（对应版本改命令）。注意：手动修改实例后，下次环境更新可能会被覆盖，所以最好还是找到根本问题，用EB的标准流程修复。

3. WAR包命名或版本标识问题 #

如果你的WAR包名字和之前完全一样（比如都是ROOT.war），Elastic Beanstalk可能会判定为同一版本，不会触发更新逻辑。

解决办法：

• 给WAR包加上版本号后缀，比如myapp-v2.war，再重新上传部署；
• 去控制台的「应用版本」标签，确认新上传的版本已经被创建，并且被设置为当前环境的活跃版本。

4. 环境部署设置未正确配置 #

有些环境可能被手动设置为「不自动部署新应用版本」，或者滚动部署时出现了实例替换失败的情况。

解决办法：

• 在环境页面的「应用版本」标签，选择刚上传的新版本，点击「部署」；
• 检查环境的「软件」配置选项，看看滚动部署的健康检查阈值是不是设置得太严格，导致新实例无法通过检查，环境只能保留旧实例继续运行。

5. 负载均衡器流量未切换（如果有LB的话） #

如果你的环境使用了负载均衡器，可能新实例还没通过健康检查，导致流量还在旧实例上流转。

解决办法：

• 去EC2控制台的「负载均衡器」页面，查看目标组的健康状态，确认所有新实例都处于「健康」状态；
• 等待几分钟让负载均衡器完成流量切换，或者手动清空LB的缓存（如果有配置静态资源缓存的话）。

6. 查看日志定位根本问题 #

以上方法都没解决的话，一定要看日志！在Elastic Beanstalk控制台的「日志」标签，下载完整日志包，重点看这几个文件：

• catalina.out：Tomcat的启动日志，能看到应用启动时的依赖缺失、配置错误等问题；
• eb-engine.log：Elastic Beanstalk的部署引擎日志，记录了整个部署过程的细节，比如WAR包解压失败、脚本执行错误；
• webapps/[你的应用]/logs：应用自身的运行日志，看看有没有业务代码层面的报错。

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