Elastic Beanstalk部署WordPress对接RDS/EFS配置持久化问题

自动扩缩容拉起的新实例配置丢失，核心原因是所有手动在单台运行中EC2实例上做的本地修改，都不会被Elastic Beanstalk（以下简称EB）自动同步到新实例。
EB新实例启动时只会加载环境级别的预设配置、应用部署包内自带的部署脚本，不会继承旧实例本地存储的wp-config.php配置、手动执行的EFS挂载命令、本地临时写入的参数。如果之前是在第一台实例上跟着WordPress引导手动填过数据库信息、手动敲命令挂载过EFS，这些操作全存在旧实例的本地系统盘上，实例被终止后本地盘直接销毁，新实例自然拿不到这些配置，就会重新弹出安装引导。

• 所有配置参数统一通过EB环境级变量注入，不做本地硬编码
  进入EB环境控制台的「配置-软件」板块，把RDS的连接地址、库名、账号、密码、表前缀，以及EFS的文件系统ID、站点挂载路径这类参数全部添加到环境属性中。这类变量是环境全局生效的，所有新启动的实例启动阶段会自动拉取这些变量，不会随实例销毁丢失。实例上运行的PHP程序可以直接通过getenv()读取这些参数，操作系统层面也可以从/opt/elasticbeanstalk/deployment/env文件加载所有环境变量。
  如果是通过EB控制台直接关联创建的RDS，平台会自动把RDS连接参数注入环境变量，不需要手动重复填写。
• 通过.platform平台钩子实现实例启动时的自动配置，禁止手动在实例上操作
  在WordPress应用部署包根目录创建.platform/hooks/predeploy目录，把EFS自动挂载、wp-config自动生成的逻辑写成可执行Shell脚本放在这个目录下，EB在每台新实例启动、每次应用部署前都会自动执行这个目录下的脚本，完全不需要人工登录实例操作。
  脚本核心逻辑参考：
  1. 先安装nfs-utils依赖，判断EFS是否已经挂载，未挂载的话创建挂载目标目录（一般是WordPress的wp-content目录，用来存主题、插件、上传文件），执行nfs4挂载命令，同时把挂载规则写入/etc/fstab保证实例重启后挂载不失效，挂载命令格式参考：mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport ${EFS_ID}.efs.${当前区域}.amazonaws.com:/ /var/www/html/wp-content
  2. 判断站点根目录下是否存在wp-config.php，不存在的话直接从环境变量读取数据库配置、盐值等参数，生成标准的WordPress配置文件，把文件属主调整为Web服务运行用户（apache或www-data，根据所选PHP平台版本确定），避免Web服务无权限读取配置。脚本要加存在性判断，避免覆盖EFS上已经存在的自定义配置。
• 提前打通EFS和EB实例的网络权限
  EFS的挂载目标要覆盖EB环境所在的所有可用区，EFS绑定的安全组要放通EB实例所属安全组的2049端口（NFS协议）入站规则，不要开放0.0.0.0/0的公网访问权限，避免数据泄露。
• 配置完成后做故障演练验证
  手动在EB控制台终止一台运行中的实例，等自动扩缩容组拉起新实例后直接访问站点：如果能正常打开前台、后台页面，不弹出WordPress安装引导，就说明配置已经持久化生效。可以登录新实例执行df -h确认EFS挂载正常，检查wp-config.php配置是否正确读取了环境变量中的参数。

• 不要把wp-config.php存在实例本地系统盘：实例本地盘随实例生命周期销毁，只有EFS上存储的站点静态文件是跨实例共享的，配置生成逻辑必须通过平台钩子落地，不能依赖实例本地留存的文件。
• 不要登录实例手动执行挂载、修改配置的操作：所有实例级别的配置变更都要通过修改应用部署包内的钩子脚本、调整EB环境配置的方式实现，手动操作的内容仅对当前操作的实例生效，新实例不会同步。
• 如果开启了EB的滚动部署，要确保钩子脚本是幂等的（重复执行不会报错、不会重复写入配置），避免部署过程中脚本执行失败导致实例启动异常。

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