AWS EB环境变量管理：三种高效配置方案详解

1. 项目背景与核心需求

在AWS Elastic Beanstalk（EB）环境中，我们经常需要为EC2实例配置环境变量。传统做法是通过EB控制台手动添加，但这种方式存在明显缺陷：每次部署新环境都需要重复操作，无法实现版本控制，也难以保证多环境一致性。通过代码方式管理环境变量，可以完美解决这些问题。

我最近在一个电商项目中就遇到了这个需求：需要为不同环境的EC2实例配置不同的数据库连接字符串。经过多次实践，总结出以下几种可靠方案，特别适合需要自动化部署的场景。

2. 方案选型与技术对比

2.1 主流方案全景图

在AWS EB环境中，为EC2添加环境变量主要有三种技术路径：

1. EB扩展文件（.ebextensions）
2. 用户数据脚本（User Data）
3. AWS Systems Manager参数存储

我们通过一个对比表格来看各方案特点：

2.2 方案选择建议

对于大多数场景，我推荐使用.ebextensions方案，原因有三：

1. 与EB部署流程天然集成
2. 配置文件可版本化管理
3. 无需额外AWS服务权限

但当涉及数据库密码等敏感信息时，应优先考虑SSM Parameter Store方案。

3. 核心实现方案详解

3.1 使用.ebextensions配置环境变量

这是最经典的实现方式，具体操作步骤如下：

1. 在项目根目录创建.ebextensions文件夹
2. 新建配置文件（如envvars.config）
3. 添加如下YAML内容：

yaml复制option_settings:
  aws:elasticbeanstalk:application:environment:
    DB_HOST: "production-db.example.com"
    DB_PORT: "5432"
    APP_ENV: "production"

关键注意事项：

• 文件必须使用.config后缀
• YAML格式缩进必须使用空格（不能使用Tab）
• 部署后需要重启EC2实例才能生效

我在实际项目中遇到过因缩进错误导致配置失效的情况，建议使用YAML校验工具检查语法。

3.2 通过User Data脚本动态设置

对于需要运行时计算的变量，可以使用User Data方案。在.ebextensions中创建如下配置：

yaml复制files:
  "/etc/ec2_user_data.sh":
    mode: "000755"
    content: |
      #!/bin/bash
      echo 'export CUSTOM_VAR="dynamic_value"' >> /etc/profile

然后在EC2启动配置中执行该脚本。这种方式的优势是可以访问AWS元数据服务：

bash复制INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
echo "export INSTANCE_ID=$INSTANCE_ID" >> /etc/environment

重要提示：User Data脚本最多只能运行16KB的内容，复杂逻辑建议拆分为多个脚本。

3.3 集成SSM Parameter Store方案

对于生产环境，我强烈推荐使用SSM方案。首先在AWS控制台创建参数：

1. 进入Systems Manager > Parameter Store
2. 创建SecureString类型参数
3. 命名如/prod/database/password

然后在.ebextensions配置中添加：

yaml复制Resources:
  AWSEBAutoScalingGroup:
    Metadata:
      AWS::CloudFormation::Authentication:
        S3Auth:
          type: "s3"
          roleName: 
            Fn::GetOptionSetting: 
              Namespace: "aws:autoscaling:launchconfiguration"
              OptionName: "IamInstanceProfile"
              DefaultValue: "aws-elasticbeanstalk-ec2-role"
              
files:
  "/etc/profile.d/ssm_params.sh":
    mode: "000755"
    content: |
      #!/bin/bash
      export DB_PASSWORD=$(aws ssm get-parameter --name "/prod/database/password" --with-decryption --query "Parameter.Value" --output text)

需要确保EC2实例角色有ssm:GetParameter权限。

4. 高级配置技巧

4.1 环境差异化配置

通过EB环境变量实现多环境配置：

yaml复制option_settings:
  aws:elasticbeanstalk:application:environment:
    DB_HOST: 
      Fn::GetOptionSetting: 
        Namespace: "aws:elasticbeanstalk:application:environment"
        OptionName: "DB_HOST"
        DefaultValue: "localhost"

然后在EB环境属性中设置DB_HOST的实际值。

4.2 敏感信息处理最佳实践

我总结的安全处理流程：

1. 永远不要在代码仓库中存储明文密码
2. 开发环境使用假值，生产环境通过CI/CD注入
3. 密码类变量必须使用SecureString
4. 定期轮换密钥

4.3 自动化部署集成

在CI/CD管道中添加变量注入步骤（以GitHub Actions为例）：

yaml复制- name: Configure EB Environment
  run: |
    aws elasticbeanstalk update-environment \
      --environment-name ${{ env.EB_ENV_NAME }} \
      --option-settings Namespace=aws:elasticbeanstalk:application:environment,OptionName=API_KEY,Value=${{ secrets.PRODUCTION_API_KEY }}

5. 常见问题排查

5.1 变量未生效问题

检查清单：

1. 确认.ebextensions文件在正确的目录层级
2. 检查YAML语法是否正确
3. 查看/var/log/eb-activity.log日志
4. 确认实例已重启（配置变更后）

5.2 权限问题处理

典型错误及解决方案：

5.3 性能优化建议

1. 减少SSM调用：启动时批量获取参数并缓存
2. 合并配置文件：将多个.config文件合并减少解析时间
3. 使用env文件：对于大量变量，可以考虑上传.env文件到S3，启动时下载

6. 监控与维护

6.1 配置审计

定期检查实际生效的变量：

bash复制eb printenv

或直接登录EC2查看：

bash复制cat /proc/$(pgrep -f "application name")/environ | tr '\0' '\n'

6.2 变更管理策略

我建议的变更流程：

1. 先在staging环境测试
2. 使用EB配置版本控制
3. 变更时记录时间点和修改人
4. 关键变量变更后监控应用日志

6.3 成本控制

需要注意的成本点：

• SSM高级参数每月费用
• 频繁部署可能产生的EC2重启成本
• CloudTrail日志存储费用（如果开启日志记录）

经过多个项目的实践验证，这套方案在保证安全性的同时，提供了足够的灵活性。特别是在微服务架构下，通过代码管理环境变量大大简化了配置管理工作。