エクスポートされたリソースを使用した具体的な例では、vitralリソースの主な意味がすでに明らかになっているようです-仮想リソースがデータベースに配置され、エージェント間で情報を交換するために使用される
場合、再帰を理解するには、再帰を理解する必要があるため 、ローカルアプリケーションから始めましょう。 たとえば。
例は少し合成されます。 仮想リソースの意味を示しながら、かなり短い例を思いつくことは困難でした。 実際には、有線ユーザー名を使用したこのような例はまれです。 少なくともそうすべきです。
Apacheがインストールされたサーバーがあります。 インストールと構成は、Apache Puppetクラスで便利でファッショナブルです。 簡単にするために、
site.ppのメインマニフェストにすべてを保存します。 例の開発中に発生するすべての問題は、ロジックの一部をモジュールに配置する場合に関連します。
クラスにUNIXユーザー（この例では
webUser ）が
必要であり、そのホームディレクトリがWebのドキュメントルートになるとします。 次に、次の
site.ppスケルトンを取得します。
class apache { user { 'webUser' : ensure => present } ... } node default { include apache }
すべてがシンプルです。 ここで、どのような目的であっても、nginxをインフラストラクチャに追加することにしました。 主なことは、コンテンツをレンダリングするためにwebUserユーザーも必要なことです。 クラスを追加します。
class apache { user { 'webUser' : ensure => present } } class nginx { user { 'webUser' : ensure => present } } node default { include apache include nginx }
以下を開始します。
root@puppet:/vagrant
明らかな理由により、機能しません。 1つのスコープに、同じ
namevar値を持つ2つのリソースがあることが
わかります。 たとえば、ユーザーのリソースを別のクラスに入れることで問題を解決できます。
class users { user { 'webUser' : ensure => present } } class nginx { include users } class apache { include users } node default { include apache include nginx }
起動-動作します：
root@puppet:/vagrant
キャッシュを保存するフォルダに新しいユーザー
cacheUserを追加する必要があるとします。 Apacheとnginxは両方ともこのキャッシュを使用するため、対応するユーザーを
ユーザークラスに追加し
ます 。
class users { user { 'webUser': ensure => present } user { 'cacheUser': ensure => present } }
次に、php5-fpmとuwsgiを追加することにしました。これらは
webUserを必要とし
ますが、
cacheUserは必要ありません。 この状況では、apacheクラスとnginxクラスのみで個別に接続するために、
cacheUserを別のクラスに割り当てる必要があります。 これは不便です。 さらに、少し後で別のクラスの別のユーザーを選択する必要がないという保証はありません。 これは、仮想リソースが助けになる場所です。
リソース定義に
@記号を追加する場合：
@user { 'webUser': ensure => present }
リソースは仮想と見なされます。 このようなリソースは、明示的に定義するまでエージェントディレクトリに追加されません。 ドキュメントから：
仮想リソース宣言は、リソースをカタログに追加せずに、リソースの望ましい状態を指定します
したがって、システムに
webUserおよび
cacheUserユーザーが存在しない場合でも、以下のコードを実行すると、それらは追加されません。
class users { @user { 'webUser': ensure => present } @user { 'cacheUser': ensure => present } } class nginx { include users } class apache { include users } node default { include apache include nginx }
私たちはチェックします：
root@puppet:/vagrant
予想どおり、ユーザーは追加されませんでした。
ただし、注意が必要です。 仮想リソースがディレクトリに追加されないという事実にもかかわらず、これは次のコードが機能することを意味しません。
class apache { @user { 'webUser' : ensure => present } } class nginx { @user { 'webUser' : ensure => present } } node default { include apache include nginx }
それでもコンパイルエラーがスローされます。 これは、最初、パペットパーサーがすべてのリソースを反復処理し、カタログにin vitroを追加するためです。 この段階で、名前の重複が原因でエラーが発生します。 次のステップは、仮想タイプの実装の処理です。コレクターは、仮想リソースが決定され、非仮想として検出された場所をカタログで探します。 そして、最後になって初めて、実現されない仮想リソースからカタログがクリーンアップされます。
リソースを決定するには、宇宙船演算子
<| | > 実現機能を使用します。 1つの構文と他の構文の両方を使用してマニフェストを書き換えます。
class users { @user { 'webUser': ensure => present } @user { 'cacheUser': ensure => present } } class nginx { include users realize User['webUser'], User['cacheUser'] } class apache { include users User <| title == 'webUser' or title == 'cacheUser' |> } node default { include apache include nginx }
一度に複数のリソースを
実現関数に渡す
ことができ、
<| |>リソースを検索して決定する条件をいくつか指定できます。
Realizeと
<|の構文の違いに加えて
|>動作に違いがあります。 指定された名前のリソースが存在しない場合、
realizeはエラーを
スローします。
Error: Failed to realize virtual resources User[nonExistingUser] on node puppet.example.com
演算子
<| |>この場合、
realize関数の一種のアドオンであるため、エラーは発生しません。 見つかったすべてのリソースに対して、
realize関数が本体で指定された検索クエリに適用されます。 したがって、所定の基準に従ってリソースが見つからなかった場合、
実現機能が呼び出されない
ため 、エラーは発生しません。
ところで、演算子
<| |>さらに2つの使用法があります。 クラス内のリソースの状態をオーバーライドするために使用できます。 例：
class configurations { file { '/etc/nginx.conf' : ensure => present } file { '/etc/apache2.conf' : ensure => present } } node s1.example.com { include configurations } node s2.example.com { include configurations File <| title == '/etc/apache2.conf' |> { ensure => absent } }
ノード
s2.example.comのファイル
/etc/apache2.con fを
除外します。
〜>および
->演算子とともに使用することもできます。 したがって、すべてのサービスに変更を通知するか、パッケージをインストールする前にすべての
yumリポジトリを追加する必要があります。
Yumrepo <| |> -> Package <| |>
仮想リソースの主な利点は、それらをエクスポートして他のエージェントが利用できるようになることです。 仮想リソースをエクスポートするには、説明の前に別の
@記号を追加する必要があります。
Puppetドキュメントの典型的な例：
class ssh {
この例では、仮想リソース
sshkeyを定義しました。 コレクターオペレーター
<< | | >>は空のボディを含むため、
Sshkeyクラスのエクスポートされたすべてのオブジェクトをアンロードします。 したがって、sshクラスが接続されているマニフェスト内のエージェントは、公開キー（
@@ sshkey ）をエクスポートしてから、他のエージェントによって追加されたすべてのキーを自身にインポートします（
Sshkey << | | >> ）。
エクスポートされたリソースは、PuppetLabsのデータベースであるPuppetDBに保存されます。 PuppetDBに接続した後、pupetマスターによってコピーされた各ディレクトリはPuppetDBデータベースに配置され、PuppetDBデータベースはディレクトリを検索するための検索インターフェイスを提供します。
@@を指定することにより、リソースをエクスポート可能としてマークし、リソースをディレクトリに追加し、
エクスポートされたラベルをそのディレクトリに配置する必要があることをpuppetに通知します。 パペットマスターが演算子を見るとき
<< | | >> 、
PuppetDBに対して検索クエリを
作成し、検索条件に一致するすべての見つかったエクスポート済みリソースを追加します。
エクスポートされたリソースはグローバルスコープ内にあることが重要であるため、それらの名前は一意でなければなりません。
この機能には大きな可能性があり、頻繁に使用する必要があります。 サーバーを監視またはnginxバックエンドに追加する自動化。
既存のモジュールを使用することをお勧めしますが、原則を示すには、この例が適しています。
構文および使用パターンの詳細については、次のリンクを参照してください。