使用 Puppet 实现多站点高可用性的选项

Question

我维护着两个数据中心，随着我们越来越多的重要基础设施开始通过 puppet 进行控制，如果我们的主站点出现故障，puppet master 在第二个站点上工作很重要。

更好的是进行某种主动/主动设置，以便第二个站点的服务器不会通过 WAN 轮询。

是否有任何标准的多站点 puppet 高可用性方法？

Answer 1

Puppet 实际上非常适合多主机环境，但需要注意。主要的？ Puppet 的很多部分都喜欢集中化。 证书颁发机构、清单和仪表板/报告服务、文件存储和存储配置——所有这些都在（或只是需要）一个只有一个地方供他们交谈的设置中处于最佳状态。

但是，如果您在失去主站点时对某些功能的正常丢失感到满意，那么让许多这些活动部件在多主环境中工作是非常可行的。

让我们从基本功能开始，让节点向主节点报告：

模块和清单

这部分很简单。版本控制它们。如果它是分布式版本控制系统，则只需集中和同步，并根据需要在故障转移站点中更改推/拉流程。如果它是 Subversion，那么您可能希望svnsync将存储库复制到您的故障转移站点。

证书颁发机构

这里的一种选择是简单地在主服务器之间同步证书颁发机构文件，以便所有人共享相同的根证书并能够签署证书。这一直让我觉得“做错了”；

• 一个主人真的应该看到它自己的证书在客户端身份验证中提供，用于来自另一个主人的传入连接是有效的吗？
• 这对库存服务、仪表板等是否可靠？
• 您如何添加其他有效的 DNS 替代名称？

我不能诚实地说我已经对这个选项进行了彻底的测试，因为它看起来很可怕。但是，根据此处的说明，Puppet Labs 似乎并不鼓励这种选择。

所以，剩下的就是拥有一个中央 CA 主控。当 CA 关闭时，所有信任关系仍然有效，因为所有客户端和其他主服务器都会缓存 CA 证书和 CRL（尽管它们不会像应有的那样经常刷新 CRL），但是您将无法签署新证书，直到您可以备份主站点或从故障转移站点的备份中恢复 CA 主站点。

您将选择一个 master 作为 CA，并让所有其他 master 禁用它：

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

然后，您会希望中央系统获得所有与证书相关的流量。对此有几种选择；

1. 使用SRV3.0 中的新记录支持将所有代理节点指向 CA 的正确位置 -_x-puppet-ca._tcp.example.com
2. ca_server在puppet.conf所有代理中设置配置选项

3. 将 CA 相关请求的所有流量代理到正确的主服务器上。例如，如果您通过 Passenger 在 Apache 中运行所有主服务器，则在非 CA 上进行配置：

   SSLProxyEngine On
   # Proxy on to the CA.
   ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
   # Caveat: /certificate_revocation_list requires authentication by default,
   # which will be lost when proxying. You'll want to alter your CA's auth.conf
   # to allow those requests from any device; the CRL isn't sensitive.
   

而且，应该这样做。

在我们进入辅助服务之前，请注意：

主证书的 DNS 名称

我认为这是迁移到 3.0 的最令人信服的理由。假设您想将一个节点指向“任何 ol'working master”。

在 2.7 下，您需要一个通用的 DNS 名称，如puppet.example.com，并且所有的主人都需要在他们的证书中使用它。这意味着dns_alt_names在他们的配置中进行设置，重新颁发他们在配置为 master 之前拥有的证书，当您需要将新的 DNS 名称添加到列表时再次重新颁发证书（例如，如果您想要多个 DNS 名称让代理商更喜欢他们网站上的主人）。丑陋。

使用 3.0，您可以使用SRV记录。给你所有的客户这个；

[main]
    use_srv_records = true
    srv_domain = example.com

然后，大师不需要特殊的证书 - 只需将新记录添加到您的SRVRR_x-puppet._tcp.example.com就可以了，它是组中的实时大师。更好的是，您可以轻松地使主选择逻辑更加复杂；通过SRV为不同的站点设置不同的记录集，“任何 ol' 工作大师，但更喜欢您站点中的那个” ；没有dns_alt_names必要的。

报告/仪表板

这个最集中，但如果您可以在主站点关闭时没有它，那么没问题。只需将您的所有母版配置为放置报告的正确位置即可。

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

..你已经准备好了。未能上传报告对于配置运行来说是非致命的；如果仪表板服务器的吐司，它只会丢失。

事实清单

粘在仪表板上的另一件好事是库存服务。按照文档中的建议facts_terminus设置rest为，这实际上会在中央库存服务关闭时中断配置运行。这里的技巧是inventory_service在非中央主节点上使用终端，这允许优雅的失败。

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

将中央库存服务器设置为通过 ActiveRecord 或 PuppetDB 存储库存数据，并且只要服务可用，它就应该保持最新。

所以 - 如果你可以接受一个相当准系统的配置管理环境，在那里你甚至不能使用 CA 来签署新节点的证书，直到它恢复，那么这可以正常工作 - 尽管它真的很好如果其中一些组件对分发更友好一些。

Answer 2

Ladadadada 描述的“无主傀儡”方法是我最熟悉的方法（这基本上是我们在我公司使用 radmind 所做的）。我猜更准确地说是“由外部进程同步的多个主服务器”，任何给定的服务器都可以（理论上）在紧急情况下为我们的整个宇宙服务。

在我们的例子中，由于 radmind 的性质，我们只是rsync将副本和数据文件从批准的主服务器发送到每个远程站点的 radmind 服务器，并且客户端从具有短主机名的服务器中提取更新radmind（通过这种神奇的resolv.conf计算结果radmind.[sitename].mycompany.com- 总是本地radmind 服务器。如果本地服务器关闭，则很容易覆盖并指向任何其他站点的服务器）。

这种 rsync 过程可能也适用于您的情况，但与基于版本控制的解决方案相比，它可能不是最佳选择。

对于 puppet 或 Chef 而言，基于版本控制的系统比简单的 rsync 更有意义，原因有几个 - 最大的原因是您正在版本控制 puppet 脚本（而不是像使用 radmind 那样控制整个操作系统映像）。
作为基于版本控制的管理的额外好处，您可以让多人同时在存储库上工作（并行性的巨大胜利），您基本上免费获得修订历史，如果有人破坏了 Puppet 环境，您可以轻松回滚（假设您是重新使用git你也有git blame它在锡上说的那样）。
创造性的分支和合并甚至可以让您在版本控制框架内处理主要的操作系统升级或其他转换——一旦你做对了，只需切换到新的分支，并且（希望）生产推送将正常工作。

如果我在这里实现这个，我可能会利用 git 中的 pre-commit 和 post-commit 钩子来确保提交的 puppet 配置是健全的（客户端预）并将它们推送到宇宙的其余部分是（服务器端帖子——如果您的部署策略允许这种行为，也可能触发环境更新）。

就在每个站点启动新的 puppetmaster 服务器而言，您可以简单地检查每个远程 puppetmaster 的 puppet 环境，并使用我上面描述的 resolv.conf/hostname 黑客或重定向到 Michuelnik 建议的本地系统的任播服务 IP（如果您希望在一个站点的 puppetmaster 发生故障时自动进行故障转移，后者会很方便）以确保每个站点都能看到“正确的” puppetmaster 并且不会阻塞试图获取更新的 WAN 链接。

Brain Tree Payments 的人显然已经将版本控制和 rsync 解决方案与一些自定义 Capistrano 任务结合起来——他们的解决方案似乎是半生不熟的，因为它仍然依赖于手动工作流元素，但它可以在没有太多工作。
我心中的偏执强迫性测试者喜欢他们的noop健全性检查步骤——我讨厌手动过程，希望围绕它实现某种程度的自动化......