我发现我经常为许多客户设置几乎相同的服务器和VPS，这可能非常耗时。通常，每个部署之间唯一发生变化的就是要提供服务的不同网站。是否有一种简单的方法可以自动完成所有这些工作，并采取无聊的单调方式来设置56个相同的服务器？
到目前为止，我已经部署的服务器仅是Ubuntu，但我可能开始使用其他Linux操作系统甚至Windows。到目前为止，我已经看过Capistrano，但它似乎只专注于编写小红宝石程序来完成这项工作，而且我一点也不了解
Answers:
Puppet听起来很适合您想要做的事情，但需要注意的是，到目前为止，不支持Windows。
对于您的情况，您将根据所有机器上相同的所有软件包定义一个Server节点。然后，将各个主机定义为从Server继承的节点，并为其设置特定的唯一事物。
木偶是声明性的-它使您可以根据每个盒子应具有的资源来描述盒子。因此，如果您愿意ssh-您可以为该资源编写一个类-并且可以在类内部包含有关FreeBSD与Ubuntu上ssh调用方式略有不同的逻辑。它还知道yum在Redhat和apt-get基于Debian的发行版以及portsBSD中使用。现在在“服务器”节点中，您将看到类似include ssh- 的一行，并且puppet将做正确的事情并将SSH放在计算机上，而无需记住这是Ubuntu，Redhat还是FreeBSD。
很好的是，所有Server内容都存放在一个地方-如果在任何时候添加到Server节点定义中，所有机器都会相应地更新其配置。
现在，我只使用Puppet管理三个盒子-但是已经兑现了。在花了一个星期的时间设置好一个盒子之后，我们将在实验中使用它来进行激励演示，结果发现显卡驱动程序在我安装的Ubuntu版本（8.04）中太旧了。我必须安装最新的Ubuntu（9.04），但此后，我不得不apt-get并运行puppet-并恢复了我花了一周的时间才能完成的所有工作。
Puppet确实有一些学习曲线，但是我已经成功地避免了学习Ruby-我知道我正在使用它，因为这就是Puppet编写的内容-但到目前为止，我已经成功地修改了其中的示例维基上的文档和食谱。另一个缺点是，pet第一次做事情确实需要更长的时间。好处是，您在所有计算机上更改的所有内容都存储在一个地方-这是将木偶配置保留在版本控制系统中的标准做法-因此，您始终可以回头看看过去如何设置服务器-或回滚一些不成功的更改。
我们使用Cobbler和Puppet进行真实和虚拟机的构建和配置自动化。
Cobbler将DHCP，PXE引导和Kickstart连接在一起，使部署仅需添加计算机配置文件并单击电源按钮即可。对于VM，该koan
命令执行Xen magic（在我们的示例中）以开始安装-在dom0我刚键入的内容上：
koan --system vps.fqdn --server cobbler --no-gfx
然后virsh console观看没有任何交互作用的VPS建筑。
我们使用RHEL并设置了一堆配置文件来分区磁盘，配置网络并为不同的服务器类安装基本软件包。Cobbler支持Debian和Ubuntu版本，但我从未尝试过。撇开：Cobbler的其他有趣用途包括运行memtest ISO和HP固件更新。
使用Cobbler构建我们的系统后，Puppet将接管配置应用程序，系统守护程序，向RHN注册框等。Puppet作为守护程序运行，该守护程序会定期检查系统配置是否与定义的清单匹配-您知道更新已经完成所有服务器。在您将要维修的盒子恢复正常使用之前，这也是一种确保其正确配置的好方法。
木偶真的很棒。您不需要将配置的所有方面都置于其控制之下-首先，让它管理一些您需要在每个框上进行配置的简单操作（这sudoers是典型示例），然后从那里进行配置。确保您的人偶清单也已版本化；没有比记住要调整的内容容易地回滚到已知良好配置更好的了。
目前我在哪里工作，我们必须管理服务器场的Linux部分，该部分只有300多个Linux服务器。其中主要包括HP Proliants，其次是IBM 3850，一些IBM刀片服务器，VMware ESX和一些用于我们内部管理服务器的KVM。
我们看过补鞋匠，但是问题在于补鞋匠是RHEL / Red Hat特有的。我们至少需要支持RHEL和SLES，然后是Ubuntu。
我们确实考虑过p，但是后来决定反对它，因为它取决于Ruby，这意味着Ruby的升级可能会破坏我们的管理系统。
Hotwire是我们使用的（内部开发，但是开源的），并且在过去几年中一直在使用。它首先盘点将要构建的系统，这意味着盘点数据中心，机架，硬件，操作系统，网络等，其次执行快速构建和部署。构建系统后，hotwire的自动库存将使库存保持同步，而cfengine会维护它们。Hotwire通过python-dmidecode与Bios中的SMBIOS / DMI数据进行对话，从而了解服务器硬件。
优点是，它将库存和构建过程合二为一，因此管理的工作量更少，而且实时库存功能非常有用，因为我们知道某些事情不太正确。
缺点是用户界面仍然需要完善，并且到处都有错误，但是开发仍然很热，并且报告的错误相对较快地修复了。
我们使用cfengine是因为除了它之外，还有puppet，没有别的。它实际上是一个很好的工具，但是“好的”仅取决于您的策略的优劣-如果您设置了危险策略，那么一个小错误就会造成很多损害。例如，根据政策，我们不“修改”文件，或者替换它们，或者不这样做。同样，所有替换的文件都有一个标头，任何编辑它的人都知道在下次运行时它将被替换（通过cron每小时运行一次）。
cfengine推送到服务器的配置和所有文件也保存在SCM中，并使用提交后挂钩，如果可能，我们检查语法，如果失败，则拒绝提交。这对于不错的应用程序（例如Apache）很容易，但是对于大多数企业应用程序则不那么容易。
我在Puppet上取得了成功。 厨师是一个新兴的厨师。有关选项的更多列表和比较表，请参阅Wikipedia文章“ 开源配置管理软件比较”。
在此再次投票给Puppet。我们广泛使用它来执行所有服务器和应用程序的安装以及配置管理。200多个节点并在计数。Windows支持显然正在开发中，尽管我不确定是什么状态。
我们仍在研究操作系统的初始引导方面，但如上所述，Cobbler看起来很有趣。目前，我们在混合使用PXE引导和Debian / Ubuntu进行预播，但这并不是最佳选择。