可用于集群的开源软件赏：Chef

目前我在腾讯主要负责一个服务器端软件的相关开源项目，所以接下来几天的开源内容是最近工作上积累的一些经验和想法，下图中的内容就是我目前主要的工作内容和一些小小的成果。

服务器集群系统设计是一个需要考虑开发、部署、维护整个生命周期的复杂工作。因此把这个复杂的过程切分成单独的任务，是解决问题最重要的思想。而开源软件最擅长的就是，能很好的完成特定的任务。因此我们通过学习、利用开源软件，就能逐步的完成服务器集群系统设计的困难工作。

今天的主题是关注集群服务器系统的安装部署。我们关注的是一款流行的开源安装部署专用软件——Chef。

Chef是什么

现在在Linux上安装服务器系统，变得越来越复杂。早期的Linux软件往往通过源代码就能编译成功，然后简单的拷贝安装就可以了。但是现在的一个完整业务系统，往往会依赖多款开源服务系统。如一个电子商务网站，可能会依赖Apache/PHP/ MySQL /memcache/redis，而一个游戏服务器端系统，则可能会由Tomcat/MySQL/ActiveMQ/Ngix/PHP-FPM构成。同时这些服务器软件不是安装到一个服务器上，而是要按某种规划，分种类安装到不同的服务器上，组成服务器组。这样除了要安装开源软件外，还涉及复杂的互相连接配置的设置工作。如果这些工作全部都手工完成，其工作量将不可想象。因此很多运维工程师都会自己编写很多脚本，去自动化的完成任务。但是，这些脚本往往不能重用，也缺乏重用的基础环境，而脚本所依赖的各种配置数据，也没有统一的存储和操作方法。因此，有很多工程师开始探索开发一套通用的基础部署、配置系统。而Chef，就是这样一套提供简化安装开源软件，且能统一管理各种配置的一个平台。

[一个基本的开源电子商务集群架构]

Chef是一个使用Ruby脚本的集群部署配置系统。它可以运行在各种Linux平台上。官方网站：https://www.chef.io/chef

Chef的组成

Chef对于安装部署的理解是这样的：我们需要一个中心服务器，也就是Chef server，他负责存储所有的安装脚本和配置参数，并且负责执行部署工作。然后，我们在需要部署软件的目标服务器上，安装一个chef-client软件，这个软件负责接收Chef server的指令，执行安装部署和配置的工作，并且这个软件必须能在虚拟机、云实例、物理服务器上都能运行。最后，我们需要一个管理平台，也就是运维人员进行安装部署方案制作、管理的电脑，称之为Administrator’s workstakstation，在这个电脑上，Chef提供一个叫knife的软件，用来把配置项和安装脚本编写和配置好，这些安装脚本被称为cookbooks。需要安装的开源软件的安装包，可以从任意的Repo仓库中获取，比如通过Git/SVN仓库，这也是能让我们把自己编写的服务器端软件用Chef一起部署的入口。

Chef概念

上面简单介绍了一下Chef的模型，下面来详细介绍一下各种角色：

Chef Server 存放所有通过Workstation上传的资源，和用户等公共数据（用PostgreSQL）。可以干脆叫它为资源服务器，大家都可以与它通讯（用RabbitMQ ），本身提供一个在线管理工具叫chef-server-webui（用Nginx，包括它的rest-api）。 Chef Server只能安装在linux系统上。

Workstation 简单理解为管理员操作机，通过安装的工具knife远程操作Chef-Server上的资源，或者注册Nodes等 这个可以安装在任意系统上，包括windows

Nodes 一些客户端的机子，它们是内部装有一个工具叫做Chef-Client，这东西会自动到Chef-Server上获取自己的要执行命令清单 可以安装在任意系统上，包括windows

DataBag 这是一个集中包含各种配置信息的数据区，这些数据是以JSON格式表达的。这些参数一般包含集群中各个机器的地址、端口、角色信息。这些信息是部署脚本可以共享使用的。

Cookbook 针对每个服务器系统，都需要一个安装、配置脚本。每个脚本都会负责安装一套软件到目标服务器上

Environments

由于我们对于同一个服务器集群，可能会在不同环境下部署。比如一套游戏服务器，可能会开几个游戏区服；一套电子商务系统，可能会开多个功能类似但商品不同的店。每一套服务器集群的部署方案，就被称为一个Environment。它代表了部署方案的多个实例。

Role

在一个服务器集群中，每个服务器会承担不同的角色，有时候一个服务器会兼几个角色，也有可能几个服务器共同承担一个角色。如有时候多个服务器安装Squid来负载均衡，有时候安装了MySQL的服务器会同时安装一个Memcache来兼任缓存服务器。因此每个Role(角色)代表了对某一个系统的安装，这样我们就能在不同的物理环境下，灵活的分配集群中的角色，从而自动安装配置相关软件。

Chef除了提供命令行工具knife外，还提供了一个Web界面来使用。在这个web界面上，我们可以看到针对以上每个概念的入口，可以直接在上面填写数据和操作。

Cookbook

安装部署系统的核心是安装脚本，而Cookbook(烹饪书)，就是代表安装脚本的名词。他负责针对某一个系统的安装配置。每个Cookbook都包含以下部分：

• Attributes 针对节点（Node）的配置
• Definitions 复用安装资源（Resources）的定义
• File Distribution 传到服务器上的文件
• Libraries Ruby代码支持库
• Recipe –食谱，某项任务的安装配置
• Resource 需要安装的软件和配置项
• Provider 软件的安装提供者
• Ligtweight Resources and Providers - 自定义Resource和Provide
• Templates 模版，可重用的“config文件”模板
• Metadata 烹饪书的概要

这里的内容，最重要的Recipe，这是真正的编程语言代码，而不仅仅是一些数据。下图给出了对ntpd这个软件的安装写法实例。(ntpd是一个对时服务)

这个脚本本身是一个ruby脚本文件。当然这里简单的action[:install]实际上是配置了专门的“安装”脚本，可能是用Ubuntu的apt-get install ntpd命令，也可能是RedHat的yum install ntpd命令。

当你写完一个cookbook后，你就可以运行这个脚本。最简单的做法就是通过WEB界面，先建立一个Run List任务，然后选定运行的Node节点，最后选择你写的cookbook脚本，就可以执行了。

Data Bags & Enviroments

我们在部署集群系统的时候，需要很多公共变量，比如安装路径之类的。这些就需要用Data Bags来装，这些数据是放在Chef server上的，所有的cookbook都能读取。这些数据都是JSON格式的，所以能实现非常丰富的结构。除了公共变量，我们还可以存放各种安装进程的位置、配置参数等等。有一些复杂的系统，会专门另外编写一个系统来操作Data Bags数据。Data Bags的大概样子：

{

"id":"charlie", "uid": 1005, "gid":"ops","shell":"/bin/zsh", "comment":"Charlie theUnicorn"

}

Enviroments负责管理不同的部署环境，最常见的有：开发环境、测试环境、运营环境等。在开发环境中，我们可能会把整个集群安装在很少的服务器上；而测试环境我们则会针对测试目的，来独立安装特定的程序，到特定的服务器上；运营环境下我们考虑的更多是负载均衡和充分利用服务器性能，所以就算同一套系统，在不同的环境下，安装配置的情况都是不一样的，所以Enviroments包括了以下部分：

l 多个角色定义

l 指定每个环境中的“角色”(Role)的run list

l 每个环境的Cookbook版本

l 不同的环境属性

Chef的实现

Chef本身也是由一批开源软件组成的，他使用了CouchDB存放各种cookbook和data bags内容、Enviroments配置。使用了Solr提供索引和搜索的功能。使用RadbbitMQ来对搜索任务进行队列缓存。而核心是一套Chef Server的API，他集中了所有的Chef server的能力。Chef Client作为执行者访问这些API；Knife则以命令行模式执行这些Chef server的API；一套Web UI系统以图形方式执行Chef server API。

这里值得夸奖的是对于Chef ServerAPI的这种设计，让多个不同的使用角色，都可以集中的使用同一个系统功能，对于维护、扩展Chef Server的能力提供了有力的架构支持。那些复杂的实现，如存储、搜索，都被这套标准的接口所封装了。

集群部署配置系统的思考

我们可以考虑一般的集群部署配置系统，我们往往使用基本的Linux Shell作为脚本，然后对常见的配置数据建立模型，最后使用一些代理进程来下发配置。但是这样做和Chef对比，能发现有很多可以学习的地方。

今天有读者从后台发来留言，想共同探讨一些他感兴趣的内容，感谢这位读者（阿木）的关注，关于敏捷开发的内容下周可以探讨一下，大家有需要探讨的或者想了解的内容，可以后台留言给我。