.env文件被Git忽略时，EC2生产环境部署的变量配置方案问询

当.env因包含敏感信息被加入.gitignore、不纳入Git仓库时，用Jenkins作为CI/CD管控核心是行业内的主流方案，下面是具体实现流程和代码获取环境变量的可行方法：

一、基于Jenkins的生产部署全流程 #

Jenkins在这里的核心作用是标准化部署流程+安全管控敏感配置，具体步骤如下：

1. Jenkins端配置准备 #

• 加密存储敏感变量：用Jenkins自带的Credentials插件，把生产环境的每个敏感配置（比如数据库地址、密码、第三方API密钥）以「Secret Text」或「Secret File」的形式加密存储。这些内容仅对授权的构建Job开放，不会以明文形式暴露。
• 构建Job配置：
  • 源码管理：配置Git仓库地址，指定拉取生产分支（如main或prod），由于.env在.gitignore中，拉取的代码包不会包含该文件。
  • 部署执行步骤：添加SSH执行任务，让Jenkins通过免密SSH登录到EC2实例（需提前给EC2的部署用户配置Jenkins服务器的公钥），先清空实例上的旧代码目录，再把拉取到的最新代码同步过去。

2. EC2实例端准备 #

• 提前安装好应用运行所需的依赖（如Node.js、Python、JDK等），确保应用具备启动基础环境。
• 给EC2上的部署用户（如ubuntu）配置Jenkins服务器的SSH公钥，实现Jenkins免密登录执行命令。

二、生产代码获取环境变量的几种方式 #

1. 启动时直接注入环境变量 #

在Jenkins的SSH执行脚本中，启动应用时直接传递环境变量，以Node.js应用为例：

DB_HOST=prod-db.example.com DB_PASSWORD=${DB_PASSWORD} node /path/to/app/app.js

这里的${DB_PASSWORD}是Jenkins从Credentials中取出的加密变量，执行脚本时会自动替换为明文值，应用启动后可直接读取这些变量。

2. 在EC2上动态生成.env文件 #

通过Jenkins的SSH脚本，将所有需要的环境变量写入EC2实例的应用目录下的.env文件：

# 覆盖生成应用目录下的.env文件
cat > /path/to/app/.env << EOF
DB_HOST=prod-db.example.com
DB_PASSWORD=${DB_PASSWORD}
API_KEY=${API_KEY}
REDIS_URL=prod-redis.example.com
EOF

应用启动时，通过对应语言的dotenv类库（如Python的python-dotenv、Node.js的dotenv）读取该文件，即可获取所有配置。

3. 不推荐的方式：写入系统环境变量 #

将变量添加到EC2实例的/etc/profile或部署用户的~/.bashrc中，虽然能让应用读取到，但变量会持久化存储在实例上，一旦实例被入侵就会暴露敏感信息，且修改配置需手动操作，不符合CI/CD自动化要求，因此不建议使用。

三、Jenkins的安全管控细节 #

• 敏感信息加密：所有存储在Credentials中的变量均为加密状态，仅授权Job可调用，Jenkins服务器不会存储明文内容。
• 权限隔离：可对Jenkins用户进行分组，仅运维或部署权限的用户能修改部署Job、查看Credentials，避免无关人员接触敏感配置。
• 审计追踪：Jenkins会记录每个构建的详细日志，包括触发人、使用的变量、执行的命令等，方便事后排查问题或合规审计。
• 避免手动操作：所有部署流程均通过Jenkins自动化执行，无需手动登录EC2修改配置，减少人为失误和安全风险。

四、额外优化建议 #

• 使用参数化构建：若需部署预生产、生产等多环境，可在Jenkins Job中设置环境参数，选择对应的变量集合，无需重复创建多个Job。
• 配合配置管理工具：如用Ansible编写Playbook，将EC2实例的依赖安装、环境变量配置标准化，Jenkins仅负责触发Playbook执行，让部署流程更规范。
• 应用侧校验：在应用启动时添加必要环境变量的校验逻辑，避免因变量缺失导致应用启动失败。

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