配置同步

自动化配置工具（例如 CFEngine、Puppet 或 Chef）允许您通过提供描述服务器元素配置的方案来避免 雪花服务器。配置同步会在整个生命周期内定期或在配置更改时将这些规范应用于服务器实例。如果有人在工具外部更改了服务器，则会在下次同步服务器时将其恢复为集中指定的配置。如果需要进行某些配置更改，则在配置规范（方案、清单或特定配置工具的任何称呼）中进行更改，然后将其应用于基础架构中的所有相关服务器。

理论上，一旦创建了服务器，配置同步就会使其保持最新状态，应用升级和补丁，并在其潜在的较长生命周期内防止 配置漂移。

然而，在实践中，使用当前的自动化配置管理工具无法完全保持服务器的一致性，因此随着时间的推移，配置同步会导致不一致。[1]

由自动化工具管理的服务器配置的每个元素都需要编写、测试和维护方案或清单。尝试使用这些工具管理典型服务器的每个元素是不合理的。它们太多了。对于您指定的每个附加元素，由于它们之间潜在的交互、集成和依赖关系，所涉及的工作量呈非线性增长。

软件包是一个特殊的挑战，因为它们可能依赖于更多的软件包。yum、apt-get、gems 等工具会自动计算依赖关系并从存储库中安装它们。因此，系统上的大量软件包只是隐式管理的，并且可能会在没有通知的情况下发生更改。尽管您可以微观管理已安装软件包的版本和依赖关系，但考虑到所涉及的软件包数量，这是一项棘手的工作。

如果管理您想要在服务器上拥有的东西很困难，那么管理您不想要的东西就更糟了，因为它们的数量实际上是无限的。当前的配置管理工具要求您明确列出要删除的每个文件、包或其他元素（如果找到）。这意味着可以在某些服务器上手动添加其他内容，从而导致不一致和意外的行为。

实际上，使用自动化配置工具的人们在没有指定服务器 100% 可配置表面积的情况下也能很好地完成工作。团队将 80/20 规则应用于自动化配置，将 80%（或更像是 95%）的注意力集中在定义与他们特定需求最相关的 20%（或 5%）的系统上，而将其余部分留给基本操作系统安装的默认值。因此，系统的大部分内容都不在自动化配置之下，而且通常情况下，这是可行的。不幸的是，当它不起作用时——当自动化工具未管理的系统某些部分确实导致问题时，其影响是意外的，并且可能难以追踪。

这个问题会随着服务器寿命的延长和变化频率的增加而变得更加严重。服务器运行的时间越长，它与其他服务器（尤其是较新的服务器）的偏差就越大。

这个问题导致一些人使用 凤凰服务器。通过确保服务器的生命周期保持较短，并经常从基本映像重建新的服务器，可以将配置漂移的可能性保持在较小的范围内，而无需在管理工具中指定比实际需要更多的服务器配置。将凤凰服务器推向其逻辑结论会导致 不可变服务器，这可以避免在其生命周期内对服务器进行任何更改。