Go to main content
Oracle® Solaris 11.3 での Puppet を使用した構成管理の実行

印刷ビューの終了

更新: 2016 年 7 月
 
 

Puppet の動作のしくみ

Puppet には、システムに必要なソフトウェアや構成を定義したあと、初期設定後に指定された状態を維持する機能があります。

特定の環境またはインフラストラクチャーの構成パラメータを定義するには、Ruby に似た宣言型のドメイン固有言語 (DSL) を使用します。Puppet は、Puppet ソフトウェアパッケージのインストール時にインストールされる Facter と呼ばれるユーティリティーを使用して、システムに関する情報を検出します。Facter を使用したシステムに関する情報の収集を参照してください。

Puppet マスターは、マニフェストを使用して制御するすべてのノードの重要な構成情報を管理するシステムです。Puppet マニフェストを参照してください。

マスターが制御するノードは、Puppet がインストールされており、Puppet エージェント (デーモン) を実行しているノードです。エージェントがノードに関して収集した構成情報は、Puppet マスターに送信されます。Puppet マスターはそのあと、そのノードがどのように構成されるべきかに基づいてカタログをコンパイルします。各ノードは、その情報を使用して、必要なすべての構成の更新を自身に適用します。

Puppet は、プルモードを使用して動作します。ここで、エージェントはマスターを定期的にポーリングして、サイト固有の構成やノード固有の構成を取得します。このインフラストラクチャーでは、管理対象ノードは Puppet エージェントアプリケーションを (通常はバックグラウンドサービスとして) 実行します。詳細は、https://docs.puppet.com/puppet/3.6/reference/architecture.html を参照してください。

次の図は、Puppet マスター/エージェントトポロジをさらに詳細に説明しています。

image:Puppet マスター/エージェントトポロジを説明している図。

Puppet マスターについて

Puppet マスターは、指定されたサーバー上で実行されるデーモンであり、Puppet の構成データおよび権限のプライマリソースです。マスターは、Puppet インフラストラクチャーの一部であるすべてのノードに手順を提供します。 コンポーネント構成のある側面はほかのコンポーネントの構成に依存するため、Puppet マスターとして指定されているサーバーはシステムの構成全体を認識している必要があります。Puppet では、マスターを独自のユーザーおよびグループとして実行させることによってマスターへのアクセスを制限します。Puppet ユーザーおよびグループの機能を参照してください。

    マスターは、次を含むいくつかのアクションに責任を負っています。

  • エージェント用のカタログのコンパイル

  • ファイルサーバーからのファイルの転送

  • セントラルインスタンスへのレポートの送信


注 -  マスターは、root 特権を必要としないその他のアクションも実行する可能性があります。

Puppet エージェントについて

ターゲットシステム (またはノード) 上で実行される Puppet デーモンは、Puppet エージェントと呼ばれます。エージェントは、Puppet マスターからプルした構成カタログを適用できるように、それが有効になっているノードの適切な特権を持っている必要があります。エージェントは、マスターにはじめて接続したときに SSL (Secure Socket Layer) 証明書を要求することによって、マスターサーバーから通信特権を取得します。そのあと、エージェントは構成の更新がないかどうかマスターをポーリングするたびに、その証明書が有効な場合にのみそれらの更新を受信します。

各ターゲットノード上で実行される Puppet エージェントは、システムの構成のほとんどの側面を変更する機能を備えている必要があります。この要件によって、マスターが示したそのエージェントのあるべき状態が適用されます。Puppet エージェントはシステムへのアクセスを大量に必要とするため、root ユーザー、または Puppet Management 権利プロファイルが割り当てられたユーザーとして実行されます。


注 -  マスターは、正しくない構成情報を誤って受信することのないように、エージェントに対する認証も実行する必要があります。

Puppet ユーザーおよびグループの機能

Puppet ユーザーおよびグループは、モジュールがマスターから取得する必要のある情報にのみアクセスできるようにするために、セキュリティー上の理由から使用されます。また、Puppet ユーザーおよびグループにより、Puppet モジュールが攻撃または改ざんされることも防止されます。Puppet ユーザーはマスター上でタスクを実行し、Puppet グループのメンバーです。設定プロセス中にマスターの SMF サービスインスタンスを有効にすると、この特権ユーザーおよびグループが自動的に作成され、マスターデーモンに割り当てられます。Oracle Solaris での Puppet の使用開始を参照してください。

    Puppet ユーザーを通して、Puppet マスターは次のタスクを実行します。

  • 構成マニフェストを Puppet マニフェストのディレクトリ内に格納します。

  • エージェントからの SSL 証明書を受け入れます。

  • ファイルをエージェントに転送します。

  • カタログを作成します。

Puppet の暗号化および通信方式

Puppet は、SSL および TLS (Transport Layer Security) 暗号化プロトコルに基づく OpenSSL ツールキットとインタフェースを取ります。Puppet は、エージェントとマスターの認証および検証に標準の SSL/TLS 暗号化テクノロジと標準の SSL 証明書を使用します。Puppet はまた、サーバーとエージェントの間のトラフィックフローの暗号化にも SSL/TLS を使用します。使用されるデフォルトのハッシュは SHA-256 です。

    Puppet の暗号化方式では、次のことを実行します。

  • すべてのエージェントをマスターに対して認証します

  • すべてのエージェントでマスターを認証します

  • マスターとエージェントの間の盗聴する通信を防ぎます

Puppet は、TLS クライアント側の X.509 証明書を使用して、相互のホスト認証を実行します。デフォルトでは、この情報は Puppet 構成ファイル (puppet.conf) で定義されている /etc/puppet/ssl ディレクトリ内に格納されます。このデフォルトの場所は SMF コマンドを使用して変更でき、これはそのあと、サイトの構成ファイルに反映されます。鍵、証明書、署名された要求だけでなく、署名を待っている要求に対しても個別のディレクトリが存在します。これらのディレクトリは、マスターとエージェントの両方に存在します。

Puppet は独自の認証局 (CA) を使用するため、CA に対するシステムのデフォルト設定 (/etc/certs/CA) を使用する必要はありません。マスターは初期化されると、独自の CA 証明書と非公開鍵を生成し、証明書失効リスト (CRL) を初期化してから、サーバー証明書と呼ばれる別の証明書を生成します。この証明書は SSL および TLS 通信に使用され、エージェントに送信されます。マスターとエージェントの交換中に、この CA はマスター上の /etc/puppet/ssl/ca/signed ディレクトリおよびエージェント上の /etc/puppet/ssl/certs ディレクトリ内に格納されます。