2

我们一直在使用 chef 进行部署，它非常适合简单的场景。但是，我们现在想在我们的 VM 基础架构上编写一个冗余架构。几个盒子聚集在一起，但过早运行厨师脚本会导致它们失败。例如，我们想配置一个 Windows 集群。服务器 1 可以配置故障转移集群功能，然后尝试形成集群，但由于服务器 2 尚未配置，因此运行将失败。

这应该怎么做？以下是我们提出的一些想法：

  1. 设计厨师运行，知道它们会失败，但在不断重新运行时最终会通过。
    • 从自动化的角度来看，这并不理想，因为反馈会变得模棱两可。运行是否以预期的方式失败，还是由于未知原因而失败？这可能需要一个人来设置它。

  2. 当配方在服务器 1 上运行时，从自定义配方调用“knife ssh”以配置服务器 2。例如：

    windows_feature "FailoverClusters" do
    action: install
end

# ensure server 2 has the cluster feature enabled 
# (this would likely be implemented as a LWRP using the  the Knife::Chef::Ssh class rather than the execute LWRP)
execute 'knife ssh "name:Server2" "recipe[windows_cluster::secondary]"'
    action :run
end

# join the second server to this cluster (semi-pseudo code)
windows_cluster 'server2' do
    action :join
end

  3. 或者，可以编写一个协调器脚本，以便它以正确的顺序调用“knife ssh”。该脚本将从构建机器或开发人员框中运行：

    # ensure the failover cluster feature is enabled on the secondary server
execute 'knife ssh "name:Server2" "recipe[windows_cluster::secondary]"'
    action :run
end

# install the failover cluster feature on the primary box and have it configure the cluster
execute 'knife ssh "name:Server1" "recipe[windows_cluster::primary]"'
    action :run
end

  4. 已经开发了一个不同的框架或技术来处理这个问题？

在这些解决方案中，我们正在走向 3（或 4，如果存在）。一般来说，这似乎是组织部署的最干净的方式，因为意图将存在于更高的抽象层中。

处理这些场景的最佳实践或常用方法是什么？

4

1 回答 1

1

我建议为此使用 Chef Search。这是合乎逻辑的工作流程。

  1. 在第一台服务器上运行 Chef，允许食谱在其主厨节点属性中将其设置为“主”
  2. 在所有其他服务器上运行 Chef，允许他们看到“master”

我称之为高级节点部署。首先部署一台服务器，然后再部署所有其他服务器。

食谱将包含搜索属性、根据结果查找或设置属性的代码。见下文：

myclusternodes = search(:node, "cluster_name:clusterb")

if myclusternodes != nil
  master = myclusternodes.count == 0 ? node[:ipaddress] : myclusternodes[0].ipaddress
end

node.set[:clusterb][:master] = master
于 2013-11-24T08:42:19.707 回答