返回 登录
0

Docker世界中的配置管理:5分钟让你明白如何在Puppet,Chef, Ansible之间选择

阅读3348

译者点评:

微服务的运用,小型化团队(Two-pizza team)理念的倡导使更多的公司采用研制周期(Lead Time)来衡量DevOps团队的执行效率。在实际项目研发结束后,服务的部署频率(Deploy Frequency)不仅说明了运维的稳定性,还能折射出业务的繁荣程度。这一切的背后都离不开运维工具强有力的保障。

让我们一起学习下Puppet,Chef, Ansible等工具的前世今生,花五分钟明白如何在容器化的今天,选择一个靠谱的配置管理工具。
人工进行配置管理工作会耗费大量时间,而且风险极大,但凡是管理过服务器的技术人员对此都深信不疑。配置管理(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#

普元公众号:

图片描述

评论