Question

Standalone(单机模式)

Puppet 可以很容易地以单机模式下执行配置管理的工作。在这种模式下 Puppet 将会在本地 编译并且执行 catalog，无需和 Puppet Server 通讯，适合一些简单的配置管理任务或者 Puppetserver 节点的自部署工作。

puppet 命令支持多种使用方式，可以在终端下输入:

   puppet -v apply test.pp  # 最常用的使用方式
   puppet apply -e 'include ::ntp::server'  #执行一段 puppet 代码
   puppet apply --catalog catalog.json #指定执行一个 catalog 文件

Client/Server(客户端/服务器端模式)

C/S 模式是大家都熟悉的运行模式。在这种模式下，Puppet agent 端被部署在了被管理的服务器上，Puppet master(server) 端部署在管理服务器上。

TODO：C/S 流程图

如何选择？

脱离业务场景去谈孰优孰劣都是不合时宜的。

适合单机模式的场景

如果是个人开发环境的配置管理，少数服务器的配置管理，以及业务逻辑比较简单的情况下，推荐使用单机模式，简单方便。

适合 C/S 模式的场景

在涉及正式线上环境的情况下，我们推荐是 C/S 模式。优势非常明显：

1. 安全管理和权限控制

配置管理代码中其实包含了大量的敏感信息，其一旦发生泄漏或者权限被越界，就发导致严重的安全问题。

在单机模式下，每台服务器都会拿到完整的 puppet 代码和 hiera 数据，试想一台 Apache 服务器上放着 MySQL 服务器的配置管理代码和管理员用户名密码是何其危险的事情！

另外，在 CS 模式下，agent 端和 server 端通过 SSL 进行通信，并且可以根据节点的 FQDN 做细粒度的控制，试想一台伪造自己是数据库服务器的节点，在向服务器端请求就轻而易举地拿到了数据库节点的 catalog 也是非常危险的事情。

2.支持高级特性

在 C/S 模式下，通过开启 storeconfigs 参数，配合 PuppetDB，可以使用 Puppet 中诸如 exported_resources 等高级特性。

3.集中式管理

在单机模式下，若要批量执行 puppet 配置管理任务，一般选择使用集群管理工具例如 clustershell 等做批量的变更操作。 在 C/S 模式下，agent 既可以定期地从 server 端获取最新的 catalog，也可以由 Server 端主动地发送更新指令。 此外，在 C/S 模式下，agent 端在完成配置应用的任务后，可以发送 report 给 Server 端或者其他服务器。