例は少し合成されます。 仮想リソースの意味を示しながら、かなり短い例を思いつくことは困難でした。 実際には、有線ユーザー名を使用したこのような例はまれです。 少なくともそうすべきです。
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# puppet apply ./site.pp --noop Error: Duplicate declaration: User[webUser] is already declared in file /vagrant/site.pp:17; cannot redeclare at /vagrant/site.pp:11 on node puppet.example.com Error: Duplicate declaration: User[webUser] is already declared in file /vagrant/site.pp:17; cannot redeclare at /vagrant/site.pp:11 on node puppet.example.com
明らかな理由により、機能しません。 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# puppet apply ./site.pp --noop Notice: Compiled catalog for puppet.example.com in environment production in 0.07 seconds Notice: /Stage[main]/users/User[webUser]/ensure: current_value absent, should be present (noop) Notice: Class[users]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.02 seconds
キャッシュを保存するフォルダに新しいユーザー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# puppet apply ./site.pp Notice: Compiled catalog for puppet.example.com in environment production in 0.07 seconds Notice: Finished catalog run in 0.02 seconds
予想どおり、ユーザーは追加されませんでした。
ただし、注意が必要です。 仮想リソースがディレクトリに追加されないという事実にもかかわらず、これは次のコードが機能することを意味しません。
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 { # Declare: @@sshkey { $hostname: type => dsa, key => $sshdsakey, } # Collect: Sshkey <<| |>> }
この例では、仮想リソースsshkeyを定義しました。 コレクターオペレーター<< | | >>は空のボディを含むため、 Sshkeyクラスのエクスポートされたすべてのオブジェクトをアンロードします。 したがって、sshクラスが接続されているマニフェスト内のエージェントは、公開キー（ @@ sshkey ）をエクスポートしてから、他のエージェントによって追加されたすべてのキーを自身にインポートします（ Sshkey << | | >> ）。
エクスポートされたリソースは、PuppetLabsのデータベースであるPuppetDBに保存されます。 PuppetDBに接続した後、pupetマスターによってコピーされた各ディレクトリはPuppetDBデータベースに配置され、PuppetDBデータベースはディレクトリを検索するための検索インターフェイスを提供します。
@@を指定することにより、リソースをエクスポート可能としてマークし、リソースをディレクトリに追加し、 エクスポートされたラベルをそのディレクトリに配置する必要があることをpuppetに通知します。 パペットマスターが演算子を見るとき<< | | >> 、 PuppetDBに対して検索クエリを作成し、検索条件に一致するすべての見つかったエクスポート済みリソースを追加します。
エクスポートされたリソースはグローバルスコープ内にあることが重要であるため、それらの名前は一意でなければなりません。
この機能には大きな可能性があり、頻繁に使用する必要があります。 サーバーを監視またはnginxバックエンドに追加する自動化。
既存のモジュールを使用することをお勧めしますが、原則を示すには、この例が適しています。
# "server IP:PORT;" upstream nginx class nginx::backend($ip = $::ipaddress, $port = 8080) { @@concat::fragment { "$::fqdn" : content => "server $ip:$port;", tag => 'nginx-backend', target => '/etc/nginx/conf.d/backend.conf' } } # , concat, nginx::backend class nginx::frontend { concat { '/etc/nginx/backend.conf' : ensure => present, force => true, ensure_newline => true } ~> Class['::nginx::service'] concat::fragment { 'upstream_header': content => 'upstream backend { ', order => '01', target => '/etc/nginx/backend.conf', } concat::fragment { 'upstream_footer' : content => '}', order => '03', target => '/etc/nginx/backend.conf' } # Concat::Fragment <<| tag == 'nginx-backend' |>> { target => '/etc/nginx/backend.conf', order => '02' } } class nginx::install { package { 'nginx' : ensure => present } } class nginx::service { service { 'nginx' : ensure => running, require => Class['nginx::install'] } } class nginx { class { 'nginx::install' : } -> class { 'nginx::service': } } node 'back1.example.com' { class { 'nginx' : } class { 'nginx::backend' : port => 8083 } } node 'back2.example.com' { class { 'nginx' : } class { 'nginx::backend' : port => 8084 } } node 'front1.example.com' { class { 'nginx' : } class { 'nginx:::frontend' : } }
構文および使用パターンの詳細については、次のリンクを参照してください。