自动化验证是关键——它涉及运行测试，将您的实际环境与您定义的环境进行比较。
译自 The Engineer's Guide to Controlling Configuration Drift，作者 Saqib Jan。
配置漂移，即系统由于一些无伤大雅的错误或补丁而逐渐偏离其预期状态的微妙而危险的现象，可能导致轻微的故障，让用户感到沮丧，也可能导致严重的停机，从而瘫痪业务运营。
这通常是由于看似无害的手动更改造成的——随着时间的推移而累积的未记录的调整。即使在管理良好的环境中，手动基础设施操作通常也是不可避免的，从而留下差异。虽然Terraform、Ansible和AWS Config等配置管理工具可以帮助减轻漂移，但它们无法消除它，因为它也源于人和流程。
这种逐渐偏离已知良好配置——配置漂移——可能导致一系列问题，从不可预测的应用程序行为和性能瓶颈到明显的安全漏洞。
“防止配置漂移是可扩展、弹性基础设施的基石，”LambdaTest（一个提供即时基础设施的基于云的测试平台）的首席技术官评论道。“大规模情况下，即使是很小的不一致也会迅速演变成主要的运营效率低下。随着基础设施规模扩大以满足不断增长的需求，我们遇到了这些挑战[用户面临的影响]。直接解决这一挑战不仅仅是维护秩序；而是确保技术的基石是可靠的。因此，通过将基础设施作为代码并自动化合规性，我们在LambdaTest确保每个服务器、服务和设置都与我们的增长目标保持一致，无论我们扩展的速度有多快。
采用漂移检测和修复策略对于维护弹性基础设施至关重要。我转向著名的工程领导者，他们分享了他们解决配置漂移挑战的经验和最佳实践。他们的见解为在复杂环境中实施有效的策略来预防、检测和修复漂移提供了路线图。
DevOps 对直接与机器通信的需求日益增长，使团队和运营能够使用共享语言协作和管理系统，并消除不必要的过于复杂的接口层。
减少复杂性的趋势——远离不必要的复杂性——IaC 允许通过直接面向机器的代码来配置、部署和管理基础设施。
Bhola 分享道：“我们使用 Terraform 和 Ansible 等工具将我们的环境定义和管理为代码。这使我们能够一致地配置和配置环境，从而降低配置漂移的风险。并且对环境配置的更改是版本控制的，确保所有环境保持一致。”
像 Terraform、CloudFormation 或 ARM 模板之类的工具允许您在代码中定义服务器、网络、数据库和其他资源。然后对这段代码进行版本控制，存储在存储库中，并像组织中的任何其他代码一样进行审查和测试。
说：“最初，我们所有的环境都是通过带有大量手动干预的脚本来配置的。”“为了解决这个问题，我们将近 90% 的基础设施引入了 Terraform。现在，我们已经开始使用由 Git 支持的 Terraform 来配置我们的开发环境，其中环境的基础设施配置是版本控制的。我们最近也开始探索 Pulumi，它提供了更大的灵活性，因为它允许我们使用主要的例如 Python 和 JavaScript 等编程语言编写 IaC。我们利用 Helm 来管理我们应用程序在 Kubernetes 上部署 的 99% 的资源。这使我们能够有效地管理多个开发和生产环境中的配置，所有内容都存储在 Git 中，以确保一致性并最大限度地减少配置漂移。”
“好处，”Bhola评论道，他凭借在LambdaTest的执行权限，“不胜枚举：可重复性、降低人为错误的风险、清晰的变更历史记录，以及能够在需要时轻松回滚到之前的配置。”但是，“实施IaC是一场文化变革，”他强调，“与其说是一项技术变革，不如说是一场文化变革。”这需要组织的认可，并承诺将基础设施视为软件开发生命周期中的一等公民。
我们可以用代码定义我们的基础设施并编写其规则。Splunk（思科公司）的高级DevOps工程师Sandeep Kampa认为，“PaC适用于应用程序和基础设施层面。”
在应用程序层面，如果您有一个需要登录密码或管理用户访问权限的应用程序，这些策略有助于维护安全性和可审计性。您可以控制用户帐户、定义访问级别和设置密码规则。“任何不在策略范围内的内容都应经过身份验证，”Kampa强烈建议。“这确保您的应用程序（无论是网络应用程序、移动应用程序还是其他任何应用程序）保持安全。同样的原则也适用于SaaS提供商和云环境。使用AWS、GCP或Azure的组织通常有管理对云资源访问权限的策略；实施这些针对多云的策略有助于维护安全，防止过度配置权限。
您在基础设施层面设置的策略，例如SSH访问策略，为您的基础设施增加了另一层安全保护。Ansible允许您定义策略，例如删除root访问权限、更改默认SSH端口和设置用户命令权限。“很容易看到谁有访问权限以及他们可以执行什么操作，”Kampa评论道。“这确保了弹性基础设施，保持安全，并允许您在出现问题时跟踪谁做了什么。”
Ansible提供了一种强大的方法来自动化这些基础设施级别的策略。从管理员的角度来看，可以在Ansible中实现代码即策略以增强安全性。虽然存在许多强制工具，但Ansible的YAML配置定义了SSH访问的权限和策略，从而强化了系统并增强了基础设施安全性。
有趣的是，“自动化是使用Ansible进行策略强制执行的关键优势，”LambdaTest的高级DevOps领导者Shahid Ali Khan说。“一旦定义了策略，就可以同时将其应用于众多用户和服务器，无需人工干预。这种方法，”他强调，“是可重用、可扩展、自动化的和一致的，允许在所有环境（开发、测试、登台、UAT、生产）中强制执行相同的策略，而维护开销最小。”
“Open Policy Agent和Rego是开发适用于任何自动化和基础设施工具（包括Ansible Automation Platform和Red Hat OpenShift等系统）的策略的良好基线，”Red Hat杰出工程师兼首席Ansible架构师Matthew Jones说。“它们还允许您发展到更复杂的策略。”
您可以定义一项策略，要求对所有存储卷进行加密，或禁止使用默认密码。然后，这些策略会自动根据您的基础设施定义和部署进行检查。PaC提供了一种强大的方法，可以防止不符合规范的配置被部署，从而在问题变成问题之前发现潜在的问题。它还通过提供清晰的策略执行证据来简化审计。
想想所有您必须满足的那些繁琐的合规性要求——SOC 2、ISO 27001、PCI DSS，等等。代码即合规性将这些通常含糊不清的任务转化为可执行代码。这意味着您可以根据特定的合规性框架持续验证您的基础设施。一些工具可以帮助将合规性控制映射到特定的配置，并自动检查是否符合要求。
对于大多数组织来说，策略和合规性的发展相对较新，这就是利用开源技术作为IaC和自动化的基础的好处所在，因为这些工具正在快速成熟，并已成为工具架构的核心部分。“当您将高级自动化平台和Open Policy Agent结合起来时，您也离理想的代码即合规性解决方案非常接近，”Jones在我们的电子邮件采访中强调说，他推荐了Trestle，这是一个与它们一起工作的工具套件，用于管理合规性的开发和报告，遵循NIST的OSCAL格式。
这节省了审计过程中大量的時間和精力，并持续保证您的系统保持合规。它将合规性从被动的、一次性的活动转变为主动的、持续的过程。最终目标是确保一切符合组织层面设定的标准。
对关键考虑因素的概述：
- 组织环境：合规性要求受每个组织的特定行业、监管环境和内部政策的强烈影响。
- 量身定制的方法：虽然行业框架提供了一个良好的起点，但组织必须根据自身独特需求定制其合规性策略。
- 跨职能协作：不同的团队（例如，安全、销售、DevOps）可能具有不同的合规性需求，应通过协作和沟通来解决这些需求。
这有助于组织朝着更主动和自动化地满足其合规性要求的方向发展，无论这些要求如何在内部定义。通过将这些要求作为代码强制执行，组织可以显著降低配置漂移的风险。因为系统会根据定义的合规性策略自动进行检查，所以任何与期望状态的偏差都会很快被识别并得到纠正，从而维护更安全且合规的基础设施。
在该基础设施上运行的应用程序具有必须管理的复杂配置。考虑所有决定软件在不同环境中行为方式的设置、参数和依赖项。有效地管理这些配置可能是一个巨大的障碍。“我们面临着一些挑战，”Rajendiran（Kissflow公司）在描述他们的问题时分享道。他建议“将配置设置存储在版本控制的文件中，并确保定期在所有环境中一致地应用它们”。
Chef、Puppet、Ansible或SaltStack等工具允许您在整个应用程序环境中管理这些配置。您可以在代码中定义应用程序配置的期望状态，确保开发、登台和生产环境之间的一致性。这消除了“在我的机器上能运行”的问题（以及随之而来的听起来像坏掉的唱片的争论），并确保应用程序的行为可预测性，无论它们部署在哪里。
但是，至关重要的是，在使用秘密管理工具（如HashiCorp Vault或AWS Parameter Store）保护敏感数据安全的同时，要对动态变量使用特定于环境的模板。“对于高级漂移预防，不变的基础设施是可行的——服务器在部署后不会被修改；而是每次更改都会启动一个新的实例，”Khan（LambdaTest公司）指出。有效地实施不变的基础设施还涉及使用像Docker这样的容器化平台和像Kubernetes这样的编排工具来标准化和简化部署。他补充道：“在尽早发现漂移方面，像Driftctl和Terraform内置的漂移检测工具有助于在配置更改成为更大的问题之前发现它们。”
在存储方面，务必解决应用程序数据的存储方式和位置。例如，如果您的Web应用程序涉及用户交互（例如表单提交或下载），您希望以结构化格式在安全数据库中捕获每个操作。如果您使用云存储（例如S3存储桶），Khan建议采取必要的预防措施，例如：
- 访问控制：确保存储不可公开访问。实施适当的访问控制，仅限授权用户和服务访问。
- 版本控制：启用云存储的版本控制。如有必要，这允许您回滚到以前的版本，为意外删除或修改提供安全保障。
- 数据安全：切勿以明文形式存储敏感数据。对静态数据和传输中的敏感数据进行加密。处理高度敏感数据时，请使用AES-256等强大的加密方法。考虑使用专用的密钥管理系统来安全地管理您的加密密钥。
- 定期备份：虽然版本控制至关重要，但请将应用程序数据定期备份到单独的安全位置，以防止在重大中断或灾难中数据丢失。
正确管理应用程序的存储，包括访问控制、版本控制和加密，对于维护数据完整性、安全性和合规性至关重要。
即使是简单的清单，也能确保在手动操作过程中不会忽略关键步骤。但这不仅仅是拥有一个清单——更重要的是将其视为一个随着流程发展而不断演变的动态文档。“清单应该进行版本控制、审查和定期更新，以反映技术和工作流程的变化，”Khan 鼓励道。“它们是组织运营知识的一部分，有助于确保即使是复杂的程序也能始终如一、准确地执行。”即使在高度自动化的世界中，一些手动任务仍然会出现——尤其是在迁移或独特的、一次性操作期间。
然而，配置清单中经常被忽视的一个要素是验证步骤。“仅仅遵循步骤是不够的——你需要确认结果。添加配置后验证可以确保更改产生预期的效果，并防止问题未被察觉地蔓延到生产环境中，”Khan 说。“尽可能自动化验证过程的部分内容可以进一步提高可靠性并减少人为错误。”
定义明确的配置清单提供了一种结构化的方法，可以防止错误并最大限度地降低风险。在我们的谈话中，Khan 敦促为这些清单分配明确的所有权：“明确的所有权有助于避免歧义并确保问责制。当每个人都知道谁负责更新和审查时，流程运行就会顺利，错误也会更少。”
在团队的敏捷工作流程中使用清单非常有用，尤其是在软件更新或新功能方面。“定义整个流程，从最初的利益相关者请求到开发、测试和部署。”Kampa（来自 Splunk）建议将发布与既定的敏捷工作流程对齐，并补充道：“如果工作流程是预定义的并且一直在运行，基于您的敏捷[方法论]，确保您发布的任何内容，就谁在做什么、谁在部署、谁在验证、谁在批准以及谁在充当某种门控角色而言，都应该确保它与您的工作流程保持一致。”
定义明确的敏捷工作流程有助于识别瓶颈并简化发布流程。Kampa 解释说：“这样一来，就不会有任何混淆。例如，如果中间有什么东西坏了，您就知道工作流程在哪里坏了。清单是必不可少的，但应该是这个更广泛的工作流程的一部分。使用定期的每日站会和 sprint 回顾来讨论清单和整体工作流程改进。肯定应该有一个清单，但要确保它与您的工作流程一致，就像您业务的端到端工作流程一样。”
嵌入在配置文件或脚本中的硬编码凭据构成了重大的安全漏洞和配置漂移的常见原因。它们很容易被忽视，可能会错误地出现在公共存储库中，并且难以轮换。然而，一个强大的凭据管理系统——例如 HashiCorp Vault、AWS Secrets Manager 或 Azure Key Vault——可以直接解决这些问题。这些系统通常与您的身份提供商集成，允许您安全地存储、管理和访问密钥。
“凭据可以定期自动轮换，从而减少攻击者利用被泄露凭据的机会，”Khan 指出。必须严格控制访问权限，确保只有授权用户和服务才能检索特定密钥。这些系统通过允许对权限进行细粒度控制来强制执行最小权限原则，只为用户和应用程序提供处理必要凭据的功能。敏感信息不会直接暴露在配置中，从而降低了未经授权访问的风险，并防止了由过时或被泄露的凭据引起的漂移。
Khan 还指出，“敏感凭据应始终在静止状态下加密，并且仅在需要时解密”，并强调“需要定期轮换凭据”，这是凭据管理系统的关键优势。关于访问控制，他建议“通过将其与组织的身份管理系统集成并使用公司电子邮件身份验证来保护凭据存储”。这确保只有授权人员才能处理敏感凭据，从而增强安全性。
分散在多个系统和文件中的配置会造成管理噩梦并导致配置漂移。集中式配置管理系统为环境中的所有配置数据提供单一事实来源。它可以像一个专用的数据库那样简单，也可以像Consul、etcd或ZooKeeper这样的平台那样复杂。这些平台提供结构化、可靠的数据存储——通常使用键值存储或分层数据模型——以及强大的变更管理功能，包括版本历史记录、审计日志和审批工作流程。基于角色的访问控制 (RBAC) 通过限制谁可以修改或访问特定配置来增加安全层。许多系统还会将实时或近实时更新推送到连接的服务，并提供基于API的编程访问，以便无缝集成工具。
集中式系统使从一个地方轻松管理、更新和跟踪配置更改成为可能。它简化了故障排除，保持一致性，并提供所有修改的清晰审计跟踪。“一个关键优势，”Bhola指出，“是在跨环境（从开发到生产）管理配置时建立一致、可重复的过程。这种一致性对于维护基础设施稳定性和减少漂移至关重要。”
在构建集中式配置管理系统时，“可扩展性很重要，”Bhola进一步阐述，并进一步强调高可用性的重要性：“系统必须同时处理您当前的规模和未来配置量的增长。防止配置管理系统成为单点故障至关重要。”
集成也是关键，Bhola建议“与CI/CD管道、监控系统和自动化工具无缝连接，以实现流畅的工作流程。”模式设计也很重要，他强调“仔细组织配置数据可确保其易于理解和维护。”
除了这些功能性考虑之外，安全性也是另一个优先事项，Bhola强调需要“强大的加密、身份验证和授权机制来保护敏感的配置数据。”
集中式配置管理通过在可扩展性、高可用性、集成、模式设计和安全性方面的周全规划，减少漂移，提高一致性，并提高运营效率。
保持环境一致性可使部署保持顺畅并降低意外问题的风险。开发、登台和生产环境中配置的一致性是关键。虽然CPU和内存规格可能会根据需要而有所不同，但整体配置结构应保持不变——涵盖应用程序路径、用户访问权限、已安装的应用程序和补丁更新。
“应该很容易回滚或撤消更改，”Bhola强调。“如果配置一致，则无需返回并在每个环境中单独修改配置，除了规格。”
例如，如果您的登台环境使用8 GB内存，而生产环境使用16 GB内存，则再现生产问题只需要将登台环境中的内存调整为与生产环境匹配。无需更改整个配置，因为结构保持一致。唯一需要调整的是增加内存，从而更容易识别和解决问题，而无需进行重大更改。
保持跨环境的配置一致性还可以使故障排除更可预测。当环境发生漂移时，很难知道应用程序在生产环境中的行为。尽可能使用相同的配置、依赖项和相同的基础设施。这包括容器镜像、操作系统版本和网络设置。完美的parity可能并非总是可行，但减少差异可以减少意外并更快地解决问题。
对于希望更进一步的团队，临时环境——为每个新功能或分支创建的临时、短暂的环境——提供了一种保持环境一致性的有效解决方案。这些环境会自动配置和销毁，确保干净、一致的测试空间。
“通过保持一致性，您还可以最大限度地减少环境之间的配置漂移，”Bhola总结道，“使部署更稳定并减少运营方面的麻烦。”
谈到环境验证，仅仅设置好配置然后听天由命是不够的。您必须主动检查一切是否按预期运行。自动化验证在这里至关重要——它涉及运行测试，将您的实际环境与您定义的环境进行比较。通过将这些检查集成到您的CI/CD管道中，您可以立即获得反馈，无论何时出现任何偏差。尽早发现这些问题可以节省您日后很多麻烦。InSpec或ServerSpec之类的工具可以帮助您快速定义和运行这些测试。
为此，我们将继续进行审计和监控。您需要持续关注您的系统，以检测任何配置漂移。设置清晰的指标，以便了解何时出现问题，并使用监控工具跟踪文件、设置和应用程序的更改。警报有助于发现异常，但也不要忘记定期审计。无论是自动的还是手动的，这些审计都能确保一切仍然符合您的策略，发现任何未经授权的更改，并确认您的流程按预期运行。