您如何指定锚定仅发生在人偶中的某些 classes/scopes 内
How can you specify anchoring to only happen within certain classes/scopes in puppet
我看到 用户有同样的问题，但我不是在问同样的问题。
我在 puppet 中遇到了与其他 OP 相同的循环依赖问题。此错误的原因是我们使用的上游模块内置了有意义的锚定，但与我们锚定我们在 manifests/site.pp 中使用的上游 apt 模块组件的方式不兼容，以确保apt update 在添加新源时运行。
manifests/site.pp 中确保任何 apt 源在 apt 更新之前运行的 puppet 代码是：
Apt::Source <| |> -> Class['apt::update'] -> Package <| |>
上游 docker 模块与此不兼容，具体来说，repo.pp puppet 清单的 this line 在 apt 源之前锚定一个包，如下所示：
Package['apt-transport-https'] -> Apt::Source <||>
因此出现了合法的循环依赖循环。
显然，我可以通过更新上游模块使其兼容（已被其他人作为问题 here 打开，所以显然对其他人来说也是一个问题）或更新我们的锚定来解决这个问题在 manifests/site.pp 中删除它并在每个适当的地方添加它 module/package (yuck).
我更感兴趣的解决方案，既可以解决这个特定问题，也可以更好地理解 puppet 清单，是否有办法设置 manifests/site.pp 以便特定锚定apt 源、apt 更新和包（上面引用）的模式仅在特定范围内出现。
类似于 if 用于打开诸如主机名之类的东西的逻辑：
if $hostname !~ /^myhostname/ {}
有没有办法在 puppet 中引用 class/scope 而不是关于节点的 facts/variables ？此代码不起作用，但我正在寻找理论上类似的东西：
if scope != 'docker' {
Apt::Source <| |> -> Class['apt::update'] -> Package <| |>
}
或者，如果没有办法做到这一点，我是否正确地声明 puppet 清单包含有关适用于整个节点的事物的逻辑（例如主机名、内存、CPU 数量）和资源included 适用于整个编译清单，而 ruby 函数可以包含关于人偶执行范围的更具体的逻辑？
[Is there] a way to set manifests/site.pp so the specific anchoring pattern of apt source, apt update, and package (referenced above) only occurs within certain scopes[?]
首先，您不应该声明 Apt::Source 资源和 Class['apt::update'] 之间的关系，至少如果这些来自 puppetlabs-apt 模块。 class 不是模块的 public class 就足够了——因此模块外的代码永远不应该触及它。但是，此外，该模块已经负责管理 classes 和它提供的资源类型之间的关系，您不应该搞砸它。换句话说，你太努力了。
事实上，这基本上就是让您陷入困境的原因。您插入到 site.pp 中的链式表达式过于宽泛，除了您希望涵盖的资源之外，还涵盖了属于 third-party 模块的资源。
如果您询问如何更具体，那么您应该考虑在收集器表达式中使用 filter predicate。例如：
Exec['apt-update'] -> Package<| tag == 'docker' |>
（请注意，puppetlabs-apt 模块记录了 Exec['apt-update'] 的存在和可用性，这使得使用起来相当安全。）
这有时与 tags 配合得很好，如上所示，但您可能会发现 Puppet 的自动标记涵盖的资源比适合您的目的多，并且必须手动标记您的资源达不到目的。
Alternatively, if there isn't a way to do this, would I be correct in stating that puppet manifests contain logic about things that apply to the entire node (e.g. hostname, memory, number of CPUs) and the resources included apply to the entire compiled manifest, whereas the ruby functions can contain more specific logic about the puppet execution scope?
这听起来太宽泛也太模糊了。
所有class和资源声明都具有全局可见性和效果。同样，收集器收集资源而不考虑声明出现的范围或在目录构建期间评估这些声明的相对顺序。
在目录构建期间评估清单代码。它可以依赖节点事实、目录构建器可用的外部数据来定制要为目标节点构建的目录。它还可以依赖硬编码到您的清单中的数据，但它本身很难被视为 "customization".
Puppet 支持 Ruby plug-ins 各种不同的范围、角色和功能。从技术上讲，他们可以访问 Puppet 内部，因为他们 运行 在 Puppet 的整体 Ruby 上下文中， 但他们不应该这样做 。一般来说，Ruby 插件应该限制自己使用与清单代码可用的基本相同的信息。或更少。
我看到
我在 puppet 中遇到了与其他 OP 相同的循环依赖问题。此错误的原因是我们使用的上游模块内置了有意义的锚定，但与我们锚定我们在 manifests/site.pp 中使用的上游 apt 模块组件的方式不兼容，以确保apt update 在添加新源时运行。
manifests/site.pp 中确保任何 apt 源在 apt 更新之前运行的 puppet 代码是：
Apt::Source <| |> -> Class['apt::update'] -> Package <| |>
上游 docker 模块与此不兼容，具体来说，repo.pp puppet 清单的 this line 在 apt 源之前锚定一个包，如下所示：
Package['apt-transport-https'] -> Apt::Source <||>
因此出现了合法的循环依赖循环。
显然，我可以通过更新上游模块使其兼容（已被其他人作为问题 here 打开，所以显然对其他人来说也是一个问题）或更新我们的锚定来解决这个问题在 manifests/site.pp 中删除它并在每个适当的地方添加它 module/package (yuck).
我更感兴趣的解决方案，既可以解决这个特定问题，也可以更好地理解 puppet 清单，是否有办法设置 manifests/site.pp 以便特定锚定apt 源、apt 更新和包（上面引用）的模式仅在特定范围内出现。
类似于 if 用于打开诸如主机名之类的东西的逻辑：
if $hostname !~ /^myhostname/ {}
有没有办法在 puppet 中引用 class/scope 而不是关于节点的 facts/variables ？此代码不起作用，但我正在寻找理论上类似的东西：
if scope != 'docker' {
Apt::Source <| |> -> Class['apt::update'] -> Package <| |>
}
或者，如果没有办法做到这一点，我是否正确地声明 puppet 清单包含有关适用于整个节点的事物的逻辑（例如主机名、内存、CPU 数量）和资源included 适用于整个编译清单，而 ruby 函数可以包含关于人偶执行范围的更具体的逻辑？
[Is there] a way to set manifests/site.pp so the specific anchoring pattern of apt source, apt update, and package (referenced above) only occurs within certain scopes[?]
首先，您不应该声明 Apt::Source 资源和 Class['apt::update'] 之间的关系，至少如果这些来自 puppetlabs-apt 模块。 class 不是模块的 public class 就足够了——因此模块外的代码永远不应该触及它。但是，此外，该模块已经负责管理 classes 和它提供的资源类型之间的关系，您不应该搞砸它。换句话说，你太努力了。
事实上，这基本上就是让您陷入困境的原因。您插入到 site.pp 中的链式表达式过于宽泛，除了您希望涵盖的资源之外，还涵盖了属于 third-party 模块的资源。
如果您询问如何更具体，那么您应该考虑在收集器表达式中使用 filter predicate。例如：
Exec['apt-update'] -> Package<| tag == 'docker' |>
（请注意，puppetlabs-apt 模块记录了 Exec['apt-update'] 的存在和可用性，这使得使用起来相当安全。）
这有时与 tags 配合得很好，如上所示，但您可能会发现 Puppet 的自动标记涵盖的资源比适合您的目的多，并且必须手动标记您的资源达不到目的。
Alternatively, if there isn't a way to do this, would I be correct in stating that puppet manifests contain logic about things that apply to the entire node (e.g. hostname, memory, number of CPUs) and the resources included apply to the entire compiled manifest, whereas the ruby functions can contain more specific logic about the puppet execution scope?
这听起来太宽泛也太模糊了。
所有class和资源声明都具有全局可见性和效果。同样，收集器收集资源而不考虑声明出现的范围或在目录构建期间评估这些声明的相对顺序。
在目录构建期间评估清单代码。它可以依赖节点事实、目录构建器可用的外部数据来定制要为目标节点构建的目录。它还可以依赖硬编码到您的清单中的数据，但它本身很难被视为 "customization".
Puppet 支持 Ruby plug-ins 各种不同的范围、角色和功能。从技术上讲，他们可以访问 Puppet 内部，因为他们 运行 在 Puppet 的整体 Ruby 上下文中， 但他们不应该这样做 。一般来说，Ruby 插件应该限制自己使用与清单代码可用的基本相同的信息。或更少。