如何通过AWS Code Pipeline为不同环境部署不同的bootstrap.properties

我之前在部署Serverless Spring Boot应用到AWS时，也碰到过一模一样的配置隔离需求，下面是几个我实际验证过、能实现自动化部署的方案：

方案1：CodeBuild环境变量+配置占位符替换 #

这是最直接的方案，利用CodePipeline不同阶段的环境变量，在构建阶段动态替换bootstrap.properties的内容：

• 步骤1：在CodePipeline各阶段配置环境变量
  给Dev、Staging、Prod等不同部署阶段分别设置专属的环境变量，比如SPRING_CLOUD_CONFIG_URI、SPRING_PROFILE_ACTIVE，值对应各环境的Config Server地址和激活的配置文件。
• 步骤2：修改bootstrap.properties为占位符格式
  把项目里的bootstrap.properties内容改成用变量占位的形式：

  spring.cloud.config.uri=${SPRING_CLOUD_CONFIG_URI}
  spring.profiles.active=${SPRING_PROFILE_ACTIVE}
  # 其他配置同理
  

• 步骤3：在CodeBuild的buildspec.yml中添加替换逻辑
  在build阶段使用envsubst命令（Linux系统默认支持）替换占位符：

  phases:
    build:
      commands:
        - envsubst < src/main/resources/bootstrap.properties > src/main/resources/bootstrap.properties.tmp
        - mv src/main/resources/bootstrap.properties.tmp src/main/resources/bootstrap.properties
        - ./mvnw clean package -DskipTests
  

  注意：如果有敏感配置（比如Config Server的认证信息），不要直接放在环境变量里，改用AWS Secrets Manager存储，在buildspec里通过AWS CLI拉取后再替换。

方案2：用AWS Parameter Store/Secrets Manager托管配置，彻底告别本地bootstrap文件 #

这个方案更符合Serverless的最佳实践，把配置完全托管在AWS服务中，应用启动时动态拉取：

• 步骤1：按环境存储配置参数
  在AWS Systems Manager Parameter Store中创建分层的参数，比如：
  • /dev/spring/cloud/config/uri
  • /prod/spring/cloud/config/uri
    敏感信息（比如密码）可以存在Secrets Manager中。
• 步骤2：修改Spring Boot应用集成AWS配置服务
  引入Spring Cloud AWS依赖，让应用启动时自动从Parameter Store读取配置：

  <dependency>
    <groupId>io.awspring.cloud</groupId>
    <artifactId>spring-cloud-starter-aws-parameter-store-config</artifactId>
  </dependency>
  

  然后在bootstrap.properties中只需要配置参数的根路径和当前环境：

  spring.cloud.aws.parameterstore.enabled=true
  spring.cloud.aws.parameterstore.prefix=/spring
  spring.profiles.active=${ENVIRONMENT}
  

• 步骤3：给部署的IAM角色赋予对应权限
  在CodePipeline部署Serverless应用时，给应用的执行角色添加读取对应环境参数路径的权限，比如Dev角色只能读取/dev/*的参数，确保环境隔离。

方案3：代码仓库中维护多环境配置文件，构建时动态复制 #

如果偏好把配置文件放在代码仓库中管理，可以按环境拆分配置：

• 步骤1：在代码中创建多环境配置目录
  在src/main/resources/config下创建dev、prod等子目录，每个目录下存放对应环境的bootstrap.properties：

  src/main/resources/
  ├── config/
  │   ├── dev/
  │   │   └── bootstrap.properties
  │   └── prod/
  │       └── bootstrap.properties
  └── bootstrap.properties # 可以留空或者放通用配置
  

• 步骤2：在buildspec中根据环境复制对应配置
  通过CodePipeline传递的环境变量（比如DEPLOY_ENV）判断要复制哪个目录的文件：

  phases:
    build:
      commands:
        - cp src/main/resources/config/${DEPLOY_ENV}/bootstrap.properties src/main/resources/bootstrap.properties
        - ./mvnw clean package -DskipTests
  

• 步骤3：CodePipeline阶段绑定对应环境变量
  给每个部署阶段设置DEPLOY_ENV为dev、prod等，确保构建时复制正确的配置文件。

注意事项 #

• 不管用哪种方案，都要严格控制IAM权限，确保Dev环境无法访问Prod的配置信息。
• 部署前一定要在测试环境验证配置替换/拉取是否正确，避免出现应用连接错误Config Server的情况。
• 如果使用Serverless Framework部署，可以在serverless.yml中结合环境变量进一步简化配置传递。

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