Puppet ガイド

Red Hat Satellite 6.7

独自の Puppet モジュールを構築し、これを Red Hat Satellite 6 にインポートするためのガイド

Red Hat Satellite Documentation Team

概要

Puppet は、Red Hat Satellite 6 で使用されるシステム設定ツールです。本ガイドは、基本的な Puppet モジュールの作成と、Red Hat Satellite 6 インフラストラクチャーでのこのモジュールの使用方法について説明します。

第1章 概要

Puppet は、システム設定を適用および管理するためのツールです。Puppet は、システム情報またはファクトを収集し、この情報を使用してモジュールのセットを使用してカスタマイズされたシステム設定を作成します。これらのモジュールには、パラメーター、条件付き引数、アクション、テンプレートが含まれます。Puppet は、ローカルシステムコマンドラインツールまたはクライアントとサーバーの関係のいずれかとして使用されます。この場合、サーバーが Puppet マスターとして機能し、Puppet エージェントを使用して複数のクライアントシステムに設定が適用されます。これにより、新規プロビジョニングされたシステムを自動的に設定する方法(個別に、または同時に特定のインフラストラクチャーを作成することができます)。

1.1. Puppet ワークフローの定義

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

  1. 各システムに関するファクトを収集します。このようなファクトには、ハードウェア、オペレーティングシステム、パッケージバージョンなどの情報が含まれます。各システムの Puppet エージェントがこの情報を収集し、それを Puppet マスターに送信します。
  2. Puppet マスターは、各システムのカスタム設定を生成し、それを Puppet エージェントに送信します。このカスタム設定はカタログと呼ばれます。
  3. Puppet エージェントは、設定をシステムに適用します。
  4. Puppet エージェントは、該当する変更と変更が失敗した場合にレポートを Puppet マスターに返信します。
  5. サードパーティーアプリケーションは、Puppet の API を使用してこれらのレポートを収集できます。

1.2. Satellite 6 での Puppet の使用

Red Hat Satellite 6 では、いくつかの方法で Puppet を使用します。

  • Red Hat Satellite 6 は、システム設定の定義に使用する Puppet モジュールをインポートします。これには、モジュールバージョンとその環境の制御が含まれます。
  • Red Hat Satellite 6 は、Puppet モジュールからパラメーターセット(Puppet Smart Class パラメーターとも呼ばれる)をインポートします。ユーザーは、Puppet クラスからのデフォルト値を受け入れたり、グローバルレベルまたはシステム固有のレベルで独自の値を提供したりできます。
  • Red Hat Satellite 6 は、マスターと各システムのエージェント間で Puppet の実行をトリガーします。Puppet の実行は、以下のいずれかで発生する可能性があります。

    • プロビジョニングプロセスの完了後や、ライフサイクル全体でマシンの設定を確認して管理するデーモンとして自動的に行われます。
    • 管理者が即時 Puppet の実行をトリガーする必要がある場合など、手動で行う必要があります。
  • Satellite 6 は、設定ワークフローの完了後に Puppet からレポートを収集します。これは、長期におけるシステム設定の監査とアーカイブに役立ちます。

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

必要な場合は、「Satellite 環境で使用される Puppet のバージョンを確認するには、パッケージマニフェスト」を参照 してください

1.3. Satellite 6 での Puppet のパフォーマンスとスケーラビリティー

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

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

第2章 Scratch からの Puppet モジュールの構築

本章では、独自の Puppet モジュールを構築してテストする方法を説明します。これには、単純な Web サーバー設定をデプロイする Puppet モジュールの作成に関する基本的なチュートリアルが含まれます。

2.1. Puppet モジュールの分析の確認

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

Puppet マニフェスト

マニフェストと混同しないようにしてください(サブスクリプションマニフェスト)。Puppet マニフェストは、リソースセットとその属性を定義するコードが含まれるファイルです。リソースは、システムの設定可能な部分です。リソースの例には、パッケージ、サービス、ファイル、ユーザー、グループ、SELinux 設定、SSH キー認証、cron ジョブなどが含まれます。マニフェストは、属性のキーと値のペアのセットを使用して必要な各リソースを定義します。例を示します。

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

この宣言は、httpd パッケージがインストールされているかどうかを確認します。そうでない場合には、マニフェストは yum を実行してインストールします。

コンパイルの開始に使用する Puppet マニフェストは、「main manifest」または「サイトマニフェスト」と呼ばれます。

マニフェストは、モジュールの manifest ディレクトリーにあります。

また Puppet モジュールは、テストマニフェストの テスト ディレクトリーを使用します。これらのマニフェストは、公式マニフェストに含まれる特定のクラスをテストするために使用されます。

静的ファイル

モジュールには、システムの特定の場所に Puppet がコピーできる静的ファイルを含めることができます。これらの場所や、パーミッションなどのその他の属性は、マニフェストの ファイル リソース宣言で定義されます。

静的ファイルは、モジュールの files ディレクトリーに配置されています。

テンプレート

設定ファイルにはカスタムの内容が必要な場合があります。このような場合、ユーザーは静的ファイルの代わりにテンプレートを作成します。静的ファイルと同様に、テンプレートはマニフェストで定義され、システム上の場所にコピーされます。違いは、テンプレートでは Ruby 表現でカスタマイズされたコンテンツや変数入力を定義することができる点です。たとえば、カスタマイズ可能なポートで httpd を設定する場合は、設定ファイルのテンプレートには以下が含まれます。

Listen <%= @httpd_port %>

この場合、httpd_port 変数はこのテンプレートを参照するマニフェストに定義されています。

テンプレートは、モジュールの templates ディレクトリーにあります。

プラグイン

プラグインにより、Puppet のコア機能を超えて機能を拡張することができます。プラグインを使用して、カスタムファクト、カスタムリソース、または新機能を定義できます。たとえば、データベース管理者が PostgreSQL データベースのリソースタイプを必要とする場合があります。これにより、データベース管理者は PostgreSQL のインストール後に新規データベースセットで PostgreSQL にデータを設定するのに役立ちます。そのため、データベース管理者は、PostgreSQL のインストールとデータベース作成を確実に行う Puppet マニフェストのみを作成する必要があります。

プラグインは、モジュールの lib ディレクトリーにあります。これには、プラグインタイプに応じたサブディレクトリーセットが含まれます。例を示します。

  • /lib/facter: カスタムファクトの場所
  • /lib/puppet/type: 属性のキーと値のペアを記述するカスタムリソース種別の定義の場所
  • /lib/puppet/provider: リソースを制御するためのリソース種別の定義と併用するカスタムリソースプロバイダーの場所
  • /lib/puppet/parser/functions: カスタム関数の場所

2.2. Puppet 開発システムの設定

Puppet の開発システムは、独自のモジュールを作成およびテストするのに便利です。

手順

以下の手順に従って、新しい Puppet 開発システムをデプロイします。

  1. 新しい Red Hat Enterprise Linux 7 システムをデプロイし、システムを Red Hat CDN または Satellite Server に登録します。
  2. Red Hat Satellite Tools 6 リポジトリーが有効になっている必要があります。

    # subscription-manager repos \
    --enable=rhel-7-server-satellite-tools-6.7-rpms
  3. Puppet エージェントをインストールします。

    # yum install puppet

2.3. 新規モジュールのボタイプ生成

新規モジュール作成の最初の手順は、Puppet モジュールディレクトリーに移動し、基本的なモジュール構造を作成することです。この構造を手作業で作成するか、Puppet を使用してモジュール用の定型テンプレートを作成します。

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

インタラクティブなウィザードが表示され、モジュールの metadata .json ファイルをメタデータ で設定することができます。

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

class mymodule {


}

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

include::mymodule

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

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

2.4. HTTP サーバーのインストール

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

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

# touch mymodule/manifests/httpd.pp

このマニフェストには、モジュールの HTTP 設定がすべて含まれます。組織上の目的上、このマニフェストは init.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 がない場合は、httpd パッケージがインストールされていないことを Puppet が検出したことを意味 します。--noop オプションを指定しないと、Puppet は httpd パッケージをインストールします。

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

2.5. HTTP サーバーの実行

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

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

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

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

  • ensure ⇒ running 属性は、サービスが実行しているかどうかを確認します。そうでない場合は、Puppet が起動します。
  • enable ⇒ true 属性は、システムの起動時にサービスが実行されるように設定します。
  • require ⇒ Package["httpd"] 属性は、リソース宣言同士の順序関係を定義します。この場合、httpd サービスが 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 サービスの新しいリソース定義の結果です。

2.6. Hammer CLI の設定

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",
  }
}

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

  • サーバー設定ファイル /etc/httpd/conf.d/myserver.conf のファイルリソース宣言を追加します。
  • notify ⇒ Service["httpd"] 属性を使用して、設定ファイルと httpd サービスの間の関係を追加します。これにより、設定ファイルの変更の有無がチェックされます。ファイルが変更された場合には、Puppet によりサービスが再起動されます。
  • このファイルを追加する前に、httpd パッケージがインストールされていることを確認します。
  • この /etc/httpd/conf.d/myserver.conf ファイルの 内容 は、以前に作成した myserver.conf.erb テンプレートです。
  • 2 番目のファイルリソース宣言を追加します。これにより、Web サーバーのディレクトリー /var/www/myserver/ が作成されます。

また、メインのマニフェストファイルに 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 サーバーディレクトリーの作成が表示されます。

2.7. ファイアウォールの設定

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

この決定は、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'],
    }
  }

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

  • オペレーティングシステムが Red Hat Enterprise Linux 6 または 7 であるかを確認するには、operatingsystemmajrelease ファクト を使用します。
  • Red Hat Enterprise Linux 6 を使用している場合は、iptables および iptables -save を実行する実行ファイル(exec)リソースを宣言して、永続的なファイアウォールルールを追加します。httpd_port 変数は、開こうとするポートを定義するためにインラインで使用されます。exec リソースが完了すると、iptables サービスの更新がトリガーされます。これを行うには、subscribe 属性が含まれるサービスリソースを定義します。この属性は、別のリソースに何らかの変更があるかどうかを確認し、存在する場合は更新を実行します。この場合、iptables の実行可能なリソースを確認します。
  • Red Hat Enterprise Linux 7 を使用している場合は、firewall-cmd を実行して永続的なファイアウォールルール を追加する同様の実行リソースを宣言します。httpd_port 変数もインラインで使用して、開くポートを定義します。exec リソースが完了すると、firewalld サービスの更新をトリガーしますが、firewall-cmd 実行可能なリソースを参照する subscribe 属性を使用します。
  • ファイアウォールの実行可能なリソースには 、refreshonly ⇒ truesubscribe ⇒ Package['httpd'] 属性が含まれます。これにより、ファイアウォールコマンドは、httpd のインストール後にのみ実行されるようになります。これらの属性がないと、後続の実行により、同じファイアウォールルールのインスタンスを複数追加します。

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

# 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
...

この出力通知メッセージには、subscription 属性の結果としてファイアウォールルールの作成と後続のサービスのリフレッシュが表示さ ます。

重要

この設定は、条件付きステートメントの使用例としてのみ機能します。今後、システムに複数のファイアウォールルールを管理する予定の場合は、ファイアウォール用のカスタムリソースを作成することが推奨されます。多くの Bash コマンドを常にチェーンする実行可能なリソースを使用することは推奨されません。

2.8. SELinux の設定

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,
  }

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

  • require ⇒ Package['policycoreutils-python'] 属性は、コマンドを実行する前に policycoreutils-python をインストールするようにします。
  • Puppet は semanage を実行し、httpd_port を変数として使用し、Apache がリッスンできる TCP ポートの一覧にカスタムポートを追加します。
  • ⇒ Service ['httpd'] は、httpd サービスを起動する前にこのコマンドを必ず実行します。httpd が SELinux コマンドを起動すると、SELinux はポートへのアクセスを拒否し、サービスが起動しなくなります。
  • SELinux 実行リソースのコードには、refreshonly ⇒ true および subscribe ⇒ Package['httpd'] 属性が含まれます。これにより、SELinux コマンドは、httpd のインストール後にのみ実行されるようになります。これらの属性がないと、後続の実行に失敗します。これは、SELinux がポートが有効であることを検知し、エラーを報告するためです。

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 サービスを起動する前にポートアクセスが設定されます。

2.9. Web ホストへの HTML ファイルのコピー

これで、HTTP サーバーの設定が完了しました。これにより、Puppet が設定する Web ベースのアプリケーションをインストールするプラットフォームを利用できます。この例では、簡単なインデックス 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:: app を適用する前に、mymodule::httpd クラスが正常に設定を完了するようにします

最後に、この新しいマニフェストをメインの 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 サーバーにコピーされることを示しています。

2.10. モジュールの最終処理

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

# puppet module build mymodule

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

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

第3章 Red Hat Satellite 6 への Puppet モジュールの追加

Puppet モジュールは、Red Hat Satellite 6 の Satellite 製品の一部を形成します。つまり、カスタムの Product を作成し、その製品の基礎を形成するモジュールをアップロードする必要があります。たとえば、カスタム製品は、HTTP サーバー、データベース、およびカスタムアプリケーションをセットアップするために必要な Puppet モジュールセットで構成されます。カスタム製品には、アプリケーションに適用される RPM パッケージを含むリポジトリーを含めることもできます。

3.1. カスタム製品の作成

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

カスタム製品の作成

  1. Red Hat Satellite 6 Server の管理
  2. Content > Products の順 に移動します。
  3. Create Product を クリックします。
  4. カスタム製品に Name を提供します。この例では、MyProduct を名前として使用します。
  5. Label フィールドは、名前に基づいて自動的にラベルが入力され ます
  6. 必要に応じて GPG キー同期計画、および 説明 を指定します。この例では、これらのフィールドを空白のままにします。
  7. 「Save」をクリックします。

CLI をご利用の場合

以下のコマンドを使用してカスタムの製品を作成します。

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

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

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

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

  1. Products ページで、前のステップで作成したカスタム製品(MyProduct)をクリックします。
  2. Repositories サブタブに移動します。
  3. では、「New Repository」をクリックします。
  4. Name でリポジトリーを指定します。この例では、MyRepo という名前を使用 ます。
  5. Label フィールドは、名前に基づいて自動的にラベルが入力され ます
  6. puppet をリポジトリーの Type として選択します。
  7. URL フィールドを空白のままにします。このフィールドはリモートリポジトリーに使用されますが、Satellite 6 では独自のリポジトリーが作成されます。
  8. 「Save」をクリックします。

CLI をご利用の場合

カスタム製品に Puppet リポジトリーを作成するには、以下のコマンドを入力します。

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

3.3. Puppet モジュールをリポジトリーにアップロードするには、以下を実行します。

これで、mymodule モジュールを新規作成したリポジトリーにアップロードし、カスタム製品に追加します。

  1. 新規作成されたリポジトリーの 名前 をクリックします。
  2. Puppet モジュールのアップロードセクション で、Browse をクリックし、mymodule アーカイブを選択します。
  3. アップロード をクリックします。

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

CLI をご利用の場合

Puppet モジュールをコンテンツビューに追加するには、以下のコマンドを実行します。

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

3.4. リポジトリーからの Puppet モジュールの削除

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

  1. Products ページで、削除するモジュールが含まれるカスタム製品をクリックします。
  2. 削除するモジュールが含まれるリポジトリーの 名前 をクリックします。
  3. puppet モジュールを表示および管理します。画面には、リポジトリーに含まれる Puppet モジュールの一覧が表示されます。
  4. 削除するモジュールを選択します。
  5. Remove Puppet Modules を クリックします。

CLI をご利用の場合

リポジトリーからテンプレートをインポートするには、以下のコマンドを実行します。

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

3.5. Git リポジトリーからの Puppet Modules の同期

モジュールを手動でアップロードする代わりに、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. puppet モジュールビルド Module _Directory を一度実行します。
  2. Modulefile を削除します。
  3. リビジョン制御リポジトリーで更新された metadata.json ファイルを確認します。
注記

pulp-puppet-tools パッケージを使用して、別のマシンに pulp-puppet-module- builder ツールをインストールすることもできます。

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

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

  1. Satellite Server 上にディレクトリーを作成して、モジュールを同期します。

    # mkdir /var/www/puppet-modules
    # chmod 755 /var/www/puppet-modules

    /var/www/ ディレクトリーにモジュールを保存します。それ以外の場合は、SELinux はリポジトリーの同期をブロックします。別のディレクトリーを使用する必要がある場合は、SELinux タイプ httpd_sys_r_content_t または pulp_tmp_t を使用できます。SELinux タイプ httpd_sys_r_content_t を使用すると、Web サーバーはファイルを読み取ることができます。SELinux ファイルタイプの設定に関する詳細は、SELinux ユーザーおよび管理者のガイド を参照してください。

  2. pulp-puppet-module-builder を実行して Git リポジトリーをチェックアウトします。

    # pulp-puppet-module-builder --output-dir=/var/www/puppet-modules \
    --url=git@mygitserver.com:mymodules.git --branch=develop

    これにより、git@mygitserver.com :mymodules.git から Git リポジトリーの 開発 ブランチをチェックアウトし、モジュールを /var/www/puppet-modules/ に公開します。

モジュールを HTTP サーバーへ公開するのと同じ手順が適用されます。

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

  1. Web サーバーにディレクトリーを作成し、モジュールを同期します。

    # mkdir /var/www/html/puppet-modules
    # chmod 755 /var/www/html/puppet-modules
  2. pulp-puppet-module-builder を実行して Git リポジトリーをチェックアウトします。

    # pulp-puppet-module-builder \
    --output-dir=/var/www/html/puppet-modules \
    --url=git@mygitserver.com:mymodules.git --branch=develop

    これにより、git@mygitserver.com :mymodules.git から Git リポジトリーの 開発 ブランチをチェックアウトし、モジュールを /var/www/html/puppet-modules/ に公開します。

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

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

  1. Products ページで、前のステップで作成したカスタム製品(MyProduct)をクリックします。
  2. Repositories サブタブに移動します。
  3. では、「New Repository」をクリックします。
  4. Name でリポジトリーを指定します。この例では、MyGitRepo という名前を使用 ます。
  5. Label フィールドは、名前に基づいて自動的にラベルが入力され ます
  6. puppet をリポジトリーの Type として選択します。
  7. URL フィールドに、先に定義した場所を設定します。たとえば、Satellite 6 サーバーのローカルディレクトリーは file:// protocol を使用します。

    file:///modules

    リモートリポジトリーは http:// プロトコルを使用します。

    http://webserver.example.com/modules/
  8. 「Save」をクリックします。
  9. リポジトリーの同期

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

3.6. コンテンツビューの公開

Puppet モジュールを利用するための最終ステップは、コンテンツビューの一部として公開することです。このモジュールを既存のビューに追加できますが、この例では新しいビューを作成します。

コンテンツビューの公開

  1. Content > Content Views の順に移動します。
  2. + 新規ビューの作成を クリックします。
  3. Name でビューを指定します。この例では、MyView を名前として使用します。
  4. Label フィールドは、名前に基づいて自動的にラベルが入力され ます
  5. Composite View が選択されていないことを確認します。
  6. 「Save」をクリックします。
  7. 新規作成されたビューの 名前 を選択します。
  8. カスタムコンテンツリポジトリー
  9. 同じバージョンの Red Hat Enterprise Linux Server RPM コレクションと Red Hat Satellite Tools 6.7 RPM コレクションを含む、必要な Red Hat Enterprise Linux リポジトリーを追加します。Tools RPM コレクションには、プロビジョニングしたシステムにリモート Puppet 設定を設定するパッケージが含まれます。
  10. Puppet モジュールに移動します
  11. Add New Module を クリックします。
  12. モジュールまでスクロールし、Select a Version をクリックします。
  13. モジュールバージョンが Latest を使用 し、Select Version をクリックします。
  14. これで、モジュールは Content View の一部になりました。新しいバージョンの Content View をパブリッシュする Versions に移動し、プロモートします。
  15. 新規バージョンの公開 をクリックします。Publish New Version ページで Save をクリックします。これにより、コンテンツビューがモジュールで公開されます。
  16. 新しいバージョンのビューまでスクロールし、Promote をクリックします。ライフサイクル環境を選択し、Promote Version をクリックします。これにより、ビューが選択したライフサイクル環境の一部となります。

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

3.7. Puppet 環境

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

Puppet 環境は、Puppet モジュールを異なるタイプのホストから分離するために使用されます。通常の使用は、モジュールへの変更をある環境でテストしてから別の環境にプッシュできるようにすることです。Puppet モジュールには、ファクトや関数、ならびに Hosts に割り当て可能な 1 つ以上の Puppet クラスを含めることができます。モジュールは環境の一部で、Puppet クラスはモジュールの一部であるため、環境の一部となります。

Red Hat Satellite では、CV に Puppet モジュールがある場合は、コンテンツビュー用に Puppet 環境が自動的に作成されます。自動的に作成された Puppet 環境名には、組織のラベル、ライフサイクル環境、コンテンツビュー名、およびコンテンツビュー ID が含まれます。たとえば、KT_Example_Org_Library_RHEL6Server_3 のようになります。

Red Hat Satellite での Puppet 環境の作成

  1. ConfigureEnvironments に移動し、New Puppet Environment を選択します。
  2. 新しい環境の名前を付け、Submit をクリックして変更を保存します。

環境が Puppet マスターに存在しておらず、その後にインポートを実行すると、Satellite は環境の削除を求めるプロンプトを出します。

注記

Puppet は、<literal>Production</literal> 環境内に作成した Puppet 環境に関連付けられているホストグループにホストを登録すると、Puppet CA 証明書の取得に失敗します。ホストグループに関連付けて、適切な Puppet 環境を作成するには、以下の手順を実行します。

  1. 手動でディレクトリーを作成して、所有者を変更します。

    # mkdir /etc/puppetlabs/code/environments/example_environment
    # chown apache /etc/puppetlabs/code/environments/example_environment
  2. ConfigureEnvironments に移動し、Import environment from をクリックします。ボタン名には、内部または外部の Capsule の FQDN が含まれます。
  3. 作成したディレクトリーを選択し、Update をクリックします。

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

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

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

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

Hosts > All Hosts の順に移動し、Hosts リストから名前でホストを選択し、Edit を選択します。Host タブで、ホストの Puppet 環境 を選択できます。環境を選択すると、選択した環境のクラスを区別できるように Puppet Classes タブのクラスにフィルターをかけます。

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

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

ホストグループ の作成時に、環境フィールドは、関連付けられたコンテンツビュー(ある場合)によって自動的に作成された環境によって事前に設定されます。

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

3.8. パラメーター

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

パラメーターのタイプ

Red Hat Satellite には 2 種類のパラメーターがあります。

単純パラメーター
キーと値ペアの関係を定義する基本的なパラメーターです。これらはユーザー設定で上書きできませんが、Satellite のパラメーター階層に従って上書きされます。Red Hat Satellite では、グローバル、組織レベル、位置レベル、ドメインレベル、サブネットレベル、オペレーティングシステムレベル、ホストグループ、およびホストのパラメーターの簡単なパラメーターを以下に示します。
スマートクラスパラメーター
キーの値を定義するだけではなく、特定のオブジェクトタイプの条件付き引数、検証および上書きを可能にする複雑なパラメーターです。Smart クラスパラメーターにより、Puppet クラスが外部データを取得できるようになります。これらのクラスは Puppet クラスで使用され、Puppet の用語でパラメーター化されたクラスと呼ばれます。これらのパラメーターの階層は、Web UI で設定できます。

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

グローバルパラメーター

Satellite のすべてのホストに適用されるデフォルトパラメーター。Configure > Global parameters で設定 されます。Hammer CLI を使用してグローバルパラメーターを設定するには、以下のコマンドを入力します。

# hammer global-parameter set --name parameter_name --value parameter_value
組織レベルのパラメーター

指定の組織内のすべてのホストに影響するパラメーター。組織レベルのパラメーターはグローバルパラメーターを上書きします。Administer > Organizations > Edit > Parameters で設定される。Hammer CLI を使用して組織レベルのパラメーターを設定するには、以下のコマンドを入力します。

# hammer organization set-parameter --organization "Your Organization" \
--name parameter_name --value parameter_value
ロケーションレベルのパラメーター

指定された場所のすべてのホストに影響するパラメーター。場所レベルのパラメーターは、組織レベルのパラメーターとグローバルパラメーターを上書きします。Administer > Locations > Edit > Parameters で設定される。Hammer CLI を使用して場所レベルのパラメーターを設定するには、以下のコマンドを入力します。

# hammer location set-parameter --location "Your_Location" \
--name parameter_name --value parameter_value
ドメインパラメーター

指定のドメインのすべてのホストに影響するパラメーター。ドメインパラメーターは、場所レベルのパラメーターを上書きします。Infrastructure > Domains > [choose_a_domain] > パラメーターで設定される。Hammer CLI を使用してドメインパラメーターを設定するには、以下のコマンドを入力します。

# hammer domain set-parameter --domain domain_name \
--name parameter_name --value parameter_value
スマートパラメーター

特定のサブネットのプライマリーインターフェースを持つすべてのホストに影響するパラメーター。サブネットパラメーターは、ホストグループのシステムレベル以降のパラメーターを上書きします。Infrastructure > Subnets > [choose_a_subnet] > パラメーターで設定します。Hammer CLI を使用してサブネットパラメーターを設定するには、以下のコマンドを入力します。

# hammer subnet set-parameter --subnet subnet_name \
--name parameter_name --value parameter_value
オペレーティングシステムレベルのパラメーター

指定のオペレーティングシステムを持つすべてのホストに影響するパラメーター。オペレーティングシステムレベルのパラメーターは、ドメイン以降のパラメーターを上書きします。Hosts > Operating systems > [choose_an_operating_system] > Parameters で設定される。Hammer CLI を使用してオペレーティングシステムのパラメーターを設定するには、以下のコマンドを入力します。

# hammer os set-parameter --operatingsystem os_name \
--name parameter_name --value parameter_value
ホストグループパラメーター

指定のホストグループ内のすべてのホストに影響するパラメーター。ホストグループパラメーターは、オペレーティングシステムレベルとそれ以降のパラメーターを上書きします。Configure > Host Groups > [choose_a_host_group] > パラメーターで設定します。Hammer CLI を使用してホストグループパラメーターを設定するには、以下のコマンドを入力します。

# hammer hostgroup set-parameter --hostgroup hostgroup_name \
--name parameter_name --value parameter_value
ホストパラメーター

特定のホストに影響するパラメーター。以前継承されたパラメーターはすべて Parameters サブタブに表示され、上書きできます。Hosts > All hosts > Edit > Parameters で設定される。Hammer CLI を使用してホストパラメーターを設定するには、以下のコマンドを入力します。

# hammer host set-parameter --host host_name \
--name parameter_name --value parameter_value

パラメーターと Puppet クラスの使用

Red Hat Satellite では、2 つの方法によって Puppet クラスで使用するためにホストの Puppet マスターに値を指定することができます。

スマート変数
Smart クラスパラメーターを持たないクラス用に、キー/値形式で Puppet マスターにグローバルパラメーターを提供するツール。これにより、Puppet マニフェストのパラメーター値を上書きできます。これは、クラスに Smart クラスパラメーターがない場合や、グローバルパラメーターが必要な場合に特別なケースで使用することを目的としています。階層コンテキストやユーザーが適用できるさまざまな条件に応じて、複数の値を持つことができます。Puppet はパラメーター化されたクラスを持つ前に存在し、現時点では後方互換性のために維持されるか、検証が必要なグローバルパラメーターの使用、特定の Puppet クラスのみ、および文字列以外のタイプに保持されます(それ以外の場合は、単純なパラメーターを使用することができます)。
パラメーター化クラス
スマートクラスパラメーターを含む Puppet クラス。クラスは Puppet マスターからインポートされ、パラメーター名(例 :$::name (preferred)、$$name )は、クラスを作成し、変更できないユーザーによって定義されます。これらは、グローバルにではなく、特定クラスの変数の値を決定できます。

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

重要

パラメーター化されたクラスサポートは、Satellite 6 ではデフォルトで有効になっています。これを有効にするには、Administer > Settings に移動し、Puppet タブを選択して、ENC の Parameterized Classes が True に設定され ていることを確認します。

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

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

Smart クラスパラメーターは、全組織で共通しています。edit_external_parameters パーミッションを持つユーザーは、これらのパラメーターを編集できます。スマートカードパラメーターを編集するパーミッションを制限する場合は、KCS ソリューション「 複数の組織間で共通の puppet クラスおよびそのスマートクラスパラメーターを編集する厳格なパーミッション 」を参照してください。

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

  1. Configure > Puppet Classes を クリックします。
  2. <guilabel>パラメーター</guilabel> 列に示されるパラメーターを含むクラスを一覧から選択します。
  3. スマートクラスパラメーターを更新します。これにより、新しい画面が表示されます。左側のセクションには、クラスがサポートする設定可能なパラメーターの一覧が含まれます。右側のセクションには、選択したパラメーターの設定オプションが含まれます。
  4. 左側の一覧からパラメーターを選択します。
  5. <guilabel>詳細</guilabel> テキストボックスを編集して、プレーンテキストのメモを追加します。
  6. Override を選択して、Satellite をこの変数で制御できるようにします。このチェックボックスを選択しないと、Satellite は新しい変数を Puppet に渡しません。
  7. パスするデータ のパラメータータイプ を選択します。これは最も一般的な文字列ですが、他のデータタイプがサポートされます。
  8. ホストが一致しない場合に Puppet Master に送信されるパラメーターの <guilabel>Default Value</guilabel> を入力します。
  9. オプション: 上書きがマッチ ない 限り、Puppet マスターに値を送信しない場合には、このチェックボックスを選択します。
  10. フィールドに作業中に表示したくないデータがが含まれる場合、オプションで <guilabel>非表示の値</guilabel> を選択します。
  11. 任意の 入力バリデーターセクションを使用し て、パラメーターに許可される値を制限します。Validator タイプ (コンマ区切りの値または 正規表現の 一覧 )を選択し、許可される値または正規表現コードを Validator rule フィールドに入力します。
  12. Override オプションが選択されていると、優先順位の Attribute Order セクションが表示されます。これにより、条件付き引数に基づいて特定ホストの値をオーバーライドするオプションが提供されます。属性タイプおよびその値は matcher と呼ばれます。
  13. Order フィールドに、一覧のエントリーを整理して、ホスト属性または Facts がマッチャーに対して評価される優先順位を設定します。Facter にある属性で、ホストの属性と混同しない属性を使用することが推奨されています。

    マッチー間で論理 AND 条件を作成し、複数の属性をマッチングキーとして使用する場合は、以下の形式でコンマ区切りリストとして 1 行ずつ指定します。

    location,environment
    注記

    BZ#1772381 が解決さ れるまで、Order ツールチップは、matcher キーとして複数の属性を使用するための設定例を表示することに注意してください。

  14. 条件引数を追加するには、Add Matcher をクリックします。照合する属性は、Order 一覧のエントリーに対応します。マッチーが設定されていない場合は、オーバーライド機能にデフォルト値のみを使用できます。
  15. Attribute type 一覧から属性を選択します。
  16. 属性の横にあるフィールドに、属性文字列を入力します。
  17. Value フィールドに必要な値を入力します。

    動的なデータは、組み込み Ruby(ERB)テンプレート構文の Value フィールドにパラメーターおよび Puppet ファクトを使用して実行できます。たとえば、値の一部として Puppet ファクトを使用するには、以下を実行します。

    <%= @host.facts['network_eth0'] %>

    利用可能な Puppet Facts を一覧表示するには、Monitor > Facts に移動します。

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

  18. Submit をクリックします。

単一の属性を matcher キーとして設定

1 つの属性を matcher キーとして設定できます。

たとえば、パラメーターの テスト 値を Default_Location 内のホストの Puppet マスターに指定するには、以下の手順を実施します。

  1. Order フィールドに 場所 を追加します。
  2. Add Matcher を クリックし、Attribute type 一覧から 場所 を選択します。
  3. 属性の横にあるフィールドに Default_Location を入力します。
  4. Value フィールドに test を入力し ます。
  5. Submit をクリックします。

複数の属性を matcher キーとして設定

複数の属性をマッチングとして設定できます。

たとえば、パラメーターのテスト値を、Default_Location 内のホストの Puppet マスターおよび 開発 環境に指定するには、以下の手順を実施します。

  1. Order フィールドに、location、environment を追加し ます。
  2. Add Matcher を クリックし、Attribute type 一覧から location、environment を選択します。
  3. 属性の横にあるフィールドに Default_Location,development を入力します。
  4. Value フィールドに test を入力し ます。
  5. Submit をクリックします。

一致する概要の優先順位

ホストと一致する場合は、Satellite は以下の優先順位を使用します。

  1. Satellite は、ホスト属性でマッチーを検索します。
  2. ホスト属性に一致がない場合、Satellite はホストパラメーターでマッチングを検索します。ホストパラメーターは、パラメーター階層に従って継承されます。
  3. ホストパラメーターに一致がない場合は、Satellite はホスト Facts 内のマッチングを検索します。

3.10. 親ホストグループを使用したファクトの適用

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

前提条件

  • ホストが割り当てられているホストグループがある。
  • ホストグループが割り当てられている親ホストグループがある。

複数のホストグループのメンバーにファクトの適用

  1. Satellite Web UI で、Configure > Classes に移動します。
  2. 使用する Puppet クラスを選択します。
  3. スマートクラスパラメーターを更新します。
  4. 左側の一覧からパラメーターを選択します。
  5. オプション: Description フィールドを編集して、プレーンテキストのノートを追加します。
  6. この変数に対する Satellite 制御を許可するには、Override を選択します。
  7. パスするデータ のパラメータータイプ を選択します。これは最も一般的な文字列ですが、他のデータタイプがサポートされます。
  8. ホストが一致しない場合に Puppet Master に送信されるパラメーターの <guilabel>Default Value</guilabel> を入力します。
  9. オプション: 上書きが一致し ない 限り、Puppet マスターに値を送信しない場合は選択してください。
  10. フィールドに作業中に表示したくないデータがが含まれる場合、オプションで <guilabel>非表示の値</guilabel> を選択します。
  11. オプション: 任意の 入力バリデーターセクションを使用し て、パラメーターに許可される値を制限します。Validator Type を選択します。これは、コンマ区切りの値のリストまたは 正規 表現(正規表現)のどちらかで、Validator rule フィールドに許可される値または正規表現コードを追加します。
  12. Prioritize Attribute Order エリアで、一覧のエントリーを整理してホスト属性またはマッチーに対して Facts を評価する 優先 順位 を設定します。デフォルトの一覧に追加できます。マッチー間で論理 AND 条件を作成するには、マッチング側のマッチングをコンマ区切りリストとして 1 行で囲みます。
  13. Specify Matchers エリアAdd Matcher をクリックし、条件引数を追加します。
  14. 属性タイプhostgroup に設定します。
  15. = 記号 後に、一致させるホストグループを入力します。この例では、親ホストグループです。
  16. Value フィールドに、親ホストグループに属する Content Hosts に送信する値を入力します。
  17. Submit をクリックします。

    親ホストグループがホストグループの階層の一部である場合は、matcher の値 top_host_group / parent_host_group /parent_host_groupについて以下のようにすべての権限を入力します。

3.11. 複数のカスタムファクトの使用

以下は、Puppet Smart class パラメーター matcher で複数のカスタムファクトとその値を作成して使用する例です。

前提条件

  • Puppet 環境をインポートし、Satellite でスマートクラスを持つ Puppet モジュールがある。
  • クライアントがプロビジョニングされ、Satellite に登録されている。
  • Satellite によってプロビジョニングされていないクライアントについては、の説明に従ってクライアントが設定されていることを確認し 「設定の既存クライアントへの適用」 ます。

    1. クライアントで、2 つ以上のカスタムファクトを作成し、値を割り当てます。例を示します。

      # vi /etc/facter/facts.d/my_custom_facts
      #! /bin/bash
      echo example_fact1=myfact1
      echo example_fact2=myfact2
    2. クライアントで、ファイルパーミッションを設定します。

      # chmod a+x /etc/facter/facts.d/my_custom_facts
    3. クライアントで、ファクトと各値を確認します。

      # facter | grep example
       example_fact1 => myfact1
       example_fact2 => myfact2
    4. Satellite Server Web にログインします。

      1. Configure > Classes に移動し、設定する Puppet クラスを選択します。
      2. Smart Class Parameter タブをクリックし、上書きするパラメーターを選択します。
      3. Default Behavior エリアで Override チェックボックスを選択します。
      4. Prioritize Attribute Order エリアで、Order フィールドに example ファクトをリストの末尾に追加します。2 つのファクト間で論理 AND 条件を作成するには、それらをコンマで区切った example_fact1,example_fact2 として追加します。
      5. Matcher の追加
      6. Attribute type メニューから example _fact1,example_fact2 を選択し、= 記号の後に表示されるボックスに myfact 1,myfact2 を入力します。
      7. 2 つの属性とその値にマッチすると、Value フィールドに Content Host に送信する値を入力します。
      8. Submit をクリックします。
    5. クライアントでファクトをクライアントから Puppet マスターに送信します。

      # puppet agent --test
    6. Satellite Server Web にログインします。

      1. Hosts > Content Hosts に移動し、コンテンツホストの名前を選択します。
      2. YAML をクリックし、classes セクションを見つけます。パラメーターの値が必要な値があることを確認します。

3.12. スマート変数の設定

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

スマート変数の設定

  1. Configure > Puppet Classes を クリックします。
  2. 一覧からクラスを選択します。
  3. Smart Variables タブをクリックします。これにより、新しい画面が表示されます。左側のセクションには、クラスがサポートする設定可能なパラメーターの一覧が含まれます。右側のセクションには、選択したパラメーターの設定オプションが含まれます。Add Variable をクリックして、新しいパラメーターを追加します。左側の一覧からパラメーターを選択します。
  4. Key フィールドにパラメーターの名前を入力します。
  5. <guilabel>詳細</guilabel> テキストボックスを編集して、プレーンテキストのメモを追加します。
  6. 渡すデータの Parameter Type を選択します。これは最も一般的な文字列ですが、他のデータタイプがサポートされます。
  7. ホストが一致しない場合に Puppet Master に送信されるパラメーターの <guilabel>Default Value</guilabel> を入力します。
  8. フィールドに作業中に表示したくないデータがが含まれる場合、オプションで <guilabel>非表示の値</guilabel> を選択します。
  9. 任意の 入力バリデーターセクションを使用し て、パラメーターに許可される値を制限します。Validator Type (コンマ区切りの値または 正規表現の 一覧 のいずれか)を選択し、Validator rule フィールドに許可される値または正規表現コードを入力します。
  10. Prioritize Attribute Order セクションには、条件引数に基づいて特定ホストのオーバーライド値を上書きするためのオプションを指定します。属性タイプおよびその値は matcher と呼ばれ ます

    1. リスト内のエントリーを整理して、ホスト属性または Facts がマッチーに対して評価される優先順位の Order を設定します。デフォルトの一覧に追加できます。マッチー間で論理 AND 条件を作成するには、コンマ区切りリストとして 1 行で囲みます。
    2. 条件引数を追加するには、Add Matcher をクリックします。照合する属性は、Order 一覧のエントリーに対応している必要があります。マッチーが設定されていない場合は、オーバーライド機能にデフォルト値のみを使用できます。

      たとえば、Puppet マスターに指定する必要のあるパラメーターの値が <literal>server1.example.com</literal> の完全修飾ドメイン名を持つホストの <literal>test</literal> の場合、Matcher を <literal>fqdn=server1.example.com</literal> として、<guilabel>値</guilabel> を <literal>test</literal> に設定します。

      マッチングの優先順位は以下のとおりです。

      1. マッチャーがホスト属性の場合はそれを使用します。
      2. 該当する名前を持つ属性がない場合は、一致するホストパラメーター (パラメーターの階層に基づいて継承される) を探します。
      3. それでも一致しなければホストのファクトをチェックします。

        Facter にある属性で、ホストの属性と混同しない属性を使用することが推奨されています。ホスト属性は、ホストパラメーターまたはホスト(ホストグループ、ドメイン、組織など)への関連付けのいずれかになります。マッチーは、ホストにの 1 つしか指定することはできません。たとえば、ホストには設定グループが多数あり、ホストには場所が 1 つしかないため、場所は有効な一致になります。

        動的なデータは、組み込み Ruby (ERB)テンプレート構文の Value フィールドにパラメーターおよび Puppet ファクトを使用して実行できます。たとえば、値の一部として Puppet ファクトを使用するには、以下を実行します。

        <%= @host.facts['network_eth0'] %>

        利用可能な Puppet Facts を一覧表示するには、Monitor > Facts に移動します。

  11. Submit をクリックして変更を保存します。

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

3.13. Puppet マスターからのパラメーター化されたクラスのインポート

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

注記

パラメーター化されたクラスのインポートは、Puppet モジュールが製品およびコンテンツビューで管理される場合に自動的に実行されます。

パラメーター化されたクラスの設定

  1. Satellite web UI では、コンテキストメニューから <guilabel>組織</guilabel> および <guilabel>ロケーション</guilabel> を選択します。
  2. Configure > Puppet Classes を クリックします。
  3. Import from Host Name をクリックし、Puppet マスターからパラメーター化されたクラスをインポートします。
  4. <guilabel>Puppet クラス</guilabel> ページが新規クラスの一覧と共に表示されます。

3.14. Smart Variable ツールの使用

Smart 変数は、Smart Class パラメーターが含まれない Puppet クラスで使用するために Puppet マスターにグローバルパラメーターを提供するツールです。Smart Matcher ルールは、Smart Variables および Smart Class パラメーターの両方に使用されます。

注記

Puppet モジュールが Smart Class パラメーターをサポートする前に、Smart Variables ツールが中間手段として導入されました。Smart 変数を使用する特定の理由がない場合、Red Hat は、で説明されているように Smart Class パラメーターを使用することを推奨してい 「スマートクラスパラメーターの設定」 ます。

Smart Class パラメーターが導入される前に、グローバルパラメーターを使用するために Puppet コードを書き直すように要求されたパラメーターを上書きする必要があるユーザーは、パラメーターを上書きします。例を示します。

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

上記の例では、$global_var は Web UI の Smart Variables セクションで設定され、値は「example1」クラスに関連付けられます。Puppet がグローバルスコープを検索するよう Puppet を制限するには、:: でグローバル変数を追加することを推奨しますが、変数がグローバル変数ではないというわけではありません。

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

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

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

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

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

Satellite で作成する変数が、ホスト YAML ファイルに追加されます。このファイルは、Web UI で表示するには、Hosts > All Hosts と選択し、ホストの名前を選択してから YAML ボタンをクリックします。Satellite は、ホストの YAML ファイルを 外部ノード分類子 (ENC)に送信します。これは、Puppet マスターに含まれる関数です。Puppet マスターがホストの ENC にクエリーされると、ENC はホストの状態を説明する YAML ドキュメントを返します。この YAML ドキュメントは、Puppet マニフェストから取得したデータをベースとしていますが、Smart Class Parameter の上書きおよび Smart Variables の対象となります。

スマート変数のホストへの適用

Smart 変数は、以前はグローバルパラメーターが含まれるように変更されたカスタム Puppet モジュールをサポートするためにのみ使用する必要があります。以下の例では、anothermodule という簡単な例を使用してい ます。anothermodule Puppet Manifest は以下の通りです。

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

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

  1. Web UI で Configure > Classes に移動します。
  2. 一覧から Puppet クラスの名前を選択します。
  3. Smart Variables タブをクリックします。これにより、新しい画面が表示されます。左側のセクションには、以前に作成されたパラメーターの一覧が記載されています(ある場合)。右側のセクションには設定オプションが含まれます。
  4. Add Variable をクリックして、新しいパラメーターを追加します。
  5. Key フィールドにパラメーターを入力します。この例では、content_for_motd です。
  6. Description テキストボックス(例: testing /tmp motd Text )を編集します。
  7. 渡すデータの Parameter Type を選択します。string を選択します。
  8. パラメーターの デフォルト値 を入力します。たとえば、未承認の使用は使用し ません。
  9. 任意の 入力バリデーターセクションを使用し て、パラメーターに許可される値を制限します。Validator Type (コンマ区切りの値または 正規表現の 一覧 のいずれか)を選択し、Validator rule フィールドに許可される値または正規表現コードを入力します。
  10. 「優先属性順序」 セクションを使用して、ホスト属性または Facts がスキャナーに対して評価される優先順位 (以下で設定される)を設定します。一覧のエントリーを再編成し、デフォルト一覧に追加できます。マッチー間で論理 AND 条件を作成するには、ある行でコンマ区切りリストとしてマッチング名を指定します。
  11. Specify Matchers セクションAdd Matcher をクリックし、条件引数を追加します。照合する属性は、上記の Order 一覧のエントリーに対応している必要があります。マッチーが設定されていない場合は、デフォルト値のみを使用できます。たとえば、パラメーターで必要な値が、完全修飾ドメイン名 が server1.example.com の Server 1 の場合、Matchfqdn=server1.example.com として指定し、Server1 の場合はこれValue として指定します。
  12. Submit をクリックして変更を保存します。

第4章 ホスト情報の保存および維持

Red&nbsp;Hat Satellite&nbsp;6 はアプリケーションの組み合わせを使用して管理対象ホストについての情報を収集し、それらのホストがあるべき状態で維持されるようにします。これらのアプリケーションには以下が含まれます。これらのアプリケーションには以下が含まれます。

  • Foreman: 物理および仮想システムのプロビジョニングおよびライフサイクル管理に使用します。Foreman は、キックスタートモジュールや Puppet モジュールなどのさまざまな方法を使用して、これらのシステムを自動的に設定します。
  • Puppet: ホストを設定するためのクライアント/サーバーアーキテクチャーです。Puppet マスター (サーバー) および Puppet エージェント (クライアント) で構成されます。
  • facter: Puppet のシステムインベントリーツール。facter は、ハードウェアの詳細、ネットワーク設定、OS タイプおよびバージョン、IP アドレス、MAC アドレス、SSH キーなどのホストの基本的な情報を収集します。これらのファクトは、Puppet マニフェストで変数として利用できるようになります。

Puppet、Facter およびファクトの使用については、以下で詳述します。

4.1. Puppet アーキテクチャー

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

  • カタログのコンパイル
  • カタログの該当ホストへの適用

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

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

4.2. Facter およびファクトの使用

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

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

条件式とファクトの使用

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

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

注記

この例では、versioncmp ($::operatingsystemmajrelease, '7')>= 0 という式を使用して、Red Hat Enterprise Linux のバージョン 7 以降をテストします。このテストを実行するには、式 $::operatingsystemmajrelease >= '7' を使用しないでください。これおよび その他 の Puppet 機能の詳細は、https://docs.puppetlabs.com/references/latest/function.html#versioncmp を参照してください。

また、Puppet は、facts のように多くの動作を行う特別な変数も設定します。詳細は、「 Puppet および コアファクト により追加される特別な変数 」を参照してください。

4.2.1. 特定ホストのファクトの表示

Puppet は、Puppet モジュールに存在するカスタムまたは外部ファクトに加えて、Facter の組み込みコアファクトにアクセスできます。利用可能なファクトはコマンドライン(facter -p)や Web UI(Monitor > Facts)から確認できます。ファクトのリストを参照したり、検索ボックスに特定のファクトを検索 することができます。たとえば、「facts.」と入力して、利用可能なファクトの一覧を表示します。

注記

利用可能なファクトの一覧は非常に長くなります。UI は一度に 20 ファクトのみを表示します。詳細を入力する際に、ファクトのリストは徐々にフィルターされます。たとえば、「facts.e」と入力して、「e」で始まるすべてのファクトを表示します。

特定ホストのファクトの表示

  1. メインメニューで Hosts > All Hosts をクリックしてから、検査するホストの名前をクリックします。
  2. 詳細 ペインで Facts をクリックし、ホストに関する既知のすべてのファクト を表示します。
注記
  • このページに一覧表示されているファクトについて、<guibutton>Chart (チャート)</guibutton> をクリックし、このファクト名のすべての管理対象ホストにおけるディストリビューションチャートを表示します。
  • 検索を行うと、将来使用しやすくなります。検索を絞り込んだら、検索ボタンの横にあるドロップダウン矢印をクリックし、この 検索 の Bookmark をクリックします。検索に関する 検索 は、メインメニューの Administer > Bookmarks にも表示されます。

4.2.2. ファクトに基づくホストの検索

Facter 情報を使用して、特定のホストを検索することができます。つまり、facts .architecture = x86_64 などの特定のファクト 基準に一致するすべてのホストを検索できます。

ファクトに基づくホストの検索

  1. メインメニューで Monitor > Facts をクリックし、Fact Values ページを表示します。
  2. Search フィールドで、で絞り込む実際の名前を入力します。特定の名前、名前/値のペアなどで検索できます。
  3. <guibutton>検索</guibutton> をクリックして、一致するホストの一覧を検索します。

4.2.3. カスタムファクトのレポート

管理対象ホストからカスタム情報を取得することは、Red Hat Satellite 6 で完全にサポートされています。本項では、Puppet Forge から取得した Puppet モジュールの使用について説明しますが、この原則は Puppet モジュールの他のソースに同じように適用されます。

標準の Facter インターフェースを介して報告されるファクトの数は拡張できます。たとえば、モジュールで変数として使用するファクトを収集するには、以下を実行します。インストールされたパッケージが記述されている場合は、このデータを調べ、情報に基づいて情報管理決定を行うことができます。

ホストにインストールされたパッケージについてのレポートを取得するプロセスは以下のようになります。

  • マニフェスト <literal>pkginventory</literal> は Puppet Forge から取得され、ベースシステムに保存されます。
  • Puppet モジュールはコンテンツビューに追加され、これはシステムにプロモートされてからそのシステムにデプロイされます。
  • その後、システムのファクトはパッケージ名を使用してクエリーされます。この例では、hostname というホストで、クレデンシャル および パスワード で Satellite ユーザーを使用する場合、以下の API クエリーは検索文字列「bash」に一致するファクトを返します。

    curl -u username:password -X GET http://localhost/api/hosts/:hostname/facts?search=bash
    {"hostname":{"pkg_bash":"4.2.45-5.el7_0.4"}}

    検索は、パッケージバージョンを返します。これは、外部データベースを設定するのに使用できます。

4.2.3.1. pkginventory Puppet モジュールの追加

<literal>pkginventory</literal> Puppet モジュールを Red&nbsp;Hat Satellite Server アプリケーションに追加するには、モジュールを <ulink url="https://forge.puppetlabs.com/ody/pkginventory">https://forge.puppetlabs.com/ody/pkginventory</ulink> から Satellite Server アプリケーションがインストールされているベースシステムにダウンロードし、以下の手順に従います。

Puppet モジュールは通常、Puppet Modules という名前のカスタムリポジトリーに保存されます。以下の手順では、その名前のカスタムリポジトリーを作成していることを前提としています。Puppet モジュール用のカスタムリポジトリーを作成していない場合は、『 クイックスタートガイド』の「カスタム 製品の作成 」を参照してください

Puppet モジュールをリポジトリーにアップロードするには、以下を実行します。

  1. Puppet モジュールをベースシステムにダウンロードします。ダウンロードするモジュールには .tar.gz 拡張子が含まれます。
  2. Content > Products をクリックしてから、Puppet モジュールリポジトリーに関連付けられた Name フィールドで製品名をクリックします。例: カスタム製品
  3. リポジトリータブ 、変更する Puppet モジュールリポジトリーを選択します。たとえば、Puppet モジュールなど
  4. Puppet モジュールのアップロードセクションでBrowse をクリックし、ダウンロードしたモジュールに移動します。
  5. アップロード をクリックします。

Puppet モジュールをクライアントやコンテンツホストに配信するには、モジュールはコンテンツビューに適用し、公開される必要があります。以下の手順に従ってモジュールをコンテンツビューに追加します。モジュールをコンテンツビューに追加するには、以下を実行します。

モジュールをコンテンツビューに追加するには、以下を実行します。

  1. Content > Content Views をクリックしてから、Name メニューから Content View を選択します。
  2. Puppet Modules タブで、Add New Module を クリックします。インストール済みモジュールの一覧が表示されます。
  3. アクション コラムから、Select a Version をクリックし、追加するモジュールを選択します。利用可能なバージョンの表が表示されます。
  4. 追加するモジュールのバージョンの横にある <guibutton>バージョンの選択</guibutton> をクリックします。
  5. <guibutton>新規バージョンの公開</guibutton> をクリックして新規コンテンツビューを作成します。
  6. オプションで説明を追加し、<guibutton>保存</guibutton> をクリックします。

第5章 設定管理のクライアント設定およびサーバー設定

Red Hat Satellite 6 の設定プロセスの重要な部分は、Puppet クライアント(Puppet エージェントと呼ばれる)が、内部 Satellite Capsule または外部の Satellite Capsule のいずれかで Puppet サーバー(Puppet マスターと呼ばれる)と通信できることです。本章では、Red Hat Satellite 6 が Puppet マスターと Puppet エージェントの両方を設定する方法を考察します。

5.1. Red Hat Satellite サーバーに root としてログインします。

Red Hat Satellite 6 は、すべての Satellite Capsules 上の 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 設定オプションのセットと説明が記載されています。

5.2. プロビジョニングされたシステムでの Puppet エージェントの設定

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

このスニペットには、テンプレート変数が含まれます。以下に例を示します。

  • @host.puppet_ca_server and@host.certname: Puppet 通信の セキュリティー を保護するための証明書および認証局。
  • @host.environment: 設定に使用する Satellite 6 サーバーの Puppet 環境
  • @host.puppetmaster: Puppet マスターを含むホスト。これは、Satellite 6 Server の内部 Capsule または外部の Satellite Capsule のいずれかです。

第6章 クライアントの設定の適用

この時点で、Satellite 6 Server の Puppet エコシステムが設定され、mymodule モジュールが含まれます。これで、このモジュールの設定を登録済みシステムに適用することを目指しています。

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

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

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

  1. Hosts > New host の順に移動します。
  2. Host タブをクリックします。ホストの 名前 を入力して、システムの組織と場所を選択します。ライフサイクル環境 とそのプロモートされたコンテンツビューを選択し ます。これにより、設定に使用する Puppet 環境が定義されます。Capsule Settings から Puppet CA および Puppet Master も選択します。選択した Capsule は、設定を制御し、新規ホストのエージェントと通信するサーバーとして機能します。
  3. Puppet Classes タブをクリックし、Available Classes セクションから、適用する設定が含まれる Puppet クラスを選択します。この例では、以下を選択します。

    • mymodule
    • mymodule:httpd
    • mymodule:app
  4. Operating System タブで必要なオプションを選択します。これらのオプションは、独自の Satellite 6 インフラストラクチャーによって異なります。プロビジョニングテンプレートの オプション に、Satellite Kickstart Default kickstart テンプレートが含まれていることを確認してください。このテンプレートには、新規ホスト上で Puppet エージェントのインストールコマンドが含まれています。
  5. Parameters タブをクリックし、Puppet クラスパラメーターにカスタムオーバーライドを指定します。この機能 「スマートクラスパラメーターの設定」 を有効にするには、を参照してください。
  6. すべてのプロビジョニングオプションが完了したら、Submit をクリックします。

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

<% 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 -%>

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

  • Red Hat Satellite Tools 6.7 リポジトリーから puppet パッケージをインストールします。
  • /etc/puppetlabs/puppet/puppet.conf のシステムに Puppet 設定スニペットをインストールします。
  • システムで Puppet サービスを実行できるようにします。
  • ノードを初めて実行し、ノードを初期化します。

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

Congratulations

Your puppet module has correctly applied your configuration.

6.2. 設定の既存クライアントへの適用

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

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

重要

puppet パッケージは Red Hat Satellite Tools 6.7 リポジトリーに含まれます。次のステップに進む前に、このリポジトリーを有効にしてください。

Puppet エージェントをインストールし、有効にするには、以下を実行します。

  1. ホストでターミナルを開き、root でログインします。
  2. Puppet エージェントをインストールします。

    # yum install puppet
  3. システムの起動時に Puppet エージェントが起動するように設定します。

    • Red Hat Enterprise Linux 6 の場合:

      # chkconfig puppet on
    • Red Hat Enterprise Linux 7 の場合:

      # systemctl enable puppet

Puppet エージェントの設定

  1. /etc/puppetlabs/puppet/puppet.conf ファイルを変更して Puppet エージェントを設定します。

    # vi /etc/puppetlabs/puppet/puppet.conf
    [main]
        # The Puppet log directory.
        # The default value is '$vardir/log'.
        logdir = /var/log/puppet
    
        # Where Puppet PID files are kept.
        # The default value is '$vardir/run'.
        rundir = /var/run/puppet
    
        # Where SSL certificates are kept.
        # The default value is '$confdir/ssl'.
        ssldir = $vardir/ssl
    
    [agent]
        # The file in which puppetd stores a list of the classes
        # associated with the retrieved configuratiion.  Can be loaded in
        # the separate puppet executable using the --loadclasses
        # option.
        # The default value is '$confdir/classes.txt'.
        classfile = $vardir/classes.txt
        pluginsync = true
        report = true
        ignoreschedules = true
        daemon = false
        ca_server = satellite.example.com
        server = satellite.example.com
        environment = KT_Example_Org_Library_RHEL6Server_3
    
        # Where puppetd caches the local configuration.  An
        # extension indicating the cache format is added automatically.
        # The default value is '$confdir/localconfig'.
        localconfig = $vardir/localconfig
    重要

    環境 パラメーターを、Satellite Server からホストの Puppet 環境に設定します。Puppet 環境ラベルには、組織ラベル、ライフサイクル環境、コンテンツビュー名、およびコンテンツビュー ID が含まれます。Satellite 6 の Web UI で Puppet 環境の一覧を表示するには、Configure > Environments の順に移動します。

  2. ホスト上で Puppet エージェントを実行します。

    # puppet agent -t --server satellite.example.com
  3. Satellite Server Web インターフェースを使って Puppet クライアント用の SSL 証明書に署名します。

    1. Web UI から Satellite Server にログインします。
    2. Infrastructure > Capsules を選択します。
    3. 必要なホストの右側にある <guibutton>証明書</guibutton> をクリックします。
    4. 「Save」をクリックします。
    5. ホスト上で Puppet エージェントを実行します。

      # puppet agent -t --server satellite.example.com
注記

Puppet エージェントがホストに設定されていると、All Hosts に一覧表示されますが、ホストが組織や場所に割り当てられないため、すべての コンテキスト が選択される場合のみです。

第7章 設定グループを使用した Puppet クラスの管理

Red Hat Satellite には、システムグループの 構築および 管理を可能に する設定グループとホスト グループの概念が含まれています。

設定グループは、ホストおよびホストグループの設定に使用するビルディングブロックを形成するために作成する Puppet クラスのコレクションです。設定グループは、Puppet の概念である Profiles の概念に類似しています。これには、ビルディングブロックを形成する Puppet クラスのコレクションが含まれます。設定グループは、Satellite Web UI で作成および管理することができます。

ホストグループは、システムの定義用のホストサーバーとコンテナーの両方です。これには、コンテンツビュー、割り当てられたライフサイクル、および Puppet モジュールのセットが含まれます。ホストグループは、特定のビジネスロールでシステムを構築する多数のプロファイルを含む Puppet クラスである Roles というコミュニティーの Puppet の概念に類似しています。ホストグループは、Satellite Web UI で Hammer CLI を使用して作成および管理することができます。

設定グループを作成します。

左側のコンテキストドロップダウンメニューから、任意の 組織および 場所 選択します。

Configure > Config groups の順に移動します。

New Config Group を選択し、名前(TestConfGroup など)を入力し ます

利用可能なクラスの一覧から 1 つ以上の Puppet クラス を選択します。

Submit を選択して変更を適用します。

Config グループを作成したら、ホストまたはホストグループの設定時に Puppet クラスタブで選択できるようになります。ホストグループの作成に関する詳細は、『 Red Hat Satellite Provisioning Guide』の「 Creating a Host Group on Satellite Server 」を参照してください

第8章 Red Hat Satellite 6 での Puppet レポートの確認

Puppet は、設定を適用するたびにレポートを生成します。プロビジョニングされたホストはこのレポートを Red Hat Satellite 6 Server に送信します。ホストの詳細ページで、これらのレポートを表示します。

Red Hat Satellite 6 での Puppet レポートの確認

  1. Hosts > All hosts の 順に移動します。
  2. 必要なホスト の名前 をクリックします。
  3. Report ボタンを クリック します。
  4. 表示するレポートを選択します。

各レポートには、各 Puppet リソースのステータスと、ホストに適用される設定が表示されます。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.