[翻译]用 Puppet 搭建易管理的服务器基础架构（2）

koflover

　　我通过伯乐在线翻译了一个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

node "puppetclient" {   file { "/root/helloworld.txt":     ensure => file,     owner  => "root",     group  => "root",     mode   => 0644   } }

　　我们稍后会看到，清单可以通过模块化的方式放到任意数目的不同文件中（这样可以帮助我们针对大型复杂的站点建立清单结构）。但是一切都还是从site.pp开始。
　　我们来仔细分析一下这个最简化的清单，它包含两部分：一个包含file定义的node，因为file部分包含在node部分中，这样file部分的定义产生的结果会应用到名为puppetclient的节点上。
　　通过在puppetclient虚拟机系统上运行Puppet代理，我们可以很容易理解上面描述的内容。
　　On the puppetclient VM

1 2 3 4

~# sudo puppet agent --verbose --no-daemonize --onetime info: Caching catalog for puppetclientinfo: Applying configuration version '1395862307' notice: /Stage[main]//Node[puppetclient]/File[/home/ubuntu/helloworld.txt]/ensure: created notice: Finished catalog run in 0.03 seconds

　　或许这看上去没有什么大惊小怪：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

~# sudo puppet agent --verbose --no-daemonize --onetime info: Caching catalog for puppetclient info: Applying configuration version '1395862542' notice: Finished catalog run in 0.03 seconds

　　如我们所见，这次代理并没有做任何事情，这是因为目标节点的状况已经满足了。那如果我们修改目标节点上的状况会怎么样呢？让我们来修改这个文件的访问模式：
　　在 puppetclient VM 上
　　~# chmod 0640 /home/ubuntu/helloworld.txt
　　然后再次运行代理：
　　在 puppetclient VM 上

1 2 3 4 5 6

~# sudo puppet agent --verbose --no-daemonize --onetime info: Caching catalog for puppetclient info: Applying configuration version '1395862307' notice: /Stage[main]//Node[puppetclient]/File[/home/ubuntu/helloworld.txt]/ensure: created notice: Finished catalog run in 0.03 seconds

　　代理注意到了区别，然后通过修改文件访问模式来移除了这个区别。
　　如果我们修改了文件的内容，会发生什么呢？
　　在 puppetclient VM 上
　　~# echo "This is a test" > /home/ubuntu/helloworld.txt
　　…这时运行代理？
　　在 puppetclient VM 上

1 2 3 4 5

~# sudo puppet agent --verbose --no-daemonize --onetime info: Caching catalog for puppetclient info: Applying configuration version '1395862542' notice: Finished catalog run in 0.03 seconds

　　没有发生任何事情。为什么？因为在清单中，我们没有对文件内容进行任何描述。我们所做的是让Puppet来保证这个指定名字的文件是存在的，并且这个文件的一些元数据（拥有者、用户组、访问模式）应该有指定设置。Puppet只会关心那些我们让它去关心的事情。
　　我们在之前示例中看到的行为，正好表明了Puppet哲学的核心。在我们的清单中，我们不告诉Puppet做什么，我们也不告诉它怎么去做，我们只告诉Puppet最终的结果应该是什么样子。
　　这种哲学带来了巨大的能量，因为它对配置系统所需要的繁重的工作进行了抽象。它抚平了不同的操作系统带来的差别。考虑下面一个场景，你有一个由不同的Linux系统构成的网络：有些运行Red Hat Linux，有些在运行Ubuntu Linux。我们进一步假设你希望在所有的系统上安装htop包。如果我们需要告诉Puppet做什么和怎么做，那么我们不得不编写一个清单，它在Ubuntu上使用apt-get，在Red Hat上使用yum。相反，我们所需要放到清单中的内容如下所示：

1 2 3

package { "htop":   ensure => installed }

　　目标节点中的puppet代理会去搞清楚如何做，才能实现清单中描述的目标场景。Red Hat系统中的代理会使用yum来安装包，而Ubuntu系统中的代理则会使用apt-get。
　　我们在稍后会回来讨论包安装，让我们继续之前的文件示例。通过Puppet来创建一个空文件，通常都不是特别有用——当然我们更喜欢部署一些带内容的文件。Puppet可以很容易做到：我们可以将文件放在puppetserver虚拟机上，然后通过Puppet将其传输到puppetclient虚拟机上。
　　首先，我们在puppetserver虚拟机上创建源文件：
　　在 puppetserver VM 上

1 2 3

~# sudo -s ~# mkdir /etc/puppet/files ~# echo "Hello World." > /etc/puppet/files/helloworld.txt

　　然后，我们需要允许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

# This file consists of arbitrarily named sections/modules # defining where files are served from and to whom # Define a section 'files' # Adapt the allow/deny settings to your needs. Order # for allow/deny does not matter, allow always takes precedence # over deny [files]   path /etc/puppet/files   allow * #  allow *.example.com #  deny *.evil.example.com #  allow 192.168.0.0/24 [plugins] #  allow *.example.com #  deny *.evil.example.com #  allow 192.168.0.0/24

　　现在我们可以修改/etc/puppet/manifest/site.pp清单文件，扩展其中已有的file块：
　　/etc/puppet/manifests/site.pp on puppetserver

1 2 3 4 5 6 7 8 9 10 11

node "puppetclient" {   file { "/root/helloworld.txt":     ensure => file,     owner  => "root",     group  => "root",     mode   => 0644,     source => "puppet://puppetserver/files/helloworld.txt"   } }

　　让我们再次运行客户端系统上的代理：
　　在 puppetclient VM 上

1 2 3 4 5 6 7 8

~# sudo puppet agent --verbose --no-daemonize --onetime info: Caching catalog for puppetclient info: Applying configuration version '1395878127' info: FileBucket adding {md5}ff22941336956098ae9a564289d1bf1b info: /Stage[main]//Node[puppetclient]/File[/home/ubuntu/helloworld.txt]: Filebucketed /home/ubuntu/helloworld.txt to puppet with sum ff22941336956098ae9a564289d1bf1b notice: /Stage[main]//Node[puppetclient]/File[/home/ubuntu/helloworld.txt]/content: content changed '{md5}ff22941336956098ae9a564289d1bf1b' to '{md5}770b95bb61d5b0406c135b6e42260580' notice: Finished catalog run in 0.09 seconds

　　现在Puppet代理的确会关心文件的内容，它会使用从puppetserver虚拟机上得到的文件，来覆盖现有文件。
　　在第三部分中，我们会看一个更复杂的清单，以及如何将清单组织成不同的模块。