本文转载自朱双印个人日志：https://www.zsythink.net/archives/306
这篇文章将会解释puppet在独立模式下的工作流程，并且初步的介绍”提供者”的概念。
我们回顾一下puppet在master/agent模式下的简化过的工作流程，如下图：
上图中的工作流程为puppet在master/agent模型下的工作流程。我们说过，puppet也可以工作在单机模式下，也就是说，只需要agent端即可完成工作，不需要puppet master，这种情况下，agent就无法从master端获取catalog了，那么agent所在的服务器上必须存在对应的”清单”，以便能过通过清单获取配置信息，所以，单机模式下，puppet的工作流程如下图所示。
从上图可以看出，单机模式下，puppet客户端的工作流程并没有发生多大改变，唯一不同的就是puppet agent从本机获取了manifest而已，所以，如果我们没有接触过puppet，完全可以使用单机模式学习puppet，这样会让我们的学习曲线不是那么陡峭。
我们需要考虑一个问题，当puppet工作在master/agent模型下的时候，如果我们使用明文传输协议，那么被管理主机的配置信息有可能会被”不怀好意”的人获取到，所以，我们不应该使用明文传输，而puppet为了确保传输的安全性，使用的https协议进行传输的，所以，puppet中会有自建的CA存在，以保证数据加密传输，而当我们在单机模式中使用puppet时，却不存在这些问题，这样会方便我们学习puppet，所以，当我们开始动手实际操作puppet时，就从单机模式开始。
我们再来思考一个问题，作为运维工程师，我们管理的服务器上可能安装了各种各样的操作系统，他们有可能是redhat/centos，可能是windows server，也可能是unix，当我们想要使用puppet在这些服务器上批量安装同一个应用时，我们应该怎样怎样做呢，我们知道，在linux中，我们可以使用rpm包直接安装，也可以通过yum源安装应用，虽然本质上yum源也是使用rpm包进行安装，但是yum源会自动解决依赖关系并且下载对应的安装包， 而在windows中，我们可能会手动的点击一个后缀名为exe或者msi的文件进行安装，那么puppet能知道被管理服务器是windows还是linux吗，答案是肯定的。
当我们使用puppet安装某个应用时，puppet会自动判断被管理服务器的系统平台，并且会选择对应的默认方法安装对应的文件，puppet针对不同的操作系统以及发行版，准备了对应的默认的安装方案，我们只要告诉puppet，安装哪个文件，文件在哪里即可，因为puppet把这些问题通过”中间层”的概念解决了，这个”中间层”负责判断服务器上具体的操作系统是什么，这个中间层在puppet中被称为”资源抽象层”，资源抽象层会自动匹配操作系统的种类与发行版，然后选择对应的默认的provider对操作系统进行操作（provider又称提供者），rpm、yum、apt、msi这些”东西”在puppet中都被称为provider(提供者)，而管理员只要工作在”配置语言层”即可，我们只要按照配置语言的语法，将配置写入配置文件（清单）中，而资源抽象层根据我们的配置，选择对应操作系统的默认的provider，并且通过provider执行对应的安装操作，但是某些情况下我们需要指定”提供者”，就拿centos为例，我们在centos中，既能使用rpm包安装，也能通过yum源安装，它们都属于centos系统的提供者，但是puppet默认情况下使用yum作为redhat/centos系统的提供者，如果在没有yum源的情况下，我们可以通过清单，指定使用rpm作为提供者，当然，如果默认的提供者能够满足我们的需求，我们就更加方便了，只是通过上面的文字描述，可能不太容易理解，不过没有关系，这些只是纯粹的概念，我们在后面的使用中，会更加清晰的理解它们，此处我们不用细究，这并不影响我们继续学习puppet。
好了，说了这么多理论，我们该动动手了，剩下的没有涉及到的理论等到用到的时候，我们再根据实际情况进行总结。