Puppet-quick-guide
Puppet-概要
Puppetは、インフラストラクチャの管理と構成を自動化するためにPuppet Labsによって開発された構成管理ツールです。 Puppetは、Infrastructure as codeの概念を支援する非常に強力なツールです。 このツールは、完全なインフラストラクチャをコード形式に変換するのに役立つRuby DSL言語で記述されており、簡単に管理および構成できます。
Puppetはクライアント/サーバーモデルに従います。この場合、クラスター内の1台のマシンはpuppetマスターと呼ばれるサーバーとして機能し、もう1台のマシンはノード上のスレーブと呼ばれるクライアントとして機能します。 Puppetには、初期構成から特定のマシンのサポート終了まで、システムを最初から管理する機能があります。
Puppet Systemの機能
Puppetの最も重要な機能は次のとおりです。
べき等
Puppetはそれをユニークにするmakes等性をサポートしています。 Chefと同様、Puppetでは、同じマシン上で同じ構成セットを複数回安全に実行できます。 このフローでは、Puppetはターゲットマシンの現在のステータスをチェックし、構成に特定の変更がある場合にのみ変更を行います。
べき等性は、マシンの作成から始まり、マシンの構成変更、寿命に至るまで、ライフサイクル全体を通して特定のマシンを管理するのに役立ちます。 Puppet Idempotency機能は、構成に変更がある場合に同じマシンを何度も再構築するのではなく、マシンを何年も更新し続けるのに非常に役立ちます。
クロスプラットフォーム
Puppetでは、Puppetリソースを使用するResource Abstraction Layer(RAL)の助けを借りて、実装の詳細や、基本構成で定義されているシステム内での構成コマンドの動作を心配することなく、指定されたシステム構成をターゲットにできますファイル。
Puppet-ワークフロー
Puppetは次のワークフローを使用して、システムに構成を適用します。
- Puppetでは、Puppetマスターが最初に行うことは、ターゲットマシンの詳細を収集することです。 すべてのPuppetノードに存在するファクター(ChefのOhaiと同様)を使用して、すべてのマシンレベルの構成の詳細を取得します。 これらの詳細が収集され、Puppetマスターに返送されます。
- 次に、Puppetマスターは、取得した構成を定義済みの構成詳細と比較し、定義済みの構成でカタログを作成して、ターゲットのPuppetエージェントに送信します。
- 次に、Puppetエージェントはこれらの構成を適用して、システムを望ましい状態にします。
- 最後に、ターゲットノードが目的の状態になると、レポートがPuppetマスターに返されます。これは、Puppetマスターがカタログで定義されているシステムの現在の状態を把握するのに役立ちます。
Puppet-主要コンポーネント
Puppetの主要コンポーネントは次のとおりです。
Puppetリソース
Puppetリソースは、特定のマシンをモデリングするための重要なコンポーネントです。 これらのリソースには独自の実装モデルがあります。 Puppetは同じモデルを使用して、特定のリソースを目的の状態に取得します。
プロバイダ
プロバイダーは基本的に、Puppetで使用される特定のリソースの履行者です。 たとえば、パッケージタイプ「apt-get」と「yum」はどちらもパッケージ管理に有効です。 特定のプラットフォームで複数のプロバイダーが利用できる場合があります。 ただし、各プラットフォームには常にデフォルトのプロバイダーがあります。
マニフェスト
マニフェストは、ターゲットシステムを構成するために関数またはクラス内で結合されるリソースのコレクションです。 システムを構成するために、Rubyコードのセットが含まれています。
モジュール
モジュールはPuppetの主要な構成要素であり、リソース、ファイル、テンプレートなどのコレクションとして定義できます。 それらは、同じフレーバーであると定義されているさまざまな種類のOSに簡単に配布できます。 簡単に配布できるため、1つのモジュールを同じ構成で複数回使用できます。
テンプレート
テンプレートは、Ruby式を使用して、カスタマイズされたコンテンツと変数入力を定義します。 カスタムコンテンツの開発に使用されます。 テンプレートはマニフェストで定義され、システム上の場所にコピーされます。 たとえば、httpdをカスタマイズ可能なポートで定義する場合は、次の式を使用して実行できます。
この場合のhttpd_port変数は、このテンプレートを参照するマニフェストで定義されています。
静的ファイル
静的ファイルは、特定のタスクを実行するために必要になることがある一般的なファイルとして定義できます。 Puppetを使用して、ある場所から別の場所に簡単にコピーできます。 すべての静的ファイルは、モジュールのファイルディレクトリ内にあります。 マニフェスト内のファイルの操作は、ファイルリソースを使用して行われます。
Puppet-アーキテクチャ
以下は、Puppetアーキテクチャの概略図です。
パペットマスター
Puppet Masterは、構成に関連するすべてのものを処理する重要なメカニズムです。 Puppetエージェントを使用してノードに構成を適用します。
パペットエージェント
Puppetエージェントは、Puppetマスターによって管理される実際の作業マシンです。 Puppetエージェントデーモンサービスが実行されています。
構成リポジトリ
これは、すべてのノードとサーバー関連の構成が保存され、必要に応じてプルされるリポジトリです。
事実
カタログ
Puppetで記述されたすべてのマニフェストファイルまたは構成は、最初にカタログと呼ばれるコンパイル済み形式に変換され、後でそれらのカタログがターゲットマシンに適用されます。
Puppet-インストール
Puppetはクライアントサーバーアーキテクチャ上で動作し、サーバーをPuppetマスターとして、クライアントをPuppetノードとして呼び出します。 このセットアップは、クライアントとすべてのサーバーマシンの両方にPuppetをインストールすることで実現します。
ほとんどのプラットフォームでは、選択したパッケージマネージャーを介してPuppetをインストールできます。 ただし、一部のプラットフォームでは、 tarball または RubyGems をインストールすることで実行できます。
前提条件
Factorは、Chefに存在する Ohai に付随しない唯一の前提条件です。
標準OSライブラリ
基盤となるOSのライブラリの標準セットが必要です。 残りのすべてのシステムには、Ruby 1.8.2 +バージョンが付属しています。 以下は、OSで構成されるライブラリ項目のリストです。
- base64
- cgi
- ダイジェスト/md5
- etc
- fileutils
- ipaddr
- openssl
- strscan
- syslog
- uri
- ウェブリック
- webrick/https
- xmlrpc
ファクターのインストール
説明したように、 facter はRubyの標準版には付属していません。 したがって、ターゲットシステムでファクターを取得するには、ファクターライブラリがPuppetの前提条件であるため、ソースから手動でファクターをインストールする必要があります。
このパッケージは複数のプラットフォームで使用できますが、安全のために tarball を使用してインストールできます。これは最新バージョンの取得に役立ちます。
まず、 wget ユーティリティを使用して、Puppetの公式サイトから tarball をダウンロードします。
次に、tarファイルを展開します。 CDコマンドを使用して、展開したディレクトリ内に移動します。 最後に、 facter ディレクトリ内にある install.rb ファイルを使用してファクターをインストールします。
ソースからのPuppetのインストール
まず、 wget を使用してPuppetサイトからPuppet tarballをインストールします。 次に、目的の場所にtarballを抽出します。 CD コマンドを使用して、作成したディレクトリ内を移動します。 install.rb ファイルを使用して、基礎となるサーバーにPuppetをインストールします。
Ruby Gemを使用したPuppetとFacterのインストール
Puppet-設定
Puppetをシステムにインストールしたら、次のステップは特定の初期操作を実行するようにPuppetを構成することです。
マシンのファイアウォールポートを開く
Puppetサーバーでクライアントのサーバーを一元管理するには、すべてのマシンで指定されたポートを開く必要があります。 8140 は、構成しようとしているマシンで使用されていない場合に使用できます。 すべてのマシンでTCP通信とUDP通信の両方を有効にする必要があります。
構成ファイル
Puppetのメイン構成ファイルは etc/puppet/puppet.conf です。 すべての構成ファイルは、Puppetのパッケージベースの構成で作成されます。 Puppetの構成に必要な構成のほとんどはこれらのファイルに保存され、Puppetの実行が行われると、それらの構成が自動的に選択されます。 ただし、Webサーバーや外部認証局(CA)の構成などの特定のタスクについては、Puppetにはファイルと設定の個別の構成があります。
サーバー構成ファイルは、Puppetマスターとも呼ばれる conf.d ディレクトリにあります。 これらのファイルは、デフォルトで /etc/puppetlabs/puppetserver/conf.d パスの下にあります。 これらの構成ファイルはHOCON形式であり、JSONの基本構造を保持しますが、より読みやすくなっています。 Puppetの起動が行われると、conf.dディレクトリからすべての.congファイルを取得し、それらを使用して構成を変更します。 これらのファイルの変更は、サーバーの再起動時にのみ行われます。
リストファイルと設定ファイル
- global.conf
- webserver.conf
- web-routes.conf
- puppetserver.conf
- auth.conf
- master.conf(非推奨)
- ca.conf(非推奨)
Puppetには、Puppetの各コンポーネントに固有のさまざまな構成ファイルがあります。
Puppet.conf
Puppet.confファイルはPuppetのメイン構成ファイルです。 Puppetは同じ構成ファイルを使用して、必要なすべてのPuppetコマンドとサービスを構成します。 Puppet master、Puppet agent、Puppet apply、証明書の定義など、Puppetに関連するすべての設定がこのファイルで定義されています。 Puppetは要件ごとにそれらを参照できます。
構成ファイルは、設定がメインセクションの特定のアプリケーションセクションに移動できる標準のiniファイルに似ています。
メイン構成セクション
Puppetマスター構成ファイル
詳細概要
Puppet設定では、使用されるファイルには複数の設定セクションがあり、各セクションには異なる種類の複数の設定があります。
構成セクション
Puppet構成ファイルは、主に次の構成セクションで構成されています。
- メイン-これは、Puppetのすべてのコマンドおよびサービスで使用されるグローバルセクションとして知られています。 メインセクションでデフォルト値を定義します。このデフォルト値は、puppet.confファイルにあるセクションでオーバーライドできます。
- マスター-このセクションは、PuppetマスターサービスおよびPuppet certコマンドによって参照されます。
- エージェント-このセクションは、Puppetエージェントサービスによって参照されます。
- ユーザー-あまり一般的ではないコマンドの多くと同様に、Puppet applyコマンドで主に使用されます。
構成ファイルの主要コンポーネント
構成ファイルの主要コンポーネントは次のとおりです。
コメント行
Puppetでは、コメント行は(#)記号で始まります。 これは、任意の量のスペースで意図する場合があります。 同じ行内に部分的なコメントを含めることもできます。
設定行
設定行で構成する必要があります-
- 任意の量の先行スペース(オプション)
- 設定の名前
- 等号=符号、任意の数のスペースで囲むことができます
- 設定の値
変数を設定する
ほとんどの場合、設定の値は単一の単語になりますが、特別な場合には、特別な値はほとんどありません。
パス
構成ファイルの設定で、ディレクトリのリストを取得します。 これらのディレクトリを定義する際、システムパス区切り文字( *nixプラットフォームでは(:)、Windowsではセミコロン(;)で区切る必要があることに注意してください。
定義では、最初にリストされているファイルディレクトリがスキャンされ、見つからない場合は後でリスト内の他のディレクトリに移動します。
ファイルとディレクトリ
単一のファイルまたはディレクトリを取るすべての設定は、オプションのアクセス許可のハッシュを受け入れることができます。 サーバーの起動時に、Puppetはリスト内のこれらのファイルまたはディレクトリを強制します。
上記のコードでは、許可されるハッシュは所有者、グループ、およびモードです。 所有者キーとグループキーの有効な値は2つだけです。
Puppet-環境設定
Puppetでは、すべての環境に environment.conf ファイルがあります。 マスターが特定の環境に割り当てられたノードまたはすべてのノードにサービスを提供している場合、このファイルはいくつかのデフォルト設定をオーバーライドできます。
ロケーション
Puppetでは、定義されているすべての環境で、environment.confファイルはホーム環境の最上位、マニフェストおよびモジュールディレクターのすぐ隣にあります。 たとえば、環境がデフォルトディレクトリ*(Vipin/testing/environment)にある場合、テスト環境の構成ファイルは *Vipin/testing/environments/test/environment.conf にあります。
例
フォーマット
Puppetのすべての構成ファイルは、同じ方法で同じINIのような形式を使用します。 environment.conf ファイルは、他のpuppet.confファイルと同じINIのような形式に従います。 environment.confと puppet.conf の唯一の違いは、environment.confファイルに[main]セクションを含めることができないことです。 environment.confファイルのすべての設定は、configセクションの外部にある必要があります。
値の相対パス
許可される設定のほとんどは、ファイルパスまたはパスのリストを値として受け入れます。 パスのいずれかが関連するパスである場合、先頭のスラッシュまたはドライブ文字なしで始まります。ほとんどの場合、その環境のメインディレクトリに関連して解決されます。
値の内挿
Environment.conf設定ファイルは、他の設定の値を変数として使用できます。 environment.confファイルに挿入できる複数の便利な変数があります。 ここにいくつかの重要な変数のリストがあります-
- $ basemodulepath -モジュールパス設定にディレクトリを含めるのに便利です。 Puppetエンジンは basemodulepath のモジュールを使用するため、通常、Puppetエンタープライズユーザーはこの値 modulepath を含める必要があります。
- $ environment -config_versionスクリプトのコマンドライン引数として便利です。 この変数は、config_version設定でのみ補間できます。
- $ codedir -ファイルの検索に役立ちます。
許可された設定
デフォルトでは、Puppet environment.confファイルは、リストされている構成の4つの設定のみをオーバーライドできます。
- モジュールパス
- マニフェスト
- Config_version
- Environment_timeout
モジュールパス
これは、environment.confファイルの重要な設定の1つです。 modulepathで定義されているすべてのディレクターは、デフォルトでPuppetによってロードされます。 これは、Puppetがモジュールをロードする場所です。 これを明示的に設定する必要があります。 この上記の設定が設定されていない場合、Puppetのすべての環境のデフォルトのモジュールパスは-
マニフェスト
これはメインのマニフェストファイルを定義するために使用され、Puppetマスターは、環境の構成に使用される定義済みのマニフェストからカタログを起動およびコンパイルするときに使用します。 これで、単一のファイル、ファイルのリスト、または定義済みのアルファベット順で評価およびコンパイルする必要がある複数のマニフェストファイルで構成されるディレクトリを定義できます。
environment.confファイルでこの設定を明示的に定義する必要があります。 そうでない場合、Puppetは環境のデフォルトのマニフェストディレクトリをメインマニフェストとして使用します。
Config_version
Config_versionは、カタログとイベントを識別するために使用される明確なバージョンとして定義できます。 Puppetがデフォルトでマニフェストファイルをコンパイルするとき、PuppetマスターがPuppetノードで定義されたカタログを適用するときに生成されるカタログとレポートに構成バージョンを追加します。 Puppetはスクリプトを実行して上記のすべての手順を実行し、生成されたすべての出力をConfig_versionとして使用します。
環境タイムアウト
これは、特定の環境のデータをロードするためにPuppetが使用する必要がある時間の詳細を取得するために使用されます。 値がpuppet.confファイルで定義されている場合、これらの値はデフォルトのタイムアウト値をオーバーライドします。
サンプルenvironment.confファイル
上記のコードの $ confdir は、環境設定ファイルが置かれているディレクトリのパスです。 $ environment は、構成が行われている環境の名前です。
実稼働環境の構成ファイル
人形-マスター
Puppetでは、Puppetマスターのクライアントサーバーアーキテクチャは、セットアップ全体の制御機関と見なされます。 Puppetマスターはセットアップでサーバーとして機能し、すべてのノードのすべてのアクティビティを制御します。
Puppetマスターとして機能する必要のあるサーバーでは、Puppetサーバーソフトウェアが実行されている必要があります。 このサーバーソフトウェアは、ノード上のすべてのアクティビティを制御する重要なコンポーネントです。 このセットアップで覚えておくべき重要なポイントの1つは、セットアップで使用するすべてのマシンにスーパーユーザーがアクセスできるようにすることです。 Puppetマスターをセットアップする手順は次のとおりです。
前提条件
- プライベートネットワークDNS *-フォワードおよびバックワードを設定する必要があります。各サーバーには一意のホスト名が必要です。 DNSが構成されていない場合、インフラストラクチャとの通信にプライベートネットワークを使用できます。
Puppet Master Serverの作成
作成するPuppetマスターは、Puppetをホスト名として使用するCentOS 7×64マシン上にあります。 Puppetマスターを作成するための最小システム構成は、2つのCPUコアと1GBのメモリです。 このマスターで管理するノードの数によっては、構成のサイズも大きくなる場合があります。 インフラストラクチャでは、2 GB RAMを使用して構成されたものよりも大きくなります。
Host Name | Role | Private FQDN |
---|---|---|
Brcleprod001 | Puppet master | bnrcleprod001.brcl.com |
次に、PuppetマスターSSL証明書を生成する必要があり、すべてのノードの構成ファイルにマスターマシンの名前がコピーされます。
NTPのインストール
Puppetマスターは、どのセットアップでもエージェントノードの中央機関であるため、ノードにエージェント証明書を発行するときに発生する可能性のある構成の問題を回避するために、正確なシステム時間を維持することはPuppetマスターの重要な責任の1つです。
時間の競合の問題が発生した場合、マスターとノードの間に時間の不一致があると、証明書が期限切れに見える可能性があります。 ネットワークタイムプロトコルは、このような問題を回避するための重要なメカニズムの1つです。
利用可能なタイムゾーンのリスト
上記のコマンドは、利用可能なタイムゾーンの全リストを提供します。 地域にタイムゾーンの可用性を提供します。
次のコマンドを使用して、マシンに必要なタイムゾーンを設定できます。
CentOSマシンのyumユーティリティを使用して、PuppetサーバーマシンにNTPをインストールします。
上記のコマンドで設定したシステム時刻とNTPを同期します。
一般的には、マシンデータセンターの近くで利用可能な共通プールを使用するようにNTP構成を更新します。 このため、 /etc の下にあるntp.confファイルを編集する必要があります。
NTPプールのタイムゾーンからタイムサーバーを追加します。 ntp.confファイルは次のようになります。
設定を保存します。 サーバーを起動し、デーモンを有効にします。
Puppet Serverソフトウェアのセットアップ
Puppetサーバーソフトウェアは、Puppetマスターマシンで実行されるソフトウェアです。 Puppet agentソフトウェアを実行している他のマシンに構成をプッシュするのはマシンです。
次のコマンドを使用して、公式のPuppet labsコレクションリポジトリを有効にします。
puppetserverパッケージをインストールします。
Puppet Serverでメモリ割り当てを構成する
すでに説明したように、デフォルトでは、Puppetサーバーは2GB RAMマシン上で構成されます。 マシンで使用可能な空きメモリとサーバーが管理するノードの数に応じて、セットアップをカスタマイズできます。
viモードでpuppetサーバー構成を編集します
完了したら、保存して編集モードを終了します。
上記のセットアップがすべて完了したら、次のコマンドを使用してマスターマシンでPuppetサーバーを起動する準備ができました。
次に、マスターサーバーが起動するたびにパペットサーバーが起動するようにセットアップします。
Puppet.confマスターセクション
Puppet-エージェントのセットアップ
PuppetエージェントはPuppetラボが提供するソフトウェアアプリケーションで、Puppetクラスター内の任意のノードで実行されます。 Puppet masterを使用してサーバーを管理する場合は、Puppet agentソフトウェアをその特定のサーバーにインストールする必要があります。 一般に、Puppetエージェントは、特定のインフラストラクチャ上のPuppetマスターマシンを除くすべてのマシンにインストールされます。 Puppetエージェントソフトウェアには、ほとんどのLinux、UNIX、およびWindowsマシンで実行できる機能があります。 次の例では、CentOSマシンインストールPuppetエージェントソフトウェアを使用しています。
- ステップ1 *-次のコマンドで公式のPuppet labsコレクションリポジトリを有効にします。
- ステップ2 *-Puppetエージェントパッケージをインストールします。
- ステップ3 *-Puppetエージェントがインストールされたら、次のコマンドで有効にします。
Puppetエージェントの重要な機能の1つは、Puppetエージェントが初めて実行を開始したときに、SSL証明書を生成し、署名と承認のために管理するPuppetマスターに送信することです。 Puppetマスターは、エージェントの証明書署名リクエストを承認すると、エージェントノードと通信および管理できるようになります。
注-指定されたPuppetマスターを設定および管理する必要があるすべてのノードで上記の手順を繰り返す必要があります。
Puppet-SSL署名証明書のセットアップ
PuppetエージェントソフトウェアがPuppetノードで初めて実行されると、証明書が生成され、証明書署名要求がPuppetマスターに送信されます。 Puppetサーバーは、エージェントノードと通信して制御する前に、その特定のエージェントノードの証明書に署名する必要があります。 以下のセクションでは、署名要求に署名して確認する方法について説明します。
現在の証明書要求を一覧表示する
Puppetマスターで、次のコマンドを実行して、すべての未署名の証明書要求を表示します。
新しいエージェントノードをセットアップしたばかりなので、承認の要求が1つ表示されます。 以下が*出力*です。
先頭に+(記号)が含まれていません。これは、証明書がまだ署名されていないことを示します。
リクエストに署名する
Puppetエージェントの実行が新しいノードで行われたときに生成された新しい証明書要求に署名するために、Puppet cert signコマンドが使用され、証明書のホスト名が必要になります。署名する。 Brcleprod004.brcl.comの証明書があるので、次のコマンドを使用します。
以下が*出力*です。
パペットサーバーは、サイン証明書が属するノードと通信できるようになりました。
Puppetセットアップからのホストの取り消し
ホストをセットアップから削除して再度追加する必要がある場合、カーネルの再構築の構成には条件があります。 これらは、Puppet自体では管理できない状態です。 次のコマンドを使用して実行できます。
すべての署名済みリクエストの表示
次のコマンドは、要求が承認されたことを示す+(署名)付きの署名付き証明書のリストを生成します。
以下はその output です。
上記が完了したら、Puppetマスターが新しく追加されたノードを管理できるインフラストラクチャを準備します。
Puppet-r10Kのインストールと設定
Puppetには、r10kというコード管理ツールがあり、開発、テスト、本番など、Puppetで設定できるさまざまな種類の環境に関連する環境設定の管理に役立ちます。 これは、環境関連の構成をソースコードリポジトリに保存するのに役立ちます。 ソース管理レポジトリブランチを使用して、r10kはレポジトリにあるモジュールを使用してPuppetマスターマシンのインストールおよび更新環境に環境を作成します。
Gemファイルを使用して、r10kを任意のマシンにインストールできますが、モジュール方式であり、最新バージョンを取得するために、rpmおよびrpmパッケージマネージャーを使用します。 以下は同じ例です。
/etc/puppet/puppet.confで環境を構成します
r10k Configの構成ファイルを作成する
Puppetマニフェストとモジュールのインストール
15分ごとに環境の更新を続ける必要があるため、同じ環境のcronジョブを作成します。
インストールのテスト
すべてが正常に機能するかどうかをテストするには、PuppetモジュールのPuppetマニフェストをコンパイルする必要があります。 次のコマンドを実行し、結果としてYAML出力を取得します。
Puppet-Puppetセットアップの検証
Puppetでは、セットアップをローカルでテストできます。 したがって、Puppetマスターとノードをセットアップしたら、セットアップをローカルで検証します。 VagrantとVagrant boxをローカルにインストールする必要があります。これはセットアップをローカルでテストするのに役立ちます。
仮想マシンのセットアップ
ローカルでセットアップをテストしているため、実際にPuppetマスターを実行する必要はありません。 これは、サーバーで実際にPuppetマスターを実行せずに、Puppetを使用してPuppetセットアップ検証のコマンドを適用するだけでよいことを意味します。 Puppet applyコマンドは、構成ファイル内の仮想マシンのホスト名に応じて、 local/etc/puppet からの変更を適用します。
セットアップをテストするために実行する必要がある最初のステップは、次の Vagrantfile をビルドしてマシンを起動し、 /etc/puppet フォルダーを所定の場所にマウントすることです。 必要なすべてのファイルは、次の構造を持つバージョン管理システム内に配置されます。
ディレクトリ構造
Vagrant File
上記のコードでは、 update-puppet.sh という名前のシェルスクリプトを実行しようとしているシェルプロビジョニングツールを使用しています。 スクリプトは、Vagrantファイルが配置されているディレクトリと同じディレクトリに存在し、スクリプトの内容は以下のとおりです。
さらに処理する場合、ユーザーはマニフェストディレクトリ内に site.pp という名前のマニフェストファイルを作成する必要があります。これにより、VMにソフトウェアがインストールされます。
ユーザーは、必要なVagrantファイル構成で上記のスクリプトの準備ができたら、テストディレクトリにcdして* vagrant upコマンド*を実行できます。 これにより、後で新しいVMが起動し、Puppetがインストールされ、シェルスクリプトを使用して実行されます。
出力は次のようになります。
複数マシン構成の検証
複数のマシンの構成をローカルでテストする必要がある場合は、Vagrant構成ファイルを変更するだけで簡単に実行できます。
新しい構成済みVagrantファイル
SSLユーティリティをインストールする必要がある新しい運用サーバーがあるとします。 次の構成で古いマニフェストを拡張するだけです。
マニフェストファイルの構成を変更した後、テストディレクトリに移動し、 brclelocal003.brcl.com と brcleprod004.brcl.com の両方のマシンを起動する基本的なvagrant upコマンドを実行するだけです。 この例では、* vagrant up productionコマンド*を実行することで実行できる実動マシンを起動しようとしています。 Vagrantファイルで定義されているproductionという名前の新しいマシンを作成し、SSLパッケージをインストールします。
Puppet-コーディングスタイル
Puppetのコーディングスタイルは、マシン構成のインフラストラクチャをコードに変換する際に従う必要のあるすべての標準を定義します。 Puppetは、リソースを使用して、定義されたすべてのタスクを実行および実行します。
Puppetの言語定義は、管理が必要なターゲットマシンを管理するために必要な、構造化された方法ですべてのリソースを指定するのに役立ちます。 Puppetは、Rubyをエンコード言語として使用します。Rubyには、コード側の単純な構成で物事を非常に簡単に実行できる複数の組み込み機能があります。
基本単位
Puppetは、理解と管理が容易な複数の基本的なコーディングスタイルを使用しています。 以下にいくつかのリストを示します。
リソース
Puppetでは、リソースは基本モデリングユニットとして知られ、ターゲットシステムを管理または変更するために使用されます。 リソースは、ファイル、サービス、パッケージなどのシステムのすべての側面をカバーしています。 Puppetには、ユーザーまたは開発者がマシンの特定のユニットの管理に役立つカスタムリソースを開発できる組み込み機能が付属しています。
Puppetでは、すべてのリソースは "define" または "classes" を使用して集約されます。 これらの集約機能は、モジュールの編成に役立ちます。 以下は、Puppetが複数の属性をサポートできる複数のタイプ、タイトル、および属性のリストで構成されるサンプルリソースです。 Puppetの各リソースには独自のデフォルト値があり、必要に応じてオーバーライドできます。
ファイルのサンプルPuppetリソース
次のコマンドでは、特定のファイルのアクセス許可を指定しようとしています。
上記のコマンドがいずれかのマシンで実行されるたびに、システム内のpasswdファイルが説明どおりに構成されていることを確認します。 前のファイル:コロンはリソースのタイトルで、Puppet設定の他の部分でリソースとして参照できます。
タイトルに加えてローカル名を指定する
常に同じタイトルを使用することで、OS関連のロジックを繰り返すことなく、構成でファイルリソースを参照するのが非常に簡単になります。
別の例として、ファイルに依存するサービスの使用があります。
この依存関係により、 sshdconfig ファイルが変更されると、 sshd サービスは常に再起動します。 ここで覚えておくべきポイントは、 File [sshdconfig] は小文字の場合のFileとしての宣言ですが、これを FILE [sshdconfig] に変更すると、参照になります。
リソースを宣言する際に留意する必要がある基本的なポイントの1つは、構成ファイルごとに1回だけ宣言できることです。 同じリソースの宣言を複数回繰り返すと、エラーが発生します。 この基本概念により、Puppetは構成が適切にモデル化されていることを確認します。
リソースの依存関係を管理する機能もあり、複数の関係を管理するのに役立ちます。
メタパラメータ
メタパラメーターは、Puppetではグローバルパラメーターとして知られています。 メタパラメーターの重要な機能の1つは、Puppetのあらゆるタイプのリソースで機能することです。
リソースのデフォルト
デフォルトのリソース属性値を定義する必要がある場合、Puppetは、タイトルのない大文字のリソース仕様を使用して、それをアーカイブするための構文セットを提供します。
たとえば、すべての実行可能ファイルのデフォルトパスを設定する場合は、次のコマンドで実行できます。
上記のコマンドでは、最初のステートメントExecはexecリソースのデフォルト値を設定します。 Execリソースには、完全修飾パスまたは実行可能ファイルのように見えるパスが必要です。 これにより、設定全体に対して単一のデフォルトパスを定義できます。 デフォルトは、Puppetのすべてのリソースタイプで機能します。
デフォルトはグローバル値ではありませんが、定義されているスコープまたはそのすぐ隣の変数にのみ影響します。 完全な構成のために default を定義する場合は、次のセクションで default とクラスを定義します。
リソースコレクション
集約は、物を一緒に収集する方法です。 Puppetは、非常に強力な集約の概念をサポートしています。 Puppetでは、Puppetの基本単位であるリソースをグループ化するために集約が使用されます。 Puppetでのこの集約の概念は、 classes および definition として知られる2つの強力なメソッドを使用して実現されます。
クラスと定義
クラスは、ノードの基本的な側面のモデリングを担当します。 ノードはWebサーバーであり、この特定のノードはそれらの1つであると言うことができます。 Puppetでは、プログラミングクラスはシングルトンであり、ノードごとに1回評価できます。
一方、定義は単一のノードで何度も使用できます。 言語を使用して独自のPuppetタイプを作成した場合と同様に機能します。 それらは、毎回異なる入力で複数回使用されるように作成されます。 これは、変数値を定義に渡すことができることを意味します。
クラスと定義の違い
クラスと定義の唯一の重要な違いは、建物構造の定義とリソースの割り当て中にクラスがノードごとに1回だけ評価されることです。一方、定義は同じ単一ノードで複数回使用されます。
クラス
Puppetのクラスはclassキーワードを使用して導入され、その特定のクラスのコンテンツは、次の例に示すように中括弧で囲まれています。
次の例では、上記と同様のショートハンドを使用しました。
Puppetクラスの継承
Puppetでは、継承のOOPコンセプトがデフォルトでサポートされており、クラスは新しく作成されたクラスに完全なコードビットをコピーして貼り付けることなく、以前の機能を拡張できます。 継承により、サブクラスは親クラスで定義されたリソース設定をオーバーライドできます。 継承を使用する際に留意すべき重要な点の1つは、クラスは1つ以上の親クラスからのみ機能を継承できないことです。
親クラスで指定されたロジックを元に戻す必要がある場合は、* undefコマンド*を使用できます。
継承を使用する別の方法
Puppetのネストされたクラス
Puppetは、ネストされたクラスの使用を許可するクラスのネストの概念をサポートします。これは、一方のクラスが他方のクラスの内部にあることを意味します。 これは、モジュール性とスコープの達成に役立ちます。
パラメータ化されたクラス
Puppetでは、クラスは機能を拡張して、パラメーターをクラスに渡すことができます。
クラスでパラメータを渡すには、次の構成を使用できます-
Puppetで覚えておくべき重要な点の1つは、include関数を使用してパラメーターを持つクラスを追加するのではなく、結果のクラスを定義として追加できることです。
クラスのパラメーターとしてのデフォルト値
実行ステージ
Puppetは実行ステージの概念をサポートします。これは、特定のリソースまたは複数のリソースを管理するために、ユーザーが要件に従って複数のステージを追加できることを意味します。 この機能は、ユーザーが複雑なカタログを開発する場合に非常に役立ちます。 複雑なカタログには、定義するリソース間の依存関係に影響を与えないように注意しながら、コンパイルする必要のあるリソースが多数あります。
実行ステージは、リソースの依存関係の管理に非常に役立ちます。 これは、特定のクラスにリソースのコレクションが含まれる定義済みの段階でクラスを追加することで実行できます。 実行ステージでは、Puppetは、カタログが実行され、Puppetノードに適用されるたびに、定義されたステージが指定された予測可能な順序で実行されることを保証します。
これを使用するには、既存のステージを超えて追加のステージを宣言する必要があります。Puppetは、必要な "→" および* "+>の前に同じリソース関係構文を使用して、指定された順序で各ステージを管理するように構成できます」*。 この関係により、各ステージに関連付けられたクラスの順序が保証されます。
Puppet宣言構文を使用した追加ステージの宣言
ステージが宣言されると、ステージを使用するメイン以外のステージにクラスを関連付けることができます。
クラスapt-keyに関連付けられているすべてのリソースが最初に実行されます。 Sendmailのすべてのリソースがメインクラスになり、Apacheに関連付けられたリソースが最終段階になります。
定義
Puppetでは、マニフェストファイル内のリソースの収集は、クラスまたは定義によって行われます。 定義はPuppetのクラスに非常に似ていますが、* defineキーワード(クラスではない)*で導入され、継承ではなく引数をサポートします。 異なるパラメーターを使用して、同じシステムで複数回実行できます。
たとえば、同じシステム上で複数のリポジトリを作成しようとしているソースコードリポジトリを制御する定義を作成する場合、クラスではなく定義を使用できます。
ここで注意すべき重要な点は、変数を定義で使用する方法です。 ( $ )ドル記号変数を使用します。 上記では、$ titleを使用しました。 定義には、名前とタイトルを表すことができる$ titleと$ nameの両方を含めることができます。 デフォルトでは、$ titleと$ nameは同じ値に設定されますが、タイトル属性を設定して、異なる名前をパラメーターとして渡すことができます。 $ titleと$ nameは定義でのみ機能し、クラスや他のリソースでは機能しません。
モジュール
モジュールは、特定のPuppetノード(エージェント)に構成変更を適用するためにPuppetマスターが使用するすべての構成のコレクションとして定義できます。 これらは、特定のタスクを実行するために必要なさまざまな種類の構成のポータブルコレクションとしても知られています。 たとえば、モジュールには、PostfixとApacheの構成に必要なすべてのリソースが含まれている場合があります。
ノード
ノードは非常に単純な残りのステップであり、定義したもの(「これはWebサーバーの外観」)を、それらの命令を実行するために選択されたマシンと一致させる方法です。
ノード定義は、継承を含むクラスとまったく同じように見えますが、ノード(Puppetクライアントを実行する管理対象コンピューター)がPuppetマスターデーモンに接続すると、定義されたノードのリストでその名前が検索されます。 定義された情報はノードに対して評価され、ノードはその構成を送信します。
ノード名には、短いホスト名または完全修飾ドメイン名(FQDN)を使用できます。
上記の定義は、www.vipin.comというノードを作成し、一般的なApacheクラスとSquidクラスを含みます
同じ構成を異なるノードに送信するには、各ノードをコンマで区切ります。
一致するノードの正規表現
ノードの継承
ノードは限定された継承モデルをサポートします。 クラスと同様に、ノードは他の1つのノードからのみ継承できます。
上記のコードでは、www.testing2.comは、追加のロードバランサークラスに加えて、www.testing.comからすべての機能を継承しています。
高度なサポート機能
引用-ほとんどの場合、Puppetで文字列を引用する必要はありません。 文字で始まる英数字の文字列は、引用符なしで残されます。 ただし、負でない値の文字列を引用符で囲むことは常にベストプラクティスです。
引用付き変数補間
これまでのところ、定義に関して変数について述べてきました。 これらの変数を文字列で使用する必要がある場合は、一重引用符ではなく二重引用符を使用してください。 一重引用符の文字列は変数の補間を行いませんが、二重引用符の文字列は行います。 変数を \ {} で囲むと、一緒に使いやすくなり、理解しやすくなります。
ベストプラクティスとして、文字列の補間を必要としないすべての文字列に一重引用符を使用する必要があります。
大文字
大文字化は、特定のリソースのデフォルト属性の参照、継承、および設定に使用されるプロセスです。 基本的には、2つの基本的な使用方法があります。
- 参照-すでに作成されたリソースを参照する方法です。 主に依存関係の目的で使用され、リソースの名前を大文字にする必要があります。 例、require ⇒ file [sshdconfig]
- 継承-サブクラスから親クラスの設定をオーバーライドする場合、リソース名の大文字バージョンを使用します。 小文字バージョンを使用すると、エラーが発生します。
- デフォルト属性値の設定-タイトルなしで大文字のリソースを使用すると、リソースのデフォルトが設定されます。
配列
Puppetでは、複数の領域で配列を使用できます[1、2、3]。
ホスト定義のエイリアスなど、いくつかの型メンバーは、値に配列を受け入れます。 複数のエイリアスを持つホストリソースは、次のようになります。
上記のコードは、3つのエイリアス*「satu」、「dua」、「tiga」を含むホスト *'one.brcletest.com' をホストリストに追加します。 1つのリソースに複数のリソースを追加する場合は、次の例に示すように実行できます。
変数
Puppetは、他のほとんどのプログラミング言語と同様に複数の変数をサポートしています。 Puppet変数は $ で示されます。
前述のように、Puppetは宣言型言語です。つまり、その範囲と割り当て規則は命令型言語とは異なります。 主な違いは、変数の値を決定するためにファイル内の順序に依存するため、1つのスコープ内で変数を変更できないことです。 宣言言語では順序は関係ありません。
可変スコープ
変数スコープは、定義されているすべての変数が有効かどうかを定義します。 最新の機能と同様に、Puppetは現在動的にスコープされています。これは、Puppetの用語では、定義されたすべての変数が、定義された場所ではなくスコープで評価されることを意味します。
修飾変数
Puppetは、クラスまたは定義内での修飾変数の使用をサポートしています。 これは、ユーザーが定義した、または定義しようとしている他のクラスで同じ変数を使用する場合に非常に役立ちます。
上記のコードでは、$ other変数の値がコンテンツを評価します。
条件付き
条件は、定義された条件または必要な条件が満たされたときに、ユーザーがステートメントまたはコードのセットを実行したい状況です。 Puppetは2種類の条件をサポートしています。
マシンの正しい値を選択するために定義されたリソース内でのみ使用できるセレクター条件。
ステートメント条件は、マニフェストでより広く使用される条件であり、ユーザーが同じマニフェストファイルに含めたい追加のクラスを含めるのに役立ちます。 クラス内でリソースの異なるセットを定義するか、他の構造的な決定を下します。
セレクター
セレクターは、ユーザーがファクトまたは他の変数に基づいてデフォルト値とは異なるリソース属性と変数を指定したい場合に役立ちます。 Puppetでは、セレクターインデックスは複数値の三元演算子のように機能します。 セレクターは、マニフェストで定義され、条件に一致する値なしでカスタムのデフォルト値を定義することもできます。
Puppet 0.25.0以降のバージョンでは、セレクターを正規表現として使用できます。
上記の例では、セレクターの $ Sysoperenv 値はLinuxまたはUbuntuのいずれかに一致し、ビンは選択された結果になります。そうでない場合、ユーザーは未定義として設定されます。
ステートメント条件
ステートメント条件は、Puppetの他のタイプの条件ステートメントであり、シェルスクリプトのswitch case条件に非常によく似ています。 これでは、caseステートメントの複数のセットが定義され、指定された入力値が各条件と照合されます。
指定された入力条件に一致するcaseステートメントが実行されます。 このcaseステートメント条件には戻り値がありません。 Puppetでは、条件ステートメントの非常に一般的なユースケースは、基盤となるオペレーティングシステムに基づいて一連のコードビットを実行することです。
Caseステートメントでは、複数の条件をコンマで区切って指定することもできます。
If-Elseステートメント
Puppetは、条件ベースの操作の概念をサポートしています。 それを実現するために、If/elseステートメントは、条件の戻り値に基づいて分岐オプションを提供します。 次の例に示すように-
最新バージョンのPuppetは、式の値に基づいてifステートメントも分岐できる変数式をサポートしています。
コードの多様性を高め、複雑な条件付き操作を実行するために、Puppetは次のコードに示すようにネストされたif/elseステートメントをサポートしています。
仮想リソース
仮想リソースは、実現しない限りクライアントに送信されないリソースです。
以下は、Puppetで仮想リソースを使用する構文です。
上記の例では、コレクションで使用できる定義を実現するために、ユーザーvipinが仮想的に定義されています。
コメント
コード行のセットとその機能について追加のノードを作成するために、任意のコードビットでコメントが使用されます。 Puppetには、現在2種類のコメントがサポートされています。
- Unixシェルスタイルのコメント。 彼らは、独自の行または次の行にすることができます。
- 複数行のCスタイルのコメント。
次に、シェルスタイルのコメントの例を示します。
以下は複数行コメントの例です。
演算子の優先順位
Puppetオペレーターの優先順位は、ほとんどのシステムの標準的な優先順位(最高から最低まで)に準拠しています。
以下は式のリストです
- ! =しない */=回と除算
- -+ =マイナス、プラス
- << >> =左シフトと右シフト
- ==!= =等しくない、等しい *> = <⇒ ⇐より大きい、より小さいまたは等しい、より大きい、より小さい
比較式
比較式は、指定された条件が満たされたときにユーザーが一連のステートメントを実行する場合に使用されます。 比較式には、==式を使用した等価性のテストが含まれます。
等しくない例
算術式
ブール式
ブール式は、or、and、&notを使用して可能です。
正規表現
Puppetは、=〜(一致)および!〜(非一致)を使用した正規表現一致をサポートしています。
大文字小文字の区別とセレクターの正規表現の一致は、各正規表現の限定スコープ変数を作成します。
同様に、正常に終了しない限り、下のコマンドを除き、常にコマンドを実行しない限り、使用できます。
テンプレートの使用
テンプレートは、Puppetの複数のモジュール間で使用される定義済みの構造を希望し、それらのモジュールが複数のマシンに配布される場合に使用されます。 テンプレートを使用するための最初のステップは、テンプレートメソッドを使用してテンプレートコンテンツをレンダリングするテンプレートを作成することです。
Puppetは、組織とモジュール性を強化するために、ローカルファイルを扱う際にほとんど仮定を行いません。 Puppetは、モジュールディレクトリ内のapache/templatesフォルダー内でvhost.erbテンプレートを探します。
サービスの定義とトリガー
Puppetには、特定のマシンまたは環境で実行されているすべてのサービスのライフサイクルを管理できるserviceというリソースがあります。 サービスリソースは、サービスが初期化および有効化されていることを確認するために使用されます。 また、サービスの再起動にも使用されます。
たとえば、以前のTomcatのテンプレートでは、apache仮想ホストを設定する場所があります。 仮想ホストの変更後にapacheを確実に再起動したい場合は、次のコマンドを使用してapacheサービスのサービスリソースを作成する必要があります。
リソースを定義するとき、再起動をトリガーするために通知オプションを含める必要があります。
Puppet-マニフェストファイル
Puppetでは、Rubyプログラミング言語を使用して記述され、*。pp *の拡張子で保存されたすべてのプログラムは*マニフェスト*と呼ばれます。 一般的に、ターゲットホストマシンの作成または管理を目的として構築されたすべてのPuppetプログラムは、マニフェストと呼ばれます。 Puppetで記述されたすべてのプログラムは、Puppetコーディングスタイルに従います。
Puppetの中核は、リソースの宣言方法と、これらのリソースが状態をどのように表しているかです。 どのマニフェストでも、ユーザーはクラスと定義を使用してグループ化されたさまざまな種類のリソースのコレクションを持つことができます。
場合によっては、Puppetマニフェストに目的の状態を達成するための条件ステートメントを含めることもできます。 ただし、最終的にはすべてのリソースが正しい方法で定義および使用され、カタログに変換された後に適用された定義済みマニフェストが設計されたタスクを実行できることを確認します。
マニフェストファイルのワークフロー
Puppetマニフェストは、次のコンポーネントで構成されています-
- ファイル(これらは、Puppetがそれらとは関係なく、単に拾い上げてターゲットの場所に配置するためのプレーンなファイルです)
- リソース
- テンプレート(これらは、ノード上で構成ファイルを構築するために使用できます)。
- Nodes (クライアントノードに関連するすべての定義はここで定義されます)
- クラス
注意点
- Puppetでは、すべてのマニフェストファイルはエンコード言語としてRubyを使用し、*。pp *拡張子で保存されます。
- 多くのマニフェストの「インポート」ステートメントは、Puppetの起動時にファイルをロードするために使用されます。 ディレクトリに含まれるすべてのファイルをインポートするには、import 'clients/ 'のような別の方法でimportステートメントを使用できます。 これにより、そのディレクトリ内のすべての .pp ファイルがインポートされます。
マニフェストの作成
変数の使用
マニフェストの作成中に、ユーザーは新しい変数を定義するか、マニフェストの任意の時点で既存の変数を使用できます。 Puppetはさまざまな種類の変数をサポートしていますが、文字列や文字列の配列など、頻繁に使用される変数はほとんどありません。 それらとは別に、他の形式もサポートされています。
文字列変数の例
ループを使用する
ループは、定義された条件が満たされるまで、同じコードセットで複数の反復を実行する場合に使用されます。 また、異なる値のセットを使用して反復タスクを実行するためにも使用されます。 10種類のタスクを10個作成します。 1つのタスクを作成し、ループを使用して、インストールするさまざまなパッケージでタスクを繰り返すことができます。
最も一般的には、異なる値でテストを繰り返すために配列が使用されます。
条件付きの使用
Puppetは、従来のプログラミング言語に見られる条件構造のほとんどをサポートしています。 条件を使用して、特定のタスクを実行するか、コードセットを実行するかを動的に定義できます。 if/elseおよびcaseステートメントと同様。 さらに、実行のような条件は、条件のように機能する属性もサポートしますが、コマンド出力のみを条件として受け入れます。
Puppet-モジュール
Puppetでは、モジュールはリソース、クラス、ファイル、定義、およびテンプレートのコレクションとして定義できます。 Puppetはモジュールの簡単な再配布をサポートします。これは、指定された汎用モジュールを記述し、簡単なコード変更をほとんどせずに複数回使用できるため、コードのモジュール化に非常に役立ちます。 たとえば、これにより、/etc/puppetでデフォルトのサイト構成が有効になり、Puppetによって出荷されるモジュールは/etc/share/puppetに適切に格納されます。
モジュール構成
Puppetモジュールには、コードの構造を定義し、宗派を制御するのに役立つ2つのパーティションがあります。
- モジュールの検索パスは、 puppetmasterd または masterd のコロンで区切られたディレクトリのリストを使用して構成されます。 puppetmasterd または masterd は、Puppetのマスター構成ファイルの後のセクションで、 modulepath パラメーターを使用します。
- fileserver.conf内のファイルサーバーモジュールのアクセス制御設定。そのモジュールのパス構成は常に無視され、パスを指定すると警告が生成されます。
モジュールソース
Puppetは、モジュールを保存するための別の場所をサポートしています。 モジュールは、特定のマシンの異なるファイルシステムに保存できます。 ただし、モジュールが格納されているすべてのパスは、一般的に modulepath として知られる構成変数で指定する必要があります。これは、Puppetがすべてのモジュールディレクトリをスキャンし、起動時にロードするパス変数です。
合理的なデフォルトパスは次のように設定できます-
または、/etc/puppetディレクトリを特別な匿名モジュールとして確立し、常に最初に検索することもできます。
モジュールの命名
Puppetは特定のモジュールと同じ命名規則に従います。モジュール名は通常の単語で、[-\\ w +](文字、単語、数字、アンダースコア、ダッシュ)に一致し、名前空間の区切り文字を含まない必要があります。 モジュール階層に関しては許可される場合がありますが、新しいモジュールの場合はネストできません。
モジュール内部組織
ユーザーがPuppetで新しいモジュールを作成すると、同じ構造に従い、次のコードに示すように、特定のディレクトリ構造に配置されたマニフェスト、分散ファイル、プラグイン、テンプレートが含まれます。
モジュールが作成されるたびに、マニフェストディレクトリ内の指定された修正場所に init.pp マニフェストファイルが含まれます。 このマニフェストファイルは、特定のモジュールで最初に実行され、その特定のモジュールに関連付けられているすべてのクラスのコレクションを含むデフォルトファイルです。 追加の .pp ファイルは、manifestsフォルダーの下に直接追加できます。 追加の.ppファイルを追加する場合は、クラスにちなんで名前を付ける必要があります。
モジュールを使用することで達成される重要な機能の1つは、コードの共有です。 モジュールは本質的に自己完結型である必要があります。つまり、どこからでも任意のモジュールを含めることができ、Puppetの起動時にロードされるモジュールパスにドロップできる必要があります。 モジュールの助けを借りて、Puppetインフラストラクチャコーディングのモジュール性を得ることができます。
例
固定のauto.homesマップをインストールし、テンプレートからauto.masterを生成するautofsモジュールを検討してください。
ファイルシステムには次のファイルがあります。
モジュール検索
Puppetは事前定義された構造に従い、定義された構造に複数のディレクトリとサブディレクトリが含まれます。 これらのディレクトリには、特定のアクションを実行するためにモジュールが必要とするさまざまな種類のファイルが含まれています。 少し舞台裏の魔法は、適切なファイルが適切なコンテキストに関連付けられていることを確認します。 すべてのモジュール検索は、コロンで区切られたディレクトリのリストであるmodulepath内で行われます。
ファイルサーバー上のファイル参照では、同様の参照が使用され、puppet://$servername/modules/autofs/auto.homesへの参照がモジュールパス内のファイルautofs/files/auto.homesに解決されます。
コマンドラインクライアントとパペットマスターの両方でモジュールを使用できるようにするには、from puppet:///pathのURLを使用できます。 i.e. 明示的なサーバー名のないURL。 このようなURLは、 Puppet と* puppetd によってわずかに異なります。 Puppetは、ローカルファイルシステムでサーバーレスURLを検索します。
テンプレートファイルは、マニフェストおよびファイルと同様の方法で検索されます。テンプレート(「autofs/auto.master.erb」)に言及すると、puppetmasterは $ templatedir/autofs/auto.master.erb のファイルを最初に検索します。そして、モジュールパス上の autofs/templates/auto.master.erb 。 Puppetの下にあるすべてのPuppetバージョンでは、使用できます。 これは、モジュールの自動ロードと呼ばれます。 Puppetはモジュールからクラスと定義を自動ロードしようとします。
Puppet-ファイルサーバー
Puppetはクライアントとサーバーの概念に従い、セットアップ内の1台のマシンがPuppetサーバーソフトウェアが実行されているサーバーマシンとして機能し、残りがPuppetエージェントソフトウェアが実行されているクライアントとして機能します。 ファイルサーバーのこの機能は、複数のマシンにファイルをコピーするのに役立ちます。 Puppetのファイルサービス機能のこの機能は、中央のPuppetデーモンの一部として提供されます。 Puppetmasterdとクライアント関数は、ファイルオブジェクトとしてファイル属性を取得する際に重要な役割を果たします。
上記のコードスニペットのように、Puppetのファイルサービス機能は、ファイルサービスモジュールをサポートすることにより、ローカルファイルシステムトポロジを抽象化します。 ファイルサービングモジュールは次の方法で指定します。
ファイルフォーマット
Puppetディレクトリ構造では、デフォルトでファイルサーバー設定は /etc/puppet/fileserver.config ディレクトリにあります。ユーザーがこのデフォルト設定ファイルパスを変更したい場合は、新しい設定フラグを puppetmasterdに使用して実行できます。 。 構成ファイルはINIファイルに似ていますが、まったく同じではありません。
上記のコードスニペットに示すように、3つのオプションはすべて構成ファイルで表されます。 モジュール名は大括弧で囲みます。 パスは唯一の必須オプションです。 デフォルトのセキュリティオプションはすべてのアクセスを拒否するため、許可行が指定されていない場合、設定されるモジュールは誰でも利用できます。
パスには、ドメイン名、ホスト名、完全修飾ホスト名で動的に置き換えられる%d、%h、%Hのいずれかまたはすべてを含めることができます。 すべてがクライアントのSSL証明書から取得されます(ホスト名と証明書名に不一致がある場合は注意してください)。 これは、各クライアントのファイルが完全に個別に保持されるモジュールを作成するのに役立ちます。 例、プライベートホストキーの場合。
上記のコードスニペットでは、コードはクライアント client1.vipin.com からファイル/private/file.txtを検索しようとしています。/data/private/client1/file.txtで検索しますが、client2.vipin.comに対する同じ要求は、ファイルサーバー上のファイル/data/private/client2/file.txtを取得しようとします。
セキュリティ
Puppetは、Puppetファイルサーバー上のファイルを保護する2つの基本概念をサポートしています。 これは、特定のファイルへのアクセスを許可し、不要なファイルへのアクセスを拒否することにより実現されます。 デフォルトでは、Puppetはどのファイルへのアクセスも許可しません。 明示的に定義する必要があります。 アクセスを許可または拒否するためにファイルで使用できる形式は、IPアドレス、名前、またはグローバル許可を使用することです。
クライアントが、たとえばリバースプロキシとMongrelを使用してPuppetファイルサーバーに直接接続されていない場合、ファイルサーバーはすべての接続をPuppetクライアントではなくプロキシサーバーからのものとして認識します。 上記の場合、ホスト名に基づいてホスト名を制限することがベストプラクティスです。
ファイル構造を定義する際に注意すべき重要な点は、すべての拒否ステートメントが許可ステートメントの前に解析されることです。 したがって、いずれかの拒否ステートメントがホストと一致する場合、そのホストは拒否され、許可ファイルが今後のファイルに書き込まれない場合、ホストは拒否されます。 この機能は、特定のサイトの優先順位を設定するのに役立ちます。
ホスト名
任意のファイルサーバー構成で、次の例に示すように、完全なホスト名を使用するか、*ワイルドカードを使用してドメイン名全体を指定することにより、2つの方法でファイルホスト名を指定できます。
IPアドレス
任意のファイルサーバー構成で、完全なIPアドレスまたはワイルドカードアドレスを使用して、ホスト名と同様にファイルアドレスを指定できます。 CIDRシステム表記も使用できます。
グローバル許可
ユーザーが特定のモジュールにアクセスできるようにしたい場合、グローバル許可が使用されます。 これを行うには、単一のワイルドカードを使用して、全員がモジュールにアクセスできるようにします。
人形-事実と事実
Puppetは、環境変数として複数の値を保持することをサポートしています。 この機能は、 facter を使用してPuppetでサポートされています。 Puppetでは、ファクトは環境レベル変数を保持するスタンドアロンツールです。 Inは、BashまたはLinuxのenv変数に似ていると考えることができます。 ファクトに保存されている情報とマシンの環境変数が重複している場合があります。 Puppetでは、キーと値のペアは「ファクト」として知られています。 各リソースには独自のファクトがあり、Puppetでは、ユーザーは独自のカスタムファクトを構築するために活用できます。
- Facterコマンド*を使用して、すべての異なる環境変数とそれに関連する値をリストできます。 これらのファクトのコレクションには、すぐに使えるファクトが付属しており、コアファクトと呼ばれます。 コレクションにカスタムファクトを追加できます。
1つの変数のみを表示する場合。 次のコマンドを使用して実行できます。
ファクターがPuppetにとって重要である理由は、ファクターとファクトがPuppetコード全体で*「グローバル変数」*として利用可能であるためです。
テストする例
それをテストする
上記のコードスニペットでわかるように、 OperatingSystem を定義していません。 値を通常の変数としてソフトコード値 $ OperatingSystem に置き換えました。
Puppetでは、使用および定義できる事実には3つのタイプがあります-
- コアファクト
- カスタムファクト
- 外部の事実
コアファクトはトップレベルで定義され、コード内のすべてのポイントでアクセスできます。
人形の事実
エージェントがマスターにカタログを要求する直前に、エージェントはまず、キー値ペアの形式でそれ自体で利用可能な情報の完全なリストをコンパイルします。 エージェントに関する情報は、ファクターと呼ばれるツールによって収集され、各キーと値のペアはファクトと呼ばれます。 以下は、エージェントに関するファクトの一般的な出力です。
上記のコードでは、bashの「env」変数で使用可能な情報の一部とデータの一部が重複していることがわかります。 Puppetはデータを直接使用せず、代わりにファクターデータを使用します。Facterデータはグローバル変数として扱われます。
ファクトはトップレベル変数として利用可能になり、Puppetマスターはそれらを使用して、要求元エージェントのPuppetカタログをコンパイルできます。 係数は、$プレフィックス付きの通常の変数としてマニフェストで呼び出されます。
例
上記のマニフェストファイルは、 machineOperatingSystem.txt という単一のファイルについてのみ気にします。このファイルの内容は、 OperatingSystem という事実によって差し引かれます。
カスタムファクト
私たちが見た上記の事実はすべて、マシンの中核的な事実です。 次の方法でノードにこのカスタムファクトを追加できます-
- 「export FACTER…構文」を使用する
- $ LOAD_PATH設定を使用する
- ファクトライブラリ
- Pluginsync
「export FACTER」構文の使用
export FACTER _ \ {fact’s name}構文を使用して、ファクトを手動で追加できます。
例
$ LOAD_PATH設定の使用
Rubyでは、$ LOAD_PATHはBashの特殊パラメーターと同等です。 bash $ PATH変数に似ていますが、実際には$ LOAD_PATHは環境変数ではなく、事前定義された変数です。
$ LOAD_PATHには同義語「$:」があります。 この変数は、値を検索してロードする配列です。
ディレクトリファクタを作成し、*。pp *ファイルを追加し、それにコンテンツを追加する例を見てみましょう。
次のコンテンツをcustom_facts.rbファイルに追加します。
Facterは、$ LOAD_PATHにリストされているすべてのフォルダーをスキャンする方法で動作し、facterと呼ばれるディレクターを探します。 特定のフォルダーが見つかると、フォルダー構造内の任意の場所にロードされます。 このフォルダーを見つけると、そのファクターフォルダーでRubyファイルを探し、メモリ内の特定の構成に関するすべての定義済みファクトを読み込みます。
FACTERLIBを使用する
Puppetでは、FACTERLIBは$ LOAD_PATHと非常によく似ていますが、Rubyの特殊変数ではなく、OSレベルの環境パラメーターであるという重要な違いが1つあります。 デフォルトでは、環境変数は設定されていません。
FACTERLIBをテストするには、次の手順を実行する必要があります。
次の構造にtest_factsというフォルダーを作成します。
rbファイルに次の内容を追加します。.
exportステートメントを使用します。
新しいファクターをテストします。
外部の事実
ユーザーがプロビジョニング時に作成されたいくつかの新しいファクトを適用したい場合、外部ファクトは非常に役立ちます。 外部ファクトは、プロビジョニング段階でVMにメタデータを適用する重要な方法の1つです(例: vSphere、OpenStack、AWSなどを使用)
作成されたすべてのメタデータとその詳細をPuppetが使用して、カタログにどの詳細を適用するかを決定できます。
外部ファクトの作成
エージェントマシンで、以下に示すようにディレクトリを作成する必要があります。
ディレクトリに次の内容のシェルスクリプトを作成します。
スクリプトファイルの権限を変更します。
完了すると、キーと値のペアに存在する変数を見ることができます。
Puppetでカスタムファクトを作成できます。 参考として、Puppetサイトから次のリンクを使用してください。
https://docs.puppet.com/facter/latest/fact_overviewl#writing-structured-facts
Puppet-リソース
リソースは、特定のインフラストラクチャまたはマシンを設計および構築するために使用されるPuppetの主要な基本ユニットの1つです。 これらは主に、システム構成のモデリングと保守に使用されます。 Puppetには複数のタイプのリソースがあり、それらを使用してシステムアーキテクチャを定義したり、ユーザーが新しいリソースを構築および定義したりできます。
マニフェストファイルまたはその他のファイル内のPuppetコードのブロックは、リソース宣言と呼ばれます。 コードのブロックは、宣言型モデリング言語(DML)と呼ばれる言語で記述されています。 以下は、どのように見えるかの例です。
Puppetでは、特定のリソースタイプのリソース宣言はコードブロックで行われます。 次の例では、ユーザーは主に4つの事前定義されたパラメーターで構成されています。
- リソースタイプ-上記のコードスニペットでは、ユーザーです。
- リソースパラメータ-上記のコードスニペットでは、Vipinです。
- 属性-上記のコードスニペットでは、uid、shell、homeが確認されています。
- 値-これらは各プロパティに対応する値です。
各リソースタイプには、定義とパラメータを定義する独自の方法があり、ユーザーには、リソースの外観を選択する権限があります。
リソースタイプ
Puppetにはさまざまな種類のリソースがあり、それぞれ独自の機能を備えています。 これらのリソースタイプは、「describe」コマンドと「-list」オプションを使用して表示できます。
リソースタイトル
上記のコードスニペットでは、コードの同じファイルで使用される各リソースに固有のvipinとしてリソースタイトルがあります。 これは、このユーザーリソースタイプの一意のタイトルです。 競合が発生するため、同じ名前のリソースを持つことはできません。
リソースコマンドを使用すると、タイプuserを使用してすべてのリソースのリストを表示できます。
特定のユーザーのリソースの一覧表示
属性と値
リソースの本体は、属性と値のペアのコレクションで構成されています。 ここで、特定のリソースのプロパティの値を指定できます。 各リソースタイプには、キーと値のペアで設定できる独自の属性セットがあります。
特定のリソース属性に関する詳細を取得するために使用できるサブコマンドを説明します。 次の例では、ユーザーリソースに関する詳細と、その構成可能なすべての属性があります。
Puppet-リソース抽象化レイヤー
Puppetでは、Resource Abstraction Layer(RAL)は、インフラストラクチャ全体およびPuppetセットアップが機能するコア概念化モデルと見なすことができます。 RALでは、各アルファベットには次のように定義された独自の重要な意味があります。
リソース[R]
リソースは、Puppetの構成のモデリングに使用されるすべてのリソースと見なすことができます。 基本的には、Puppetにデフォルトで存在する組み込みリソースです。 これらは、事前定義されたリソースタイプに属するリソースのセットと見なすことができます。 これらは、オブジェクトがクラスのインスタンスである他のプログラミング言語のOOPコンセプトに似ています。 Puppetでは、そのリソースはリソースタイプのインスタンスです。
抽象化[A]
抽象化は、リソースがターゲットOSから独立して定義される重要な機能と考えることができます。 言い換えると、マニフェストファイルを書き込む際に、ユーザーはターゲットマシンやその特定のマシンに存在するOSについて心配する必要はありません。 抽象化では、リソースはPuppetエージェントに存在する必要があるものに関する十分な情報を提供します。
Puppetは、舞台裏で発生するすべての機能またはマジックを処理します。 リソースとOSに関係なく、Puppetはターゲットマシンに設定を実装します。ユーザーはPuppetが舞台裏でどのように動作するか心配する必要はありません。
抽象化では、Puppetはその実装からリソースを分離します。 このプラットフォーム固有の構成は、プロバイダーから提供されます。 プロバイダーとともに複数のサブコマンドを使用できます。
レイヤー[L]
リソースの収集という観点から、マシン全体のセットアップと構成を定義し、PuppetのCLIインターフェースを介して表示および管理することができます。
ユーザーリソースタイプの例
テストリソース
Puppetでは、リソースのテストは、ターゲットノードの構成に使用するリソースを最初に適用する必要があることを直接示しているため、それに応じてマシンの状態が変化します。
テストのために、リソースをローカルに適用します。* user = vipin *で定義済みのリソースがあるため。 リソースを適用する1つの方法はCLIです。 これは、完全なリソースを単一のコマンドに再書き込みし、それをリソースサブコマンドに渡すことで実行できます。
適用されたリソースをテストします。
上記の出力は、リソースがシステムに適用され、Vipinという名前で新しいユーザーが作成されたことを示しています。 上記のコードはすべてテストされており、動作するコードなので、自分でテストすることをお勧めします。
人形-テンプレート
テンプレートの評価
テンプレートは、単純な関数を使用して評価されます。
テンプレートの完全なパスを指定するか、通常/var/puppet/templatesにあるPuppetのtemplatedir内のすべてのテンプレートをプルすることができます。 puppet –-configprint templatedirを実行すると、ディレクトリの場所を見つけることができます。
テンプレートは常にクライアントではなくパーサーによって評価されます。つまり、puppetmasterdを使用している場合、テンプレートはサーバー上にあればよく、クライアントにダウンロードする必要はありません。 クライアントがテンプレートを使用することと、ファイルのすべてのコンテンツを文字列として指定することとの間に違いはありません。 これは、puppetの起動段階でクライアント固有の変数がpuppetmasterdによって最初に学習されることを明確に示しています。
テンプレートを使用する
以下は、サイトをテストするためのTomcat設定を生成する例です。
以下はテンプレート定義です。
これにより、各テンプレートファイルが個別のファイルにプッシュされ、Apacheにこれらの構成ファイルを読み込むよう指示するだけで済みます。
テンプレートを結合する
次のコマンドを使用して、2つのテンプレートを簡単に組み合わせることができます。
テンプレートでの反復
Puppetテンプレートは配列反復もサポートしています。 アクセスしている変数が配列である場合、それを反復処理できます。
次のようなテンプレートを作成できます。
上記のコマンドは、次の結果を生成します。
テンプレートの条件
テンプレートと変数
テンプレートを使用して、ファイルの内容を記入するだけでなく、変数を記入することもできます。
未定義の変数
変数を使用する前に定義されているかどうかを確認する必要がある場合、次のコマンドが機能します。
スコープ外の変数
lookupvar関数を使用して、スコープ外の変数を明示的に探すことができます。
サンプルプロジェクトテンプレート
人形-クラス
Puppetクラスは、ターゲットノードまたはマシンを目的の状態にするためにグループ化されたリソースのコレクションとして定義されます。 これらのクラスは、Puppetモジュール内にあるPuppetマニフェストファイル内で定義されます。 クラスを使用する主な目的は、マニフェストファイルまたは他のPuppetコード内での同じコードの繰り返しを減らすことです。
以下は、Puppetクラスの例です。
上記の例では、ユーザーが存在する必要がある2つのクライアントがあります。 お気づきのように、同じリソースを2回繰り返しました。 2つのノードを結合する際に同じタスクを実行しない1つの方法。
この方法でノードをマージして構成を実行することはお勧めできません。 これは、クラスを作成し、作成されたクラスを次のようにノードに含めることで簡単に実現できます。
注目すべき点は、クラス構造がどのように見えるか、classキーワードを使用して新しいリソースを追加した方法です。 Puppetの各構文には独自の機能があります。 したがって、選択する構文は条件によって異なります。
パラメータ化されたクラス
上記の例のように、クラスを作成してノードに含める方法を見てきました。 現在、同じクラスを使用する各ノードで異なるユーザーを必要とする場合など、各ノードで異なる構成が必要な状況があります。 この機能は、パラメーター化されたクラスを使用してPuppetで提供されます。 新しいクラスの構成は、次の例のようになります。
上記のsite.ppマニフェストをノードに適用すると、各ノードの出力は次のようになります。
しょー
しょー
次のコードに示すように、クラスパラメーターのデフォルト値を設定することもできます。
パペット-機能
Puppetの基本開発言語はRubyであるため、Puppetは他のプログラミング言語としての機能をサポートしています。 statement および rvalue 関数の名前で知られる2種類の関数をサポートします。
- Statements は独立しており、戻り値の型はありません。 これらは、新しいマニフェストファイルに他のPuppetモジュールをインポートするなどのスタンドアロンタスクを実行するために使用されます。
- Rvalue は値を返すため、割り当てやcaseステートメントなど、ステートメントに値が必要な場合にのみ使用できます。
Puppetでの機能の実行の鍵は、Puppetマスターでのみ実行され、クライアントまたはPuppetエージェントでは実行されないことです。 したがって、それらはPuppetマスターで使用可能なコマンドとデータにのみアクセスできます。 すでに存在するさまざまな種類の関数があり、ユーザーにも要件ごとにカスタム関数を作成する権限があります。 いくつかの組み込み関数を以下にリストします。
ファイル機能
ファイルリソースのファイル機能は、Puppetでモジュールをロードし、目的の出力を文字列の形式で返すことです。 探す引数は<モジュール名>/<ファイル>参照です。これは、Puppetモジュールのファイルディレクトリからモジュールをロードするのに役立ちます。
script/tesingscript.shと同様に、<モジュール名>/script/files/testingscript.shからファイルをロードします。 関数には絶対パスを読み取って受け入れる機能があり、ディスク上のどこからでもファイルをロードするのに役立ちます。
機能を含める
Puppetでは、インクルード関数は他のプログラミング言語のインクルード関数に非常によく似ています。 1つまたは複数のクラスの宣言に使用され、それらのクラス内に存在するすべてのリソースを評価し、最終的にそれらをカタログに追加します。 動作方法は、include関数がクラス名、クラスのリスト、またはクラス名のコンマ区切りリストを受け入れることです。
- include ステートメントを使用する際に留意すべきことの1つは、1つのクラスで複数回使用できますが、1つのクラスを1回しか含めることができないという制限があります。 含まれるクラスがパラメーターを受け入れる場合、include関数は、<class name>
- <parameter name>を検索キーとして使用して、それらの値を自動的に検索します。
インクルード関数は、クラスが宣言されたときにクラスに含まれるようにしません。そのため、含まれる関数を使用する必要があります。 宣言されたクラスとそれを取り巻くクラスに依存関係を作成することさえしません。
インクルード関数では、クラスのフルネームのみが許可され、相対名は許可されません。
定義済み関数
Puppetでは、定義された関数は、特定のクラスまたはリソースタイプが定義されている場所を判断するのに役立ち、ブール値を返すかどうかを返します。 defineを使用して、特定のリソースが定義されているか、定義された変数に値があるかを判断することもできます。 定義された関数を使用する際に留意すべき重要な点は、この関数は少なくとも1つの文字列引数を取ります。これは、クラス名、型名、リソース参照、または「$ name」形式の変数参照です。
モジュールによって提供される型を含む、ネイティブ関数型と定義済み関数型の両方の関数チェックを定義します。 タイプとクラスは名前で一致します。 この関数は、リソース参照を使用して、リソースの減速と一致します。
関数の一致を定義する
Puppet-カスタム関数
前の章で説明したように、関数はユーザーにカスタム関数を開発する特権を提供します。 Puppetは、カスタム関数を使用して解釈能力を拡張できます。 カスタム関数は、Puppetモジュールとマニフェストファイルの能力を向上および拡張するのに役立ちます。
カスタム関数の作成
関数を書く前に心に留めておかなければならないことがいくつかあります。
- Puppetでは、関数はコンパイラーによって実行されます。つまり、すべての関数はPuppetマスターで実行され、同じためにPuppetクライアントを扱う必要はありません。 情報が事実の形式である場合、関数はエージェントとのみ対話できます。
- Puppetマスターはカスタム関数をキャッチします。つまり、Puppet関数に何らかの変更を加えた場合、Puppetマスターを再起動する必要があります。
- 関数はサーバー上で実行されます。つまり、関数に必要なファイルはサーバー上に存在する必要があり、関数がクライアントマシンへの直接アクセスを必要とする場合は何もできません。
- 使用可能な関数には完全に2つのタイプがあります。1つは、値を返すRvalue関数と、何も返さないステートメント関数です。
- 関数を含むファイルの名前は、ファイル内の関数の名前と同じでなければなりません。 そうしないと、自動的にロードされません。
カスタム関数を配置する場所
すべてのカスタム関数は個別の .rb ファイルとして実装され、モジュール間で配布されます。 lib/puppet/parser/functionにカスタム関数を配置する必要があります。 関数は、次の場所から .rb ファイルからロードできます。
- $ libdir/puppet/parser/functions
- Rubyのpuppet/parser/functionsサブディレクトリ$ LOAD_PATH
新しい関数を作成する
- 新しい関数は、 *puppet
- parser :: Functions* モジュール内の newfunction メソッドを使用して作成または定義されます。 関数名をシンボルとして newfunction メソッドに渡し、コードをブロックとして実行する必要があります。 次の例は、/userディレクトリ内のファイルに文字列を書き込むために使用される関数です。
ユーザーが関数を宣言すると、以下に示すようにマニフェストファイルで使用できます。
Puppet-環境
ソフトウェア開発および配信モデルには、特定の製品またはサービスのテストに使用されるさまざまな種類のテスト環境があります。 標準的な慣行として、主に開発、テスト、本番の3種類の環境があり、それぞれに独自のセット構成があります。
Puppetは、Ruby on Railsと同じラインに沿った複数の環境の管理をサポートしています。 これらの環境の作成の背後にある重要な要素は、SLA契約のさまざまなレベルで管理するための簡単なメカニズムを提供することです。 場合によっては、古いソフトウェアを使用せずに、マシンを常に稼働させる必要があります。 ここで、他の環境は最新であり、テスト目的で使用されます。 より重要なマシンのアップグレードに使用されます。
Puppetは、標準の本番環境、テスト環境、および開発環境の構成に固執することをお勧めしますが、ここでは、要件に応じてカスタム環境を作成することもできます。
環境目標
環境によって分割されたセットアップの主な目標は、Puppetがモジュールとマニフェストの異なるソースを持つことができることです。 その後、実稼働ノードに影響を与えることなく、テスト環境で構成の変更をテストできます。 これらの環境は、ネットワークのさまざまなソースにインフラストラクチャを展開するためにも使用できます。
Puppet Masterで環境を使用する
環境のポイントは、ファイルのどのマニフェスト、モジュール、テンプレートをクライアントに送信する必要があるかをテストすることです。 したがって、Puppetは、これらの情報の環境固有のソースを提供するように構成する必要があります。
Puppet環境は、サーバーのpuppet.confにpre-environmentセクションを追加し、環境ごとに異なる構成ソースを選択するだけで実装されます。 これらの事前環境セクションは、メインセクションに優先して使用されます。
上記のコードでは、開発環境のクライアントはディレクトリ /usr/share/puppet/development にあるsite.ppマニフェストファイルを使用し、Puppetは*/usr/share/puppet/developmentのモジュールを検索します/modulesディレクトリ*。
環境の有無にかかわらずPuppetを実行すると、デフォルトでsite.ppファイルと、メイン構成セクションのマニフェストとmodulepathの値で指定されたディレクトリになります。
実際に環境を構成するのに意味のある構成はほとんどありません。これらのパラメーターはすべて、クライアントの構成をコンパイルするために使用するファイルの指定を中心に展開されます。
以下はパラメーターです。
- モジュールパス-Puppetでは、基本的な標準モードとして、すべての環境が共有する標準モジュールディレクトリを作成し、次にカスタムモジュールを保存できる事前環境ディレクトリを作成するのが最適です。 モジュールパスは、Puppetが環境関連のすべての設定ファイルを探す場所です。
- Templatedir -テンプレートディレクトリは、関連するテンプレートのすべてのバージョンが保存される場所です。 モジュールはこれらの設定よりも優先されるべきですが、各環境で特定のテンプレートの異なるバージョンを持つことができます。
- マニフェスト-これは、エントリポイントスクリプトとして使用する構成を定義します。
複数のモジュールを備えたPuppetsは、構成のモジュール性を実現するのに役立ちます。 Puppetで複数の環境を使用できます。これは、主にモジュールに依存している場合に非常によく機能します。 変更をモジュールにカプセル化することにより、変更を環境に移行するのが簡単になります。 ファイルサーバーは、環境固有のモジュールパスを使用します。個別のマウントされたディレクトリではなく、モジュールからファイルを提供する場合、この環境は環境固有のファイルを取得でき、最終的に現在の環境はマニフェストファイル内の$ environment変数でも利用可能になります。
クライアント環境の設定
環境設定に関連するすべての設定は、puppet.confファイルで行われます。 Puppetクライアントが使用する環境を指定するには、クライアントのpuppet.confファイルで環境設定変数の値を指定できます。
構成ファイル内の上記の定義は、構成ファイルがどの環境でテストされているかを定義しています。
また、コマンドラインでこれを指定することもできます-
あるいは、Puppetは環境設定での動的な値の使用もサポートしています。 開発者は、静的な値を定義するのではなく、他のクライアント属性または外部データソースに基づいてクライアント環境を作成するカスタムファクトを作成するために活用します。 推奨される方法は、カスタムツールを使用することです。 これらのツールはノードの環境を指定することができ、一般的にノード情報を指定するのにはるかに優れています。
パペット検索パス
Puppetは単純な検索パスを使用して、ターゲットマシンに適用する必要がある構成を決定します。 同様に、Puppetの検索パスは、適用する必要のある適切な値を取得しようとする場合に非常に便利です。 Puppetが適用する必要のある値を検索する場所は、以下にリストされているように複数あります。
- コマンドラインで指定された値
- 環境固有のセクションで指定された値
- 実行可能ファイル固有のセクションで指定された値
- メインセクションで指定された値
Puppet-タイプとプロバイダー
Puppetタイプは、個々の構成管理に使用されます。 Puppetには、サービスタイプ、パッケージタイプ、プロバイダータイプなどのさまざまなタイプがあります。 各タイプにはプロバイダーがあります。 プロバイダーは、さまざまなプラットフォームまたはツールで構成を処理します。 たとえば、パッケージタイプにはaptitude、yum、rpm、およびDGMプロバイダーがあります。 多くのタイプがあり、Puppetは管理が必要な優れたスペクトル構成管理項目をカバーしています。
Puppetはベース言語としてRubyを使用します。 存在するすべてのPuppetタイプおよびプロバイダーは、Ruby言語で記述されています。 標準のエンコード形式に従っているため、リポジトリを管理するリポジトリの例に示すように単純に作成できます。 ここでは、タイプリポジトリとプロバイダーのsvnとgitを作成します。 リポジトリタイプの最初の部分は、タイプ自体です。 タイプは通常lib/puppet/typeに保存されます。 このために、 repo.rb というファイルを作成します。
ファイルに次のコンテンツを追加します。
- 上記のスクリプトでは、repoという名前の新しいタイプを作成するブロック「 *Puppet
- Type.newtype(:repo)do* 」を作成しました。 次に、追加したい詳細のレベルを追加するのに役立つ@docがあります。 次のステートメントはEnsurableです。基本的なensureプロパティを作成します。 Puppetタイプは、 ensure プロパティを使用して構成アイテムの状態を判断します。
例
ensureステートメントは、Puppetに対して、作成、破棄、およびプロバイダ内に存在する3つのメソッド以外を指示します。 これらの方法は、次の機能を提供します-
- リソースを作成するコマンド
- リソースを削除するコマンド
- リソースの存在を確認するコマンド
その後、これらのメソッドとそのコンテンツを指定するだけです。 Puppetは、それらの周りにサポートインフラストラクチャを作成します。
次に、sourceという新しいパラメーターを定義します。
ソースは、ソースリポジトリを取得/クローン/チェックアウトする場所をリポジトリタイプに通知します。 これでは、validateと呼ばれるフックも使用しています。 プロバイダーセクションでは、定義したリポジトリの有効性をチェックするgitとsvnを定義しました。
最後に、コードでパスと呼ばれるもう1つのパラメーターを定義しました。
これは、取得される新しいコードを配置する場所を指定する値タイプです。 ここでも、validateフックを使用して、適切性の値をチェックするブロックを作成します。
Subversionプロバイダーの使用例
上記で作成したタイプを使用して、Subversionプロバイダーから始めましょう。
上記のコードでは、 fileutils ライブラリが必要であり、メソッドを使用する 'fileutils' が必要であると事前に定義されています。
- 次に、プロバイダーをブロックPuppet
- Type.type(:repo).provide(:svn)doとして定義しました。これは、これがレポと呼ばれるタイプのプロバイダーであることをPuppetに伝えます。
次に、プロバイダーにドキュメントを追加できる desc を追加しました。 このプロバイダーが使用するコマンドも定義しました。 次の行では、作成、削除、存在などのリソースの機能を確認しています。
リソースを作成する
上記のすべてが完了したら、次のコードに示すように、クラスとマニフェストファイルで使用されるリソースを作成します。
Puppet-RESTful API
Puppetは、PuppetマスターとPuppetエージェント間の通信チャネルとしてRESTful APIを使用します。 以下は、このRESTful APIにアクセスするための基本的なURLです。
REST APIセキュリティ
Puppetは通常、セキュリティとSSL証明書の管理を行います。 ただし、クラスターの外部でRESTful APIを使用する場合は、マシンに接続しようとするときに証明書を独自に管理する必要があります。 Puppetのセキュリティポリシーは、残りのauthconfigファイルを使用して構成できます。
REST APIのテスト
Curlユーティリティは、RESTful API接続を休める基本的なユーティリティとして使用できます。 以下は、REST API curlコマンドを使用してノードのカタログを取得する方法の例です。
次の一連のコマンドでは、SSL証明書を設定しているだけです。これは、SSLディレクトリの場所と使用されているノードの名前によって異なります。 たとえば、次のコマンドを見てみましょう。
上記のコマンドでは、戻す形式を指定するヘッダーと、実稼働環境で brcleprod001 のカタログを生成するためのRESTful URLを送信するだけで、次の出力が生成されます。
PuppetマスターからCA証明書を取得する別の例を考えてみましょう。 署名されたSSL証明書で認証される必要はありません。これは、認証される前に必要なことです。
Puppet Master APIリファレンス
認証済みリソース(有効な署名済み証明書が必要)。
カタログ
証明書失効リスト
証明書リクエスト
レポートレポートを提出する
Node-特定のノードに関する事実
ステータス-テストに使用
Puppet Agent APIリファレンス
マシンに新しいエージェントがセットアップされると、デフォルトでは、PuppetエージェントはHTTP要求をリッスンしません。 puppet.confファイルに「listen = true」を追加して、Puppetで有効にする必要があります。 これにより、Puppetエージェントの起動時にPuppetエージェントがHTTPリクエストをリッスンできるようになります。
事実
実行-クライアントをパペットターンまたはパペットキックのように更新します。
Puppet-ライブプロジェクト
Puppetノードに構成とマニフェストを適用するライブテストを実行するために、ライブで動作するデモを使用します。 これを直接コピーして貼り付けて、構成の動作をテストできます。 ユーザーが同じコードセットを使用する場合は、次のコードスニペットに示されているのと同じ命名規則を使用する必要があります。
新しいモジュールの作成から始めましょう。
新しいモジュールの作成
httpd構成のテストと適用の最初のステップは、モジュールを作成することです。 これを行うには、ユーザーは自分の作業ディレクトリをPuppetモジュールディレクトリに変更し、基本的なモジュール構造を作成する必要があります。 構造の作成は、手動で、またはPuppetを使用してモジュールのボイラープレートを作成することで実行できます。
注-Puppet module generateコマンドでは、Puppet forgeの仕様に準拠するために、モジュール名が[ユーザー名]-[モジュール]の形式を取る必要があります。
新しいモジュールには、マニフェストディレクトリを含むいくつかの基本的なファイルが含まれています。 ディレクトリには、モジュールのメインマニフェストファイルであるinit.ppという名前のマニフェストが既に含まれています。 これは、モジュールの空のクラス宣言です。
モジュールには、 init.pp というマニフェストを含むテストディレクトリも含まれています。 このテストマニフェストには、manifest/init.pp内のlive-moduleクラスへの参照が含まれています。
Puppetはこのテストモジュールを使用してマニフェストをテストします。 これで、構成をモジュールに追加する準備ができました。
HTTPサーバーのインストール
Puppetモジュールは、httpサーバーを実行するために必要なパッケージをインストールします。 これには、httpdパッケージの構成を定義するリソース定義が必要です。
モジュールのマニフェストディレクトリで、httpd.ppという新しいマニフェストファイルを作成します
このマニフェストには、モジュールのすべてのHTTP構成が含まれます。 分離のために、httpd.ppファイルをinit.ppマニフェストファイルとは別にします
httpd.ppマニフェストファイルに次のコードを配置する必要があります。
このコードは、httpdというtest-moduleのサブクラスを定義してから、httpdパッケージのパッケージリソース宣言を定義します。 ensure ⇒ installed属性は、必要なパッケージがインストールされているかどうかを確認します。 インストールされていない場合、Puppetはyumユーティリティを使用してインストールします。 次に、このサブクラスをメインマニフェストファイルに含めます。 init.ppマニフェストを編集する必要があります。
次は、モジュールをテストする時間です。
puppet applyコマンドは、ターゲットシステムのマニフェストファイルに存在する構成を適用します。 ここでは、メインのinit.ppを参照するテストinit.ppを使用しています。 -noopは、構成の予行演習を実行します。これは、出力のみを表示しますが、実際には何もしません。
出力は以下のとおりです。
ハイライト行は、== installed属性の結果です。 current_value不在は、Puppetがhttpdパッケージがインストールされていることを検出したことを意味します。 –noopオプションを指定しないと、Puppetはhttpdパッケージをインストールします。
httpdサーバーの実行
httpdサーバーをインストールした後、他のリソース減速を使用してサービスを開始する必要があります:サービス
httpd.ppマニフェストファイルを編集し、次のコンテンツを編集する必要があります。
以下は、上記のコードから達成した目標のリストです。
- ensure ⇒ running statusは、サービスが実行されているかどうかを確認し、実行されていない場合は有効にします。
- enable ⇒ true属性は、システムの起動時に実行するサービスを設定します。
- require ⇒ Package ["httpd"] 属性は、あるリソースの減速と他のリソースの減速の順序関係を定義します。 上記の場合、httpパッケージのインストール後にhttpdサービスが確実に開始されます。 これにより、サービスと各パッケージの間に依存関係が作成されます。
puppet applyコマンドを実行して、変更を再度テストします。
httpdサーバーの構成
上記の手順が完了したら、HTTPサーバーをインストールして有効にします。 次のステップは、サーバーに何らかの構成を提供することです。 デフォルトでは、httpdはWebホストポート80を提供する/etc/httpd/conf/httpd.confでいくつかのデフォルト設定を提供します。 いくつかの追加のホストを追加して、ユーザー固有の機能をWebホストに提供します。
可変入力が必要なため、テンプレートを使用して追加のポートを提供します。 templateというディレクトリを作成し、test-server.config.erbというファイルを新しいディレクタに追加して、次のコンテンツを追加します。
上記のテンプレートは、標準のapache-tomcatサーバー構成フォーマットに従います。 唯一の違いは、Rubyエスケープ文字を使用してモジュールから変数を注入することです。 システムの完全修飾ドメイン名を保存するFQDNがあります。 これは*システムファクト*として知られています。
システムファクトは、各システムのパペットカタログを生成する前に各システムから収集されます。 Puppetはfacterコマンドを使用してこの情報を取得し、facterを使用してシステムに関するその他の詳細を取得できます。 httpd.ppマニフェストファイルにハイライト行を追加する必要があります。
これは、次のことを達成するのに役立ちます-
- これにより、サーバー構成ファイル(/etc/httpd/conf.d/test-server.conf)のファイルリソース宣言が追加されます。 このファイルの内容は、以前に作成されたtest-serverconf.erbテンプレートです。 このファイルを追加する前に、インストールされているhttpdパッケージも確認します。
- これは、Webサーバーのディレクトリ(/var/www/test-server)を作成する2番目のファイルリソース宣言を追加します。
- 次に、 notify ⇒ Service ["httpd"] attribute を使用して、構成ファイルとhttpsサービスの関係を追加します。 これにより、構成ファイルに変更があるかどうかがチェックされます。 存在する場合、Puppetはサービスを再起動します。
次に、メインマニフェストファイルにhttpd_portを含めます。 そのためには、メインのinit.ppマニフェストファイルを終了し、次のコンテンツを含める必要があります。
これにより、httpdポートがデフォルト値の80に設定されます。 次に、Puppet applyコマンドを実行します。
出力は次のようになります。
ファイアウォールの構成
サーバーと通信するには、ポートを開く必要があります。 ここでの問題は、異なる種類のオペレーティングシステムが異なる方法でファイアウォールを制御することです。 Linuxの場合、6より下のバージョンはiptablesを使用し、バージョン7はfirewalldを使用します。
適切なサービスを使用するというこの決定は、システムファクトとそのロジックを使用してPuppetによってある程度処理されます。 そのためには、まずOSを確認してから、適切なファイアウォールコマンドを実行する必要があります。
- これを実現するには、testmodule
- httpクラス内に次のコードスニペットを追加する必要があります。
上記のコードは次を実行します-
- operatingsystemmajrelease を使用すると、使用されているOSがバージョン6か7かが決まります。
- バージョンが6の場合、必要なすべての構成コマンドを実行して、Linux 6バージョンを構成します。
- OSバージョンが7の場合、ファイアウォールの構成に必要なすべてのコマンドが実行されます。
- 両方のOSのコードスニペットには、httpパッケージのインストール後にのみ構成が実行されるようにするロジックが含まれています。
最後に、Puppet applyコマンドを実行します。
SELinuxの構成
バージョン7以降のLinuxマシンで作業しているため、http通信を行うように設定する必要があります。 SELinuxは、デフォルトでHTTPサーバーへの非標準アクセスを制限します。 カスタムポートを定義する場合、SELinuxを構成してそのポートへのアクセスを提供する必要があります。
- Puppetには、ブール値やモジュールなどのSELinux機能を管理するためのリソースタイプが含まれています。 ここでは、ポート設定を管理するためにsemanageコマンドを実行する必要があります。 このツールはpolicycoreutils-pythonパッケージの一部であり、デフォルトではred-hatサーバーにはインストールされません。 上記を実現するには、test-module
- httpクラス内に次のコードを追加する必要があります。
上記のコードは次を実行します-
- require ⇒ Package ['policycoreutils-python']は、必要なpythonモジュールがインストールされていることを確認します。
- Puppetはsemanageを使用して、httpd_portを検証可能として使用してポートを開きます。
- before ⇒サービスは、httpdサービスが開始する前にこのコマンドを実行するようにします。 SELinuxコマンドの前にHTTPDが開始された場合、SELinuxはサービスリクエストとサービスリクエストを失敗させます。
最後に、Puppet applyコマンドを実行します
Puppetは最初にpythonモジュールをインストールしてからポートアクセスを構成し、最後にhttpdサービスを開始します。
WebホストでのHTMLファイルのコピー
上記の手順で、httpサーバーの構成が完了しました。 これで、Puppetが設定できるWebベースのアプリケーションをインストールする準備ができたプラットフォームができました。 テストするために、いくつかのサンプルhtmlインデックスWebページをサーバーにコピーします。
ファイルディレクトリ内にindexlファイルを作成します。
マニフェストディレクトリ内にマニフェストapp.ppを作成し、次のコンテンツを追加します。
- この新しいクラスには、単一のリソース減速が含まれています。 これにより、モジュールのファイルディレクトリからウェブサーバーにファイルがコピーされ、その権限が設定されます。 必須属性により、test-module
- httpクラスがtest-module :: appを適用する前に構成を正常に完了することが保証されます。
最後に、メインのinit.ppマニフェストに新しいマニフェストを含める必要があります。
次に、applyコマンドを実行して、実際に何が起こっているかをテストします。 出力は次のようになります。
強調表示された行は、indexlファイルがWebホストにコピーされた結果を示しています。
モジュールの完成
上記のすべての手順で、作成した新しいモジュールを使用する準備が整いました。 モジュールのアーカイブを作成する場合は、次のコマンドを使用して実行できます。