AWS Elastic Beanstalk部署时跳过未变更.ebextensions配置的规范处理方法

哥们儿，我太懂你这糟心事儿了——每次用eb deploy部署的时候，明明没碰过.ebextensions/my.config里的初始化步骤，结果这些安装依赖、装NVIDIA驱动的命令还是会重复跑一遍，不仅白浪费时间，还经常因为驱动已经装过了直接报错失败。

在Elastic Beanstalk里，确实没有直接跳过未变更配置的开关，因为EB的设计逻辑是每次部署都会完整应用所有配置项。不过咱们有几种规范的处理方式，完美解决这个问题：

1. 给命令添加幂等性检查（最常用的最佳实践） #

核心思路是让每个命令不管执行多少次都不会出错，也就是先检查操作是否已经完成，只有没完成的时候才执行。这是EB官方推荐的处理方式，操作简单且可靠。

比如你可以把原来的配置改成这样，给每个步骤加前置判断：

commands:
  01_install_make:
    command: |
      # 检查make是否已经安装，没装才执行安装
      if ! command -v make &> /dev/null; then
        sudo yum install -y gcc make
      fi
  02_install_headers:
    command: |
      # 检查对应版本的kernel-devel是否存在
      if ! rpm -q kernel-devel-$(uname -r) &> /dev/null; then
        sudo yum install -y kernel-devel-$(uname -r)
      fi
  03_install_kernel_extras:
    command: |
      if ! rpm -q kernel-modules-extra &> /dev/null; then
        sudo dnf install -y kernel-modules-extra
      fi
  04_download_grid_drivers:
    command: |
      # 用标记文件判断是否已经下载过驱动
      if [ ! -f /opt/nvidia_drivers_downloaded ]; then
        aws s3 cp --recursive s3://ec2-linux-nvidia-drivers/latest/ .
        # 创建标记文件，下次执行就会跳过
        touch /opt/nvidia_drivers_downloaded
      fi
  05_add_permissions:
    command: |
      # 检查驱动安装包是否已经有执行权限
      if [ ! -x NVIDIA-Linux-x86_64*.run ]; then
        chmod +x NVIDIA-Linux-x86_64*.run
      fi
  06_install_nvidia_driver:
    command: |
      # 检查nvidia-smi是否存在，判断驱动是否已安装
      if ! command -v nvidia-smi &> /dev/null; then
        sudo /bin/sh ./NVIDIA-Linux-x86_64*.run -s
      fi

这种方式的好处是不需要改变你的部署流程，每次部署时这些命令会自动跳过已经完成的步骤，不会报错。

2. 制作自定义AMI（适合长期固定的依赖） #

如果这些初始化步骤完全不会变更，你可以把所有依赖预先安装好，制作一个自定义的EC2 AMI，然后在创建EB环境时指定使用这个AMI。

这样每次部署的时候，EB会基于已经配置好的AMI启动实例，不需要再跑.ebextensions里的初始化命令，部署速度会快很多，也彻底避免了重复执行的问题。

不过这个方法的缺点是，如果以后需要更新依赖（比如升级NVIDIA驱动版本），你得重新制作AMI并更新EB环境的AMI配置，适合依赖长期稳定的场景。

3. 拆分配置文件（可选优化） #

你可以把一次性初始化的命令和日常部署需要的配置拆分到不同的.ebextensions文件里。比如：

• 把初始化依赖的命令放到init.config里，只有在环境创建时上传这个文件；
• 日常部署只上传包含应用配置的app.config。

不过这个方法需要你手动管理配置文件的上传，不够自动化，所以一般不如前两种方法常用。

总结一下：最推荐的是第一种给命令加幂等性检查的方式，既符合EB的设计逻辑，又能灵活应对后续可能的依赖变更；如果依赖完全固定，自定义AMI是更高效的选择。

备注：内容来源于stack exchange，提问作者Lukasz Tracewski