引言

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

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

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

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

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

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

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

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

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

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

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

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

3.使用版本控制

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

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

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

4.集中化配置管理

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

5.使用自动化系统分发配置信息

您的配置应该使用自动化系统进行部署，就像您的软件部署方式一样。 使用 CI/CD 管道是现代云原生应用程序的标准策略，部署管道应部署所有配置以及所有代码。 如上所述，这可以实现变量的一致应用和对宏的更改，并确保所有更改都部署在需要配置的所有组件中。 自动化可确保管理大量配置的一致性和责任制。

总结

配置即资产。配置与代码一样有价值，不正确的更改可能对您的应用程序同样危险。 您应该按照对源代码应用的相同级别来对待您的配置。

通过使用由版本控制跟踪并自动部署的共享、集中、模板化配置，您将降低现代云原生应用程序固有的配置复杂性。

关于 HummerRisk

HummerRisk 是开源的云原生安全平台，以非侵入的方式解决云原生的安全和治理问题，核心能力包括混合云的安全治理和 K8S 容器云安全检测。

Github 地址：https://github.com/HummerRisk/HummerRisk

Gitee 地址：https://gitee.com/hummercloud/HummerRisk