puppet入门:puppet基本概念 (puppet 2)

  • A+
所属分类:puppet  运维技术

puppet入门:puppet基本概念 (puppet 2)

我们继续介绍puppet的基本概念,如果你完全没有了解过puppet,请查看上一篇文章,直达链接:puppet入门 (1):puppet是什么 

前文已经说过,puppet是C/S架构的,有服务端,也有客户端,管理员可以通过puppet服务端(master),管理每一台被管理的服务器,但是需要puppet客户端作为中介,也就是说,puppet客户端作为代理(agent),接收来自puppet服务端的配置信息,按照服务端(master)发送过来的配置信息,对被管理服务器进行配置,真正执行配置操作的是puppet客户端,puppet服务端只负责将配置信息准备好,发送给puppet客户端,以便客户端执行具体操作,puppet客户端还有另一个作用,就是向puppet服务端发送报告,当客户端按照配置信息执行完成相关配置以后,会将执行信息发送到服务端,比如执行成功与否,执行结果等,默认情况下,每30分钟,puppet客户端会向puppet服务端发起一次请求,请求受管理服务器的配置信息, puppet服务端将配置信息发送给客户端,客户端根据反回的信息进行判断,判断被管理服务器是否符合管理员定义的配置,puppet的这种工作模式就是C/S架构的,也可以理解为master/agent的工作模式,如下图。

puppet入门:puppet基本概念 (puppet 2) 

当然,puppet也可以不在master/agent模式下工作,我们可以在受管理服务器上只安装puppet客户端,使用客户端手动执行对应配置文件,相当于配置文件中的信息并不是通过puppet服务端发送过来,而是通过本地的配置文件获取,也是可以的,我们暂且称这种不需要puppet服务端的工作模式为单机模式,我们在学习puppet时,可以使用单机的模式进行练习,但是在生产环境中,一般都使用master/agent的方式使用puppet。

还记得我们在文章的开头提到的场景一吗,我们就拿场景一做例子,比如,管理员想要在100台服务器上同时创建一个名叫"zsythink"的用户,我们该怎样使用puppet解决这个问题呢,我们来描述一下,首先,管理员需要在puppet服务端创建了一个配置文件,这个配置文件的作用就是在被管理主机上创建一个"zsythink"用户,当管理员写好配置文件以后,通过puppet服务端,将准备好的配置文件发送到puppet客户端,puppet客户端会解析这些配置,然后判断,被管理服务器上是否存在"zsythink"用户,如果"zsythink"用户不存在,则创建zsythink用户,如果"zsythink"用户已经存在,puppet则不会创建这个用户。 

上面这段话会引出两个概念,"资源"与"目标状态"。

我们先说 "资源"的概念,在上述描述中,我们所要创建的用户"zsythink"就算是一种资源,可以理解为"用户资源",如果我们把上述场景稍微改动一下,变成 "管理员想要在100台服务器上同时创建一个名叫think的组",那么,"think组"在puppet中也被称之为"资源" ,我们可以这样理解,  puppet中把要操作的对象称之为资源,说的通俗一点,就是如果我们要创建用户,用户就是资源,如果我们要删除组,组就是资源,如果我们要使用puppet在多台机器上安装应用,应用就是资源,如果我们想要通过puppet启动服务,那么服务就是资源,如果我们想要使用puppet批量上传某个文件,文件就是资源,"资源"在puppet中是一个抽象的概念,所以,我们可以把puppet将要操作的对象理解为资源。那么我们经常使用puppet操作哪些资源呢,换句话说,常用的资源如下(并非全部): 

file 代表文件或者目录
package 代表程序包
service 代表服务
user 代表用户
group 代表组
cron 代表定时任务
exec 代表命令
yumrepo 代表yum仓库

通过查看上述列表中的常用资源,你可能已经推测出了某个结论,我们平常使用puppet,就是围绕着文件、软件包,服务,命令等工作展开的,我们会通过puppet批量的操作这些资源,以免重复的工作。

我们再来聊聊"目标状态"的概念,我们在上述创建zsythink用户的例子中提到,puppet客户端会判断被管理服务器上是否存在"zsythink"用户,如果"zsythink"用户不存在,则创建zsythink用户,如果"zsythink"用户已经存在,puppet则不会创建"zsythink"用户, 这就是"目标状态"的概念,我们在配置文件中定义的最终目标是创建"zsythink"用户,如果在被管理服务器上已经存在zsythink用户,那么被管理服务器的当前状态与我们预期的"目标"相同,所以puppet不会再次执行创建用户的操作,如果被管理服务器上当前并没有zsythink用户,那么puppet则认为被管理服务器的当前状态并不符合我们预期的"目标状态",这个时候,puppet则会执行创建用户的操作,从而让被管理服务器达到我们指定的"目标状态",puppet通过"目标状态"的概念,体现了puppet执行操作时的幂等性。 

好了,聊完了场景一,我们来聊聊场景二,还记得场景二吗,我们重复一遍场景二,以便大家能够回忆起来。

场景二:公司新买了一堆云服务器,这些服务器最终可能要提供相同的服务,现在需要管理员在这一堆服务器上安装一些相同的应用,而且安装完成后,还需要这些服务器上的应用自动启动,怎么办,我们会推荐你使用puppet解决这个问题。

根据我们之前提到的概念,场景二中最起码会使用到两个资源,一个是package资源,一个是service资源,因为我们最起码要将应用程序包安装上,才能启动对应的服务,于是,管理员开始定义配置文件,配置文件的最终目的就是安装上对应的package,启动对应的服务,那么应该怎样写配置文件呢,管理员只需要按照固定的语法,将资源按照一定的格式和顺序写在配置文件中即可,我们会在后面的实际应用示例中,为大家展示怎样写配置文件,配置文件中可能包含了一个或多个资源,具体有哪些资源,会根据你的应用场景发生变化,就像场景二中,我们需要安装应用,启动服务,所以在配置文件中最起码有两个资源,"配置文件"在puppet中有一个专业术语,它被称为"manifest",翻译过来就是"货单"、"清单"的意思,其实想想,也很形象,可以这样想象,我们把要操作的资源列在一个单子上,puppet根据这个单子执行对应的操作,最终实现我们的目标,这个被称为"资源清单"或者"清单"的东西,其实就是我们的配置文件。

但是,需要注意的是"清单"并不会被puppet直接执行,因为清单从本质上来说,是一个人类易读的文本文件,puppet会将清单进行进一步的处理,把它变成puppet可以理解的"机器语言",而被处理过的清单被称为"catalog",也就是说,puppet会将清单先编译成catalog,最终执行catalog。 

我们说过,生产环境中,puppet往往是以master/agent的方式执行的,那么,puppet服务端(以后简称master)与puppet客户端(以后简称agent)到底是怎样协作的呢,或者说,它们之间的内部工作流程是什么样子的呢,我们还是看图说话,方便理解,为了更简明的描述master与agent之间的工作流程,我们假设目前只有一台master,并且只有一台被管理服务器,如下图红线标注的场景:

puppet入门:puppet基本概念 (puppet 2)

那么,我们把上图中的两台服务器拿出来,详细说说它们之间的具体工作流程,但是此处我们需要说明,在master/agent模型下工作的puppet的工作流程比我们总结的要复杂一点,但是为了入门方便,我们只取出其中的一部分核心的流程进行总结,在后面的实际应用中,我们会不断的丰富这些流程,此处先给出一个简化过的流程图,如下图所示。

puppet入门:puppet基本概念 (puppet 2) 

1、客户端puppet agent请求catalog,我们已经说过,catalog其实就是被管理服务器对应的配置文件(经过处理过的配置文件),服务端master收到agent的请求,然后找到对应被管理服务器的"站点清单",或者被称为"主机清单",因为一台"被管理服务器"可能同时担任多个"角色",每个角色可能都会对应一个"manifest"(也就是清单),所以,我们可以为每一台被管理服务器配置一个"站点清单",站点清单也可以理解成为一种"清单",只是它是针对一台服务器而存在的一种清单。

2、服务端master找到被管理服务器的站点清单后,根据站点清单,找到对应服务器需要哪些"清单",因为一台服务器可能会需要多张"清单",上图中为了示例,只画出了一个清单,但是这不代表必定只有一个。

3、master将找到的所有"清单"进行处理,处理为catalog。

4、master将处理过的catalog发送到agent端。

5、agent收到master发送过来的catalog,然后,agent会查询"被管理服务器的当前状态",看看服务器的当前状态是否符合catalog中定义的目标状态。

6、如果"被管理服务器的当前状态"与"catalog中定义的目标状态"一致,那么资源对应的操作将不会执行,如果"被管理服务器的当前状态"与"catalog中定义的目标状态"不一致,那么资源对应的操作将会执行,以便让"被管理服务器"达到管理员指定的"目标状态"。

7、经过上一步的"状态判断",执行对应操作,不管执行是否成功,都会生成对应的报告信息。

8、agent将生成的报告信息发送给master端。 

上述过程,就是puppet在master/agent模式下的工作流程,我们说过,默认情况下,客户端每隔30分钟向服务端请求一次配置信息,然后根据服务端返回的配置信息,判断当前服务器是否处于管理员定义的目标状态,如果被管理的服务器不处于管理员定义的目标状态,则需要执行对应的操作,使得被管理主机最终处于管理员定义的目标状态,我们也可以不必每次都等待30分钟,我们可以从master端推送catalog到agent端,主动告诉agent端,配置已经发生了改变,请执行对应的操作。这是后话,我们以后再聊。

weinxin
我的微信公众号
关注"实用运维笔记"微信公众号,当博客中有新文章时,可第一时间得知哦~
朱双印

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:2   其中:访客  1   博主  1

    • avatar Peterer~ 0

      纠个错:“配置文件”在puppet中有个专业术语,他被称为“manigest”,是manifest

        • avatar 朱双印 Admin

          @Peterer~ 感谢客官指正,已经修改,如果博客中有一些错误,希望大家能够帮忙及时指正,常来呦,亲~~~~