Puppet は、以下のワークフローを使用して設定をシステムに適用します。

Red Hat Satellite 6 では、Puppet は複数の方法で使用します。

これらの機能は、Puppet を使用してアプリケーションライフサイクルのシステム設定を簡単に制御する方法を提供します。

必要に応じて、お使いの Satellite 環境で使用される Puppet のバージョンを確認するには、『パッケージマニフェスト』を参照してください。

Satellite 6 における Puppet のパフォーマンスは、アプリケーションの制限よりも Satellite および Capsule のストレージ容量、CPU パフォーマンス、および利用可能なメモリーの影響を受けます。したがって、ハードウェアと設定のテストは、パフォーマンスがニーズに合っているかどうかを確かめる唯一の方法となります。

推奨されるストレージ要件およびシステム要件の詳細は、『 オンラインネットワークからの Satellite Server の インストール』の「インストールのための環境準備 」を 参照してください。

モジュールを作成する前に、Puppet モジュールを作成するコンポーネントを理解する必要があります。

Puppet 開発システムは、独自のモジュールを作成およびテストする際に役立ちます。

新規モジュール作成の最初の手順は、Puppet モジュールディレクトリーに切り替え、基本的なモジュール構造を作成することです。この構造を手動で作成するか、Puppet を使用してモジュール用のボイラープレートを作成します。

# cd /etc/puppetlabs/code/modules
# puppet module generate user_name-module_name

インタラクティブなウィザードが表示され、メタデータでのモジュールの metadata.json ファイルの入力方法を説明します。

モジュールの生成プロセスが完了すると、新しいモジュールには manifests ディレクトリーを含む一部の基本ファイルが含まれます。このディレクトリーには、モジュールのメインマニフェストファイルである init.pp というマニフェストファイルがすでに含まれています。ファイルを表示して、モジュールの空のクラス宣言を表示します。

class mymodule {


}

モジュールには、同じく init.pp という名前のマニフェストを含む examples ディレクトリーも含まれています。このテストマニフェストには、manifests/init.pp 内の mymodule クラスへの参照が含まれます。

include::mymodule

Puppet はこのテストマニフェストを使用してモジュールをテストします。

これで、システム設定をモジュールに追加する準備ができました。

Puppet モジュールは、HTTP サーバーの実行に必要なパッケージをインストールします。これには、httpd パッケージの設定を定義するリソース定義が必要です。

モジュールの manifests ディレクトリーに、httpd.pp という名前の新規のマニフェストファイルを作成します。

# touch mymodule/manifests/httpd.pp

このマニフェストには、モジュールのすべての HTTP 設定が含まれます。組織上の理由から、このマニフェストを init.pp マニフェストから分離します。

以下の内容を新しい httpd.pp マニフェスト追加します。

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
}

このコードは、httpd と呼ばれる mymodule のサブクラスを定義し、続いて httpd パッケージのパッケージリソース宣言を定義します。ensure ⇒ installed 属性は、パッケージがインストールされているかどうかを確認するよう Puppet に指示します。インストールされていない場合には、Puppet は yum を実行してパッケージをインストールします。

また、メインのマニフェストファイルにこのサブクラスを含める必要があります。init.pp マニフェストを編集します。

class mymodule {
  include mymodule::httpd
}

ここで、モジュールをテストします。以下のコマンドを実行します。

# puppet apply mymodule/examples/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop)
...

この出力通知メッセージは、ensure ⇒ installed 属性の結果です。current_value absent は、httpd パッケージがインストールされていないことを Puppet が検出したことを意味します。--noop オプションを指定しないと、Puppet は httpd パッケージをインストールします。

puppet apply コマンドは、マニフェスト内の設定をシステムに適用します。メインの init.pp マニフェストを参照するテスト init.pp マニフェストを使用します。--noop は、設定のドライランを実行します。これは出力のみを表示しますが、実際には設定を適用しません。

httpd パッケージのインストール後に、別のリソース宣言 service を使用してサービスを起動します。

httpd.pp マニフェストを編集し、強調表示されている行を追加します。

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
}

これにより、以下の操作が実行されます。

puppet apply コマンドを再度実行して、モジュールへの変更をテストします。

# puppet apply mymodule/tests/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop)
...

この出力通知メッセージは、httpd サービスに対する新しいリソース定義の結果です。

HTTP サーバーがインストールされ、有効化されました。次のステップでは、設定を指定します。HTTP サーバーは、ポート 80 に Web サーバーを提供する /etc/httpd/conf/httpd.conf にデフォルト設定をすでにいくつか提供しています。ユーザー指定のポートに追加の Web サーバーを提供するために、設定を追加します。

ユーザー定義のポートには変数入力が必要なため、テンプレートファイルを使用して設定内容を保存します。モジュールで、templates という名前のディレクトリーを作成し、新しいディレクトリーに myserver.conf.erb という名前のファイルを追加します。ファイルに以下のコンテンツを追加します。

Listen <%= @httpd_port %>
NameVirtualHost *:<%= @httpd_port %>
<VirtualHost *:<%= @httpd_port %>>
  DocumentRoot /var/www/myserver/
  ServerName <%= @fqdn %>
  <Directory "/var/www/myserver/">
    Options All Indexes FollowSymLinks
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

このテンプレートは、Apache Web サーバー設定の標準構文に従います。唯一の相違点は、モジュールから変数を注入する際に Ruby のエスケープ文字が含まれる点です。たとえば、Web サーバーポートを指定するために使用する httpd_port などがあります。

fqdn が追加されている点にも注意してください。これは、システムの完全修飾ドメイン名を保存する変数です。これは、システムファクトとして知られています。システムファクトは、各該当システムの Puppet カタログを生成する前に各システムから収集します。Puppet は facter コマンドを使用して、これらのシステムファクトを収集します。また、facter を実行してこれらのファクトのリストを表示することもできます。

httpd.pp マニフェストを編集し、強調表示されている行を追加します。

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
  file {'/etc/httpd/conf.d/myserver.conf':
  notify => Service["httpd"],
    ensure => file,
    require => Package["httpd"],
    content => template("mymodule/myserver.conf.erb"),
  }
  file { "/var/www/myserver":
    ensure => "directory",
  }
}

これにより、以下の操作が実行されます。

また、メインのマニフェストファイルに httpd_port パラメーターを含める必要があります。init.pp マニフェストを編集し、以下の太字のテキストを追加します。

class mymodule (
  $httpd_port = 8120
) {
  include mymodule::httpd
}

これにより、httpd_port パラメーターをデフォルト値 8120 に設定します。この値は Satellite Server で上書きできます。

puppet apply コマンドを再度実行して、モジュールへの変更をテストします。

# puppet apply mymodule/tests/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/File[/var/www/myserver]/ensure: current_value absent, should be directory (noop)
...
Notice: /Stage[main]/Mymodule::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensure: current_value absent, should be file (noop)
...

これらの出力通知メッセージでは、設定ファイルと Web サーバーディレクトリーの作成が表示されます。

ユーザーが、Web サーバーでホストされるページにアクセスできるように、Web サーバーにはオープンポートが必要です。問題は、Red Hat Enterprise Linux のバージョンによってファイアウォールの制御方法が異なることです。Red Hat Enterprise Linux 6 以前では、iptables を使用します。Red Hat Enterprise Linux 7 では、firewalld を使用します。

この決定は、条件付きロジックとシステムファクトを使用して Puppet が処理するものです。この手順では、オペレーティングシステムを確認し、適切なファイアウォールコマンドを実行するステートメントを追加します。

mymodule::httpd クラス内に以下のコードを追加します。

  if versioncmp($::operatingsystemmajrelease, '6') <= 0 {
    exec { 'iptables':
      command => "iptables -I INPUT 1 -p tcp -m multiport --ports ${httpd_port} -m comment --comment 'Custom HTTP Web Host' -j ACCEPT &amp;&amp; iptables-save > /etc/sysconfig/iptables",
      path => "/sbin",
      refreshonly => true,
      subscribe => Package['httpd'],
    }
    service { 'iptables':
      ensure => running,
      enable => true,
      hasrestart => true,
      subscribe => Exec['iptables'],
    }
  }
  elsif $operatingsystemmajrelease == 7 {
    exec { 'firewall-cmd':
      command => "firewall-cmd --zone=public --add-port=${httpd_port}/tcp --permanent",
      path => "/usr/bin/",
      refreshonly => true,
      subscribe => Package['httpd'],
    }
    service { 'firewalld':
      ensure => running,
      enable => true,
      hasrestart => true,
      subscribe => Exec['firewall-cmd'],
    }
  }

このコードは、以下を実行します。

puppet apply コマンドを再度実行して、モジュールへの変更をテストします。以下の例では、Red Hat Enterprise Linux 6 をテストしています。

# puppet apply mymodule/tests/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/Exec[iptables]/returns: current_value notrun, should be 0 (noop)
...
Notice: /Stage[main]/Mymodule::Httpd/Service[iptables]: Would have triggered 'refresh' from 1 events
...

これらの出力通知メッセージには、subscribe 属性の結果としてのファイアウォールルール作成の実行とそれに続くサービスの更新が表示されます。

SELinux は、デフォルトで HTTP サーバーへの標準以外のアクセスを制限します。カスタムポートを定義する場合は、SELinux がアクセスを付与できる設定を追加する必要があります。

Puppet には、ブール値やモジュールなどの一部の SELinux 機能を管理するリソースタイプが含まれます。ただし、semanage コマンドを実行してポート設定を管理する必要があります。このツールは policycoreutils-python パッケージの一部で、Red Hat Enterprise Linux システムにはデフォルトではインストールされていません。

mymodule::httpd クラス内に以下のコードを追加します。

  exec { 'semanage-port':
    command => "semanage port -a -t http_port_t -p tcp ${httpd_port}",
    path => "/usr/sbin",
    require => Package['policycoreutils-python'],
    before => Service['httpd'],
    subscribe => Package['httpd'],
    refreshonly => true,
  }
  package { 'policycoreutils-python':
    ensure => installed,
  }

このコードは、以下を実行します。

puppet apply コマンドを再度実行して、モジュールへの変更をテストします。

# puppet apply mymodule/tests/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/Package[policycoreutils-python]/ensure: current_value absent, should be present (noop)
...
Notice: /Stage[main]/Mymodule::Httpd/Exec[semanage-port]/returns: current_value notrun, should be 0 (noop)
...
Notice: /Stage[main]/Mymodule::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop)
...

Puppet は、最初に policycoreutils-python をインストールしてから、httpd サービスを起動する前にポートアクセスを設定します。

これで、HTTP サーバー設定が完了しました。これにより、Web ベースのアプリケーションをインストールするプラットフォームが提供され、Puppet も設定することができます。ただし、この例では、簡単なインデックス Web ページのみを Web サーバーにコピーします。

files ディレクトリーに index.html という名前のファイルを作成します。以下の内容をファイルに追加します。

<html>
  <head>
    <title>Congratulations</title>
  <head>
  <body>
    <h1>Congratulations</h1>
    <p>Your puppet module has correctly applied your configuration.</p>
  </body>
</html>

manifests ディレクトリーに app.pp という名前のマニフェストを作成します。以下の内容をファイルに追加します。

class mymodule::app {
  file { "/var/www/myserver/index.html":
    ensure => file,
    mode   => '755',
    owner  => root,
    group  => root,
    source => "puppet:///modules/mymodule/index.html",
    require => Class["mymodule::httpd"],
  }
}

この新しいクラスには、単一のリソース宣言が含まれます。この宣言は、モジュールのファイルディレクトリのファイルを、Puppet Serverからシステムにコピーし、そのパーミッションを設定します。さらに、require 属性は mymodule::httpd クラスが、mymodule::app を適用する前に設定を正常に完了させます。

最後に、メインの init.pp マニフェストにこの新しいマニフェストを追加します。

class mymodule (
  $httpd_port = 8120
) {
  include mymodule::httpd
  include mymodule::app
}

puppet apply コマンドを再度実行して、モジュールへの変更をテストします。出力は以下のようになります。

# puppet apply mymodule/tests/init.pp --noop
....
Notice: /Stage[main]/Mymodule::App/File[/var/www/myserver/index.html]/ensure: current_value absent, should be file (noop)
...

この出力通知メッセージは、index.html ファイルが Web サーバーにコピーされることを示しています。

モジュールの使用準備が整いました。モジュールを Red Hat Satellite 6 が使用するアーカイブにエクスポートするには、以下のコマンドを入力します。

# puppet module build mymodule

これにより、mymodule ディレクトリーの内容が含まれる mymodule/pkg/mymodule-0.1.0.tar.gz にアーカイブファイルが作成されます。このモジュールを Red Hat Satellite 6 Server にアップロードし、独自の HTTP サーバーをプロビジョニングします。

変更が必要な場合は、puppet module build コマンドを使用して、モジュールディレクトリーのファイルを編集し、モジュールを再構築します。この変更は、モジュールのバージョンが増加する場合にのみ Satellite に反映されます。バージョン番号を増やすには、/etc/puppetlabs/code/modules/mymodule/metadata.json ファイルを編集し、モジュールを再ビルドします。Satellite Server で新しいバージョンをアップロードして公開します。

Puppet モジュールを追加する最初の手順は、カスタム製品を作成することです。

カスタム製品の作成

# hammer product create \
--name "MyProduct" \
--organization "Default Organization"

次の手順では、カスタム製品に Puppet リポジトリーを作成します。

カスタム Puppet リポジトリーの作成

# hammer repository create \
--organization "Default Organization" \
--product "MyProduct" \
--name "MyRepo" \
--content-type puppet

次に、mymodule モジュールを新たに作成されたリポジトリーにアップロードし、カスタムの Product に追加します。

このリポジトリーに他のモジュールをアップロードすることができます。この例では、mymodule モジュールをアップロードすることのみが必要になります。

# hammer repository upload-content \
--organization "Default Organization" \
--product "MyProduct" \
--name "MyRepo" \
--path path_to_the_module

今後カスタムリポジトリーから冗長モジュールを削除する場合は、Puppet モジュールの管理 機能を使用します。

# hammer repository remove-content \
--organization "Default Organization" \
--product "MyProduct" \
--name "MyRepo" \
--ids array of content IDs to remove

モジュールを手動でアップロードする代わりに、Red Hat Satellite 6 には pulp-puppet-module-builder と呼ばれるユーティリティーが含まれています。このツールは、モジュールのセットが含まれるリポジトリーを確認し、モジュールをビルドし、それらを Satellite 6 が同期する構造で公開します。これにより、Git でモジュール開発を管理する効率的な方法が提供され、Satellite 6 ワークフローに追加されます。

Modulefile の使用は、Puppet バージョン 3 以降は非推奨となりました。Puppet バージョン 3.X の使用時に Modulefile を含む Puppet モジュールをビルドすると、非推奨の警告が表示されます。Satellite 6.7 には、モジュールファイルデータを無視する Puppet バージョン 4 が含まれます。Modulefile のデータは metadata.json ファイルに移動する必要があります。以下のように metadata.json ファイルを使用するようにモジュールを変換することができます。

一般的な方法の 1 つは、Satellite 6 Server 自体でユーティリティーを実行し、ローカルディレクトリーに公開することです。

Git リポジトリーのローカルディレクトリーへの公開

HTTP サーバーにモジュールを公開する場合も同様です。

Web サーバーへの Git リポジトリーの公開

Satellite 6 Web UI で、URL が公開されたモジュールの場所に設定した新規リポジトリーを作成します。

Git からの Puppet モジュールのリポジトリーの作成

Git リポジトリーの Puppet モジュールが Satellite 6 Server に含まれているようになりました。

Puppet モジュールの使用準備できた最後の手順は、コンテンツビューの一部として公開することです。このモジュールを既存のビューに追加できますが、この例では新しいビューを作成します。

コンテンツビューの公開

これで、コンテンツビューが公開されました。コンテンツビューの作成の一環として、Red Hat Satellite 6 は、プロビジョニングプロセスで使用する新規の Puppet 環境を作成します。この Puppet 環境にはモジュールが含まれます。この新規の Puppet 環境は、設定 > 環境 ページで表示できます。

Puppet 環境は、特定の Puppet モジュールのセットに関連付けることができる Puppet エージェントノードの単独のセットとして定義されます。Satellite 6 のコンテキストでは、Puppet 環境は、特定の Puppet モジュールセットに関連付けられる Puppet エージェントを実行しているホストセットと考えることができます。たとえば、実稼働 環境に関連付けられているノードは、実稼働 環境にあるモジュールにのみアクセスできます。

Puppet 環境は、さまざまなタイプのホストから Puppet モジュールを分離するために使用されます。典型的な使用方法は、別の環境にプッシュされる前に、モジュールへの変更を 1 つの環境でテストできるようにすることです。Puppet モジュールには、ファクトと関数のほか、ホストに割り当てることができる 1 つ以上の Puppet クラスを含めることができます。モジュールは環境の一部であり、Puppet クラスはモジュールの一部であることから環境の一部となります。

Red Hat Satellite では、CV に Puppet モジュールがある場合は、コンテンツビュー用に Puppet 環境が自動的に作成されます。自動的に作成される Puppet 環境名には、組織ラベル、ライフサイクル環境、コンテンツビュー名、コンテンツビュー ID が含まれます。例: KT_Example_Org_Library_RHEL6Server_3

Red Hat Satellite 内での Puppet 環境の作成

環境が Puppet マスターに存在せず、その後にインポートを実行すると、Satellite は環境を削除するように求める点に留意してください。

Red Hat Satellite への Puppet 環境のインポート

Satellite は、Puppet マスターに含まれる環境および Puppet モジュールをすべて検出し、自動的にインポートすることができます。これを行うには、設定 > 環境 に移動して、インポート元 ボタンをクリックします。ボタン名には、内部または外部の Capsule の FQDN が含まれます。Satellite は、Capsule から Puppet マスターをスキャンし、検出された変更の一覧を表示します。適用する変更を選択し、更新 を選択して変更を適用します。

Capsule は、Puppet クラスが 1 つ以上含まれる環境のみを検出する点に留意してください。したがって、少なくとも 1 つのクラスを含む 1 つの Puppet モジュールが Puppet マスターにデプロイされていることを確認してください。

ホストへの Puppet 環境の割り当て

ホスト > すべてのホスト に移動し、ホスト リストから名前でホストを選択してから 編集 を選択します。ホスト タブで、ホストの Puppet 環境 を選択できます。環境を選択すると、Puppet クラス タブでクラスが絞り込まれ、選択した環境のクラスが区別できるようになります。

ホストのグループに環境を大量に割り当てることができます。ホスト 一覧で必要なホストのチェックボックスを選択して、ページの上部にある Select Action ドロップダウンメニューから Change Environment を選択します。

ホストグループへの Puppet 環境の割り当て

ホストグループを作成するとき、環境フィールドには、関連付けられたコンテンツビュー（存在する場合）によって自動的に作成された環境が事前に入力されています。

デフォルトでは、新規ホストを作成してHost Groupを選択すると、環境が自動的に事前に選択されます。ユーザーは、新規ホストの環境を変更することができます。

Red Hat Satellite パラメーターは、ホストのプロビジョニング時に使用するキーと値のペアを定義します。これらは、Puppet のデフォルトのスコープパラメーターの概念に似ています。Puppet でホストを設定する際にパラメーターを定義することができます。

以下のパラメーター階層は単純なパラメーターに対して適用されます。

設定したパラメーターは各ホストの対応する YAML ファイルに含まれ、Puppet マスターに送信されます。YAML ファイルは、特定のホストのページにある Web UI で表示できます。/etc/foreman/settings.yaml 設定ファイルは、次に satellite-installer コマンドを実行する際に上書きされるため、手動で変更しないでください。

以下の手順では、クラス内でパラメーターを設定します。パラメーターが含まれるクラスは、パラメーター化されたクラスと呼ばれます。

スマートクラスパラメーターは、すべての組織で共通しています。edit_external_parameters パーミッションを持つユーザーなら誰でも、これらのパラメーターを編集できます。スマートクラスパラメーターを編集するパーミッションを制限する場合は、KCS のソリューション記事「Restrict permissions to edit puppet classes and their smart class parameters which are common between multiple organizations」を参照してください。

スマートクラスパラメーターの設定

たとえば、Default_Location のロケーション内の任意のホストの Puppet マスターにパラメーターの test 値を指定するには、以下の手順を実行します。

たとえば、Default_Location のロケーションおよび開発環境内の任意のホストの Puppet マスターにパラメーターの test 値を指定するには、以下の手順を実行します。

親ホストグループを使用して、ファクトを複数のホストグループのメンバーに適用することができます。

以下は、Puppet Smart クラスパラメーター matcher で、複数のカスタムファクトを作成および使用する例です。

以下の手順では、Puppet クラスで値を上書きできるようにスマート編集を設定します。

スマート変数の設定

ERB 構文の詳細は、『 ホストの管理 』の「 テンプレート作成の参照 」を参照してください。

以下の手順では、Puppet マスターからパラメーター化されたクラスをインポートします。

パラメーター化されたクラスのインポート

スマート変数は、スマートクラスパラメーターを含まない Puppet クラスで使用するために、Puppet マスターにグローバルパラメーターを提供するツールです。同じスマートな Matcher ルールは、スマート変数とスマートクラスパラメーターの両方に使用されます。

スマートクラスパラメーターが導入される前は、グローバルパラメーターを使用するようにPuppetコードを書き直すように求められたパラメーターをオーバーライドしたいユーザー。以下は例になります。

class example1 {
  file { '/tmp/foo': content => $global_var }
}

上記の例では、$global_var は Web UI の スマート変数セクションで設定され、値は "example1" クラスに関連付けられます。Puppetがグローバルスコープを検索するのを制限するために、グローバル変数の前に::を付けることが推奨されますが、付けなくても、変数が非グローバル変数になるわけではありません。

スマートクラスパラメーターの導入により、以下の形式を使用できます。

class example2($var="default") {
  file { '/tmp/foo': content => $var }
}

上記の例では、$var は Web UI の Smart Class Parameters セクションで設定され、値は "example2" クラスに関連付けられます。上記の class example2($var="default") のように、クラスヘッダーで定義された変数が表示された場合は、$var がクラスパラメーターであることを確認できます。スマートクラスパラメーター関数を使用して、変数を上書きする必要があります。

示されているように、スマート変数には、Puppetコミュニティの標準モジュールではなく、global-namespace パラメーターを使用してカスタム設計されたモジュールが必要です。結果は同じです。上記の例では、テキストは '/tmp/foo' に置かれています。そのため、レガシーモジュールのサポート以外に、スマート変数を使用する理由がなくなりました。

スマート変数はグローバル変数ですが、Puppet クラスに関連付けられ、Satellite で特定の Puppet クラスが割り当てられたホストにのみ送信されます。任意の名前でスマート変数を作成できますが、検証は Satellite で行われませんが、関連する Puppet モジュールにコードに一致する変数がない場合は、スマート変数は使用されません。

Satellite は、Satellite で作成した変数をホスト YAML ファイルに追加します。このファイルは、Web UI で Hosts > All Hosts に移動して、ホスト名を選択してから YAML ボタンをクリックします。Satellite は、ホスト YAML ファイルを 外部ノードの分類子（ENC）（Puppet マスターに含まれる機能）に送信します。Puppet マスターがホストの ENC にクエリーを実行すると、ENC はホストの状態を記述する YAML ドキュメントを返します。この YAML ドキュメントは Puppet マニフェストから取得したデータに基づいていますが、スマートクラスパラメーターの上書きとスマート変数が適用されます。

class anothermodule {
   file { '/tmp/motd':
     ensure  => file,
     content => $::content_for_motd,
  }
}

この例では、$::content_for_motd パラメーターの値を指定します。

Puppet は通常、エージェント/マスター (クライアント/サーバーとしても知られる) アーキテクチャーで実行されます。ここで、Puppet サーバーは重要な設定情報を管理し、管理対象ホスト (クライアント) は独自の設定カタログのみを要求します。Puppet は 2 つの手順でホストを設定します。

エージェント/マスターの設定では、Puppet クライアントは Facter によって収集されるファクトや他の情報を Puppet マスターに送信します。Puppet マスターは、これらのファクトに基づいてカタログをコンパイルし、このカタログをクライアントに送信します。クライアントは変更したすべての変更のレポートを送信するか、--noop パラメーターを使用した場合は Puppet マスターに結果を送信し、その結果を Foreman に送信します。このカタログは、1 つの特定ホストの必要な状態を記述します。リソース間の依存関係を含む、そのホストで管理するリソースを一覧表示します。エージェントはカタログをホストに適用します。

マスターとエージェント間の通信は、デフォルトで 30 分ごとに実行されます。runinterval パラメーターを使用して、/etc/puppetlabs/puppet/puppet.conf ファイルに別の値を指定できます。puppet agent apply を実行し、通信を手動で開始することもできます。

Facter は Puppet のシステムインベントリーツールで、多くの組み込みファクトが含まれています。Facter は、ローカルホストのコマンドラインで実行して、ファクト名と値を表示できます。カスタムファクトで Facter を拡張し、これを使用してホストのサイト固有の詳細を Puppet マニフェストに公開することができます。Facter が提供するファクトを使用して、Puppet で条件式に通知することもできます。

Puppetは、リソースに基づいてシステム状態を判別します。たとえば、httpdサービスは常に実行している必要があり、Puppetはそれを処理する方法を知っていることをPuppetに伝えることができます。異なるオペレーティングシステムを管理する場合は、osfamily ファクトを使用して条件式を作成し、どのサービスを監視するか、どのパッケージをインストールするかを示すことができます。operatingsystemmajrelease パラメーターおよび versioncmp パラメーターを使用して、同じオペレーティングシステムの異なるバージョンに基づいて条件式を作成できます。以下の例は、Facts を使用した条件式の使用を示しています。

if $::osfamily == 'RedHat' {
  if $::operatingsystemmajrelease == '6' {
   $ntp_service_name = 'ntpd'
   }

  elseif versioncmp($::operatingsystemmajrelease, '7') >= 0 {
   $ntp_service_name = 'chrony'
   }
 }

また、Puppet は、ファクトが多く動作する他の特別な変数も設定します。詳細は、Special Variables Added by PuppetおよびCore Factsを参照してください。

Red Hat Satellite 6 は、全 Satellite Capsule 上の Puppet マスターの主な設定を制御します。追加の設定は不要であり、これらの設定ファイルを手動で変更しないようにすることが推奨されます。たとえば、メインの /etc/puppetlabs/puppet/puppet.conf 設定ファイルには、以下の [master] セクションが含まれます。

[master]
    autosign       = $confdir/autosign.conf { mode = 664 }
    reports        = foreman
    external_nodes = /etc/puppetlabs/code/node.rb
    node_terminus  = exec
    ca             = true
    ssldir         = /var/lib/puppet/ssl
    certname       = sat6.example.com
    strict_variables = false

    manifest       = /etc/puppetlabs/code/environments/$environment/manifests/site.pp
    modulepath     = /etc/puppetlabs/code/environments/$environment/modules
    config_version =

このセクションには、さまざまな環境の設定の作成に Satellite 6 が使用する変数（$environmentなど）が含まれます。

一部の Puppet 設定オプションが Satellite 6 Web UI に表示されます。Administer > Settings に移動して、Puppet サブタブを選択します。このページには、Puppet 設定オプションのセットと、それぞれの説明が記載されています。

プロビジョニングプロセスの一環として、Satellite 6 は Puppet をシステムにインストールします。このプロセスでは、選択した Capsule 上の Puppet マスターのエージェントとして Puppet を設定するために /etc/puppetlabs/puppet/puppet.conf ファイルもインストールされます。この設定ファイルは、Satellite 6 のプロビジョニングテンプレートスニペットとして保存されます。Hosts > Provisioning templates に移動し、puppet.conf スニペットをクリックして表示します。

デフォルトの puppet.conf スニペットには、以下のエージェント設定が含まれます。

[agent]
pluginsync      = true
report          = true
ignoreschedules = true
daemon          = false
ca_server       = <%= @host.puppet_ca_server %>
certname        = <%= @host.certname %>
environment     = <%= @host.environment %>
server          = <%= @host.puppetmaster %>

このスニペットには、テンプレート変数が含まれています。

まず、以下の手順で新規ホストの Puppet 設定を定義します。この手順では、サンプルとしてアップロードされた mymodule を使用します。

プロビジョニング時のクライアントへの設定の適用

プロビジョニングプロセスが開始されます。Satellite 6は、Satellite Kickstart Defaultプロビジョニングテンプレートの一部として必要な設定ツールをインストールします。このプロビジョニングテンプレートには、以下が含まれます。

<% if puppet_enabled %>
# and add the puppet package
yum -t -y -e 0 install puppet

echo "Configuring puppet"
cat > /etc/puppetlabs/puppet/puppet.conf << EOF
<%= snippet 'puppet.conf' %>
EOF

# Setup puppet to run on system reboot
/sbin/chkconfig --level 345 puppet on

/usr/bin/puppet agent --config /etc/puppetlabs/puppet/puppet.conf -o --tags no_such_tag <%= @host.puppetmaster.blank? ? '' : "--server #{@host.puppetmaster}" %> --no-daemonize
<% end -%>

本セクションでは、以下を実行します。

プロビジョニングプロセスと設定プロセスが新規ホストで完了したら、Web ブラウザーでユーザー定義のポートでホストにアクセスします。たとえば、http://newhost.example.com:8120/ に移動します。以下のメッセージがブラウザーに表示されるはずです。

Congratulations

Your puppet module has correctly applied your configuration.

Puppet 設定は、Red Hat Satellite 6 でプロビジョニングされていない既存のクライアントに適用されている可能性があります。このような場合には、Red Hat Satellite 6 に登録した後に、既存のクライアントに Puppet をインストールして設定します。

既存のシステムを Red Hat Satellite 6 に登録します。既存ホストの登録に関する情報は、『ホスト の管理』ガイドの 「ホストの登録 」を参照し てください。

Puppet エージェントをインストールし、有効にする方法:

Puppet エージェントの設定