Puppet的多站点高可用性选项

我维护着两个数据中心，并且随着我们越来越多的重要基础架构开始受到puppet的控制，如果我们的主站点发生故障，第二个站点上的puppet master工作非常重要。

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

有多站点木偶高可用性的任何标准方法吗？

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

但是，如果在丢失主站点后又能正常丧失某些功能，那么让许多活动部件在多主设备环境中工作是非常可行的。

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

模块和清单

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

证书颁发机构

这里的一种选择是简单地在主机之间同步证书颁发机构文件，以便所有共享相同的根证书并能够对证书进行签名。这一直使我感到“做错了”。

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

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

因此，剩下的就是拥有一个中央CA管理员。当CA关闭时，所有信任关系仍然有效，因为所有客户端和其他主服务器都缓存CA证书和CRL（尽管它们没有按应有的频率刷新CRL），但是您将无法签名新证书，直到您可以备份主站点，或者从故障转移站点的备份还原CA主服务器。

您将选择一个主机充当CA，并让所有其他主机禁用它：

[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所有代理中设置config选项

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的最令人信服的理由。假设您想将节点指向“任何其他正常工作的主人”。

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

在3.0中，您可以使用SRV记录。给您所有的客户；

[main]
    use_srv_records = true
    srv_domain = example.com

然后，大师不需要任何特殊证书-只需在SRVRR中添加新记录就可以了_x-puppet._tcp.example.com，这是该组中的实时大师。更好的是，您可以轻松地使主选择逻辑更加复杂。通过SRV为不同的站点设置不同的记录集，“任何工作的主管，但更喜欢您站点中的那个” ；没有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在恢复新节点的证书之前对其进行签名，那么它就可以正常工作-尽管它真的很好如果这些组件中的一些对分发更友好。

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

在我们的案例中，由于radmind的性质，我们只需要将rsync经过批准的主服务器的成绩单和数据文件发送到每个远程站点的radmind服务器，客户端就可以使用短主机名将其更新从服务器中拉出radmind（通过这种方式的神奇之处resolv.conf在于radmind.[sitename].mycompany.com-总是本地radmind服务器。如果本地服务器已关闭，则可以很容易地覆盖并指向任何其他站点的服务器。

这种rsync流程也可能会在您的情况下工作，但是与基于版本控制的解决方案相比，它可能不是最佳的。

对于puppet或Chef，基于版本控制的系统比简单的rsync更有意义，这有几个原因-最大的原因是您是版本控制的puppet脚本（而不是像radmind那样完整的操作系统映像）。
作为基于版本控制的管理的附加好处，您可以让多个人一次在存储库上工作（为并行而战），您基本上可以免费获得修订历史记录，而且如果有人破坏了Puppet环境，您可以轻松回滚（假设您是重新使用git您还可以git blame做到锡盒上的含义）。
创意的分支和合并甚至可以让您在版本控制框架内处理主要的OS升级或其他过渡-一旦正确完成，只需切换到新分支，（希望）进行生产即可。

如果我在这里实现了这一点，我可能会利用git中的pre-commit和post-commit钩子来确保提交的人偶配置是健全的（客户端的pre），如果它们被推送到Universe的其余部分，是（服务器端发布-如果您的部署策略允许此类行为，则可能还会触发环境更新）。

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

Brain Tree Payments的人们显然已经将版本控制和rsync解决方案与一些自定义的Capistrano任务结合在一起 -他们的解决方案似乎半生半熟，因为它仍然依赖于手动工作流程元素，但是无需进行调整和自动化即可太多工作。
我中偏执的强迫性测试员对他们的noop健全性检查步骤很满意-我讨厌手动过程的人希望对此有一定程度的自动化...