标签:
我通过伯乐在线翻译了一个Puppet简明教程,一共分为四部分,这是第二部分。
原文地址:http://blog.jobbole.com/87680/
本文由 伯乐在线 - Wing 翻译,黄利民 校稿。未经许可,禁止转载!
英文出处:Manue Kiessling。欢迎加入翻译组。
在第一部分中,我们已经建立了两个Linux系统虚拟机:puppetserver 和 puppetclient。我们已经实现了一个重要的里程碑:在虚拟机上分别安装了Puppet服务器和Puppet客户端软件,并且在Puppet服务器端对Puppet客户端进行了认证。接下来我们要在此基础上,开始通过在puppetserver虚拟机上的Puppet服务器,来配置puppetclient虚拟机系统。
我们以一个非常基本的示例开始。在这个示例中,我们为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虚拟机上得到的文件,来覆盖现有文件。
在第三部分中,我们会看一个更复杂的清单,以及如何将清单组织成不同的模块。
标签:
原文地址:http://www.cnblogs.com/wing011203/p/4621043.html