![使用“puppet parser verify”验证 Puppet 清单时出现问题](https://linux22.com/image/556885/%E4%BD%BF%E7%94%A8%E2%80%9Cpuppet%20parser%20verify%E2%80%9D%E9%AA%8C%E8%AF%81%20Puppet%20%E6%B8%85%E5%8D%95%E6%97%B6%E5%87%BA%E7%8E%B0%E9%97%AE%E9%A2%98.png)
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。
答案3
为了进一步验证资源和属性是否合理,您可以使用 编译示例节点目录puppet master --compile
。这应该可以找到第一个例子。
我不太确定资源引用(第二个示例)是在主服务器还是客户端上进行验证,但您始终可以使用 或 以无操作模式执行它puppet catalog apply
。puppet apply
后者将再次编译它然后应用它,而前者应该能够从早期的验证中获取已编译的目录。