Puppet 自动化集群管理基础篇

Puppet 作为开源的集群管理框架，有着简单易用、快速部署、使用范围广等特性，已经积累了超过 250 家的用户，包括阿里巴巴、新浪、Oracle 等大公司。本文作者将带领大家了解 puppet 技术及其简单的应用。

背景简介

在传统的服务器集群管理中，每增加一台服务器，都需要对该服务器进行相应的配置。如果服务器数量少，那逐一对服务器进行配置是没问题的。但是在目前的生产环境中，服务器数量动辄就是成千上万台。传统的集群管理方案耗时耗力，已无法快速有效的适应生产环境的需求。目前，在公司内部存在 3 万多台的 web 服务器，如何对其进行快速部署成为公司内部亟待解决的问题。主要需求包括：

1.突然有一天，某机房 DNS 出问题了，需要换个 DNS。

2.基于某个模板的业务快速上线。

3.Apache 的配置需要将 robots 文件的配置修改。

4.快速安装某个软件某个模块。

5.修改了某个配置，需要重启对应服务。

6.某天我们对某台机器做某个测试修改了配置，又某天我们对另外一台机器测试又修改了一个配置，越积越多。

如何快速的解决以上情况所引起的生产环境失效的问题，我们对自动化集群管理工具 puppet 进行了调研，从软件包、配置文件和服务三种类型的资源出发，对服务器集群进行了自动化管理设计。

1 Puppet 是什么

Puppet 是一种跨平台、C/S 架构的集中配置管理系统，可以用于管理 linux、windows、unix、mac 等平台下的用户、软件包、文件、服务和 cron 任务等，并且可以妥善处理资源之间的依赖关系。其使用 ruby 语言开发，但是使用者并不需要了解 ruby 语言，因为其仅仅依赖于一种以 pp 为后缀的文件，在 puppet 框架搭建好后，就只剩下模块的开发，模块开发采用描述性语言和基本的逻辑控制语句，简单易懂，非常适合于管理和部署大规模的集群系统。

2 Puppet 架构

Puppet 使用 C/S 架构，分为 puppet server（master）和 puppet client（agent）。master 是配置和管理中心，管理着所有的节点。系统管理员需要在 master 上编写每个节点所对应的 pp 文件来描述不同节点的资源集合和目标状态。各个 agent 会周期性的查询 master，来获取自己的配置，并将结果以报告的形式传送给 master。

puppet 使用 ssl 认证，在 client 与 master 第一次通讯认证通过后，证书会存储在 master 上，当仅有一台 master 时，这不会产生问题。但是，在我们的设计中，为了保证高可用和高并发，master 是集群，master 集群的前面是负载均衡，同一 client 与 master 多次通信时，无法保证连接的是同一个 master，也就是说无法保证证书的获取。为此，puppet 官方建议搭建单独的 CA 认证服务器，从而实现证书的统一中心化管理。因此在大规模集群管理系统中，常见的 puppet 架构如上图，本公司同样也采用了该架构搭建集群管理系统。

3 Puppet 工作流程

Puppet 既可以单机运行，也可以通过 C/S 架构的方式运行，不过在大多数情况下还是基于 C/S 架构的方式来运行，其交互过程如下图所示。

1.agent 通过 ssl 向 master 建立认证。

2.建立认证后，puppet 调用 agent 的 facter，探测出主机的一些内置变量，如主机名、系统版本号、ip 地址和负载等信息。Agent 将这些信息通过 ssl 加密发送到 master 端。

3.Master 接收到 agent 的主机信息请求后，根据域名或 ip 地址将他们发送到本机的 manifests 或 ENC，进行节点配置信息的查询。

4.在解析过程中，首先进行语法检查，如果有语法错误，则停止，返回错误信息，否则继续解析生成 catalog。

5.Puppet 客户端 agent 对服务端生成的 catalog 进行应用。

6.Puppet 客户端 agent 对 catalog 进行代码验证并执行，并将结果记入日志。

7.将 agent 信息以报告的形式上报 master。

8.流程结束。

4 Puppet 安装与配置

基于公司内部已有的 DNS 域名解析和 LVS 负载均衡服务，围绕 puppet 的整个集群管理系统架构图，在 centos 环境下，puppet 安装与配置方法如下：

Master

目前使用了 4 台 master 用于管理 15000 台左右的服务器，如果后期 master 压力增大，再适当的扩容。配置步骤如下：

1）安装 puppet 的相关包，包括 puppet-server、Apache、mod_ssl、mod_passenger。

在安装以上包的同时，系统会自动安装 facter 包和一些 ruby 依赖包。

2）编辑 /etc/puppet/puppet.conf 配置文件。

3）复制 CA 服务器上的证书，主要是打包 CA 服务器上的 ssl 目录，并放到 master 上的 ssl 目录下。

4）初始化 master，生成必须文件。

5）建立/etc/httpd/conf.d/puppet.conf 配置文件。

6）创建虚拟主机的 DocumentRoot。

7）启动 puppet。

CA

将 master 和 agent 的认证机制放在单独的 CA 服务器上，可以方便 master 集群的管理和扩容。配置步骤如下：

1）安装 puppet 的相关包，包括 puppet-server、Apache、mod_ssl、mod_passenger。

2）编辑/etc/puppet/puppet.conf 配置文件。

3）创建/etc/puppet/autosign.conf 配置文件，如果内容是“*”，表示所有主机都可访问。

4）启动一下 puppet master，实现初始化，生成 key 和自认证。

5）为 master 服务器生成证书。

6）建立/etc/httpd/conf.d/puppet.conf 配置文件，文件的设置参照 master 的配置。

7）创建虚拟主机的 DocumentRoot，参照 master 的配置。

8）启动 puppet，参照 master 的配置。

Agent

Puppet 客户端安装比较简单，配置步骤如下：

1）安装 puppet 的相关包，包括 addops-puppet、addops-puppet-agent-extra（公司内部包）。其中第一个包为 yum 源包，第二个包为 puppet 的扩展包，其依赖于 puppet 包，并且会自动修改配置文件中的 ca_server、server 和 node_name_value 三个变量的值。

2）测试运行：puppet agent --test，默认同步的环境为 production，可以手动添加环境参数，如–environment=staging，即可改为临时环境。

5 Puppet 配置解读

puppet 的主配置文件 puppet.conf 位于/etc/puppet/（社区版）目录下，其中主要包含了 main、master 和 agent 三个命名空间，依次介绍如下：

1）main 通用配置选项

• confdir：配置文件存放目录，默认在/etc/puppet。

• vardir：动态数据存放目录，默认在/var/lib/puppet。

• logdir：日志存放目录，默认在/var/log/log。

• rundir：PID 存放目录，默认在/var/run/puppet。

• statedir：状态存放目录，默认在 $vardir/state。

• ssldir：SSL 证书存放目录，默认在 $vardir/ssl。

• trace：发生错误时显示跟踪信息，默认 false。

• filetimeout：检测配置文件状态改变的时间周期，单位秒，默认 15 秒。

• syslogfacility：指定 syslog 功能的级别，默认为 daemon 级。

• manifestdir：系统的启动文件存放目录，默认在/etc/puppet/manifests。

• basemodulepath：模块的存放目录，默认为/etc/puppet/modules，可以指定多个。

• luginsync：当有自定义 facter 变量时，需要指定该值为 true。

• ca_server：认证服务器的名称。

2）Master 服务端配置选项

• user：后台进程执行的用户。

• group：后台进程执行的组。

• certname：进行 ssl 认证时的变量名，默认为主机名。

• node_name_value：节点名称，默认为主机名。

• mainfest：mainfest 站点文件的名字，默认为 site.pp。

• bindaddress：后台进程绑定的网卡地址接口。

• masterport：后台进程执行的端口，默认为 8140。

• ca：当认证服务器位于单独的服务器上时，需要指定该值为 false。

3）Agent 客户端配置选项

• classfile：显示从服务端加载到的类列表。

• localconfig：本地缓存配置目录。

• runinterval：客户端的检测时长，默认为 30 分钟检测一次。

• listen：监听进程，用于监听服务端下发的同步信息。

• report：值为 true 时，向 master 端发送报告。

• node_name_value：节点名称，默认为主机名。

• certname：认证名称，默认为主机名。

• Server：master 的认证名称，即 certname 变量的值。

6 Puppet 资源简介

资源是 puppet 系统的核心，抽象的足够彻底，相似的资源被抽象成了一种资源类型，如程序包资源、文件资源、服务资源和 exec 资源等。资源属性与其实现方式剥离开来，仅仅描述资源的状态，而不是其具体的实现过程，即可达到资源的同步。

资源定义

资源定义即向资源类型的属性赋值，也称为资源类型的实例化。资源的定义在 pp 文件中完成，其目录结构一般如下所示：

Files 文件夹用于存放该软件包的配置文件，manifests 文件夹用于存放资源的实例，即类文件，templates 用于存放模板。

定义的资源语法如下：

Type 即为资源的类型，比如程序包资源 package，文件资源 file 等，title 是一个字符串，在同一类型中必须唯一，每个属性用“，”隔开。通过将 class、条件控制语句与资源的定义相结合，即可实现资源的模块化，达到易复用的效果。

常用资源

基于公司内部运维组的需求，puppet 主要从程序包、配置文件、服务、exec 四个方面展开应用，本文主要对前两种资源展开介绍。另外，我们可以利用“Puppet describe 资源名称”命令查看资源的详细描述。

1）程序包 package

Package 资源的描述如上图所示，下来我们将对 package 资源的主要属性进行介绍：

• name：包名，可以省略，如果省略，将继承 title 的值。

• ensure：指定软件包的状态，安装、卸载还是升级。需要卸载时，指定为“absent”；需要保证最新版本时，指定为“latest”；需要保证某一版本时，指定为版本号。

• source：指定程序包的来源。如果本地 yum 仓库已经包含该包，则可以不指定。

• provider：指明安装方式。

使用案例如下：

其中，package_name 和 package_ensure 是传入的参数值，通过对属性以参数的形式赋值，可以大大提高模块的复用性。

2）配置文件 file

file 资源的描述如上图所示，下来我们将对 file 资源的主要属性进行介绍：

• ensure：文件的状态，值有 absent、present、file、directory 和 link。

• path：文件路径，不指定时为 title 的值。“ensure=>absent”共用。

• owner：文件的属主。

• Group：文件的属组。

• Mode：文件的权限。

• Source：文件来源。

使用案例如下：

服务和 exec 资源在这里不再赘述，可以利用上述提到的命令，查看资源的详细介绍和参数的使用方法。从以上案例可以看出，采用 puppet 描述语言，结合常用的逻辑控制语句，可以快速的开发出不同资源的类模块。

7 结论

随着服务器集群规模的增大，公司越来越重视通过自动化配置来减小管理部署的成本。Puppet 作为开源的集群管理框架，有着简单易用、快速部署、使用范围广等特性，已经有超过 250 家的用户，包括 Zynga、Twitter、Citrix、Oracle、Shopzilla、Google、RedHat、新浪、阿里巴巴、豆瓣、好乐买、趣游、PPTV 等大公司。本文主要介绍了 puppet 架构、安装方法以及资源的使用案例，属于 puppet 集群管理的基础篇。随着 puppet 集群规模的增大，将来我们会继续介绍 puppet 中的 facter 工具、hiera 工具、模块编写规范、master 集群扩展，逐渐搭建一套大规模、健壮的 puppet 自动化管理集群。

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/oitFRUJ_9LGTdRl7HxyVjQ