用 Puppet 搭建易管理的服务器基础架构(2)

关于

第一部分,我们已经建立了两个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

我们稍后会看到,清单可以通过模块化的方式放到任意数目的不同文件中(这样可以帮助我们针对大型复杂的站点建立清单结构)。但是一切都还是从site.pp开始。

我们来仔细分析一下这个最简化的清单,它包含两部分:一个包含file定义的node,因为file部分包含在node部分中,这样file部分的定义产生的结果会应用到名为puppetclient的节点上。

通过在puppetclient虚拟机系统上运行Puppet代理,我们可以很容易理解上面描述的内容。

On the puppetclient VM

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

如我们所见,这次代理并没有做任何事情,这是因为目标节点的状况已经满足了。那如果我们修改目标节点上的状况会怎么样呢?让我们来修改这个文件的访问模式:

在 puppetclient VM 上

~# chmod 0640 /home/ubuntu/helloworld.txt

然后再次运行代理:

在 puppetclient VM 上

代理注意到了区别,然后通过修改文件访问模式来移除了这个区别。

如果我们修改了文件的内容,会发生什么呢?

在 puppetclient VM 上

~# echo "This is a test" > /home/ubuntu/helloworld.txt

…这时运行代理?

在 puppetclient VM 上

没有发生任何事情。为什么?因为在清单中,我们没有对文件内容进行任何描述。我们所做的是让Puppet来保证这个指定名字的文件是存在的,并且这个文件的一些元数据(拥有者、用户组、访问模式)应该有指定设置。Puppet只会关心那些我们让它去关心的事情。

我们在之前示例中看到的行为,正好表明了Puppet哲学的核心。在我们的清单中,我们不告诉Puppet做什么,我们也不告诉它怎么去做,我们只告诉Puppet最终的结果应该是什么样子

这种哲学带来了巨大的能量,因为它对配置系统所需要的繁重的工作进行了抽象。它抚平了不同的操作系统带来的差别。考虑下面一个场景,你有一个由不同的Linux系统构成的网络:有些运行Red Hat Linux,有些在运行Ubuntu Linux。我们进一步假设你希望在所有的系统上安装htop包。如果我们需要告诉Puppet做什么和怎么做,那么我们不得不编写一个清单,它在Ubuntu上使用apt-get,在Red Hat上使用yum。相反,我们所需要放到清单中的内容如下所示:

目标节点中的puppet代理会去搞清楚如何做,才能实现清单中描述的目标场景。Red Hat系统中的代理会使用yum来安装包,而Ubuntu系统中的代理则会使用apt-get

我们在稍后会回来讨论包安装,让我们继续之前的文件示例。通过Puppet来创建一个空文件,通常都不是特别有用——当然我们更喜欢部署一些带内容的文件。Puppet可以很容易做到:我们可以将文件放在puppetserver虚拟机上,然后通过Puppet将其传输到puppetclient虚拟机上。

首先,我们在puppetserver虚拟机上创建源文件:

在 puppetserver VM 上

然后,我们需要允许Puppet客户端来访问这个文件,为此,我们需要修改puppetserver虚拟机上的/etc/puppet/fileserver.conf文件,添加一个allow *语句:

/etc/puppet/fileserver.conf on puppetserver

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

/etc/puppet/manifests/site.pp on puppetserver

让我们再次运行客户端系统上的代理:

在 puppetclient VM 上

现在Puppet代理的确会关心文件的内容,它会使用从puppetserver虚拟机上得到的文件,来覆盖现有文件。

第三部分中,我们会看一个更复杂的清单,以及如何将清单组织成不同的模块。

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

1 2 收藏 评论

关于作者:Wing

简介还没来得及写 :) 个人主页 · 我的文章 · 21 ·    

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部