(特价书)Puppet实战

1.5.1　Puppet基本结构 7
1.5.2　Puppet是如何工作的 8
1.5.3　Puppet数据流 8
1.5.4　文件结合 9
1.5.5　详细交互过程 9
1.5.6　安全与认证 10
1.6　Puppet核心配置文件详解 11
1.6.1　主配置文件puppet.conf 11
1.6.2　主机配置文件site.pp 13
1.6.3　认证与安全配置文件 14
1.6.4　客户端自动认证配置 16
1.6.5　报告系统配置 16
1.6.6　文件系统配置文件 16
1.7　本章小结 17
第2章　Puppet安装与配置 18
2.1　Puppet对各系统平台的支持 18
2.2　Puppet对Ruby的支持 19
2.3　Puppet的安装步骤 19
2.4　在Linux下安装 20
2.4.1　包管理器方式安装 21
2.4.2　从源代码进行安装 23
2.4.3　从Git版本库进行安装 24
2.4.4　通过Gems进行安装 25
2.5　在Mac OS X下安装 25
2.5.1　通过二进制发布包进行安装 25
2.5.2　从Git版本库进行安装 26
2.5.3　从Ports仓库进行安装 27
2.6　配置Puppet 28
2.7　在Windows下安装与使用 30
2.7.1　包管理器方式安装 31
2.7.2　在Windows下使用Puppet 33
2.7.3　Puppet在Windows下的功能 35
2.8　如何升级 35
2.9　本章小结 36
第3章　创建你的第一个Puppet配置 37
3.1　配置一个测试节点 37
3.2　检测你的配置文件 38
3.3　客户端运行配置 39
3.4　查看运行结果 40
3.5　增加httpd模块 40
3.6　本章小结 42
第4章　Puppet运行环境 43
4.1　服务器端配置 43
4.2　客户端配置 44
4.3　如何运用环境配置 45
4.4　本章小结 48
第二部分　基础篇
第5章　Puppet语法与命令详解 50
5.1　Puppet的命名规范 51
5.1.1　资源 51
5.1.2　属性 51
5.1.3　类 52
5.1.4　模块 52
5.1.5　节点 52
5.2　主机、模块和类的命名 53
5.2.1　主机的命名 53
5.2.2　模块的命名 54
5.2.3　类的命名 54
5.3　资源、变量、参数和标签的命名 54
5.3.1　资源的命名 54
5.3.2　变量的命名 55
5.3.3　参数的命名 55
5.3.4　标签的命名 55
5.4　Puppet语法风格 55
5.4.1　间距、缩进和空白字符 56
5.4.2　注释 56
5.4.3　变量的引用 56
5.4.4　资源 57
5.4.5　条件语句 60
5.4.6　类 61
5.5　检查命令的用法 64
5.5.1　语法检查 64
5.5.2　代码调试 65
5.6　Puppet命令详解 66
5.6.1　Puppet常用命令 68
5.6.2　帮助命令详解 73
5.6.3　模块和不常用命令 75
5.7　本章小结 76
第6章　Puppet资源详解 77
6.1　什么是资源 78
6.1.1　图解核心资源 81
6.1.2　什么是manifests 81
6.1.3　资源的依赖 82
6.2　虚拟资源? 85
6.2.1　虚拟资源的定义 85
6.2.2　虚拟资源的用法 86
6.3　常用资源的用法 87
6.3.1　用户资源 88
6.3.2　用户组资源 90
6.3.3　软件安装 91
6.3.4　文件管理 94
6.3.5　服务管理 97
6.3.6　定时脚本 99
6.3.7　执行命令 101
6.3.8　调试与输出 103
6.4　Puppet作用域与变量 104
6.4.1　作用域 104
6.4.2　变量 108
6.5　条件语句 110
6.5.1　if语句 110
6.5.2　case语句 112
6.5.3　selector选择器 112
6.6　表达式 113
6.6.1　什么是表达式 113
6.6.2　运用位置 114
6.6.3　操作顺序 114
6.6.4　比较运算符 114
6.6.5　布尔运算符 115
6.6.6　算术运算符 116
6.7　函数 116
6.8　数据类型 118
6.8.1　布尔类型 118
6.8.2　未定义 119
6.8.3　字符串 119
6.8.4　资源引用 120
6.8.5　数字 120
6.8.6　哈希类型 121
6.8.7　正则表达式 121
6.8.8　数组 122
6.9　标签 123
6.10　stage运行阶段 123
6.11　本章小结 124
第7章　Puppet模块、类、模板 125
7.1　图解模块结构 125
7.2　模块管理 126
7.2.1　实例：创建一个模块 127
7.2.2　模块布局 129
7.3　类管理 130
7.3.1　类的定义 131
7.3.2　类的继承 131
7.3.3　参数化类 132
7.4　模板管理 135
7.4.1　定义与声明 135
7.4.2　ERB模板语法 136
7.5　融合 139
7.6　从Puppet Forge获取模块 141
7.7　从Example42获取模块 142
7.8　本章小结 143
第8章　节点管理 144
8.1　什么是节点 144
8.2　主机名命名规范 145
8.3　节点继承 146
8.3.1　节点继承关系 146
8.3.2　继承变量覆盖 147
8.3.3　默认类与默认节点 147
8.3.4　节点继承的判断 148
8.4　节点管理方法 149
8.4.1　每个主机名独立 149
8.4.2　采用正则匹配 150
8.4.3　使用外部节点分类器 150
8.4.4　利用WEB-UI管理 153
8.5　如何选择合适的管理方式 154
8.6　本章小结 154
第9章　认识Facter 155
9.1　什么是Facter 155
9.2　Facter的作用与特点 156
9.3　Facter的常用变量 157
9.3.1　操作系统名 158
9.3.2　操作系统相关 159
9.3.3　主机名 159
9.3.4　IP地址 160
9.3.5　内存管理 160
9.3.6　系统状态信息 161
9.3.7　版本管理 161
9.4　如何自定义fact 162
9.5　案例一：条件语句 164
9.6　案例二：匹配不同硬件配置 165
9.7　本章小结 167
第10章　小标签大用途 168
10.1　Puppet标签的定义 168
10.2　Puppet标签的说明 168
10.2.1　自动分配标签 169
10.2.2　tag元参数 169
10.2.3　tag函数 170
10.2.4　tagged函数 171
10.2.5　识别标签 171
10.3　指定标签运行特定配置 172
10.3.1　在命令行中指定特定标签 172
10.3.2　在配置文件中指定 174
10.3.3　在Node节点配置中指定 174
10.4　标签的更多用法 175
10.4.1　在收集资源中使用 175
10.4.2　实例化资源 175
10.4.3　创建资源集合 176
10.5　本章小结 176
第三部分　实战篇
第11章　大规模Nginx集群部署方案 178
11.1　应用场景 178
11.2　场景需求分析 178
11.2.1　日常变更分析 178
11.2.2　网络及架构分析 179
11.2.3　软件安装分析 180
11.2.4　软件配置分析 180
11.2.5　节点管理分析 181
11.3　合理规划 181
11.3.1　系统安装 181
11.3.2　系统初始化 182
11.3.3　部署规划 182
11.3.4　关注点 183
11.4　实施步骤 183
11.4.1　前期准备：创建软件仓库 183
11.4.2　Puppet配置文件管理 185
11.4.3　初始化操作系统 187
11.4.4　编写nginx模块 187
11.4.5　采用Forge的nginx模块 192
11.5　本章小结 194
第12章　分布式监控系统部署方案 195
12.1　利用Puppet部署Zabbix 196
12.1.1　Zabbix简介 196
12.1.2　Zabbix架构 197
12.1.3　利用Puppet部署Zabbix 198
12.1.4　Zabbix自定义监控 201
12.2　利用Puppet部署Nagios 202
12.2.1　Nagios简介 202
12.2.2　Nagios架构 203
12.2.3　Nagios服务端安装 204
12.2.4　Nagios模块应用 206
12.2.5　创建Nagios客户端监控 208
12.3　本章小结 210
第13章　OpenStack快速部署方案 211
13.1　OpenStack简介 211
13.1.1　什么是OpenStack 211
13.1.2　OpenStack的组件、服务及逻辑架构 212
13.1.3　OpenStack版本说明 213
13.2　部署OpenStack 214
13.2.1　环境准备 214
13.2.2　安装软件及Puppet模块 216
13.2.3　部署controller 218
13.2.4　部署compute 220
13.2.5　验证OpenStack部署 221
13.3　本章小结 222
第四部分　进阶篇
第14章　Puppet版本控制 224
14.1　Puppet版本控制方法 224
14.1.1　为什么要使用版本控制 224
14.1.2　版本控制的架构与原理 225
14.1.3　Git与SVN的区别 226
14.1.4　为什么采用Git 226
14.2　使用Git实现Puppet 226
14.2.1　安装与配置Git 227
14.2.2　将Puppet加入Git 228
14.2.3　使用Rake自动更新副本 229
14.2.4　使用hook实现自动语法检查 231
14.3　本章小结 232
第15章　Puppet架构扩展与分布式 233
15.1　Puppet瓶颈分析 233
15.1.1　单台Puppet Master瓶颈 233
15.1.2　认证的瓶颈 234
15.1.3　文件的瓶颈 234
15.1.4　网路的瓶颈 234
15.2　架构扩展之单台Puppet Master 234
15.2.1　Nginx+Mongrel模式 235
15.2.2　Apache+Passenger模式 238
15.2.3　Nginx+Passenger模式 242
15.3　架构扩展之多台Puppet Master 244
15.3.1　配置前的准备 248
15.3.2　Puppet CA认证服务器部署 250
15.3.3　Puppet LB负载均衡器部署 251
15.3.4　Puppet Master服务器部署 252
15.3.5　Puppet客户端配置 254
15.3.6　验证架构 254
15.4　架构扩展之利用Git构建分布式的Puppet 254
15.4.1　实现原理 255
15.4.2　安装与部署 256
15.5　本章小结 259
第16章　File资源管理优化 260
16.1　深入理解File资源? 260
16.2　操作实践 262
16.3　File资源配置方法? 269
16.3.1　模块文件目录配置 269
16.3.2　统一文件目录配置 270
16.3.3　content属性 271
16.4　File资源的优化 271
16.4.1　配置Nginx代理 272
16.4.2　选择File资源还是ERB 272
16.4.3　大文件下发方法 272
16.5　从filebucket检索文件 272
16.6　备份与恢复文件 275
16.7　File资源的缺点 276
16.8　本章小结 276
第17章　强大的报告系统 277
17.1　report介绍 277
17.2　Puppet信息记录方式 278
17.3　tagmail发送邮件报告 279
17.4　rrdgraph图形化报告 280
17.5　自定义报告处理器 282
17.6　本章小结 284
第18章　必须了解的控制台 285
18.1　Puppet DashBoard 285
18.1.1　简介 285
18.1.2　DashBoard安装 285
18.1.3　配置DashBoard 287
18.1.4　集成DashBoard 292
18.2　Foreman 297
18.2.1　Foreman简介 297
18.2.2　安装Foreman 298
18.2.3　配置Foreman 303
18.2.4　使用Foreman管理Puppet 311
18.2.5　从Foreman显示报告 313
18.2.6　Foreman其他功能 314
18.3　本章小结 314
第19章　Puppet扩展工具 315
19.1　生成HTML文档 315
19.1.1　利用puppet doc生成HTML 316
19.1.2　puppet doc的其他使用方法 318
19.2　生成依赖关系图 319
19.2.1　什么是关系图 319
19.2.2　配置方法 319
19.2.3　关系图说明? 322
19.3　PuppetDB 322
19.3.1　PuppetDB功能与特性 322
19.3.2　安装PuppetDB 324
19.3.3　PuppetDB配置文件详解 326
19.3.4　配置与使用PuppetDB 329
19.3.5　PuppetDB瓶颈 332
19.4　Hiera 335
19.4.1　Hiera的特点 335
19.4.2　Hiera的使用 335
19.5　本章小结 335
第20章　MCollective结合 336
20.1　MCollective简介 336
20.1.1　什么是MCollective 336
20.1.2　MCollective角色互换 337
20.1.3　MCollective的特点 338
20.1.4　MCollective给Puppet带来的改变 338
20.2　消息中间件 339
20.2.1　Stomp 339
20.2.2　ActiveMQ 339
20.2.3　RabbitMQ 339
20.3　标准化部署MCollective 340
20.3.1　体系结构与配置 340
20.3.2　安全模型 340
20.3.3　未来扩展 341
20.4　部署MCollective步骤 341
20.4.1　创建和收集证书 342
20.4.2　部署和配置中间件 344
20.4.3　MCollective安装与配置 348
20.5　如何使用MCollective 355
20.5.1　mco基本命令的用法 355
20.5.2　执行RPC请求 356
20.5.3　过滤器的使用 358
20.6　MCollective使用 Shell Commands 359
20.7　MCollective控制Puppet 360
20.8　本章小结 362

.　　勘误和支持
　　由于作者的水平有限，加之编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。为此，我特意在博客（http://liuyu.github.io）的基础上开辟了在线支持与应急方案的站点http://puppet.bubbyroom.com。你可以将书中的错误以及遇到的有关Puppet的任何问题，通过访问该站点的Q&A页面提交给我。书中的全部源文件除可以从华章网站①下载外，还可以从这个站点下载。同时我也会将相应的功能更新在这个站点上及时发布出来。如果你有更多的宝贵意见，也欢迎发送邮件至邮箱liuyu105#gmail.com（sed 's/#/@/g'），标题请注明《Puppet实战》，期待能够得到你们的真挚反馈。同样你也可以关注我为本书建立的微信公共平台（puppetchina），我会在此公共平台定期发布Puppet相关信息。
　　致谢
　　首先要感谢伟大的Puppet作者Luke Kanies，他开发了一款影响我整个人生的软件。
　　特别感谢刘长元、王广胜、吴问志、刘继伟、王哲，感谢你们对本书提出的宝贵修改意见。
　　感谢为本书撰写的童剑先生、窦哲先生、田逸先生、程辉先生，感谢你们在繁忙的工作中抽出时间，阅读了本书的样稿并写下推荐和评论。
　　感谢机械工业出版社华章公司的编辑杨福川，是你的引导才促使我完成这本书。特别感谢姜影编辑，在这一年多的时间中始终帮我校对并支持我的写作，你的鼓励和帮助引导我顺利完成全部书稿。
　　最后感谢我的笨笨，一如既往地支持我写作，给予我无尽的支持与灵感，并时时刻刻为我灌输着信心和力量！
　　谨以此书献给我即将出生的Baby，以及众多热爱Puppet的朋友们！
　　刘宇（守住每一天）
　　于中国北京
　　

.　　1.1.3版本语言特征
　　Puppet各版本之间的语言也存在着差异，当然，版本越高，支持的特征越多，具体如表1-1所示。
　　表1-1Puppet各版本语言特征差异对比语法 0.24.x 0.25.x 2.6.x 2.7.x 3.x
　　运算符 支持 支持 支持 支持 支持
　　多资源的关系 支持 支持 支持 支持 支持
　　类的继承 支持 支持 支持 支持 支持
　　追加变量 支持 支持 支持 支持 支持
　　类命名 支持 支持 支持 支持 支持
　　C注释风格 支持 支持 支持 支持 支持
　　节点正则 不支持 支持 支持 支持 支持
　　变量表达式 不支持 支持 支持 支持 支持
　　正则表达式 不支持 支持 支持 支持 支持
　　条件表达式 不支持 不支持 支持 支持 支持
　　链接资源 不支持 不支持 支持 支持 支持
　　哈希 不支持 不支持 支持 支持 支持
　　类的参数化 不支持 不支持 支持 支持 支持
　　运行阶段 不支持 不支持 支持 支持 支持
　　In语法 不支持 不支持 支持 支持 支持
　　Unless语法 不支持 不支持 不支持 不支持 支持
　　1.1.4命令差异
　　Puppet命令在2.6版本发布时进行了变更，且在发布3.0版本时将2.6版本之前的旧命令完全丢弃。具体差异对比如表1-2所示。
　　表1-2不同版本Puppet的命令差异对比
　　2.6版本之前 2.6版本之后
　　Puppetmasterd Puppet master
　　Puppetd Puppet apply
　　Puppetca Puppet cert
　　Ralsh Puppet resource
　　Puppetrun Puppet kick
　　Puppetqd Puppet queue
　　Filebucket Puppet filebucket
　　Puppetdoc Puppet doc
　　Pi Puppet describe
　　1.1.5Puppet 3.0新特性
　　目前Puppet最新版为3.0，其中增添了许多新特性。
　　性能提升：目录编译采用JSON作为目录缓存。
　　增强操作系统与平台支持：对Ruby1.9的完美支持，对操作系统Windows、Solaris包和服务的更多支持，Yumrepo对SSL的支持。
　　使用Rubygems加载插件：可以通过Rubygems来安装和使用Puppet的扩展代码。
　　Server自动发现：通过DNS SRV寻找CA、Master、Report和Fileserver。
　　DSL/config变化：auth.conf增加allow_ip配置选项，unless支持，插件同步默认改为True，更新configure的语法。
　　其他BUG的修复：修复了3.0 Agent 与2.7Master工作的问题、kick无法工作问题、rack安装启动出错问题等。
　　 注意
　　Puppet 3.0将不再支持Ruby 1.8.5以下版本。
　　1.2为什么要使用Puppet
　　1.2.1都有谁在使用Puppet
　　在笔者编写本书时，Puppet已拥有250家客户，包括Zynga、Twitter、纽约证券交易所、迪斯尼、Citrix、Oracle/Sun、Constant Contact、Match.com、Shopzilla、Google、RedHat等。国内越来越多的大公司也在使用Puppet，例如新浪、阿里巴巴、百度、腾讯、奇虎360、小米、United Stack、豆瓣、好乐买、趣游、PPTV等。
　　1.2.2常见集中化管理工具对比
　　目前开源的工具非常多，很多人在选择的时候犹豫不定，不知道哪个好。如果担心在使用过程中遇到问题没有人回答，资料太少而无从查起，那么选择当前最流行的工具无疑是最明智的。现在毫无疑问，应该选Puppet。
　　针对当前开源的配置管理工具，这里进行简单的汇总：Puppet、Chef、Func、Fabric、Capistrano、Cfengine等。下面我们就最常用的Puppet与Chef进行简单对比，主要是从用户、开发、平台、实例等几个角度出发，帮助读者从中发现Puppet的优势。在用户与第三方支持方面，Puppet更胜于Chef。详细对比如表1-3所示。
　　表1-3Puppet 和Chef对比
　　 Puppet Chef
　　使用用户 Google、RedHat、Apple、Sina、… Admeld…
　　开发支持 第三方Foreman 无
　　商业运行 Enterprise Enterprise
　　程序语言 Php、Django、Ruby、… Ruby
　　文档环境 Mail-List、IRC Mail-List、IRC
　　平台支持 ALL os 较多
　　现成实例 Example42 无
　　依赖关系 灵活处理 无
　　 提示
　　Puppet所支持的操作系统：http://docs.puppetlabs.com/guides/platforms.html
　　Chef所支持的操作系统：http://wiki.opscode.com/display/chef/Installing+Chef+Server Chef
　　使用者：http://www.opscode.com/customers/ Puppet
　　使用者：http://projects.puppetlabs.com/projects/1/wiki/Whos_Using_Puppet
　　1.2.3推荐Puppet的理由
　　有很多人问笔者：学习Puppet是否需要具有开发基础？是否需要会Ruby？笔者的回答都是“不需要”。其实我们使用任何一个工具，都不需要掌握此工具所采用的语言，只要会使用工具即可。如何更深入地理解工具的特性，最大化地发挥出它的优势才是我们的首要任务，除非想在它的基础上做二次开发。通常做二次开发都有现成的框架，调用工具的API接口即可完成。因此我们不需要掌握这类开发语言。而且开发类语言都互通的，掌握一门，其他的学起来也不难。初学者在入门时一定要意识到这一点：明确自己的目的，而不要被工具本身吓住了，“Just Do It”。
　　1.3Puppet的作用和特色
　　1.3.1为什么要有自己的语言
　　为什么不使用XML or YAML配置格式？为什么不直接采用Ruby输出？Puppet开发者非常巧妙地用一个反问回答了这个问题：在使用浏览器访问网站的时候为什么不直接读HTML呢？所以说Puppet使用自有语言是为了更好地处理人机接口。而Ruby输出实际上在Puppet2.6版本中已经支持，只是没有当做主输出而已。
　　1.3.2为什么是Ruby
　　用Kanies的话来说，Ruby太适合Puppet了。最开始Kanies的大量工作都是使用Perl语言来完成的，然而当他想要开发工具时，发现在Perl中得不到想要的类关系。于是试用了一下Python，虽然很多人都说它非常棒，但也满足不了需求。这时有人说Ruby很酷，Kanies进行了尝试，没想到4个小时就做出了所需工具的原型。为此直到后来为Puppet Labs选择语言时，Kanies一直也没有后悔选择了Ruby。因此选择适合自己的语言才是硬道理。我们不能一味地追求时尚，就像我们选择Puppet一样。
　　1.3.3管理任何机器
　　目前Puppet支持所有的客户端，主流的有RedHat、Centos、Gentoo、FreeBSD、Debian、OpenBSD、Mac os x、Ubuntu、SuSE、Solaris、Windows等。我们不需要担心所管理的设备无法使用Puppet，它已经尽可能地支持一切操作系统。不过使用Windows的朋友需要注意：目前Puppet所支持的资源有File、Package、Host、Group、Service、Exec，支持的类型有限。不过刚刚发布的Puppet3.0对Windows的支持进行了加强。
　　 提示
　　更多信息可参考http://docs.puppetlabs.com/windows/writing.html。
　　处理资源与资源之间的依赖关系是Puppet的优势。Puppet管理一台主机的整个生命周期，即初始化安装、升级、维护、服务迁移及下载。在Puppet世界中，一台主机的每个生命周期内的每个动作都被抽象成一个“资源”。我们更多的是要维护一台主机上的每个“资源”，梳理好关系后将其交给Puppet维护。对于系统管理员而言，一切的配置将变得简单而有趣。后续我们将在第6章讲解Puppet的资源。
　　1.4Puppet组织结构
　　在了解了什么是Puppet后我们再来看它的组织结构，以便在后续章节中能更好地掌握其工作原理。
　　通常在安装好Puppet之后的/etc/puppet目录下运行tree就能看到下面的树结构：
　　/-- auth.conf #ACL权限控制文件
　　/-- fileserver.conf #文件服务配置文件
　　/-- manifests #节点存储目录（Puppet会首先加载site.pp）
　　/ `-- site.pp #定义Puppet变量和默认配置
　　/-- modules #模块配置目录
　　/ `-- nginx #以Nginx为例
　　/ /-- manifests
　　/ / `-- init.pp #模块主配置文件，定义类class相关信息。读取模块后先读取它
　　/ `-- templates
　　/ `-- nginx.conf.erb #模板配置文件(erb为主)
　　/-- namespaceauth.conf #命名空间配置文件（配置权限）
　　/-- puppet.conf #Puppet主配置文件
　　`-- tagmail.conf #邮件报告配置文件
　　 注意
　　不同安装包的树结构会不一样，为了便于读者理解，这里仅对主要的配置文件进行了说明。
　　1.5Puppet工作原理
　　下面进入本章重点——Puppet工作原理，这部分将分别从基本结构、Puppet是如何工作的、数据流、文件结构、详细交互过程等几方面循序渐进地讲解，以便读者理解并掌握这些知识。
　　1.5.1Puppet基本结构
　　我们先看一下Puppet基本结构，如图1-1所示。Puppet模块的编写主要是：应用程序、文件、服务及操作系统底层相关。客户端解析完成后发送给报告系统（见图1-1右上角）。
　　图1-1Puppet基本结构
　　1.5.2Puppet是如何工作的
　　接着我们来看一下Puppet是如何工作的。简单来说分4步进行。
　　1）定义：使用Puppet特定的语言定义基础配置信息。通常我们把这些信息写在Modules中。
　　2）模拟：在配置执行之前检测代码，但并不真正执行。
　　3）执行：按步骤1）定义的配置自动部署。检测并记录下所发生变化的部分。
　　4）报告：将期待的变化、实际发生的变化及任何修改发送给报告系统。
　　整个工作过程如图1-2所示。
　　1.5.3Puppet数据流
　　在了解了Puppet如何工作之后，我们需要继续了解它的数据流走向。
　　1）Node节点将Facts和本机信息发送给Master。
　　2）Master告诉Node节点应该如何配置，将这些信息写入Catalog后传给Node。
　　3）Node节点在本机进行代码解析验证并执行，将结果反馈给Master。
　　4）Master通过API将数据发给分析工具。报告完全可以通过开放API或与其他系统集成。
　　整个数据流的走向是基于SSL安全协议的，如图1-3所示。
　　图1-3Puppet数据流
　　1.5.4文件结合
　　在Puppet组织结构中我们了解了Puppet的树结构。那么结合数据流，这些目录的关系是如何关联起来的呢？
　　1）Puppet通过编译Manifest中的内容，将编译好的代码存入Catalog。
　　2）在执行前先进行代码的验证，再执行，完成最开始所定义好的状态。
　　代码编译过程如图1-4所示。
　　1.5.5详细交互过程
　　通过以上的学习，相信大家应该对Puppet的工作原理有了基本的了解，接下来我们将分析Puppet的Agent与Master的详细交互过程。通过学习这部分内容，可加深对Puppet的理解，以便在今后的使用过程中遇到任何问题都能在大脑中呈现如图1-5所示的内容，进而能快速定位故障并解决它。所有交互过程都是建立在签发证书的前提下执行的。
　　1）Puppet客户端Agent将节点名与facts信息发送给Master。
　　2）Puppet服务端Master通过分类判断请求的客户端是谁，它将要做什么。这个判断是通过site.pp中包含的Node.pp配置文件定义的。
　　3）Puppet服务端Master将所需要的Class类信息进行编译后存入Catalog并发送给Puppet客户端Agent，到此完成第一次交互。这一步是1.5.4节的内容。
　　4）Puppet客户端Agent对Catalog进行代码验证（语法检查及错误检查）并执行。主要是代码的验证，并将执行过程的信息及结果写入日志。
　　5）Puppet客户端Agent最终达到最开始所定义的状态，并且将结果及任何执行数据通过开放API的形式发送给Puppet服务端Master。
　　Puppet Master和Puppet Agent的交互过程如图1-5所示。
　　图1-5Puppet Master与Puppet Agent详细交互过程
　　1.5.6安全与认证
　　Puppet通信都采用SSL安全加密协议，以保障所有数据传输的安全性，为此我们不用担心数据的安全性问题。通常我们使用Puppet管理设备时也有可能建立在公司内网的基础之上，这样就更加安全了。当然，即使你所在的公司没有属于自己的内网也没有关系，Puppet所采用的SSL安全加密协议已经为我们解决了数据传输的安全问题。
　　 提示
　　SSL（Secure Sockets Layer， 安全套接层）及其继任者TLS（Transport Layer Security，传输层安全）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。
　　在学习了Puppet安全之后，我们来学习Puppet的认证。由于Puppet采用的是SSL加密协议，因此申请证书验证是必需的。
　　Puppet Master在启动后会向自己签发证书和key。我们可以在/var/puppet/ssl（3.1版本在/var/lib/puppet/ssl/下面）目录下看到它们。
　　Puppet Agent 在运行puppet apply --test时添加参数（--verbose），可以在客户端终端看到申请证书的详细过程。
　　Puppet Master同样也可以使用puppet cert list查看申请证书的客户端列表。使用命令puppet cert signagent_name来签发证书。
　　Puppet Agent就可以收到notice:Finished等相关字样。如果Master一直不签发证书，客户端会每2分钟请求一次。
　　证书相关的命令将会在第5章详细讲解。
　　Puppet只允许经过安全认证的客户端发送请求，这极大地保证了数据的安全。同时当客户端发起https://master.domain.com:8140/{environment}/{resource}/{key}这样的请求时，我们需要配置auth.conf与namespaceauth.conf。有关这两个配置文件详见1.6节。
　　 思考
　　当客户端要输出“Hello World!”时，整个Puppet的数据流走向？
　　1.6Puppet核心配置文件详解
　　在学习了Puppet原理及版本差异后，我们需要掌握它的核心配置文件。Puppet所有的配置都围绕着Puppet.conf展开。读者可以回顾在1.4节讲的组织结构，以便快速掌握本节内容。
　　1.6.1主配置文件puppet.conf
　　主配置文件puppet.conf主要用于设置相关的参数、认证文件、文件系统配置文件、插件配置等。Puppet版本不同，配置选项命名方式也有所不同。Puppet 2.6以前的命名方式还以[puppetmaster]、[puppetagent]为主。Puppet 2.6以后都以[main]、[master]、[agent]为主。为了防止读者混淆，建议都采用Puppet 2.6以上版本。本书都以Puppet 2.6以上版本为主。
　　先看如何生成Puppet配置文件puppet.conf：
　　puppetd --genconfig> /etc/puppet/puppet.conf
　　puppetmasterd--genconfig> /etc/puppet/puppet.conf
　　以上命令会覆盖Puppet.conf原文件。
　　在本地用如下命令查看配置参考手册：
　　puppet doc --reference configuration
　　如果不知道配置文件在哪个目录下，可以使用以下命令查看：
　　puppet agent --configprint confdir
　　默认目录是/etc/puppet。
　　由于puppet.conf配置文件内容较多，下面笔者将列举核心配置、常用配置选项（不区分Master与Agent）：
　　[main] #通用配置选项
　　vardir = /var/lib/puppet
　　confdir = /etc/puppet
　　logdir = /var/log/puppet
　　rundir = /var/run/puppet
　　ssldir = $vardir/ssl
　　fileserverconfig = /etc/puppet/fileserver.conf
　　manifestdir = /etc/puppet/manifests#可不指定默认读取此目录
　　manifest = /etc/puppet/manifests/site.pp#主机文件默认读取
　　modulepath = /etc/puppet/modules:/usr/share/puppet/modules
　　authconfig = /etc/puppet/namespaceauth.conf
　　 #如果开启Listen为true需要配置此文件
　　pluginsync = true#插件同步配置对facter自定义有效
　　reportdir = /var/lib/puppet/reports
　　 #报告文件生成目录，目录以主机名命令开头
　　reports = log, foreman#报告的方式与类型
　　 # environment = production 运行环境配置，默认为生产环境
　　[agent]#客户端配置选项
　　classfile = $vardir/classes.txt
　　localconfig = $vardir/localconfig
　　runinterval = 1800#客户端默认探测时间，可按需求修改
　　listen = true#是否监听，执行puppet kick时需要配置
　　report = true#客户端的报告系统配置，不同于Master
　　#此项的主要目的是将报告发送至Master，主要用于客户端puppet.conf配置
　　report_port = 8140 #监听端口，如果服务器配置有防火墙，需开放此端口
　　report_server = server #默认不填，此时以下面的$server变量值为准
　　server = server.domain.com
　　[master]#服务端配置选项
　　certname = server.domain.com #也可以不定义，以主机名为准
　　reports = store, http, tagmail, log
　　reporturl = http://server.domain.com:3000/reports/upload
　　#报告发送地址，可配置在dashboard或foreman配置文件中
　　#有关报告系统的配置我们将在第17章讲解
　　autosign = /etc/puppet/autosign.conf#自动认证配置文件
　　 提示
　　不同版本的配置文件可参考：http://docs.puppetlabs.com/references/。
　　通常我们应该如何配置主配置文件呢？下面分别进行介绍。
　　Puppet Master服务器端主配置文件——puppet.conf。
　　[main] #全局配置
　　#vardir用来存放缓存数据、配置、客户端传回的报告及文件备份
　　vardir = /var/lib/puppet
　　# Puppet日志文件配置目录默认为'$vardir/log'
　　logdir = /var/log/puppet
　　#PID文件目录，默认为'$vardir/run'
　　rundir = /var/run/puppet
　　#SSL签发认证文件目录，默认为 '$confdir/ssl'
　　ssldir = $vardir/ssl
　　[master]#服务器端配置
　　pluginsync = true #开启插件同步
　　reports = log, foreman #报告发送至log和foreman
　　environment = production #指定运行环境为生产环境
　　certname = server.domain.com #配置主机名为server.domain.com
　　Puppet Agent客户端主配置文件——puppet.conf。
　　[main]
　　logdir = /var/log/puppet
　　rundir = /var/run/puppet
　　ssldir = $vardir/ssl
　　pluginsync = true
　　[agent] #客户端配置
　　#关联与检索配置文件目录，默认为 '$confdir/classes.txt'，也可以使用
　　#(--loadclasses)参数指定
　　classfile = $vardir/classes.txt
　　#本地缓存配置目录，默认为'$confdir/localconfig'
　　localconfig = $vardir/localconfig
　　runinterval = 1800 #检测时长1800秒，30分钟
　　listen = true #监听进程
　　report = true #发送报告
　　server = puppet.domain.com #指定Master地址
　　1.6.2主机配置文件site.pp
　　site.pp的目的主要是告诉Puppet去哪里寻找并载入所有主机相关的配置。site.pp默认存放在/etc/puppet/manifests目录中。通常我们在会此文件中定义一些全局变量。
　　 注意
　　“清单”（Manifests）是Puppet中的术语，指的是包含配置信息的文件。清单文件的后缀是.pp。
　　生成Puppet主机配置文件site.pp的命令如下：
　　puppet apply --genmanifest> /etc/puppet/manifests/site.pp
　　通常不使用以上命令生成site.pp配置文件，主要填写的内容为：
　　# site.pp - all agent configure
　　Exec { path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }
　　#设置环境变量
　　$fileserver = "puppet.domain.com" #指定全局fileserver变量
　　$ntpserver = "ntp.domain.com" #指定ntpserver变量
　　#建议读者动手配置以上内容
　　Package { provider => "yum" } #指定软件包的安装方法为yum
　　#可以直接写节点配置文件，在所有Agent上创建其内容为"Hello World"的
　　#/tmp/temp1.txt文件
　　#node default {
　　# file { "/tmp/temp1.txt": content => "Hello World!"; }
　　# }
　　import "modules.pp"#加载模块配置文件，可以不配置
　　import "nodes/*.pp"#加载主机信息，可以使用通配符，也可以定义多组目录
　　import "test.domain.com.pp"#加载测试主机
　　1.6.3认证与安全配置文件
　　namespaceauth.conf文件用于指定允许谁访问每个名称空间。要创建namespaceauth.conf文件必须添加对每个名称空间的访问权限。以下就是针对不同名称空间的权限配置，通常不用做大的变动。
　　以下是配置的内容：
　　[fileserver]
　　 allow *.domain.com
　　[puppetmaster]
　　 allow *.domain.com
　　[puppetrunner]
　　 allow culain.domain.com
　　[puppetbucket]
　　 allow *.domain.com
　　[puppetreports]
　　 allow *.domain.com
　　[resource]
　　 allow server.domain.com
　　 注意
　　当puppet.conf配置Listen=true时必须要配置此文件，否则Puppet启动时会报出“Will not start without authorization file /etc/puppet/namespaceauth.conf”的错误提示。
　　auth.conf认证配置文件是Puppet中的ACL，主要应用于Puppet’s REST API。例如，当客户端请求https://yourpuppetmaster:8140/{environment}/{resource}/{key}时，服务器可以根据资源定义访问权限。其配置的参考如下：
　　# 以auth.conf为例
　　path /
　　auth any
　　environment override
　　allow magpie.example.com
　　path /certificate_status
　　auth any
　　environment production
　　allow magpie.example.com
　　path /facts
　　method save
　　auth any
　　allow magpie.example.com
　　path /facts
　　auth yes
　　method find, search
　　allow magpie.example.com, dashboard.example.com
　　只看上面auth.conf配置文件，读者可能难以理解配置文件的意义，参考Puppet ACL配置语法就容易理解了。其语法规则如下：
　　path [~] {/path/to/resource/regex} #目录配置
　　[environment {list of environments}] #环境配置
　　[method {list of methods}] #方法命令配置
　　[auth[enthicated] {yes/no/on/off/any}] #授权配置
　　[allow {hostname/certname/*}] #允许配置
　　我们再来看auth.conf的配置文件：
　　path /facts
　　auth yes
　　method find, search
　　allow magpie.example.com, dashboard.example.com
　　#现在就不难理解这段配置的意思了。允许主机名为"magpie.example.com"和
　　#"dashboard.example.comd的两台客户端在facts目录进行find和search操作
　　 提示
　　详细信息可参考：http://docs.puppetlabs.com/guides/rest_auth_conf.html。
　　1.6.4客户端自动认证配置
　　autosign.conf允许配置文件中的客户端自动进行签名验证，省去人工交互的过程。这对自动化配置来说省去了很多工作。在下一章介绍安装时也会讲到。
　　配置文件参考如下：
　　#允许单一客户端或者域名匹配，主机名匹配
　　rebuilt.example.com
　　*.scratch.example.com
　　*.local
　　同时Puppet客户端的证书也可以采用提前在Master上生成的方法，将生成的证书文件复制到客户端对应目录下，以实现自动认证的配置。
　　自动生成证书的命令为：
　　puppet cert generate client.domain.com
　　这时将在本地生成client.domain.com客户端证书文件，文件及其所在目录为：
　　/var/lib/puppet/ssl/private_keys/client.domain.com.pem
　　/var/lib/puppet/ssl/certs/client.domain.com.pem
　　/var/lib/puppet/ssl/certs/ca.pem
　　将这些文件复制到客户端相同的目录下即可。
　　1.6.5报告系统配置
　　tagmail.conf将配置的Puppet报告以邮件形式按要求发送给收件人。要使用此项功能，需要在Puppet Master端配置reports=tagmail，需要在Puppet Agent端配置report=true，同时也可以配置smtp由谁来发送。在Puppet Master端配置reportform为smtpserver or sendmail即可。默认由本机sendmail发送。
　　all: log-archive@example.com
　　webserver, !mailserver: httpadmins@example.com
　　emerg, crit: james@example.com, zach@example.com, ben@example.com
　　#日志的级别可以是：debug、info、notice、warning、err、alert、emerg、crit或者 verbose
　　#也可以是一个类的名字class names，一个标签名tags
　　1.6.6文件系统配置文件
　　fileserver.conf是一项安全配置，结合puppet.conf、auth.conf一起使用。配置Puppet客户端允许/禁止访问Master的文件目录。fileserver.conf的使用非常灵活，我们将在第16章节来讲解它的优化及配置。fileserver.conf配置如下：
　　# 配置方法
　　[mount_point]
　　path /path/to/files
　　allow *.example.com
　　deny *.wireless.example.com
　　#举例：允许通配主机为"*.domain.com"的主机获取/etc/puppet/files目录下
　　#的文件。以下为其配置方法
　　[files]
　　path /etc/puppet/files
　　allow *.domain.com
　　1.7本章小结
　　通过对本章的学习，我们首先了解了Puppet的发展历程、各版本存在的差异、Puppet 2.6版本的大幅度变动、Puppet 3.0版本的最新特征。接着通过学习Puppet组织结构、Puppet的工作原理、核心配置文件的相关知识，使读者能够熟练掌握Puppet的基本用法和工作原理。
　　如果你没有了解过Puppet，通过本章便能大致了解Puppet是什么、它有什么用途、是否适合在你的环境当中使用。如果你用过Puppet并有使用经验，通过本章的学习能够更深入地掌握它的原理。
　　将Puppet原理及核心信息放在第1章来讲解，是为了让大家能更全面地了解Puppet，毕竟任何一款软件的使用都离不开基础原理的掌握。
　　接下来一章将介绍Puppet在不同操作系统平台的安装与使用。