木偶 - 环境

在软件开发和交付模型中，有不同类型的测试环境用于测试特定的产品或服务。作为标准实践，主要有开发、测试和生产三种环境，其中每种环境都有自己的设置配置。

Puppet 与 Ruby on Rails 一样支持多种环境的管理。创建这些环境背后的关键因素是提供一种简单的机制来管理不同级别的 SLA 协议。在某些情况下，机器总是需要在没有任何容忍和使用旧软件的情况下启动。其中其他环境是最新的并用于测试目的。它们用于升级更重要的机器。

Puppet 建议坚持使用标准生产、测试和开发环境配置，但是，它甚至为用户提供了根据要求创建自定义环境的优势。

环境目标

按环境划分设置的主要目标是 Puppet 可以拥有不同的模块和清单源。然后，我们可以在测试环境中测试配置的更改，而不会影响生产节点。这些环境还可用于在不同的网络源上部署基础设施。

在 Puppet Master 上使用环境

环境的重点是测试需要将文件的哪些清单、模块、模板发送到客户端。因此，必须将 Puppet 配置为为这些信息提供特定于环境的源。

Puppet 环境的实现只需将预环境部分添加到服务器的 puppet.conf 并为每个环境选择不同的配置源即可。然后优先使用这些预环境部分而不是主要部分。

[main] 
manifest = /usr/testing/puppet/site.pp 
modulepath = /usr/testing/puppet/modules 
[development] 
manifest = /usr/testing/puppet/development/site.pp 
modulepath = /usr/testing/puppet/development/modules

在上面的代码中，开发环境中的任何客户端都将使用位于目录/usr/share/puppet/development中的 site.pp 清单文件，并且 Puppet 将搜索/usr/share/puppet/development/modules 目录中的任何模块。

无论有没有任何环境，运行 Puppet 都会默认使用 site.pp 文件以及主配置部分中的清单和 modulepath 值中指定的目录。

只有很少的配置实际上对配置预环境有意义，并且所有这些参数都围绕指定用于编译客户端配置的文件。

以下是参数。

Modulepath - 在 Puppet 中，作为基本标准模式，最好有一个所有环境共享的标准模块目录，然后是一个可以存储自定义模块的预环境目录。模块路径是 Puppet 查找所有与环境相关的配置文件的位置。
Templatedir - 模板目录是保存相关模板的所有版本的位置。该模块应该优先于这些设置，但是它允许在每个环境中拥有给定模板的不同版本。
Manifest - 这定义了用作入口点脚本的配置。

通过多个模块，Puppet 有助于实现配置的模块化。人们可以在 Puppet 中使用多个环境，如果主要依赖于模块，效果会更好。通过将更改封装在模块中，可以更轻松地将更改迁移到环境。文件服务器使用环境特定的模块路径；如果从模块提供文件服务，而不是单独的安装目录，则该环境将能够获取特定于环境的文件，最后当前环境也将在清单文件中的 $environment 变量中可用。

设置客户端环境

所有与环境配置相关的配置都在puppet.conf文件中完成。要指定 Puppet 客户端应使用哪个环境，可以在客户端的 puppet.conf 文件中指定环境配置变量的值。

[puppetd] 
environment = Testing

配置文件中的上述定义定义了在我们的例子中配置文件正在测试的环境。

还可以使用命令行指定这一点 -

#puppetd -–environment = testing

另外，Puppet 还支持在环境配置中使用动态值。开发人员无需定义静态值，而是可以创建自定义事实，从而根据某些其他客户端属性或外部数据源创建客户端环境。首选的方法是使用自定义工具。这些工具能够指定节点的环境，并且通常更擅长指定节点信息。

傀儡搜索路径

Puppet 使用简单的搜索路径来确定需要在目标计算机上应用哪些配置。同样，当 Puppet 尝试选取需要应用的适当值时，搜索路径非常有用。Puppet 在下面列出的多个位置中搜索需要应用的值。

命令行中指定的值
环境特定部分中指定的值
在特定于可执行文件的部分中指定的值
主要部分中指定的值