Question

在我们的基础架构中将Debian引入我们的Ganeti环境中作为硬件和VM的操作系统之后，我现在尝试通过在Debian主机中使用本地hiera.yaml文件为Debian主机部署适当的源列表。自行对其进行模块化。

我们将为Ubuntu以及本地仓库部署apt来源列表，并使用专用模块作为puppetlabs / apt模块的包装器。人偶服务器上的全局hiera.yaml如下所示：

---
version: 5
defaults:
  datadir: data
  data_hash: yaml_data
hierarchy:
  - name: "module scope"
    paths:
      - "%{facts.fqdn}.yaml"
      - "%{facts.context}-%{facts.location}-%{facts.hostgroup}.yaml"
      - "%{facts.context}-%{facts.datacenter}-%{facts.hostgroup}.yaml"
      - "%{facts.context}-%{facts.hostgroup}.yaml"
      - "%{facts.context}-%{facts.location}.yaml"
      - "%{facts.context}-%{facts.datacenter}.yaml"
      - "%{facts.context}.yaml"
      - common.yaml
    datadir: "/etc/puppetlabs/code/environments/%{environment}/modules/%{module_name}/data"

在apt_sources模块中，common.yaml包含我们仓库的apt键。 %{facts.context}.yaml包含所有Ubuntu和我们的回购源列表，在大多数情况下这是足够的，因此对于某些主机组，我们需要一些外部存储库，例如mysql，percona，{{1 }}等。这些来源包含在各自的yaml文件中，可以包含在ceph中，也可以包含在其他yaml文件中，最后，我们只将%{facts.context}-%{facts.hostgroup}.yaml和其他哈希中的哈希值合并相关的Yaml文件。现在，随着Debian的事情变得更加复杂，我不得不在%{facts.context}.yaml模块中重组data目录，以便Debian源码列表与Ubuntu源码列表分开，如下所示：

apt_sources

我创建了一个本地apt_sources$ tree -L 1 data/ data/ ├── common.yaml ├── Debian └── Ubuntu 2 directories, 1 file apt_sources$文件，其中包含以下内容：

hiera.yaml

我们的--- version: 5 defaults: datadir: data data_hash: yaml_data hierarchy: - name: "module scope" paths: - "%{facts.operatingsystem}/%{facts.fqdn}.yaml" - "%{facts.operatingsystem}/%{facts.context}-%{facts.location}-%{facts.hostgroup}.yaml" - "%{facts.operatingsystem}/%{facts.context}-%{facts.datacenter}-%{facts.hostgroup}.yaml" - "%{facts.operatingsystem}/%{facts.context}-%{facts.hostgroup}.yaml" - "%{facts.operatingsystem}/%{facts.context}-%{facts.location}.yaml" - "%{facts.operatingsystem}/%{facts.context}-%{facts.datacenter}.yaml" - "%{facts.operatingsystem}/%{facts.context}.yaml" - common.yaml datadir: "/etc/puppetlabs/code/environments/%{environment}/modules/%{module_name}/data"的相关部分必须与puppet 3保持兼容，因为它们与某些QA基础结构兼容：

init.pp

现在，当为具有附加# class apt_sources ( Hash $gnupg_key = {}, Hash $pin = {}, $proxy = {}, $purge_sources = false, Hash $settings = {}, Hash $sources = {}, ) { class { 'apt': update => { frequency => 'daily', }, purge => { 'sources.list' => $purge_sources, 'sources.list.d' => $purge_sources, }, } create_resources('apt::source', hiera_hash('apt_sources::sources', $sources)) create_resources('apt::setting', hiera_hash('apt_sources::settings', $settings)) create_resources('apt::key', hiera_hash('apt_sources::gnupg_key', $gnupg_key)) create_resources('apt::pin', hiera_hash('apt_sources::pin', $pin)) Apt::Pin <| |> -> Apt::Source <| |> -> Apt::Ppa <| |> -> Exec['apt_update'] -> Package <| |> }文件的主机部署apt_sources时，不会合并源列表，而是仅赢得更具体的yaml文件，在这种情况下为%{facts.context}-%{facts.hostgroup}.yaml文件，因此%{facts.context}-%{facts.hostgroup}.yaml中的主存储库尚未部署。在puppetserver中，我可以在日志文件中看到Puppet如何使用全局%{facts.context}.yaml然后使用本地hiera.yaml来查找密钥，但仅用于第一个哈希，然后有以下行：

hiera.yaml

并且Puppet继续寻找其他键，但是这次仅使用全局Hiera configuration recreated due to change of scope variables used in interpolation expressions配置，而跳过本地配置，因此Puppet无法找到任何哈希，并使用默认的hiera.yaml值。

很遗憾，由于Puppet 3的兼容性，暂时无法用{}函数替换hiear_hash。

编辑

最初只有Ubuntu作为操作系统，我在目录lookup中拥有所有hiera数据，而data/看起来像这样：

init.pp

也许有人可以解释这种行为。

谢谢您的帮助。

Answer 1

我通过将以下内容添加到common.yaml中来对其进行了修复：

lookup_options:
  apt_sources::sources:
    merge:
      strategy: deep

我进一步更改了create_resources语句，如下所示：

create_resources('apt::source', $sources)
create_resources('apt::setting', $settings)
create_resources('apt::key', $gnupg_key)
create_resources('apt::pin', $pin)

与multiple一起使用多个hiera.yaml文件

1 个答案: