引言

在复杂的云原生应用程序中管理配置信息是非常困难的，似乎到处都有配置。在使用基于微服务架构的云原生应用程序中，配置问题成倍增加。配置无处不在。有针对网络的配置，比如路由规则、端口控制、负载均衡，有针对数据库的配置，服务器的配置，还有众多微服务中间件的配置，以及各种相关的安全配置。

一些配置项是已知的并且很好的在一些版本控制系统中管理着，但是也有很多的配置，是零散存储，并且缺乏管理的。

如何控制并降低与云原生环境中大量配置信息相关的复杂性？这里有五种最佳实践，可帮助您处理混乱的配置。

1. 为所有配置保留单一可信来源

配置有些时候会被复制到各处。将一台服务器中使用的配置复制到另一台服务器，然后再复制到另一台服务器。最终，可能会有数百个相同或几乎相同的配置副本。对一个副本的更改不会影响到其他副本的风险很高。随着时间的推移，配置会发生漂移，导致配置错误、应用程序故障甚至安全漏洞。

相反，对于每种类型的配置信息（例如特定类型的配置文件），保留一份配置的主副本。这个单一的主副本是对配置进行所有更改的地方。然后，如果不同位置需要此配置，通过自动化工具将配置推送到目标位置。

此最佳实践使所有相同的配置保持一致，并确保对一个配置所做的必要更改适用于所有副本。

2. 使用自动化的方式来执行变更

在之前的最佳实践中，对于某些配置文件，它们的配置在所有设备上几乎相同。有时，每个配置副本都需要进行小的更改。

与其为每个组件保留一个单独的、唯一的配置副本，不如使用一个副本并使用宏和变量自动对每个组件进行更改。

例如，考虑一个特定的云安全策略，该策略需要规则中的服务器 IP 地址副本。配置在多个用例中几乎相同。但是该规则包含一个 IP 地址，该地址会随着用例的不同而变化。不要创建许多配置，而是使用包含 IP 地址的变量创建一个配置。部署安全策略时，在每个用例中将变量替换为正确的 IP 地址。

这种自动化将确保以完全相同的方式维护类似的配置文件，并且不会在每次使用配置时发生变化漂移。

3.使用版本控制

几乎所有配置最终都可以作为简单的文本文件进行管理。将这些文本文件放入您的版本控制系统（例如 Git）。然后，当您需要部署配置更改时，从版本控制系统中获取适当的版本。

这种做法将保留对配置的所有更改的历史记录；进行更改时，可以记录更改人和更改原因。

这在出现问题时会很有帮助。如果系统突然开始出现异常行为，对版本控制系统进行简单检查就可以了解配置最近发生了哪些变化。这些更改，如果发生错误，可以回滚或分析以查看它们导致问题的原因并更快地修复。

4.集中化配置管理

作为先前最佳实践的必然结果，将所有配置集中在一个众所周知的位置。使用版本控制系统来管理您的配置使这更容易做到。通过集中配置，您永远不必猜测指定组件的“主”配置存在于何处。它们在出现问题的情况下很容易审查，如果配置文件的位置是可管理的，使用和扩展会更容易。当需要增加新的配置文件时，如果其他配置都在同一位置，则遵循上述最佳实践会更容易。这减少了出于方便而使用未跟踪配置的可能性，并确保每个人都遵循最佳实践并保持问责制。