前面我们讲到关于puppet的工作模式中部署层的理解，本节主要会讲到配置语言和资源抽象层和事物层
1.1.2 配置语言和资源抽象层
Puppet使用一种描述性语言来定义配置项，配置项在Puppet中被称为"资源"。这种描述的本质使得Puppet和许多其他配置工具之间产生了重要的差别。描述性语言可以声明你的配置的状态--比如，声明一个软件包应该被安装或者一个服务应该被启动。
大部分配置工具，如shell或者Perl脚本，是命令式或者过程式的。它们描述的是事情应该怎么做而不是所需要的最终状态应该如何--比如，大部分用来管理配置的定制脚本都应当被看作命令式的。
这就意味着Puppet的用户只需要声明他们的主机应该处于什么状态即可：比如什么软件包应该被安装，什么服务应该被运行。使用Puppet，系统管理员不需要关心如何达到这种状态--那由Puppet负责。相反，我们关心的是如何将主机的配置抽象到一个个资源中。
(1) 配置语言
描述性语言的实质是什么？让我们看一个简单的例子。这里有一个包括Red Hat企业版Linux、Ubuntu以及Solaris的主机环境，我们需要在所有的主机上安装vim程序。如果手工来做，我们需要写一个脚本来完成下面这些事情：
连接到目标主机（包含输入密码或者提供密钥）；
检查是否安装了vim；
如果没有，使用每个平台上适当的命令来安装它，比如在Red Hat上使用yum命令，在Ubuntu上使用apt-get命令；
可能还包括报告结果以确保命令成功完成。
注意 如果你需要升级已经安装的vim或者应用vim的一个特定版本的时候，上面的步骤会变得更加复杂。
Puppet使用不同的方式来完成这一过程。我们在Puppet中为vim包定义一个配置资源。每个资源都由一个类型（表明被管理的是什么样的资源：软件包、服务或者定时任务等）、一个标题（资源的名字）以及一系列属性（用来说明资源状态的值--比如服务是被启动还是被停止）组成。
代码清单1-1是一个资源的例子,如下所示:
package { "vim":
ensure => present,
}
代码清单1-1中的资源表明了vim包应该被安装。它的结构是这样的：
类型 { "标题"：
属性 => 值,
}
在代码清单1-1中，资源的类型是package。Puppet默认提供许多资源类型，可以用来管理文件、服务、软件包以及定时任务等。注意 可以在http://docs.puppetlabs.com/references/stable/type.html找到Puppet目前能管理的全部资源类型及其属性。
接下来是资源的标题，在这里就是我们要安装的软件包的名字：vim。资源的类型和标题组合在一起构成一个针对这个资源的引用。例如，刚刚的资源可以被称为Package["vim"]。
最后，我们指定了一个单独的属性，ensure，它的值是present。Puppet通过属性得知我们对配置资源所要求的状态。每一个资源类型都有一系列可配置的属性。这里ensure属性用来指明软件包的状态：已安装、已卸载等。而它的值是present则告诉Puppet我们希望安装这个软件包。如果要卸载这个软件包,我们只需把它的值变为absent。
(2) 资源抽象层
资源被创建后，当agent连接到master时，Puppet将负责在管理这些资源时产生的一些细节问题。Puppet知道不同平台和操作系统在管理特定资源类型时的差异，并据此来处理这些细节问题。每一种资源类型都有许多"提供者"。一个软件包资源的提供者包含了"如何"使用特定的软件包管理工具来管理软件包。比如，对于软件包这一资源类型来说，有超过20个的提供者，覆盖了包括yum、aptitude、pkgadd、ports和emerge在内的多种包管理工具。
当一个agent连接到master时，Puppet使用一个叫做"Facter"的工具来返回agent的相关信息，其中就包括了主机运行的操作系统。然后Puppet会根据这一点为这个操作系统选择合适的软件包提供者，并使用这个提供者来检查vim包是否已经安装。例如，在Red Hat上它会执行yum命令，在Ubuntu上会执行aptitude命令，而在Solaris上会使用pkg命令。如果没有安装这个软件包，Puppet就会安装它。反之，则什么都不做。最后Puppet会向Puppet master报告应用这些资源配置是否成功。
2.1. FACTER和FACTS
Facter是一个系统盘点工具，它返回每个agent的"fact"，比如agent的主机名、IP地址、操作系统和版本以及其他配置项。这些fact由agent在运行的时候进行收集, 然后发送给Puppet master，并自动被创建为可以被Puppet使用的量。
可以通过在命令行下运行facter程序来查看客户端上所有可用的fact。每一个fact都返回一个键值对。例如：
operatingsystem => Ubuntu
ipaddress => 10.0.0.10
这样我们就能使用这些值来单独配置每一台主机。比如，在获得一台主机的IP地址后，就能据此配置这台主机的网络设置。
这些fact可以通过变量的形式在Puppet的配置中使用。结合预先定义好的Puppet配置和这些变量，就可以为每一台主机定制配置。例如，你可以编写一些通用资源，比如网络设置，然后使用客户端返回的数据来定制它们。
Facter还能帮助Puppet理解如何在一个agent上管理特定的资源类型。比如，如果Facter告诉Puppet一台主机正在运行Ubuntu，Puppet就知道在这个agent上要使用aptitude命令来安装软件包。Facter同样能进行扩展，可以通过添加自定义的fact来返回一些关于主机的指定信息。
1.1.3 事务层
Puppet的事务层就是它的引擎。Puppet事务涉及配置每一台主机的过程，包括：1.解释和编译配置；2.将编译好的配置同步到agent；3.在agent上应用配置；4.向master报告程序运行的结果。
Puppet运行的第一步是分析你的配置并且计算如何在agent上应用它们。为此目的，Puppet会创建一张图来表示所有的资源以及它们之间的关系，还有它们和agent之间的关系。Puppet将按照这些关系来决定每一台主机应用资源的顺序。这个模型是Puppet的强大特性之一。
接着Puppet为每一个agent取得相应的资源并将它们编译成为"目录"。然后将目录发送到各个主机并通过Puppet agent来应用它们。最后程序运行的结果以报告的形式发回给master。
事务层允许配置在主机上被重复创建和应用。这称为幂等，意思是多个程序的相同操作会导致同样的结果。Puppet配置可以在主机上安全地运行多次，并且每次运行都能得到同样的结果，Puppet使用这一点来保证配置的一致性。
不过Puppet并不具有完全的事务性。因为事物并没有被记录（除了日志），所以无法像一些数据库那样对事务进行回滚。不过可以使用无操作模式（noop）的事务模型来测试配置的执行，这不会导致实际上的改变。
总结:关于puppet得理解有很多概览的的知识。使用puppet不需要掌握ruby语言，但更多的是对puppet的语法的理解以及工作原理的理解！
本文出自 “菜鸟的成长记” 博客，请务必保留此出处http://blief.blog.51cto.com/6170059/1757939