OPS05-BP03 使用配置管理系统
使用配置管理系统来实现和跟踪配置更改。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。
静态配置管理在初始化资源时设置值，这些值预计在资源的生命周期内会保持一致。动态配置管理在初始化时设置值，这些值在资源的生命周期内可能或预计会发生变化。例如，可以设置功能切换，通过配置更改来激活代码中的功能，或者在意外事件发生期间更改日志详细信息级别。
配置应在已知且一致的状态下部署。应该使用自动化检查功能来持续监控跨环境和区域的资源配置。这些控制措施应定义为自动化代码和管理，从而确保在各个环境中始终如一地应用规则。配置更改应通过商定的更改控制程序进行更新，并一致地应用，从而遵守版本控制。应用程序配置应独立于应用程序和基础设施代码进行管理。这可实现在多个环境中进行一致的部署。配置更改不会导致重建或重新部署应用程序。
期望结果：可以作为持续集成、持续交付（CI/CD）管道的一部分进行配置、验证和部署。通过监控来验证配置是否正确。这样可以最大限度地减少对终端用户和客户的任何影响。
常见反模式：
-
手动更新整个实例集中的 Web 服务器配置，由于更新错误，许多服务器变得没有响应。
-
手动更新应用程序服务器实例集需要花费很长时间。在更改过程中，如果配置不一致会导致意外行为发生。
-
有人更新了安全组，Web 服务器变得无法访问。如果不知道进行了哪些更改，就需要花费大量时间来调查问题，导致恢复时间延长。
-
未经验证即通过 CI/CD 将预生产配置推送到生产环境中。让用户和客户接触到不正确的数据和服务。
建立此最佳实践的好处：采用配置管理系统可以减少更改及对其进行跟踪的工作量，还可以降低手动程序导致错误的频率。配置管理系统为治理、合规性和监管要求提供了保障。
在未建立这种最佳实践的情况下暴露的风险等级：中
实施指导
配置管理系统用于跟踪和实施对应用程序和环境配置的更改。配置管理系统还用于减少手动流程导致的错误，让配置更改可重复且可审核，并减少工作量。
在 AWS 上，可以使用 AWS Config 持续监控跨账户和区域的 AWS 资源配置。这有助于跟踪其配置历史记录，了解配置更改会如何影响其他资源，并使用 AWS Config 规则 和 AWS Config 合规包根据预期或期望的配置对其进行审查。
对于在 Amazon EC2 实例、AWS Lambda、容器、移动应用程序或 IoT 设备上运行的应用程序中的动态配置，可以使用 AWS AppConfig 在各环境中对其进行配置、验证、部署和监控。
实施步骤
-
确定配置负责人。
-
让配置负责人了解任何合规性、治理或监管需求。
-
-
确定配置项和可交付成果。
-
配置项是受 CI/CD 管道内的部署影响的所有应用程序和环境配置。
-
可交付成果包括成功标准、验证和要监控的内容。
-
-
根据业务要求和交付管道，选择配置管理工具。
-
考虑使用加权部署，例如用于重大配置更改的金丝雀部署，以便尽可能减少错误配置的影响。
-
将配置管理集成到 CI/CD 管道中。
-
验证推送的所有更改。
资源
相关最佳实践：
相关文档：
相关视频：
