Elastic Beanstalk多容器部署Play+React应用端口未暴露故障求助

1. 优先检查Play容器内服务启动状态 #

• 注意到Elastic Beanstalk（下称EB）环境下Play容器的启动命令与Dockerfile定义存在明显差异：本地运行时启动命令为sbt clean compile run，EB环境下为bin/danamex -Dpidfi…，说明EB默认覆盖了原Dockerfile的启动逻辑，仅启动了Play后端的生产模式服务，未启动监听3000端口的React前端服务，直接导致Nginx转发3000端口请求时被拒绝。
• 可登录EB实例，进入Play容器执行ss -tunlp命令，确认监听端口列表，正常情况下只会看到9000端口的监听进程，不存在3000端口的监听进程。
• 检查项目构建逻辑：绝大多数Play+React整合项目的sbt run仅为开发模式指令，会同时启动前端开发服务器，生产模式构建时只会把React代码编译为静态资源，不会再启动独立的3000端口服务。

2. 校验EB多容器环境配置规则 #

• EB多容器环境基于ECS实现，不会完全照搬本地docker-compose.yml的配置，如果你没有在项目根目录编写Dockerrun.aws.json明确指定容器配置，EB自动生成的任务定义会出现以下问题：
  • 覆盖Dockerfile定义的CMD启动命令
  • 不会自动暴露容器间的通信端口，即使Dockerfile中写了EXPOSE 3000 9000也不会生效
• 登录EB实例查看ECS任务定义，确认Play容器的端口暴露配置、启动命令配置是否和本地docker-compose对齐。
• 进入Nginx容器执行ping play确认服务名解析正常，执行telnet play 9000、telnet play 3000确认端口连通性。

3. 生产环境部署逻辑优化建议 #

• 不要在生产环境用sbt run启动服务：sbt是构建工具，运行时会占用大量额外资源，建议在镜像构建阶段就完成Play项目编译打包，直接启动打包后的可执行文件。
• 生产环境下建议把React构建后的静态资源直接交给Nginx托管，不需要额外启动3000端口的前端服务，既降低资源消耗也提升访问性能。
• 补全Dockerrun.aws.json配置，明确指定两个容器的启动命令、端口映射、依赖关系，和本地docker-compose配置对齐。

4. 临时验证方案 #

可手动进入EB实例的Play容器，手动启动3000端口的前端服务，再从Nginx容器发起访问请求，如果请求正常返回即可确认故障根源为启动逻辑缺失，调整容器启动命令即可解决问题。

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