我通过伯乐在线翻译了一个Puppet简明教程，一共分为四部分，这是第二部分。
原文地址：http://blog.jobbole.com/87680/
本文由 伯乐在线 - Wing 翻译，黄利民 校稿。未经许可，禁止转载！
英文出处：Manue Kiessling。欢迎加入翻译组。
关于
在第一部分中，我们已经建立了两个Linux系统虚拟机：puppetserver 和 puppetclient。我们已经实现了一个重要的里程碑：在虚拟机上分别安装了Puppet服务器和Puppet客户端软件，并且在Puppet服务器端对Puppet客户端进行了认证。接下来我们要在此基础上，开始通过在puppetserver虚拟机上的Puppet服务器，来配置puppetclient虚拟机系统。
你好，Puppet
我们以一个非常基本的示例开始。在这个示例中，我们为puppetclient虚拟机建立一个非常简单的配置：在puppetclient虚拟机系统的/home/ubuntu目录下创建一个名为helloworld.txt文件，文件的内容是”Hello World!”。
Puppet自带一个功能强大的声明式配置语言。我们使用这种语言来编写的内容被称为清单（manifest）。Puppet清单是一个文件，它描述了目标系统中的某些方面应该是什么样的。在这个系列教程中，我们会编写很多不同的清单：其中一些会在目标系统上创建一些文件；一些会创建用户账户；一些会安装软件包。
清单会被应用到目标系统上。对Puppet来说，目标系统被称为节点（node)。我们的puppetclient虚拟机系统就是这样一个节点。我们已经为它做了Puppet服务器认证，这样可以保证Puppet服务器来管理这个节点。但我们的服务器还没有任何信息，可以用来管理这个节点。我们可以通过编写一个清单并将其放在节点上来改变它。
为此，我们会创建一个非常简单的清单定义，这个定义会被放在puppetserver虚拟机系统的主清单文件中，文件的路径是/etc/puppet/manifests/site.pp：
/etc/puppet/manifests/site.pp on puppetserver
|
1 2 3 4 5 6 7 8 9 10 |
|
我们稍后会看到，清单可以通过模块化的方式放到任意数目的不同文件中（这样可以帮助我们针对大型复杂的站点建立清单结构）。但是一切都还是从site.pp开始。
我们来仔细分析一下这个最简化的清单，它包含两部分：一个包含file定义的node，因为file部分包含在node部分中，这样file部分的定义产生的结果会应用到名为puppetclient的节点上。
通过在puppetclient虚拟机系统上运行Puppet代理，我们可以很容易理解上面描述的内容。
On the puppetclient VM
|
1 2 3 4 |
|
或许这看上去没有什么大惊小怪：puppetclient虚拟机上的Puppet代理联系到puppetserver虚拟机上的Puppet master。然后它接收目录，这个目标就是在master上定义的所有和这个指定客户端有关的清单。如果你感兴趣的话，这个目录被存在一个yaml结构中，它存储在 /var/lib/puppet/client_yaml/catalog/puppetclient.yaml 中，这不仅仅是复制了我们的.pp清单，而是通过对清单进行解析，生成的一个关于目标配置信息的编译版本。
接下来，Puppet代理开始采取行动——当且仅当满足以下条件才会采取行动：Puppet代理会比较清单中期望的状况和目标节点上清单的状况，如果其中有一些不同（如果目标节点上找到的状况并没有同步到期望达到的状况）——那么代理就会做任何必需的操作来移除这些区别，来实现目标状况。
在我们这个特定的示例中，代理知道在目标节点的/home/ubuntu目录下，应该有一个名为helloworld.txt的文件，这个文件的所有者和所在组是ubuntu，用户对该文件的访问权限是0644。然而，当检查本地系统时，发现并没有发现这个文件。代理会采取行动，来创建这个期待中的文件。
我们可以通过再次运行代理来验证这个行为：
On the puppetclient VM
|
1 2 3 4 |
|
如我们所见，这次代理并没有做任何事情，这是因为目标节点的状况已经满足了。那如果我们修改目标节点上的状况会怎么样呢？让我们来修改这个文件的访问模式：
在 puppetclient VM 上
~# chmod 0640 /home/ubuntu/helloworld.txt
然后再次运行代理：
在 puppetclient VM 上
|
1 2 3 4 5 6 |
|
代理注意到了区别，然后通过修改文件访问模式来移除了这个区别。
如果我们修改了文件的内容，会发生什么呢？
在 puppetclient VM 上
~# echo "This is a test" > /home/ubuntu/helloworld.txt
…这时运行代理？
在 puppetclient VM 上
|
1 2 3 4 5 |
|
没有发生任何事情。为什么？因为在清单中，我们没有对文件内容进行任何描述。我们所做的是让Puppet来保证这个指定名字的文件是存在的，并且这个文件的一些元数据（拥有者、用户组、访问模式）应该有指定设置。Puppet只会关心那些我们让它去关心的事情。
我们在之前示例中看到的行为，正好表明了Puppet哲学的核心。在我们的清单中，我们不告诉Puppet做什么，我们也不告诉它怎么去做，我们只告诉Puppet最终的结果应该是什么样子。
这种哲学带来了巨大的能量，因为它对配置系统所需要的繁重的工作进行了抽象。它抚平了不同的操作系统带来的差别。考虑下面一个场景，你有一个由不同的Linux系统构成的网络：有些运行Red Hat Linux，有些在运行Ubuntu Linux。我们进一步假设你希望在所有的系统上安装htop包。如果我们需要告诉Puppet做什么和怎么做，那么我们不得不编写一个清单，它在Ubuntu上使用apt-get，在Red Hat上使用yum。相反，我们所需要放到清单中的内容如下所示：
|
1 2 3 |
|
目标节点中的puppet代理会去搞清楚如何做，才能实现清单中描述的目标场景。Red Hat系统中的代理会使用yum来安装包，而Ubuntu系统中的代理则会使用apt-get。
我们在稍后会回来讨论包安装，让我们继续之前的文件示例。通过Puppet来创建一个空文件，通常都不是特别有用——当然我们更喜欢部署一些带内容的文件。Puppet可以很容易做到：我们可以将文件放在puppetserver虚拟机上，然后通过Puppet将其传输到puppetclient虚拟机上。
首先，我们在puppetserver虚拟机上创建源文件：
在 puppetserver VM 上
|
1 2 3 |
|
然后，我们需要允许Puppet客户端来访问这个文件，为此，我们需要修改puppetserver虚拟机上的/etc/puppet/fileserver.conf文件，添加一个allow *语句：
/etc/puppet/fileserver.conf on puppetserver
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
现在我们可以修改/etc/puppet/manifest/site.pp清单文件，扩展其中已有的file块：
/etc/puppet/manifests/site.pp on puppetserver
|
1 2 3 4 5 6 7 8 9 10 11 |
|
让我们再次运行客户端系统上的代理：
在 puppetclient VM 上
|
1 2 3 4 5 6 7 8 |
|
现在Puppet代理的确会关心文件的内容，它会使用从puppetserver虚拟机上得到的文件，来覆盖现有文件。
在第三部分中，我们会看一个更复杂的清单，以及如何将清单组织成不同的模块。