六个月前，在我们的非营利项目中，我们决定开始将系统管理迁移到 Puppet 控制的环境，因为我们预计从现在到一年后我们的服务器数量将大幅增长。
自从做出决定后，我们的 IT 人员就变得有点过于恼火了。他们最大的反对意见是：
我可以理解为什么大型组织会派遣他们的系统管理员参加 Puppet 课程以成为 Puppet 大师。但是，如果小玩家不参加课程并且基本上通过浏览器和编辑器学习它，他们如何将 Puppet 学习到专业水平？
Puppet 和 Chef 工具的新功能。似乎他们正在做的工作可以用 shell 脚本来完成。也许它是在 shell 脚本中完成的，直到这些出现。
我同意它们更具可读性。但是，除了可读性之外，是否还有其他优于 shell 脚本的优点？
“我们可以将现有的生产 EL5 服务器升级到 EL6 吗？”
来自环境完全不同的两个客户的一个听起来简单的请求促使我通常的最佳实践回答“是的，但它需要协调重建您的所有系统”......
两位客户都认为，出于停机时间和资源原因，完全重建他们的系统是不可接受的选择... ……”
我不是要引出关于配置管理的回应（“Puppetize一切”并不总是适用）或客户应该如何更好地计划。这是环境在生产能力中不断发展壮大的一个真实示例，但没有看到迁移到其操作系统下一个版本的干净路径。
环境 A：
非营利组织，拥有40 个 Red Hat Enterprise Linux 5.4 和 5.5 Web、数据库服务器和邮件服务器，运行 Java Web 应用程序堆栈、软件负载平衡器和 Postgres 数据库。所有系统都在不同位置的两个 VMWare vSphere 集群上进行虚拟化，每个集群都具有 HA、DRS 等。
环境 B：
高频金融交易公司，在多个托管设施中配备200 x CentOS 5.x系统，运行生产交易业务，支持内部开发和后台功能。交易服务器在裸机商品服务器硬件上运行。他们有许多sysctl.conf，rtctl，中断到位约束力和驱动程序的调整，以降低消息传送等待时间。有些具有自定义和/或实时内核。开发人员工作站也运行类似版本的 CentOS。
在这两种情况下，环境都按原样运行良好。升级的愿望来自对 EL6 中可用的更新应用程序或功能的需求。
两者都不能在不彻底改变操作系统的情况下轻松打包或更新。
作为系统工程师，我很欣赏红帽建议在主要版本之间移动时进行完全重建。一个干净的开始迫使你重构并在此过程中注意配置。
对客户的业务需求很敏感，我想知道为什么这需要如此繁重的任务。RPM 打包系统不仅能够处理就地升级，但它是让您/boot受益的小细节：需要更多空间、新的默认文件系统、RPM 可能会在升级过程中中断、已弃用和已失效的软件包......
这里的答案是什么？其他发行版（基于 .deb、Arch 和 Gentoo）似乎具有这种能力或更好的途径。假设我们找到了以正确方式完成此任务的停机时间：
我正在通过一般的配置管理学习我的方法，特别是使用puppet来实现它，我想知道系统的哪些方面（如果有的话）不应该用 puppet 管理？
例如，在将系统借给 puppet 的管理之前，我们通常认为主机名已经设置是理所当然的。基本的 IP 连接，至少在用于联系 puppetmaster 的网络上，必须正常工作。使用 puppet 自动创建 dns 区域文件很诱人，但 DNS 反向指针应该在启动之前就已经到位，否则证书会很有趣。
那么我应该从 puppet 中省略 IP 配置吗？或者我应该在第一次启动 puppet 之前设置它但仍然使用 puppet 管理 IP 地址？具有多个 IP 的系统（例如，用于 WAN、LAN 和 SAN）会怎样？
IPMI怎么样？您可以使用ipmitool配置大部分（如果不是全部），从而避免获得控制台访问（物理、串行网络、远程 KVM 等），因此可以使用 puppet 进行自动化。但是在每次 puppet agent 运行时重新检查它的状态对我来说听起来并不酷，而且在做任何其他事情之前我希望对系统进行基本的熄灯访问。
另一个完整的故事是关于安装更新。我不打算讨论这个具体问题，已经有很多关于 SF 的问题以及不同系统管理员之间的许多不同哲学。我自己，我决定不让傀儡更新的东西（如只ensure => installed），并因为我们已经习惯了做手工更新，离开这个任务的自动化到以后的一天，当我们与木偶（如更加自信。通过增加MCollective到混合）。
这些只是我现在想到的几个例子。系统的任何方面是否应该被人偶接触到？或者，换一种说法，应该在配置时设置什么和系统中“静态”配置的内容与通过集中配置管理处理的内容之间的界限在哪里？
我正在使用 puppet 来管理一组 debian 服务器。我需要更改集群上每台机器的时区。执行此操作的正确 debian 方法是使用dpkg-reconfigure tzdata. 但是如果我使用对话框，我似乎只能改变它。有什么方法可以从 shell 自动执行此操作，以便我可以编写一个 Exec 来简化此操作？
如果没有，我认为下一个最好的方法可能是让 puppet 分发/etc/timezone并/etc/localtime在整个集群中使用正确的数据。
任何输入表示赞赏！
我已经用谷歌搜索并阅读了“to-puppet-or-to-chef-that-is-the-question”文章。
我对用例感兴趣，在现实世界的实现中，人们根据实际问题选择了一个或另一个。
我对与 cobbler问题的集成特别感兴趣（我知道 puppet 是这个方向的标准方法）；作为任何人在鞋匠 - 厨师整合方面的任何经验？
提前致谢
我正在考虑推出一种新的配置管理工具来取代我们自己开发的解决方案。事实上的标准是 Chef 和 Puppet，它们都是以 Ruby 为中心的（尽管显然可以用于部署非 Ruby 环境）。我们绝大多数的开发都是用 Python 完成的，我们的内部部署工具大量使用Fabric。因此，我正在学习Salt，因为它也是 Python，尽管它不如 Chef 或 Puppet 成熟。但由于我对这些选项不够熟悉，我发现很难进行比较。
除了较小的社区之外，我会通过使用 Salt 而不是 Puppet/Chef 来放弃任何重要的东西吗？
我发布这个问题已经六个月了。尽管它已关闭，但它已被观看了 1,000 多次，所以我想我会评论我的经历。
我最终决定使用 Puppet，因为它有一个更大的社区。然而，这是一次非常令人沮丧的经历，主要是由于复杂的 Puppet 配置语法。因为我现在有了比较两者的参考框架，所以我最近又看了看 Salt——我不会回去了。非常非常酷。我最喜欢的东西：
推和拉配置模型的无缝集成。Puppet 使用拉模型（节点定期轮询服务器以获取更新）并有一个名为 Marionette 的姊妹组件用于推送更改。两者对我都很重要，我更喜欢 Salt 的工作原理。当你有很多节点时，Salt 的执行速度也会快得多。
配置语法使用 YAML，它只是一种使用缩进和项目符号的简单文本格式。您也可以通过模板选择使用其他配置格式。根据我的经验，这使 Salt 的学习和维护难度提高了大约 10 倍。
基于Python。这是我最初开始研究 Salt 的最大原因。这最终成为我留下来的次要原因之一。但是，如果您是像我们这样的 Python 商店，则可以更轻松地开发 Salt 插件。
puppet agent从新图像进行调用时，出现err: Could not find class custommod错误。该模块本身/etc/puppet/modules/custommod与我们正在调用的所有其他模块相同，但这个模块是顽固的。
[网站.pp]
node /clunod-wk\d+\.sub\.example\.local/ {
include base
include curl
include custommod
class{ "custommod::apps": frontend => "false}
[...]
}
当 puppetmaster 以调试输出运行时，它清楚地找到了 base 和 curl 的信息：
debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production
debug: Automatically imported base from base into production
debug: importing '/etc/puppet/modules/curl/manifests/init.pp' in environment production
debug: Automatically imported curl from curl into production
err: Could not find class custommod for clunod-wk0130.sub.example.local at /etc/puppet/manifests/site.pp:84 on node clunod-wk0130.sub.example.local
第 84 行是 …
我打算用厨师或傀儡来做管理（我更多地考虑厨师，因为它更年轻，我对它有更好的感觉）。
在两个主页上我都看到有一个“企业版”要花钱，我不打算购买任何东西。如果我不买厨师/木偶，我会错过什么？
大厨提供什么东西要花钱？
Puppet 提供什么需要花钱的产品？
我从他们的网站上看不太清楚，因为它有点晦涩。
在我的组织中，我与一群 NOC 员工、初出茅庐的初级工程师和少数高级工程师一起工作；所有这些都专注于 Linux。公司培养人才的一个有趣步骤是，有一条从 NOC 到高级工程队伍的途径。将人才库视为一个相对较新的人，我发现随着时间的推移，技能组合存在分歧……
一些员工之间的一个区别因素是他们对脚本、自动化和配置管理方法的接受程度。例如，我们有两名工程师负责 Amazon AWS CloudFormation的大部分工作，另一名负责处理大部分Puppet基础设施。也许四分之一的工程师精通 BASH shell 脚本。
在就业市场对DevOps 技能的需求非常高的背景下，我很好奇其他组织如何促进这些技能的发展并培养他们的内部人才。脚本编写似乎不是一个特别可教的概念。