☰

使用“puppet parser verify”验证 Puppet 清单时出现问题

tag-icon • tag-icon git puppet
使用“puppet parser verify”验证 Puppet 清单时出现问题

puppet parser validate我在 git hook 中使用，pre-commit以便在将文件提交到我们的 Puppet 配置存储库之前发现问题。不幸的是，此命令似乎是一个非常轻量级的语法检查，仅标记不平衡引号和括号等错误。

该validate命令似乎并未真正解析配置并查找无效属性、未定义引用等内容。例如，以下内容不会导致投诉：

file { 'somefile': requires => File['some-other-file'] }

在此示例中，requires应为require。类似地，这也不会产生任何错误：

file {'somefile': require => File['file-that-does-not-exist']}

没有 的资源定义file-that-does-not-exist。

有没有办法在不实际应用配置的情况下捕获这些错误？我希望命令上有某种标志puppet apply可以完全解析配置而不进行更改，但据我所知，Puppet 2.7.1 中不存在这样的选项。

更新

puppet apply --noop似乎在另一个方向上尝试得太过分了。它会尝试访问stat()清单中引用的任何文件，如果它尝试访问stat()当前用户无法访问的文件，这通常会导致它因权限错误而失败。

其他人在做什么？

答案1

简而言之，这是一个不简单的问题，不能通过解析清单轻松解决。编译目录可以扩大测试范围，但这不是万能药。puppet master --compile 需要访问节点事实，理想情况下还需要一个可以完全测试所有类的虚拟节点。您仍然需要处理以下限制：

  • 不能位于同一目录中的类（apache、apache::disable）
  • 跨类依赖。
  • 不同的操作系统平台。
  • 具有不同参数的节点。

例如，如果节点一包含 a 和 b，那没问题，但节点二只需要 b，那您只会在节点二上看到失败。

class a {
  notify { 'hi': }
}
class b {
  notify { 'bye':
    require => Notify['hi'],
  }
}

如果您有资源，您可以为所有节点编译目录，这将提供相当全面的覆盖范围。

puppet apply --noop 也有其局限性，我首先想到的是：它会导致由包部署的 exec 失败，它会导致文件根据暂存位置失败，并且除非您将测试扩展到系统的代表性样本，否则它不会测试多个平台。一般来说，它提供了足够的覆盖范围以确保没有编译问题，让您了解哪些系统受到影响，有哪些变化，并且您可以通过报告判断更改是正常还是真正的问题。

在大多数情况下，noop 就足够了，我已经看到了不同程度的自动化测试，例如 jenkins，其中每个模块测试文件都用 --noop 模拟（上述限制适用），或者使用 Vagrant 生成虚拟机来执行全面测试。

答案2

您可能需要考虑引导一个测试环境，例如 Cucumber-puppet。

https://github.com/nistude/cucumber-puppet

答案3

为了进一步验证资源和属性是否合理，您可以使用 编译示例节点目录puppet master --compile。这应该可以找到第一个例子。

我不太确定资源引用（第二个示例）是在主服务器还是客户端上进行验证，但您始终可以使用 或 以无操作模式执行它puppet catalog apply。puppet apply后者将再次编译它然后应用它，而前者应该能够从早期的验证中获取已编译的目录。

相关内容