Questions tagged «chef»

Chef是用于基础结构自动化的开源配置管理框架。


4
Vagrant,Docker,Chef和OpenStack(或类似产品)之间的关系?
我是一名Web开发人员,但我对一些管理任务也很感兴趣。因此,从纯管理到开发人员的新转变对我来说很方便。 无论如何,我有一些问题需要解决。也许没有,所以我想寻求帮助以进行澄清。 基本上,我想介绍的是四种类型的软件(据我了解)。确切的产品无关紧要,您可以放置​​任何类似的软件作为替代: 流浪汉:据我了解,是要自动创建和管理VM:设置,启动和停止它们。可以使用本地VM或远程(例如在云平台上)完成此操作。 Docker:基于一些Linux内核概念的“轻量级VM”,可用于独立运行进程,例如在共享Web托管环境中。 Chef:一种用于设置和配置操作系统(例如在VM内部)的工具。 OpenStack:一种工具,可让您构建自己的私有云,因此可与AWS之类的东西相媲美。 问题1:我的解释正确吗,还是我对其中某些(或全部)消费有误? 问题2:如何混合所有这些工具?那有意义吗? 根据我的想象和理解,您可以 使用OpenStack构建自己的云, 使用Vagrant来管理在云中运行的VM, 使用Chef设置这些VM 最后使用Docker在VM内部运行进程。 这个对吗?如果是这样,您能给我建议如何开始使用所有这些功能吗(同时很多,而且我还不知道从哪里开始)?

6
Puppet vs Chef,来自用户和用例的赞成与反对意见
我已经在Google上搜索并阅读了“到木偶或主厨这就是问题”一文。 我对用例,现实世界中的实现感兴趣,在现实世界中,人们根据实际问题选择了一个或另一个。 我对与补鞋匠问题的融合特别感兴趣(我知道p是这个方向上的一种标准方法);作为任何人在皮匠与厨师的融合方面有任何经验吗? 提前致谢

1
厨师最佳做法/问题
我使用并喜欢Puppet。我搬到一家新公司,他们正在招收厨师。所以我想学习厨师,但是很难将它们拼凑在一起,因为我仍然认为在Puppet =) 这些是我的问题: 在Ruby DSL,JSON或从管理控制台中设置角色更好吗?为什么有多种方法可以做同一件事? 您可以将食谱组织到子目录中吗?例如:我们有一些我想为其编写食谱的自定义软件,并将其粘贴到:chef-repo / cookbooks / ourcompanystuff / customsoftwarecookbook会是一个好习惯吗? 我是否为每种角色创建食谱,以指定其作用?我是否将这些食谱包括其他食谱(即,我的网络服务器角色的食谱包括apache食谱)?我不确定如何处理食谱的相互依赖性和继承性。 是否有类似Puppet的外部节点分类器之类的东西,以便节点自动确定其角色? 看来您可以使用Knife或在管理控制台中进行配置,或编辑JSON文件?这真让我感到困惑,为什么做事的方法如此之多,简直瘫痪了!是否有理由使用其中一个?来自木偶,似乎很容易用这些工具意外地错误配置了某些东西(即,遗漏了一些东西) 如何在开发集群中使用Chef自动配置节点?使用Puppet,我启动了一个连接到puppermaster的虚拟机,并启动了puppet运行并进行了设置(角色由外部节点分类器确定)。如何与厨师一起做?使用带有将其绑定到厨师服务器的pem / rb文件安装厨师,用刀手动告诉节点其角色或在管理界面中对其进行编辑,然后启动厨师客户机运行以进行自我设置? 我已经完成了入门教程,并且看到它们有EC2教程,但是我从未使用过EC2,因此很难遵循。至此,我主持了Chef的运行,并且我开始尝试配置单个节点。我从这里去哪里?我需要开始阅读公共食谱吗? Opscode上的文档还可以,但不及Puppet的文档。我在搜索中可能还会缺少其他好的厨师资源吗?

3
运行chef-server而不是chef-solo有什么好处?
我正在为我的团队寻找自动部署解决方案,并且过去几天一直在与Chef合作。我已经能够使用Chef-solo从基本的Red Hat VM上运行一个简单的Web应用程序。 我们的最终目标是在运行构建时使用Chef(或其他系统)将应用程序拓扑自动部署到云中。我们的过程基本上是这样运行的: 我们的Web应用程序代码,依赖项和厨师食谱都存储在SCM中 执行构建,并创建单个软件包以供图像获取和测试 然后,构建引擎将部署新的云映像,该映像将运行Chef客户端以安装软件包。 图像从SCM或Chef服务器获取食谱,并安装一切以启动并运行 运行Chef Server有哪些好处和/或用例? 与使用chef-solo和拥有可从SCM提取菜谱的脚本相比,拥有Chef Server并从SCM获取菜谱有什么主要好处?

2
如何在食谱中找到Chef环境?
我只想在当前环境为“ dev”时运行cookbook_file资源。如何表达呢? 该文档建议这样做: 在配方中,这样的代码块将很有用: qa_nodes = search(:node,"chef_environment:QA") qa_nodes.each do |qa_node| # Do useful specific to qa nodes only end 但是我不确定那不是我想要的-这实际上是一个循环似乎是错误的。
30 chef 

7
厨师和木偶要花钱吗?
我打算使用厨师或人偶进行管理(因为年轻的时候我在考虑更多的厨师,对此我会感觉更好)。 在两个主页上,我都看到有一个“企业版”需要花钱,而且我不打算购买任何东西。如果我不买菜,我会在厨师/人偶中想念什么? 厨师提供什么完全可以花钱的东西? 伪造的东西到底要花多少钱? 从他们的网站对我来说还不太清楚,因为它有点晦涩。
30 puppet  chef 

10
配置管理工具(Puppet,Chef)是否能够使安装的软件包保持最新?
对于已经在运行配置管理工具的人来说,这可能是一个简单的问题。配置管理工具(例如Puppet或Chef)是否是使安装的软件包保持最新状态的正确方法? 假设我运行许多服务器,大多数基于Debian和Ubuntu。当出现安全更新或错误修复时,配置管理工具是否使从存储库中安装的软件包的更新更容易? 我目前正在运行“无人值守升级”,以使系统自动安装安全更新,但我仍然必须连接到服务器并aptitude update && aptitude safe-upgrade经常运行。自然,随着服务器数量的增加,这变得无聊,乏味且容易出错。 Puppet或Chef之类的工具是否是使安装的软件包保持最新状态的正确方法?你们中有人使用这些工具来避免手动运行aptitude或在15台服务器上等效运行吗?我很确定这些问题的答案是“是的,当然!” 但是在哪里可以找到有关此特定用例的更多信息?我还没有时间深入研究Puppet或Chef,而示例菜谱或类仅显示或多或少的安装一个特定软件包(例如ssh)的小例子。除了官方文档之外,您是否有任何其他资源可以推荐(我当然会在知道哪种工具最适合我之后,就去研究这些文档)。

2
配置管理:基于推与拉的拓扑
更加成熟的配置管理(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命令或任何其他推送机制来管理基础结构。它们不像基于拉的方法那样可扩展。或与此相关的任何其他推送机制。它们不像基于拉的方法那样可扩展。或与此相关的任何其他推送机制。它们不像基于拉的方法那样可扩展。 这不是实现问题,而是架构问题吗?为什么编写一个线程化的推送客户端比一个线程化的推送服务器更难?

6
有没有更优雅的方式远程运行Chef-Client?
这是Chef快速入门教程中推荐的方法: knife ssh name:mynode -a ipaddress -x ubuntu -i mycredentials.pem "sudo chef-client" 这真是笨拙。真的没有更好的方法吗?还是在实际的生产环境中,您将拥有自动更新节点的想法?
22 chef 

9
如何在启动时为服务设置ulimit?
我需要让mysql使用大页面来设置ulimit-我已经在limits.conf中做到了。但是,limits.conf(pam_limits.so)不会为init读入,仅对于“真实” shell才读入。我通过在初始脚本启动函数中添加“ ulimit -l”来解决此问题。我现在需要某种可重复的方式来执行此操作,因为这些框是由厨师管理的,并且我们不希望接管RPM实际拥有的文件。



2
与其他部署策略相比,AWS Elastic Beanstalk的优缺点是什么?
一般而言,我对整个Netflix OSS堆栈和部署还很​​陌生。作为我当前所学知识水平的背景,我的主要角色是担任前端应用工程师。但是,我很喜欢操作方面的内容,因此我试图为新项目设置新的部署策略和工具。 我们的目标 超级轻松的部署(我们想按一下按钮以更新生产) 自动化部署到测试环境(使用Jenkins) 易于维护(我们有一个要编写的应用程序,不想花时间摆弄生产问题) 能够处理面向服务的体系结构(许多小型应用,各种语言和数据存储) 足够的灵活性以确保我们很快就不必更改策略(我们已经在努力摆脱RightScale) 如果可以省下一些麻烦,我们可以增加一些初始设置时间。 因此,按照这些思路,我一直在听播客,观看Ops演讲,阅读大量博客文章,并根据我们的目标以及我认为是最佳实践的想法,我们开始使用Asgard,将我们的包装放入罐子,然后放入AMI。 我们已经计划了所有这一切,并且喜欢该流程与使用Chef服务器和即时聚合实例相比的优势(由于时间表有限且对Chef服务器工作流程缺乏理解,我们认为这很容易出错)。但是,一位同事自己环顾四周,觉得Elastic Beanstalk满足了我们的需求。 我研究了它,并使用WAR文件和附加的RDS数据库启动了一个测试环境。似乎一切正常,我相信我们可以通过AWS API使用Jenkins将部署自动化到测试环境。似乎很简单...也许太简单了。 我想知道的是,有什么收获?如果Elastic Beanstalk如此简单和有效,为什么不谈论更多呢?对于两种不同的部署策略,我很难找到足够的客观见解和事实,因此我想四处询问。 您是否使用Elastic Beanstalk?如果是这样,为什么和什么因素导致了这一决定?你喜欢什么和不喜欢什么? 如果您不使用而是考虑使用Elastic Beanstalk,则使用什么,为什么不使用Elastic Beanstalk? SOA的基于Elastic Beanstalk的部署策略的优缺点是什么?也就是说,Elastic Beanstalk是否可以与许多相互依赖的小型应用程序很好地工作?

5
现有配置管理系统的优缺点是什么?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 我在这里查找CFEngine,Puppet,Chef,bcfg2,AutomateIt以及其他可能存在的其他配置管理系统之间的一些比较,很惊讶我在Server Fault上发现的很少。例如,我只知道上面的前三个链接-我在相关的Google搜索中找到了另外两个。 因此,我对人们认为最好的东西或他们喜欢的东西不感兴趣。我想知道以下内容: 配置管理系统的名称。 创建它的原因(与使用现有解决方案相对)。 相对优势。 相对弱点。 执照。 链接到项目和示例。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.