Symfony 6部署AWS Beanstalk遇manifest.json缺失问题求助

你遇到的核心问题是Beanstalk的PHP环境默认不会自动构建Symfony的前端资源，以下是几个符合Beanstalk设计理念的可行方案：

方案1：用.ebextensions自动安装Node.js并构建资源 #

这是最贴合Beanstalk基础设施即代码理念的方案，通过配置文件让部署流程自动完成前端构建：

1. 在项目根目录创建.ebextensions文件夹
2. 新建node_build.config文件，写入以下内容：

commands:
  01_install_nvm:
    command: |
      curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
      echo "export NVM_DIR=\"$HOME/.nvm\"" >> /home/ec2-user/.bashrc
      echo "[ -s \"$NVM_DIR/nvm.sh\" ] && \. \"$NVM_DIR/nvm.sh\"" >> /home/ec2-user/.bashrc
  02_install_node:
    command: |
      source /home/ec2-user/.bashrc
      nvm install 20 # 替换为你项目依赖的Node版本
      nvm alias default 20
  03_install_deps:
    cwd: /var/app/staging
    command: npm install
  04_build_assets:
    cwd: /var/app/staging
    command: npm run build

3. 将.ebextensions文件夹包含到部署包中，重新部署即可

原理：Beanstalk会在EC2实例启动或部署时执行这些命令，先安装NVM和指定版本的Node.js，再进入代码暂存目录（/var/app/staging）安装依赖、构建前端资源，最后同步到/var/app/current。

方案2：本地构建后将静态资源打包部署 #

如果不需要在服务器端构建，可以提前在本地生成静态资源再打包上传：

1. 本地执行npm run build，生成public/build目录下的所有文件（包括manifest.json）
2. 修改.gitignore，移除对public/build的忽略（如果之前有配置），或者打包时手动包含该目录
3. 生成部署包时确保public/build被包含，比如用zip命令：

zip -r symfony-deploy.zip . -x "node_modules/*" ".git/*" "vendor/*" # 按需排除不必要目录，保留public/build

4. 上传该压缩包到Beanstalk完成部署

这个方案的优势是减少服务器端的依赖和构建时间，适合前端资源变动不频繁的场景。

方案3：用Platform Hooks执行构建脚本 #

Beanstalk的平台钩子提供了更细粒度的部署阶段控制，适合复杂构建流程：

1. 在项目根目录创建.platform/hooks/predeploy文件夹
2. 新建build_assets.sh脚本，内容如下：

#!/bin/bash
# 安装NVM和Node.js
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 20
nvm use 20

# 进入代码暂存目录构建资源
cd /var/app/staging
npm install
npm run build

3. 给脚本添加执行权限：

chmod +x .platform/hooks/predeploy/build_assets.sh

4. 将.platform文件夹包含到部署包中，重新部署

predeploy阶段是在代码解压到/var/app/staging后、正式部署到/var/app/current前执行，刚好适配前端构建的时机。

补充说明 #

• 你之前尝试的NPM_CONFIG_PRODUCTION=true确实只对Beanstalk的Node.js平台生效，PHP平台不会识别该变量，因此无效。
• 手动SSH到EC2实例修改环境的做法不可取，因为Beanstalk会根据配置自动替换EC2实例，手动修改的内容会丢失。
• 打包node_modules的做法不推荐，不仅会增大部署包体积，还可能因服务器与本地环境差异导致依赖兼容问题。

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