目的
在更新实时生产系统之前，创建并使用use环境来测试新配置。
操作系统和软件版本
- 操作系统：任何主要的Linux发行版，例如Ubuntu，Debian，CentOS
- 软件：Puppet(木偶)和puppet-master
要求
对人偶主服务器和人偶客户端节点的特权访问。
困难
介质
约定
介绍
大多数Puppet安装都是从运行单个分支的主服务器开始的。该主服务器包含所有清单和与之同步的所有Puppet代理的其他配置。这是一个很好的起点，但是很快就会有需要推送更新的时刻，这可能会破坏生产服务器。希望最好的不是前进的最佳方法。
Puppet提供了用于分离整个配置分支的工具。这些称为环境。 Puppet环境是一种为隔离的代理节点组提供其自己的专用配置的方法。每个环境都包含整个Puppet配置树，可以视为单独的Puppet主服务器。
Puppet(木偶)环境如何使用？
在本指南中，我们正在探讨一种典型的环境场景，即在生产环境旁边创建一个测试环境，在该环境中创建新的Puppet配置。
在测试环境中测试新配置的一种方法是通过更新生产服务器的副本(例如VM快照)。在测试机器上将观察到任何问题，并且修改了Puppet配置以更正此问题。但是，并非总是可以使用测试服务器来检查测试环境中的更改。
我们将在这里探讨的另一种方法是在生产服务器上手动运行Puppet代理，但是使用多个选项将导致Puppet代理同步到测试环境，但仅显示会发生的情况而没有进行任何实际更改。这将突出显示完全更新中可能发生的所有错误，而实际上不会导致任何停机。
创建人偶环境
在本指南中，我们将使用Puppet Master和Puppet代理节点创建一个非常简单的Puppet实例。 Puppet主服务器将配置为具有两个环境：测试和开发。
本指南假定您拥有一个Puppet主服务器和一个能够连接到Puppet主服务器的Puppet代理节点。
我们将在Puppet主数据库上创建两个环境，在这些环境中，我们将创建一个非常简单的Puppet清单，该清单在代理节点上创建一个文本文件。
Puppet配置的默认位置会根据您使用的发行版而变化。在Ubuntu 18.04LTS(本指南中将使用的版本)上，位置为/etc/puppet。其他发行版(和官方文档)可能会将其放在/etc/puppetlabs/。但是，一旦进入主Puppet配置目录，所有发行版的sub-directories均相同。
使用说明
创建环境目录
这些环境及其配置都存在于/etc/puppet/code/目录。在Ubuntu 18.04上，该目录在安装时为空，因此我们需要首先使用以下两个目录创建两个top-level环境目录命令：
# 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主服务器同步，并创建和应用site.pp我们在开发环境中创建的。
这是通过以下命令完成的：
# puppet agent --environment=production --test
的--test选项使Puppet代理使用详细日志记录执行在前台运行的目录。任何更新或更改都将应用于该节点。
的--environment=production选项可以清楚地表明我们正在与生产环境进行同步。通常，这将在主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。此选项使代理执行dry-run。这意味着，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配置会出现错误。但是，当我们使用--noop选项没有错误已提交到生产服务器。
结论
在运行由Puppet管理的生产系统时，在应用任何新配置之前测试它总是很重要的。使用Puppet提供的工具来创建替代环境，在其中可以安全地创建新配置并针对生产系统进行评估，这将减少错误并减少停机时间。