配置管理：基于推与拉的拓扑

更加成熟的配置管理（CM）系统（例如Puppet和Chef）使用基于拉的方法：客户端定期轮询集中式主服务器以获取更新。他们中的一些人也提供了一种无主的方法（因此，基于推送），但指出它不是“用于生产”（Saltstack）或“可伸缩性较差”（Puppet）。我从一开始就知道的唯一基于推送的系统是亚军Ansible。

基于拉式系统的特定可伸缩性优势是什么？为什么增加更多的pull-master比push-agent更容易？

例如，agiletesting.blogspot.nl写道：

在“拉”系统中，客户端彼此独立地联系服务器，因此与“推”系统相比，整个系统可扩展性更高

另一方面，Rackspace展示了他们可以使用基于推送的模型处理15K系统。

infastructures.org写道：

我们发誓使用诸如SUP，CVSup，rsync服务器或cfengine之类的工具来维护基础结构的拉方法。而不是将更改推送给客户端，每个单独的客户端计算机都需要负责在启动时轮询金牌服务器，然后在以后定期维护自己的转速级别。在采用这种观点之前，我们基于ssh，rsh，rcp和rdist开发了广泛的基于推式的脚本。我们发现使用r命令（或ssh）的问题是：当运行基于r命令的脚本将更改推送到目标计算机时，很奇怪的是，如果您拥有30台以上的目标主机，则其中的一台将在任何给定时间出现故障。维护调试机器列表成为噩梦。在编写代码以对此进行更正的过程中，您将最终得到详尽的包装器代码来处理：死主机超时；记录并重试已死的主机；分叉并运行并行作业，以尝试在合理的时间内击中许多主机；最后，检测并防止用尽所有出站rsh会话的源计算机上的所有可用TCP套接字的情况。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。分叉并运行并行作业，以尝试在合理的时间内击中许多主机；最后，检测并防止用尽所有出站rsh会话的源计算机上的所有可用TCP套接字的情况。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。分叉并运行并行作业，以尝试在合理的时间内击中许多主机；最后，检测并防止用尽所有出站rsh会话的源计算机上的所有可用TCP套接字的情况。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。最后，检测并防止用尽所有出站rsh会话的源计算机上的所有可用TCP套接字的情况。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。最后，检测并防止用尽所有出站rsh会话的源计算机上的所有可用TCP套接字的情况。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。然后，您仍然有一个问题，就是要为将来要安装的所有新主机将自己所做的任何事情放入安装映像中，并对要死掉而明天必须重建的任何主机重复执行此操作。在经历了实现基于r命令的复制的麻烦之后，我们发现这是不值得的。我们不打算再次使用r命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。或与此相关的任何其他推送机制。它们不像基于拉的方法那样可扩展。或与此相关的任何其他推送机制。它们不像基于拉的方法那样可扩展。

这不是实现问题，而是架构问题吗？为什么编写一个线程化的推送客户端比一个线程化的推送服务器更难？

基于推送的系统的问题在于，您必须在中央推送节点上拥有整个体系结构的完整模型。您不能将机器推到不知道的地方。

它显然可以工作，但是要使其保持同步需要大量的工作。

使用Mcollective之类的东西，您可以将Puppet和其他CM转换为基于推送的系统。通常，将拉式系统转换为基于推式系统很简单，但以其他方式进行操作并不总是那么容易。

还有组织政治的问题。基于推送的系统将所有控制权交给了中央管理员。这样很难管理复杂性。我认为扩展问题是一个红鲱鱼，如果仅查看客户数量，则两种方法都会扩展。在许多方面，推送更容易扩展。但是，动态配置或多或少地暗示您至少具有客户端注册的请求版本。

最终，它是关于哪个系统匹配您组织中的工作流程和所有权。通常，拉动系统更为灵活。

如果任何人都感兴趣，我想至少可以给用户体验报告，因为它在任务关键型系统的多主机设置的补丁程序管理中首次使用了Ansible的开箱即用推送功能在亚马逊云中。为了理解我的先入之见或偏见，我应该解释一下，我在自动化脚本级别上偏爱Ruby，并且过去已将项目设置为对每个项目Vpc使用主代理人偶配置。所以我的经验掩盖了过去的偏见，如果有的话。

我最近的经验非常有利于动态推入从数十台服务器转变为数百台服务器的不断变化的产业，这些服务器可以按比例放大或缩小，终止和刷新。在我的情况下，制作补丁所需的只是一个简单的Ansible 1.7 ad hoc命令。但是，鉴于为此目的在每个Vpc上设置AnsibleController（在t2.micro上）的有效性，将来我打算将技术扩展到更复杂的要求。

因此，让我回到这个话题中提出的问题：推动动态变化的房地产的利弊。

我针对的服务器资源类型的假设是：

• 不能假设IP地址或Amazon生成的本地主机名将持续很长时间-它们可以来去去
• 所有实例都是从机器映像创建的，该机器映像已经能够从单个特权管理用户进行ssh访问
• 要根据功能或开发阶段（例如测试或生产）将服务器个性化，并可能将它们分为几类，可以通过启动商定的常规名称的特定亚马逊标签来完成
• 我将使用不同的临时命令分别对Linux和Windows服务器进行补丁管理，因此在与Windows服务器联系时仅允许Linux特定的登录失败

考虑到这些条件，创建AnsibleController的机器映像以放入多个Vpc并在现有服务器帐户中就地进行配置（使用凭据）非常简单。从图像创建的每个实例中自动执行的是

1. 一项cron作业，用于定期将补丁推送到运行中的服务器，以便定期访问所需资源
2. 在每个这样的时间间隔计算Ansible库存的方法。

如果需要，可以使第二项相对复杂（通过Ansible库存的Info结构）。但是，如果不需要复杂性，这是一个非常简单的脚本示例，可以在每个cron间隔计算所有Amazon EC2实例，并将结果定向到适当的清单文件（例如/ etc / ansible / hosts）中……

#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute 
# path, to which the list is written

function list-of-ips {
    /usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk  '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
 }

if [ -n "$1" ]; then
   list-of-ips > "$1"
else
   list-of-ips
fi

该用例的唯一警告是patch命令应该是幂等的。理想的是进行预测试以确保完全满足要求，这是确保补丁完全符合预期目的的一部分。

综上所述，我已经说明了一个用例，其中动态推送可以有效地实现我设定的目标。这是一个可重复的解决方案（从封装在映像中的意义上讲，可以在多个帐户和区域中推广）。到目前为止，根据我的经验，动态推送技术比目前提供给我们的工具集中的替代方法更容易提供和付诸实践。