DebOps 工程师的 Puppet8 指南（四）

原文：annas-archive.org/md5/74e7dee08e6c205ecc2a82f2d11edba8

译者：飞龙

协议：CC BY-NC-SA 4.0

第十三章：深入探讨 Puppet 服务器

本章将介绍如何监控、调优并将 Puppet 基础设施与第三方数据源集成。你将了解如何查找我们在前几章讨论的各种服务的日志，并如何查找当前的状态 API。接着，你将学习如何将这些日志和状态集成到像logstash这样的服务中，以提供更大的可见性和告警选项。然后，我们将回顾 Puppet 提供的性能指标，以及如何将这些指标与 Splunk 和 Grafana 等仪表板工具集成，从而为 Puppet 的基础设施提供监控和可观测性。我们将为Splunk和Grafana设置实验环境，作为 Puppet 操作仪表板的一部分，展示这些仪表板。通过使用这些指标，你将学习如何调整和扩展 Puppet 基础设施的各个组件，以应对 Puppet 扩展时常见的问题和挑战。之后，你将了解外部提供者模式如何使事实、分类和 Hiera 数据能够从外部数据源传输到 Puppet，并允许 Puppet 平台团队提供自助服务，无需完全了解 Puppet 或环境发布程序。本章将展示多个第三方实现，包括ServiceNow和1Password。在本章的实验中，我们将实现Puppet 数据服务（PDS）来演示这一模式。

在本章中，我们将涵盖以下主要内容：

• 日志与状态

• 性能指标、调优与扩展

• 识别和避免常见问题

• 外部数据源

技术要求

从github.com/puppetlabs/control-repo将控制仓库克隆到你的 GitHub 账户（controlrepo-chapter13），并更新该仓库中的以下文件：

• 使用github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch13/Puppetfile的Puppetfile

• 使用github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch13/hiera.yaml的hiera.yaml

• 使用github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch13/site.pp的manifests/site.pp

通过下载github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch13/params.json中的params.json文件，构建一个包含三个编译器和三个客户端的大型集群，并更新文件以包含你的控制仓库位置和控制仓库的 SSH 密钥。然后，从你的pecdm目录运行以下命令：

bolt --verbose plan run pecdm::provision --params @params.json

首先，我们将查看在哪里可以找到日志以及 Puppet 服务和基础设施的当前状态。这对于如何调优和排除 Puppet 故障至关重要。

日志记录和状态

当我们在本书中之前讨论不同的 Puppet 组件时，我们列出了日志目录，但有一个统一的日志参考点是很有用的。

探索日志位置

本节提供了这些日志的列表，标题包括核心功能、包含目录和该目录中的日志列表：

• /var/log/puppetlabs/puppetserver/：主要服务器日志目录

• puppetserver.log：主要的服务器日志，记录其活动

• puppetserver-access.log：访问端点的请求

• puppetserver-daemon.log：崩溃报告和致命错误

• puppetserver-status.log：服务的调试状态日志

• /var/log/puppetlabs/postgresql/<version>：PostgreSQL 日志目录* pgstartup.log：启动日志* postgresql-<Mon – Sun>.log：每日调试日志* /var/log/puppetlabs/puppetdb/：PuppetDB 日志目录* puppetdb.log：PuppetDB 服务活动日志* puppetdb-access.log：访问端点的请求* puppetdb-status.log：服务的调试状态日志* /var/log/puppetlabs/puppetserver/：主要服务器日志目录* code-manager-access.log：访问代码管理器端点的请求* file-sync-access.log：访问文件同步端点的请求* pcp-broker.log：编译器上的 Puppet 通信协议代理* /var/log/puppetlabs/console-services/：Puppet Enterprise 控制台服务日志目录* console-services.log：控制台服务活动日志* console-services-api-access.log：访问控制台服务 API 端点的请求* console-services-access.log：访问控制台服务端点的请求* console-services-daemon.log：崩溃报告和致命错误日志* /var/log/puppetlabs/nginx/：nginx 日志目录* access.log：访问 nginx 端点的请求* error.log：nginx 错误和一般控制台错误* 代理日志：

当你手动运行 Puppet 时，你在屏幕上看到的代理输出会根据puppet.conf文件中的logdest和logdir设置记录到一个位置。logdest参数可以设置为syslog（发送到 POSIX syslog 服务）、eventlog（发送到 Windows 事件日志）、console（日志发送到控制台）或一个文件名，以便将其输出到logdest设置的位置下的该文件名。syslog是 Unix 系统的默认设置，而eventlog是 Windows 的默认设置。logdest的默认值为 Unix 的/var/log/puppetlabs/puppet和 Windows 的C:\ProgramData\PuppetLabs\puppet\var\log。

注意

可以开启服务器配置文件分析，它可以生成详细的目录日志信息。然后可以将其绘制为图形，展示目录编译的深入调试信息。本书不涉及此内容。更多信息请参考 Puppet 的文档：github.com/puppetlabs/puppet/blob/main/docs/profiling.md。

经过对不同日志位置的检查，我们可以清楚地看到，将这些服务器日志转发到专用工具中以便索引和处理是非常有用的。

转发服务器日志

随着 Puppet 客户端数量的增加，我们在第十章中完成的日志跟踪工作变得不切实际。在这种情况下，需要更专业的logback.xml，可以将其发送到像 Elastic 的 Logstash 或 Grafana 的 Loki 这样的日志后端。logback.xml文件包含appender定义，它是 Logback 用于写入日志的组件。

通过观察puppetserver.log的appender配置，我们可以看到当前的配置：

    <appender name="F1" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>/var/log/puppetlabs/puppetserver/puppetserver.log</file>
        <append>true</append>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>/var/log/puppetlabs/puppetserver/puppetserver-%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <!-- each file should be at most 200MB, keep 90 days worth of history, but at most 1GB total -->
            <maxFileSize>200MB</maxFileSize>
            <maxHistory>90</maxHistory>
            <totalSizeCap>1GB</totalSizeCap>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX} %-5p [%t] [%c{2}] %m%n</pattern>
        </encoder>
    </appender>

在这里，我们可以看到它是如何追加到日志中的，使用的文件名模式，以及日志轮转的日期，并且每个文件的大小不会超过 200 MB，总大小不超过 1 GB，日志将不会保存超过 90 天。编码器展示了日志条目的构成方式。

为了添加日志的 JSON 版本，我们可以做一个类似的条目，仅包含 5 天的日志。在这里，编码器是 Logstash 编码器，用于以 JSON 格式输出。以下是此appender的代码：

<appender name="server_JSON" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>/var/log/puppetlabs/puppetserver/puppetserver.log.json</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>/var/log/puppetlabs/puppetserver/puppetserver.log.json.%d{yyyy-MM-dd}</fileNamePattern>
        <maxHistory>5</maxHistory>
    </rollingPolicy>
    <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>

要在logback.xml文件的底部启用此appender，请添加以下定义：

    <root level="info">
        <!--<appender-ref ref="STDOUT"/>-->
        <appender-ref ref="${logappender:-DUMMY}" />
        <appender-ref ref="F1"/>
    </root>

在根部分中添加<appender-ref ref="server_JSON"/>将启用我们的 JSON appender。重新启动puppetserver服务将启用新的appender。

要设置server-access.log，可以使用github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch13/appender_example.xml中的代码，这将添加一个appender，它将配置适当模式的 JSON 输出。

在这种情况下，您需要考虑磁盘空间。可以使用 JSON 日志记录来运行此操作。Logback 是一个强大的库，但本书无法涵盖所有选项。可以在logback.qos.ch/manual/configuration.html和logback.qos.ch/manual/appenders.html中查看这些选项。

现在日志文件以 JSON 格式存在，可以配置像 Grafana 的 Promtail 或 Elastic 的 Filebeat 这样的工具，将日志文件转发到像 Elastic 的 Logstash 或 Grafana 的 Loki 这样的服务。由 Logrotate 管理的 Ruby 日志也可以被收集，但这需要更多的工作，去为它们设置合适的模式进行处理。

注意

Puppet Enterprise 服务、console-services、PuppetDB 和协调服务都使用 Logback，并可以像这样转发它们的日志。

在回顾了如何将日志发送到外部服务进行处理之后，我们将看到如何将应用 Puppet 目录生成的报告通过报告处理器发送到外部工具。

报告处理器

除了服务器日志记录，如 第十章 所示，每次运行目录都会生成报告。在 第十章 中，您看到如何通过 peadm 配置它，以便使用 reports = puppetdb 在 puppet.conf 的 master/server 部分将其存储在 puppetdb 中。设置这个 reports 值告诉服务器使用报告处理器，这是一个在 Puppet Server 接收到报告时运行的 Ruby 脚本。然后该脚本执行操作，将其传递给目标。在 PuppetDB 的情况下，就是将报告发送到 PuppetDB 存储。有三个内置的报告处理器：http、log 和 store。http 将报告发送到通过 puppet.conf 中的 reporturl 设置指定的 HTTP 地址，格式为 YAML。log 将报告输出发送到 puppet.conf 中 logdest 和 logdir 指定的日志文件，而 store 将报告的输出放入 puppet.conf 中 reportdir 设置指定的文件。Puppet Forge 中还有其他自定义报告处理器可用，包括 Splunk 集成模块，详细信息请参见 forge.puppet.com/modules/puppetlabs/splunk_hec，以及 Datadog 代理模块，详细信息请参见 forge.puppet.com/modules/datadog/datadog_agent，这使得报告数据可以在这些第三方服务中查看。根据模块的不同，指令有所不同，但通常，添加报告处理器所需的最小操作是 Puppet Server 在环境中部署该模块，并且报告的转发器名称已设置。编写自定义报告处理器超出了本书的范围，但可以在 puppet.com/docs/puppet/latest/reporting_write_processors.html 中找到详细信息。

)

除了日志和报告，我们还可以通过调用状态 API 来查看当前 Puppet 基础架构的状态。

访问状态 API

Puppet 提供了一个可以通过GET /status/v1/services调用的状态端点。该端点返回服务器上所有已知服务的状态。此访问由auth.conf控制，并可以通过 Puppet CA 证书在本地访问，如下所示：

cert="$(puppet config print hostcert)"
cacert="$(puppet config print localcacert)"
key="$(puppet config print hostprivkey)"
uri="https://$(puppet config print server):8140/status/v1/services"
curl --cert "$cert" --cacert "$cacert" --key "$key" "$uri" | jq

最后的 JQ 管道（命令行 JSON 处理器）是可选的，但它使输出更具可读性。以下是 Puppet Server 状态输出的示例：

{
  "server": {
    "service_version": "7.6.0",
    "service_status_version": 1,
    "detail_level": "info",
    "state": "running",
    "status": {},
    "active_alerts": []
  },

可以通过在 URL 中添加服务名称来定位单个服务——例如，GET/status/v1/services/server。对于有额外服务的 PE 安装，应该为每个服务调用特定的端口。PE 服务将在第十四章中讨论。

这些调用的返回代码将是200，表示所有服务正在运行；404表示找不到服务；或503，表示服务状态不在运行状态。

当所有服务都在运行时，服务器状态为running；如果任何服务报告错误，则为error；如果任何服务处于starting或stopping状态，则为这两种状态之一；如果任何服务报告未知状态，则为unknown。

Puppet Enterprise 提供了一个额外的命令行选项，可以通过puppet infrastructure status命令调用 API，输出类似如下所示：

Puppet Server: Running, checked via https://pe-server-davidsand-0-cffe02.tq2kpafq5bsehkpub4ur5a35ya.xx.internal.cloudapp.net:8140/status/v1/services
  PuppetDB: Running, checked via**https://pe-server-davidsand-0-cffe02.tq2kpafq5bsehkpub4ur5a35ya.xx.internal.cloudapp.net:8081/status/v1/services**

在网页控制台中，您可以通过点击Puppet 服务状态按钮查看 Puppet 服务的状态，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_13_01.jpg

图 13.1 – 网页控制台中的 Puppet 服务状态

注

puppet status命令在 Puppet 5 中已被弃用，并在 Puppet 7 中删除。它没有使用 API 端点。

到目前为止，我们查看的日志、报告和状态让我们了解 Puppet 基础设施和客户端的行为，但它们并未告诉我们关于基础设施及其客户端的整体性能。接下来，我们将查看 Puppet 提供的指标，以及如何使用它们来监控基础设施的性能和容量。

指标、调优和扩展

为了通过服务状态 API 提供更详细的 Puppet 服务性能和健康数据，可以将level标志设置为debug；这将返回指标。例如，要返回 Puppet Server 的指标并使用 JQ 进行过滤，可以运行以下命令：

cert="$(puppet config print hostcert)"
cacert="$(puppet config print localcacert)"
key="$(puppet config print hostprivkey)"
uri="https://$(puppet config print server):8140/status/v1/services/server?level=debug"
curl --cert "$cert" --cacert "$cacert" --key "$key" "$uri" | jq ".status.experimental"

这将输出如下指标的数据，例如puppet-v3-catalog端点：

{
  "http-metrics": [
    {
      "route-id": "puppet-v3-catalog-/*/",
      "count": 41,
      "mean": 4459,
      "aggregate": 182819
    },

这给出了自服务上次重启以来，count表示对该端点进行的调用次数。mean是 5 分钟内的平均响应时间，而aggregate是服务启动以来的总时间。

各种服务中有许多度量指标。要查看这些度量的定义，可以在文档中查看 API 服务（例如，puppet.com/docs/pe/2021.7/status_api.html）。不过，总体来说，它们的文档并不完善，可能需要一些探索，或者你可以在 Puppet 的 Slack 渠道和支持渠道（如果你有合同的话）上提问。不要被大多数度量标题中的实验性标签所困扰——大多数度量数据已经可用了，只是 Puppet 尚未移除实验性标签。

注意

有关 Puppet 的底层度量库如何工作的详细解释，可通过www.youtube.com/watch?v=czes-oa0yik&t=0s观看，由该度量库的作者提供。

现在，让我们来看一下用于展示度量数据的仪表盘。

探索度量仪表盘

Puppet 提供了三种实现方式，自动化收集和展示度量数据的过程：

• Puppet 操作仪表盘，可在forge.puppet.com/modules/puppetlabs/puppet_operational_dashboards找到，是一个由 Puppet Forge 提供的支持模块，集成了 Telegraf、InfluxDB 和 Grafana，提供机制来发送 API 度量数据、将其存储在时间序列数据库中，并在预配置的仪表盘中可视化数据。操作仪表盘支持 Puppet Enterprise 和开源 Puppet。下图展示了一个此类仪表盘的示例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_13_02.jpg

图 13.2 – Grafana Puppetserver 性能仪表盘

• Splunk 插件，可在splunkbase.splunk.com/app/4413/#/overview找到，是一个在 Splunk 商店中的应用，可以添加到你的 Splunk 设置中，提供预配置的仪表盘。Splunk HTTP 事件收集器（HEC）模块可在forge.puppet.com/modules/puppetlabs/splunk_hec找到。forge.puppet.com/modules/puppetlabs/pe_event_forwarding可以与此模块结合，使用 HTTP 将度量数据发送到 HEC 模块。下图展示了一个 Splunk 仪表盘的示例，其中绘制了 Puppet 服务器内存：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_13_03.jpg

图 13.3 – Splunk Puppet 服务器内存仪表盘

Puppet 团队共同合作，保持 Splunk 和 Grafana 仪表盘的一致性。

对于 Puppet Enterprise，还有一个/opt/puppetlabs/puppet-metrics-collector目录。然后可以使用诸如grep或JQ的命令（假设终端处于度量收集器目录中）搜索这些 JSON 文件。两个常见的查询将在average-free-jrubies和queue_depth中详细解释。可以像这样添加：

grep -oP '"average-free-jrubies.*?,' puppetserver/primary.example.com/*.json puppetserver/pe-server-davidsand-0-cffe02.tq2kpafq5bsehkpub4ur5a35ya.xx.internal.cloudapp.net/*.json
"puppetserver/pe-server-davidsand-0-cffe02.tq2kpafq5bsehkpub4ur5a35ya.xx.internal.cloudapp.net/20220731T220502Z.json":"average-free-jrubies":3
jq '.. |."queue_depth "? | select(. != null)| input_filename , .' -- puppetdb/pe-server-davidsand-0-cffe02.tq2kpafq5bsehkpub4ur5a35ya.xx.internal.cloudapp.net/*.json
"puppetdb/pe-server-davidsand-0-cffe02.tq2kpafq5bsehkpub4ur5a35ya.xx.internal.cloudapp.net/20220731T221001Z.json"
0

为了更方便地共享这些数据，可以通过运行/opt/puppetlabs/puppet-metrics-collector/scripts/create-metrics-archive命令来归档数据，如果希望归档一定天数的数据，可以使用–r标志。

在了解了如何收集和显示度量后，我们将讨论一些常见的性能和容量问题，以及如何使用度量来管理它们。

识别并避免常见问题

设置好日志、状态和度量后，我们需要考虑应该关注什么以及如何检查我们的 Puppet 基础设施。应该有正常的 CPU、内存和磁盘使用情况监控，但有一些关键的功能区域需要关注。我们将在接下来的章节中讨论这些内容。

目录编译

在 第十章中，我们学习了每次目录编译都需要一个 JRuby 实例来为每个 Puppet 请求编译目录，并且 Puppet 主服务器或编译服务器提供了这个 JRuby 能力。为了计算处理基础设施负载所需的 JRuby 实例数，我们可以将运行间隔（服务器检查频率）除以编译的平均时长。这样就能得出每台服务器所需的 JRuby 实例数。然后，我们可以将预期基础设施中 Puppet 客户端的数量除以这个数字，得到所需的 JRuby 实例总数估算值：

添加此内容：总 JRuby 实例数 = Puppet 客户端数量 / (运行间隔 / 平均 编译时长

选择适当的基础设施大小可能会很复杂。可以通过在puppetserver.conf文件中运行max-active-instances来设置主服务器或编译服务器上的 JRuby 实例数；默认情况下，它设置为 CPU 数量减 1，范围为 1 到 4。每个 JRuby 实例需要在 JVM 堆栈中分配内存。对于 Puppet Enterprise，这个文件是通过设置hiera值为puppet_enterprise::master::puppetserver::jruby_max_active_instances:来控制的。

总 JVM 堆栈内存由 Puppet 服务器启动脚本分配，根据操作系统的不同，可能位于/etc/sysconfig/puppetserver或/etc/defaults/puppetserver。这个内存大小由xmx参数设置，可以计算出每个 JRuby 实例默认需要 512MB 的内存，并为其他 Java 任务保留 512MB 的空余空间：

添加此内容：*所需总堆栈大小 = 512MB + 最大活动实例数 ** 512MB

建议你永远不要超过 32 GB 的 JVM 堆栈大小。根据各种现场实验的结果，JRuby 实例的最大有效数量似乎在 11 到 13 之间。这个最大值通常适用于规模更大的环境，并且需要关注以防止编译器故障。在这种情况下，完全依赖水平扩展是不明智的；应该与垂直扩展（增加更多的编译服务器）相结合。

在刚开始时，进行大小调整建议可能会很困难——你可能不清楚你的平均编译时间会是多少，而编译的秒数可能会产生很大的影响，因此，在整个环境逐步扩展时，监控 JRuby 的使用情况和目录编译时间是明智的，并且在出现时寻找异常值。Puppet 为 Puppet Enterprise 大小调整提供了一些指南，详情请参考puppet.com/docs/pe/2021.7/tuning_infrastructure.html。

在监控目录性能时，我们有一些关键的关注点。jruby.num-jrubies和jruby.num-free-jrubies指标显示服务器上有多少个 JRuby 实例，以及其中有多少个是空闲的。在查看这些指标时，应计算基础设施的平均使用容量。建议避免超过 80%的使用率，因为性能通常在超过这个值后无法扩展。你还应该确认负载均衡器没有问题，并且空闲的 JRuby 实例在编译器之间使用均衡。一个可能发生的问题是雷鸣群体效应，即许多服务器同时请求目录编译。这可以通过 JRuby 实例使用的巨大峰值在指标中看到。如果你遇到这种情况，可以使用Puppet 运行调度器模块，详情请参见forge.puppet.com/modules/reidmv/puppet_run_scheduler，来分散 Puppet 代理运行的调度。

如果超过了 JRuby 池的容量，请求将会排队并在默认情况下超时，超时为 10 秒。borrow-timeout-count指标提供了等待 JRuby 实例变得可用时超时的请求数量。

目录运行时间

如前所述，目录的运行时间对基础设施中所需的 JRuby 实例数量有巨大影响。查看metrics-time-total指标，它显示报告事件发送的编译时间，我们可以查看编译的平均时间，帮助进行容量计算。我们还可以查看这些数据的分布，看看是否存在任何极端异常值，我们希望对该目录及其 Puppet 代码进行调查。

可以查看以下表格中一些关键区域：

指标定义	指标名称
目录编译时间	Metrics-time-config_retrieval
应用目录的时间	Metrics-time.catalog_application
目录中的资源数量	Metrics-resources-total
生成事实的时间	Metrics-changes-total

表 12.1 – 目录指标

在这些度量指标中，您应该确保每个异常值是有原因的。如果代码或事实较为复杂，或某些资源已知较慢，这可能是正常的，或者可能是需要在应用到更多服务器之前审查的低效代码，从而节省基础设施容量。

PuppetDB 和 PostgreSQL 调优

对于 PuppetD，最佳的监控指标是 jvm-metrics.heap-memory.committed 和 jvm-metrics.heap-memory.used。如果已用内存的大小经常接近已分配内存的大小，最好增加堆栈大小。与编译器类似，这涉及到更新 /etc/sysconfig/ 或 /etc/default/puppetdb 中的 puppetdb 或 pe-puppetdb 配置文件（取决于操作系统），并更新 JAVA_ARGS 参数。例如，如果你发现 jvm-metrics.heap-memory.committed 设置为 512 MB，但 jvm-metrics.heap-memory.used 经常接近这个限制，可以将最大堆内存大小从 JAVA_ARGS ="-Xmx512m" 更新为 JAVA_ARGS="-Xmx1g"。完成后，需要重启 PuppetDB 服务。但是，请注意，所有因内存不足而排队的任务将在重启后继续执行。对于 Puppet Enterprise，这个文件可以通过将 hiera 值设置为 puppet_enterprise::profile::puppetdb::java_args: 来控制。

另一个好的性能指示是队列深度，表示为 puppetdb-status.status.queue_depth 指标。如果这个值很高且有空闲的 CPU，那么增加 PuppetDB 可用的 CPU 线程数量将是有益的。这可以在 PuppetDB 配置文件 /etc/puppetlabs/puppetdb/conf.d 中完成。如果 PuppetDB 是通过包安装的，可以在 [command-processing] 部分的 threads 键中设置，或者如果使用了 Puppet PuppetDB 模块（在 Puppet Enterprise 中也是如此），则应使用模块的设置来调整类。在 Puppet Enterprise 中，可以在 Web 控制台的 节点组 部分进行调整。任何对线程的更改都需要重启 PuppetDB 服务。

反向场景是，CPU 使用率很高且限流，但 PuppetDB 队列较低，这时应释放线程以提高其他服务的吞吐量。

调优大小

为了帮助根据可用硬件获得正确的服务器设置，Puppet Enterprise 提供了 puppet infrastructure tune 命令。

这会计算出应用于服务器的最佳设置。以下是命令输出中的建议 Hiera 设置示例：

puppet_enterprise::profile::database::shared_buffers: 3176MB
puppet_enterprise::puppetdb::command_processing_threads: 1
puppet_enterprise::profile::puppetdb::java_args:
  Xms: 1588m
  Xmx: 1588m
puppet_enterprise::profile::orchestrator::jruby_max_active_instances: 2
puppet_enterprise::profile::orchestrator::java_args:
  Xms: 1588m
  Xmx: 1588m
puppet_enterprise::profile::console::java_args:
  Xms: 1024m
  Xmx: 1024m
puppet_enterprise::master::puppetserver::jruby_max_active_instances: 2
puppet_enterprise::profile::master::java_args:
  Xms: 1536m
  Xmx: 1536m
puppet_enterprise::master::puppetserver::reserved_code_cache: 192m

这些提取的数据可以放入 Hiera 文件中，并与主服务器进行分类。请注意，如果内存足够大，它会推荐堆大小配置超过 32 GB。这是次优配置，正如我们在查看编译大小和问题时讨论的那样。

以下是一般建议：

处理度量指标的数量可能看起来很困难，尤其是在缺乏明确定义的情况下，但如果使用 Splunk 插件或操作仪表板，这可以为你提供与 Puppet 支持团队使用和监控的一致视图。了解你的环境在这些数值下的常态行为，并查看图表中的尖峰，将它们与其他数据关联起来，可以帮助你发现问题。

使用 Puppet 的知识库，它自 2021 年 4 月起向所有用户开放，可以帮助你搜索问题。查看如 support.puppet.com/hc/en-us/sections/360000926413-Performance-tuning 这样的文章集合，可以帮助你更深入理解你遇到的任何问题。

实验 – 配置度量仪表板

在讨论了度量标准和 Puppet 的两种查看选项之后，我们可以配置 Splunk 仪表板和 Puppet 操作仪表板，以查看提供的仪表板。使用前一部分中描述的关于 PuppetDB 和编译器容量的问题，找到可以帮助你调查的图表。

配置 Puppet 操作仪表板：

1. 选择一个节点来托管 Puppet 操作仪表板，并在 Web 控制台中将 puppet_operational_dashboards 分类为节点组。

2. 在节点组的 PE 基础设施代理中，将 puppet_operational_dashboards::enterprise_infrastructure 添加到 Classes（类）标签下的类列表中。

3. 在所有节点上运行 puppet，直到服务器显示为干净状态。

4. 登录到 https://<operational_dashboard_node_ip>:3000，user=admin password=admin。

配置 Splunk：

1. 在 www.splunk.com/en_us/sign-up.html?301=/page/sign_up 注册一个 Splunk 账户（这是免费的）。

2. 选择另一个节点来托管 Splunk Enterprise，通过在 Web 控制台上将 splunk::enterprise 分类为节点组并固定所选节点。

3. 安装 Puppet 报告查看器：

   1. 登录并下载 splunkbase.splunk.com/app/4413/。

   2. 登录到 https://<splunk_server_ip>:8000，username=admin 和 password=changeme。

   3. 选择 Apps 栏左上角的齿轮图标。

   4. 在下一个屏幕中，选择右上角的 upload app from file（从文件上传应用）。

4. 在 Splunk 中将许可证设置为免费：

   1. 点击右上角的 Settings（设置）。

   2. 在系统下拉菜单中，选择 Licensing（许可）。

   3. 选择 change（更改） license group（许可证组）。

   4. 选择 free license（免费许可证）并点击 Save（保存）。

5. 在 Splunk 中创建 HEC 令牌：

   1. 在 Splunk 控制台中导航到 Settings | Data Input。

   2. 添加一个新的 HTTP 事件收集器，命名为您选择的名称。

   3. 确保 Indexer acknowledgement 未启用。

   4. 单击 Next 并将 source type 设置为 Automatic。

   5. 确保 App Context 设置为 Puppet Report Viewer。

   6. 添加主索引。

   7. 设置 默认索引 为 main。

   8. 单击 Review 然后点击 Submit。

6. 在 PE 基础设施节点组中，将 puppet_metrics_collector 分类为 metrics_server_type 参数设置为 splunk_hec。

7. 将 splunk_hec 分类为 enable_reports 设置为 true

8. events_reporting_enabled 设置为 true

9. manage_routes 设置为 true

10. token 设置为 <在第 5 步生成的 token>

11. url 设置为 https://<public_ip_of_splunk_server>:8088/services/collector

12. 登录 https://<public_ip_of_splunk_server>:8000，并运行 index=* sourcetype=puppet:summary 以确保数据正在被收集（可能需要一些时间才能开始）。

现在 Puppet 操作面板和 Splunk 已经配置完成，浏览各种图表和面板，找到与目录容量和 PuppetDB 性能相关的图表。

如果可能，请保留 Splunk 设置，以便在下一部分中使用，因为库存和库存趋势视图是 Facter 终端输出的仪表板视图。

现在您已经了解了如何集成 Puppet 的状态、日志和指标，我们可以查看一种模式，该模式允许我们将 Puppet 与其他服务集成，并为 Puppet 用户提供自助服务。

外部数据提供者模式

Puppet 将不再是您系统中唯一的配置和信息来源。很可能会有多个 配置管理数据库（CMDBs），例如 ServiceNow 或应用程序团队用于存储信息的内部开发系统。您的几位同事和内部客户可能希望能够创建例外和自定义，而无需了解 Puppet 代码及其部署工作流。同时，也会有需求希望能够将 Puppet 数据反馈到外部系统。外部数据提供者模式使这一切成为可能，允许您执行以下操作：

• 在分类中进行更改

• 添加和更改受信任的事实

• 将现有数据作为事实或 Hiera 数据输入

• 将 Facter 数据发送到外部源

在介绍了外部数据提供者模式的核心概念后，我们将探讨其中使用的每个技术组件。

了解外部数据提供者组件

该模式的底层组件如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_13_04.jpg

图 13.4 – 外部数据提供者模式的核心组件

我们将逐一展示这个模式是如何工作的。本书无法展示如何编写每个组件，但我们会详细说明文档在哪里可以找到。在接下来的部分中，将参考示例实现：

后端存储服务（BSS）允许你存储数据以供使用。BSS 的技术解决方案并不重要，但它必须具有韧性，并且在读取时提供高吞吐量。

该吞吐量可以通过 2 + <Hiera 层数> 来计算每次 Puppet agent 执行时的读取次数。为了说明如果一个 10,000 台服务器的环境使用默认的 30 分钟 agent 执行时间，并且有 5 层 Hiera 配置时，如何计算该吞吐量，可以这样计算：(2+5) * 10,000 / 1,800 = 39 次查询每秒（四舍五入）。

像 CMDB 或内部应用程序这样的工具可以直接进行查询并充当 BSS，但该工具能够处理工作负载。

trusted 外部命令在 Puppet 6.11 和 7.0 中引入，允许在 Puppet 执行期间运行脚本，并从外部源收集事实和分类信息。此脚本应以客户端的 certname 属性作为参数，返回一个包含事实的 JSON 哈希，并且对于任何未知的 certname 返回错误代码。可以通过在每个主服务器和编译服务器的 puppet.conf 文件的 master/server 部分中使用 trusted_external_command 设置来配置此脚本。此命令返回的事实将包含在 trusted.external.basename 下，其中 basename 是脚本的名称。自 Puppet 6.17 和 7.0 起，还可以通过将 trusted_external_command 设置为包含多个脚本的目录来使用多个受信外部命令。这对于查询多个源非常有用。每个源将获得不同的基本名称。在外部数据提供者模式中，它用于查询 BSS。

Hiera 后端使用 Ruby 或 Puppet 编写的函数在执行 Hiera 查找时查询 API 或其他源。在外部数据提供者模式中，后端查询 BSS 以获取值。有关此内容的文档，请参见 puppet.com/docs/puppet/latest/hiera_custom_backends.html。

Puppet 允许使用称为 termini 的可插拔后端，并使用间接器，如 第十章 中所讨论的，允许 Ruby 脚本访问端点上的键值对。事实 termini 是访问事实端点的 Ruby 脚本，允许将数据发送到其他外部系统。有关此内容的更多详细信息，请参见 puppet.com/docs/puppet/latest/indirection.html 和 puppet.com/docs/puppet/latest/man/facts.html。

外部数据提供者实现

在撰写本文时，没有单一的外部数据提供者模式实现所有部分，但它们可以结合使用，以集成多个系统和用途。本节中的示例列表并不旨在穷尽所有内容，但应该能展示可以进行调查的集成范围。如果有必要，我们还将提供文档示例，后续可根据需要进行扩展。

Satellite

Red Hat Satellite 可以通过报告处理器接收来自 Puppet 服务器的报告，同时使用可在 forge.puppet.com/modules/puppetlabs/satellite_pe_tools 获取的模块。然而，也可以使用 puppetserver_foreman 模块来配置一个受信任的外部命令，以便从 Satellite 收集各种配置信息，例如智能参数和组织信息作为事实。由于 Puppet 被移除作为默认的配置管理选择，并改为作为可选插件使用，而且 Puppet 版本未能跟上 Satellite 平台的开发进展，参考 www.redhat.com/en/blog/upcoming-changes-puppet-functionality-red-hat-satellite，使用此受信任的外部命令可以将 Puppet 服务器的功能迁移为独立的 Puppet 基础设施，而配置则保存在 Satellite 的 Foreman 组件中。请参阅文件/Satellite，了解受信任的外部命令：github.com/theforeman/puppet-puppetserver_foreman。

ServiceNow

已为 Puppet 开发了多个 ServiceNow 集成；CMDB 集成允许使用来自 forge.puppet.com/modules/puppetlabs/servicenow_cmdb_integration 的模块提供的受信任命令。

由于大量节点的使用可能会使 ServiceNow 因查询而不堪重负，因此 ServiceNow 应仅在较小规模的 BSS 中使用。它提供了一个使用受信任命令的有用示例。

已开发出一种更好的方法来确保扩展性，其中 ServiceNow 图连接器连接到 Puppet API 并收集必要的数据：store.servicenow.com/sn_appstore_store.do#!/store/application/42ae987a1b832c10fa34a8233a4bcb0b。

Azure Key Vault

Azure Key Vault 的集成是一种调用 Puppet 代码中 azure_key_vault::secret 的功能。可以与 Hiera 后端一起使用来访问 Azure Key Vault 秘密。这是一个经过批准的模块（forge.puppet.com/modules/tragiccode/azure_key_vault）。

1Password

1Password 集成是一个 Hiera 后端，允许在 1Password 设置中进行密钥查找调用：forge.puppet.com/modules/bryxxit/onepassword_lookup。

Vault

两种 Vault 解决方案（服务器端和客户端）已在 第九章 中讨论并演示，但为了回顾，服务器端 Vault 查找实现了一个名为 hiera_vault 的 Hiera 后端查找功能。正如在 forge.puppet.com/modules/petems/hiera_vault 中所讨论的，这允许通过 Hiera 调用 Vault 中的密钥并将其编译到代码中。

Puppet 数据服务

Puppet 数据服务 (PDS) 提供了外部数据提供者模式的最完整实现之一，唯一的不同是它实现了一个事实终端。PDS 包含以下组件：

• 一个允许用户和应用程序交互的 REST API 和 CLI

• 一个可插拔的后端数据库，用于提供 BSS（在编写时，仅支持 PostgreSQL）

• 一个用于查询 BSS 的 Hiera 后端

• 用于查询 BSS 的受信任外部命令

PDS 的设计重点不局限于某一特定的集成，而是允许 Puppet 平台团队利用外部数据提供者模式提供自助服务并减少操作负担。PDS 提供了一个安装模块（github.com/puppetlabs/puppetlabs-puppet_data_service）。构成应用程序和 API 的代码（github.com/puppetlabs/puppet-data-service）打包为 deb 和 rpm 格式，这些包由 install 模块使用。在编写时，这两个模块仅为 Puppet Enterprise 安装设计，但基础设置并没有将应用程序局限于 Puppet Enterprise，这意味着它可以适配到开源 Puppet。

Splunk

在本章的 日志记录和状态 部分，我们讨论并演示了如何通过 splunk_hec 模块利用相同的模块事实终端，将通信从 Puppet 服务器发送到 Splunk 服务器的 Splunk Hec URL（github.com/puppetlabs/puppetlabs-splunk_hec/blob/main/lib/puppet/indirector/facts/splunk_hec.rb）。

Puppet 运行的事实可以发送到 Splunk，然后可以通过 Splunk 应用程序中的库存和库存趋势查看这些数据（splunkbase.splunk.com/app/4413/）。

实验室 – 使用 Splunk 和 Puppet 数据服务的动手操作

在讨论了几个集成之后，如果你按照前面的实验步骤进行了 Splunk 安装或重新安装，你可以登录到 Splunk 并查看 inventory 和 inventory trend 标签。在这里，你将看到 Facter 终端的输出，并可以尝试查看节点中的数据。

在本部分实验中，你将看到如何使用 PDS 来分类节点、更新 Hiera 数据并添加受信事实。

要安装 PDS，你需要执行以下任务：

1. 查看你克隆的控制仓库中的 hiera.yaml 和 site.pp 文件，了解 PDS 如何使用它们。

2. 配置两个必需的应用程序角色。

3. 对于数据库服务器，执行以下操作：

   1. 从 PE 控制台添加一个新的节点组：

   Parent name: PE Infrastructure
   Group name: PDS Database
   Environment: production
   

   1. 将 puppet_data_service::database 类添加到你在前一步创建的 PDS 数据库组中。

   2. 在执行这些步骤之前，使用规则选项卡节点将现有主服务器添加到该组中。

   3. 提交你的更改。

4. 对于 PDS API 服务器，执行以下操作：

   1. 选择 puppet_data_service::server 类。

   2. 包括 database_host: <FQDN of your primary server> 参数

   3. 选择 sensitive pds_token 参数。你可以使用 www.uuidgenerator.net/ 来生成一个 token。

   4. 提交你的更改。

5. 在所有节点上运行 Puppet，直到报告显示没有更改。

6. 在单独的终端窗口中创建一个到主服务器和一个节点的 SSH 会话。

7. 在主服务器上，运行 pds-cli node upsert <fqdn_of_node> -c motd -e production 命令。

8. 在节点上运行 puppet agent –t。在命令输出中，你将看到 motd 已应用默认设置。

9. 在主服务器上，运行 pds-cli hiera upsert nodes/<fqdn_of_node> motd::content -v '"Hello world its PDS\n"'。

10. 在节点上运行 puppet agent –t。在命令的输出中，你将看到应用了我们设置的 Hiera 覆盖的 motd。

11. 在主服务器上，运行 pds-cli node upsert <fqdn_of_node> -c motd -d '{"status": "Testing"}' -e production 和 pds-cli hiera upsert nodes/<fqdn_of_name> motd::content -v '"Hello world, I am a PDS %{``trusted.external.pds.data.status} Server\n"'。

12. 在节点上运行 puppet agent –t。观察它应用了带有 Hiera 覆盖的新的 motd，并为受信事实设置了 testing 值。

13. 登录到控制台，查看节点及其事实，检查是否设置了受信事实 pds.data.status 为 testing。

总结

在本章中，我们总结了各种日志位置，并向您展示了如何将日志转化为 JSON 格式并导出，以便它们能够在如 Elastic 或 Grafana 等日志工具集中处理，这些工具能够更好地对日志进行索引以便查看和分析。我们了解了如何在 Puppet Server 上使用报告处理器，以便通过在客户端应用目录来生成报告。这使得报告能够发送到像 Splunk 这样的工具，并支持高级可视化和搜索。我们还讨论了可用的状态 API，说明了如何通过 API 调用来查找所有正在运行的服务或某个特定服务的状态。展示了 Puppet Enterprise 具有命令行（Puppet Infrastructure status）和 Web 控制台选项来调用该 API。通过这些机制，您学习了如何访问关键日志和指标，以便了解系统的当前状态。

为了更好地利用这些信息并深入了解服务的性能，您学习了如何通过在状态 API 中使用debug标志来获取 Puppet 指标，以及如何使用 Puppet 操作仪表板和 Splunk 插件等工具来收集和可视化这些数据。Puppet Enterprise 具有 Metrics Collector 模块，它会将指标以 JSON 文件格式本地收集，您可以手动查看或导出这些文件。

为了更好地理解如何使用这些指标和仪表板，我们回顾了一些常见问题，讨论了如何为目录编译调整基础设施规模，避免像“雷鸣效应”这样的服务器需求过度集中的问题，并探讨了如何根据需求的增加或减少来调整 PuppetDB。展示了 PE 中各种基础设施调优工具作为优化已部署硬件设置的选项。

接下来，我们介绍了外部数据提供者模式，它提供了自助服务机制，使得 Puppet 数据能够在外部服务上访问，以便更好地集成。展示了一个后端存储服务的核心组件，用于存储能够处理 Puppet 查询的级别的数据，同时展示了受信任的外部命令和 Hiera 后端作为查询这些数据的方法。展示了 Fact 终端作为从 BSS 导出数据到外部服务的方式。

当使用不同的 Hiera 后端时，展示了这些组件的各种实现，其中 1Password、Azure Key Vault 和 Vault 被展示为访问外部秘密管理器的方式，而 Satellite 和 ServiceNow 则展示了可以通过受信任命令将这些应用程序中的数据输入到 Puppet 代码中的方式。

Puppet 数据服务被证明是该模式最完整的实现之一，并提供了一个稳固的设计，使得内部客户能够在不需要全面了解 Git 工作流和 Puppet 语言的情况下，访问适当暴露的 Puppet 选项，进而实现自助服务。

本节介绍了外部数据提供者模式，展示了如何通过 Puppet Enterprise 实现强大的集成，将数据输入和输出到不同的工具，并朝着将 Puppet 作为重要组成部分来构建平台的目标迈进。

在前一部分讲解了 Puppet Server 的组件、如何在大规模监控性能并进行集成后，下一章将讨论 Puppet Enterprise 特定的服务及其组件。它将描述什么是 Puppet Enterprise，它与开源版本有何不同，提供了哪些额外的服务，以及 Puppet 提供的参考架构，这些架构能更轻松地扩展和使用工具自动化部署及其状态。还将讨论专门针对 Puppet Enterprise 的项目和集成。

第四部分 – Puppet Enterprise 与 Puppet 采用方法

本部分将讨论 Puppet Enterprise 及其与开源版本的区别。我们将回顾一些可以扩展 Puppet Enterprise 的 Puppet 相关产品，以及一些 Puppet Enterprise 的具体集成。接着，我们将探讨有助于组织成功采用 Puppet 的方法。我们将探讨如何正确界定用例，从而从常规交付中获益，Puppet 如何在平台工程中发挥作用，以及如何在传统遗留环境和高度监管、变更管理的环境中使用 Puppet。

本部分包含以下章节：

• 第十四章，Puppet Enterprise 简介

• 第十五章，采用方法

第十四章：Puppet Enterprise 简要概述

本章将概述Puppet Enterprise，它是什么以及与开源 Puppet相比提供了哪些功能。尽管本书的作者是 Puppet 员工，但本章并非强行推销，而是介绍如何有效地使用 Puppet Enterprise。它将介绍 Puppet 平台中的额外企业控制台服务，展示代码部署、编排服务、RBAC、Web 控制台以及其他各种服务如何自动配置并协同工作。这将有助于理解 Puppet Enterprise 与开源 Puppet 的区别，以及在开源 Puppet 中需要手动创建的预配置和内建功能。将重点介绍支持的架构模式，帮助理解如何使用 Puppet Enterprise 包装和模块自动部署这些模式，从而部署和扩展 Puppet 基础设施。还将讨论一些相关项目和集成，以及它们如何融入 Puppet Enterprise 环境。

本章将涵盖以下主要内容：

• 什么是 Puppet Enterprise？

• 探索 Puppet Enterprise 控制台和服务

• 在 Puppet Enterprise 中使用 Bolt

• 自动化部署和参考架构

• Puppet Enterprise 相关项目和工具

• 实验—Puppet Enterprise 扩展与配置

技术要求

从 github.com/puppetlabs/control-repo 克隆控制仓库到你的 controlrepo-chapter14 GitHub 账户，并更新此仓库中的 Puppetfile 文件：github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch14/Puppetfile。

通过下载来自 github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/blob/main/ch14/params.json 的 params.json 文件，并根据控制仓库的位置以及控制仓库的 SSH 密钥进行更新，构建一个带有副本的集群，包含三个编译器和三个客户端。然后，从 pecdm 目录运行以下命令：

bolt --verbose plan run pecdm::provision –-params @params.json

什么是 Puppet Enterprise？

在讨论 Puppet Enterprise 时，常见的误解是该产品的某些功能被限制，无法为开源用户提供。Puppet Enterprise 的目标并非限制开源用户可用的功能，而是为那些希望轻松使用 Puppet 的客户提供价值，使他们能够通过减少自身在平台上的开发和自动化工作，专注于获得配置管理的价值。

Puppet 通过确保在 Enterprise 中，组件的打包与自动化安装脚本和模块一同进行版本控制和测试，从而减少用户管理基础设施所需的工作量。Puppet Enterprise 使用两种不同类型的版本发布。Puppet Enterprise 采用 xxxx.y 模式，通常每 3 个月更新一次，截至目前为 2023.0。该版本计划在 2023.3 升级到 Puppet 8.x 版本，并将在其生命周期内不断推出新功能。此版本推荐给那些希望访问最新功能和修复的用户，并且需要定期更新。另一种发布类型是长期支持（LTS）版本；此版本遵循 xxxx.y.z 模式。该分支通常每 3 个月更新一次，但更新只包含修复而不包括新功能。LTS 版本的生命周期为 2 年，并与下一个主要的 xxxx 版本重叠 6 个月，因此当前的 2021.7.z LTS 将于 2024 年 8 月 31 日结束主流支持，届时将继续提供重叠支持，直到 2025 年 2 月 28 日，此后用户应迁移到所需版本的 Puppet。2023.y 将成为新的 LTS 发布版本，继续获得 Puppet 的支持。这两种运行中的 Puppet Enterprise 版本通常与两个处于积极开发中的开源 Puppet 版本相对应。2023.0 的发布终止了 Puppet 6，预计 2023 将在 2023.3 版本或稍后转向 Puppet 8。

企业许可证最显著的特点是支持，用户可以向团队提出支持案例，这些团队可以审查基础设施问题并协助解决任何问题或提供支持的模块所需的功能。

Puppet 还提供各种专业服务，如现场服务，提供实操培训和建议。这可能会引导进行架构审查，以了解如何在你的环境中最佳实施，并为产品和解决方案的开发流程提供反馈，如Puppet 数据服务（PDS）和Puppet Enterprise 管理模块（peadm）。此外，技术账户经理（TAMs）将被分配为你提供定期的联系人，帮助你在 Puppet 中取得成功，支持你为你的组织制定成功计划，并专注于确保部署能够实现其目标。

Puppet 提供了 Puppet 产品的参考架构和模式，展示如何在不同的规模和实现类型下工作。构建在 Puppet Server 服务之上的附加应用程序允许进行访问控制、服务器分类、代码部署、可视化和数据搜索，所有操作都可以通过控制台以标准方式完成。我们将在接下来的部分中更详细地探讨这些内容。

探索 Puppet Enterprise 控制台和服务

在Puppet Enterprise 主服务器中内置了若干附加服务，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_01.jpg

图 14.1 – Puppet Enterprise 组件

Puppet 服务器

Puppet 服务与第十章中讨论的相同，证书颁发机构 (CA) 提供证书签名过程以保证通信安全，Puppet 代理联系编译器的 Puppet 服务器服务请求目录编译。 Facter 用于提供服务器配置文件。在 图 14*.1* 中，我们选择不显示主服务器本身有一个 Puppet 服务器服务，并且编译器和主服务器都有 Puppet 代理，它们都从主服务器的 Puppet 服务器请求目录编译。

引入 Puppet Web 控制台组件

Puppet Enterprise 服务器最明显的直接差异是提供我们在本书实验室中使用的登录视图的 Web 控制台。几个服务结合在一起形成控制台服务

控制台是一个基于 Jetty 的 Clojure Web 前端服务，具有充当反向代理的 NGINX 服务器。 NGINX 服务器在 HTTPS 端口 443 上监听并将 HTTP 80 重定向到 HTTPS。控制台 UI 提供聚合和翻译 Jetty-based Clojure 服务以生成正确的页面并访问其他控制台服务。

认证 UI 生成登录和重置密码内容页面。展示这一点的最简单方式是使用登录时所需的通信示例，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_02.jpg

图 14.2 – 生成登录页面的步骤

可以从图表中看出，作为第一步，NGINX 服务器接收 GET 请求，并在执行 TLS 协商后重定向到控制台 Jetty 页面。该页面评估 cookie，确认用户未登录，并重定向到 auth/login 页面，该页面从 NGINX 请求并重定向到认证 UI。认证 UI 生成登录页面，并从 RBAC Jetty 页面获取 安全断言标记语言 (SAML) 配置，然后将此登录页面传回用户。

RBAC 服务 具有用户和角色来构建访问策略。它允许在 Puppet Enterprise 中使用本地和远程用户，并可以集成到 轻量目录访问协议 (LDAP) 和 SAML 服务中。所有用户默认被拒绝创建、编辑或查看 Puppet Enterprise 的任何部分的权限，然后通过角色授予权限。

默认情况下，将有一个本地管理员用户作为 Puppet 服务的超级用户以及用于 Puppet 服务内部通信的 API 用户进行身份验证。它不能用于登录，只能通过证书身份验证进行身份验证。有一个允许列表，其中包含可以与 API 用户一起使用的证书的 certname 值。

角色允许将权限分组，以便授予用户执行操作的权限。权限由类型、权限和对象组成。类型是权限将允许在其上执行操作的对象，例如用户或节点组。权限是创建、编辑或查看的访问级别，而对象是类型的特定实例，例如节点组类型中的 Puppet Enterprise 基础设施节点组。

默认提供五个角色：

• 管理员：所有权限

• 操作员：创建和修改节点组、部署代码、运行 Puppet、签署证书并查看控制台的权限

• 查看者：查看控制台、节点组和作业的权限

• 代码部署者：使用代码管理器部署代码的权限

• 项目部署者：部署项目、从项目中运行任务和计划，并在调度器中启动、停止和查看作业的权限

可以通过参考puppet.com/docs/pe/2021.7/rbac_permissions_intro.html#user_permissions来创建自定义角色，以找到正确的用户权限粒度。

LDAP 解决方案，如Active Directory（AD）可以将用户组映射到角色，而SAML 解决方案，如Okta，可以通过属性对用户组进行类似的映射，以匹配角色。LDAP 和 SAML 都可以在 Web 控制台的访问控制选项卡中配置，通过选择相应的选项来进行映射。

令牌用于所有 Web 会话，且在运行命令时不需要每次都用密码登录，而是可以生成多个用途的令牌。这些令牌是介于0和2²⁵⁶ – 1之间的字母数字值，存储在数据库中，并根据参数存储在本地文件位置。令牌通过令牌 API 端点、puppet access login命令的 Web 控制台或 CLI 生成。令牌是基于提供的用户凭据生成的，因此将具有该用户设置的权限。默认情况下，puppet access login命令会将令牌写入~/.puppetlabs/token，其生命周期为 30 分钟，除非使用--lifetime选项设置例如5h（5 小时）的生命周期。--print标志会使令牌仅被打印而不存储，这适用于基于服务的 API 访问。

在第十一章中讨论了分类服务，我们探讨了它如何使用节点组在 Puppet 中对服务器进行分类，但为了重申关键点，节点组用于通过使用事实或直接固定命名的服务器来将类分类到服务器。节点组是基于继承的，因此节点组的每个子节点都会继承其上方的所有内容。

代码管理器在第十一章中进行了讨论，展示了如何使用r10k从命名的 Git 存储库中的控制仓库下载基于 Puppet 文件的模块，然后通过filesync服务器和filesync客户端保持该代码副本在各个服务之间同步。

活动服务用于记录通过控制台服务发生的所有活动，可以通过 API 端点以及在 Web 控制台的多个位置查看，例如任何用户和角色的活动标签。

Puppet Enterprise 的数据库组件，PuppetDB与PostgreSQL，与第十章中讨论的一样，但几个服务需要额外的数据库来存储它们的状态和记录。因此，创建了以下数据库：

• pe-activity：控制台服务的所有可审计活动

• pe-classifier：所有节点组信息

• pe-inventory：无代理客户端详细信息及其访问方式，用于编排器

• pe-orchestrator：作业运行、作业结果、用户和节点

• pe-postgres：用于模板和一般访问的 Postgres 数据库。请参阅www.postgresql.org/docs/current/manage-ag-templatedbs.html以进一步了解模板数据库。

• pe-puppetdb：报告、节点信息和上次运行的清单

• pe-rbac：用户、角色、组以及 AD/LDAP 信息

注意

所有 PostgreSQL 通信均使用证书进行，包括与副本的通信。

在图 14**.1中未涉及的一个组件是编排器服务。现在我们将介绍编排器如何提供在 Puppet Enterprise 中使用 Bolt 计划和任务的能力。

使用 Bolt 与 Puppet Enterprise

在第十二章中，介绍了如何在 Bolt 项目中使用bolt二进制文件运行 Bolt，但它可以通过编排器服务与 Puppet Enterprise 集成，允许将计划和任务作为 Puppet Enterprise 的一部分运行。

主要区别在于，目前只能部署包含任务和计划的 Puppet 模块（包括将它们添加到控制仓库）；目前没有直接将 bolt 项目部署到 Puppet Enterprise 的方法。

注意

通过模块部署的计划和任务意味着相同的计划或任务可以有多个版本，具体取决于运行环境。

还需要注意，并非 Bolt 原生提供的所有功能都能在 Puppet Enterprise 中使用。

以下列表突出显示了在编排器中运行 Puppet Enterprise 的计划和任务与在原生 Bolt 中运行时的主要区别：

• 用于计划的各种 Bolt 功能，如prompt、parallelize和file.upload，尚未实现

• puppet apply模块只能应用于具有 Puppet 代理的节点

• 目标和本地主机目标不可用

• 文件源必须基于模块，不能是绝对路径

这些大部分限制反映了没有从本地机器运行 Bolt，以及缺少运行它们的提示。完整的详情可以在 Puppet 的文档中查看：puppet.com/docs/pe/2021.7/plans_limitations.html。

Puppet Enterprise 处理三种类型的节点，包含计划和任务：

• 安装了 Puppet 代理的节点，使用Puppet 通信协议（PCP）和PCP 执行协议（PXP）

• 通过Windows 远程管理（WinRM）和安全外壳（SSH）传输的无代理节点

• 通过如 F5 和Palo Alto Networks 操作系统（PAN-OS）等传输或通过资源 API 提供的传输连接的无代理设备，如交换机或防火墙

在介绍了编排器可以运行的计划和任务之后，我们现在来看一下构成编排器的组件，重点介绍这些服务的目的和关键细节，如日志位置和配置文件。

编排器服务

编排器应用是一个由下图所示服务组成的Clojure应用：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_03.jpg

图 14.3 – Puppet 编排器服务的组成部分

让我们概览一下这些组件及其相关的服务和日志文件：

• pe-orchestration-services.service并记录到/var/log/puppetlabs/orchestration-services/orchestration-services.log。

• POST /command/create-connection 清单 API 调用（puppet.com/docs/pe/2021.7/node-inventory-v1-command-endpoints.html#node-inventory-v1-command-endpoints）。这些条目通过一个密钥加密，默认情况下存放在/etc/puppetlabs/orchestration-services/conf.d/secrets/keys.json，尽管这些条目是单独列出的，但清单服务运行在pe-orchestration-services内。它将数据存储在 PostgreSQL 清单数据库中。

注意

添加到清单中的无代理节点会计入 Puppet Enterprise 的整体授权节点数。

• pe-bolt-server.service并记录到/var/log/puppetlabs/bolt-server/bolt-server.log。

• pe-ace-server.service并记录到/var/log/puppetlabs/ace-server/ace-server.log。

• /var/log/puppetlabs/orchestration-services/pcp-broker-access.log和一般服务日志记录到/var/log/puppetlabs/orchestration-services/pcp-broker.log。

• pxp-agent.service并记录到/var/log/puppetlabs/pxp-agent/pxp-agent.log。

orchestrator 服务将通过 RBAC 验证 Puppet Enterprise 控制台用户是否拥有正确的权限。对于计划，只能指定用户或组以及他们可以运行的计划，不限制节点或计划来源的环境。对于任务，任务目标允许指定一组任务和一个 Puppet 查询语言 (PQL) 查询节点或节点组，任务可以针对这些节点执行。这可以通过 API 调用完成，如 www.puppet.com/docs/pe/2021.7/orchestrator_api_commands_endpoint.html#orchestrator_api_post_command_task_target 所示，或者通过 RBAC 图形用户界面，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_04.jpg

图 14.4 – 在 web 控制台上创建任务目标

在下一节中，我们将学习如何通过 orchestrator 运行任务、计划或 Puppet 运行。

运行作业

当通过 orchestrator 运行任务、计划或 Puppet 运行时，它们被称为 作业。有三种方式运行作业，如下所示：

• 第一种方法是通过 GUI 选择左侧栏中的相关菜单。

• 第二种方法是通过主服务器上的 CLI，语法与 puppet task run 和 puppet plan run Bolt 命令基本相同。与 Bolt 的关键区别在于，--nodes 标志用于代替 targets（反映了您只提供节点名称，而 orchestrator 将查找传输信息），并且提供了额外的标志，如 –node-groups 标志，用于选择要运行的节点组。以下是一个示例：

  puppet task run examplemodule::exampletask paramter1=value1 paramter2=value2 --node-group <node group id>
  puppet plan examplemodule::exampleplan parameter1=value1  --nodes examplehost.com,examplehost2.com
  puppet job run --query 'inventory { facts.os.name = "windows" }'
  

• 第三种方法是通过 puppet.com/docs/pe/2021.7/orchestrator_api_commands_endpoint.html 中文档化的 API，以下是一些关键调用：

  • POST /command/deploy: 按需运行 Puppet

  • POST /command/plan_run: 运行计划

  • POST /command/task: 在一组节点上运行任务

正在进行的作业可以通过按下 Ctrl + C 在 CLI 中停止，或选择 POST /command/stop API 命令。虽然我们应该小心，注意停止的作业底层进程可能会继续运行直到完成。

在 PE 2021.7.1 中引入了一个 API 命令 POST /command/stop_plan，允许停止计划。

还可以通过 GUI 或 API POST /scheduled_jobs/environment_jobs 在 orchestrator 中调度作业，但需要特别小心，注意使用调度器时的系统负载。由于 orchestrator 无法水平扩展，且任务和计划的队列系统可能会被某些类型的请求轻易阻塞，因此需要特别注意其扩展性限制。

配置性能设置

本节中讨论的设置都可以在 Puppet Enterprise orchestrator 基础设施节点组中配置，通过 Web 控制台或以代码形式在 Hiera 中进行配置。

orchestrator 可以同时运行最多数量的任务；这个最大并发任务数通过 puppet_enterprise::profile::orchestrator::task_concurrency 参数配置（默认值：250），以及 puppet_enterprise::profile::bolt_server::concurrency（默认值：100）和 puppet_enterprise::profile::ace_server::concurrency（默认值：100）一起配置，直接限制 Ace 和 Bolt（它们的数量不应大于 orchestrator::task_concurrency 总数）。它们的大小主要受到 orchestrator 内存的限制，orchestrator 会为你添加的每个实例容量保留大约 ± 1 MB 的 RAM。任务会按照接收到的顺序处理，直到完成；这意味着长时间运行的任务和目标数较多的任务可能会阻塞其他任务的运行并垄断资源。以运行任务需要 10 分钟来完成 1,000 个服务器为例，这将导致任务使用 250 的队列容量四次，执行任务的总时间为 40 分钟，在此期间，所有其他任务需要排队直到完成。强烈建议任务的执行时间不超过 5 分钟，并且需要精心管理任务，分批运行。同时需要注意，任务队列没有限制，并且有可能触及 puppet_enterprise::profile::orchestrator::allowed_pcp_status_requests 参数。理解这一点很重要，这并不意味着任务失败，而是 orchestrator 无法在超时时间内获取任务状态。任务本身可能在此之后已完成。

对于计划，orchestrator 与 Puppet Server 类似，需要 JRuby 实例来编译计划。这个容量由 puppet_enterprise::profile::orchestrator::jruby_max_active_instances 设置，JVM 的堆内存通过 puppet_enterprise::profile::orchestrator::java_args 设置。

在讨论了 Puppet Enterprise 的核心组件和服务后，我们将进一步探讨如何使用自动化工具部署这些组件，并部署到 Puppet 推荐的参考架构上，以确保基础设施能够根据用户需求进行扩展。

自动化部署与参考架构

Puppet Enterprise 专注于创建标准架构和配置以及自动化部署它们。这确保了 Puppet Enterprise 客户能够找到合适的标准架构和模式，并使用提供的工具进行部署，从而减少了设计工作的量。

理解支持的架构

Puppet 为 Puppet Enterprise 提供了三种支持的架构，如下所示：

• 标准安装仅为一个独立的主服务器，并支持最多 2,500 个客户端。

• 大型安装是一个主服务器，后面有编译服务器，通过负载均衡器连接，支持最多 20,000 个客户端。

• 超大型安装包括一个主服务器，一个单独的 PuppetDB 服务器，以及通过负载均衡器连接的编译服务器，支持超过 20,000 个服务器。

以下是通过图示说明：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_05.jpg

图 14.5 – 标准架构

标准架构受到主服务器能为多少客户端运行目录的限制，最多支持 2,500 个节点。超过此数量后，大型架构允许通过编译节点进行横向扩展，但也面临单个主服务器无法承载所有服务负载的限制。因此，在 25,000 个节点时，超大型架构建议将 PuppetDB 作为最重的服务之一分离到单独的服务器上。

在所有这些架构中，可以通过名为灾难恢复（DR）的方法，为主服务器和单独的 PostgreSQL 服务器提供副本服务器。如果主服务器或 PostgreSQL 服务器发生故障，灾难恢复可以执行故障转移操作并恢复服务，预期会丢失部分服务，以下是服务的详细表格：

服务名称	复制类型	故障转移方法
Puppet 服务器	无	主动 / 主动
控制台服务 UI	无	直到手动提升前为只读
ACE 服务	无	直到手动提升前为只读
Bolt 服务	无	直到手动提升前为只读
CA	单向复制	直到手动提升前为只读
RBAC	单向复制	直到手动提升前为只读
分类器	单向复制	直到手动提升前为只读
活动	单向复制	直到手动提升前为只读
编排	单向复制	直到手动提升前为只读
文件同步	单向复制	直到手动提升前为只读
PuppetDB	双向	主动 – 主动

表 14.1 – 服务复制和灾难恢复方法

PuppetDB 在 Puppet Enterprise 中的同步机制是独特的；它在主服务器和副本之间执行读写同步，这也是它在前述列表中唯一可以同步并在提升时可用的服务。其他使用 PostgreSQL 的服务依赖于从主服务器到副本的PGLogical同步，使得副本上的数据为只读。

从这个列表可以看出，在主服务器故障时，副本将只能接管并编译已经注册的服务器的目录、来自 PuppetDB 的查询和报告，以及通过 API 进行的节点分类查询。这意味着无法注册或删除新服务器，无法部署新代码，无法使用网页控制台，无法更改分类，并且大部分 CLI 工具将无法使用，直到通过在副本上执行 puppet infrastructure promote replica 命令进行手动提升操作。

这是一个不可逆的操作，原始的故障主服务器必须重新部署为副本才能再次使用。因此，对于许多试图修复原始主服务器的用户来说，这比通过 DR 过程更省时。

DR 不应与 高可用性 (HA) 混淆，后者是在服务器丢失的情况下预期的连续服务，而这在当前任何 Puppet 架构中都是不可能的。

注意

使用 DR 时，peadm 确保编译器被拆分并配置为两组，PuppetDB 请求在 PuppetDB 副本的两边分发，以最大化容量。如果选择不使用 pecdm，请确保遵循此优化，可在 github.com/puppetlabs/puppetlabs-peadm/blob/main/manifests/setup/node_manager.pp 中查看代码，A 和 B 组设置数据库的参数。

Puppet 架构还定义了一套跨公共云和私有云区域部署的多区域模式，其中区域由云服务提供商定义为具有区域性低延迟连接的数据中心。完整的细节请参见 puppet.com/docs/patterns-and-tactics/latest/reference-architectures/pe-multi-region-reference-architectures.html。最佳实践要求编译器具有低延迟连接，因此最好将它们部署在与主服务器和副本服务器相同的区域；同样，主服务器和副本之间的连接必须是低延迟的。因此，最佳做法是使用集中式部署，其中所有 Puppet 基础设施都位于一个所有区域都可以通信的管理区域，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_06.jpg

图 14.6 – 集中式和联合式部署

另外，也可以使用联合模型，在每个区域部署 Puppet 基础设施，缺点是没有一个控制台能够查看整个系统。

讨论了架构和模式之后，接下来是查看可用于部署这些模式的工具。

部署与配置

Puppet 通过多个层次自动化其服务器基础设施的部署。第一层使用 Puppet Enterprise 安装程序，这是一个从 Puppet 下载的 tarball 文件，其中包含所有必要的软件包和脚本来安装 Puppet Enterprise。下载到目标服务器并解压后，可以通过运行./puppet-enterprise-installer来完成基本安装。可以通过创建-c标志并指向其位置，按照puppet.com/docs/pe/2021.7/installing_pe.html上的指导添加自定义配置。一旦 Puppet 服务器配置完成，就可以使用安装脚本自动添加代理；Unix 系统使用 Bash 脚本，Windows 使用 PowerShell 脚本，这些脚本托管在主文件服务器上，确保正确的代理包被安装：

uri='https://<PRIMARY_HOST>:8140/packages/current/install.bash' curl --insecure "$uri" | sudo bash -s -- --puppet-service-ensure stopped agent:environment=production
[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $webClient = New-Object System.Net.WebClient; $webClient.DownloadFile('https://<PRIMARY_HOST>:8140/packages/current/install.ps1', 'install.ps1'); .\install.ps1 -PuppetServiceEnsure stopped agent:environment=production

在这个示例中，选项将environment设置为production，并确保服务未运行。完整的选项范围可用并记录在puppet.com/docs/pe/2021.7/installing_agents.html。

这个install脚本仅安装了主服务器，且需要进一步的手动步骤才能根据我们想要的架构添加编译器和副本。为了部署下一个层级，除了直接使用 Enterprise 安装程序外，我们使用peadm模块（forge.puppet.com/modules/puppetlabs/peadm），这是一个受支持的 Puppet 模块，提供了一种自动化方式来运行 Puppet Enterprise 安装脚本，并自动将其配置为支持的架构之一。此模块假设所请求的配置所需的基础设施已准备好，并且可以进一步提升，使用pecdm模块（github.com/puppetlabs/puppetlabs-pecdm）在公共云环境中自动进行配置。关于这些模块的使用示例已在第十二章中详细讨论，并且是我们在本书中部署实验室时一直使用的方法。

peadm模块本身不仅仅是一个简单的部署工具，它还具有显示服务器状态的计划和任务，并允许通过其任务和计划执行版本升级。

Puppet Enterprise 将安装在Enterprise文件夹中的模块与通过分类器或 Hiera 数据配置的模块结合，并与其他文件位置一起放置自定义配置。控制台有许多可以配置的项，这些项可以通过 Web 控制台中的分类或通过 Hiera 设置，例如，通过puppet_enterprise::profile::console::rbac_failed_attempts_lockout设置的失败登录尝试次数和通过puppet_enterprise::profile::console::password_minimum_length设置的密码复杂性规则，如最小密码长度。可以在puppet.com/docs/pe/2021.7/config_console.html#configure_the_pe_console_and_console_services中找到完整的控制台自定义配置列表。

此外，可以通过将文件放置在puppet_enterprise::profile::console::disclaimer_content_path指定的路径中，来为控制台放置文件，默认路径为/etc/puppetlabs/console-services。你可以创建一个登录控制台时显示的消息，例如贵组织可能需要的法律警告。

此外，在控制台中，还可以基于 PQL 搜索节点，并可以选择预定义的 PQL 示例。你可以通过简单地将文件放置在/etc/puppetlabs/console-services/custom_pql_queries.json来将自己的 PQL 示例添加到 Web 控制台，使用/etc/puppetlabs/console-services/custom_pql_queries.json.example作为模板。Web 控制台本身默认使用自签名 CA 证书，可以通过将生成的证书放置在/etc/puppetlabs/puppet/ssl/certs/console-cert.pem和/etc/puppetlabs/puppet/ssl/private_keys/console-cert.pem来替换为由贵组织 CA 系统签名的证书。另一个需要考虑的关键文件是许可证密钥，该密钥由 Puppet 颁发，并放置在/etc/puppetlabs/license.key，权限为644 root:root。你可以在 Web 控制台的License选项卡下查看许可证的详细信息。对于这些更改，应该执行一次 Puppet 代理运行，并重启控制台服务。

Puppet Enterprise 的某些领域当前无法通过原生代码进行定义，如 RBAC、分类和 LDAP，但有些 API 和 Puppet 模块可以利用这些 API，从而支持配置存储。对于分类，有一个 API 可以查看分类并配置节点组；这也可以通过node_manager模块实现（forge.puppet.com/modules/WhatsARanjit/node_manager），该模块由 peadm 使用。对于 RBAC 和 LDAP，RBAC API（puppet.com/docs/pe/2021.7/rbac-api.htm）提供了可用于管理组、角色和用户的端点。已开发了一个 Puppet 模块来使用这些 API（forge.puppet.com/modules/pltraining/rbac），并且它有一个 LDAP 端点，同样开发了一个模块来使用这些 API（forge.puppet.com/modules/abuxton/puppet_ds）。

)

在审查完架构和部署建议之后，我们将在下一部分讨论与 Puppet 一起使用的其他支持工具和产品。

Puppet Enterprise 相关项目和工具

Puppet Enterprise 拥有由 Puppet 开发的多个模块和工具，以简化 Puppet 基础设施的管理和支持。最直接的工具是内置的支持脚本；该命令会收集日志和系统信息并进行压缩，从而允许用户将详细的状态信息发送到 Puppet 支持团队的案例中。该命令的简单版本如下：/opt/puppetlabs/bin/puppet enterprise support。

详细的选项可以在文档中找到：puppet.com/docs/pe/2021.7/getting_support_for_pe.html#pe_support_script，这些选项允许选择要收集的服务，将归档文件作为命令的一部分直接安全文件传输协议(SFTP)上传，并在有GNU 隐私保护(GPG)密钥的情况下加密归档文件。

注意

可以使用SOScleaner从支持脚本内容中删除主机名和 IP 地址。有关如何安装和运行它的详细信息，请访问 support.puppet.com/hc/en-us/articles/115003312887。

在了解了如何部署 Puppet 基础设施之后，了解如何监控和排除发现的任何问题也很重要，因此我们接下来将讨论这个内容。

监控和故障排除 Puppet Enterprise 基础设施

Puppet Enterprise 状态检查模块 (forge.puppet.com/modules/puppetlabs/pe_status_check) 会根据支持案例中常见的问题，检查 Puppet 基础设施服务器和 Puppet 代理的状态，例如确认服务是否正在运行、磁盘空间是否充足以及证书是否即将过期。这些检查可以作为任务运行，Puppet 代码会将问题通知到报告中，或者作为事实——在 第十三章 中显示的 Splunk 插件有一个仪表板用于显示事实输出。使用这些检查意味着如果您在向 Puppet 提交支持案例时遇到问题，您可以引用检查编号。

support_tasks 模块 (forge.puppet.com/modules/puppetlabs/support_tasks/tasks) 提供了执行知识库文章中列出的操作的任务，例如重新生成证书、运行支持脚本和打印 Puppet 数据库表大小。

可以配置一些额外的控制台视图，使其在控制台中可见并可用；值报告只需在 值报告 标签页中输入使用任务、计划、纠正性更改和有意更改时可以回收的时间，系统还会生成统计数据。

Puppet Enterprise 可以收集有关软件包的更多信息，包括未管理的软件包；这些信息会在 puppet_enterprise::profile::agent 类中显示，供您希望从中收集信息的节点组使用，并通过将 package_inventory_enabled 参数设置为 true 来启用此功能。

最终可以启用的额外功能是补丁管理和监控，在 pe_patch 类中进行。

除了核心的 Puppet Enterprise 基础设施，还有其他 Puppet 产品可以管理代码部署管道，将代码部署到 Puppet Enterprise 并在 Puppet 节点上执行合规扫描。

管理部署并确保合规性

有两个额外的 Puppet 产品可以与 Puppet Enterprise 一起使用，v4 目录 API 用于编译新代码的目录，并将其与当前代码的目录进行比较，显示差异，以确保影响符合开发人员预期。这些管道可以在 CD4PE 的 Web 控制台中创建，也可以作为代码通过 YAML 文件插入到模块和控制库中进行部署。

Puppet Comply 是一个基于互联网安全中心（CIS）基准的合规性工具。它围绕 CIS 开发的 Java 扫描器、CIS-CAT Pro 访问器（www.cisecurity.org/cybersecurity-tools/cis-cat-pro）构建自动化。这使得可以通过 Puppet Enterprise 中的调度器自动访问主机，并通过任务自动化和安排扫描器运行，从而生成其合规性的仪表板，并在单独的 Puppet Comply 控制台中查看。以下截图展示了 Comply 的主页屏幕：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_14_07.jpg

图 14.7 – Puppet Comply 首页仪表板

从仪表板可以看到有多少节点已达到合规性，多少节点设置了合规性配置文件，以及节点结果的列表，列出了在特定扫描中分配的配置文件和合规性得分。

它还提供了高级版的cem_linux（forge.puppet.com/modules/puppetlabs/cem_linux）和cem_windows（forge.puppet.com/modules/puppetlabs/cem_windows），以加快 Puppet 的采用，允许基于 CIS 基准通过预制的 Puppet 模块进行基础安全配置。这些模块由 Puppet 维护和支持，确保执行代码与最新的 CIS 基准保持一致。

这两个产品运行在被称为Puppet 应用管理器（PAM）的框架中，这是一个基于 Kubernetes 的工具，用于管理 Puppet 应用程序。

实验室 – Puppet Enterprise 扩展和配置

在技术要求部分执行 bolt 命令，将部署一个大型的 Puppet Enterprise 2021.5。通过这个基础设施设置，我们将尝试进行我们已讨论的各种扩展和配置，具体如下：

1. 检查 peadm 中的代码和设置 A 和 B 组的节点组。请注意，github.com/puppetlabs/puppetlabs-peadm/blob/main/documentation/classification.md 提供了组的解释。

2. 创建一个个人用户，授予其查看控制台、创建节点组以及查看管理员用户活动日志的权限（尝试在没有查看控制台权限的情况下登录）。

3. 启用所有节点在 Web 控制台上的包管理功能，作为个人用户登录，并查看此操作的活动日志。

4. 通过使用node_manager模块应用代码，为节点启用补丁管理。

5. 自定义登录信息。

6. 使用 peadm 升级计划执行升级至 2021.6 版本。注意：由于 pecdm 包含 peadm，因此可以从开发环境中执行此操作。

示例解决方案可在 github.com/PacktPublishing/Puppet-8-for-DevOps-Engineers/tree/main/ch14 获取。

总结

本章回顾了 Puppet Enterprise 如何在开源工具的基础上构建，提供了确保安全和自动化部署 Puppet 所需的服务。讨论了 Puppet Enterprise 如何将开源软件包打包成一致的版本，并通过 Puppet 架构和服务团队提供支持服务。

我们还讨论了 Puppet Enterprise 的附加服务，通过 RBAC 安全地保护用户和 API 访问，提供了 Web 前端和附加 API，在控制台服务中可以通过 Code Manager 部署代码。

然后介绍了 Puppet Orchestrator，展示了如何在 Puppet Enterprise 中通过 Orchestrator 服务运行任务和计划，使用 PCP 通过 PXP 中介传输 PXP 代理与节点之间的通信。无代理客户端可以被添加到库存服务中，存储它们的传输详情，任务或计划将在 Bolt 服务器上运行，适用于通过 WinRM 或 SSH 连接的节点，而其他网络设备（如交换机或防火墙）则使用 ACE 服务器。我们看到 Orchestrator 如何存储所有作业的细节，并更新活动服务。讨论了 RBAC 访问控制，展示了如何限制哪些计划可供用户使用，同时可以将任务分配给特定用户和特定节点组，使用目标集。还讨论了 Orchestrator 的性能和容量方面的问题，以及如何通过 Web 控制台 GUI 或 CLI 接口运行任务或计划。

回顾了客户可以立即使用的支持架构，以便大规模实现 Puppet 以及满足其区域需求，展示了这些架构的模块和脚本，这些模块和脚本封装起来可以自动部署这些架构，pecdm 模块用于在公共云中部署基础设施，peadm 用于自动化安装和维护的各个步骤，并使用安装脚本。

介绍了可以在 Web 控制台中启用的附加服务，帮助报告 Puppet 提供的价值、补丁管理和打包报告，以及定制化和自动化配置控制台的方法，包括控制台消息的定制、Web 控制台上使用的证书和许可证密钥。随后讨论了几个模块，它们可以帮助报告基础设施状态，并在 support_task 和 status_check 模块中运行标准任务。

随后讨论了两个与 Puppet Enterprise 集成的 Puppet 产品：CD4PE，它提供了一个管道帮助自动化部署代码，以及 Puppet Comply，它提供了预写的模块和仪表板，用于报告 CIS 基准。

虽然所有的架构、工具、打包和一般自动化都可以通过开源 Puppet 实现，但这需要依靠你们团队的开发和支持工作。因此，Puppet Enterprise 应该被视为一个关于团队可用技能、组织已经投资的工具以及可用于工具的资金的决策，同时也考虑到你们组织希望集中精力在哪些工作上的问题。

现在，在全面审查了语言、平台以及 Puppet Enterprise 如何提供预配置的基础设施以减少操作负担和设计要求后，在最后一章中，我们将讨论采用和使用 Puppet 的方法，重点是如何在你的组织中获得最佳应用，因为理解技术只是战斗的一部分，而理解如何与人和流程整合通常是更大的挑战。

第十五章：采用方法

在详细讨论了 Puppet 语言和平台之后，本章将关注采用和实施方法。本章假设 Puppet 的最可能采用者及其观点。因此，这些建议从 Puppet 平台团队的角度出发，但它也会讨论如何让从应用程序到操作系统的所有实施团队共同合作，推动采用。

很多时候，项目或现代化计划的观点是认为仅靠技术就能解决组织的所有问题，而现有的团队和流程只是障碍，必须绕过它们才能交付未来。最成功的采用案例与现有团队合作，并将其嵌入到他们的流程中。本章将通过讨论如何选择正确的范围和焦点来确保实施能够实现其目标，定期交付并展示价值以促进采用，从而覆盖这一点。我们将讨论如何与其他团队和利益相关者合作，确保 Puppet 作为一项技术不是一个争夺空间的孤岛，而是一个可以集成并最大化效益的平台。虽然从头开始部署新服务器通常更为实际，但我们将讨论如何安全、渐进地接触遗产的老旧环境，在这里了解配置漂移的程度并开发自动化来纠正这些漂移，可以在减少昂贵的审计过程方面带来巨大的好处。我们还将详细讨论在受监管环境中使用 Puppet，因为通常认为一个经常进行更改并拥有较高权限的工具根本无法使用。我们将看到如何展示流程和测试，不仅使 Puppet 安全可靠，还能证明它是强制执行任何受监管环境要求的核心部分。最后，我们将看到 Puppet 如何融入云端、其适当的使用场景，以及如何避免公共云迁移中的错误，并不丢失 Puppet 在私有数据中心带来的效益。

在本章中，我们将涵盖以下主要主题：

• 范围和焦点

• 平台工程方法

• 管理遗产遗产的无操作模式

• 受监管环境中的采用

• 向云迁移

范围和焦点

范围和关注度的压力将取决于你的组织为什么开始使用 Puppet。如果这是一个单独团队的自动化部署练习，比如 Oracle 团队，压力将比一个购买了大规模 Puppet Enterprise 合同的转型项目小。在大型转型项目中，可能会有诱惑去快速实现大目标，以便尽快回收成本。这是危险的，因为配置问题是复杂的，技术人员往往过于乐观地认为解决方案能很快创建出来。额外的压力可能来自销售团队和决策者，他们可能夸大了变革能多快实施，从而获得必要的资金。这并不是反对有愿景或类似吉姆·柯林斯（Jim Collins）那样的宏大目标。未来的愿景是需要的，但必须表明这将是一个渐进的改善过程，而这些渐进的步骤将带来即时且持续的价值。这将建立来自支持团队和客户的信任和信心，促使他们投资你的平台，因为你可靠地交付的是一些切实可行的成果，而不仅仅是一个遥远的希望。

最佳的交付方法是遵循良好的迭代实践，设定一些大的目标（epics），例如交付核心操作系统角色或 Oracle 角色，这些目标可以拆分成每个迭代的小目标，每个任务应该足够小，能够在正常的迭代周期内完成，通常是两周。每次迭代结束时，这些功能可以展示给利益相关者，以展示进展、收益并获得反馈。

注意

本书并不主张任何特定的敏捷方法论；有大量的书籍和建议教你如何实施敏捷工作实践。适合你组织的做法将取决于当地文化和你的团队。因此，本书的建议是研究各种方法，但要保持灵活，找到适合自己团队且有效的做法，而不是盲目模仿他人的系统。使用如迭代回顾（retrospectives）等技巧，能够确保你的工作方式仍然有效，并且对问题采取相应的行动。

如果忽视这种方法，团队被分散在多个目标之间，就容易导致开发人员各自为战。当开发人员孤立工作时，其他团队成员无法提供帮助或进行有意义的评审，因为他们对工作内容或决策原因没有了解。

如果工作过于庞大和复杂，就会导致开发问题，难以测试并拆解理解。这可能导致管理层和开发人员之间的沮丧，因为交付上没有任何可见的进展。为了交付某些东西的压力可能导致开发人员的疲惫，加上审查和测试大型复杂工作中的困难，可能会导致交付一个有风险或不完整的产物，仅仅是为了交付。这会在一个恶性循环中侵蚀信心和士气，压力和待解决问题不断增加。

在 受管控环境中的采纳 部分，我们将讨论在你的流程和平台中展示可靠的测试和交付能力，以获得变更和风险团队的信任有多么关键。

经过上述警告，如果团队确实坚持专注和范围的界定，那么团队之间就可以建立对持续开发工作的理解，并强化审查、测试和学习过程。这为开发人员提供了在有趣或具有挑战性的工作部分进行配对的机会，并利用团队分组会议共同做出编码方法的决策。如第一章所讨论的，保持更新关于 Puppet 最佳实践文档中的这些决策，有助于进一步传播知识。最重要的是，在提交代码的审查中，这变成了团队积极讨论和共同工作的成果，而不仅仅是一些在简短的早会更新中听到的内容，也不是团队仅仅依赖开发人员口头描述的内容。所有这些都帮助团队更好地理解代码的预期功能以及为何选择这种方法。

为了说明这种方法，通常基础操作系统需要为核心构建设置一个安全配置文件。这个安全配置文件将包含诸如核心操作系统用户账户、SSH 配置、内核设置以及其他各种重要设置等内容。将这个配置文件作为一个冲刺的焦点，可能会导致开发人员配对并共同处理构成该配置文件的组件模块。开发人员专注于诸如用户账户等元素，并一块一块地构建配置文件，这样就能取得实际进展并分享知识。根据配置文件的大小和开发人员的数量，可能更有意义去处理多个配置文件，但目标仍然是要限制范围并聚焦。

这并不是说任何开发团队应该期待一切按自己的方式进行，并且外部压力不会导致焦点分散，但必须明确表示，这会减慢工作进度并带来风险。

在理解 Puppet 代码的重点和范围之后，下一个需要了解的关键点是代码交付到生产环境的最低验收标准。最小可行产品（MVP）这一术语已被误用，成为发布明显不适合生产的内容的借口，通常会表示后续添加测试等项目。事实上，这种情况是不可能发生的，因为总有新的功能需要开发，随着代码的进一步发展，未来会带来更大的运营负担。因此，在你的组织和平台中，Puppet 的最佳实践应该明确代码需要通过哪些测试。一个示例标准可能包含以下内容：

• 代码必须在 PDK 验证中保持干净，并接受已列出的例外

• RSpec 测试提供 100%的代码覆盖

• ServerSpec 测试该模块，并通过核心的 ServerSpec 测试

另一个挑战可能是范围蔓延，这会稀释 Puppet 在组织中使用的更高层次的范围和重点。当投资于一个工具时，很容易通过扩展用例来最大化投资回报率，随着实施的成功，其他团队也会希望加入这一成功，尝试使用提供的工具。因此，需要明确 Puppet 的使用场景；不恰当的使用，如分发二进制文件或大规模同步文件，需要在平台文档中明确指出是不可取的。在这个例子中，这会对基础设施造成很大负担，正如本书所讨论的那样。此外，在聚焦方面，本书强烈建议反对任何鼓励强制重写/重新平台化策略的政策，除非当前的实现存在维护问题或无法按需开发。这种重写几乎没有价值，除非原始实现被充分理解，否则可能导致翻译中的错误，特别是对于声明性代码，因为只有方法是可见的，而最终状态不可见。

在讨论了 Puppet 的范围和重点后，我们现在来看一下如何在传统服务器上管理这种方法，并处理历史遗留问题以及棕地站点的复杂性。

管理无操作模式的遗留资产

遗留系统的实现可能更具挑战性；配置漂移的程度可能使得难以知道从哪里开始。你的组织可能经历了多次并购，这不仅导致了核心组织本身的多个配置标准，也包括了所有接入的系统。

一个常见的采用模式是逐步在传统服务器中建立自动化水平，以建立信心，我们将详细介绍一种常见的方法。

在所有节点上安装代理以收集事实是一个常见的起点，并将这些数据存储在 PuppetDB 中，形成有价值的 CMDB 数据源。然后，如第十三章所讨论的，这些数据可以发送到诸如 ServiceNow 之类的服务，以与中央 CMDB 服务进行集成。在 Puppet Enterprise 中，这让我们可以访问包视图，并具有管理补丁的能力，如第十四章中演示的那样。这个推广立即提供了能力，并且对整个环境有了更好的理解，甚至没有编写任何代码。

下一步是考虑编排。很可能在传统环境中，各个团队手动或半自动地执行了常见的脚本和任务。将这些脚本封装为 Bolt 项目或 Puppet 模块，并使用 Bolt 或 Orchestrator 来运行这些脚本和任务，可以在不需要重新工作的情况下提供更大的控制和流程。

最简单的情况是，如果你正在使用 Puppet Enterprise，并且在第一步中已经部署了代理，那么 Orchestrator 可以直接利用代理的存在，使用 PCP 传输进行通信，并利用 Puppet Enterprise 的 RBAC 和日志系统与 Orchestrator 协同工作。对于不想为传统版本购买许可证的开源 Puppet 或 Puppet Enterprise 用户，可以使用 Bolt 服务器设置带有 SSH 密钥和 WinRM 的黄金主机。有一种折衷方案是使用无代理的 Puppet Enterprise 许可证，但允许使用 Puppet Enterprise 主机，并仍然拥有 RBAC 和访问日志。虽然在前面的章节中没有讨论过，但基于代理的服务器的优点是它们更加集成，能够执行更多操作并收集更多数据，且它们对密钥和安全的管理是由 Puppet 作为产品的一部分来管理的。无代理方法可以在不需要请求安装代理的情况下添加，这可能不适用于所有服务器。无代理方法还避免了 Puppet 代理代码版本的潜在漏洞和更新问题，但确实存在单独的访问管理问题，例如 SSH 密钥的部署和管理。

下一步正是范围和焦点部分讨论的内容：查看基线配置，并理想情况下找到一些非谈判性的起点，这些必须在你的资产上强制执行。例如，必须关闭 root 登录，或者应用程序代理需要升级并管理版本，以避免漏洞。一旦这些简单的配置得到管理，就该查看可能有历史例外的服务器配置。对于遗留服务器而言，即使服务器的预设配置不符合当前的安全和构建标准，也应首先将其标记为问题，然后再进行修复，以避免可能导致服务问题。在没有立即修复的情况下标记配置问题，可以使用在配置文件或模块级别上的无操作标记模式，正如在第八章中讨论的那样。配置漂移可以被理解为是可以接受的例外（记录在 Hiera 数据中），或者通过将模式从无操作模式切换到执行模式来使用 Puppet 进行修复，以应用配置。

一旦基础配置文件完成，就意味着我们在遗留资产中拥有了所有可用的工具，用于自动化审计报告和合规修复。

然后，可以通过与应用程序团队互动，了解他们的配置和审计需求，并按照相同的模式为其应用程序构建自己的角色和配置文件，从而重复这一方法。

提到涉及开发 Puppet 代码的不同团队时，重要的是直接讨论跨团队协作的最佳方法。

一个平台工程方法

正如本章前两部分所明确的，Puppet 的常见采用起点是创建核心基础操作系统配置，然后再与应用程序团队进行接触。这往往会导致一个设置，即 Puppet 成为 Linux/Unix 操作系统团队的工具，这个团队主导着代码库，并且是整个平台的守门人。为了确保有效的跨团队协作，所需的是一种平台工程方法。

注意

关于如何运行平台团队的更深入知识，可以通过书籍和培训获得，例如 teamtopologies.com/，而平台工程通过 platformengineering.org/ 等社区得到了普及。

平台工程的核心概念是拥有一个平台团队，负责管理工具、工作流以及自服务平台的开发。这个平台应该被视为一个产品，用户被视为客户，确保他们的需求得到满足，并在整个组织中推广该平台。正如在第一章中讨论的，Puppet 可能会成为平台的一部分，与其他各种 DevOps 工具和工作流一起使用。图 15.1展示了一个常见的工具集选择：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_15_01.jpg

图 15.1 – 常见的 DevOps 工具集

精确地看 Puppet 将如何适配，这很可能是在第 0 天、第 1 天和第 2 天的方法中，如图 15.2所示。在第 0 天，通过类似 Terraform 的专业工具进行基础设施的配置。接着，在第 1 天，Puppet 代码将被应用于客户端，以便根据基础设施上的操作系统构建和安全标准进行配置。第 2 天，Puppet 的作用将是继续执行配置，以防止配置漂移，避免因外部意外变化或标准的有意更改而导致的代码变动。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ppt8-dop-engi/img/B18492_15_02.jpg

图 15.2 – 第 0 天、第 1 天和第 2 天的做法

思考 Puppet 代码在这些平台中的关键点是，理想情况下，运行 Puppet 基础设施的责任应该是平台团队的角色之一。这使得各个团队可以开发自己的代码和角色，并通过自服务平台有清晰的部署路径。

这并非总是可能的，通常情况下，Linux 团队仍然需要同时运行他们自己的代码库和 Puppet 基础设施。在这种情况下，最好将其视为两个独立的角色，而不是仅仅优先考虑 Linux 团队的代码库需求，忽略其他使用者的需求。平台团队不应尝试成为所有人 Puppet 代码的把关人，因为这会阻止开发人员将 Puppet 作为自服务平台来使用。你们组织的流程应该涵盖责任和升级机制，下一节将进一步讨论，受监管环境中的采纳。

还应该确保负责管理遗留资产的团队承担自动化工作的责任。没有充分了解系统的新团队来自动化它们可能会面临挑战。虽然可能需要更多的时间来培训并让遗留团队参与其中，但让他们主导集成工作，可以帮助更全面地理解系统及其流程。

虽然每个团队负责自己的代码，但合作开发标准和最佳实践仍然很重要，以确保团队具备适当测试和构建工具管道的知识。

跨团队协作不仅仅限于使用 Puppet，还包括其他集成点。在 Puppet 中重写和运行所有内容既不实际也不可取。创建实践社区，让跨部门的各个团队可以见面、讨论并展示他们在自动化方面的思路和进展，能够促进思想的交流。在某些情况下，甚至可以复用其他团队在组织内已经开发的成果。这不应被视为一种竞争，而是相互受益和交流技能与想法的机会。

各个层级的宣传至关重要。参加各种团队会议、午餐会、管理层会议以及外部供应商或行业组织的活动，可以帮助传播关于你平台的消息，并为进一步的发展激发热情。外部供应商活动通常被视为法律复杂，但通过仔细考虑并与法律和营销团队咨询，你可以在组织内部提升平台的知名度，并通过激发对你工作兴趣来吸引外部人才。此外，这些外部活动，如技术顾问委员会，是与志同道合的组织交流最佳实践的绝佳机会。

虽然在范围与重点部分已提到过，但值得强调的是，不要试图解决所有被带给你的问题。如果你能够很好地宣传，大家会变得非常热情，但必须完全诚实地说明你平台的能力和适配性。你应该清楚地传达你能够实际交付的内容，以及如果他们希望参与或接触 Puppet 平台，必须承诺什么。

确定了范围和重点，并理解了协作工作方式后，接下来的重要思考应围绕监管和流程如何影响这些工作方式展开。

在受监管环境中的采用

在高度受监管的环境中工作可能具有挑战性，但这通常是 Puppet 能发挥最大影响的地方。在受监管的环境中实施自动化可能更困难，但执行大规模手动操作则更加具有挑战性，因此潜在的投资回报显著。采用新技术时，最糟糕的做法就是相信“流程只需要改变”。这种态度会导致团队在后期失败，并且可能会造成懒散和忽视流程工作的声誉，最终导致无法在生产环境中正常运行的设置。

最好的做法是在实施 Puppet 之前，先与变革、风险、审计和其他涉及管理流程的团队进行接触。尽管组织中经常抱怨流程问题，但通常没有人去与这些团队互动，而这些团队可能有自己的现代化计划，你可以将你的实施计划与之对接。讨论 Puppet 是什么以及你计划如何在生产环境中使用它，可以提供可信的反馈。即使这些反馈需要缩小你最初的雄心壮志，它也比将这些团队视为守门人要好，因为守门人往往对你的实施缺乏理解，只会拒绝他们未能理解后果或未曾参与的方法。

注意

邀请你的流程团队参加实践社区会议和演示；你们并不站在对立面，反而会发现，在为组织提供价值的过程中，你们有更多的挑战和目标是共同的。

重要的是要围绕 Puppet 能够做什么以及你的开发、测试和发布方法如何运作进行讨论，还要明确其覆盖的范围。Puppet 是一个强大的工具，操作在管理/根级别，因此必须展示你对流程的掌控力，并且理解与这些流程相关的任何风险。

为了赢得所有相关方的信任，包括流程团队，你可以向他们展示 Puppet 的可能性，并讨论它如何为组织带来益处。正如在聚焦与范围一节中讨论的那样，可以通过持续改进流程，特别是通过实践社区讨论，来实现这一点。通过这种方式，多个团队和部门可以就有益于组织的改进达成一致，而不会妥协于安全性和风险。

这种方法看起来可能并不具有革命性，但在受监管的环境中，变革无法快速发生。因此，重要的是要关注在当前限制条件下可以做的事情，展示你的解决方案如何适应这些条件，并与相关方合作来现代化或改进流程。这需要耐心和一致性来赢得团队的支持。在完成对传统私有数据中心环境的视角后，考虑这种方法在云端的不同之处也是非常重要的。

向云迁移

向公共云迁移带来了巨大的机会，尤其是在灵活性方面，提供了使用云特定技术来减少组织运营负担的机会。例如，利用可用区来减少数据中心故障风险，虽然是一个复杂的功能，但在私有数据中心中实现起来非常困难。

不幸的是，云采用方法中有两种常见的反模式。第一个是将所有基础设施、流程和组件完全复制到公共云中，就像它们在私有数据中心中一样工作。这种情况通常发生在“云优先”计划中，这往往是首席信息官（CIOs）对公共云资源采用的失望结果。这迫使在组织准备好并理解适合的情况下将部署推入公共云。这导致了意外的账单，因为部署的基础设施并未计划为灵活，并忽略了公共云的租赁性质，而且许多在私有数据中心中有效的解决方案在公共云中的云原生解决方案中实现得更好。

第二种反模式是把一切都抛在脑后，这在那些对内部流程和交付时间感到沮丧的应用团队或部门中可以看到。他们可能有理由感到沮丧，但很少有经验；可悲的是，在私有数据中心中艰难取得的经验教训被遗忘，审计、配置和测试中的最佳实践必须重新建立，因为审计员发现新设置中存在问题。

你应该考虑在公共云中真正执行的内容；当查看如何部署 Puppet 基础设施时，第十三章中提到的多区域模式和策略展示了选择。简单来说，我们可以在私有数据中心通过 Puppet 基础设施管理公共云服务器，或者将 Puppet 基础设施迁移到公共云并管理私有数据中心和公共云，或者为私有数据中心和公共云分别设置独立的 Puppet 基础设施。

这个选择取决于实施目标。例如，公共云是否将用于为私有数据中心提供灵活的容量，例如通过提供一个可以在灾难恢复中构建的备用站点？或者，公共云是否用于开始一种新的工作方式，采用更具云原生的方法和新团队？在第一种情况下，你更有可能希望服务器的配置与共享代码库保持一致，并且拥有一个单一的管理界面对团队管理基础设施可能会有帮助。在这种情况下，决定基础设施是应该私有化还是公共化将归结为成本问题，以及你是否打算利用云原生功能，如可用性集和负载均衡器的灵活性，这些功能可以按需添加编译器。

在第二种情况中，当新团队开始寻找新的方法时，拥有独立的基础设施将最为合理，回顾当前构建中哪些是有用的，哪些仅与私有数据中心相关。如在平台工程方法部分所述，这涉及到了解在云中工作的团队的需求，并确保 Puppet 作为平台的一部分来满足这些需求。云团队随后应该能够使用 API 进行自助服务，同时享受 Puppet 提供的审计和安全性要求，以符合组织在云中的要求。

这也可能是一个机会，从传统组织中使用的高度自定义标准转变，甚至考虑采用合规性来实施 CIS 标准，这在第十四章中提到过。这将是一个成本考虑问题，需要判断是否合理让你的团队来维护这些标准。

摘要

在本章中，我们讨论了如何不仅仅考虑纯技术问题，还要让 Puppet 的采用成功。我们回顾了如何选择重点和范围，以便通过迭代的持续改进交付 Puppet，使用定期的交付节奏以及像小团队集中的冲刺等方法，团队可以一起工作。我们讨论了如何将这个重点分解为可协作完成的交付物，并在定期周期中展示。我们还提到允许 Puppet 团队在做出决策和建立编码实践的过程中建立信心并学习，同时向管理层和利益相关者展示有意义的回报和进展。我们讨论了如何概述 Puppet 的使用案例，并确保避免将任务强行纳入 Puppet 中，以最大化回报，这样的做法可能会破坏 Puppet 基础设施的可靠性和性能，并带来日常维护的难题。

然后回顾了采用遗产资产的方法，展示了即使在由于标准和策略变化以及公司合并收购导致的资产断裂情况下，也可以遵循一个渐进的采用模式，逐步减少配置漂移，并收集有关资产的信息。

我们首先讨论了如何在没有配置的情况下推出代理并收集事实，以创建资产视图，这些视图可以输入到 CMDB 中，在 Puppet Enterprise 的情况下，使用内置集成来管理补丁和打包。接着我们展示了可以考虑使用编排来包装现有脚本，并提供更好的自动化。这可以通过完全授权的 Puppet Enterprise 通过 PCP 或 WinRM/SSH 连接在没有代理的 Puppet Enterprise 许可证下进行，或者使用 Bolt 服务器与 WinRM/SSH 连接来完成。这取决于你的许可证要求以及是否需要 RBAC 和日志记录。随后我们讨论了如何通过构建有状态的 Puppet 代码基准，查找需要强制执行的强制性设置，并在适当情况下使用无操作（no-op）来获取当前视图，逐步构建一个配置文件，允许将例外情况接受到 Hiera 中或对漂移进行修复。建立了这个基准之后，我们讨论了如何与应用团队重复此过程，以便将传统应用纳入控制范围，然后使用配置数据自动化审计报告。

我们讨论了如何跨多个团队协作，成立了一个 Puppet 平台团队，该团队倡导平台并为其他团队提供 API 和自服务，同时为团队设定了采用和使用 Puppet 的标准，但并没有对他们的交付进行限制。

在受管环境中部署证明了 Puppet 的有效性，通过向关键流程团队（如变更和风险管理团队）传达 Puppet 的工作原理，并解决实施过程中使用的流程，如何将代码开发和部署到生产环境中，同时考虑如何最好地与当前流程集成。赢得流程利益相关者和运营团队的信任，未来可能会改变流程，从而推动进一步的自动化。

最后，我们回顾了公共云的采用，讨论了公共云中遇到的两个主要问题：其一是采用云优先策略导致技术和流程的搬迁未经过深思熟虑，另外一个是应用团队单打独斗，忽略了在私有数据中心中为安全性和审计所做的自动化经验教训。我们解释了，应该考虑公共云的目的。它是数据中心的扩展，还是你希望将其纳入内部 Puppet 服务器视图的一部分，或者是你正在迁移的对象？将 Puppet 基础设施迁移到公共云可以开始采用云的灵活性。这是一个全新的方法，旨在通过代码优化来支持云的采用，或者通过遵循行业标准的 CIS 方法来摆脱老旧的定制内部标准，带来新的机会。关键措施是与应用团队会面，确保他们可以访问 API 和平台，从而使他们不必担心核心基础设施构建和安全配置，而只需关心对他们有用的内容，并且能够通过自助服务进行管理。

本书中展示了 Puppet 的有状态方法如何减少漂移和技术债务，自动化审计报告，提供一种标准的变更交付方式，即便在高度监管的环境中，也能为用户提供一个值得信赖的平台，以满足他们的基础设施需求，并释放团队的精力，将注意力集中在为客户交付产品上。配置管理是一个复杂的问题，没有一劳永逸的解决方案，但我们通过一种深思熟虑的迭代方法，展示了通过与组织的流程合作并全员参与，Puppet 如何为你的组织带来变革性的改变。