傀儡 – 环境

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

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

Puppet 建议坚持使用标准的生产、测试​​和开发环境配置，然而，在这里它甚至为用户提供了根据需求创建自定义环境的杠杆作用。

环境目标

根据环境拆分设置的主要目标是，Puppet 可以有不同的模块和清单来源。然后可以在不影响生产节点的情况下测试测试环境中配置的更改。这些环境还可用于在不同的网络源上部署基础设施。

在 Puppet Master 上使用环境

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

Puppet 环境的实现只需将 pre-environment 部分添加到服务器的 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 文件和主配置部分的 manifest 和 modulepath 值中指定的目录。

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

以下是参数。

• Modulepath – 在 Puppet 中，作为基本的标准模式，最好有一个所有环境共享的标准模块目录，然后是一个可以存储自定义模块的预环境目录。模块路径是 Puppet 查找所有与环境相关的配置文件的位置。

• Templatedir – 模板目录是保存所有相关模板版本的位置。该模块应该优先于这些设置，但是它允许在每个环境中具有给定模板的不同版本。

• 清单– 这定义了用作入口点脚本的配置。

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

设置客户端环境

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

[puppetd] 
environment = Testing 

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

还可以使用以下命令在命令行上指定这一点：

#puppetd -–environment = testing

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

人偶搜索路径

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

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