puppet（二）——puppet基本概念

本文转载自朱双印个人日志，链接为：https://www.zsythink.net/archives/201

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

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

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

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

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

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

我们再来聊聊”目标状态”的概念，我们在上述创建liuhaoran用户的例子中提到，puppet客户端会判断被管理服务器上是否存在”liuhaoran”用户，如果”liuhaoran”用户不存在，则创建liuhaoran用户，如果”liuhaoran”用户已经存在，puppet则不会创建”liuhaoran”用户, 这就是”目标状态”的概念，我们在配置文件中定义的最终目标是创建”liuhaoran”用户，如果在被管理服务器上已经存在liuhaoran用户，那么被管理服务器的当前状态与我们预期的”目标”相同，所以puppet不会再次执行创建用户的操作，如果被管理服务器上当前并没有liuhaoran用户，那么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，并且只有一台被管理服务器，如下图红线标注的场景:

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

• 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端，配置已经发生了改变，请执行对应的操作。