外部化应用配置的新开发者指南

# Web 开发 # AI # DevOps # 云计算

您刚刚完成了第一个可用于生产的应用程序的构建。版本 0.1.0 在您的本地机器上运行良好，您已准备好将其部署到 AWS、Azure 或 Google Cloud。但在准备部署时，出现了一个关键问题：您应该如何在不同的环境中处理应用程序的配置？

配置挑战

“一次构建，随处部署”

让我们从现实场景开始。您的应用的数据库连接可能如下所示：

// How most apps start
const config = {
  dbUser: 'admin',
  dbPassword: 'secret123',  // Works locally, but...
  dbHost: 'localhost'
};

这在您的笔记本电脑上工作正常。但准备阶段需要不同的凭据，而生产阶段还需要另一套凭据。您可能想直接修改代码，添加特定于环境的值。这些方法很常见，并且可以在较小规模下很好地工作。

了解配置依赖关系

随着时间推移，随着应用的增长，在代码中管理特定于环境的值会变得复杂。存在意外推送错误凭据或创建难以扩展的配置的风险。外部化配置提供了一种简化此过程的方法，同时保持灵活性和安全性。

将配置移出你的代码

外部化配置意味着从代码库中提取敏感值并在运行时管理它们：

// The better way
const config = {
  dbUser: process.env.DB_USER,
  dbPassword: process.env.DB_PASSWORD,
  dbHost: process.env.DB_HOST
};

配置管理云工具

云平台提供 AWS Secrets Manager、Azure Key Vault 和 Google Cloud Secret Manager 等工具就是为了实现这一目的。这些服务是从 Mitchell Hashimoto 于 2015 年率先推出的 Vault 模式发展而来的，用于存储和加密您的配置。

每个环境（开发、准备、生产）都有自己的凭据，确保清晰分离和轻松管理。当您的应用运行时，它会动态检索这些值，让相同的代码可以在任何地方无缝运行。

现代架构中的配置

在 Kubernetes 或 Amazon ECS 等容器化环境中，配置通常作为环境变量注入或作为文件挂载。您的应用每次启动时都会使用新值 — 无需重建。

AWS Lambda 或 Azure Functions 等无服务器应用程序的工作方式略有不同。由于没有持久环境，这些应用程序直接从安全存储中获取配置。例如，Lambda 函数可能会在运行时查询 AWS Secrets Manager，确保它始终具有正确的配置。

外部配置的好处

通过将配置与代码分离，您可以获得灵活性和安全性。您的应用变得可移植，能够轻松地在不同环境之间移动。敏感值保持安全，存储在代码库之外并在传输过程中加密。

最重要的是，这种方法简化了您的部署过程。不再需要为不同的环境创建单独的分支。不再需要对敏感值进行硬编码。更新变得无缝，环境保持一致。

为增长而建设

到目前为止，您使用的方法（硬编码值、特定于环境的变量或分支）可能对您很有帮助。外部化配置不会取代这些想法；它以它们为基础，提供一种可扩展的方式来管理随着应用的增长而增长的配置。

0.1.0 版本只是一个开始。通过外部化配置，您可以确保您的应用为接下来的一切做好准备，无论是跨区域扩展还是适应新环境。

采取下一步行动

准备好改进应用的配置管理了吗？从一项服务开始，将其配置移至环境变量。在每个环境中进行全面测试。记录您的新模式。与您的团队分享您的经验。

您正在应对哪些配置挑战？我很乐意在下面的评论中听到您的建议。

Mike Vincent 是一位美国软件工程师和技术作家，现居加利福尼亚州洛杉矶。他负责设计云平台并撰写有关基础设施技术的文章。他的工作重点是 AI 解决方案、平台架构和软件开发。

在 LinkedIn、Medium、Hashnode 和 Dev.to 上阅读 Mike Vincent 的更多故事。

CLIS.CC