人工进行配置管理工作会耗费大量时间，而且风险极大，但凡是管理过服务器的技术人员对此都深信不疑。配置管理（CM）工具很早就出现了，我相信只要可以，开发人员都会选择一款工具进行使用。但问题的关键不在于是否要使用CM工具，而是选择哪一款来使用。对于已经使用过CM工具的开发人员，他们投入了大量的时间和资金，所以很可能会觉得自己使用的工具才是最好的。通常情况下，对工具的选择会随着时代的发展不断变化，今天我们选择工具的出发点也和以往不同。
大部分案例中，工具的选择都是基于遗留系统（我们拼命维护的系统）的架构，而非当前可用的工具种类。如果这样的系统忽略不计，或者说谁有足够的勇气和财力对遗留系统进行更新处理，那么今天占据统治地位的一定会是容器和微服务，我们以往的选择与现在的选择也会截然不同。
CF引擎（CFEngine）
CF引擎可以看作是配置管理之父。1993年诞生的CF引擎，彻底改变了我们对于服务器设置和配置的方式。一开始CF引擎是一项开源项目，2008年发布第一个商务版本，自此实现了商业化。
CF引擎是用C语言编写的，依赖物很少，而且运行速度极快。事实上，据我所知，CF引擎的运行速度是所有工具里最快的。以前是这样，现在也是。当然，白璧微瑕，CF引擎也有缺点，对编码技术的要求可能是其主要的缺点。许多情况下，一般的技术人员不会使用CF 引擎。必须是懂得C语言的开发人员才能够管理CF引擎。这个缺点并没有限制CF引擎的发展，很多大的公司企业都采用了CF引擎。但是，随着新工具的出现，人们的选择也越来越多，现在已经很少有人会采用CF引擎。
Puppet
随后出现了Puppet，一开始Puppet也是作为一个开源项目出现的，后来发展成为商用版本。Puppet采用了模型驱动的方法，与CF引擎相比在操作上更加“友好”，学习起来也相对简单。即便是运营人员也能够通过简单学习使用这款配置管理工具。CF引擎使用的是C语言，而Puppet使用的是Ruby语言，相比C语言要更加灵活，而且支持的操作系统也更多。
Puppet的出现使得CF引擎逐渐退出了历史舞台，主要原因还是CF引擎对于编码能力的要求较高。但这并不是说人们已经完全不适用CF引擎了。就像Cobol语言，虽然过时，但还是有一些银行和金融场景会用到。Puppet也不会立刻就消失不见，只是它已经没有了往日的荣光。
Chef
终于，Chef出现了，该工具确实解决了Puppet的一些小问题，但只是暂时的。随着Puppet和Chef逐渐发展流行，两个工具进入了“零和竞争”的状态。只要一方开发出新的功能或有了新的改进，另一方就会立刻模仿并进行相同的改动。这样一来，两个工具各自的功能都越来越多，复杂性也越来越高，相应的学习起来的难度也越来越大。对比来说，Chef对于开发人员要更加“友好”，而Puppet则更适合运营和系统管理类的任务。两款工具不分伯仲，开发人员在选择时通常也是经验居多，并没有什么判断标准。
Puppet和Chef工具都很成熟，应用都很广泛（尤其是在商业环境中），开源社区的贡献也都很多。唯一的问题就是，两款工具对于我们想要实现的东西来说过于复杂。这两款工具在设计之初就没有充分考虑到容器，它们也不会想到这场“博弈”最终会因为Docker而发生变化，因为那个时候Docker还没有出现。
到目前为止，我们谈论的所有工具都是为了解决配置管理问题，但当我们使用容器和不可变部署后，这些问题就应该不复存在了。没有服务器冗乱问题、没有成百上千的程序包、配置文件、用户、日志等等，我们现在面对的是大量容器以及极少量的其他东西。但这并不是说我们不需要配置管理，相反，我们更加需要！只是工具能够做到的事情相比以前要少很多。大部分情况下，我们只需要一个或两个用户、Docker服务正常运行、还有其他很少的东西，剩余的就是容器，而部署则变成了不同的工具组合，重新定义CM应该做的事情。
今天我们可能会用到很多部署工具，Docker Compose，Mesos，Kubernetes，以及DockerSwarm只是日益涌现的众多配置管理工具的一部分。在这种背景下，我们对于配置管理的选择应当注重简洁性和不可变性，而不是其他东西。语法应当简单易读，即便是从来没有用过工具的人都应当可以看懂；而不可变性可以通过使用push模型来实现（该模型不需要在目标服务器上安装任何东西）。
Ansible
配置管理工具基本上都面临着同样的问题，而Ansible决定通过非常不同的方式来解决问题。最显著的一点就是Ansible通过SSH（安全外壳协议）进行所有的操作。使用CF引擎和Puppet时，需要在其管理的所有服务器上安装客户端。虽然Chef声称其可以不安装，但其无代理商（agent-less）版本支持的功能十分有限。与Ansible相比可谓相差万里，因为SSH的存在，Ansible对服务器几乎没有任何要求。它会使用定义完善且应用广泛的协议运行所有需要运行的命令，确保目标服务器与我们的规定相符合。唯一的要求就是Python，而Python也早已预安装在大部分的Linux操作系统中了。换句话说，其他配置管理工具一直强制你按照某种特定方式设置服务器。
Ansible则会充分利用现有的东西，而且没有其他任何要求。Ansible的架构使得你只需要一个简单的实例，该实例运行在一个Linux或者OS X的电脑上，这样就可以用笔记本管理所有的服务器。我们不建议这种做法（笔记本只是为了说明Ansible 的简洁性），Ansible可能更适合运行在“实体”的服务器（其他持续集成和持续部署工具最好也安装在该服务器上）上。从我个人经验来看，类似Ansible这样基于推送系统（push-based system）的工具要优于之前我们讨论的那些基于pull的工具。
掌握其他工具的过程可能错综复杂，但学习Ansible也就分分钟的事。它的语法以YAML（是另一种标记语言）为基础，即便是从未使用过工具的人，只需看一眼介绍就能明白所有东西。Chef、Puppet以及CF引擎都是由开发人员编写，阅读人群也都是开发人员。Ansible也是由开发人员编写，但人们不用学习另一种语言和/或DSL（领域专用语言）就能读懂。
有些人或许会指出Ansible的主要缺点：对Windows的支持很有限。它的客户端几乎不能在Windows系统上运行，而且只有非常有限的很少一部分模块可以运行使用。在我看来，假设我们使用容器，那么这种缺点反而是一种优点。Ansible的开发人员并没有浪费时间去开发一个全能型工具，而是专注于该工具最适合的场景（即就是Linux系统中通过SSH实现命令）。无论如何，Docker 目前还不能在Windows系统上运行容器。或许未来可以做到，但现在（或者至少在我写本书的时候）还只是空中楼阁。即便我们不考虑容器及其未来在Windows上的应用，其他工具在Windows上的表现也都远逊于在Linux上的表现。简单来说，Linux的系统架构比Windows系统的架构更适合配置管理工具。
可能我不应该讲这么多，苛求Windows系统，还质疑大家的选择。如果你真的选择了Windows服务器，而非Linux，那么我所讲的所有Ansible的优点都不复存在。对于Windows，你应该选择Chef或Puppet，此外，忽略CF引擎（除非你已经在使用了）。
结语（final thought）
几年前，如果有人问我应该选哪个工具，我可能很难回答。但是今天，如果他在使用容器（无论是Docker还是其他容器）和不可变部署，答案十分简单，就是Ansible（至少在我提到的这几个里面，Ansible是最好的），不论是何时何地，只要与Docker和Docker部署工具结合使用，Ansible都是最好的选择。我们甚至会讨论是否还需要CM工具。在某些案例中，人们完全依赖CoreOS、容器、以及类似Docker Swarm或Kubernetes这样的部署工具。
我并没有这样绝对的想法（到目前为止），相反我认为在今天CM工具仍然有重要的价值。只是根据CM工具的目的来看（CM工具需要完成的任务），其它工具相对来说更加复杂，学习起来也更难，Ansible才是我们真正需要的。至今为止我还没有见过谁看不懂Ansible playbook。这样一来，配置管理就成为了整个开发小组的责任（因为每个人都能够使用Ansible）。
我并不说大家要对基础架构掉以轻心（当然要有足够的重视）。但是，不论是什么任务，整个团队所有开发人员能够通力合作确实是很显著地优势（与以前相比），配置管理方面也应该是这样。CF引擎、Chef和Puppet的架构都过于复杂，学习起来比较困难，至少与Ansible相比是这样的。
上面我们简述的4个工具只是众多CM工具中的一部分，你大可认为这4个都不是最好的，选择其他的工具。当然，这些都取决于我们希望达到的目标以及个人的喜好。但是，与其他工具不同的是，Ansible能够节省大量的时间。学习Ansible十分简单，即便最后你没有选择使用它，你也不会觉得在Ansible上浪费了很多时间。此外，只要我们在不断学习新知识，就会不断进步，臻于至善。
普元云计算专区：http://primeton.csdn.net/m/zone/primeton/index#
普元公众号：
扫一扫
153
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
