Chef集中管理工具实践之 (0) 什么是Chef


目录结构
Chef集中管理工具实践之 (0) 什么是Chef
Chef集中管理工具实践之 (1) 环境部署
Chef集中管理工具实践之 (2) 服务器配置
Chef集中管理工具实践之 (3) 自定义配置

本文内容
Chef集中管理工具实践之 (0) 什么是Chef

参考资料
http://my.oschina.net/williamherrychina/blog/63576
http://www.rubycc.com/bbs/topic_detail/91
http://gigix.thoughtworkers.org/2011/2/19/chef-1

Chef社区站点
http://community.opscode.com/

1.1 初识Chef
初识Chef,我们可以先了解一下DevOps运动 http://zh.wikipedia.org/wiki/DevOps,简单点说,就是传统的软件组织将开发、IT运营和质量保障设为各自分离的部门,而DevOps运动的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。
所以Chef简单点说,就是DevOps运动中的一项重要工具成员,是一个同时面向开发与运维的集中管理工具。

想像一下我们现在需要搭建一台MySQL Database Slave服务器,安装过程我们手动操作了没过多久,又需要第二台,这时候我们会想,如果之后安装第一台的时候把操作过程执行的命令写成脚本,现在安装第二台,运行一下脚本就行了,节约时间而且不容易出错。

Chef就相当于这样的一个脚本管理工具,但功能要强大得多,可定制性强,Chef将脚本命令代码化,定制时只需要修改代码,安装的过程就是执行代码的过程。
打个比方,Chef就像一个制作玩具的工厂,它可以把一些原材料做成漂亮的玩具, 它有一些模板,你把原材料放进去,选择一个模板(比如怪物史莱克),它就会制造出这个玩具,服务器的配置也是这样,一台还没有配置的服务器,你给它指定一个模板(role或recipe), Chef就会把它配置成你想要的线上服务器。

1.2 Chef和Puppet比较
就服务器的集中管理工具而言,知名度与Chef平分天下的是叫“Puppet”的工具,它们是OSS知名度排名最前的2个。

让我们来比较下它们的不同:

比较 Puppet Chef
历史 有一些 还年轻
用户 多,有名的公司也在用 还比较少,有一些公司如37signals在使用
开发的活跃度 中等 活跃(感觉正在旺季)
文档 也足够了
设定文件 用专用的文法书写(外部DSL) 用Ruby书写(内部DSL)
设定的构成 有点难懂 相对容易理解,命名等很合适
依存关系的处理 运行次序状况由系统端决定 像Makefile,基本上是书写顺序,相比Puppet更具脚本风格
必要的中间软件 没有 服务端需要有CouchDB、RabbitMQ
安装 简单,用gem的安装就可以 服务端安装比较麻烦。客户端简单,只需要gem就可以了
和其他系统的协作 感觉基本上没有 因为使用RESTful的服务API,用JSON可以取值,能做许多事

1.3 Chef结构
这是Chef的结构图,对图做一点解释:

有一个中心服务器(运行chef-server)
Chef将数据存储在CouchDB数据库里面
RabbitMQ和chef-solo等提供搜索的功能
Chef还提供了个图形的用户界面(cher-server-webui)
Workstation上有一个pem文件,knift(对Chef进行配置)利用它作为认证来和chef-server通过REST API进行通信
Workstation将配置(利用Recipe等描述各Client应该如何配置自己)上传到服务器
Client上有一个pem文件,chef-client利用它作为认证来和chef-server通过REST API进行通信
当新加一个Client的时候,需要从中心服务器上拷贝validator.pem到新加的Client
它利用这个pem进行注册得到自己的client.pem进行以后的认证
Client连到Chef服务器查看如何配置自己,然后进行自我配置

1.4 Chef的三种管理模式
Chef-Solo
由一台普通电脑控制所有的服务器,不需要专设一台chef-server

Client-Server
所有的服务器作为chef-client,统一由chef-server进行管理,管理包括安装、配置等工作 chef-server可以自建,但安装的东西较多,由于使用solr作为全文搜索引擎,还需要安装java

Opscode Platform
类似于Client-Server,只是Server端不需要自建,而是采用http://www.opscode.com提供的chef-server服务

而上面三种管理模式,无疑Client-Server模式是最好,也是最复杂的,因为这样可以在本地环境中搭建一个私有的Chef集中管理环境而无需依赖任何第三方的平台。

1.5 Chef能做什么
Chef能做什么,答案的Anything,这个实际上很好理解,只要你可以对一台服务执行命令,你就可以对这台服务做任何配置(不是有那句话嘛:Where there is a SHELL, there is a way)
这里大家可能对Chef有一些误解,由于Chef使用类似模板的方法对服务进行配置, 大家可能认识它只适合于一些配置比较类似的服务, 这里完全小看Chef了,就拿官方的mysql cookbook来说,它可以同时支持众多OS平台:
debian ubuntu centos suse fedora redhat scientific amazon freebsd windows,当你对Chef有了更深的了解后你就不会感到惊讶了。

1.6 Chef是怎么工作的
如果忽略所有的细节,Chef是这样工作的:
在Workstation上定义各个Client应该如何配置自己,然后将这些信息上传到中心服务器
每个Client连到中心服务器查看如何配置自己,然后进行自我配置
因此,在Chef的环境搭建完成以后,绝大部分工作是在Workstation上进行的,只有在工作完成以后,决定应用到Client的时候,才会操作Server与Client。

1.7 对Chef中各个名词的形象解释
Chef 大厨
我就是个新手大厨,我想要烹调一桌服务器大餐,也就是一台体面的、可以用来满足某种用途的服务器。

Cookbook 菜谱
别人写好的一本书,书上写着一堆相关菜色的做法(比如“家常川菜”)。一些出色的服务器大厨已经写了 很多菜谱 ,这些是我要学习和抄袭的。

Recipe 菜谱里的一道菜色(比如“麻婆豆腐”)
服务器大餐里的某一部分该怎么做,都在菜色里写着呢。

所以,整个故事就是:
作为一个新手大厨(Chef),我想要从现成的很多菜谱(Cookbook)里挑选几道合适的菜色(Recipe),组合成一道大餐(服务器)来款待我的客人。
等我的手艺熟练之后我还会写我自己的菜色和菜谱,来创造属于我自己的大餐。

Chef的主要目标就是:把服务器配置变成源代码。
这样做的好处有两个:
自动化
我可以很轻松地把一台服务器大餐的做法直接照搬到另一台服务器上,于是我就得到了另一台大餐。

配置管理
服务器的配置信息能够很好的通过Git来管理,可以分享,可以多人协作,可以跟踪变化历史。

Chef使用服务器—客户端模式管理所有需要配置的机器,使用Chef涉及至少三台机器:
一台开发机器Workstation,在上面编写大餐的做法;
一台Chef服务器,管理所有要配置的Chef客户端,给它们下发配置信息;
多台Chef客户端(Node),就是我将要烹调出的大餐。

1.8 接着,我们可以开始以下过程
目前,我们对Chef已经有了一个基本的了解,接下来就可以通过以下步骤进行亲身实践,来加深理解。
Chef集中管理工具实践之 (1) 环境部署
Chef集中管理工具实践之 (2) 服务器配置
Chef集中管理工具实践之 (3) 自定义配置

, ,

  1. No comments yet.
(will not be published)
*