如何从AWS Secrets加载环境变量至CodeDeploy？CodeBuild测试阶段咨询

我们正在AWS CodePipeline中构建CI/CD流水线，目标是从GitHub拉取代码、构建Docker镜像、测试镜像并部署至预发布服务器。以下是Build Stage的配置：

pre_build: 
    # Login to ECR 
    - f'$(aws ecr get-login --region us-east-1 --no-include-email) 

    # Get env variables from AWS Secret and write them to .env file 
    - secret=$(aws secretsmanager get-secret-value --secret-id project-env-variables --query SecretString --output text) 
    - echo "${secret}" | jq -r 'to_entries|map("(.key)=(.value|tostring)")|.[]' > ".env" 

build: 
    # Build docker image 
    - docker build -f Dockerfile.prod -t myproject:latest . 

    # Test application in docker image using .env file 
    - docker run --rm --env-file .env myproject:latest pytest 

post_build 
    # Uploading image to ECR
    - docker tag myproject:latest {repository_uri}:latest 
    - docker push {repository_uri}:latest

现咨询两个问题：

1. 是否有更优的加载环境变量以运行测试的方式？
2. 在CodeBuild的build阶段运行测试是否可行？还是应放在单独的阶段或操作中？

问题1：更优的环境变量加载方式 #

你当前通过Secrets Manager拉取并写入.env文件的方式是可行的，但有几个更高效、更安全的优化方向：

• 直接注入到CodeBuild环境，不落地文件：不需要生成.env文件，直接把Secrets Manager的密钥解析为CodeBuild的环境变量，运行测试时直接传递给容器：

  # 解析Secret并导出为环境变量
  - eval "$(aws secretsmanager get-secret-value --secret-id project-env-variables --query SecretString --output text | jq -r 'to_entries|map("export \(.key)=\(.value|tostring)")|.[]')"
  # 只传递测试相关的环境变量到容器（避免传递无关变量）
  - docker run --rm --env-file <(env | grep -E '^TEST_|^DB_') myproject:latest pytest
  

  这种方式避免了敏感数据写入磁盘，减少了文件操作步骤，安全性更高。

• 用CodeBuild原生集成加载密钥：在CodeBuild项目的环境配置里，直接把Secrets Manager的密钥添加为环境变量（路径：Environment -> Environment variables -> 选择Secrets Manager），CodeBuild会自动帮你加载这些变量，不需要手动写aws secretsmanager命令。之后运行测试时直接传递即可：

  - docker run --rm -e TEST_DB_URL=$TEST_DB_URL -e TEST_API_KEY=$TEST_API_KEY myproject:latest pytest
  

  这种方式最简洁，利用AWS原生能力，减少自定义脚本的维护成本。

• 构建时注入非敏感测试变量：如果测试用的是不敏感的配置（比如测试端口、日志级别），可以在docker build时用--build-arg传递，但敏感数据绝对不能这么做——因为构建参数会留在镜像历史里，有泄露风险。

问题2：测试阶段的位置选择 #

在CodeBuild的build阶段跑测试完全可行，但从流水线的长期维护和排障效率来看，更建议把测试拆成单独的阶段——不管是CodePipeline里的独立CodeBuild阶段，还是CodeBuild内部的独立步骤，原因如下：

• 故障隔离更清晰：测试失败时，流水线直接在测试环节停住，不会执行后续的镜像推送，节省资源，也能立刻定位到是测试出了问题，而非构建或推送环节。
• 职责单一，逻辑直观：遵循“一个阶段做一件事”的原则，Build阶段专注构建镜像，Test阶段专注测试，Deploy阶段专注部署，整个流水线的逻辑一目了然，新人接手也容易理解。
• 扩展更灵活：后续要加集成测试、UI测试这类额外测试时，直接在Test阶段扩展即可，不用动Build阶段的配置。

如果暂时不想拆分CodePipeline的阶段，也可以在CodeBuild内部新增一个test步骤，把测试从build里分离出来，比如：

pre_build: 
    # Login to ECR 
    - $(aws ecr get-login --region us-east-1 --no-include-email) 

    # 加载环境变量（如果用CodeBuild原生集成则不需要这部分）
    - eval "$(aws secretsmanager get-secret-value --secret-id project-env-variables --query SecretString --output text | jq -r 'to_entries|map("export \(.key)=\(.value|tostring)")|.[]')"

build: 
    # Build docker image 
    - docker build -f Dockerfile.prod -t myproject:latest . 

test:
    # Test application in docker image
    - docker run --rm -e TEST_DB_URL=$TEST_DB_URL myproject:latest pytest 

post_build: 
    # Uploading image to ECR
    - docker tag myproject:latest {repository_uri}:latest 
    - docker push {repository_uri}:latest

这样即使在同一个CodeBuild项目里，也能清晰区分各个环节的职责，方便后续维护。

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