什么是Chef/Puppet/SaltStack/Ansible? 何故我觉得它们的功能有重叠?

Question

一. 描述问题&上下文环境

对devops, 好像所有人都很提倡,维基百科的定义是:

DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.1 It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably

一种文化? KiddingMe?
这种概念很玄乎, 难以理解

搜索了很久,脑海中对它们大概的印象是:

• 某种配置工具

• 某种运维自动化工具

• 某种"管理大量服务器"的工具

• 与DevOps相关

但仍有以下疑问:

1. 对Python后端开发者的意义在? (学习的理由在?)

2. 它们之间相互是什么关系(好像功能有重叠)?

3. DevOps到底是啥? 能否有精确定义?

4. 最重要的一个问题: 我想对它们的历史及周边进行详细了解, 即想了解它们的来龙去脉, 该如何组织关键词(devops history?) ?

5. 想要学习它们, 没有具体的使用场景(不是自己制造的), 应当很难学习吧很难理解吧?

二. 相关代码&重现

三. 报错信息

四. 相关截图

五. 已经尝试哪些方法仍然没有解决(附上相关链接)

自己尝试的Google搜索关键词

1. what is devops

2. devops tools

3. chef vs puppet vs slatstack vs ansible

4. why ansible

5. 对它们的历史了解, 我看了维基百科, 但是仍然概念模糊

6. 是得要自己亲自经历使用它们的场景,才能理解深刻吗?

依据自己的搜索信息, 自己不成熟的理解:

1. devops: 首先是开发, 然后负责自己代码的最终到生产环境运行起来,并且使之持续运行正确

2. devops: 开发干了部分运维的事情, 这个理解咋看起来这么奇怪?

六.问题简化

Answer 1

1. 对Python后端开发者的意义在? (学习的理由在?)

自动化配置管理工具属于自动化运维第一个分支。配置管理工具是开发和运维的统一服务部署语言（非容器应用，容器环境现在k8 比较流行）；在没有专职运维的公司里，开发人员不想加太多的班的话，自动化运维工具应该尽快掌握起来。Ansible 是比较热门的一种，是用 Python 实现的，Python的开发者应该需要很快上手这门技术。

1. 它们之间相互是什么关系(好像功能有重叠)?

就是同一类的配置管理工具，做的事情是一模一样的；建议搜索一下维基百科，有它们的比较详细的对比说明。

1. DevOps到底是啥? 能否有精确定义?

DevOps是一个非常庞杂的框架，在 09 年开始 DevOps 运动的推动下，目前已经是任何企业和团队都无法规避的话题。它旨在提倡通过优化开发、测试和运维之间的协助，从而在全局上，实现更优秀的软件交付效能。它来自于社区，服务于社区，并没有唯一官方的精确定义，不建议从 wiki 的解释上生硬的理解，需要更多的了解它所提倡的文化、自动化、度量、分享和学习等观念。而做 DevOps 的过程就是在不断的定义和寻找答案和意义的过程。关于它的历史和意义可以参考我的两篇文章： 1 和 2 。

1. 最重要的一个问题: 我想对它们的历史及周边进行详细了解, 即想了解它们的来龙去脉, 该如何组织关键词(devops history?) ?

我正好做过一个 DevOps 简史的小视频，推荐观看一下。

https://www.bilibili.com/vide...

1. 想要学习它们, 没有具体的使用场景(不是自己制造的), 应当很难学习吧很难理解吧?

建议在理解了 DevOps 的意义之后，先从问自己 WHY DevOps 开始，从优化当前工作的角度出发，在实践中学习，切勿跟风考证，或者追逐别人正在炫耀的技术。

Answer 2

如果说重叠，确实是的，毕竟都是自动化运维工具，最起码基本功能都要实现吧。而类似的也很正常，肯德基和麦当劳也很类似，但这并不妨碍他俩都很好吃（对于我来说） //就好比迪丽热巴和古力娜扎都很美（我全都要.jpg）

但这几个工具也是有一定的区别，总体来说puppet和chef比较像，ansible和saltstack比较像。

puppet是比较成熟有历史的，后来chef出来解决了puppet的一些老问题，之后老哥俩就相互竞争相互学习；ansible的着重点和他们不太一样，ansible更注重轻便、快速、高拓展（就是舍弃一定的复杂程度和性能，来换取方便使用、开发）；saltstack介于两种之间，saltstack什么都支持，也都还支持的不错，但是正因为是折中的设计，其优势也不像另外两种那么突出。

实际来说也都是很好的工具，简单来说，可以从这几个角度来选择：

1. 语言
   chef和puppet是用ruby写的，salt和ansible是python。如果深入使用或者想拓展的话，且不希望为此特地拓展技术栈，可以根据擅长的语言排除50%选择（笑）。
2. 是否希望部agent端
   ansible是angentless的，只需要server端部署好ansible，ansible就可以通过ssh与客户端通讯了，而无需部署agent，当然客户端还是需要有Python的。而puppet、chef都是以C/S结构的。saltstack比较特殊，同时支持两种模式，而且支持的都还不错（但主要还是CS）。
3. 通讯方式
   上面提到了ansible是ssh方法的，至于其他的工具分别是：puppet-ssl，salt-ZeroMQ，chef-ssl。这也就涉及到其他问题，比如ansible虽然通过ssh可以做到agentless，但是也由于受到ssh的限制，使得性能上受限，通常几百台客户端差不多，再多就会出问题；而ssl和ZeroMQ在性能上基本上无需过于担心。再有就是ssh由于权限问题，在有跳板机或是堡垒机的场景可能会比较麻烦。
4. 阿森纳
5. 工作方式
   这部分主要是指是push还是pull。salt和ansible主要push模式，即server端主动将配置推送到客户端上；而puppet和chef是主要pull，即客户端主动向服务端请求配置。这个根据你的场景实际需求进行选择。另外，虽然ansible、salt和puppet都可以支持push和pull全部两种模式，但是由于这些项目在设计时是更加注重其中一种模式，因此导致对非主要模式的支持实际上是较弱、或是功能不如另一种强大的。（chef不是很了解）
6. 其他
   在选择上还有一些其他因素，比如社区，相对来时ansible的社区是最活跃的，但是其他这几个的社区内容基本也够用了；再有就是使用者范围，相对来说大型公司或是复杂环境多使用puppet，而中小公司用ansible的较多；还有一个比较重要的点，这几个工具里面相对来说puppet对Windows支持最好（虽然也是阉割版，只支持部分resource），要是客户端有很多windows，可以考虑puppet。