Questions tagged «configuration-management»

配置管理是指在组织内建立和维护标准化的系统配置。该标签包含定义配置文件的过程以及用于管理和部署它的软件。

7
小型自动化Linux部署和配置管理-值得吗?
我将部署约25台运行Debian的服务器。这些机器将扮演不同的角色-网络服务器,Java应用服务器,代理,MySQL机器。该环境将来可能不会增长太多-未来两年内可能会再增加2-5台服务器。 我可能会使用fai进行系统安装,但是我不确定是否值得为如此小的规模添加cfengine或puppet集中式配置管理。 配置管理对于如此大的环境有意义吗?

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

5
up:修改配置文件后强制重启服务
我如何确保如果通过木偶从主存储库将新版本的配置文件下载到其中一台受管服务器,则相关服务将重新启动。 典型场景-假设有新的munin或apache配置。puppet客户端发现它,覆盖本地文件...以及...-如何确保服务重新启动/重新加载? 非常感谢!



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

7
在决定使用Chef或Puppet时,有哪些正确的问题要问?
我将开始一个新项目,该项目将部分需要部署大约三个不同类的许多相同节点: 数据节点,它将运行MongoDB的分片实例。 应用程序节点,它将运行Ruby on Rails应用程序和较旧的ASP.NET MVC应用程序的实例。 处理节点,它将运行应用程序节点请求的作业。 所有节点将在Ubuntu 10.04实例上运行,尽管它们将安装不同的软件包。 尽管我不认为自己是专家,但我对以前项目中的Chef有所了解。为了尽职调查,我一直在研究其他可能性。我们内部有很多人是Puppet的长期用户,所以他们鼓励我看看。 我在评估这两种选择时遇到了麻烦。Chef和Puppet共享许多相同的领域术语- 包,资源,属性等,它们有着共同的历史,源于对同一问题采用不同的方法。因此从某种意义上说它们非常相似。但是,像本文一样,我发现的许多比较信息都有些过时。 如果您今天开始这个项目,您会问自己哪些问题来决定应该使用Chef还是Puppet进行配置管理?(注:我不想要回答这个问题:“我应该用厨师或木偶?”)

15
您将为Firefox添加哪些功能以使其进入企业?
Firefox在家庭/个人用户群中的采用似乎正在增长,但是在企业中的采用并不能很快发展。 我对此的看法是因为SysAdmins并未在组织内部推广它,因为Internet Explorer具有使它更易为企业所接受的功能,例如 通过GPO管理设置 集成到其余更新堆栈中 支持常见业务应用 那么,您将在Firefox中添加些什么,以使SysAdmins在企业中进一步推广它呢?

1
如何在ansible中打印主机的当前主机名
我写了一个角色,用于在用户登录计算机时编辑motd,但是我想个性化motd以打印计算机的主机名 我使用什么变量?或我该怎么做?模板?怎么样?我copy module将motd文件用于 因此,例如,我希望能够说“欢迎使用$ hostname”,那么如何使用ansible解析此主机名?

3
我可以使用什么工具来管理Windows Server环境的配置
我帮助管理使用基于云的Windows服务器VM的应用程序的环境。该应用程序堆栈由Windows Server 2008和Windows Server 2012,SQL Server 2008,IIS和SharePoint 2010组成。我有几种环境Dev / Test / Stage / Prod。我正在寻找一种对这些环境进行配置管理的方法,以确保以一致的方式应用任何环境更改,并且有一种方法可以验证没有对一个环境进行过其他环境所做的任何更改。 我一直在阅读有关Puppet,Chef等的内容,我喜欢进行代理配置管理的想法。有什么好的方法或工具可以用来帮助管理这些环境的配置。我对SCCM有点了解,但是对于这种特殊情况来说,它太昂贵了,尽管我仍然想知道它是否有能力执行这些操作。

5
使用EC2时,如何跟上Nagios / Capistrano配置?
我将Amazon EC2用于我的移动应用程序。根据给定时间的应用程序负载,我可能会生成新的实例,然后在负载较低时将其删除以节省成本。 在这样一个动态环境下,如何与Nagios配置保持一致?当涉及托管硬件时,配置文件是可预测的。在这种情况下,需要添加Nagios,Capistrano和许多其他配置文件。Capistrano需要知道将新版本部署到应用服务器的位置。Nagios需要知道要删除现有实例或添加新实例进行监视。Nagios还需要知道节点是否被有意关闭或主机是否由于错误而关闭。 VPS /动态实例的精彩世界是如何做到的?

3
使用Puppet设置sysctl.conf参数
在CFEngine中这是一件轻而易举的事 ……但是我现在在Puppet环境中,需要能够分配/确保/检查某些sysctl.conf变量。在CFEngine的世界中,我可以简单地检查配置文件中的特定行... 在Puppet Wiki上找到了对sysctl模块的小引用,在github中的一个项目看来可以满足我的要求。 但是,两者都没有得到很好的记录。我只是在寻找一种方法来编辑一些值,例如net.core.rmem_default和net.core.wmem_max。按照github上托管的项目的格式,init.pp清单中的配置应类似于: class sysctl { sysctl::value { "net.core.rmem_default": value => "9000000"; "net.core.wmem_default": value => "9000000"; "net.core.rmem_max": value => "16777216"; "net.core.wmem_max": value => "16777216"; } } 通过论坛和邮件列表,似乎对Puppet插件和模块之间的差异感到困惑。这些术语几乎可以互换使用...我最终需要在我的客户端上启用pluginsync,以克服一些麻烦的错误。我以为这是一个模块! 当前客户端错误: info: Loading downloaded plugin /var/lib/puppet/lib/puppet/type/sysctl.rb info: Loading downloaded plugin /var/lib/puppet/lib/puppet/provider/sysctl/parsed.rb err: Could not retrieve catalog from remote server: Error 400 …

1
3个节点群集的配置管理功能过大?
我的负载均衡器和各种Web应用程序有2-3个节点群集。我必须先在质量检查中进行更改,然后在暂存中(在2-3台服务器上)进行更改,然后在生产中(在2-3台服务器上)进行更改。这里是否适合使用诸如Chef或puppet之类的配置管理工具?还是过度杀伤力?如果这是过度杀伤力,那么有什么技巧可以使之更容易。

2
如何分割Prometheus配置文件?
现在,我们正在使用Prometheus进行监视,并且有很多配置(我们的prometheus.yml主配置文件长1400多行)。 我想将其分为逻辑分组(也许是DEV / TEST / PROD?),但是我似乎找不到关于如何在Prometheus配置文件语法中使用“包含”(或类似内容)的任何文档。 有人用他们的Prometheus配置文件做到了吗?如果是这样,您是如何做到的?

4
有关使sysfs参数保持一致的建议
我正在尝试对通过sysfs虚拟文件系统公开的Linux系统运行时参数进行较大的更改。 维护这些参数以使它们在RHEL / CentOS风格的系统上重新启动后仍然有效的最有效方法是什么? 这仅仅是将命令转储到/etc/rc.local中的一种情况吗?是否有一个适合此的初始化脚本?我还从配置管理的角度考虑标准化。是否有一个等效的干净sysfs sysctl?

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.