自动化运维工具-Puppet

前面已经介绍或一款自动化运维工具Ansible，ansible功能的实现依赖于模块，适用于小型的网络架构，而puppet功能实现是依赖于资源的，把需要实现的某些相同的功能定义为模块，相当于ansible的角色，下面给出一些ansible和puppet的不同点对比
1、服务器端：
puppet：至少包含一个或多个puppet-master服务器，每个客户端安装agent包
ansible：不需要master和agent，只需要一个节点列表（inventory），允许使用SSH连接各个节点
2、拉取/推送模式（pull/push）：
puppet：客户端会定期向服务器端确认，接收或者”拉取”需要被应用的配置
ansible：通过ssh协议将命令发送到远程主机，客户端除了python以外不需要安装其他东西
3、模块：
puppet：使用一些比较基本的组件(资源、类、定义、文件、模板等)自己组合成模块
ansible：在安装时，包含了扩展的自动化模块
4、使用语言：
puppet：基于Ruby搭建，语法格式采用基于Ruby的DSL语言（puppet自己的语言），template模板采用Ruby的ERB
ansible：基于python搭建，语法格式采用YAML格式，模板采用Jinja2语言
5、DevOps工具支持：
都非常好的支持开发运维工具，比如Vagrant, Packer, and Jenkins
6、依赖关系：
puppet：puppet 的manifest中定义的资源在执行时，不是按照顺序依次执行的，是按照任意顺序执行的，除非明确使用了before、require等关键字或者定义依赖关系
ansible：ansible的playbook按照定义的顺序，依次执行
通过对比之后更加清晰的认识到ansible和puppet的不同更方便我们选择使用哪种工具来实现在工作中的需求
对于puppet来说有7种核心资源类型，分别是：file，package,service,notify(信息通知用于记录日志),exec,cron,user,group可以使用puppet describe -l 命令列出有哪些资源
ansible中定义主机各自的配置通过调用模块来实现，而在puppet中每定义一个任务叫做一个资源，所以puppet中是资源清单
puppet严重依赖于主机名因为它是通过证书认证的它识别每一个被管控的主机靠的是证书（证书中的主机都应该有一个主机名以确保此证书对此主机时可用的），所以我们至少应该建立一个内网DNS服务器以确保主机名解析是ok的，不可能使用hosts文件,因为使用hosts文件是极为不便的，最好定义的主机名要见名知义
puppet工作原理
单机模式：使用puppet首先要定义资源清单，然后进行编译，编译生成伪代码叫catalog，之后在本地应用，在应用之前先进行状态查询，最后执行目标状态
非单机模式：每次ansible在运行之前先收集facts而puppet中不用收集，agent会自动报告自己的facts和名称发送给master（server）并向master请求与自己相关的catalog,master收到这个请求后查找（通过主机名来查找）与该主机相关的配置并在master端进行编译，所以每一个agent拿到的都是进行编译后的结果而不是明文文件，拿到伪代码后agent就开始状态查询最后执行目标状态，执行完的结果报告master端，master可以将结果存储于mysql中，也可以不存
注意安装puppet需要使用ruby环境
Puppet的工作过程大体来说分为以下四个方面，如下所示:
1.定义：使用Puppet特定的语言定义基础配置信息。通常我们把这些信息写在Modules中。
2.模板：在配置执行之前检测代码，但并不真正执行。
3.执行：定义的配置自动部署。检测并记录下所发生变化的部分。
4.报告：将期待的变化、实际发生的变化及任何修改发送给报告系统

整个数据流的走向是基于SSL安全协议的，如下图所示:

数据流说明:
1.首先所有的节点（Node）Node节点将Facts和本机信息发送给Master
2.Master告诉Node节点应该如何配置，将这些信息写入Catalog后传给Node。
3.Node节点在本机进行代码解析验证并执行，将结果反馈给Master。
4.Master通过API将数据发给分析工具。报告完全可以通过开放API或与其他系统集成。

模板文件处理过程说明：Puppet通过编译Manifest中的内容 (即模板中内容)，将编译好的代码存入Catalog。在执行前先进行代码的验证，再执行，完成最开始所定义好的状态。代码编译过程如图所示：

下图为整个puppet自动部署过程中agent和master的详细的交互过程:

工作流程说明：
1. Puppet客户端Agent将节点名与facts信息发送给Master。
2. Puppet服务端Master通过分类判断请求的客户端是谁，它将要做什么。这个判断是通过site.pp中包含的Node.pp配置文件定义的。
3. Puppet服务端Master将所需要的Class类信息进行编译后存入Catalog并发送给Puppet客户端Agent，到此完成第一次交互。
4. Puppet客户端Agent对Catalog进行代码验证（语法检查及错误检查）并执行。主要是代码的验证，并将执行过程的信息及结果写入日志。
5. Puppet客户端Agent最终达到最开始所定义的状态，并且将结果及任何执行数据通过开放API的形式发送给Puppet服务端Master。