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をカスタマイズ可能なポートで定義する場合は、次の式を使用して実行できます。

Listen <% = @httpd_port %>

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

静的ファイル

静的ファイルは、特定のタスクを実行するために必要になることがある一般的なファイルとして定義できます。 Puppetを使用して、ある場所から別の場所に簡単にコピーできます。すべての静的ファイルは、モジュールのファイルディレクトリ内にあります。マニフェスト内のファイルの操作は、ファイルリソースを使用して行われます。

Puppet-アーキテクチャ

以下は、Puppetアーキテクチャの概略図です。

アーキテクチャ

パペットマスター

Puppet Masterは、構成に関連するすべてのものを処理する重要なメカニズムです。 Puppetエージェントを使用してノードに構成を適用します。

パペットエージェント

Puppetエージェントは、Puppetマスターによって管理される実際の作業マシンです。 Puppetエージェントデーモンサービスが実行されています。

構成リポジトリ

これは、すべてのノードとサーバー関連の構成が保存され、必要に応じてプルされるリポジトリです。

事実

*Facts* は、ノードまたはマスターマシンに関連する詳細であり、基本的に任意のノードの現在のステータスを分析するために使用されます。 事実に基づいて、変更はどのターゲットマシンでも行われます。 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 をダウンロードします。

$ wget http://puppetlabs.com/downloads/facter/facter-latest.tgz  ------: 1

次に、tarファイルを展開します。 CDコマンドを使用して、展開したディレクトリ内に移動します。最後に、 facter ディレクトリ内にある install.rb ファイルを使用してファクターをインストールします。

$ gzip -d -c facter-latest.tgz | tar xf - -----: 2
$ cd facter-* ------: 3
$ sudo ruby install.rb # or become root and run install.rb -----:4

ソースからのPuppetのインストール

まず、 wget を使用してPuppetサイトからPuppet tarballをインストールします。次に、目的の場所にtarballを抽出します。 CD コマンドを使用して、作成したディレクトリ内を移動します。 install.rb ファイルを使用して、基礎となるサーバーにPuppetをインストールします。

# get the latest tarball
$ wget http://puppetlabs.com/downloads/puppet/puppet-latest.tgz -----: 1

# untar and install it
$ gzip -d -c puppet-latest.tgz | tar xf - ----: 2
$ cd puppet-* ------: 3
$ sudo ruby install.rb # or become root and run install.rb -------: 4

Ruby Gemを使用したPuppetとFacterのインストール

# Installing Facter
$ wget http://puppetlabs.com/downloads/gems/facter-1.5.7.gem
$ sudo gem install facter-1.5.7.gem

# Installing Puppet
$ wget http://puppetlabs.com/downloads/gems/puppet-0.25.1.gem
$ sudo gem install puppet-0.25.1.gem

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ファイルに似ています。

メイン構成セクション

[main]
certname = Test1.vipin.com
server = TestingSrv
environment = production
runinterval = 1h

Puppetマスター構成ファイル

[main]
certname = puppetmaster.vipin.com
server = MasterSrv
environment = production
runinterval = 1h
strict_variables = true
[master]

dns_alt_names = MasterSrv,brcleprod01.vipin.com,puppet,puppet.test.com
reports = puppetdb
storeconfigs_backend = puppetdb
storeconfigs = true
environment_timeout = unlimited

詳細概要

Puppet設定では、使用されるファイルには複数の設定セクションがあり、各セクションには異なる種類の複数の設定があります。

構成セクション

Puppet構成ファイルは、主に次の構成セクションで構成されています。

メイン-これは、Puppetのすべてのコマンドおよびサービスで使用されるグローバルセクションとして知られています。メインセクションでデフォルト値を定義します。このデフォルト値は、puppet.confファイルにあるセクションでオーバーライドできます。
マスター-このセクションは、PuppetマスターサービスおよびPuppet certコマンドによって参照されます。
エージェント-このセクションは、Puppetエージェントサービスによって参照されます。
ユーザー-あまり一般的ではないコマンドの多くと同様に、Puppet applyコマンドで主に使用されます。

[main]
certname = PuppetTestmaster1.example.com

構成ファイルの主要コンポーネント

構成ファイルの主要コンポーネントは次のとおりです。

コメント行

Puppetでは、コメント行は（＃）記号で始まります。これは、任意の量のスペースで意図する場合があります。同じ行内に部分的なコメントを含めることもできます。

# This is a comment.
Testing = true #this is also a comment in same line

設定行

設定行で構成する必要があります-

任意の量の先行スペース（オプション）
設定の名前
等号=符号、任意の数のスペースで囲むことができます
設定の値

変数を設定する

ほとんどの場合、設定の値は単一の単語になりますが、特別な場合には、特別な値はほとんどありません。

パス

構成ファイルの設定で、ディレクトリのリストを取得します。これらのディレクトリを定義する際、システムパス区切り文字（ *nixプラットフォームでは（:)、Windowsではセミコロン（;）で区切る必要があることに注意してください。

#* nix version:
environmentpath = $codedir/special_environments:$codedir/environments
# Windows version:
environmentpath = $codedir/environments;C:\ProgramData\PuppetLabs\code\environment

定義では、最初にリストされているファイルディレクトリがスキャンされ、見つからない場合は後でリスト内の他のディレクトリに移動します。

ファイルとディレクトリ

単一のファイルまたはディレクトリを取るすべての設定は、オプションのアクセス許可のハッシュを受け入れることができます。サーバーの起動時に、Puppetはリスト内のこれらのファイルまたはディレクトリを強制します。

ssldir = $vardir/ssl {owner = service, mode = 0771}

上記のコードでは、許可されるハッシュは所有者、グループ、およびモードです。所有者キーとグループキーの有効な値は2つだけです。

Puppet-環境設定

Puppetでは、すべての環境に environment.conf ファイルがあります。マスターが特定の環境に割り当てられたノードまたはすべてのノードにサービスを提供している場合、このファイルはいくつかのデフォルト設定をオーバーライドできます。

ロケーション

Puppetでは、定義されているすべての環境で、environment.confファイルはホーム環境の最上位、マニフェストおよびモジュールディレクターのすぐ隣にあります。たとえば、環境がデフォルトディレクトリ*（Vipin/testing/environment）にある場合、テスト環境の構成ファイルは *Vipin/testing/environments/test/environment.conf にあります。

例

#/etc/testingdir/code/environments/test/environment.conf
# Puppet Enterprise requires $basemodulepath; see note below under modulepath".
modulepath = site:dist:modules:$basemodulepath
# Use our custom script to get a git commit for the current state of the code:
config_version = get_environment_commit.sh

フォーマット

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のすべての環境のデフォルトのモジュールパスは-

<MODULES DIRECTORY FROM ENVIRONMENT>:$basemodulepath

マニフェスト

これはメインのマニフェストファイルを定義するために使用され、Puppetマスターは、環境の構成に使用される定義済みのマニフェストからカタログを起動およびコンパイルするときに使用します。これで、単一のファイル、ファイルのリスト、または定義済みのアルファベット順で評価およびコンパイルする必要がある複数のマニフェストファイルで構成されるディレクトリを定義できます。

environment.confファイルでこの設定を明示的に定義する必要があります。そうでない場合、Puppetは環境のデフォルトのマニフェストディレクトリをメインマニフェストとして使用します。

Config_version

Config_versionは、カタログとイベントを識別するために使用される明確なバージョンとして定義できます。 Puppetがデフォルトでマニフェストファイルをコンパイルするとき、PuppetマスターがPuppetノードで定義されたカタログを適用するときに生成されるカタログとレポートに構成バージョンを追加します。 Puppetはスクリプトを実行して上記のすべての手順を実行し、生成されたすべての出力をConfig_versionとして使用します。

環境タイムアウト

これは、特定の環境のデータをロードするためにPuppetが使用する必要がある時間の詳細を取得するために使用されます。値がpuppet.confファイルで定義されている場合、これらの値はデフォルトのタイムアウト値をオーバーライドします。

サンプルenvironment.confファイル

[master]
   manifest =  $confdir/environments/$environment/manifests/site.pp
   modulepath =  $confdir/environments/$environment/modules

上記のコードの $ confdir は、環境設定ファイルが置かれているディレクトリのパスです。 $ environment は、構成が行われている環境の名前です。

実稼働環境の構成ファイル

# The environment configuration file
# The main manifest directory or file where Puppet starts to evaluate code
# This is the default value. Works with just a site.pp file or any other
manifest = manifests/
# The directories added to the module path, looked in first match first used order:
# modules - Directory for external modules, populated by r10k based on Puppetfile
# $basemodulepath - As from: puppet config print basemodulepath
modulepath = site:modules:$basemodulepath
# Set the cache timeout for this environment.
# This overrides what is set directly in puppet.conf for the whole Puppet server
# environment_timeout = unlimited
# With caching you need to flush the cache whenever new Puppet code is deployed
# This can also be done manually running: bin/puppet_flush_environment_cache.sh
# To disable catalog caching:
environment_timeout = 0
# Here we pass to one in the control repo the Puppet environment (and git branch)
# to get title and essential info of the last git commit
config_version = 'bin/config_script.sh $environment'

人形-マスター

Puppetでは、Puppetマスターのクライアントサーバーアーキテクチャは、セットアップ全体の制御機関と見なされます。 Puppetマスターはセットアップでサーバーとして機能し、すべてのノードのすべてのアクティビティを制御します。

Puppetマスターとして機能する必要のあるサーバーでは、Puppetサーバーソフトウェアが実行されている必要があります。このサーバーソフトウェアは、ノード上のすべてのアクティビティを制御する重要なコンポーネントです。このセットアップで覚えておくべき重要なポイントの1つは、セットアップで使用するすべてのマシンにスーパーユーザーがアクセスできるようにすることです。 Puppetマスターをセットアップする手順は次のとおりです。

前提条件

プライベートネットワークDNS *-フォワードおよびバックワードを設定する必要があります。各サーバーには一意のホスト名が必要です。 DNSが構成されていない場合、インフラストラクチャとの通信にプライベートネットワークを使用できます。

*Firewall Open Port* -特定のポートで着信リクエストをリッスンできるように、Puppetマスターは特定のポートで開いている必要があります。 ファイアウォールで開いている任意のポートを使用できます。

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つです。

利用可能なタイムゾーンのリスト

$ timedatectl list-timezones

上記のコマンドは、利用可能なタイムゾーンの全リストを提供します。地域にタイムゾーンの可用性を提供します。

次のコマンドを使用して、マシンに必要なタイムゾーンを設定できます。

$ sudo timedatectl set-timezone India/Delhi

CentOSマシンのyumユーティリティを使用して、PuppetサーバーマシンにNTPをインストールします。

$ sudo yum -y install ntp

上記のコマンドで設定したシステム時刻とNTPを同期します。

$ sudo ntpdate pool.ntp.org

一般的には、マシンデータセンターの近くで利用可能な共通プールを使用するようにNTP構成を更新します。このため、 /etc の下にあるntp.confファイルを編集する必要があります。

$ sudo vi/etc/ntp.conf

NTPプールのタイムゾーンからタイムサーバーを追加します。 ntp.confファイルは次のようになります。

brcleprod001.brcl.pool.ntp.org
brcleprod002.brcl.pool.ntp.org
brcleprod003.brcl.pool.ntp.org
brcleprod004.brcl.pool.ntp.org

設定を保存します。サーバーを起動し、デーモンを有効にします。

$ sudo systemctl restart ntpd
$ sudo systemctl enable ntpd

Puppet Serverソフトウェアのセットアップ

Puppetサーバーソフトウェアは、Puppetマスターマシンで実行されるソフトウェアです。 Puppet agentソフトウェアを実行している他のマシンに構成をプッシュするのはマシンです。

次のコマンドを使用して、公式のPuppet labsコレクションリポジトリを有効にします。

$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpm

puppetserverパッケージをインストールします。

$ sudo yum -y install puppetserver

Puppet Serverでメモリ割り当てを構成する

すでに説明したように、デフォルトでは、Puppetサーバーは2GB RAMマシン上で構成されます。マシンで使用可能な空きメモリとサーバーが管理するノードの数に応じて、セットアップをカスタマイズできます。

viモードでpuppetサーバー構成を編集します

$ sudo vi/etc/sysconfig/puppetserver
Find the JAVA_ARGS and use the –Xms and –Xms options to set the memory allocation.
We will allocate 3GB of space
JAVA_ARGS="-Xms3g -Xmx3g"

完了したら、保存して編集モードを終了します。

上記のセットアップがすべて完了したら、次のコマンドを使用してマスターマシンでPuppetサーバーを起動する準備ができました。

$ sudo systemctl start puppetserver

次に、マスターサーバーが起動するたびにパペットサーバーが起動するようにセットアップします。

$ sudo systemctl enable puppetserver

Puppet.confマスターセクション

[master]
autosign = $confdir/autosign.conf { mode = 664 }
reports = foreman
external_nodes =/etc/puppet/node.rb
node_terminus = exec
ca = true
ssldir =/var/lib/puppet/ssl
certname = sat6.example.com
strict_variables = false
manifest =
/etc/puppet/environments/$environment/manifests/site.pp
modulepath =/etc/puppet/environments/$environment/modules
config_version =

Puppet-エージェントのセットアップ

PuppetエージェントはPuppetラボが提供するソフトウェアアプリケーションで、Puppetクラスター内の任意のノードで実行されます。 Puppet masterを使用してサーバーを管理する場合は、Puppet agentソフトウェアをその特定のサーバーにインストールする必要があります。一般に、Puppetエージェントは、特定のインフラストラクチャ上のPuppetマスターマシンを除くすべてのマシンにインストールされます。 Puppetエージェントソフトウェアには、ほとんどのLinux、UNIX、およびWindowsマシンで実行できる機能があります。次の例では、CentOSマシンインストールPuppetエージェントソフトウェアを使用しています。

ステップ1 *-次のコマンドで公式のPuppet labsコレクションリポジトリを有効にします。

$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpm

ステップ2 *-Puppetエージェントパッケージをインストールします。

$ sudo yum -y install puppet-agent

ステップ3 *-Puppetエージェントがインストールされたら、次のコマンドで有効にします。

$ sudo/opt/puppetlabs/bin/puppet resource service puppet ensure=running enable = true

Puppetエージェントの重要な機能の1つは、Puppetエージェントが初めて実行を開始したときに、SSL証明書を生成し、署名と承認のために管理するPuppetマスターに送信することです。 Puppetマスターは、エージェントの証明書署名リクエストを承認すると、エージェントノードと通信および管理できるようになります。

注-指定されたPuppetマスターを設定および管理する必要があるすべてのノードで上記の手順を繰り返す必要があります。

Puppet-SSL署名証明書のセットアップ

PuppetエージェントソフトウェアがPuppetノードで初めて実行されると、証明書が生成され、証明書署名要求がPuppetマスターに送信されます。 Puppetサーバーは、エージェントノードと通信して制御する前に、その特定のエージェントノードの証明書に署名する必要があります。以下のセクションでは、署名要求に署名して確認する方法について説明します。

現在の証明書要求を一覧表示する

Puppetマスターで、次のコマンドを実行して、すべての未署名の証明書要求を表示します。

$ sudo/opt/puppetlabs/bin/puppet cert list

新しいエージェントノードをセットアップしたばかりなので、承認の要求が1つ表示されます。以下が*出力*です。

"Brcleprod004.brcl.com" (SHA259)
15:90:C2:FB:ED:69:A4:F7:B1:87:0B:BF:F7:ll:
B5:1C:33:F7:76:67:F3:F6:45:AE:07:4B:F 6:E3:ss:04:11:8d

先頭に+（記号）が含まれていません。これは、証明書がまだ署名されていないことを示します。

リクエストに署名する

Puppetエージェントの実行が新しいノードで行われたときに生成された新しい証明書要求に署名するために、Puppet cert signコマンドが使用され、証明書のホスト名が必要になります。署名する。 Brcleprod004.brcl.comの証明書があるので、次のコマンドを使用します。

$ sudo/opt/puppetlabs/bin/puppet cert sign Brcleprod004.brcl.com

以下が*出力*です。

Notice: Signed certificate request for Brcle004.brcl.com
Notice: Removing file Puppet::SSL::CertificateRequest Brcle004.brcl.com at
'/etc/puppetlabs/puppet/ssl/ca/requests/Brcle004.brcl.com.pem'

パペットサーバーは、サイン証明書が属するノードと通信できるようになりました。

$ sudo/opt/puppetlabs/bin/puppet cert sign --all

Puppetセットアップからのホストの取り消し

ホストをセットアップから削除して再度追加する必要がある場合、カーネルの再構築の構成には条件があります。これらは、Puppet自体では管理できない状態です。次のコマンドを使用して実行できます。

$ sudo/opt/puppetlabs/bin/puppet cert clean hostname

すべての署名済みリクエストの表示

次のコマンドは、要求が承認されたことを示す+（署名）付きの署名付き証明書のリストを生成します。

$ sudo/opt/puppetlabs/bin/puppet cert list --all

以下はその output です。

+ "puppet" (SHA256) 5A:71:E6:06:D8:0F:44:4D:70:F0:
BE:51:72:15:97:68:D9:67:16:41:B0:38:9A:F2:B2:6C:B
B:33:7E:0F:D4:53 (alt names: "DNS:puppet", "DNS:Brcle004.nyc3.example.com")

+ "Brcle004.brcl.com" (SHA259) F5:DC:68:24:63:E6:F1:9E:C5:FE:F5:
1A:90:93:DF:19:F2:28:8B:D7:BD:D2:6A:83:07:BA:F E:24:11:24:54:6A

+ " Brcle004.brcl.com" (SHA259) CB:CB:CA:48:E0:DF:06:6A:7D:75:E6:CB:22:BE:35:5A:9A:B3

上記が完了したら、Puppetマスターが新しく追加されたノードを管理できるインフラストラクチャを準備します。

Puppet-r10Kのインストールと設定

Puppetには、r10kというコード管理ツールがあり、開発、テスト、本番など、Puppetで設定できるさまざまな種類の環境に関連する環境設定の管理に役立ちます。これは、環境関連の構成をソースコードリポジトリに保存するのに役立ちます。ソース管理レポジトリブランチを使用して、r10kはレポジトリにあるモジュールを使用してPuppetマスターマシンのインストールおよび更新環境に環境を作成します。

Gemファイルを使用して、r10kを任意のマシンにインストールできますが、モジュール方式であり、最新バージョンを取得するために、rpmおよびrpmパッケージマネージャーを使用します。以下は同じ例です。

$ urlgrabber -o/etc/yum.repos.d/timhughes-r10k-epel-6.repo
https://copr.fedoraproject.org/coprs/timhughes/yum -y install rubygem-r10k

/etc/puppet/puppet.confで環境を構成します

[main]
environmentpath = $confdir/environments

r10k Configの構成ファイルを作成する

cat <<EOF >/etc/r10k.yaml
# The location to use for storing cached Git repos
:cachedir: '/var/cache/r10k'
# A list of git repositories to create
:sources:
# This will clone the git repository and instantiate an environment per
# branch in/etc/puppet/environments
:opstree:
#remote: 'https://github.com/fullstack-puppet/fullstackpuppet-environment.git'
remote: '/var/lib/git/fullstackpuppet-environment.git'
basedir: '/etc/puppet/environments'
EOF

Puppetマニフェストとモジュールのインストール

r10k deploy environment -pv

15分ごとに環境の更新を続ける必要があるため、同じ環境のcronジョブを作成します。

cat << EOF >/etc/cron.d/r10k.conf
SHELL =/bin/bash
PATH =/sbin:/bin:/usr/sbin:/usr/bin
H/15 * * * * root r10k deploy environment -p
EOF

インストールのテスト

すべてが正常に機能するかどうかをテストするには、PuppetモジュールのPuppetマニフェストをコンパイルする必要があります。次のコマンドを実行し、結果としてYAML出力を取得します。

curl --cert/etc/puppet/ssl/certs/puppet.corp.guest.pem \
--key/etc/puppet/ssl/private_keys/puppet.corp.guest.pem \
--cacert/etc/puppet/ssl/ca/ca_crt.pem \
-H 'Accept: yaml' \
https://puppet.corp.guest:8140/production/catalog/puppet.corp.guest

Puppet-Puppetセットアップの検証

Puppetでは、セットアップをローカルでテストできます。したがって、Puppetマスターとノードをセットアップしたら、セットアップをローカルで検証します。 VagrantとVagrant boxをローカルにインストールする必要があります。これはセットアップをローカルでテストするのに役立ちます。

仮想マシンのセットアップ

ローカルでセットアップをテストしているため、実際にPuppetマスターを実行する必要はありません。これは、サーバーで実際にPuppetマスターを実行せずに、Puppetを使用してPuppetセットアップ検証のコマンドを適用するだけでよいことを意味します。 Puppet applyコマンドは、構成ファイル内の仮想マシンのホスト名に応じて、 local/etc/puppet からの変更を適用します。

セットアップをテストするために実行する必要がある最初のステップは、次の Vagrantfile をビルドしてマシンを起動し、 /etc/puppet フォルダーを所定の場所にマウントすることです。必要なすべてのファイルは、次の構造を持つバージョン管理システム内に配置されます。

ディレクトリ構造

- manifests
   \- site.pp
- modules
   \- your modules
- test
   \- update-puppet.sh
   \- Vagrantfile
- puppet.conf

Vagrant File

# -*- mode: ruby -*-
# vi: set ft = ruby :
Vagrant.configure("2") do |config|
   config.vm.box = "precise32"
   config.vm.box_url = "http://files.vagrantup.com/precise64.box"
   config.vm.provider :virtualbox do |vb|
      vb.customize ["modifyvm", :id, "--memory", 1028, "--cpus", 2]
   end

   # Mount our repo onto/etc/puppet
   config.vm.synced_folder "../", "/etc/puppet"

   # Run our Puppet shell script
   config.vm.provision "shell" do |s|
      s.path = "update-puppet.sh"
   end

   config.vm.hostname = "localdev.example.com"
end

上記のコードでは、 update-puppet.sh という名前のシェルスクリプトを実行しようとしているシェルプロビジョニングツールを使用しています。スクリプトは、Vagrantファイルが配置されているディレクトリと同じディレクトリに存在し、スクリプトの内容は以下のとおりです。

!/bin/bash
echo "Puppet version is $(puppet --version)"
if [ $( puppet --version) != "3.4.1" ]; then
   echo "Updating puppet"
   apt-get install --yes lsb-release
   DISTRIB_CODENAME = $(lsb_release --codename --short)
   DEB = "puppetlabs-release-${DISTRIB_CODENAME}.deb"
   DEB_PROVIDES="/etc/apt/sources.list.d/puppetlabs.list"

   if [ ! -e $DEB_PROVIDES ]
   then
      wget -q http://apt.puppetlabs.com/$DEB
      sudo dpkg -i $DEB
   fi
sudo apt-get update
   sudo apt-get install -o Dpkg::Options:: = "--force-confold"
   --force-yes -y puppet
else
   echo "Puppet is up to date!"
fi

さらに処理する場合、ユーザーはマニフェストディレクトリ内に site.pp という名前のマニフェストファイルを作成する必要があります。これにより、VMにソフトウェアがインストールされます。

node 'brclelocal03.brcl.com' {
   package { ['vim','git'] :
      ensure => latest
   }
}
echo "Running puppet"
sudo puppet apply/etc/puppet/manifests/site.pp

ユーザーは、必要なVagrantファイル構成で上記のスクリプトの準備ができたら、テストディレクトリにcdして* vagrant upコマンド*を実行できます。これにより、後で新しいVMが起動し、Puppetがインストールされ、シェルスクリプトを使用して実行されます。

出力は次のようになります。

Notice: Compiled catalog for localdev.example.com in environment production in 0.09 seconds
Notice:/Stage[main]/Main/Node[brclelocal03.brcl.com]/Package[git]/ensure: created
Notice:/Stage[main]/Main/Node[brcllocal03.brcl.com]/Package[vim]/ensure: ensure changed 'purged' to 'latest'

複数マシン構成の検証

複数のマシンの構成をローカルでテストする必要がある場合は、Vagrant構成ファイルを変更するだけで簡単に実行できます。

新しい構成済みVagrantファイル

config.vm.define "brclelocal003" do |brclelocal003|
   brclelocal03.vm.hostname = "brclelocal003.brcl.com"
end

config.vm.define "production" do |production|
   production.vm.hostname = "brcleprod004.brcl.com"
end

SSLユーティリティをインストールする必要がある新しい運用サーバーがあるとします。次の構成で古いマニフェストを拡張するだけです。

node 'brcleprod004.brcl.com' inherits 'brcleloacl003.brcl.com' {
   package { ['SSL'] :
      ensure => latest
   }
}

マニフェストファイルの構成を変更した後、テストディレクトリに移動し、 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リソース

次のコマンドでは、特定のファイルのアクセス許可を指定しようとしています。

file {
   '/etc/passwd':
   owner => superuser,
   group => superuser,
   mode => 644,
}

上記のコマンドがいずれかのマシンで実行されるたびに、システム内のpasswdファイルが説明どおりに構成されていることを確認します。前のファイル：コロンはリソースのタイトルで、Puppet設定の他の部分でリソースとして参照できます。

タイトルに加えてローカル名を指定する

file { 'sshdconfig':
   name => $operaSystem ? {
      solaris => '/usr/local/etc/ssh/sshd_config',
      default => '/etc/ssh/sshd_config',
   },
   owner => superuser,
   group => superuser,
   mode => 644,
}

常に同じタイトルを使用することで、OS関連のロジックを繰り返すことなく、構成でファイルリソースを参照するのが非常に簡単になります。

別の例として、ファイルに依存するサービスの使用があります。

service { 'sshd':
   subscribe => File[sshdconfig],
}

この依存関係により、 sshdconfig ファイルが変更されると、 sshd サービスは常に再起動します。ここで覚えておくべきポイントは、 File [sshdconfig] は小文字の場合のFileとしての宣言ですが、これを FILE [sshdconfig] に変更すると、参照になります。

リソースを宣言する際に留意する必要がある基本的なポイントの1つは、構成ファイルごとに1回だけ宣言できることです。同じリソースの宣言を複数回繰り返すと、エラーが発生します。この基本概念により、Puppetは構成が適切にモデル化されていることを確認します。

リソースの依存関係を管理する機能もあり、複数の関係を管理するのに役立ちます。

service { 'sshd':
   require => File['sshdconfig', 'sshconfig', 'authorized_keys']
}

メタパラメータ

メタパラメーターは、Puppetではグローバルパラメーターとして知られています。メタパラメーターの重要な機能の1つは、Puppetのあらゆるタイプのリソースで機能することです。

リソースのデフォルト

デフォルトのリソース属性値を定義する必要がある場合、Puppetは、タイトルのない大文字のリソース仕様を使用して、それをアーカイブするための構文セットを提供します。

たとえば、すべての実行可能ファイルのデフォルトパスを設定する場合は、次のコマンドで実行できます。

Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin' }
exec { 'echo Testing mataparamaters.': }

上記のコマンドでは、最初のステートメントExecはexecリソースのデフォルト値を設定します。 Execリソースには、完全修飾パスまたは実行可能ファイルのように見えるパスが必要です。これにより、設定全体に対して単一のデフォルトパスを定義できます。デフォルトは、Puppetのすべてのリソースタイプで機能します。

デフォルトはグローバル値ではありませんが、定義されているスコープまたはそのすぐ隣の変数にのみ影響します。完全な構成のために default を定義する場合は、次のセクションで default とクラスを定義します。

リソースコレクション

集約は、物を一緒に収集する方法です。 Puppetは、非常に強力な集約の概念をサポートしています。 Puppetでは、Puppetの基本単位であるリソースをグループ化するために集約が使用されます。 Puppetでのこの集約の概念は、 classes および definition として知られる2つの強力なメソッドを使用して実現されます。

クラスと定義

クラスは、ノードの基本的な側面のモデリングを担当します。ノードはWebサーバーであり、この特定のノードはそれらの1つであると言うことができます。 Puppetでは、プログラミングクラスはシングルトンであり、ノードごとに1回評価できます。

一方、定義は単一のノードで何度も使用できます。言語を使用して独自のPuppetタイプを作成した場合と同様に機能します。それらは、毎回異なる入力で複数回使用されるように作成されます。これは、変数値を定義に渡すことができることを意味します。

クラスと定義の違い

クラスと定義の唯一の重要な違いは、建物構造の定義とリソースの割り当て中にクラスがノードごとに1回だけ評価されることです。一方、定義は同じ単一ノードで複数回使用されます。

クラス

Puppetのクラスはclassキーワードを使用して導入され、その特定のクラスのコンテンツは、次の例に示すように中括弧で囲まれています。

class unix {
   file {
      '/etc/passwd':
      owner => 'superuser',
      group => 'superuser',
      mode => 644;
      '/etc/shadow':
      owner => 'vipin',
      group => 'vipin',
      mode => 440;
   }
}

次の例では、上記と同様のショートハンドを使用しました。

class unix {
   file {
      '/etc/passwd':
      owner => 'superuser',
      group => 'superuser',
      mode => 644;
   }

   file {'/etc/shadow':
      owner => 'vipin',
      group => 'vipin',
      mode => 440;
   }
}

Puppetクラスの継承

Puppetでは、継承のOOPコンセプトがデフォルトでサポートされており、クラスは新しく作成されたクラスに完全なコードビットをコピーして貼り付けることなく、以前の機能を拡張できます。継承により、サブクラスは親クラスで定義されたリソース設定をオーバーライドできます。継承を使用する際に留意すべき重要な点の1つは、クラスは1つ以上の親クラスからのみ機能を継承できないことです。

class superclass inherits testsubclass {
   File['/etc/passwd'] { group => wheel }
   File['/etc/shadow'] { group => wheel }
}

親クラスで指定されたロジックを元に戻す必要がある場合は、* undefコマンド*を使用できます。

class superclass inherits testsubcalss {
   File['/etc/passwd'] { group => undef }
}

継承を使用する別の方法

class tomcat {
   service { 'tomcat': require => Package['httpd'] }
}
class open-ssl inherits tomcat {
   Service[tomcat] { require +> File['tomcat.pem'] }
}

Puppetのネストされたクラス

Puppetは、ネストされたクラスの使用を許可するクラスのネストの概念をサポートします。これは、一方のクラスが他方のクラスの内部にあることを意味します。これは、モジュール性とスコープの達成に役立ちます。

class testclass {
   class nested {
      file {
         '/etc/passwd':
         owner => 'superuser',
         group => 'superuser',
         mode => 644;
      }
   }
}
class anotherclass {
   include myclass::nested
}

パラメータ化されたクラス

Puppetでは、クラスは機能を拡張して、パラメーターをクラスに渡すことができます。

クラスでパラメータを渡すには、次の構成を使用できます-

class tomcat($version) {
   ... class contents ...
}

Puppetで覚えておくべき重要な点の1つは、include関数を使用してパラメーターを持つクラスを追加するのではなく、結果のクラスを定義として追加できることです。

node webserver {
   class { tomcat: version => "1.2.12" }
}

クラスのパラメーターとしてのデフォルト値

class tomcat($version = "1.2.12",$home = "/var/www") {
   ... class contents ...
}

実行ステージ

Puppetは実行ステージの概念をサポートします。これは、特定のリソースまたは複数のリソースを管理するために、ユーザーが要件に従って複数のステージを追加できることを意味します。この機能は、ユーザーが複雑なカタログを開発する場合に非常に役立ちます。複雑なカタログには、定義するリソース間の依存関係に影響を与えないように注意しながら、コンパイルする必要のあるリソースが多数あります。

実行ステージは、リソースの依存関係の管理に非常に役立ちます。これは、特定のクラスにリソースのコレクションが含まれる定義済みの段階でクラスを追加することで実行できます。実行ステージでは、Puppetは、カタログが実行され、Puppetノードに適用されるたびに、定義されたステージが指定された予測可能な順序で実行されることを保証します。

これを使用するには、既存のステージを超えて追加のステージを宣言する必要があります。Puppetは、必要な "→" および* "+>の前に同じリソース関係構文を使用して、指定された順序で各ステージを管理するように構成できます」*。この関係により、各ステージに関連付けられたクラスの順序が保証されます。

Puppet宣言構文を使用した追加ステージの宣言

stage { "first": before => Stage[main] }
stage { "last": require => Stage[main] }

ステージが宣言されると、ステージを使用するメイン以外のステージにクラスを関連付けることができます。

class {
   "apt-keys": stage => first;
   "sendmail": stage => main;
   "apache": stage => last;
}

クラスapt-keyに関連付けられているすべてのリソースが最初に実行されます。 Sendmailのすべてのリソースがメインクラスになり、Apacheに関連付けられたリソースが最終段階になります。

定義

Puppetでは、マニフェストファイル内のリソースの収集は、クラスまたは定義によって行われます。定義はPuppetのクラスに非常に似ていますが、* defineキーワード（クラスではない）*で導入され、継承ではなく引数をサポートします。異なるパラメーターを使用して、同じシステムで複数回実行できます。

たとえば、同じシステム上で複数のリポジトリを作成しようとしているソースコードリポジトリを制御する定義を作成する場合、クラスではなく定義を使用できます。

define perforce_repo($path) {
   exec {
      "/usr/bin/svnadmin create $path/$title":
      unless => "/bin/test -d $path",
   }
}
svn_repo { puppet_repo: path => '/var/svn_puppet' }
svn_repo { other_repo: path => '/var/svn_other' }

ここで注意すべき重要な点は、変数を定義で使用する方法です。（ $ ）ドル記号変数を使用します。上記では、$ titleを使用しました。定義には、名前とタイトルを表すことができる$ titleと$ nameの両方を含めることができます。デフォルトでは、$ titleと$ nameは同じ値に設定されますが、タイトル属性を設定して、異なる名前をパラメーターとして渡すことができます。 $ titleと$ nameは定義でのみ機能し、クラスや他のリソースでは機能しません。

モジュール

モジュールは、特定のPuppetノード（エージェント）に構成変更を適用するためにPuppetマスターが使用するすべての構成のコレクションとして定義できます。これらは、特定のタスクを実行するために必要なさまざまな種類の構成のポータブルコレクションとしても知られています。たとえば、モジュールには、PostfixとApacheの構成に必要なすべてのリソースが含まれている場合があります。

ノード

ノードは非常に単純な残りのステップであり、定義したもの（「これはWebサーバーの外観」）を、それらの命令を実行するために選択されたマシンと一致させる方法です。

ノード定義は、継承を含むクラスとまったく同じように見えますが、ノード（Puppetクライアントを実行する管理対象コンピューター）がPuppetマスターデーモンに接続すると、定義されたノードのリストでその名前が検索されます。定義された情報はノードに対して評価され、ノードはその構成を送信します。

ノード名には、短いホスト名または完全修飾ドメイン名（FQDN）を使用できます。

node 'www.vipin.com' {
   include common
   include apache, squid
}

上記の定義は、www.vipin.comというノードを作成し、一般的なApacheクラスとSquidクラスを含みます

同じ構成を異なるノードに送信するには、各ノードをコンマで区切ります。

node 'www.testing.com', 'www.testing2.com', 'www3.testing.com' {
   include testing
   include tomcat, squid
}

一致するノードの正規表現

node/^www\d+$/{
   include testing
}

ノードの継承

ノードは限定された継承モデルをサポートします。クラスと同様に、ノードは他の1つのノードからのみ継承できます。

node 'www.testing2.com' inherits 'www.testing.com' {
   include loadbalancer
}

上記のコードでは、www.testing2.comは、追加のロードバランサークラスに加えて、www.testing.comからすべての機能を継承しています。

高度なサポート機能

引用-ほとんどの場合、Puppetで文字列を引用する必要はありません。文字で始まる英数字の文字列は、引用符なしで残されます。ただし、負でない値の文字列を引用符で囲むことは常にベストプラクティスです。

引用付き変数補間

これまでのところ、定義に関して変数について述べてきました。これらの変数を文字列で使用する必要がある場合は、一重引用符ではなく二重引用符を使用してください。一重引用符の文字列は変数の補間を行いませんが、二重引用符の文字列は行います。変数を \ {} で囲むと、一緒に使いやすくなり、理解しやすくなります。

$value = "${one}${two}"

ベストプラクティスとして、文字列の補間を必要としないすべての文字列に一重引用符を使用する必要があります。

大文字

大文字化は、特定のリソースのデフォルト属性の参照、継承、および設定に使用されるプロセスです。基本的には、2つの基本的な使用方法があります。

参照-すでに作成されたリソースを参照する方法です。主に依存関係の目的で使用され、リソースの名前を大文字にする必要があります。例、require ⇒ file [sshdconfig]
継承-サブクラスから親クラスの設定をオーバーライドする場合、リソース名の大文字バージョンを使用します。小文字バージョンを使用すると、エラーが発生します。
デフォルト属性値の設定-タイトルなしで大文字のリソースを使用すると、リソースのデフォルトが設定されます。

配列

Puppetでは、複数の領域で配列を使用できます[1、2、3]。

ホスト定義のエイリアスなど、いくつかの型メンバーは、値に配列を受け入れます。複数のエイリアスを持つホストリソースは、次のようになります。

host { 'one.vipin.com':
   alias => [ 'satu', 'dua', 'tiga' ],
   ip => '192.168.100.1',
   ensure => present,
}

上記のコードは、3つのエイリアス*「satu」、「dua」、「tiga」を含むホスト *'one.brcletest.com' をホストリストに追加します。 1つのリソースに複数のリソースを追加する場合は、次の例に示すように実行できます。

resource { 'baz':
   require => [ Package['rpm'], File['testfile'] ],
}

変数

Puppetは、他のほとんどのプログラミング言語と同様に複数の変数をサポートしています。 Puppet変数は $ で示されます。

$content = 'some content\n'
file { '/tmp/testing': content => $content }

前述のように、Puppetは宣言型言語です。つまり、その範囲と割り当て規則は命令型言語とは異なります。主な違いは、変数の値を決定するためにファイル内の順序に依存するため、1つのスコープ内で変数を変更できないことです。宣言言語では順序は関係ありません。

$user = root
file {
   '/etc/passwd':
   owner => $user,
}

$user = bin
   file {
      '/bin':
      owner => $user,
      recurse => true,
   }

可変スコープ

変数スコープは、定義されているすべての変数が有効かどうかを定義します。最新の機能と同様に、Puppetは現在動的にスコープされています。これは、Puppetの用語では、定義されたすべての変数が、定義された場所ではなくスコープで評価されることを意味します。

$test = 'top'
class Testclass {
   exec { "/bin/echo $test": logoutput => true }
}

class Secondtestclass {
   $test = 'other'
   include myclass
}

include Secondtestclass

修飾変数

Puppetは、クラスまたは定義内での修飾変数の使用をサポートしています。これは、ユーザーが定義した、または定義しようとしている他のクラスで同じ変数を使用する場合に非常に役立ちます。

class testclass {
   $test = 'content'
}

class secondtestclass {
   $other = $myclass::test
}

上記のコードでは、$ other変数の値がコンテンツを評価します。

条件付き

条件は、定義された条件または必要な条件が満たされたときに、ユーザーがステートメントまたはコードのセットを実行したい状況です。 Puppetは2種類の条件をサポートしています。

マシンの正しい値を選択するために定義されたリソース内でのみ使用できるセレクター条件。

ステートメント条件は、マニフェストでより広く使用される条件であり、ユーザーが同じマニフェストファイルに含めたい追加のクラスを含めるのに役立ちます。クラス内でリソースの異なるセットを定義するか、他の構造的な決定を下します。

セレクター

セレクターは、ユーザーがファクトまたは他の変数に基づいてデフォルト値とは異なるリソース属性と変数を指定したい場合に役立ちます。 Puppetでは、セレクターインデックスは複数値の三元演算子のように機能します。セレクターは、マニフェストで定義され、条件に一致する値なしでカスタムのデフォルト値を定義することもできます。

$owner = $Sysoperenv ? {
   sunos => 'adm',
   redhat => 'bin',
   default => undef,
}

Puppet 0.25.0以降のバージョンでは、セレクターを正規表現として使用できます。

$owner = $Sysoperenv ? {
  /(Linux|Ubuntu)/=> 'bin',
   default => undef,
}

上記の例では、セレクターの $ Sysoperenv 値はLinuxまたはUbuntuのいずれかに一致し、ビンは選択された結果になります。そうでない場合、ユーザーは未定義として設定されます。

ステートメント条件

ステートメント条件は、Puppetの他のタイプの条件ステートメントであり、シェルスクリプトのswitch case条件に非常によく似ています。これでは、caseステートメントの複数のセットが定義され、指定された入力値が各条件と照合されます。

指定された入力条件に一致するcaseステートメントが実行されます。このcaseステートメント条件には戻り値がありません。 Puppetでは、条件ステートメントの非常に一般的なユースケースは、基盤となるオペレーティングシステムに基づいて一連のコードビットを実行することです。

case $ Sysoperenv {
   sunos: { include solaris }
   redhat: { include redhat }
   default: { include generic}
}

Caseステートメントでは、複数の条件をコンマで区切って指定することもできます。

case $Sysoperenv {
   development,testing: { include development } testing,production: { include production }
   default: { include generic }
}

If-Elseステートメント

Puppetは、条件ベースの操作の概念をサポートしています。それを実現するために、If/elseステートメントは、条件の戻り値に基づいて分岐オプションを提供します。次の例に示すように-

if $Filename {
   file { '/some/file': ensure => present }
} else {
   file { '/some/other/file': ensure => present }
}

最新バージョンのPuppetは、式の値に基づいてifステートメントも分岐できる変数式をサポートしています。

if $machine == 'production' {
   include ssl
} else {
   include nginx
}

コードの多様性を高め、複雑な条件付き操作を実行するために、Puppetは次のコードに示すようにネストされたif/elseステートメントをサポートしています。

if $ machine == 'production' {
   include ssl
} elsif $ machine == 'testing' {
   include nginx
} else {
   include openssl
}

仮想リソース

仮想リソースは、実現しない限りクライアントに送信されないリソースです。

以下は、Puppetで仮想リソースを使用する構文です。

@user { vipin: ensure => present }

上記の例では、コレクションで使用できる定義を実現するために、ユーザーvipinが仮想的に定義されています。

User <| title == vipin |>

演算子の優先順位

Puppetオペレーターの優先順位は、ほとんどのシステムの標準的な優先順位（最高から最低まで）に準拠しています。

以下は式のリストです

！ =しない */=回と除算
-+ =マイナス、プラス
<< >> =左シフトと右シフト
==！= =等しくない、等しい *> = <⇒ ⇐より大きい、より小さいまたは等しい、より大きい、より小さい

比較式

比較式は、指定された条件が満たされたときにユーザーが一連のステートメントを実行する場合に使用されます。比較式には、==式を使用した等価性のテストが含まれます。

if $environment == 'development' {
   include openssl
} else {
   include ssl
}

等しくない例

if $environment != 'development' {
   $otherenvironment = 'testing'
} else {
   $otherenvironment = 'production'
}

算術式

$one = 1
$one_thirty = 1.30
$two = 2.034e-2 $result = ((( $two + 2)/$one_thirty) + 4* 5.45) -
   (6 << ($two + 4)) + (0×800 + -9)

ブール式

ブール式は、or、and、＆notを使用して可能です。

$one = 1
$two = 2
$var = ( $one < $two ) and ( $one + 1 == $two )

正規表現

Puppetは、=〜（一致）および！〜（非一致）を使用した正規表現一致をサポートしています。

if $website =~/^www(\d+)\./{
   notice('Welcome web server #$1')
}

大文字小文字の区別とセレクターの正規表現の一致は、各正規表現の限定スコープ変数を作成します。

exec { "Test":
   command => "/bin/echo now we don’t have openssl installed on machine >/tmp/test.txt",
   unless => "/bin/which php"
}

同様に、正常に終了しない限り、下のコマンドを除き、常にコマンドを実行しない限り、使用できます。

exec { "Test":
   command => "/bin/echo now we don’t have openssl installed on machine >/tmp/test.txt",
   unless => "/bin/which php"
}

テンプレートの使用

テンプレートは、Puppetの複数のモジュール間で使用される定義済みの構造を希望し、それらのモジュールが複数のマシンに配布される場合に使用されます。テンプレートを使用するための最初のステップは、テンプレートメソッドを使用してテンプレートコンテンツをレンダリングするテンプレートを作成することです。

file { "/etc/tomcat/sites-available/default.conf":
   ensure => "present",
   content => template("tomcat/vhost.erb")
}

Puppetは、組織とモジュール性を強化するために、ローカルファイルを扱う際にほとんど仮定を行いません。 Puppetは、モジュールディレクトリ内のapache/templatesフォルダー内でvhost.erbテンプレートを探します。

サービスの定義とトリガー

Puppetには、特定のマシンまたは環境で実行されているすべてのサービスのライフサイクルを管理できるserviceというリソースがあります。サービスリソースは、サービスが初期化および有効化されていることを確認するために使用されます。また、サービスの再起動にも使用されます。

たとえば、以前のTomcatのテンプレートでは、apache仮想ホストを設定する場所があります。仮想ホストの変更後にapacheを確実に再起動したい場合は、次のコマンドを使用してapacheサービスのサービスリソースを作成する必要があります。

service { 'tomcat':
   ensure => running,
   enable => true
}

リソースを定義するとき、再起動をトリガーするために通知オプションを含める必要があります。

file { "/etc/tomcat/sites-available/default.conf":
   ensure => "present",
   content => template("vhost.erb"),
   notify => Service['tomcat']
}

Puppet-マニフェストファイル

Puppetでは、Rubyプログラミング言語を使用して記述され、*。pp *の拡張子で保存されたすべてのプログラムは*マニフェスト*と呼ばれます。一般的に、ターゲットホストマシンの作成または管理を目的として構築されたすべてのPuppetプログラムは、マニフェストと呼ばれます。 Puppetで記述されたすべてのプログラムは、Puppetコーディングスタイルに従います。

Puppetの中核は、リソースの宣言方法と、これらのリソースが状態をどのように表しているかです。どのマニフェストでも、ユーザーはクラスと定義を使用してグループ化されたさまざまな種類のリソースのコレクションを持つことができます。

場合によっては、Puppetマニフェストに目的の状態を達成するための条件ステートメントを含めることもできます。ただし、最終的にはすべてのリソースが正しい方法で定義および使用され、カタログに変換された後に適用された定義済みマニフェストが設計されたタスクを実行できることを確認します。

マニフェストファイルのワークフロー

Puppetマニフェストは、次のコンポーネントで構成されています-

ファイル（これらは、Puppetがそれらとは関係なく、単に拾い上げてターゲットの場所に配置するためのプレーンなファイルです）
リソース
テンプレート（これらは、ノード上で構成ファイルを構築するために使用できます）。
Nodes （クライアントノードに関連するすべての定義はここで定義されます）
クラス

注意点

Puppetでは、すべてのマニフェストファイルはエンコード言語としてRubyを使用し、*。pp *拡張子で保存されます。
多くのマニフェストの「インポート」ステートメントは、Puppetの起動時にファイルをロードするために使用されます。 ディレクトリに含まれるすべてのファイルをインポートするには、import 'clients/ 'のような別の方法でimportステートメントを使用できます。これにより、そのディレクトリ内のすべての .pp ファイルがインポートされます。

マニフェスト

マニフェストの作成

変数の使用

マニフェストの作成中に、ユーザーは新しい変数を定義するか、マニフェストの任意の時点で既存の変数を使用できます。 Puppetはさまざまな種類の変数をサポートしていますが、文字列や文字列の配列など、頻繁に使用される変数はほとんどありません。それらとは別に、他の形式もサポートされています。

文字列変数の例

$package = "vim"

package {  $package:
   ensure => "installed"
}

ループを使用する

ループは、定義された条件が満たされるまで、同じコードセットで複数の反復を実行する場合に使用されます。また、異なる値のセットを使用して反復タスクを実行するためにも使用されます。 10種類のタスクを10個作成します。 1つのタスクを作成し、ループを使用して、インストールするさまざまなパッケージでタスクを繰り返すことができます。

最も一般的には、異なる値でテストを繰り返すために配列が使用されます。

$packages = ['vim', 'git', 'curl']

package { $packages:
   ensure => "installed"
}

条件付きの使用

Puppetは、従来のプログラミング言語に見られる条件構造のほとんどをサポートしています。条件を使用して、特定のタスクを実行するか、コードセットを実行するかを動的に定義できます。 if/elseおよびcaseステートメントと同様。さらに、実行のような条件は、条件のように機能する属性もサポートしますが、コマンド出力のみを条件として受け入れます。

if $OperatingSystem != 'Linux' {
   warning('This manifest is not supported on this other OS apart from linux.')
} else {
   notify { 'the OS is Linux. We are good to go!': }
}

Puppet-モジュール

Puppetでは、モジュールはリソース、クラス、ファイル、定義、およびテンプレートのコレクションとして定義できます。 Puppetはモジュールの簡単な再配布をサポートします。これは、指定された汎用モジュールを記述し、簡単なコード変更をほとんどせずに複数回使用できるため、コードのモジュール化に非常に役立ちます。たとえば、これにより、/etc/puppetでデフォルトのサイト構成が有効になり、Puppetによって出荷されるモジュールは/etc/share/puppetに適切に格納されます。

モジュール構成

Puppetモジュールには、コードの構造を定義し、宗派を制御するのに役立つ2つのパーティションがあります。

モジュールの検索パスは、 puppetmasterd または masterd のコロンで区切られたディレクトリのリストを使用して構成されます。 puppetmasterd または masterd は、Puppetのマスター構成ファイルの後のセクションで、 modulepath パラメーターを使用します。

[puppetmasterd]
...
modulepath =/var/lib/puppet/modules:/data/puppet/modules

fileserver.conf内のファイルサーバーモジュールのアクセス制御設定。そのモジュールのパス構成は常に無視され、パスを指定すると警告が生成されます。

モジュールソース

Puppetは、モジュールを保存するための別の場所をサポートしています。モジュールは、特定のマシンの異なるファイルシステムに保存できます。ただし、モジュールが格納されているすべてのパスは、一般的に modulepath として知られる構成変数で指定する必要があります。これは、Puppetがすべてのモジュールディレクトリをスキャンし、起動時にロードするパス変数です。

合理的なデフォルトパスは次のように設定できます-

/etc/puppet/modules:/usr/share/puppet:/var/lib/modules.

または、/etc/puppetディレクトリを特別な匿名モジュールとして確立し、常に最初に検索することもできます。

モジュールの命名

Puppetは特定のモジュールと同じ命名規則に従います。モジュール名は通常の単語で、[-\\ w +]（文字、単語、数字、アンダースコア、ダッシュ）に一致し、名前空間の区切り文字を含まない必要があります。モジュール階層に関しては許可される場合がありますが、新しいモジュールの場合はネストできません。

モジュール内部組織

ユーザーがPuppetで新しいモジュールを作成すると、同じ構造に従い、次のコードに示すように、特定のディレクトリ構造に配置されたマニフェスト、分散ファイル、プラグイン、テンプレートが含まれます。

MODULE_PATH/
   downcased_module_name/
      files/
      manifests/
         init.pp
      lib/
         puppet/
            parser/
               functions
            provider/
            type/
         facter/
      templates/
      README

モジュールが作成されるたびに、マニフェストディレクトリ内の指定された修正場所に init.pp マニフェストファイルが含まれます。このマニフェストファイルは、特定のモジュールで最初に実行され、その特定のモジュールに関連付けられているすべてのクラスのコレクションを含むデフォルトファイルです。追加の .pp ファイルは、manifestsフォルダーの下に直接追加できます。追加の.ppファイルを追加する場合は、クラスにちなんで名前を付ける必要があります。

モジュールを使用することで達成される重要な機能の1つは、コードの共有です。モジュールは本質的に自己完結型である必要があります。つまり、どこからでも任意のモジュールを含めることができ、Puppetの起動時にロードされるモジュールパスにドロップできる必要があります。モジュールの助けを借りて、Puppetインフラストラクチャコーディングのモジュール性を得ることができます。

モジュール

例

固定のauto.homesマップをインストールし、テンプレートからauto.masterを生成するautofsモジュールを検討してください。

class autofs {
   package { autofs: ensure => latest }
   service { autofs: ensure => running }

   file { "/etc/auto.homes":
      source => "puppet://$servername/modules/autofs/auto.homes"
   }
   file { "/etc/auto.master":
      content => template("autofs/auto.master.erb")
   }
}

ファイルシステムには次のファイルがあります。

MODULE_PATH/
autofs/
manifests/
init.pp
files/
auto.homes
templates/
auto.master.erb

モジュール検索

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とクライアント関数は、ファイルオブジェクトとしてファイル属性を取得する際に重要な役割を果たします。

class { 'java':
   package               => 'jdk-8u25-linux-x64',
   java_alternative      => 'jdk1.8.0_25',
   java_alternative_path => '/usr/java/jdk1.8.0_25/jre/bin/java'
}

上記のコードスニペットのように、Puppetのファイルサービス機能は、ファイルサービスモジュールをサポートすることにより、ローカルファイルシステムトポロジを抽象化します。ファイルサービングモジュールは次の方法で指定します。

“puppet://server/modules/module_name/sudoers”

ファイルフォーマット

Puppetディレクトリ構造では、デフォルトでファイルサーバー設定は /etc/puppet/fileserver.config ディレクトリにあります。ユーザーがこのデフォルト設定ファイルパスを変更したい場合は、新しい設定フラグを puppetmasterdに使用して実行できます。 。構成ファイルはINIファイルに似ていますが、まったく同じではありません。

[module]
path/path/to/files
allow *.domain.com
deny *.wireless.domain.com

上記のコードスニペットに示すように、3つのオプションはすべて構成ファイルで表されます。モジュール名は大括弧で囲みます。パスは唯一の必須オプションです。デフォルトのセキュリティオプションはすべてのアクセスを拒否するため、許可行が指定されていない場合、設定されるモジュールは誰でも利用できます。

パスには、ドメイン名、ホスト名、完全修飾ホスト名で動的に置き換えられる％d、％h、％Hのいずれかまたはすべてを含めることができます。すべてがクライアントのSSL証明書から取得されます（ホスト名と証明書名に不一致がある場合は注意してください）。これは、各クライアントのファイルが完全に個別に保持されるモジュールを作成するのに役立ちます。例、プライベートホストキーの場合。

[private]
path/data/private/%h
allow *

上記のコードスニペットでは、コードはクライアント 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つの方法でファイルホスト名を指定できます。

[export]
path/usr
allow brcleprod001.brcl.com
allow *.brcl.com
deny brcleprod002.brcl.com

IPアドレス

任意のファイルサーバー構成で、完全なIPアドレスまたはワイルドカードアドレスを使用して、ホスト名と同様にファイルアドレスを指定できます。 CIDRシステム表記も使用できます。

[export]
path/usr
allow 127.0.0.1
allow 172.223.30. *
allow 172.223.30.0/24

グローバル許可

ユーザーが特定のモジュールにアクセスできるようにしたい場合、グローバル許可が使用されます。これを行うには、単一のワイルドカードを使用して、全員がモジュールにアクセスできるようにします。

[export]
path/export
allow*

人形-事実と事実

Puppetは、環境変数として複数の値を保持することをサポートしています。この機能は、 facter を使用してPuppetでサポートされています。 Puppetでは、ファクトは環境レベル変数を保持するスタンドアロンツールです。 Inは、BashまたはLinuxのenv変数に似ていると考えることができます。ファクトに保存されている情報とマシンの環境変数が重複している場合があります。 Puppetでは、キーと値のペアは「ファクト」として知られています。各リソースには独自のファクトがあり、Puppetでは、ユーザーは独自のカスタムファクトを構築するために活用できます。

# facter

Facterコマンド*を使用して、すべての異なる環境変数とそれに関連する値をリストできます。これらのファクトのコレクションには、すぐに使えるファクトが付属しており、コアファクトと呼ばれます。コレクションにカスタムファクトを追加できます。

1つの変数のみを表示する場合。次のコマンドを使用して実行できます。

# facter {Variable Name}

Example
[root@puppetmaster ~]# facter virtual
virtualbox

ファクターがPuppetにとって重要である理由は、ファクターとファクトがPuppetコード全体で*「グローバル変数」*として利用可能であるためです。

テストする例

[root@puppetmaster modules]# tree brcle_account
brcle_account
└── manifests  └── init.pp [root@puppetmaster modules]# cat brcle_account/manifests/init.pp
class brcle_account {
   user { 'G01063908':
      ensure => 'present',
      uid => '121',
      shell => '/bin/bash',
      home => '/home/G01063908',
   }

   file {'/tmp/userfile.txt':
      ensure => file,
      content => "the value for the 'OperatingSystem' fact is: $OperatingSystem \n",
   }
}

それをテストする

[root@puppetmaster modules]# puppet agent --test
Notice:/Stage[main]/Activemq::Service/Service[activemq]/ensure:
ensure changed 'stopped' to 'running'
Info:/Stage[main]/Activemq::Service/Service[activemq]:
Unscheduling refresh on Service[activemq]

Notice: Finished catalog run in 4.09 seconds
[root@puppetmaster modules]# cat/tmp/testfile.txt
the value for the 'OperatingSystem' fact is: Linux

[root@puppetmaster modules]# facter OperatingSystem
Linux

上記のコードスニペットでわかるように、 OperatingSystem を定義していません。値を通常の変数としてソフトコード値 $ OperatingSystem に置き換えました。

Puppetでは、使用および定義できる事実には3つのタイプがあります-

コアファクト
カスタムファクト
外部の事実

コアファクトはトップレベルで定義され、コード内のすべてのポイントでアクセスできます。

人形の事実

エージェントがマスターにカタログを要求する直前に、エージェントはまず、キー値ペアの形式でそれ自体で利用可能な情報の完全なリストをコンパイルします。エージェントに関する情報は、ファクターと呼ばれるツールによって収集され、各キーと値のペアはファクトと呼ばれます。以下は、エージェントに関するファクトの一般的な出力です。

[root@puppetagent1 ~]# facter
architecture => x86_64
augeasversion => 1.0.0
bios_release_date => 13/09/2012
bios_vendor => innotek GmbH
bios_version => VirtualBox
blockdevice_sda_model => VBOX HARDDISK
blockdevice_sda_size => 22020587520
blockdevice_sda_vendor => ATA
blockdevice_sr0_model => CD-ROM
blockdevice_sr0_size => 1073741312
blockdevice_sr0_vendor => VBOX
blockdevices => sda,sr0
boardmanufacturer => Oracle Corporation
boardproductname => VirtualBox
boardserialnumber => 0

domain => codingbee.dyndns.org
facterversion => 2.1.0
filesystems => ext4,iso9660
fqdn => puppetagent1.codingbee.dyndns.org
hardwareisa => x86_64
hardwaremodel => x86_64
hostname => puppetagent1
id => root
interfaces => eth0,lo
ipaddress => 172.228.24.01
ipaddress_eth0 => 172.228.24.01
ipaddress_lo => 127.0.0.1
is_virtual => true
kernel => Linux
kernelmajversion => 2.6
kernelrelease => 2.6.32-431.23.3.el6.x86_64
kernelversion => 2.6.32
lsbdistcodename => Final
lsbdistdescription => CentOS release 6.5 (Final)
lsbdistid => CentOS
lsbdistrelease => 6.5
lsbmajdistrelease => 6
lsbrelease => :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0noarch:graphics-4.0-amd64:
graphics-4.0-noarch:printing-4.0-amd64:printing-4.0noarch
macaddress => 05:00:22:47:H9:77
macaddress_eth0 => 05:00:22:47:H9:77
manufacturer => innotek GmbH
memoryfree => 125.86 GB
memoryfree_mb => 805.86
memorysize => 500 GB
memorysize_mb => 996.14
mtu_eth0 => 1500
mtu_lo => 16436
netmask => 255.255.255.0
netmask_eth0 => 255.255.255.0

network_lo => 127.0.0.0
operatingsystem => CentOS
operatingsystemmajrelease => 6
operatingsystemrelease => 6.5
osfamily => RedHat
partitions => {"sda1"=>{
"uuid"=>"d74a4fa8-0883-4873-8db0-b09d91e2ee8d", "size" =>"1024000",
"mount" => "/boot", "filesystem" => "ext4"}, "sda2"=>{"size" => "41981952",
"filesystem" => "LVM2_member"}
}
path =>/usr/lib64/qt3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
physicalprocessorcount => 1
processor0 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
processor1 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
processor2 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
processorcount => 3
productname => VirtualBox
ps => ps -ef
puppetversion => 3.6.2
rubysitedir =>/usr/lib/ruby/site_ruby/1.8
rubyversion => 1.8.7
selinux => true
selinux_config_mode => enforcing
selinux_config_policy => targeted
selinux_current_mode => enforcing
selinux_enforced => true
selinux_policyversion => 24
serialnumber => 0
sshdsakey => AAAAB3NzaC1kc3MAAACBAK5fYwRM3UtOs8zBCtRTjuHLw56p94X/E0UZBZwFR3q7
WH0x5+MNsjfmdCxKvpY/WlIIUcFJzvlfjXm4qDaTYalbzSZJMT266njNbw5WwLJcJ74KdW92ds76pjgm
CsjAh+R9YnyKCEE35GsYjGH7whw0gl/rZVrjvWYKQDOmJA2dAAAAFQCoYABgjpv3EkTWgjLIMnxA0Gfud
QAAAIBM4U6/nerfn6Qvt43FC2iybvwVo8ufixJl5YSEhs92uzsW6jiw68aaZ32q095/gEqYzeF7a2knr
OpASgO9xXqStYKg8ExWQVaVGFTR1NwqhZvz0oRSbrN3h3tHgknoKETRAg/imZQ2P6tppAoQZ8wpuLrXU
CyhgJGZ04Phv8hinAAAAIBN4xaycuK0mdH/YdcgcLiSn8cjgtiETVzDYa+jF
swapfree => 3.55 GB
swapfree_mb => 2015.99
swapsize => 3.55 GB
swapsize_mb => 2015.99
timezone => GMT
type => Other
uniqueid => a8c0af01
uptime => 45:012 hours
uptime_days => 0
uptime_hours => 6
uptime_seconds => 21865
uuid => BD8B9D85-1BFD-4015-A633-BF71D9A6A741
virtual => virtualbox

上記のコードでは、bashの「env」変数で使用可能な情報の一部とデータの一部が重複していることがわかります。 Puppetはデータを直接使用せず、代わりにファクターデータを使用します。Facterデータはグローバル変数として扱われます。

ファクトはトップレベル変数として利用可能になり、Puppetマスターはそれらを使用して、要求元エージェントのPuppetカタログをコンパイルできます。係数は、$プレフィックス付きの通常の変数としてマニフェストで呼び出されます。

例

if ($OperatingSystem == "Linux") {
   $message = "This machine OS is of the type $OperatingSystem \n"
} else {
   $message = "This machine is unknown \n"
}

file { "/tmp/machineOperatingSystem.txt":
   ensure => file,
   content => "$message"
}

上記のマニフェストファイルは、 machineOperatingSystem.txt という単一のファイルについてのみ気にします。このファイルの内容は、 OperatingSystem という事実によって差し引かれます。

[root@puppetagent1/]# facter OperatingSystem
Linux

[root@puppetagent1/]# puppet apply/tmp/ostype.pp
Notice: Compiled catalog for puppetagent1.codingbee.dyndns.org
in environment production in 0.07 seconds
Notice:/Stage[main]/Main/File[/tmp/machineOperatingSystem.txt]/ensure:
defined content as '{md5}f59dc5797d5402b1122c28c6da54d073'
Notice: Finished catalog run in 0.04 seconds

[root@puppetagent1/]# cat/tmp/machinetype.txt
This machine OS is of the type Linux

カスタムファクト

私たちが見た上記の事実はすべて、マシンの中核的な事実です。次の方法でノードにこのカスタムファクトを追加できます-

「export FACTER…構文」を使用する
$ LOAD_PATH設定を使用する
ファクトライブラリ
Pluginsync

「export FACTER」構文の使用

export FACTER _ \ {fact’s name}構文を使用して、ファクトを手動で追加できます。

例

[root@puppetagent1 facter]# export FACTER_tallest_mountain="Everest"
[root@puppetagent1 facter]# facter tallest_mountain Everest

$ LOAD_PATH設定の使用

Rubyでは、$ LOAD_PATHはBashの特殊パラメーターと同等です。 bash $ PATH変数に似ていますが、実際には$ LOAD_PATHは環境変数ではなく、事前定義された変数です。

$ LOAD_PATHには同義語「$：」があります。この変数は、値を検索してロードする配列です。

[root@puppetagent1 ~]# ruby -e 'puts $LOAD_PATH'
# note you have to use single quotes.
/usr/lib/ruby/site_ruby/1.6
/usr/lib64/ruby/site_ruby/1.6
/usr/lib64/ruby/site_ruby/1.6/x86_64-linux
/usr/lib/ruby/site_ruby
/usr/lib64/ruby/site_ruby
/usr/lib64/site_ruby/1.6
/usr/lib64/site_ruby/1.6/x86_64-linux
/usr/lib64/site_ruby
/usr/lib/ruby/1.6
/usr/lib64/ruby/1.6
/usr/lib64/ruby/1.6/x86_64-linux

ディレクトリファクタを作成し、*。pp *ファイルを追加し、それにコンテンツを追加する例を見てみましょう。

[root@puppetagent1 ~]# cd/usr/lib/ruby/site_ruby/
[root@puppetagent1 site_ruby]# mkdir facter
[root@puppetagent1 site_ruby]# cd facter/
[root@puppetagent1 facter]# ls
[root@puppetagent1 facter]# touch newadded_facts.rb

次のコンテンツをcustom_facts.rbファイルに追加します。

[root@puppetagent1 facter]# cat newadded_facts.rb
Facter.add('tallest_mountain') do
   setcode "echo Everest"
end

Facterは、$ LOAD_PATHにリストされているすべてのフォルダーをスキャンする方法で動作し、facterと呼ばれるディレクターを探します。特定のフォルダーが見つかると、フォルダー構造内の任意の場所にロードされます。このフォルダーを見つけると、そのファクターフォルダーでRubyファイルを探し、メモリ内の特定の構成に関するすべての定義済みファクトを読み込みます。

FACTERLIBを使用する

Puppetでは、FACTERLIBは$ LOAD_PATHと非常によく似ていますが、Rubyの特殊変数ではなく、OSレベルの環境パラメーターであるという重要な違いが1つあります。デフォルトでは、環境変数は設定されていません。

[root@puppetagent1 facter]# env | grep "FACTERLIB"
[root@puppetagent1 facter]#

FACTERLIBをテストするには、次の手順を実行する必要があります。

次の構造にtest_factsというフォルダーを作成します。

[root@puppetagent1 tmp]# tree/tmp/test_facts/
/tmp/some_facts/
├── vipin
│   └── longest_river.rb
└── testing
   └── longest_wall.rb

rbファイルに次の内容を追加します。.

[root@puppetagent1 vipin]# cat longest_river.rb
Facter.add('longest_river') do
   setcode "echo Nile"
end

[root@puppetagent1 testing]# cat longest_wall.rb
Facter.add('longest_wall') do
   setcode "echo 'China Wall'"
end

exportステートメントを使用します。

[root@puppetagent1/]# export
FACTERLIB = "/tmp/some_facts/river:/tmp/some_facts/wall"
[root@puppetagent1/]# env | grep "FACTERLIB"
FACTERLIB =/tmp/some_facts/river:/tmp/some_facts/wall

新しいファクターをテストします。

[root@puppetagent1/]# facter longest_river
Nile
[root@puppetagent1/]# facter longest_wall
China Wall

外部の事実

ユーザーがプロビジョニング時に作成されたいくつかの新しいファクトを適用したい場合、外部ファクトは非常に役立ちます。外部ファクトは、プロビジョニング段階でVMにメタデータを適用する重要な方法の1つです（例： vSphere、OpenStack、AWSなどを使用）

作成されたすべてのメタデータとその詳細をPuppetが使用して、カタログにどの詳細を適用するかを決定できます。

外部ファクトの作成

エージェントマシンで、以下に示すようにディレクトリを作成する必要があります。

$ mkdir -p/etc/facter/facts.d

ディレクトリに次の内容のシェルスクリプトを作成します。

$ ls -l/etc/facter/facts.d
total 4
-rwxrwxrwx. 1 root root 65 Sep 18 13:11 external-factstest.sh
$ cat/etc/facter/facts.d/external-factstest.sh
#!/bin/bash
echo "hostgroup = dev"
echo "environment = development"

スクリプトファイルの権限を変更します。

$ chmod u+x/etc/facter/facts.d/external-facts.sh

完了すると、キーと値のペアに存在する変数を見ることができます。

$ facter hostgroup
dev
$ facter environment
development

Puppetでカスタムファクトを作成できます。参考として、Puppetサイトから次のリンクを使用してください。

https://docs.puppet.com/facter/latest/fact_overviewl#writing-structured-facts

Puppet-リソース

リソースは、特定のインフラストラクチャまたはマシンを設計および構築するために使用されるPuppetの主要な基本ユニットの1つです。これらは主に、システム構成のモデリングと保守に使用されます。 Puppetには複数のタイプのリソースがあり、それらを使用してシステムアーキテクチャを定義したり、ユーザーが新しいリソースを構築および定義したりできます。

マニフェストファイルまたはその他のファイル内のPuppetコードのブロックは、リソース宣言と呼ばれます。コードのブロックは、宣言型モデリング言語（DML）と呼ばれる言語で記述されています。以下は、どのように見えるかの例です。

user { 'vipin':
   ensure => present,
   uid    => '552',
   shell  => '/bin/bash',
   home   => '/home/vipin',
}

Puppetでは、特定のリソースタイプのリソース宣言はコードブロックで行われます。次の例では、ユーザーは主に4つの事前定義されたパラメーターで構成されています。

リソースタイプ-上記のコードスニペットでは、ユーザーです。
リソースパラメータ-上記のコードスニペットでは、Vipinです。
属性-上記のコードスニペットでは、uid、shell、homeが確認されています。
値-これらは各プロパティに対応する値です。

各リソースタイプには、定義とパラメータを定義する独自の方法があり、ユーザーには、リソースの外観を選択する権限があります。

リソースタイプ

Puppetにはさまざまな種類のリソースがあり、それぞれ独自の機能を備えています。これらのリソースタイプは、「describe」コマンドと「-list」オプションを使用して表示できます。

[root@puppetmaster ~]# puppet describe --list
These are the types known to puppet:
augeas          - Apply a change or an array of changes to the  ...
computer        - Computer object management using DirectorySer ...
cron            - Installs and manages cron jobs
exec            - Executes external commands
file            - Manages files, including their content, owner ...
filebucket      - A repository for storing and retrieving file  ...
group           - Manage groups
host            - Installs and manages host entries
interface       - This represents a router or switch interface
k5login         - Manage the ‘.k5login’ file for a user
macauthorization - Manage the Mac OS X authorization database
mailalias       - .. no documentation ..
maillist        - Manage email lists
mcx             - MCX object management using DirectoryService  ...
mount           - Manages mounted filesystems, including puttin ...
nagios_command  - The Nagios type command
nagios_contact  - The Nagios type contact
nagios_contactgroup - The Nagios type contactgroup
nagios_host     - The Nagios type host
nagios_hostdependency - The Nagios type hostdependency
nagios_hostescalation - The Nagios type hostescalation
nagios_hostextinfo - The Nagios type hostextinfo
nagios_hostgroup - The Nagios type hostgroup

nagios_service  - The Nagios type service
nagios_servicedependency - The Nagios type servicedependency
nagios_serviceescalation - The Nagios type serviceescalation
nagios_serviceextinfo - The Nagios type serviceextinfo
nagios_servicegroup - The Nagios type servicegroup
nagios_timeperiod - The Nagios type timeperiod
notify          - .. no documentation ..
package         - Manage packages
resources       - This is a metatype that can manage other reso ...
router          - .. no documentation ..
schedule        - Define schedules for Puppet
scheduled_task  - Installs and manages Windows Scheduled Tasks
selboolean      - Manages SELinux booleans on systems with SELi ...
service         - Manage running services
ssh_authorized_key - Manages SSH authorized keys
sshkey          - Installs and manages ssh host keys
stage           - A resource type for creating new run stages
tidy            - Remove unwanted files based on specific crite ...
user            - Manage users
vlan            - .. no documentation ..
whit            - Whits are internal artifacts of Puppet's curr ...
yumrepo         - The client-side description of a yum reposito ...
zfs             - Manage zfs
zone            - Manages Solaris zones
zpool           - Manage zpools

リソースタイトル

上記のコードスニペットでは、コードの同じファイルで使用される各リソースに固有のvipinとしてリソースタイトルがあります。これは、このユーザーリソースタイプの一意のタイトルです。競合が発生するため、同じ名前のリソースを持つことはできません。

リソースコマンドを使用すると、タイプuserを使用してすべてのリソースのリストを表示できます。

[root@puppetmaster ~]# puppet resource user
user { 'abrt':
   ensure           => 'present',
   gid              => '173',
   home             => '/etc/abrt',
   password         => '!!',
   password_max_age => '-1',
   password_min_age => '-1',
   shell            => '/sbin/nologin',
   uid              => '173',
}

user { 'admin':
   ensure           => 'present',
   comment          => 'admin',
   gid              => '444',
   groups           => ['sys', 'admin'],
   home             => '/var/admin',
   password         => '*',
   password_max_age => '99999',
   password_min_age => '0',
   shell            => '/sbin/nologin',
   uid              => '55',
}

user { 'tomcat':
   ensure           => 'present',
   comment          => 'tomcat',
   gid              => '100',
   home             => '/var/www',
   password         => '!!',
   password_max_age => '-1',
   password_min_age => '-1',
   shell            => '/sbin/nologin',
   uid              => '100',
}

特定のユーザーのリソースの一覧表示

[root@puppetmaster ~]# puppet resource user tomcat
user { 'apache':
   ensure           => 'present',
   comment          => 'tomcat',
   gid              => '100',
   home             => '/var/www',
   password         => '!!',
   password_max_age => '-1',
   password_min_age => '-1',
   shell            => '/sbin/nologin',
   uid              => '100’,
}

属性と値

リソースの本体は、属性と値のペアのコレクションで構成されています。ここで、特定のリソースのプロパティの値を指定できます。各リソースタイプには、キーと値のペアで設定できる独自の属性セットがあります。

特定のリソース属性に関する詳細を取得するために使用できるサブコマンドを説明します。次の例では、ユーザーリソースに関する詳細と、その構成可能なすべての属性があります。

[root@puppetmaster ~]# puppet describe user
user
====
Manage users.  This type is mostly built to manage system users,
so it is lacking some features useful for managing normal users.

This resource type uses the prescribed native tools for creating groups
and generally uses POSIX APIs for retrieving information about them.
It does not directly modify ‘/etc/passwd’ or anything.

**Autorequires:* *If Puppet is managing the user's primary group
(as provided in the ‘gid’ attribute),
the user resource will autorequire that group.
If Puppet is managing any role accounts corresponding to the user's roles,
the user resource will autorequire those role accounts.

Parameters
----------
-* *allowdupe* *
   Whether to allow duplicate UIDs. Defaults to ‘false’.
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.

-* *attribute_membership* *
   Whether specified attribute value pairs should be treated as the
  * *complete list* *(‘inclusive’) or the* *minimum list* *(‘minimum’) of
   attribute/value pairs for the user. Defaults to ‘minimum’.
   Valid values are ‘inclusive’, ‘minimum’.

-* *auths* *
   The auths the user has.  Multiple auths should be
   specified as an array.
   Requires features manages_solaris_rbac.

-* *comment* *
   A description of the user.  Generally the user's full name.

-* *ensure* *
   The basic state that the object should be in.
   Valid values are ‘present’, ‘absent’, ‘role’.

-* *expiry**
   The expiry date for this user. Must be provided in
   a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19.
   If you want to make sure the user account does never
   expire, you can pass the special value ‘absent’.
   Valid values are ‘absent’. Values can match ‘/^\d{4}-\d{2}-\d{2}$/’.
   Requires features manages_expiry.

- **forcelocal* *
   Forces the mangement of local accounts when accounts are also
   being managed by some other NSS

-* *gid* *
   The user's primary group. Can be specified numerically or by name.
   This attribute is not supported on Windows systems; use the ‘groups’
   attribute instead. (On Windows, designating a primary group is only
   meaningful for domain accounts, which Puppet does not currently manage.)

-* *groups* *
   The groups to which the user belongs. The primary group should
   not be listed, and groups should be identified by name rather than by
   GID.  Multiple groups should be specified as an array.

-* *home* *
   The home directory of the user.  The directory must be created
   separately and is not currently checked for existence.

-* *ia_load_module* *
   The name of the I&A module to use to manage this user.
   Requires features manages_aix_lam.

-* *iterations* *
   This is the number of iterations of a chained computation of the
   password hash (http://en.wikipedia.org/wiki/PBKDF2).  This parameter
   is used in OS X. This field is required for managing passwords on OS X
   >= 10.8.
   Requires features manages_password_salt.

-* *key_membership* *

-* *managehome* *
   Whether to manage the home directory when managing the user.
   This will create the home directory when ‘ensure => present’, and
   delete the home directory when ‘ensure => absent’. Defaults to ‘false’.
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.

-* *membership* *
   Whether specified groups should be considered the* *complete list* *
   (‘inclusive’) or the* *minimum list* *(‘minimum’) of groups to which
   the user belongs. Defaults to ‘minimum’.
   Valid values are ‘inclusive’, ‘minimum’.

-* *name* *
   The user name. While naming limitations vary by operating system,
   it is advisable to restrict names to the lowest common denominator,
   which is a maximum of 8 characters beginning with a letter.
   Note that Puppet considers user names to be case-sensitive, regardless
   of the platform's own rules; be sure to always use the same case when
   referring to a given user.

-* *password* *
   The user's password, in whatever encrypted format the local
   system requires.
  * Most modern Unix-like systems use salted SHA1 password hashes. You can use
      Puppet's built-in ‘sha1’ function to generate a hash from a password.
 *Mac OS X 10.5 and 10.6 also use salted SHA1 hashes.

Windows API
   for setting the password hash.
   [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/
   Be sure to enclose any value that includes a dollar sign ($) in single
   quotes (') to avoid accidental variable interpolation.
   Requires features manages_passwords.

-* *password_max_age* *
   The maximum number of days a password may be used before it must be changed.
   Requires features manages_password_age.

-* *password_min_age* *
   The minimum number of days a password must be used before it may be changed.
   Requires features manages_password_age.

-* *profile_membership* *
   Whether specified roles should be treated as the* *complete list* *
   (‘inclusive’) or the* *minimum list* *(‘minimum’) of roles
   of which the user is a member. Defaults to ‘minimum’.
   Valid values are ‘inclusive’, ‘minimum’.

-* *profiles* *
   The profiles the user has.  Multiple profiles should be
   specified as an array.
   Requires features manages_solaris_rbac.

-* *project* *
   The name of the project associated with a user.
   Requires features manages_solaris_rbac.

-* *uid**
   The user ID; must be specified numerically. If no user ID is
   specified when creating a new user, then one will be chosen
   automatically. This will likely result in the same user having
   different UIDs on different systems, which is not recommended. This is
   especially noteworthy when managing the same user on both Darwin and
   other platforms, since Puppet does UID generation on Darwin, but
   the underlying tools do so on other platforms.
   On Windows, this property is read-only and will return the user's
   security identifier (SID).

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インターフェースを介して表示および管理することができます。

ユーザーリソースタイプの例

[root@puppetmaster ~]# puppet describe user --providers
user
====
Manage users.
This type is mostly built to manage systemusers,
so it is lacking some features useful for managing normalusers.
This resource type uses the prescribed native tools for
creating groups and generally uses POSIX APIs for retrieving informationabout them.
It does not directly modify '/etc/passwd' or anything.

- **comment* *
   A description of the user.  Generally the user's full name.

-* *ensure* *
   The basic state that the object should be in.
   Valid values are 'present', 'absent', 'role'.

-* *expiry* *
   The expiry date for this user.
   Must be provided in a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19.
   If you want to make sure the user account does never expire,
   you can pass the special value 'absent'.
   Valid values are 'absent'.
   Values can match '/^\d{4}-\d{2}-\d{2}$/'.
   Requires features manages_expiry.

-* *forcelocal* *
   Forces the management of local accounts when accounts are also
   being managed by some other NSS
   Valid values are 'true', 'false', 'yes', 'no'.
   Requires features libuser.

-* *gid* *
   The user's primary group.  Can be specified numerically or by name.
   This attribute is not supported on Windows systems; use the ‘groups’
   attribute instead. (On Windows, designating a primary group is only
   meaningful for domain accounts, which Puppet does not currently manage.)

-* *groups* *
   The groups to which the user belongs. The primary group should
   not be listed, and groups should be identified by name rather than by
   GID. Multiple groups should be specified as an array.

-* *home* *
   The home directory of the user.  The directory must be created
   separately and is not currently checked for existence.

-* *ia_load_module**
   The name of the I&A module to use to manage this user.
   Requires features manages_aix_lam.

- **iterations* *
   This is the number of iterations of a chained computation of the
   password hash (http://en.wikipedia.org/wiki/PBKDF2).
   This parameter is used in OS X.
   This field is required for managing passwords on OS X >= 10.8.

-* *key_membership* *
   Whether specified key/value pairs should be considered the
  * *complete list* *('inclusive') or the* *minimum list* *('minimum') of
   the user's attributes. Defaults to 'minimum'.
   Valid values are 'inclusive', 'minimum'.

-* *keys* *
   Specify user attributes in an array of key = value pairs.
   Requires features manages_solaris_rbac.

-* *managehome* *
   Whether to manage the home directory when managing the user.
   This will create the home directory when 'ensure => present', and
   delete the home directory when ‘ensure => absent’. Defaults to ‘false’.
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.

-* *membership* *
   Whether specified groups should be considered the* *complete list* *
   (‘inclusive’) or the* *minimum list* *(‘minimum’) of groups to which
   the user belongs. Defaults to ‘minimum’.
   Valid values are ‘inclusive’, ‘minimum’.

-* *name* *
   The user name. While naming limitations vary by operating system,
   it is advisable to restrict names to the lowest common denominator.

-* *password* *
   The user's password, in whatever encrypted format the local system requires.
  * Most modern Unix-like systems use salted SHA1 password hashes. You can use
      Puppet's built-in ‘sha1’ function to generate a hash from a password.
 *Mac OS X 10.5 and 10.6 also use salted SHA1 hashes.
  * Mac OS X 10.7 (Lion) uses salted SHA512 hashes.
   The Puppet Labs [stdlib][] module contains a ‘str2saltedsha512’
   function which can generate password hashes for Lion.
 *Mac OS X 10.8 and higher use salted SHA512 PBKDF2 hashes.
   When managing passwords on these systems the salt and iterations properties
   need to be specified as well as the password.
   [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/
   Be sure to enclose any value that includes a dollar sign ($) in single
   quotes (') to avoid accidental variable interpolation.
   Requires features manages_passwords.

-* *password_max_age* *
   The maximum number of days a password may be used before it must be changed.
Requires features manages_password_age.

-* *password_min_age* *
   The minimum number of days a password must be used before it may be changed.
Requires features manages_password_age.

-* *profile_membership* *
   Whether specified roles should be treated as the* *complete list* *
   (‘inclusive’) or the* *minimum list* *(‘minimum’) of roles
   of which the user is a member. Defaults to ‘minimum’.
   Valid values are ‘inclusive’, ‘minimum’.

-* *profiles* *
   The profiles the user has.  Multiple profiles should be
   specified as an array.
Requires features manages_solaris_rbac.

-* *project* *
   The name of the project associated with a user.
   Requires features manages_solaris_rbac.

-* *purge_ssh_keys* *
   Purge ssh keys authorized for the user
   if they are not managed via ssh_authorized_keys.
   When true, looks for keys in .ssh/authorized_keys in the user's home directory.
   Possible values are true, false, or an array of
   paths to file to search for authorized keys.
   If a path starts with ~ or %h, this token is replaced with the user's home directory.
   Valid values are ‘true’, ‘false’.

-* *role_membership* *
   Whether specified roles should be considered the* *complete list* *
   (‘inclusive’) or the* *minimum list* *(‘minimum’) of roles the user has.
   Defaults to ‘minimum’.
Valid values are ‘inclusive’, ‘minimum’.

-* *roles* *
   The roles the user has.  Multiple roles should be
   specified as an array.
Requires features manages_solaris_rbac.

-* *salt* *
   This is the 32 byte salt used to generate the PBKDF2 password used in
   OS X. This field is required for managing passwords on OS X >= 10.8.
   Requires features manages_password_salt.

-* *shell* *
   The user's login shell.  The shell must exist and be
   executable.
   This attribute cannot be managed on Windows systems.
   Requires features manages_shell.

-* *system* *
   Whether the user is a system user, according to the OS's criteria;
   on most platforms, a UID less than or equal to 500 indicates a system
   user. Defaults to ‘false’.
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.

-* *uid* *
   The user ID; must be specified numerically. If no user ID is
   specified when creating a new user, then one will be chosen
   automatically. This will likely result in the same user having
   different UIDs on different systems, which is not recommended.
   This is especially noteworthy when managing the same user on both Darwin and
   other platforms, since Puppet does UID generation on Darwin, but
   the underlying tools do so on other platforms.
   On Windows, this property is read-only and will return the user's
   security identifier (SID).

Providers
---------

-* *aix* *
   User management for AIX.
  * Required binaries: '/bin/chpasswd', '/usr/bin/chuser',
   '/usr/bin/mkuser', '/usr/sbin/lsgroup', '/usr/sbin/lsuser',
   '/usr/sbin/rmuser'.
 *Default for ‘operatingsystem’ == ‘aix’.
  * Supported features: ‘manages_aix_lam’, ‘manages_expiry’,
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’,
   ‘manages_shell’.

- **directoryservice* *
   User management on OS X.
  * Required binaries: ‘/usr/bin/dscacheutil’, ‘/usr/bin/dscl’,
   ‘/usr/bin/dsimport’, ‘/usr/bin/plutil’, ‘/usr/bin/uuidgen’.
 *Default for ‘operatingsystem’ == ‘darwin’.
  * Supported features: ‘manages_password_salt’, ‘manages_passwords’,
   ‘manages_shell’.

- **hpuxuseradd* *
   User management for HP-UX. This provider uses the undocumented ‘-F’
   switch to HP-UX's special ‘usermod’ binary to work around the fact that
   its standard ‘usermod’ cannot make changes while the user is logged in.
  * Required binaries: ‘/usr/sam/lbin/useradd.sam’,
   ‘/usr/sam/lbin/userdel.sam’, ‘/usr/sam/lbin/usermod.sam’.
 *Default for ‘operatingsystem’ == ‘hp-ux’.
  * Supported features: ‘allows_duplicates’, ‘manages_homedir’,
   ‘manages_passwords’.

- **ldap**
   User management via LDAP.
   This provider requires that you have valid values for all of the
   LDAP-related settings in ‘puppet.conf’, including ‘ldapbase’.
   You will almost definitely need settings for ‘ldapuser’ and ‘ldappassword’ in order
   for your clients to write to LDAP.
 *Supported features: ‘manages_passwords’, ‘manages_shell’.

-* *pw* *
   User management via ‘pw’ on FreeBSD and DragonFly BSD.
  * Required binaries: ‘pw’.
 *Default for ‘operatingsystem’ == ‘freebsd, dragonfly’.
  * Supported features: ‘allows_duplicates’, ‘manages_expiry’,
   ‘manages_homedir’, ‘manages_passwords’, ‘manages_shell’.

- **user_role_add* *
   User and role management on Solaris, via ‘useradd’ and ‘roleadd’.
  * Required binaries: ‘passwd’, ‘roleadd’, ‘roledel’, ‘rolemod’,
   ‘useradd’, ‘userdel’, ‘usermod’.
 *Default for ‘osfamily’ == ‘solaris’.
  * Supported features: ‘allows_duplicates’, ‘manages_homedir’,
   ‘manages_password_age’, ‘manages_passwords’, ‘manages_solaris_rbac’.

- **useradd* *
   User management via ‘useradd’ and its ilk.  Note that you will need to
   install Ruby's shadow password library (often known as ‘ruby-libshadow’)
   if you wish to manage user passwords.
  * Required binaries: ‘chage’, ‘luseradd’, ‘useradd’, ‘userdel’, ‘usermod’.
 *Supported features: ‘allows_duplicates’, ‘libuser’, ‘manages_expiry’,
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’,
   ‘manages_shell’, ‘system_users’.

-* *windows_adsi* *
   Local user management for Windows.
  * Default for 'operatingsystem' == 'windows'.
 *Supported features: 'manages_homedir', 'manages_passwords'.

テストリソース

Puppetでは、リソースのテストは、ターゲットノードの構成に使用するリソースを最初に適用する必要があることを直接示しているため、それに応じてマシンの状態が変化します。

テストのために、リソースをローカルに適用します。* user = vipin *で定義済みのリソースがあるため。リソースを適用する1つの方法はCLIです。これは、完全なリソースを単一のコマンドに再書き込みし、それをリソースサブコマンドに渡すことで実行できます。

puppet resource user vipin ensure = present uid = '505'
shell = '/bin/bash' home = '/home/vipin'

適用されたリソースをテストします。

[root@puppetmaster ~]# cat/etc/passwd | grep "vipin"
vipin:x:505:501::/home/vipin:/bin/bash

上記の出力は、リソースがシステムに適用され、Vipinという名前で新しいユーザーが作成されたことを示しています。上記のコードはすべてテストされており、動作するコードなので、自分でテストすることをお勧めします。

人形-テンプレート

*Templating* は、複数の場所で使用できる標準形式で物事を取得する方法です。 Puppetでは、標準のRubyライブラリの一部として提供されるerbを使用してテンプレートとテンプレートがサポートされます。これは、Ruby on RailsプロジェクトなどのRuby以外の他のプロジェクトで使用できます。 標準的な慣行として、Rubyの基本的な理解が必要です。 テンプレートファイルは、ユーザーがテンプレートファイルのコンテンツを管理しようとしているときに非常に役立ちます。 組み込みのPuppetタイプで構成を管理できない場合、テンプレートが重要な役割を果たします。

テンプレートの評価

テンプレートは、単純な関数を使用して評価されます。

$value = template ("testtemplate.erb")

テンプレートの完全なパスを指定するか、通常/var/puppet/templatesにあるPuppetのtemplatedir内のすべてのテンプレートをプルすることができます。 puppet –-configprint templatedirを実行すると、ディレクトリの場所を見つけることができます。

テンプレートは常にクライアントではなくパーサーによって評価されます。つまり、puppetmasterdを使用している場合、テンプレートはサーバー上にあればよく、クライアントにダウンロードする必要はありません。クライアントがテンプレートを使用することと、ファイルのすべてのコンテンツを文字列として指定することとの間に違いはありません。これは、puppetの起動段階でクライアント固有の変数がpuppetmasterdによって最初に学習されることを明確に示しています。

テンプレートを使用する

以下は、サイトをテストするためのTomcat設定を生成する例です。

define testingsite($cgidir, $tracdir) {
   file { "testing-$name":
   path => "/etc/tomcat/testing/$name.conf",
   owner => superuser,
   group => superuser,
   mode => 644,
   require => File[tomcatconf],
   content => template("testsite.erb"),
   notify => Service[tomcat]
}
   symlink { "testsym-$name":
      path => "$cgidir/$name.cgi",
      ensure => "/usr/share/test/cgi-bin/test.cgi"
   }
}

以下はテンプレート定義です。

<Location "/cgi-bin/<%= name %>.cgi">
   SetEnv TEST_ENV "/export/svn/test/<%= name %>"
</Location>

# You need something like this to authenticate users
<Location "/cgi-bin/<%= name %>.cgi/login">
   AuthType Basic
   AuthName "Test"
   AuthUserFile/etc/tomcat/auth/svn
   Require valid-user
</Location>

これにより、各テンプレートファイルが個別のファイルにプッシュされ、Apacheにこれらの構成ファイルを読み込むよう指示するだけで済みます。

Include/etc/apache2/trac/[^.#]*

テンプレートを結合する

次のコマンドを使用して、2つのテンプレートを簡単に組み合わせることができます。

template('/path/to/template1','/path/to/template2')

テンプレートでの反復

Puppetテンプレートは配列反復もサポートしています。アクセスしている変数が配列である場合、それを反復処理できます。

$values = [val1, val2, otherval]

次のようなテンプレートを作成できます。

<% values.each do |val| -%>
Some stuff with <%= val %>
<% end -%>

上記のコマンドは、次の結果を生成します。

Some stuff with val1
Some stuff with val2
Some stuff with otherval

テンプレートの条件

*erb* テンプレートは条件をサポートしています。 次の構成は、コンテンツをファイルに条件付きですばやく簡単に配置する方法です。

<% if broadcast != "NONE" %> broadcast <%= broadcast %> <% end %>

テンプレートと変数

テンプレートを使用して、ファイルの内容を記入するだけでなく、変数を記入することもできます。

testvariable = template('/var/puppet/template/testvar')

未定義の変数

変数を使用する前に定義されているかどうかを確認する必要がある場合、次のコマンドが機能します。

<% if has_variable?("myvar") then %>
myvar has <%= myvar %> value
<% end %>

スコープ外の変数

lookupvar関数を使用して、スコープ外の変数を明示的に探すことができます。

<%= scope.lookupvar('apache::user') %>

サンプルプロジェクトテンプレート

<#Autogenerated by puppet. Do not edit.
[default]
#Default priority (lower value means higher priority)
priority = <%= @priority %>
#Different types of backup. Will be done in the same order as specified here.
#Valid options: rdiff-backup, mysql, command
backups = <% if @backup_rdiff %>rdiff-backup,
<% end %><% if @backup_mysql %>mysql,
<% end %><% if @backup_command %>command<% end %>
<% if @backup_rdiff -%>

[rdiff-backup]

<% if @rdiff_global_exclude_file -%>
   global-exclude-file = <%= @rdiff_global_exclude_file %>
<% end -%>
   <% if @rdiff_user -%>
      user = <%= @rdiff_user %>
<% end -%>
<% if @rdiff_path -%>
   path = <%= @rdiff_path %>
<% end -%>

#Optional extra parameters for rdiff-backup

extra-parameters = <%= @rdiff_extra_parameters %>

#How long backups are going to be kept
keep = <%= @rdiff_keep %>
<% end -%>
<% if @backup_mysql -%>%= scope.lookupvar('apache::user') %>

[mysql]

#ssh user to connect for running the backup
sshuser =  <%= @mysql_sshuser %>

#ssh private key to be used
   sshkey = <%= @backup_home %>/<%= @mysql_sshkey %>
   <% end -%>
<% if @backup_command -%>
[command]

#Run a specific command on the backup server after the backup has finished

command = <%= @command_to_execute %>
<% end -%>

人形-クラス

Puppetクラスは、ターゲットノードまたはマシンを目的の状態にするためにグループ化されたリソースのコレクションとして定義されます。これらのクラスは、Puppetモジュール内にあるPuppetマニフェストファイル内で定義されます。クラスを使用する主な目的は、マニフェストファイルまたは他のPuppetコード内での同じコードの繰り返しを減らすことです。

以下は、Puppetクラスの例です。

[root@puppetmaster manifests]# cat site.pp
class f3backup (
   $backup_home   = '/backup',
   $backup_server = 'default',
   $myname        = $::fqdn,
   $ensure        = 'directory',
) {
   include '::f3backup::common'
   if ( $myname == '' or $myname == undef ) {
      fail('myname must not be empty')
   }
   @@file { "${backup_home}/f3backup/${myname}":
      # To support 'absent', though force will be needed
      ensure => $ensure,
      owner  => 'backup',
      group  => 'backup',
      mode   => '0644',
      tag    => "f3backup-${backup_server}",
   }
}

上記の例では、ユーザーが存在する必要がある2つのクライアントがあります。お気づきのように、同じリソースを2回繰り返しました。 2つのノードを結合する際に同じタスクを実行しない1つの方法。

[root@puppetmaster manifests]# cat site.pp
node 'Brcleprod001','Brcleprod002' {
   user { 'vipin':
      ensure => present,
      uid    => '101',
      shell  => '/bin/bash',
      home   => '/home/homer',
   }
}

この方法でノードをマージして構成を実行することはお勧めできません。これは、クラスを作成し、作成されたクラスを次のようにノードに含めることで簡単に実現できます。

class vipin_g01063908 {
   user { 'g01063908':
      ensure => present,
      uid    => '101',
      shell  => '/bin/bash',
      home   => '/home/g01063908',
   }
}
node 'Brcleprod001' {
   class {vipin_g01063908:}
}
node 'Brcleprod002' {
   class {vipin_g01063908:}
}

注目すべき点は、クラス構造がどのように見えるか、classキーワードを使用して新しいリソースを追加した方法です。 Puppetの各構文には独自の機能があります。したがって、選択する構文は条件によって異なります。

パラメータ化されたクラス

上記の例のように、クラスを作成してノードに含める方法を見てきました。現在、同じクラスを使用する各ノードで異なるユーザーを必要とする場合など、各ノードで異なる構成が必要な状況があります。この機能は、パラメーター化されたクラスを使用してPuppetで提供されます。新しいクラスの構成は、次の例のようになります。

[root@puppetmaster ~]# cat/etc/puppet/manifests/site.pp
class user_account ($username){
   user { $username:
      ensure => present,
      uid    => '101',
      shell  => '/bin/bash',
      home   => "/home/$username",
   }
}
node 'Brcleprod002' {
   class { user_account:
      username => "G01063908",
   }
}
node 'Brcleprod002' {
   class {user_account:
      username => "G01063909",
   }
}

上記のsite.ppマニフェストをノードに適用すると、各ノードの出力は次のようになります。

しょー

[root@puppetagent1 ~]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for puppetagent1.testing.dyndns.org
Info: Applying configuration version '1419452655'

Notice:/Stage[main]/User_account/User[homer]/ensure: created
Notice: Finished catalog run in 0.15 seconds
[root@brcleprod001 ~]# cat/etc/passwd | grep "vipin"
G01063908:x:101:501::/home/G01063909:/bin/bash

しょー

[root@Brcleprod002 ~]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for puppetagent2.testing.dyndns.org
Info: Applying configuration version '1419452725'

Notice:/Stage[main]/User_account/User[bart]/ensure: created
Notice: Finished catalog run in 0.19 seconds
[root@puppetagent2 ~]# cat/etc/passwd | grep "varsha"
G01063909:x:101:501::/home/G01063909:/bin/bash

次のコードに示すように、クラスパラメーターのデフォルト値を設定することもできます。

[root@puppetmaster ~]# cat/etc/puppet/manifests/site.pp
class user_account ($username = ‘g01063908'){
   user { $username:
      ensure => present,
      uid    => '101',
      shell  => '/bin/bash',
      home   => "/home/$username",
   }
}
node 'Brcleprod001' {
   class {user_account:}
}
node 'Brcleprod002' {
   class {user_account:
      username => "g01063909",
   }
}

パペット-機能

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」形式の変数参照です。

モジュールによって提供される型を含む、ネイティブ関数型と定義済み関数型の両方の関数チェックを定義します。タイプとクラスは名前で一致します。この関数は、リソース参照を使用して、リソースの減速と一致します。

関数の一致を定義する

# Matching resource types
defined("file")
defined("customtype")

# Matching defines and classes
defined("testing")
defined("testing::java")

# Matching variables
defined('$name')

# Matching declared resources
defined(File['/tmp/file'])

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ディレクトリ内のファイルに文字列を書き込むために使用される関数です。

module Puppet::Parser::Functions
   newfunction(:write_line_to_file) do |args|
      filename = args[0]
      str = args[1]
      File.open(filename, 'a') {|fd| fd.puts str }
   end
end

ユーザーが関数を宣言すると、以下に示すようにマニフェストファイルで使用できます。

write_line_to_file('/user/vipin.txt, "Hello vipin!")

Puppet-環境

ソフトウェア開発および配信モデルには、特定の製品またはサービスのテストに使用されるさまざまな種類のテスト環境があります。標準的な慣行として、主に開発、テスト、本番の3種類の環境があり、それぞれに独自のセット構成があります。

Puppetは、Ruby on Railsと同じラインに沿った複数の環境の管理をサポートしています。これらの環境の作成の背後にある重要な要素は、SLA契約のさまざまなレベルで管理するための簡単なメカニズムを提供することです。場合によっては、古いソフトウェアを使用せずに、マシンを常に稼働させる必要があります。ここで、他の環境は最新であり、テスト目的で使用されます。より重要なマシンのアップグレードに使用されます。

Puppetは、標準の本番環境、テスト環境、および開発環境の構成に固執することをお勧めしますが、ここでは、要件に応じてカスタム環境を作成することもできます。

環境目標

環境によって分割されたセットアップの主な目標は、Puppetがモジュールとマニフェストの異なるソースを持つことができることです。その後、実稼働ノードに影響を与えることなく、テスト環境で構成の変更をテストできます。これらの環境は、ネットワークのさまざまなソースにインフラストラクチャを展開するためにも使用できます。

Puppet Masterで環境を使用する

環境のポイントは、ファイルのどのマニフェスト、モジュール、テンプレートをクライアントに送信する必要があるかをテストすることです。したがって、Puppetは、これらの情報の環境固有のソースを提供するように構成する必要があります。

Puppet環境は、サーバーのpuppet.confにpre-environmentセクションを追加し、環境ごとに異なる構成ソースを選択するだけで実装されます。これらの事前環境セクションは、メインセクションに優先して使用されます。

[main]
manifest =/usr/testing/puppet/site.pp
modulepath =/usr/testing/puppet/modules
[development]
manifest =/usr/testing/puppet/development/site.pp
modulepath =/usr/testing/puppet/development/modules

上記のコードでは、開発環境のクライアントはディレクトリ /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ファイルで環境設定変数の値を指定できます。

[puppetd]
environment = Testing

構成ファイル内の上記の定義は、構成ファイルがどの環境でテストされているかを定義しています。

また、コマンドラインでこれを指定することもできます-

#puppetd -–environment = testing

あるいは、Puppetは環境設定での動的な値の使用もサポートしています。開発者は、静的な値を定義するのではなく、他のクライアント属性または外部データソースに基づいてクライアント環境を作成するカスタムファクトを作成するために活用します。推奨される方法は、カスタムツールを使用することです。これらのツールはノードの環境を指定することができ、一般的にノード情報を指定するのにはるかに優れています。

パペット検索パス

Puppetは単純な検索パスを使用して、ターゲットマシンに適用する必要がある構成を決定します。同様に、Puppetの検索パスは、適用する必要のある適切な値を取得しようとする場合に非常に便利です。 Puppetが適用する必要のある値を検索する場所は、以下にリストされているように複数あります。

コマンドラインで指定された値
環境固有のセクションで指定された値
実行可能ファイル固有のセクションで指定された値
メインセクションで指定された値

Puppet-タイプとプロバイダー

Puppetタイプは、個々の構成管理に使用されます。 Puppetには、サービスタイプ、パッケージタイプ、プロバイダータイプなどのさまざまなタイプがあります。各タイプにはプロバイダーがあります。プロバイダーは、さまざまなプラットフォームまたはツールで構成を処理します。たとえば、パッケージタイプにはaptitude、yum、rpm、およびDGMプロバイダーがあります。多くのタイプがあり、Puppetは管理が必要な優れたスペクトル構成管理項目をカバーしています。

Puppetはベース言語としてRubyを使用します。存在するすべてのPuppetタイプおよびプロバイダーは、Ruby言語で記述されています。標準のエンコード形式に従っているため、リポジトリを管理するリポジトリの例に示すように単純に作成できます。ここでは、タイプリポジトリとプロバイダーのsvnとgitを作成します。リポジトリタイプの最初の部分は、タイプ自体です。タイプは通常lib/puppet/typeに保存されます。このために、 repo.rb というファイルを作成します。

$ touch repo.rb

ファイルに次のコンテンツを追加します。

Puppet::Type.newtype(:repo) do
@doc = "Manage repos"
   Ensurable
   newparam(:source) do
      desc "The repo source"

      validate do |value|
         if value =~/^git/
            resource[:provider] = :git
         else
            resource[:provider] = :svn
         end
      end
      isnamevar
   end

   newparam(:path) do
      desc "Destination path"
      validate do |value|
         unless value =~/^\/[a-z0-9]+/
            raise ArgumentError , "%s is not a valid file path" % value
         end
      end
   end
end

上記のスクリプトでは、repoという名前の新しいタイプを作成するブロック「 *Puppet: Type.newtype（：repo）do* 」を作成しました。次に、追加したい詳細のレベルを追加するのに役立つ@docがあります。次のステートメントはEnsurableです。基本的なensureプロパティを作成します。 Puppetタイプは、 ensure プロパティを使用して構成アイテムの状態を判断します。

例

service { "sshd":
   ensure => present,
}

ensureステートメントは、Puppetに対して、作成、破棄、およびプロバイダ内に存在する3つのメソッド以外を指示します。これらの方法は、次の機能を提供します-

リソースを作成するコマンド
リソースを削除するコマンド
リソースの存在を確認するコマンド

その後、これらのメソッドとそのコンテンツを指定するだけです。 Puppetは、それらの周りにサポートインフラストラクチャを作成します。

次に、sourceという新しいパラメーターを定義します。

newparam(:source) do
   desc "The repo source"
   validate do |value|
      if value =~/^git/
         resource[:provider] = :git
      else
         resource[:provider] = :svn
      end
   end
   isnamevar
end

ソースは、ソースリポジトリを取得/クローン/チェックアウトする場所をリポジトリタイプに通知します。これでは、validateと呼ばれるフックも使用しています。プロバイダーセクションでは、定義したリポジトリの有効性をチェックするgitとsvnを定義しました。

最後に、コードでパスと呼ばれるもう1つのパラメーターを定義しました。

newparam(:path) do
   desc "Destination path"
   validate do |value|
      unless value =~/^\/[a-z0-9]+/
         raise ArgumentError , "%s is not a valid file path" % value
      end

これは、取得される新しいコードを配置する場所を指定する値タイプです。ここでも、validateフックを使用して、適切性の値をチェックするブロックを作成します。

Subversionプロバイダーの使用例

上記で作成したタイプを使用して、Subversionプロバイダーから始めましょう。

require 'fileutils'
Puppet::Type.type(:repo).provide(:svn) do
   desc "SVN Support"

   commands :svncmd => "svn"
   commands :svnadmin => "svnadmin"

   def create
      svncmd "checkout", resource[:name], resource[:path]
   end

   def destroy
      FileUtils.rm_rf resource[:path]
   end

   def exists?
      File.directory? resource[:path]
   end
end

上記のコードでは、 fileutils ライブラリが必要であり、メソッドを使用する 'fileutils' が必要であると事前に定義されています。

次に、プロバイダーをブロックPuppet: Type.type（：repo）.provide（：svn）doとして定義しました。これは、これがレポと呼ばれるタイプのプロバイダーであることをPuppetに伝えます。

次に、プロバイダーにドキュメントを追加できる desc を追加しました。このプロバイダーが使用するコマンドも定義しました。次の行では、作成、削除、存在などのリソースの機能を確認しています。

リソースを作成する

上記のすべてが完了したら、次のコードに示すように、クラスとマニフェストファイルで使用されるリソースを作成します。

repo { "wp":
   source => "http://g01063908.git.brcl.org/trunk/",
   path => "/var/www/wp",
   ensure => present,
}

Puppet-RESTful API

Puppetは、PuppetマスターとPuppetエージェント間の通信チャネルとしてRESTful APIを使用します。以下は、このRESTful APIにアクセスするための基本的なURLです。

https://brcleprod001:8140/{environment}/{resource}/{key}
https://brcleprod001:8139/{environment}/{resource}/{key}

REST APIセキュリティ

Puppetは通常、セキュリティとSSL証明書の管理を行います。ただし、クラスターの外部でRESTful APIを使用する場合は、マシンに接続しようとするときに証明書を独自に管理する必要があります。 Puppetのセキュリティポリシーは、残りのauthconfigファイルを使用して構成できます。

REST APIのテスト

Curlユーティリティは、RESTful API接続を休める基本的なユーティリティとして使用できます。以下は、REST API curlコマンドを使用してノードのカタログを取得する方法の例です。

curl --cert/etc/puppet/ssl/certs/brcleprod001.pem --key
  /etc/puppet/ssl/private_keys/brcleprod001.pem

次の一連のコマンドでは、SSL証明書を設定しているだけです。これは、SSLディレクトリの場所と使用されているノードの名前によって異なります。たとえば、次のコマンドを見てみましょう。

curl --insecure -H 'Accept: yaml'
https://brcleprod002:8140/production/catalog/brcleprod001

上記のコマンドでは、戻す形式を指定するヘッダーと、実稼働環境で brcleprod001 のカタログを生成するためのRESTful URLを送信するだけで、次の出力が生成されます。

--- &id001 !ruby/object:Puppet::Resource::Catalog
aliases: {}
applying: false
classes: []
...

PuppetマスターからCA証明書を取得する別の例を考えてみましょう。署名されたSSL証明書で認証される必要はありません。これは、認証される前に必要なことです。

curl --insecure -H 'Accept: s' https://brcleprod001:8140/production/certificate/ca

-----BEGIN CERTIFICATE-----
MIICHTCCAYagAwIBAgIBATANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDDAxwdXBw

Puppet MasterおよびAgent Shared APIリファレンス

GET/certificate/{ca, other}

curl -k -H "Accept: s" https://brcelprod001:8140/production/certificate/ca
curl -k -H "Accept: s" https://brcleprod002:8139/production/certificate/brcleprod002

Puppet Master APIリファレンス

認証済みリソース（有効な署名済み証明書が必要）。

カタログ

GET/{environment}/catalog/{node certificate name}

curl -k -H "Accept: pson" https://brcelprod001:8140/production/catalog/myclient

証明書失効リスト

GET/certificate_revocation_list/ca

curl -k -H "Accept: s" https://brcleprod001:8140/production/certificate/ca

証明書リクエスト

GET/{environment}/certificate_requests/{anything} GET
/{environment}/certificate_request/{node certificate name}

curl -k -H "Accept: yaml" https://brcelprod001:8140/production/certificate_requests/all
curl -k -H "Accept: yaml" https://brcleprod001:8140/production/certificate_request/puppetclient

レポートレポートを提出する

PUT/{environment}/report/{node certificate name}
curl -k -X PUT -H "Content-Type: text/yaml" -d "{key:value}" https://brcleprod002:8139/production

Node-特定のノードに関する事実

GET/{environment}/node/{node certificate name}

curl -k -H "Accept: yaml" https://brcleprod002:8140/production/node/puppetclient

ステータス-テストに使用

GET/{environment}/status/{anything}

curl -k -H "Accept: pson" https://brcleprod002:8140/production/certificate_request/puppetclient

Puppet Agent APIリファレンス

マシンに新しいエージェントがセットアップされると、デフォルトでは、PuppetエージェントはHTTP要求をリッスンしません。 puppet.confファイルに「listen = true」を追加して、Puppetで有効にする必要があります。これにより、Puppetエージェントの起動時にPuppetエージェントがHTTPリクエストをリッスンできるようになります。

事実

GET/{environment}/facts/{anything}

curl -k -H "Accept: yaml" https://brcelprod002:8139/production/facts/{anything}

実行-クライアントをパペットターンまたはパペットキックのように更新します。

PUT /{environment}/run/{node certificate name}

curl -k -X PUT -H "Content-Type: text/pson" -d "{}"
https://brcleprod002:8139/production/run/{anything}

Puppet-ライブプロジェクト

Puppetノードに構成とマニフェストを適用するライブテストを実行するために、ライブで動作するデモを使用します。これを直接コピーして貼り付けて、構成の動作をテストできます。ユーザーが同じコードセットを使用する場合は、次のコードスニペットに示されているのと同じ命名規則を使用する必要があります。

新しいモジュールの作成から始めましょう。

新しいモジュールの作成

httpd構成のテストと適用の最初のステップは、モジュールを作成することです。これを行うには、ユーザーは自分の作業ディレクトリをPuppetモジュールディレクトリに変更し、基本的なモジュール構造を作成する必要があります。構造の作成は、手動で、またはPuppetを使用してモジュールのボイラープレートを作成することで実行できます。

# cd/etc/puppet/modules
# puppet module generate Live-module

注-Puppet module generateコマンドでは、Puppet forgeの仕様に準拠するために、モジュール名が[ユーザー名]-[モジュール]の形式を取る必要があります。

新しいモジュールには、マニフェストディレクトリを含むいくつかの基本的なファイルが含まれています。ディレクトリには、モジュールのメインマニフェストファイルであるinit.ppという名前のマニフェストが既に含まれています。これは、モジュールの空のクラス宣言です。

class live-module {
}

モジュールには、 init.pp というマニフェストを含むテストディレクトリも含まれています。このテストマニフェストには、manifest/init.pp内のlive-moduleクラスへの参照が含まれています。

include live-module

Puppetはこのテストモジュールを使用してマニフェストをテストします。これで、構成をモジュールに追加する準備ができました。

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

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

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

# touch test-module/manifests/httpd.pp

このマニフェストには、モジュールのすべてのHTTP構成が含まれます。分離のために、httpd.ppファイルをinit.ppマニフェストファイルとは別にします

httpd.ppマニフェストファイルに次のコードを配置する必要があります。

class test-module::httpd {
   package { 'httpd':
      ensure => installed,
   }
}

このコードは、httpdというtest-moduleのサブクラスを定義してから、httpdパッケージのパッケージリソース宣言を定義します。 ensure ⇒ installed属性は、必要なパッケージがインストールされているかどうかを確認します。インストールされていない場合、Puppetはyumユーティリティを使用してインストールします。次に、このサブクラスをメインマニフェストファイルに含めます。 init.ppマニフェストを編集する必要があります。

class test-module {
   include test-module::httpd
}

次は、モジュールをテストする時間です。

# puppet apply test-module/tests/init.pp --noop

puppet applyコマンドは、ターゲットシステムのマニフェストファイルに存在する構成を適用します。ここでは、メインのinit.ppを参照するテストinit.ppを使用しています。 -noopは、構成の予行演習を実行します。これは、出力のみを表示しますが、実際には何もしません。

出力は以下のとおりです。

Notice: Compiled catalog for puppet.example.com in environment
production in 0.59 seconds

Notice:/Stage[main]/test-module::Httpd/Package[httpd]/ensure:
current_value absent, should be present (noop)

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 1
events

Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.67 seconds

ハイライト行は、== installed属性の結果です。 current_value不在は、Puppetがhttpdパッケージがインストールされていることを検出したことを意味します。 –noopオプションを指定しないと、Puppetはhttpdパッケージをインストールします。

httpdサーバーの実行

httpdサーバーをインストールした後、他のリソース減速を使用してサービスを開始する必要があります：サービス

httpd.ppマニフェストファイルを編集し、次のコンテンツを編集する必要があります。

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

以下は、上記のコードから達成した目標のリストです。

ensure ⇒ running statusは、サービスが実行されているかどうかを確認し、実行されていない場合は有効にします。
enable ⇒ true属性は、システムの起動時に実行するサービスを設定します。
require ⇒ Package ["httpd"] 属性は、あるリソースの減速と他のリソースの減速の順序関係を定義します。上記の場合、httpパッケージのインストール後にhttpdサービスが確実に開始されます。これにより、サービスと各パッケージの間に依存関係が作成されます。

puppet applyコマンドを実行して、変更を再度テストします。

# puppet apply test-module/tests/init.pp --noop
Notice: Compiled catalog for puppet.example.com in environment
production in 0.56 seconds

Notice:/Stage[main]/test-module::Httpd/Package[httpd]/ensure:
current_value absent, should be present (noop)

Notice:/Stage[main]/test-module::Httpd/Service[httpd]/ensure:
current_value stopped, should be running (noop)

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 2
events

Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.41 seconds

httpdサーバーの構成

上記の手順が完了したら、HTTPサーバーをインストールして有効にします。次のステップは、サーバーに何らかの構成を提供することです。デフォルトでは、httpdはWebホストポート80を提供する/etc/httpd/conf/httpd.confでいくつかのデフォルト設定を提供します。いくつかの追加のホストを追加して、ユーザー固有の機能をWebホストに提供します。

可変入力が必要なため、テンプレートを使用して追加のポートを提供します。 templateというディレクトリを作成し、test-server.config.erbというファイルを新しいディレクタに追加して、次のコンテンツを追加します。

Listen <%= @httpd_port %>
NameVirtualHost *:<% = @httpd_port %>

<VirtualHost *:<% = @httpd_port %>>
   DocumentRoot/var/www/testserver/
   ServerName <% = @fqdn %>

   <Directory "/var/www/testserver/">
      Options All Indexes FollowSymLinks
      Order allow,deny
      Allow from all
   </Directory>
</VirtualHost>

上記のテンプレートは、標準のapache-tomcatサーバー構成フォーマットに従います。唯一の違いは、Rubyエスケープ文字を使用してモジュールから変数を注入することです。システムの完全修飾ドメイン名を保存するFQDNがあります。これは*システムファクト*として知られています。

システムファクトは、各システムのパペットカタログを生成する前に各システムから収集されます。 Puppetはfacterコマンドを使用してこの情報を取得し、facterを使用してシステムに関するその他の詳細を取得できます。 httpd.ppマニフェストファイルにハイライト行を追加する必要があります。

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

これは、次のことを達成するのに役立ちます-

これにより、サーバー構成ファイル（/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マニフェストファイルを終了し、次のコンテンツを含める必要があります。

class test-module (
   $http_port = 80
) {
   include test-module::httpd
}

これにより、httpdポートがデフォルト値の80に設定されます。次に、Puppet applyコマンドを実行します。

出力は次のようになります。

# puppet apply test-module/tests/init.pp --noop
Warning: Config file/etc/puppet/hiera.yaml not found, using Hiera
defaults

Notice: Compiled catalog for puppet.example.com in environment
production in 0.84 seconds

Notice:/Stage[main]/test-module::Httpd/File[/var/www/myserver]/ensure:
current_value absent, should be directory (noop)

Notice:/Stage[main]/test-module::Httpd/Package[httpd]/ensure:
current_value absent, should be present (noop)

Notice:
/Stage[main]/test-module::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensure:
current_value absent, should be file (noop)

Notice:/Stage[main]/test-module::Httpd/Service[httpd]/ensure:
current_value stopped, should be running (noop)

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 4
events

Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.51 seconds

ファイアウォールの構成

サーバーと通信するには、ポートを開く必要があります。ここでの問題は、異なる種類のオペレーティングシステムが異なる方法でファイアウォールを制御することです。 Linuxの場合、6より下のバージョンはiptablesを使用し、バージョン7はfirewalldを使用します。

適切なサービスを使用するというこの決定は、システムファクトとそのロジックを使用してPuppetによってある程度処理されます。そのためには、まずOSを確認してから、適切なファイアウォールコマンドを実行する必要があります。

これを実現するには、testmodule: httpクラス内に次のコードスニペットを追加する必要があります。

if $operatingsystemmajrelease <= 6 {
   exec { 'iptables':
      command => "iptables -I INPUT 1 -p tcp -m multiport --ports
      ${httpd_port} -m comment --comment 'Custom HTTP Web Host' -j ACCEPT &&
      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 --addport = $ {
      httpd_port}/tcp --permanent",
      path => "/usr/bin/",
      refreshonly => true,
      subscribe => Package['httpd'],
   }
   service { 'firewalld':
      ensure => running,
      enable => true,
      hasrestart => true,
      subscribe => Exec['firewall-cmd'],
   }
}

上記のコードは次を実行します-

operatingsystemmajrelease を使用すると、使用されているOSがバージョン6か7かが決まります。
バージョンが6の場合、必要なすべての構成コマンドを実行して、Linux 6バージョンを構成します。
OSバージョンが7の場合、ファイアウォールの構成に必要なすべてのコマンドが実行されます。
両方のOSのコードスニペットには、httpパッケージのインストール後にのみ構成が実行されるようにするロジックが含まれています。

最後に、Puppet applyコマンドを実行します。

# puppet apply test-module/tests/init.pp --noop
Warning: Config file/etc/puppet/hiera.yaml not found, using Hiera
defaults

Notice: Compiled catalog for puppet.example.com in environment
production in 0.82 seconds

Notice:/Stage[main]/test-module::Httpd/Exec[iptables]/returns:
current_value notrun, should be 0 (noop)

Notice:/Stage[main]/test-module::Httpd/Service[iptables]: Would have
triggered 'refresh' from 1 events

SELinuxの構成

バージョン7以降のLinuxマシンで作業しているため、http通信を行うように設定する必要があります。 SELinuxは、デフォルトでHTTPサーバーへの非標準アクセスを制限します。カスタムポートを定義する場合、SELinuxを構成してそのポートへのアクセスを提供する必要があります。

Puppetには、ブール値やモジュールなどのSELinux機能を管理するためのリソースタイプが含まれています。ここでは、ポート設定を管理するためにsemanageコマンドを実行する必要があります。このツールはpolicycoreutils-pythonパッケージの一部であり、デフォルトではred-hatサーバーにはインストールされません。上記を実現するには、test-module: httpクラス内に次のコードを追加する必要があります。

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']は、必要なpythonモジュールがインストールされていることを確認します。
Puppetはsemanageを使用して、httpd_portを検証可能として使用してポートを開きます。
before ⇒サービスは、httpdサービスが開始する前にこのコマンドを実行するようにします。 SELinuxコマンドの前にHTTPDが開始された場合、SELinuxはサービスリクエストとサービスリクエストを失敗させます。

最後に、Puppet applyコマンドを実行します

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

Puppetは最初にpythonモジュールをインストールしてからポートアクセスを構成し、最後にhttpdサービスを開始します。

WebホストでのHTMLファイルのコピー

上記の手順で、httpサーバーの構成が完了しました。これで、Puppetが設定できるWebベースのアプリケーションをインストールする準備ができたプラットフォームができました。テストするために、いくつかのサンプルhtmlインデックスWebページをサーバーにコピーします。

ファイルディレクトリ内にindexlファイルを作成します。

<html>
   <head>
      <title>Congratulations</title>
   <head>

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

マニフェストディレクトリ内にマニフェストapp.ppを作成し、次のコンテンツを追加します。

class test-module::app {
   file { "/var/www/test-server/indexl":
      ensure => file,
      mode => 755,
      owner => root,
      group => root,
      source => "puppet:///modules/test-module/indexl",
      require => Class["test-module::httpd"],
   }
}

この新しいクラスには、単一のリソース減速が含まれています。これにより、モジュールのファイルディレクトリからウェブサーバーにファイルがコピーされ、その権限が設定されます。必須属性により、test-module: httpクラスがtest-module :: appを適用する前に構成を正常に完了することが保証されます。

最後に、メインのinit.ppマニフェストに新しいマニフェストを含める必要があります。

class test-module (
   $http_port = 80
) {
   include test-module::httpd
   include test-module::app
}

次に、applyコマンドを実行して、実際に何が起こっているかをテストします。出力は次のようになります。

# puppet apply test-module/tests/init.pp --noop
Warning: Config file/etc/puppet/hiera.yaml not found, using Hiera
defaults

Notice: Compiled catalog for brcelprod001.brcle.com in environment
production in 0.66 seconds

Notice:/Stage[main]/Test-module::Httpd/Exec[iptables]/returns:
current_value notrun, should be 0 (noop)

Notice:/Stage[main]/Test-module::Httpd/Package[policycoreutilspython]/
ensure: current_value absent, should be present (noop)

Notice:/Stage[main]/Test-module::Httpd/Service[iptables]: Would have
triggered 'refresh' from 1 events

Notice:/Stage[main]/Test-module::Httpd/File[/var/www/myserver]/ensure:
current_value absent, should be directory (noop)

Notice:/Stage[main]/Test-module::Httpd/Package[httpd]/ensure:
current_value absent, should be present (noop)

Notice:
/Stage[main]/Test-module::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensur
e: current_value absent, should be file (noop)

Notice:/Stage[main]/Test-module::Httpd/Exec[semanage-port]/returns:
current_value notrun, should be 0 (noop)

Notice:/Stage[main]/Test-module::Httpd/Service[httpd]/ensure:
current_value stopped, should be running (noop)

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 8
Notice:
/Stage[main]/test-module::App/File[/var/www/myserver/indexl]/ensur:
current_value absent, should be file (noop)

Notice: Class[test-module::App]: Would have triggered 'refresh' from 1
Notice: Stage[main]: Would have triggered 'refresh' from 2 events Notice:
Finished catalog run in 0.74 seconds

強調表示された行は、indexlファイルがWebホストにコピーされた結果を示しています。

モジュールの完成

上記のすべての手順で、作成した新しいモジュールを使用する準備が整いました。モジュールのアーカイブを作成する場合は、次のコマンドを使用して実行できます。

# puppet module build test-module

Puppet-quick-guide

Puppet-概要

Puppet Systemの機能

べき等

クロスプラットフォーム

Puppet-ワークフロー

Puppet-主要コンポーネント

Puppetリソース

プロバイダ

マニフェスト

モジュール

テンプレート

静的ファイル

Puppet-アーキテクチャ

パペットマスター

パペットエージェント

構成リポジトリ

事実

カタログ

Puppet-インストール

前提条件

標準OSライブラリ

ファクターのインストール

ソースからのPuppetのインストール

Ruby Gemを使用したPuppetとFacterのインストール

Puppet-設定

マシンのファイアウォールポートを開く

構成ファイル

リストファイルと設定ファイル

Puppet.conf

メイン構成セクション

Puppetマスター構成ファイル

詳細概要

構成セクション

構成ファイルの主要コンポーネント

コメント行

設定行

変数を設定する

パス

ファイルとディレクトリ

Puppet-環境設定

ロケーション

例

フォーマット

値の相対パス

値の内挿

許可された設定

モジュールパス

マニフェスト

Config_version

環境タイムアウト

サンプルenvironment.confファイル

実稼働環境の構成ファイル

人形-マスター

前提条件

Puppet Master Serverの作成

NTPのインストール

利用可能なタイムゾーンのリスト

Puppet Serverソフトウェアのセットアップ

Puppet Serverでメモリ割り当てを構成する

Puppet.confマスターセクション

Puppet-エージェントのセットアップ

Puppet-SSL署名証明書のセットアップ

現在の証明書要求を一覧表示する

リクエストに署名する

Puppetセットアップからのホストの取り消し

すべての署名済みリクエストの表示

Puppet-r10Kのインストールと設定

r10k Configの構成ファイルを作成する

Puppetマニフェストとモジュールのインストール

インストールのテスト

Puppet-Puppetセットアップの検証

仮想マシンのセットアップ

ディレクトリ構造

Vagrant File

複数マシン構成の検証

新しい構成済みVagrantファイル

Puppet-コーディングスタイル

基本単位

リソース