这是 Chef Fast Start 教程中推荐的方式：
knife ssh name:mynode -a ipaddress -x ubuntu -i mycredentials.pem "sudo chef-client"
这真的很笨拙。真的没有更好的方法，或者是在真实的生产环境中，您无论如何都会让节点自动更新？
总的来说，我对整个 Netflix OSS 堆栈和部署还很陌生。作为我目前的运维知识水平的背景，我的主要角色是前端应用工程师。但是，我喜欢事物的运营方面，因此我正在尝试为新项目设置新的部署策略和工具。
我们的目标
我们可以多花一点初始设置时间，如果这样做会在将来为我们省去一些麻烦。
因此，沿着这些思路，我一直在听播客、观看 Ops 演讲并阅读大量博客文章，并根据我们的目标以及我所采取的一些最佳实践，我们已经开始制定计划，使用Asgard，将我们的包滚动到 jar 中，然后将其滚动到 AMI 中。
我们已经计划好了这一切，并且喜欢该流程与使用 Chef 服务器和动态融合实例相比的优势（鉴于我们有限的时间线和对 Chef 服务器工作流程的缺乏了解，我们认为这很容易出错）。然而，一位同事自己环顾四周，觉得 Elastic Beanstalk 满足了我们的需求。
我已经研究过它并使用 WAR 文件和附加的 RDS 数据库启动了一个测试环境。事情似乎奏效了，我相信我们可以通过 AWS API 使用 Jenkins 自动部署到测试环境。看起来很简单……也许太简单了。
我想知道的是，有什么收获？如果 Elastic Beanstalk 如此简单有效，为什么没有更多地谈论它？我很难找到关于两种不同部署策略的足够客观的意见和事实，所以我想我会四处打听。
您使用 Elastic Beanstalk 吗？如果是这样，为什么以及哪些因素会导致该决定？你喜欢和不喜欢什么？
如果您不使用 Elastic Beanstalk 但考虑过它，您使用什么，为什么不使用 Elastic Beanstalk？
基于 Elastic Beanstalk 的 SOA 部署策略的优缺点是什么？也就是说，Elastic Beanstalk 是否可以与许多相互依赖才能工作的小型应用程序一起工作？
我的团队创作了大量厨师食谱。我想知道我应该研究哪些方法和框架，以便我们可以开始创建测试以确保我们的节点配置正确？
automated-testing testing configuration-management chef chef-solo
对于 mysql 使用大页面，我需要设置一个 ulimit - 我已经在limits.conf 中做到了这一点。但是，limits.conf (pam_limits.so) 不会为 init 读入，仅适用于“真实”shell。我之前通过向 initscript 启动函数添加“ulimit -l”解决了这个问题。我需要某种可重复的方法来做到这一点，现在这些盒子是由厨师管理的，我们不想接管实际上由 RPM 拥有的文件。
我喜欢使用“knife cloudstack server create ...”来构建一个新的VM。我的引导模板以“apt-get update”和“apt-get -y upgrade”开始。
升级然后停止：
10.190.113.11 Configuration file `/etc/nscd.conf'
10.190.113.11 ==> Modified (by you or by a script) since installation.
10.190.113.11 ==> Package distributor has shipped an updated version.
10.190.113.11 What would you like to do about it ? Your options are:
10.190.113.11 Y or I : install the package maintainer's version
10.190.113.11 N or O : keep your currently-installed version
10.190.113.11 D : show the differences between the versions
10.190.113.11 Z : start a shell …我在这里查找CFEngine、Puppet、Chef、bcfg2、AutomateIt以及其他任何可能存在的配置管理系统之间的一些比较，并且很惊讶我在 Server Fault 上发现的很少。例如，我只知道上面的前三个链接——另外两个是我在相关的谷歌搜索中找到的。
所以，我对人们认为最好的或者他们喜欢的不感兴趣。我想知道以下内容：
如果我有一个正在创建的模板，我如何确保该目录存在？例如：
template "#{node[:app][:deploy_to]}/#{node[:app][:name]}/shared/config/database.yml" do
source 'database.yml.erb'
owner node[:user][:username]
group node[:user][:username]
mode 0644
variables({
:environment => node[:app][:environment],
:adapter => node[:database][:adapter],
:database => node[:database][:name],
:username => node[:database][:username],
:password => node[:database][:password],
:host => node[:database][:host]
})
end
这失败了，因为/var/www/example/shared/config不存在database.yml要复制到。我在考虑 puppet 如何让您“确保”目录存在。
在我目前的工作场所，我负责管理两台 VMware 主机、一台 OpenBSD 物理机、三台 Debian 虚拟机和六台 Windows Server 虚拟机（2008/2012）。
我正在考虑实施配置管理工具，例如 Puppet 或 Chef。这是否合理，或者学习该工具的开销是否会超过收益？可管理性和实施成本之间的临界点在哪里？
我即将开始一个新项目，该项目在一定程度上需要部署大约三个不同类的许多相同节点：
所有节点都将在 Ubuntu 10.04 实例上运行，但它们将安装不同的软件包。
我从以前的项目中对 Chef 有一些熟悉，尽管我不认为自己是专家。为了进行尽职调查，我一直在研究其他可能性。我们内部有很多人是 Puppet 的长期用户，他们鼓励我去看看。
不过，我无法评估这两种选择。Chef 和 Puppet 共享许多相同的领域术语——包、资源、属性等等，它们有共同的历史，源于对同一问题采取不同的方法。所以在某种意义上，它们非常相似。但是我找到的很多比较信息，比如这篇文章，都有些过时了。
如果你今天开始这个项目，你会问自己什么问题来决定你应该使用 Chef 还是 Puppet 进行配置管理？（注：我不想要回答这个问题：“我应该用厨师或木偶？”）
厨师文档非常糟糕。谷歌没有帮助我。
任何人都可以给我指出一篇体面的文章或可以帮助我入门的东西吗？
我的具体问题是：