yumrepo 組み込み型を使用しています。 hieraworkingへの基本的な統合を得ることができます
_ yumrepo { hiera('yumrepo::name') :
metadata_expire => hiera('yumrepo::metadata_expire'),
descr => hiera('yumrepo::descr'),
gpgcheck => hiera('yumrepo::gpgcheck'),
http_caching => hiera('yumrepo::http_caching'),
baseurl => hiera('yumrepo::baseurl'),
enabled => hiera('yumrepo::enabled'),
}
_
その定義を削除して代わりにhiera_include('classes')
に移動しようとすると、対応するyamlバックエンドにあるものは次のようになります
_classes:
- "yumrepo"
yumrepo::metadata_expire: 0
yumrepo::descr: "custom repository"
yumrepo::gpgcheck: 0
yumrepo::http_caching: none
yumrepo::baseurl: "http://myserver/custom-repo/$basearch"
yumrepo::enabled: 1
_
エージェントでこのエラーが発生します
サーバーでのエラー400:クラスyumrepoが見つかりませんでした
Hieraとリソースタイプを使用したある種の最小限のノード宣言から逃れることはできないと思いますか?多分 hiera_hash 行く方法ですか?
これを試してみましたが、構文エラーが発生します
_ yumrepo { 'hnav-development':
hiera_hash('yumrepo')
}
_
create_resources を使用することになりました。基本的に、hiera_include
がすぐに使用できるクラスで行うのとほぼ同じ方法で、定義されたタイプをhieraのノードにマップする機能を提供します。
この設定では、階層の任意のレベルで任意の数のfile
リソースタイプを宣言でき、さらに構成はすべてhieraデータソースにあります。
/ etc/hiera.yaml
:hierarchy:
- defaults
- "%{environment}"
/ var/lib/hiera/defaults.yaml
classes:
- hiera_file_wrapper
hiera_file:
hiera-two:
path: /home/quickshiftin/hiera-two
ensure: file
content: 'Hiera two'
/ var/lib/hiera/production.yaml
hiera_file:
hiera-baby:
path: /home/quickshiftin/hiera-baby
ensure: file
content: 'Hiera baby!
modules/hiera_file_wrapper/manifestes/init.pp
class hiera_file_wrapper()
{
create_resources(file, hiera_hash('hiera_file'))
}
manifestes/site.pp
hiera_include('classes')
私は自分の仕事でhiera_manifest機能を構築しました。基本的に、モジュール、クラス、パラメーター、および定義されたタイプをすべてhierayaml経由で呼び出すことができます。
共有するためにGithubに載せました: https://github.com/mlbam/hiera_manifest
これには、モジュール、クラス、またはタイプの呼び出し時にパラメーターも配置されるというわずかな利点があります。
注意すべき点の1つは、メタパラメーターを使用する場合のリソース定義の構文の違いです。また、トラブルシューティング時に、エラーがマニフェストに付着することがあり、エラーをスローするモジュールに対して適切なエラーメッセージが表示されません。
yumrepo
はクラスではなくリソースタイプであるため、機能しません。
yumrepo_myreponame
という名前のクラスを配置し、yumrepo
リソースを宣言するようにします。必要に応じて、そのためにクラスパラメータをHieraに配置し、それらをリソース宣言に渡すことができます。
たとえば、サーバーのEPELをオンにするモジュールがあり、Hiera classes
配列に配置して有効にすることができます。その全体の内容は次のとおりです。
class epel_yumrepo {
yumrepo { "epel":
descr => 'Extra Packages for Enterprise Linux 6 - $basearch',
enabled => 1,
gpgcheck => 1,
gpgkey => 'http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6',
mirrorlist => 'https://mirrors.fedoraproject.org/metalink?repo=epel-6&Arch=$basearch',
failovermethod => "priority",
}
}
Hnavという名前のyumリポジトリがあり、使用しているOSのバージョン(5または6)に基づいて異なるURLを持つ必要があると仮定します。
/ etc/puppet/hiera.yaml likeで階層を構成しました
:hierarchy:
- "%{::operatingsystemmajrelease}"
- common
そのため、hieraは最初にOSバージョンにちなんで名付けられたyamlファイル5.yamlまたは6.yamlを探します。そこに値が見つからない場合は、common.yamlを検索します。
Hieraが自動的にURLを提供できるように、パラメーター化されたクラスを作成しました。
modules/hnav/manifests.init.pp
class hnav ( $url ) {
yumrepo { 'hnav':
enabled => true,
baseurl => $url
}
}
何らかの理由でパラメーター化されたクラスが気に入らなかった場合は、上記を次のように書くことができます。
class hnav {
yumrepo { 'hnav':
enabled => true,
baseurl => hiera('hnav::url')
}
}
次に、すべてのノードに適用する必要のあるクラスを構成しました
common.yaml
classes:
- hnav
そして、URLの値を設定します
5.yaml
hnav::url: http://example.com.yum/5/
6.yaml
hnav::url: http://example.com.yum/6/
これは本当に人工的な例ですが、hieraがどこで使用されているかを理解するのに役立つかもしれません。