如何在 Linux 中使用 Puppet 环境安全更新代理

发表 admin at 2025年2月28日

类别

未分类

标签

客观的

在更新实时生产系统之前创建并使用 Puppet 环境来测试新配置。

操作系统和软件版本

操作系统：任何主要的 Linux 发行版，例如Ubuntu、Debian、CentOS
软件：木偶和木偶大师

要求

对 Puppet Master 服务器和 Puppet 客户端节点的特权访问。

惯例

# – 要求以root权限直接以root用户身份或使用sudo命令执行给定的linux命令
$ – 给定以普通非特权用户身份执行的 linux 命令

介绍

大多数 Puppet 安装都是从运行单个分支的主服务器开始的。主节点包含与其同步的所有 Puppet 代理的所有清单和其他配置。这是一个很好的起点，但很快就会出现需要推送更新的情况，这可能会破坏生产服务器。抱有最好的希望并不是继续前进的最佳方式。

Puppet 提供了分离整个配置分支的工具。这些称为环境。 Puppet 环境是一种为一组隔离的代理节点提供其自己的专用配置的方法。每个环境都包含整个 Puppet 配置树，并且可以被视为单独的 Puppet 主服务器。

如何使用 Puppet 环境？

环境的典型场景（也是我们在本指南中探讨的场景）是在生产环境旁边创建一个测试环境，并在其中创建新的 Puppet 配置。

在测试环境中测试新配置的一种方法是更新生产服务器的副本，例如 VM 快照。任何问题都会在测试机器上观察到，并修改 Puppet 配置来纠正这个问题。然而，并不总是能够有一个测试服务器来检查测试环境中的变化。

我们将在此处探讨的另一种方法是在生产服务器上手动运行 Puppet 代理，但使用多个选项使 Puppet 代理同步到测试环境，但仅显示会发生的情况，而不进行任何实际更改。这将突出显示在完整更新中可能发生的任何错误，而不会实际导致任何停机。

创建 Puppet 环境

在本指南中，我们将创建一个非常简单的 Puppet 实例，其中包含 Puppet Master 和 Puppet 代理节点。 Puppet master 服务器将配置为有两个环境；测试和开发。

本指南假设您有一个 Puppet master 服务器和一个能够连接到 Puppet master 的 Puppet 代理节点。

我们将在 Puppet master 上创建两个环境，并在这些环境中创建一个非常简单的 Puppet 清单，该清单在代理节点上创建一个文本文件。

Puppet 配置的默认位置会根据您使用的发行版而变化。在 Ubuntu 18.04LTS（本指南将使用的版本）上，位置位于 /etc/puppet。其他发行版（和官方文档）可能会将其放置在 /etc/puppetlabs/ 中。但是，一旦进入主 Puppet 配置目录，所有发行版的所有子目录都是相同的。

指示

创建环境目录

环境及其配置都位于 /etc/puppet/code/ 目录下。在 Ubuntu 18.04 上，此目录在安装时为空，因此我们需要首先使用以下两个命令创建两个顶级环境目录：

# mkdir -p /etc/puppet/code/environments/testing
# mkdir -p /etc/puppet/code/environments/development

任何新的代理节点都会自动连接到development环境，除非将environment变量设置为[agent]部分中的替代变量。代理节点上的puppet.conf 文件。

创建两个简单的 site.pp 清单

site.pp 文件是主要清单，Puppet 代理从这里开始构建所需机器状态的目录。我们将在两个环境中创建两个非常简单的 site.pp 文件，这两个环境在代理节点上创建相同的文件。唯一的区别是他们将不同的文本放入文件中。

第一个 site.pp 文件将是生产环境： <代码> /etc/puppet/code/environments/development/manifests/site.pp 该文件应包含以下内容：

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Development Environment \n",
}

使用您最喜欢的文本编辑器创建并填充此文件。

此清单确保文件存在于 /tmp/example.txt 中，并包含文本“来自开发环境”（“\n”在文件末尾添加一个新行，即良好的做法，并在 Puppet 不存在时停止显示警告消息）。

第二个清单将在测试环境下： <代码> /etc/puppet/code/environments/testing/manifests/site.pp 该文件包含以下内容：

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Testing Environment \n",
}

这与开发环境中的文件几乎相同，唯一的区别是文件中的文本表明它来自测试环境。

从测试环境评估新的 Puppet 配置

代理节点默认仅同步到开发环境。我们将首先手动指示 Puppet 代理与 Puppet 主服务器同步，并创建并应用我们在开发环境中创建的 site.pp。

这是通过以下命令完成的：

# puppet agent --environment=production --test

--test 选项使 Puppet 代理在前台执行目录运行并进行详细日志记录。任何更新或更改都将应用于该节点。

--environment=product 选项用于明确我们正在从生产环境进行同步。通常，这将在主 Puppet 代理配置中进行配置，并且不需要包含在命令中。

运行上述命令时，我们得到以下输出：

  Info: Using configured environment 'production'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Caching catalog for digital-2.net
  Info: Applying configuration version '1527680694'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/ensure: defined content as '{md5}59f9ce1d4aad5fd155db7ccc2478a93b'
  Notice: Applied catalog in 0.02 seconds

此输出表明文件 /tmp/example.txt 不存在，因此 Puppet 代理按照 site.pp 清单中的说明创建了该文件。后续运行将不会出现 Notice: 行，因为 /tmp/example.txt 文件存在且内容正确。

现在代理节点的状态与开发环境的清单一致，我们可以测试如果我们应用测试环境中的替代清单会发生什么。

为了测试而不是提交新配置，我们需要运行以下命令：

# puppet agent --environment=testing --test --noop

如您所见，--environment 选项已更改为测试，并且我们添加了附加选项 --noop。此选项使代理执行试运行。这意味着 Puppet 代理不会对代理节点进行任何实际更改，但会像以前一样生成所有输出。

这使我们能够评估如果将新配置应用于服务器会发生什么。在这种情况下，上述命令的输出如下所示：

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Applying configuration version '1527683748'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content:
  --- /tmp/example.txt    2018-05-30 12:19:16.205774048 +0000
  +++ /tmp/puppet-file20180530-21610-8ipzur      2018-05-30 12:35:48.740982652 +0000
  @@ -1 +1 @@
  -From The Development Environment
  +From The Testing Environment

  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content: current_value '{md5}59f9ce1d4aad5fd155db7ccc2478a93b', should be '{md5}abbb8f68df144a5673d
  62ae6c4a036ed' (noop)
  Notice: Class[Main]: Would have triggered 'refresh' from 1 event
  Notice: Stage[main]: Would have triggered 'refresh' from 1 event
  Notice: Applied catalog in 0.04 seconds

这里最有趣的几行如下：

  -From The Development Environment
  +From The Testing Environment

这些用减号 ( - ) 表示要更改的内容，用加号 ( + ) 表示要更改的内容。在此示例中，它是文件中的文本。

所有这些输出都表明新配置已成功应用，并且 /tmp/example.txt 的内容已被修改。如果这是生产服务器所需的状态，则可以在生产环境中安全地对 site.pp 文件进行更改。

识别错误

新的 Puppet 配置并不总是能够毫无错误地应用，这就是在将其应用到生产系统之前应始终对其进行测试的原因。在这种情况下，我们将通过在测试 site.pp 文件中故意犯错误来强制发生错误。我们将尝试将文件的权限设置为0944，这不是有效的权限，会导致错误。

现在，当我们运行时：

  # puppet agent --environment=testing --test --noop

我们将看到以下输出：

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Error: Failed to apply catalog: Parameter mode failed on File[/tmp/example.txt]: The file mode specification is invalid: "0944" (file: /etc/puppetcode/environments/testing/manifests/site.pp, line: 1)

以下屏幕截图显示了命令行上显示的输出：

Puppet 将通过用红色打印来指示任何错误。

这些颜色立即让我们知道尝试使用测试环境中的新 Puppet 配置时会出现错误。但是，当我们使用 --noop 选项时，不会向生产服务器提交任何错误。

结论

当运行由 Puppet 管理的生产系统时，在应用任何新配置之前对其进行测试始终很重要。使用 Puppet 提供的工具来创建替代环境，在该环境中可以安全地创建新配置并针对生产系统进行评估，这将意味着更少的错误和更少的停机时间。