什么时候适合使用配置管理器（例如Puppet / Chef / Ansible）？

在我目前的工作场所中，我负责管理两台VMware主机，一台OpenBSD物理机，三台Debian VM和六台Windows Server VM（2008/2012年）。

我正在考虑实施配置管理工具，例如Puppet或Chef。这是否合理，还是学习该工具的开销会超过收益？可管理性和实施成本之间的转折点在哪里？

恕我直言，即使您只管理一台服务器，也值得学习

是的，会有学习曲线。是的，您会感到沮丧。但是，对于这些费用，您将通过可靠，一致，一键式部署，版本控制的服务器配置，易于设置测试/开发环境等方式获得多倍的回报。

除了为您当前的工作带来好处之外，能够在您的履历表中添加CM系统是一大胜利。现在，如果不熟练，现在有望使现代系统管理员至少接触配置管理系统。

（旁注：还考虑使用Ansible。这是我首选的CM，并且很容易启动和运行-比Puppet或Chef更容易。此外，Ansible中的Windows支持也很不错。）

我正在考虑实施配置管理工具，例如Puppet或Chef。这是否合理，还是学习该工具的开销会超过收益？

合理的选择取决于您需要消耗多少时间和金钱，以及是否要消耗金钱。

配置管理工具（其中的任何一种）正在成为当今市场上的一项宝贵技能。

从业务或环境的角度来看，花时间学习和实施CM工具可能不是最有效的方法，但从您的技能上来说可能是值得的。

可管理性和实施成本之间的转折点在哪里？

大多数配置管理工具是免费提供的，但有一个警告，即它们很难安装和使用。

这个问题很难回答，因为它实际上取决于您日常管理这些服务器的工作。如果您根本不需要做很多事情，那么配置管理工具可能完全是过头了。

如果您真的只需要将基础架构强制为可预测的基本状态，那么使用SaltStack或Ansible之类的基础知识可能不会造成太大危害。

根据我的个人经验，Salt很容易上手并引导到服务器上，并且可以用于非常基本的远程执行和报告，如果您尚未在环境中实现它，则可能会派上用场。

请记住，我有偏见。您应该自己评估每个CM工具。

就像@EEAA所说的-服务器数量无关紧要。您可以在单台计算机上使用配置管理来获得好处：

• 记录的设置（通过CM脚本记录）
• 可靠的部署（您可以一次又一次地[重新]部署您的设置
• 设置的弹性（当前的服务器崩溃了-升级一个新的）
• 重用（当您拥有第二台服务器时-您已经可以从第一台服务器回收CM脚本）
• 升级（有点像新设置，只是在另一个平台上）

我可以说，由于我不经常在那里工作，所以必须为所有个人服务器实施CM，而忘记了所有小细节。同时拥有CM脚本似乎很耗时（确实）的回报很值得。从长远来看，您将节省更多的时间来进行设置。

我有Puppet和Ansible的经验。Ansible是IMO的简化程序，而Puppet是声明性程序。两者都有优点和缺点，但是由于Puppet的隐秘错误，我已经拔了不少毛。

如果要创建干净且可重用的配置，两者都需要大量工作。如果您至少有两个非常相似的服务器（例如云或群集），那么这些成本就开始真正得到回报。

但是，它甚至对于独立服务器也有一些用途-您可以设置管理员用户，标准（具有本地变体）的sshd，后缀或snmpd配置，还可以将它们用于简单的信息收集，例如遵守策略或测试Shellshock漏洞。

另外，如EEAA所述，如果您验证安装程序确实将服务器从基本状态转换为运行状态，则它具有记录安装程序的值。最好将它与版本控制系统（git）结合使用，以便对所做的更改进行版本控制并记录下来。如果您有一个管理员团队，那将非常有价值。

人偶或任何其他管理系统都带来了巨大的好处，所有其他答案在此处都突出显示了这些好处，但是在管理方面没有灵丹妙药。

例如，为复杂系统创建人偶类会花费大量时间和精力，有时会因为很多陷阱而流泪，并且错误消息并不总是100％清晰，并且在软件升级时，您必须花费时间调整人偶类以适应任何新规范或程序，并找出最适合该方法的方法（例如，声明式的人偶，而升级通常是程序性的）

另外，您还需要弄清楚如何计划以受控方式推出对类所做的更改，以及如何维护清单的不同版本。

您还应该考虑在需要时如何升级管理解决方案。

如果您花费大量时间来编写诸如人偶类之类的东西，那么您必须执行大量的一键式安装才能获得真正的好处。

我建议仍然在适当的地方进行探索，即分发配置文件是一个很好的起点，然后从那里开始。