问题描述
在设置一个面向小到中等规模项目的基础设施即代码（Infrastructure as Code）代码仓库时，用户面临一个问题：如何存储环境变量，以便所有服务和脚本都能读取和使用。在这个问题中涉及的一些工具有 Ansible、PowerShell、Bash 等等。
用户当前的解决方案是使用简单的文本文件，为每个环境手动创建一个。每一行包含一个变量，服务和脚本可以查找这些变量。然而，这种方式显得有些笨拙，因为在每个脚本中都必须创建读取这个文件的逻辑。
用户的问题是，应该采取什么方法来为所有服务提供环境变量？他是否走在了正确的道路上，或者应该使用完全不同的方法？
他并不清楚如何为不同的工具提供这些变量。需要强调的是，他不是在谈论秘密管理，而是指像环境的 DNS 地址、日志服务器地址等这样的变量。由于环境的敏感性，添加新的软件或工具存在一些重要的限制。例如，他曾考虑使用 JSON 格式的环境文件，但是 Bash 并不原生解析它。这意味着他需要安装一个第三方工具，比如 ‘jq’，来使用这种格式。
欢迎任何反馈。谢谢！
解决方案
请注意以下操作注意版本差异及修改前做好备份。
在存储代码仓库的环境变量时，有多种方法可以选择，具体取决于你的工具、流程和约束条件。下面是一些解决方案的示例：
使用 Bash 脚本文件
你可以创建一个 Bash 脚本文件，其中包含你的环境变量设置，并将其放在代码仓库中。然后在需要使用这些变量的地方，通过 source 命令来加载这个脚本文件。这样的好处是，你只需要在脚本中加载一次，所有的服务和脚本都可以共享这些变量。
#!/bin/bash
export DNS_ADDRESS="your_dns_address"
export LOG_SERVER_ADDRESS="your_log_server_address"
# 添加其他环境变量
使用版本控制工具
将环境变量文件存储在代码仓库中，这样所有开发者和脚本都可以访问。你可以使用不同的文件格式，比如 .env 文件、.json 文件等。这样的好处是，环境变量与代码一起维护，方便版本控制和协作。
# .env 文件示例
DNS_ADDRESS=your_dns_address
LOG_SERVER_ADDRESS=your_log_server_address
利用持续集成/持续交付工具
许多 CI/CD 工具都支持在构建和部署过程中设置环境变量。例如，GitLab CI 和 GitHub Actions 都提供了设置环境变量的功能，你可以在构建和部署流程中使用这些变量，而不需要手动管理文件。
# GitLab CI 配置文件示例
stages:
- build
- deploy
variables:
DNS_ADDRESS: your_dns_address
LOG_SERVER_ADDRESS: your_log_server_address
build_job:
stage: build
script:
- echo "Building..."
deploy_job:
stage: deploy
script:
- echo "Deploying to environment"
使用容器化技术
如果你的应用程序使用 Docker 进行部署，你可以在容器运行时将环境变量传递给容器。这样，你可以通过 Docker 的环境变量机制来管理和传递这些变量。
# Dockerfile 示例
FROM your_base_image
ENV DNS_ADDRESS=your_dns_address
ENV LOG_SERVER_ADDRESS=your_log_server_address
# 添加其他环境变量和应用程序配置
不同的解决方案适用于不同的情况，你可以根据你的需求和约束条件选择最合适的方法。无论你选择哪种方法，确保在代码仓库中对环境变量的处理要统一和规范，以便于团队的协作和维护。
参考链接
请根据你的实际情况选择并结合上述方法，以确保代码仓库中的环境变量能够得到适当的管理和使用。