如何过滤木偶清单中的哈希值?
How to filter hash in puppet manifest?
你能帮帮我吗?我从木偶清单中的 hiera 获取命令,然后尝试过滤它们并将 python 脚本作为参数传递。但是不知道怎么做。
我的家:
myclass::server_conf:
'first_serv':
'serv_name': 'testname'
'serv_hostname': 'testhost'
'test_url': 'test@url.com'
'second_serv':
'serv_name': 'testname2'
'serv_hostname': 'testhost2'
'test_url': 'test@url.com2'
我的人偶清单(我从 hiera 中的值中获取哈希值):
$server_conf = hiera_hash('myclass::server_conf', {})
因此我有:
{\"first_serv\"=>{\"serv_name\"=>\"testname\", \"serv_hostname\"=>\"testhost\", \"test_url\"=>\"test@url.com\"}, \"second_serv\"=>{\"serv_name\"=>\"serv2\", \"serv_name\"=>\"testname2\", \"serv_hostname\"=>\"testhost2\", \"test_url\"=>\"test@url.com2\"}}
然后我想 select 从此列表中仅值:
'testname' 'testhost' 'test@url.com' 'testname2' 'testhost2' 'test@url.com2'
我正在尝试使用地图函数来完成:
$transforrmed_data = map(server_conf) |$key,$value| { $value }
出现错误:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not match |$key,$value| at /manifests/server.pp:26 on node test.node
我该如何解决这个问题?我还需要转移到另一个变量 'testname2' 'testhost2' 'test@url.com2' 并将其传递给 exec 命令资源。
谢谢!
在 Ask PuppetLabs 论坛上似乎有一个很好的例子:Iterate nested hash from hiera in manifest。
该解决方案使用 defined type which runs your exec. Then just iterate over your hash automatically with create_resources(),它将哈希转换为一组资源并将它们添加到目录中。此函数可以轻松地一次从 Hiera data-source 创建许多资源,而不必编写自己的循环函数。它最好与已定义的类型一起使用,因为它们可以多次实现。
我已根据您的目的修改了他们的示例:
define run_my_exec($serv_name, $serv_hostname, $test_url) {
notify { "$serv_name": }
}
$server_conf = hiera_hash('myclass::server_conf', {})
create_resources( run_my_exec, $server_conf )
此外,在 puppet 中使用 exec 是一种代码味道。并不是说它总是不好,但通常它是解决问题的最不优雅的方法。例如,这个 exec 正在配置您的服务器吗?如果是这样,也许使用模板来编写配置文件会更好。这是 puppet 文档中关于该类型执行人员的另一种观点:
A caution: There’s a widespread tendency to use collections of execs to manage resources that aren’t covered by an existing resource type. This works fine for simple tasks, but once your exec pile gets complex enough that you really have to think to understand what’s happening, you should consider developing a custom resource type instead, as it will be much more predictable and maintainable.
你能帮帮我吗?我从木偶清单中的 hiera 获取命令,然后尝试过滤它们并将 python 脚本作为参数传递。但是不知道怎么做。
我的家:
myclass::server_conf:
'first_serv':
'serv_name': 'testname'
'serv_hostname': 'testhost'
'test_url': 'test@url.com'
'second_serv':
'serv_name': 'testname2'
'serv_hostname': 'testhost2'
'test_url': 'test@url.com2'
我的人偶清单(我从 hiera 中的值中获取哈希值):
$server_conf = hiera_hash('myclass::server_conf', {})
因此我有:
{\"first_serv\"=>{\"serv_name\"=>\"testname\", \"serv_hostname\"=>\"testhost\", \"test_url\"=>\"test@url.com\"}, \"second_serv\"=>{\"serv_name\"=>\"serv2\", \"serv_name\"=>\"testname2\", \"serv_hostname\"=>\"testhost2\", \"test_url\"=>\"test@url.com2\"}}
然后我想 select 从此列表中仅值:
'testname' 'testhost' 'test@url.com' 'testname2' 'testhost2' 'test@url.com2'
我正在尝试使用地图函数来完成:
$transforrmed_data = map(server_conf) |$key,$value| { $value }
出现错误:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not match |$key,$value| at /manifests/server.pp:26 on node test.node
我该如何解决这个问题?我还需要转移到另一个变量 'testname2' 'testhost2' 'test@url.com2' 并将其传递给 exec 命令资源。
谢谢!
在 Ask PuppetLabs 论坛上似乎有一个很好的例子:Iterate nested hash from hiera in manifest。
该解决方案使用 defined type which runs your exec. Then just iterate over your hash automatically with create_resources(),它将哈希转换为一组资源并将它们添加到目录中。此函数可以轻松地一次从 Hiera data-source 创建许多资源,而不必编写自己的循环函数。它最好与已定义的类型一起使用,因为它们可以多次实现。
我已根据您的目的修改了他们的示例:
define run_my_exec($serv_name, $serv_hostname, $test_url) {
notify { "$serv_name": }
}
$server_conf = hiera_hash('myclass::server_conf', {})
create_resources( run_my_exec, $server_conf )
此外,在 puppet 中使用 exec 是一种代码味道。并不是说它总是不好,但通常它是解决问题的最不优雅的方法。例如,这个 exec 正在配置您的服务器吗?如果是这样,也许使用模板来编写配置文件会更好。这是 puppet 文档中关于该类型执行人员的另一种观点:
A caution: There’s a widespread tendency to use collections of execs to manage resources that aren’t covered by an existing resource type. This works fine for simple tasks, but once your exec pile gets complex enough that you really have to think to understand what’s happening, you should consider developing a custom resource type instead, as it will be much more predictable and maintainable.