Puppet - 环境

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

Puppet 支持与 Ruby on Rails 相同的多种环境管理。创建这些环境的关键因素是提供一种简单的机制，用于在不同级别的 SLA 协议上进行管理。在某些情况下，机器始终需要保持运行，不能容忍和使用旧软件。而其他环境是最新的，用于测试目的。它们用于升级更重要的机器。

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

环境目标

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

在 Puppet Master 上使用环境

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

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

[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，都会默认使用主配置中的清单和 modulepath 值中指定的 site.pp 文件和目录部分。

实际上，只有少数配置才需要在环境前进行配置，所有这些参数都围绕着指定要使用哪些文件来编译客户端配置。

以下是参数。

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

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

• Manifest − 这定义了要使用哪个配置作为入口点脚本。

使用多个模块，Puppets 有助于获得配置的模块化。人们可以在 Puppet 中使用多个环境，如果人们很大程度上依赖模块，效果会更好。通过将更改封装在模块中，可以更轻松地将更改迁移到环境中。文件服务器使用特定于环境的模块路径；如果从模块而不是单独挂载的目录执行文件服务，则该环境将能够获取特定于环境的文件，最终当前环境也将在清单文件中的 $environment 变量中可用。

设置客户端环境

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

[puppetd]
environment = Testing

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

也可以使用 − 在命令行上指定它

#puppetd ​​-–environment = testing

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

Puppet 搜索路径

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

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