配置管理SaaS平台Config开始内部Beta测试啦

Posted 2021-04-28 细说云计算

作者｜Richard Seroter

译者｜谢丽

Config 是一个新的管理配置文件的 SaaS 服务。该服务由 Bien David 在 2017 年创建，旨在简化团队存储和访问由系统、App、模块、环境和服务器实例使用的配置信息。为了进一步了解 Config 解决的问题，InfoQ 采访了其背后的团队。

Config 平台既可以在公有环境中运行，也可以在私有环境中运行，支持存储在 INI、XML、JSON、YAML、TOML 配置文件中的属性。它包括版本控制、变更审查工作流、搜索以及持续集成 & 部署支持等功能。

Config 目前处于内部 Beta 测试阶段，包括多个定价方案。如果客户想增加用户，或者使用类似 webhook 通知、本地支持这样的特性，或者希望单个系统支持更多的 App，则价格会相应增加。

现如今配置管理面临什么挑战？该服务如何与团队当前使用的解决方案一起使用？为了找出这些问题的答案，InfoQ 采访了 Bien David。

InfoQ：在配置文件管理方面，开发人员和系统管理员面临的主要挑战是什么？

David：要我说，主要问题是如何轻松地管理所有环境的配置文件。我说的不是各服务器上相同的配置文件，那些文件可以作为服务器镜像或 rsync'd 的一部分。我说的是因环境而变化的配置文件，如应用程序从开发环境进入生产环境。

不过，我的这种回答并不完善，因为这个问题取决于你的工作岗位和工作职责。所以，让我更详细地说一下程序员、系统管理员和管理者所面临的问题。

  程序员

如果有一个应用程序需要部署到多个环境（本地、开发、QA、过渡、生产）和多个实例上（集群、区域等），那么问题就是如何确保一切保持同步。如何添加一个所有服务器上都使用的配置项？如何新增一个特定于环境的配置项？与此相关的问题是，配置文件存储在哪里。

当程序员开始一个新的应用程序，尤其是使用一个不熟悉的框架时，配置会经过一定的生命周期，这部分是因为配置不属于优先考虑事项。最开始的时候，值是硬编码的，然后变成常量，然后转移到配置文件中，再然后就是转移到外部配置文件或者系统环境变量中。环境覆写或者转换成集中式配置意味着配置文件的最终成熟。

但是，即使是在这个成熟阶段，也没有一种简单或者标准的方式管理这些因环境而异的配置，仍然需要人工同步配置，仍然涉及特定于应用程序框架或配置库的编码。随着应用程序越来越多，使用的服务器越来越多，团队越来越大、越来越分散，问题只会越来越多。

  在哪里存储这些配置文件

可以把它们存储在服务器本地，或者作为源代码库的一部分，或者存储在一个单独的配置库中，再或者存储在一个中央配置服务器上。不管配置文件存在哪里，你都需要保证共用值和因环境而异的值都要正确地应用到主副本，并部署到正确的地方。不要忘了，有些公司会锁定过渡环境和生产环境，配置修改流程比较长。

  系统管理员

系统管理对配置文件问题的看法和程序员不同。首先，他们得管理 OS 和系统配置。他们需要轻松准备新的服务器和桌面，安装好标准的软件，并进行必要的环境配置或特定于服务的配置。

其次，他们需要考虑锁定环境里的应用程序配置文件。对于客户化的应用程序，通常意味着配置文件文档较少，而且没有在线帮助。在最好的情况下，应用程序开发者仍然是公司成员，还可以为他们提供指导。

  管理者

第三组很少讨论，就是技术经理，他们需要考虑的是保证生产服务器平稳运行。他们需要快速修复生产环境的问题，或者更好，防止问题出现。由于应用程序和服务器一样，至少在理想情况下如此，环境的差异就体现在配置上。当某个东西在一个环境里可以正常工作，但在其他环境里不行，这通常是其中一个需要检查的东西。

你是否遇到过这样的情况？技术经理焦头烂额，因为生产环境出问题了。他们想要查看配置和日志，但是无法访问。这是一个旧应用程序，原先的开发人员离开了，所以他们就找到了系统管理员。系统管理员不了解应用程序配置，因此，他们一起定位配置文件目录，和其他配置文件进行比较，使用可用的文档，弄清楚配置情况。应该有更好的方式。

InfoQ：有用户现在甚至都没意识到的问题吗？

David：需要程序员，包括我自己在内，都相信 YAGNI。没有一个标准的配置文件管理方案，我们将针对应用程序平台或者我们使用的框架采用一种简单直接的做法。配置文件通常不是优先事项，因此我们最终会有多种方法。在开发阶段，这很有效，但当项目成熟时就有问题了，我们必须管理多个服务器上的许多应用程序，每个都有自己的小怪癖。

对于系统管理员来说，配置管理是他们的主要工作职责之一， IaC 的流行就是证明。我认为，系统管理员知道问题，但有些被公司审批耽误了。

最后我要指出的是，转向可自由使用的应用程序和容器。如果你可以毫不费力地让一个新应用程序在一个新容器上运行，那么配置就成为你唯一需要担心的问题。这使得配置文件管理更为重要了。

InfoQ：在当前的解决方案中存在什么空白启发您创建了 Config？

David：好问题。我遇到一个配置文件问题，我没有找到可以直接解决这个问题的方案。Stack Overflow 上有一个时间很久的问题，但没有一个易于实现的答案。2017 年的博文也抱怨了同一个问题。我们处于 AI 的时代，而我这个相对简单的问题仍然存在。

那么，如何跨所有的环境管理所有的应用程序配置文件呢？现在有解决方案了，Config 填补了通过源代码控制系统存储配置文件和从中央配置服务器访问配置文件之间的空白。把 Config 看成是一个托管的源代码控制，有一个专门针对配置文件设计的、简单易用的 Web 界面。由于按需生成配置，所以它有部署时依赖，而没运行时开销，但有集中式运行时解决方案的优点。

手动 <-> 源代码控制 <-> Config <-> 微服务 <-> 集中式服务器 <-> IaC

我不会详细说明每一种的优缺点。不过，我将比较现有的解决方案和 Config。

  手动 vs Config

如果你有一个小型 App，而且将来也不会变大，它运行在一台或两台服务器上，手动操作是可行的。我能想到的使用 Config 的唯一理由是你有许多这种小型的应用程序。你可以把 Config 作为应用程序目录，那样你就可以有一个包含所有应用程序的总体视图以及相应配置文件的位置、值和文档。如果你的设置规模快速增长，那么手动操作就无法扩展了。

  源代码控制 vs Config

例如，将配置文件存储在 Git 上。我建议把配置文件和环境覆写存储在单独的库中。其他常用的方法包括：1）把配置模板作为需要客制化的源代码库的一部分；2）生产环境只在源代码库中配置；3）所有的配置文件，包括环境覆写，都存储在源代码库中。

Config 以环境变量为核心构建。如果你使用 Git，那么配置文件就是普通的文本文件，你仍然得手动管理环境差异，并实现代码（或者使用一个库）处理环境覆写。

Config 让你可以管理一个配置文件，新增应用到所有环境的公共键，或者遍历所有的环境，做特定于环境的修改。和 Git 一样，Config 有版本控制，你可以通过 pull 获取需要的配置。不过，Config 只会 pull 你所请求的环境的配置文件，按需生成恰当的配置。

和托管的 Git 相比，像 GitHub，Config 更好，因为配置文件总是私有的。你不会无意间让它成为一个公开库或者不费力地公开克隆。还有其他一些 Git（或 GitHub）中没有的特性，包括审核或审批工作流、闲时加密、推送部署和类型安全编辑。

  微服务 vs Config

其中一个例子是 Spring Cloud Config。如果你使用 Spring Boot，那么它很有效。虽然不完全特定于 Spring，但是你需要编写自己的客户端。在以下情况下，Config 更好。

你更愿意使用一种部署时解决方案，不用管理另一台服务器，不另外引入运行时依赖。你不希望修改代码或者找一种对使用配置文件的第三方应用程序也有效的解决方案。你正在寻找一个用户友好的界面来管理配置。

  集中式服务器 vs Config

这会用到类似 ZooKeeper 这样的东西。获得认同并让公司采用就完成了一半。如果公司已经在使用一个中央配置服务器，而你又有访问权限，那么这是可行的。

如果你想要支持使用配置文件的应用程序，并且不想编写中间脚本在文件和 KV 副本之间转换配置信息，那么 Config 更好。将配置文件从 Config 推送到 Git 或者中央配置服务器是我们路线图的一部分。这是 Config 补充现有解决方案的一个例子。

  IaC vs Config

这是像 Ansible 这样的配置管理。这里，我们更多地进入了系统管理员的领域。适用于系统准备和配置。如果你不管在本地开发机器上，还是在生产环境中，都希望采用同样的方式管理配置文件，则 Config 更好。

这当真是 Config 对现有解决方案的完善，而不是取代。Ansible 可以完成系统准备和配置方面的所有工作，在应用程序配置时，可以让 Ansible 从 Config 拉取配置文件。这和 Ansible 从 Git 拉取配置类似。

对于还还没有准备好上云的公司，Config 的主要缺点是，它是一项 SaaS 服务。我们通过提供本地方案来缓解这个问题。我们也会在云市场上提供这项服务，如 AWS 市场，以便你可以快速配置到自己的 VPC 上。

Config 的口号是“为管理所有服务器和环境的配置文件提供最简单的方式”。关键词是最简单。只要导入现有的配置文件，选择 push 或 pull 部署。遍历环境，比较环境变量，跨应用程序搜索。只需几分钟就可以设置好并运行我们的永久免费方案。

InfoQ：当源值发生变化，客户端的配置如何保持最新？是靠客户端自己发现（如缓存失效），还是由服务器通知？哪种做法好？

David：这包含两部分。部署配置和重新加载配置。

部署配置。我希望 Config 可以用到尽可能多的应用程序里。这就是说，我们必须成为部署时依赖。简单地讲，不用使用 vi 或 notepad 编辑配置文件，我们会帮你更新。那么我们是如何更新配置文件的呢？

我们有几种不同的方法，那取决于你的流程或者基础设施。最简单的是推送部署，用户可以从 Web 界面触发。我们使用 SCP 把配置文件复制到用户的服务器，因此，我们需要 SSH 访问权。它支持批量推送，一次可以处理多台服务器。另一个选项是手动拉取，和从 Git 上拉取文件类似。还有一个选项是自动拉取，就是简单地通过 cron 或任务调度器拉取。最后一个选项是手动导出 / 下载。

重新加载配置。配置文件到目标机器上之后，应用程序如何知道要重新加载配置文件？我们提供了几个选项，这些选项都需要应用程序本身的支持。在推送时，我们允许运行一段自定义脚本，让用户可以借此发送一条 SIGHUP 命令，至少可以用于支持这个命令的应用程序。还有一个选项是让应用程序从文件时间戳发现变化，并据此重新加载。

我们提供的最后一个选项是，用户在配置文件中嵌入一个 Config 时间戳变量。每次部署时，我们会更新配置文件里的时间戳。然后，应用程序可以定期检查时间戳属性是否有变化。和时间戳检测非常像，但这里检查的是配置值。

我的建议是支持 SIGHUP，但它并不适用于所有的应用程序，例如 Java，也并不适用于所有的操作系统，如 Windows。作为 SIGHUP 的替代方案，你可以在实现应用程序时让它可以接收一条命令，并在接到这条命令时按需重新加载配置。

InfoQ：那些已经在配置文件管理上有投入的企业如何利用 Config？是把它作为替代者引入？还是可以和那些已有的方案一起使用？

David：如果你的配置文件管理只是使用 Git 存储所有的配置文件和所有的变量覆写，那么 Config 是更好的解决方案。如果你已经将大多数 Git 操作自动化，那么你就可以让 Config 推送到 Git，而保持现有的流程不变。这样，你就可以快速上手，然后逐阶段过渡。

如果你有一个微服务解决方案，而你的微服务仍然需要从某个地方获取配置，那么这些配置可以来自 Config，而不是文件系统或源代码控制系统。

如果你有一个用着还满意的中央配置服务器，那么可以继续用。如果你搭配配置服务器使用了版本控制系统，那么 Config 可以成为那个版本控制系统。Config 可以进一步完善你的配置服务器，有的应用程序仅能使用文件或者无法很好地纳入 KV 存储的复杂配置，Config 为支持这类应用程序提供了一种简单的方法。

Config 完善了现有的配置管理解决方案。部分 IaC 脚本（manifest、playbook 等）将从 Config 获取配置文件，而不是文件系统或源代码控制系统。

InfoQ：把敏感的配置数据交给第三方需要信任。你们是如何着手构建这样一项提供必要防护的 SaaS 服务的？您能介绍下你们的架构吗？

David：谢谢你问我，因为这是个常见问题。最佳实践是敏感信息静态数据加密。这意味着不管配置文件是存在于内部网络、云服务器、公司笔记本、GitHub 上，还是在 Config 中，都不会有敏感数据暴露在外面。

不过，也很常见，敏感的配置信息没有加密，有些面向第三方应用程序的配置文件不在控制范围内，那不是一个在所有情况下都有效的解决方案。

为了帮助用户实现在配置文件中加密敏感值的理想方案，我们将提供资源 / 工具，让用户可以轻松地加密 / 解密值。可能这不是用户想要的，Config 还允许用户指定哪些配置值是敏感数据，我们会自动加密这些静态数据。

但这并不意味着用户在使用我们的搜索特性时这些值不会出现。对于那些还没有准备好使用云的公司，我们提供了本地方案。用户可以在内部网络或 VPC 中运行自己的 Config 实例。

对于这个敏感配置的问题，最佳解决方案是不要把它们放在配置文件中。这时候应该使用类似 Vault 这样的秘密管理解决方案。Config 的路线图上就有一部分是增加秘密管理服务器支持。Config 将从 Vault 获取敏感信息，并放进生成的配置文件中。这让现有的应用程序可以轻松地使用 Vault。

在架构方面，我们使用了 Docker on Linux。我们使用最低限度的 CentOS 服务器，每天更新。我们使用 nginx Docker 作为负载均衡器和 Web 服务器。我们使用 Java Docker 运行我们的后端 REST API。

我们使用 Postgres Docker 作为数据库。我们仅开放 App 需要的端口和容器之间通信需要的端口，数据库无法通过互联网访问。离线备份是加密的，有安全监控，我们还会定期进行安全测试。

InfoQ：我们经常听说因为配置没有恰当的上传到 GitHub 所导致的证书泄露。一般来说，您认为什么样的配置文件保健法好？

David：我在回答有关安全和信任的问题时提到过这个主题。让我总结下，并提供些建议。如果你需要在配置文件中存储敏感值，那么就在文件中把它们加密，并在应用程序中解密。类似 Jasypt for Java 这样的库可以提供帮助。

如果你想要使用一个托管的 Git 库，那么务必确保你使用的是一个私有库。就这个地方来说，Bitbucket 比 GitHub 好。Config 永远是私有的，因此，可以保证你的配置文件不会被意外公开曝光。最佳解决方案是把敏感配置从配置文件中拿出来，放到秘密管理服务器上。

给你一个爱学习的理由

现在注册极客时间App，立享30元新人红包，付费内容券后价低至19元起！

细说云计算  

「细说云计算」是 InfoQ 旗下关注云计算技术的垂直社群，投稿请发邮件到 [e-mail]，注明“细说云计算投稿”即可。