
私は、ほぼ同一の Linux VM を 200 台ほど持っています。すべての共通構成にはクラスがあります。
class my_packages {
class { "::ntp":
servers => [ "de.pool.ntp.org" ],
}
....
}
これを site.pp の各ノードに含めます。
ここで、独自のローカル タイム サーバーを実行したいと思います。これは、puppetlabs/ntp パッケージを使用すれば簡単です。my_packages の servers エントリを新しいタイム サーバー VM の IP アドレスに置き換えるだけで、その VM には、以前 my_packages で使用されていたのと同じ ntp クラス エントリが含まれるようになります。
node 'mytime' {
# include my_packages
class { '::ntp':
servers => [
'de.pool.ntp.org',
'ptbtime1.ptb.de',
'ptbtime2.ptb.de',
'ptbtime3.ptb.de',
],
}
...
}
ただし、クラス「::ntp」エントリがノードで定義されているため、新しいタイム サーバー VM のノード エントリに my_packages を含めることができません。この場合、「重複宣言」エラーが発生するためです。
ローカル ネーム サーバーの使用時にも同様の問題が発生しています。各 VM にはローカル ネーム サーバーを指す /etc/resolv.conf ファイルがあるため、my_packages にはそのためのファイル リソースがあります。ただし、ローカル ネーム サーバー自体には別の /etc/resolv.conf ファイルが必要です。インストールが完了するまで、ローカル ネーム サーバー自体を指すことはできませんが、インストール中はそうではありません。
共通のリソースセットを使用しながら、時々例外を許容するためのベストプラクティスは何ですか?
答え1
Puppet 3以降を使用している場合、これを実行する最善の方法は、hieraを使用して実行することです。自動パラメータ検索簡単に言うと、リソース スタイルの構文ではなく、インクルード構文を使用してクラスを宣言できるため、クラスに対して複数の宣言を行うことができます。クラスに対してインクルード スタイルとリソース スタイルの宣言を混在させることはできないことに注意してください。
通常、include 構文を使用してクラスを宣言する場合、必須パラメータがあると失敗します。自動パラメータ検索を使用すると、puppet は hiera を通じてパラメータの値を検索しようとします。
Hiera は、データ ソースの階層を通じて値を検索しようとするため、このように名付けられています。hiera.yaml でこの階層を指定し、さまざまなファクト (ホスト名、カスタム ファクトなど) と照合したり、ハードコードされたファイルをチェックしたりできます。
あなたのケースに当てはまるかもしれない簡単な例を次に示します。
クラス定義:
class my_packages {
include ::ntp
...
}
mytime.yaml:
----
ntp::servers:
- 'de.pool.ntp.org'
- 'ptbtime1.ptb.de'
- 'ptbtime2.ptb.de'
- 'ptbtime3.ptb.de'
共通.yaml:
---
ntp::servers: ['de.pool.ntp.org']
hiera.yaml:
...
:hierarchy:
- "${::fqdn}"
- common
...
この場合、hiera は ntp::servers キーを使用して、ntp クラスの servers パラメータの値を検索しようとします。最初に、ホスト名に一致するすべての yaml ファイルでそのキーを検索し、その後 common.yaml を検索します。
ほとんどの場合、common.yaml 内のキーが使用されますが、mytime ノードの場合は階層の上位にある値が見つかり、そこで検索を停止します。
ここにリンクがあります完全な例ちなみに、これは ntp モジュールをカバーしています。