Puppet-クイックガイド
Puppetは、インフラストラクチャの管理と構成を自動化するためにPuppetLabsによって開発された構成管理ツールです。Puppetは、コードとしてのインフラストラクチャの概念に役立つ非常に強力なツールです。このツールはRubyDSL言語で記述されており、インフラストラクチャ全体をコード形式に変換するのに役立ちます。コード形式は、簡単に管理および構成できます。
Puppetは、クライアントサーバーモデルに従います。このモデルでは、任意のクラスター内の1台のマシンがサーバーとして機能し、Puppetマスターと呼ばれ、もう1台がノード上のスレーブと呼ばれるクライアントとして機能します。Puppetには、初期構成から特定のマシンの寿命が尽きるまで、システムを最初から管理する機能があります。
操り人形システムの特徴
以下は、Puppetの最も重要な機能です。
べき等
Puppetは、べき等性をサポートしているため、独自性があります。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で使用される特定のリソースのフルフィルメントです。たとえば、パッケージタイプ「apt-get」と「yum」はどちらもパッケージ管理に有効です。特定のプラットフォームで複数のプロバイダーを利用できる場合があります。ただし、各プラットフォームには常にデフォルトのプロバイダーがあります。
マニフェスト
マニフェストは、任意のターゲットシステムを構成するために関数またはクラス内で結合されるリソースのコレクションです。これらには、システムを構成するための一連のRubyコードが含まれています。
モジュール
モジュールはPuppetの主要な構成要素であり、リソース、ファイル、テンプレートなどのコレクションとして定義できます。これらは、同じフレーバーであると定義されているさまざまな種類のOSに簡単に分散できます。簡単に配布できるため、1つのモジュールを同じ構成で複数回使用できます。
テンプレート
テンプレートはRuby式を使用して、カスタマイズされたコンテンツと変数入力を定義します。これらは、カスタムコンテンツの開発に使用されます。テンプレートはマニフェストで定義され、システム上の場所にコピーされます。たとえば、カスタマイズ可能なポートを使用してhttpdを定義する場合は、次の式を使用して定義できます。
Listen <% = @httpd_port %>この場合のhttpd_port変数は、このテンプレートを参照するマニフェストで定義されています。
静的ファイル
静的ファイルは、特定のタスクを実行するために必要になることがある一般的なファイルとして定義できます。Puppetを使用して、ある場所から別の場所に簡単にコピーできます。すべての静的ファイルは、任意のモジュールのファイルディレクトリ内にあります。マニフェスト内のファイルの操作は、ファイルリソースを使用して行われます。
以下は、Puppetアーキテクチャの図式表現です。
操り人形マスター
Puppet Masterは、構成に関連するすべてのものを処理する主要なメカニズムです。Puppetエージェントを使用してノードに構成を適用します。
人形エージェント
Puppet Agentは、Puppetマスターによって管理される実際の作業マシンです。Puppetエージェントデーモンサービスが内部で実行されています。
構成リポジトリ
これは、すべてのノードとサーバー関連の構成が保存され、必要に応じてプルされるリポジトリです。
事実
Factsノードまたはマスターマシンに関連する詳細であり、基本的に任意のノードの現在のステータスを分析するために使用されます。事実に基づいて、変更は任意のターゲットマシンで行われます。Puppetには、事前定義されたカスタムファクトがあります。
カタログ
Puppetで記述されたすべてのマニフェストファイルまたは構成は、最初にカタログと呼ばれるコンパイル済み形式に変換され、後でそれらのカタログがターゲットマシンに適用されます。
Puppetは、サーバーをPuppetマスターと呼び、クライアントをPuppetノードと呼ぶクライアントサーバーアーキテクチャで動作します。このセットアップは、Puppetをクライアントとすべてのサーバーマシンの両方にインストールすることで実現されます。
ほとんどのプラットフォームでは、Puppetは選択したパッケージマネージャーを介してインストールできます。ただし、一部のプラットフォームでは、をインストールすることで実行できます。tarball または RubyGems。
前提条件
ファクターは、一緒に来ない唯一の前提条件です Ohai これはシェフに存在します。
標準OSライブラリ
基盤となるOSのライブラリの標準セットが必要です。残りのすべてのシステムには、Ruby 1.8.2+バージョンが付属しています。以下は、OSが構成する必要のあるライブラリアイテムのリストです。
- base64
- cgi
- digest/md5
- etc
- fileutils
- ipaddr
- openssl
- strscan
- syslog
- uri
- webrick
- webrick/https
- xmlrpc
ファクターのインストール
議論したように、 facterRubyの標準版には付属していません。したがって、ファクトライブラリはPuppetの前提条件であるため、ターゲットシステムにファクタを取得するには、ソースからファクタを手動でインストールする必要があります。
このパッケージは複数のプラットフォームで利用できますが、安全のために、次の方法でインストールできます。 tarball、最新バージョンの入手に役立ちます。
まず、ダウンロードします tarball Puppetの公式サイトから wget ユーティリティ。
$ wget http://puppetlabs.com/downloads/facter/facter-latest.tgz ------: 1次に、tarファイルのtarを解除します。CDコマンドを使用して、風袋引きされていないディレクトリ内に入ります。最後に、を使用してファクターをインストールしますinstall.rb 内部に存在するファイル facter ディレクトリ。
$ 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のインストール
まず、PuppetサイトからPuppettarballを使用してインストールします。 wget。次に、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 -------: 4RubyGemを使用した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.gemPuppetをシステムにインストールしたら、次のステップは、特定の初期操作を実行するようにPuppetを構成することです。
マシンでファイアウォールポートを開く
Puppetサーバーでクライアントのサーバーを一元管理するには、すべてのマシンで指定されたポートを開く必要があります。 8140構成しようとしているどのマシンでも使用されていない場合に使用できます。すべてのマシンでTCP通信とUDP通信の両方を有効にする必要があります。
構成ファイル
Puppetの主な設定ファイルは etc/puppet/puppet.conf。すべての構成ファイルは、Puppetのパッケージベースの構成で作成されます。Puppetの構成に必要な構成のほとんどはこれらのファイルに保持され、Puppetの実行が行われると、それらの構成が自動的に取得されます。ただし、Webサーバーや外部認証局（CA）の構成などの特定のタスクについては、Puppetにはファイルと設定の個別の構成があります。
サーバー構成ファイルはにあります conf.dPuppetマスターとしても知られているディレクトリ。これらのファイルはデフォルトで下にあります/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マスター、Puppetエージェント、Puppet適用、証明書の定義など、Puppetに関連するすべての設定がこのファイルで定義されています。Puppetは、要件に従ってそれらを参照できます。
構成ファイルは標準のiniファイルに似ており、設定はメインセクションの特定のアプリケーションセクションに移動できます。
メイン構成セクション
[main]
certname = Test1.vipin.com
server = TestingSrv
environment = production
runinterval = 1hPuppet MasterConfigファイル
[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構成ファイルは、主に次の構成セクションで構成されています。
Main−これは、Puppetのすべてのコマンドとサービスで使用されるグローバルセクションとして知られています。1つは、puppet.confファイルに存在する任意のセクションによってオーバーライドできるメインセクションのデフォルト値を定義します。
Master −このセクションは、PuppetマスターサービスおよびPuppetcertコマンドによって参照されます。
Agent −このセクションは、Puppetエージェントサービスによって参照されます。
User −これは主に、Puppetのapplyコマンドと、あまり一般的ではないコマンドの多くで使用されます。
[main]
certname = PuppetTestmaster1.example.com構成ファイルの主要コンポーネント
以下は、構成ファイルの主要なコンポーネントです。
コメント行
Puppetでは、コメント行は（#）サイン。これは、任意のスペースで意図できます。同じ行内に部分的なコメントを含めることもできます。
# This is a comment.
Testing = true #this is also a comment in same line設定行
設定行は-で構成されている必要があります
- 任意の量の先頭スペース（オプション）
- 設定名
- 等号=記号は、任意の数のスペースで囲むことができます
- 設定値
変数の設定
ほとんどの場合、設定の値は1語になりますが、特別な場合には、特別な値がほとんどありません。
パス
構成ファイルの設定で、ディレクトリのリストを取得します。これらのディレクトリを定義するときは、システムパス区切り文字で区切る必要があることに注意してください。これは、* 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では、すべての環境に 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.confenvironment.confファイルに[main]セクションを含めることはできません。environment.confファイルのすべての設定は、構成セクションの外にある必要があります。
値の相対パス
許可されている設定のほとんどは、ファイルパスまたはパスのリストを値として受け入れます。パスのいずれかが関連するパスである場合、それらは先頭のスラッシュまたはドライブ文字なしで始まります-それらはほとんどその環境のメインディレクトリに関連して解決されます。
値の補間
Environment.conf設定ファイルは、他の設定の値を変数として使用できます。environment.confファイルに補間できる有用な変数が複数あります。ここにいくつかの重要な変数のリストがあります-
$basemodulepath−モジュールパス設定にディレクトリを含めるのに便利です。Puppetエンタープライズユーザーは通常、この値を含める必要がありますmodulepath Puppetエンジンはモジュールを使用するため basemodulepath。
$environment−config_versionスクリプトのコマンドライン引数として役立ちます。この変数は、config_version設定でのみ補間できます。
$codedir −ファイルの検索に役立ちます。
許可される設定
デフォルトでは、Puppet environment.confファイルは、リストされている構成の4つの設定のみをオーバーライドできます。
- Modulepath
- Manifest
- 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 構成が行われている環境の名前です。
ProductionReady環境の構成ファイル
# 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マスターをセットアップする手順です。
前提条件
Private Network DNS−順方向と逆方向を構成する必要があります。各サーバーには一意のホスト名が必要です。DNSが構成されていない場合は、インフラストラクチャとの通信にプライベートネットワークを使用できます。
Firewall Open Port− Puppetマスターは、特定のポートで着信要求をリッスンできるように、特定のポートで開いている必要があります。ファイアウォールで開いている任意のポートを使用できます。
Puppetマスターサーバーの作成
私たちが作成しているPuppetマスターは、ホスト名としてPuppetを使用するCentOS7×64マシン上にあります。Puppetマスターを作成するための最小システム構成は、2つのCPUコアと1GBのメモリです。このマスターで管理するノードの数によっては、構成のサイズも大きくなる場合があります。インフラストラクチャでは、2GBのRAMを使用して構成されているよりも大きいです。
| ホスト名 | 役割 | プライベートFQDN |
|---|---|---|
| Brcleprod001 | 操り人形マスター | bnrcleprod001.brcl.com |
次に、PuppetマスターSSL証明書を生成する必要があり、マスターマシンの名前がすべてのノードの構成ファイルにコピーされます。
NTPのインストール
Puppetマスターは、特定のセットアップにおけるエージェントノードの中央機関であるため、ノードにエージェント証明書を発行するときに発生する可能性のある潜在的な構成の問題を回避するために、正確なシステム時間を維持することはPuppetマスターの重要な責任の1つです。
時間の競合の問題が発生した場合、マスターとノードの間に時間の不一致があると、証明書が期限切れになっているように見えることがあります。ネットワークタイムプロトコルは、このような問題を回避するための重要なメカニズムの1つです。
利用可能なタイムゾーンの一覧表示
$ timedatectl list-timezones上記のコマンドは、利用可能なタイムゾーンの全リストを提供します。リージョンにタイムゾーンの可用性を提供します。
次のコマンドを使用して、マシンに必要なタイムゾーンを設定できます。
$ sudo timedatectl set-timezone India/DelhiCentOSマシンのyumユーティリティを使用して、PuppetサーバーマシンにNTPをインストールします。
$ sudo yum -y install ntpNTPを上記のコマンドで設定したシステム時刻と同期します。
$ sudo ntpdate pool.ntp.org一般的には、マシンのデータセンターの近くで利用できる共通プールを使用するようにNTP構成を更新します。このために、下のntp.confファイルを編集する必要があります/etc。
$ 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 ntpdPuppetサーバーソフトウェアのセットアップ
Puppetサーバーソフトウェアは、Puppetマスターマシンで実行されるソフトウェアです。これは、Puppetエージェントソフトウェアを実行している他のマシンに構成をプッシュするマシンです。
次のコマンドを使用して、公式のPuppetラボコレクションリポジトリを有効にします。
$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpmpuppetserverパッケージをインストールします。
$ sudo yum -y install puppetserverPuppetサーバーでのメモリ割り当ての構成
すでに説明したように、デフォルトでは、Puppetサーバーは2GBのRAMマシンで構成されます。マシンで使用可能な空きメモリとサーバーが管理するノードの数に応じて、セットアップをカスタマイズできます。
viモードでパペットサーバーの構成を編集する
$ 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次に、マスターサーバーが起動するたびにpuppetサーバーが起動するようにセットアップを行います。
$ sudo systemctl enable puppetserverPuppet.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エージェントソフトウェアをその特定のサーバーにインストールする必要があります。通常、Puppetエージェントは、特定のインフラストラクチャ上のPuppetマスターマシンを除くすべてのマシンにインストールされます。Puppetエージェントソフトウェアには、ほとんどのLinux、UNIX、およびWindowsマシンで実行する機能があります。次の例では、CentOSマシンインストールのPuppetエージェントソフトウェアを使用しています。
Step 1 −次のコマンドを使用して、公式のPuppetラボコレクションリポジトリを有効にします。
$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpmStep 2 −Puppetエージェントパッケージをインストールします。
$ sudo yum -y install puppet-agentStep 3 − Puppetエージェントがインストールされたら、次のコマンドで有効にします。
$ sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable = truePuppetエージェントの重要な機能の1つは、Puppetエージェントが初めて実行を開始すると、SSL証明書を生成し、署名と承認のために管理するPuppetマスターに送信することです。Puppetマスターがエージェントの証明書署名要求を承認すると、Puppetマスターはエージェントノードと通信して管理できるようになります。
Note −特定のPuppetマスターを構成および管理する必要があるすべてのノードで上記の手順を繰り返す必要があります。
PuppetエージェントソフトウェアがいずれかのPuppetノードで初めて実行されると、証明書が生成され、証明書署名要求がPuppetマスターに送信されます。Puppetサーバーがエージェントノードと通信して制御できるようになる前に、その特定のエージェントノードの証明書に署名する必要があります。次のセクションでは、署名および署名要求の確認方法について説明します。
現在の証明書要求を一覧表示する
Puppetマスターで、次のコマンドを実行して、署名されていないすべての証明書要求を表示します。
$ sudo /opt/puppetlabs/bin/puppet cert list新しいエージェントノードを設定したばかりなので、承認のリクエストが1つ表示されます。以下はoutput。
"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以下は output。
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 --allPuppetセットアップからのホストの取り消し
セットアップからホストを削除して再度追加する必要がある場合、カーネル再構築の構成には条件があります。これらは、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には、開発、テスト、本番など、Puppetで構成できるさまざまな種類の環境に関連する環境構成の管理に役立つr10kと呼ばれるコード管理ツールがあります。これは、環境関連の構成をソースコードリポジトリに保存するのに役立ちます。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/environmentsr10kConfigの構成ファイルを作成します
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'
EOFPuppetマニフェストとモジュールのインストール
r10k deploy environment -pv15分ごとに環境を更新し続ける必要があるため、同じための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.guestPuppetでは、セットアップをローカルでテストできます。したがって、Puppetマスターとノードをセットアップしたら、セットアップをローカルで検証します。VagrantとVagrantboxをローカルにインストールする必要があります。これは、セットアップをローカルでテストするのに役立ちます。
仮想マシンのセットアップ
セットアップをローカルでテストしているため、実際には実行中のPuppetマスターは必要ありません。つまり、サーバー上でPuppetマスターを実際に実行しなくても、Puppetを使用してPuppetセットアップ検証のコマンドを適用するだけで済みます。Puppet applyコマンドは、からの変更を適用しますlocal/etc/puppet 構成ファイル内の仮想マシンのホスト名によって異なります。
セットアップをテストするために実行する必要がある最初のステップは、以下をビルドすることです。 Vagrantfile マシンを起動してマウントします /etc/puppetフォルダーを所定の位置に配置します。必要なすべてのファイルは、次の構造でバージョン管理システム内に配置されます。
ディレクトリ構造
- manifests
\- site.pp
- modules
\- your modules
- test
\- update-puppet.sh
\- Vagrantfile
- puppet.confVagrantファイル
# -*- 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上記のコードでは、Shellプロビジョナーを使用して、という名前のシェルスクリプトを実行しようとしています。 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 command。これにより、新しい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"
endSSLユーティリティをインストールする必要がある新しい本番サーバーがあると仮定します。次の構成で古いマニフェストを拡張する必要があります。
node 'brcleprod004.brcl.com' inherits 'brcleloacl003.brcl.com' {
package { ['SSL'] :
ensure => latest
}
}マニフェストファイルで構成を変更した後、テストディレクトリに移動し、基本的なvagrantupコマンドを実行するだけで両方が表示されます。 brclelocal003.brcl.com そして brcleprod004.brcl.com機械。私たちの場合、私たちは、を実行することによって行うことができる生産機械を立ち上げようとしていますvagrant up production command。は、Vagrantファイルで定義されているproductionという名前の新しいマシンを作成し、SSLパッケージがインストールされます。
Puppetでは、コーディングスタイルは、マシン構成のインフラストラクチャをコードに変換しようとするときに従う必要のあるすべての標準を定義します。Puppetは、リソースを使用して、定義されたすべてのタスクを実行します。
Puppetの言語定義は、管理が必要なターゲットマシンを管理するために必要な、構造化された方法ですべてのリソースを指定するのに役立ちます。Puppetは、エンコーディング言語としてRubyを使用します。これには、コード側の単純な構成で非常に簡単に作業を行うことができる複数の機能が組み込まれています。
基本単位
Puppetは、理解と管理が容易な複数の基本的なコーディングスタイルを使用しています。以下はいくつかのリストです。
リソース
Puppetでは、リソースは基本モデリングユニットと呼ばれ、ターゲットシステムを管理または変更するために使用されます。リソースは、ファイル、サービス、パッケージなど、システムのすべての側面をカバーしています。Puppetには、ユーザーまたは開発者がカスタムリソースを開発できる機能が組み込まれており、マシンの特定のユニットの管理に役立ちます。
Puppetでは、すべてのリソースは次のいずれかを使用して集約されます。 “define” または “classes”。これらの集約機能は、モジュールの編成に役立ちます。以下は、複数のタイプ、タイトル、およびPuppetが複数の属性をサポートできる属性のリストで構成されるサンプルリソースです。Puppetの各リソースには独自のデフォルト値があり、必要に応じてオーバーライドできます。
ファイルのサンプルPuppetリソース
次のコマンドでは、特定のファイルのアクセス許可を指定しようとしています。
file {
'/etc/passwd':
owner => superuser,
group => superuser,
mode => 644,
}上記のコマンドがいずれかのマシンで実行されると、システム内のpasswdファイルが説明どおりに構成されていることを確認します。before：colonのファイルはリソースのタイトルであり、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],
}この依存関係により、 sshd サービスは、 sshdconfigファイルの変更。ここで覚えておくべきポイントはFile[sshdconfig] 小文字のようにファイルとしての宣言ですが、に変更すると 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での集約のこの概念は、次の2つの強力な方法を使用して実現されます。classes そして definition。
クラスと定義
クラスは、ノードの基本的な側面をモデル化する責任があります。彼らはノードがウェブサーバーであり、この特定のノードがそれらの1つであると言うことができます。Puppetでは、プログラミングクラスはシングルトンであり、ノードごとに1回評価できます。
一方、定義は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では、継承のOOP概念がデフォルトでサポートされており、クラスは、新しく作成されたクラスに完全なコードビットを再度コピーして貼り付けることなく、以前の機能を拡張できます。継承により、サブクラスは親クラスで定義されたリソース設定をオーバーライドできます。継承を使用する際に留意すべき重要な点の1つは、クラスが継承できるのは1つの親クラスからのみであり、複数ではないということです。
class superclass inherits testsubclass {
File['/etc/passwd'] { group => wheel }
File['/etc/shadow'] { group => wheel }
}親クラスで指定されたロジックを元に戻す必要がある場合は、次を使用できます。 undef command。
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は、実行ステージの概念をサポートしています。つまり、ユーザーは、特定のリソースまたは複数のリソースを管理するために、要件に応じて複数のステージを追加できます。この機能は、ユーザーが複雑なカタログを開発する場合に非常に役立ちます。複雑なカタログでは、定義されたリソース間の依存関係に影響を与えないように注意しながら、コンパイルする必要のあるリソースが多数あります。
Run Stageは、リソースの依存関係を管理するのに非常に役立ちます。これは、特定のクラスにリソースのコレクションが含まれる定義済みの段階でクラスを追加することで実行できます。実行ステージを使用すると、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 keyword (not class)そしてそれらは継承ではなく引数をサポートします。それらは、異なるパラメーターを使用して同じシステムで複数回実行できます。
たとえば、同じシステム上に複数のリポジトリを作成しようとしているソースコードリポジトリを制御する定義を作成したい場合は、クラスではなく定義を使用できます。
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. Definitions can have both a $タイトルと $name with which the name and the title can be represented. By default, $タイトルと $name are set to the same value, but one can set a title attribute and pass different name as a parameter. $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からすべての機能を継承しています。
高度なサポート機能
Quoting−ほとんどの場合、Puppetで文字列を引用する必要はありません。文字で始まる英数字の文字列は、引用符なしで残してください。ただし、負でない値については文字列を引用することが常にベストプラクティスです。
引用符を使用した変数補間
これまで、定義の観点から変数について説明してきました。これらの変数を文字列で使用する必要がある場合は、一重引用符ではなく二重引用符を使用してください。一重引用符の文字列は変数の補間を行いませんが、二重引用符の文字列は行います。変数は括弧で囲むことができます{} これにより、それらを一緒に使用しやすく、理解しやすくなります。
$value = "${one}${two}"ベストプラクティスとして、文字列補間を必要としないすべての文字列に一重引用符を使用する必要があります。
大文字化
大文字と小文字の区別は、特定のリソースの参照、継承、およびデフォルト属性の設定に使用されるプロセスです。それを使用する基本的に2つの基本的な方法があります。
Referencing−作成済みのリソースを参照する方法です。これは主に依存関係の目的で使用され、リソースの名前を大文字にする必要があります。例、require =>ファイル[sshdconfig]
Inheritance−サブクラスから親クラスの設定を上書きする場合は、大文字のリソース名を使用してください。小文字バージョンを使用すると、エラーが発生します。
Setting Default Attribute Value −タイトルのない大文字のリソースを使用すると、リソースのデフォルトを設定できます。
配列
Puppetでは、複数の領域[1、2、3]で配列を使用できます。
ホスト定義のエイリアスなど、いくつかのタイプメンバーは、値に配列を受け入れます。複数のエイリアスを持つホストリソースは、次のようになります。
host { 'one.vipin.com':
alias => [ 'satu', 'dua', 'tiga' ],
ip => '192.168.100.1',
ensure => present,
}上記のコードはホストを追加します ‘one.brcletest.com’ 3つのエイリアスを持つホストリストへ ‘satu’ ‘dua’ ‘tiga’。1つのリソースに複数のリソースを追加したい場合は、次の例に示すように行うことができます。
resource { 'baz':
require => [ Package['rpm'], File['testfile'] ],
}変数
Puppetは、他のほとんどのプログラミング言語と同様に、複数の変数をサポートしています。Puppet変数はで示されます$。
$content = 'some content\n' file { '/tmp/testing': content => $content }前述のように、Puppetは宣言型言語です。つまり、そのスコープと割り当てルールは命令型言語とは異なります。主な違いは、変数の値を決定するためにファイル内の順序に依存しているため、単一のスコープ内で変数を変更できないことです。宣言型言語では順序は重要ではありません。
$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では、セレクターインデックスは複数値の3方向演算子のように機能します。セレクターは、マニフェストで定義され、条件に一致するカスタムデフォルト値を値なしで定義することもできます。
$owner = $Sysoperenv ? {
sunos => 'adm',
redhat => 'bin',
default => undef,
}Puppet 0.25.0以降のバージョンでは、セレクターを正規表現として使用できます。
$owner = $Sysoperenv ? {
/(Linux|Ubuntu)/ => 'bin',
default => undef,
}上記の例では、セレクター $Sysoperenv 値がLinuxまたはUbuntuのいずれかに一致する場合、binが選択された結果になります。それ以外の場合、ユーザーは未定義として設定されます。
ステートメント条件
ステートメント条件は、シェルスクリプトのswitch case条件と非常によく似た、Puppetの他のタイプの条件ステートメントです。この場合、複数のケースステートメントのセットが定義され、指定された入力値が各条件と照合されます。
指定された入力条件に一致するcaseステートメントが実行されます。このcaseステートメントの条件には戻り値はありません。Puppetでは、条件ステートメントの非常に一般的な使用例は、基盤となるオペレーティングシステムに基づいて一連のコードビットを実行することです。
case $ Sysoperenv {
sunos: { include solaris }
redhat: { include redhat }
default: { include generic}
}Case Statementは、複数の条件をコンマで区切って指定することもできます。
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には、現在2種類のサポートされているコメントがあります。
- Unixシェルスタイルのコメント。それらは、独自の行または次の行に配置できます。
- 複数行のcスタイルのコメント。
以下は、シェルスタイルのコメントの例です。
# this is a comment以下は、複数行コメントの例です。
/*
This is a comment
*/オペレーターの優先順位
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"
}同様に、unlessが正常に終了しない限り、コマンドを常に実行しない限り、unlessを使用できます。
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は、modulesディレクトリ内のapache / templatesフォルダ内でvhost.erbテンプレートを探します。
サービスの定義とトリガー
Puppetには、特定のマシンまたは環境で実行されているすべてのサービスのライフサイクルを管理できるサービスと呼ばれるリソースがあります。サービスリソースは、サービスが初期化されて有効になっていることを確認するために使用されます。また、サービスの再起動にも使用されます。
たとえば、以前の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では、Rubyプログラミング言語を使用して記述され、拡張子が .pp と呼ばれる manifests。一般的に、ターゲットホストマシンを作成または管理することを目的として構築されたすべてのPuppetプログラムは、マニフェストと呼ばれます。Puppetで記述されたすべてのプログラムは、Puppetコーディングスタイルに従います。
Puppetの中核は、リソースが宣言される方法と、これらのリソースがそれらの状態をどのように表すかです。どのマニフェストでも、ユーザーは、クラスと定義を使用してグループ化されたさまざまな種類のリソースのコレクションを持つことができます。
場合によっては、Puppetマニフェストに、目的の状態を実現するための条件ステートメントを含めることもできます。ただし、最終的には、すべてのリソースが正しい方法で定義および使用され、カタログに変換された後に適用されたときに定義されたマニフェストが、設計されたタスクを実行できることを確認する必要があります。
マニフェストファイルのワークフロー
Puppetマニフェストは次のコンポーネントで構成されています-
Files （これらは、Puppetがそれらとは関係がなく、それらを取得してターゲットの場所に配置するだけのプレーンファイルです）
Resources
Templates （これらは、ノード上に構成ファイルを作成するために使用できます）。
Nodes （クライアントノードに関連するすべての定義はここで定義されます）
Classes
注意点
Puppetでは、すべてのマニフェストファイルはエンコード言語としてRubyを使用し、 .pp 拡張。
多くのマニフェストの「インポート」ステートメントは、Puppetの起動時にファイルをロードするために使用されます。
ディレクトリに含まれるすべてのファイルをインポートするには、import'clients / * 'のような別の方法でimportステートメントを使用できます。これはすべてをインポートします.pp そのディレクトリ内のファイル。
マニフェストを書く
変数の操作
マニフェストを作成している間、ユーザーはマニフェストの任意の時点で新しい変数を定義したり、既存の変数を使用したりできます。Puppetはさまざまな種類の変数をサポートしていますが、文字列や文字列の配列など、頻繁に使用される変数はほとんどありません。それらとは別に、他の形式もサポートされています。
文字列変数の例
$package = "vim" package { $package:
ensure => "installed"
}ループの使用
ループは、定義された条件が満たされるまで、同じコードセットで複数の反復を実行する場合に使用されます。また、さまざまな値のセットを使用して繰り返しタスクを実行するためにも使用されます。10の異なるものに対して10のタスクを作成します。単一のタスクを作成し、ループを使用して、インストールするさまざまなパッケージでタスクを繰り返すことができます。
最も一般的には、配列は異なる値でテストを繰り返すために使用されます。
$packages = ['vim', 'git', 'curl'] package { $packages:
ensure => "installed"
}条件文の使用
Puppetは、従来のプログラミング言語に見られるほとんどの条件付き構造をサポートしています。条件を使用して、特定のタスクを実行するか、一連のコードを実行するかを動的に定義できます。if / elseやcaseステートメントのように。さらに、executeなどの条件は、conditionと同様に機能する属性もサポートしますが、条件としてコマンド出力のみを受け入れます。
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は、モジュールの簡単な再配布をサポートします。これは、指定された汎用モジュールを記述でき、簡単なコード変更をほとんど行わずに複数回使用できるため、コードのモジュール化に非常に役立ちます。たとえば、これにより、/ etc / puppetでデフォルトのサイト構成が有効になり、Puppetによって出荷されたモジュールが/ etc / share / puppetに適切に配置されます。
モジュール構成
どのPuppetモジュールにも、コードの構造を定義し、宗派を制御するのに役立つ2つのパーティションがあります。
モジュールの検索パスは、コロンで区切られたディレクトリのリストを使用して構成されます。 puppetmasterd または masterd、Puppetのマスター構成ファイルの後のセクション modulepath パラメータ。
[puppetmasterd]
...
modulepath = /var/lib/puppet/modules:/data/puppet/modulesfileserver.conf内のファイルサーバーモジュールのアクセス制御設定。そのモジュールのパス構成は常に無視され、パスを指定すると警告が生成されます。
実行時に検索パスを追加するには、PUPPETLAB環境変数を設定します。この環境変数は、コロンで区切った変数のリストでもある必要があります。
モジュールソース
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ファイルはマニフェストフォルダのすぐ下に追加できます。追加の.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を使用できます。つまり、明示的なサーバー名のない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は、セットアップ内の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 *上記のコードスニペットでは、コードはクライアントからファイル/private/file.txtを検索しようとしています。 client1.vipin.com。/data/private/client1/file.txtで検索しますが、client2.vipin.comに対する同じリクエストは、ファイルサーバー上のファイル/data/private/client2/file.txtを取得しようとします。
セキュリティ
Puppetは、Puppetファイルサーバー上のファイルを保護するという2つの基本的な概念をサポートしています。これは、特定のファイルへのアクセスを許可し、不要なファイルへのアクセスを拒否することで実現されます。デフォルトでは、Puppetはどのファイルにもアクセスを許可しません。明示的に定義する必要があります。ファイルでアクセスを許可または拒否するために使用できる形式は、IPアドレス、名前、またはグローバル許可を使用することです。
クライアントがPuppetファイルサーバーに直接接続されていない場合、たとえばリバースプロキシとMongrelを使用している場合、ファイルサーバーはすべての接続をPuppetクライアントではなくプロキシサーバーからのものとして認識します。上記の場合、ホスト名に基づいてホスト名を制限することがベストプラクティスです。
ファイル構造を定義する際に注意すべき重要な点の1つは、すべてのdenyステートメントがallowステートメントの前に解析されることです。したがって、いずれかのdenyステートメントがホストと一致する場合、そのホストは拒否され、次のファイルにallowステートメントが書き込まれない場合、ホストは拒否されます。この機能は、特定のサイトの優先順位を設定するのに役立ちます。
ホスト名
どのファイルサーバー構成でも、ファイルホスト名は、次の例に示すように、完全なホスト名を使用するか、*ワイルドカードを使用してドメイン名全体を指定するかの2つの方法で指定できます。
[export]
path /usr
allow brcleprod001.brcl.com
allow *.brcl.com
deny brcleprod002.brcl.comIPアドレス
どのファイルサーバー構成でも、完全なIPアドレスまたはワイルドカードアドレスを使用して、ホスト名と同様にファイルアドレスを指定できます。CIDRシステム表記を使用することもできます。
[export]
path /usr
allow 127.0.0.1
allow 172.223.30.*
allow 172.223.30.0/24グローバル許可
グローバル許可は、ユーザーが全員が特定のモジュールにアクセスできるようにする場合に使用されます。これを行うには、1つのワイルドカードを使用すると、全員がモジュールにアクセスできます。
[export]
path /export
allow *Puppetは、環境変数として複数の値を保持することをサポートしています。この機能は、Puppetで次を使用してサポートされていますfacter。Puppetでは、facterは環境レベル変数を保持するスタンドアロンツールです。Inは、BashまたはLinuxのenv変数に類似していると見なすことができます。ファクトに格納されている情報とマシンの環境変数が重複している場合があります。Puppetでは、キーと値のペアは「ファクト」と呼ばれます。各リソースには独自のファクトがあり、Puppetではユーザーは独自のカスタムファクトを構築するためのレバレッジを持っています。
# facterFacter commandさまざまな環境変数とそれに関連する値をすべて一覧表示するために使用できます。これらのファクトのコレクションには、すぐに使用できるファクトが付属しており、コアファクトと呼ばれます。コレクションにカスタムファクトを追加できます。
1つの変数のみを表示したい場合。次のコマンドを使用して実行できます。
# facter {Variable Name}
Example
[root@puppetmaster ~]# facter virtual
virtualboxファクトがPuppetにとって重要である理由は、ファクトとファクトがPuppetコード全体で次のように利用できるためです。 “global variable”、つまり、他の参照なしでいつでもコードで使用できます。
テストする例
[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つのタイプのファクトがあります-
- コアファクト
- カスタムファクト
- 外部の事実
コアファクトはトップレベルで定義され、コードの任意の時点ですべての人がアクセスできます。
人形の事実
エージェントがマスターにカタログを要求する直前に、エージェントはまず、キーと値のペアの形式で、それ自体で利用可能な情報の完全なリストをコンパイルします。エージェントに関する情報は、facterと呼ばれるツールによって収集され、各キーと値のペアはファクトと呼ばれます。以下は、エージェントに関する事実の一般的な出力です。
[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はデータを直接使用せず、代わりにファクトデータを使用します。ファクトデータはグローバル変数として扱われます。
ファクトはトップレベルの変数として利用可能になり、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カスタムファクト
私たちが見た上記のすべての事実は、マシンのコアファクトです。このカスタムファクトを次の方法でノードに追加できます-
- 「exportFACTER…構文」の使用
- $ LOAD_PATH設定の使用
- FACTERLIB
- Pluginsync
「exportFACTER」構文の使用
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 is equivalent to Bash special parameter. Although it is similar to 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"
endFacterは、$ LOAD_PATHにリストされているすべてのフォルダーをスキャンする方法で機能し、facterと呼ばれるディレクターを探します。その特定のフォルダが見つかると、フォルダ構造内の任意の場所にそれらをロードします。このフォルダーが見つかると、そのファクトフォルダーでRubyファイルを探し、メモリ内の特定の構成について定義されているすべてのファクトをロードします。
FACTERLIBの使用
Puppetでは、FACTERLIBは$ LOAD_PATHと非常によく似ていますが、重要な違いが1つだけあります。それは、Rubyの特殊変数ではなくOSレベルの環境パラメーターです。デフォルトでは、環境変数は設定されていない可能性があります。
[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'"
endexportステートメントを使用します。
[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
developmentPuppetでカスタムファクトを書くことができます。参考までに、Puppetサイトから次のリンクを使用してください。
https://docs.puppet.com/facter/latest/fact_overview.html#writing-structured-facts
リソースは、特定のインフラストラクチャまたはマシンを設計および構築するために使用されるPuppetの主要な基本単位の1つです。これらは主に、システム構成のモデリングと保守に使用されます。Puppetには複数のタイプのリソースがあり、システムアーキテクチャを定義するために使用できます。または、ユーザーは新しいリソースを構築および定義するために活用できます。
マニフェストファイルまたはその他のファイル内のPuppetコードのブロックは、リソース宣言と呼ばれます。コードのブロックは、宣言型モデリング言語（DML）と呼ばれる言語で記述されています。以下はそれがどのように見えるかの例です。
user { 'vipin':
ensure => present,
uid => '552',
shell => '/bin/bash',
home => '/home/vipin',
}Puppetでは、特定のリソースタイプのリソース宣言はコードブロックで行われます。次の例では、ユーザーは主に4つの事前定義されたパラメーターで構成されています。
Resource Type −上記のコードスニペットでは、ユーザーです。
Resource Parameter −上記のコードスニペットでは、Vipinです。
Attributes −上記のコードスニペットでは、ensure、uid、shell、homeです。
Values −これらは各プロパティに対応する値です。
各リソースタイプには、定義とパラメーターを定義する独自の方法があり、ユーザーには、リソースの外観を希望する方法を選択する権限があります。
リソースタイプ
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では、リソース抽象化レイヤー（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を使用することです。これは、リソース全体を1つのコマンドに書き直してから、それをresourcesubコマンドに渡すことで実行できます。
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 on RailsプロジェクトのようにRuby以外の他のプロジェクトで使用できる、標準のRubyライブラリの一部として提供されるerbを使用してサポートされます。標準的な方法として、Rubyの基本を理解している必要があります。テンプレートファイルは、ユーザーがテンプレートファイルのコンテンツを管理しようとしているときに非常に役立ちます。組み込みのPuppetタイプで構成を管理できない場合、テンプレートは重要な役割を果たします。
テンプレートの評価
テンプレートは、単純な関数を使用して評価されます。
$value = template ("testtemplate.erb")テンプレートのフルパスを指定することも、通常/ var / puppet / templatesにあるPuppetのtemplatedirですべてのテンプレートをプルすることもできます。puppet –-configprint templatedirを実行すると、ディレクトリの場所を見つけることができます。
テンプレートは常にクライアントではなくパーサーによって評価されます。つまり、puppetmasterdを使用している場合、テンプレートはサーバー上にあるだけでよく、クライアントにダウンロードする必要はありません。テンプレートを使用する場合と、ファイルのすべてのコンテンツを文字列として指定する場合で、クライアントの見方に違いはありません。これは、クライアント固有の変数が、パペットの起動フェーズ中に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マニフェストをノードに適用すると、各ノードの出力は次のようになります。
Brcleprod001
[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/bashBrcleprod002
[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は他のプログラミング言語と同様に関数をサポートします。の名前で知られている2種類の関数をサポートしていますstatement そして rvalue 関数。
Statements自立しており、戻り値の型はありません。これらは、新しいマニフェストファイルに他のPuppetモジュールをインポートするなどのスタンドアロンタスクを実行するために使用されます。
Rvalue 値を返し、代入やcaseステートメントなど、ステートメントに値が必要な場合にのみ使用できます。
Puppetでの関数の実行の背後にある鍵は、Puppetマスターでのみ実行され、クライアントまたはPuppetエージェントでは実行されないことです。したがって、Puppetマスターで使用可能なコマンドとデータにのみアクセスできます。すでに存在するさまざまな種類の関数があり、ユーザーでさえ、要件に応じてカスタム関数を作成する特権を持っています。いくつかの組み込み関数を以下に示します。
ファイル機能
ファイルリソースのファイル機能は、Puppetにモジュールをロードし、目的の出力を文字列の形式で返すことです。探す引数は、<モジュール名> / <ファイル>参照です。これは、Puppetモジュールのファイルディレクトリからモジュールをロードするのに役立ちます。
script / tesingscript.shのように、<モジュール名> /script/files/testingscript.shからファイルをロードします。関数には、絶対パスを読み取って受け入れる機能があり、ディスク上のどこからでもファイルをロードするのに役立ちます。
インクルード機能
Puppetでは、include関数は他のプログラミング言語のinclude関数と非常によく似ています。これは、1つ以上のクラスの宣言に使用されます。これにより、それらのクラス内に存在するすべてのリソースが評価され、最終的にカタログに追加されます。それが機能する方法は、include関数がクラス名、クラスのリスト、またはクラス名のコンマ区切りのリストを受け入れることです。
を使用する際に留意すべき1つのこと includeステートメントは、クラス内で複数回使用できますが、1つのクラスを1回だけ含めるという制限があります。インクルードされたクラスがパラメーターを受け入れる場合、インクルード関数は、ルックアップキーとして<クラス名> :: <パラメーター名>を使用してそれらの値を自動的にルックアップします。
Include関数は、宣言されたときにクラスがクラスに含まれることを引き起こしません。そのため、含まれる関数を使用する必要があります。宣言されたクラスとそれを取り巻くクラスに依存関係を作成することさえありません。
インクルード関数では、クラスのフルネームのみが許可され、相対名は許可されません。
定義された関数
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'])前の章で説明したように、functionはユーザーにカスタム関数を開発する特権を提供します。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
新しい関数の作成
新しい関数は、を使用して作成または定義されます newfunction 内部のメソッド puppet::parser::Functionsモジュール。関数名をシンボルとしてに渡す必要があります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!")ソフトウェアの開発および提供モデルには、特定の製品またはサービスをテストするために使用されるさまざまな種類のテスト環境があります。標準的な方法として、開発、テスト、本番の3種類の環境があり、それぞれに独自の構成が設定されています。
Puppetは、Ruby onRailsと同じラインに沿った複数の環境の管理をサポートします。これらの環境の作成の背後にある重要な要素は、さまざまなレベルのSLA契約で管理するための簡単なメカニズムを提供することです。場合によっては、マシンは常に許容範囲を超えて古いソフトウェアを使用せずに稼働している必要があります。他の環境は最新であり、テスト目的で使用されます。これらは、より重要なマシンのアップグレードに使用されます。
Puppetは、標準の本番環境、テスト環境、および開発環境の構成を使用することをお勧めしますが、ここでは、要件に応じてカスタム環境を作成することもできます。
環境目標
環境によって分割されたセットアップの主な目標は、Puppetがモジュールとマニフェストのさまざまなソースを持つことができることです。その後、本番ノードに影響を与えることなく、テスト環境で構成の変更をテストできます。これらの環境を使用して、さまざまなネットワークソースにインフラストラクチャを展開することもできます。
PuppetMasterでの環境の使用
環境のポイントは、ファイルのどのマニフェスト、モジュール、テンプレートをクライアントに送信する必要があるかをテストすることです。したがって、Puppetは、これらの情報の環境固有のソースを提供するように構成する必要があります。
Puppet環境は、事前環境セクションをサーバーのpuppet.confに追加し、環境ごとに異なる構成ソースを選択するだけで実装されます。これらの事前環境セクションは、メインセクションよりも優先して使用されます。
[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上記のコードでは、開発環境のすべてのクライアントは、ディレクトリにあるsite.ppマニフェストファイルを使用します /usr/share/puppet/development Puppetはでモジュールを検索します /usr/share/puppet/development/modules directory。
環境の有無にかかわらずPuppetを実行すると、デフォルトでsite.ppファイルと、メイン構成セクションのマニフェストおよびモジュールパス値で指定されたディレクトリになります。
事前環境を構成するのに実際に意味のある構成はごくわずかであり、これらのパラメーターはすべて、クライアントの構成をコンパイルするために使用するファイルの指定を中心に展開されます。
以下はパラメータです。
Modulepath− Puppetでは、基本的な標準モードとして、すべての環境が共有する標準モジュールディレクトリを用意し、次にカスタムモジュールを保存できる環境前ディレクトリを用意するのが最適です。モジュールパスは、Puppetが環境に関連するすべての構成ファイルを検索する場所です。
Templatedir−テンプレートディレクトリは、関連するテンプレートのすべてのバージョンが保存される場所です。モジュールはこれらの設定よりも優先される必要がありますが、各環境で特定のテンプレートの異なるバージョンを持つことができます。
Manifest −これは、エントリポイントスクリプトとして使用する構成を定義します。
複数のモジュールを備えたPuppetsは、構成のモジュール性を実現するのに役立ちます。Puppetで複数の環境を使用できます。これは、モジュールに大きく依存している場合にはるかにうまく機能します。モジュールに変更をカプセル化することで、変更を環境に移行するのが簡単になります。ファイルサーバーは環境固有のモジュールパスを使用します。個別にマウントされたディレクトリではなく、モジュールからファイルを提供する場合、この環境は環境固有のファイルを取得でき、最終的に現在の環境はマニフェストファイル内の$ environment変数でも利用できるようになります。
クライアント環境の設定
環境構成に関連するすべての構成は、puppet.confファイルで行われます。Puppetクライアントが使用する環境を指定するには、クライアントのpuppet.confファイルで環境構成変数の値を指定できます。
[puppetd]
environment = Testing構成ファイルの上記の定義は、構成ファイルがテストしている場合の環境を定義します。
-を使用してコマンドラインでこれを指定することもできます。
#puppetd -–environment = testingあるいは、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上記のスクリプトでは、ブロック「Puppet::Type.newtype(:repo) do"これはrepoという名前の新しいタイプを作成します。次に、追加したい詳細レベルを追加するのに役立つ@docがあります。次のステートメントはEnsurableです。これは、基本的なensureプロパティを作成します。Puppetタイプは ensure 構成アイテムの状態を判別するためのプロパティー。
例
service { "sshd":
ensure => present,
}sureステートメントは、Puppetに、create、destroy、およびプロバイダーに存在するという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を定義しました。
最後に、コードでpathと呼ばれるもう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として定義しました。これは、これがrepoと呼ばれるタイプのプロバイダーであることをPuppetに通知します。
次に、追加しました descこれにより、プロバイダーにドキュメントを追加できます。このプロバイダーが使用するコマンドも定義しました。次の行では、作成、削除、存在などのリソースの機能を確認しています。
リソースの作成
上記のすべてが完了したら、次のコードに示すように、クラスとマニフェストファイルで使用されるリソースを作成します。
repo { "wp":
source => "http://g01063908.git.brcl.org/trunk/",
path => "/var/www/wp",
ensure => present,
}Puppetは、PuppetマスターとPuppetエージェントの両方の間の通信チャネルとしてRESTfulAPIを使用します。以下は、このRESTfulAPIにアクセスするための基本的なURLです。
https://brcleprod001:8140/{environment}/{resource}/{key}
https://brcleprod001:8139/{environment}/{resource}/{key}RESTAPIセキュリティ
Puppetは通常、セキュリティとSSL証明書の管理を担当します。ただし、クラスターの外部でRESTful APIを使用する場合は、マシンに接続するときに、証明書を自分で管理する必要があります。Puppetのセキュリティポリシーは、残りのauthconfigファイルを介して構成できます。
RESTAPIのテスト
Curlユーティリティは、RESTfulAPI接続を停止するための基本的なユーティリティとして使用できます。以下は、REST APIcurlコマンドを使用してノードのカタログを取得する方法の例です。
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上記のコマンドでは、戻したいフォーマットを指定するヘッダーと、カタログを生成するためのRESTfulURLを送信するだけです。 brcleprod001 実稼働環境では、次の出力が生成されます。
--- &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-----
MIICHTCCAYagAwIBAgIBATANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDDAxwdXBwPuppetマスターとエージェントの共有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/brcleprod002Puppet MasterAPIリファレンス
認証されたリソース（有効な署名付き証明書が必要です）。
カタログ
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ノード-特定のノードに関する事実
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/puppetclientPuppet AgentAPIリファレンス
新しいエージェントがいずれかのマシンにセットアップされると、デフォルトでは、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}Run −クライアントをパペットターンやパペットキックのように更新します。
PUT /{environment}/run/{node certificate name}
curl -k -X PUT -H "Content-Type: text/pson" -d "{}"
https://brcleprod002:8139/production/run/{anything}Puppetノードで構成とマニフェストを適用するライブテストを実行するために、ライブ作業デモを使用します。これを直接コピーして貼り付け、構成がどのように機能するかをテストできます。ユーザーが同じコードセットを使用する場合は、次のコードスニペットに示されているのと同じ命名規則を使用する必要があります。
新しいモジュールの作成から始めましょう。
新しいモジュールの作成
httpd構成をテストして適用する最初のステップは、モジュールを作成することです。これを行うには、ユーザーは自分の作業ディレクトリをPuppetモジュールディレクトリに変更し、基本的なモジュール構造を作成する必要があります。構造の作成は、手動で行うことも、Puppetを使用してモジュールのボイラープレートを作成することによって行うこともできます。
# cd /etc/puppet/modules
# puppet module generate Live-moduleNote − Puppet module generateコマンドでは、Puppet forgeの仕様に準拠するために、module-nameが[username]-[module]の形式である必要があります。
新しいモジュールには、マニフェストディレクトリを含むいくつかの基本的なファイルが含まれています。ディレクトリには、モジュールのメインマニフェストファイルであるinit.ppという名前のマニフェストがすでに含まれています。これは、モジュールの空のクラス宣言です。
class live-module {
}モジュールには、と呼ばれるマニフェストを含むテストディレクトリも含まれています init.pp。このテストマニフェストには、manifest /init.pp内のライブモジュールクラスへの参照が含まれています。
include live-modulePuppetは、このテストモジュールを使用してマニフェストをテストします。これで、構成をモジュールに追加する準備が整いました。
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パッケージのパッケージリソース宣言を定義します。保証=>インストール済み属性は、必要なパッケージがインストールされているかどうかを確認します。インストールされていない場合、Puppetはyumユーティリティを使用してインストールします。次に、このサブクラスをメインのマニフェストファイルに含めます。init.ppマニフェストを編集する必要があります。
class test-module {
include test-module::httpd
}さて、次のように実行できるモジュールをテストする時が来ました
# puppet apply test-module/tests/init.pp --nooppuppet applyコマンドは、ターゲットシステムのマニフェストファイルに存在する構成を適用します。ここでは、メインのinit.ppを参照するtestinit.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ハイライト行は、ensure =>インストール済み属性の結果です。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 => 実行ステータスは、サービスが実行されているかどうかを確認し、実行されていない場合は有効にします。
ザ・ 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 secondshttpdサーバーの構成
上記の手順が完了すると、HTTPサーバーがインストールされて有効になります。次のステップは、サーバーにいくつかの構成を提供することです。デフォルトでは、httpdは/etc/httpd/conf/httpd.confにいくつかのデフォルト構成を提供します。これはウェブホストポート80を提供します。ウェブホストにいくつかのユーザー固有の機能を提供するためにいくつかのホストを追加します。
テンプレートは可変入力を必要とするため、追加のポートを提供するために使用されます。templateというディレクトリを作成し、新しいdirectorに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があります。これは、system fact。
システムファクトは、それぞれのシステムのパペットカタログを生成する前に、各システムから収集されます。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番目のファイルリソース宣言が追加されます。
次に、を使用して構成ファイルとhttpsサービスの関係を追加します。 notify => Service["httpd"]attribute。これにより、構成ファイルに変更があるかどうかがチェックされます。存在する場合、Puppetはサービスを再開します。
次に、メインマニフェストファイルにhttpd_portを含めます。このためには、メインのinit.ppマニフェストファイルを終了し、次のコンテンツを含める必要があります。
class test-module (
$http_port = 80
) {
include test-module::httpd
}これにより、httpdポートがデフォルト値の80に設定されます。次に、Puppetapplyコマンドを実行します。
以下が出力になります。
# 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の場合、Linux6バージョンを構成するために必要なすべての構成コマンドを実行します。
OSバージョンが7の場合、ファイアウォールの構成に必要なすべてのコマンドを実行します。
両方のOSのコードスニペットには、httpパッケージがインストールされた後にのみ構成が実行されるようにするロジックが含まれています。
最後に、Puppetapplyコマンドを実行します。
# 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 eventsSELinuxの設定
バージョン7以降のLinuxマシンで作業しているため、http通信を行うように構成する必要があります。SELinuxは、デフォルトでHTTPサーバーへの非標準アクセスを制限します。カスタムポートを定義する場合は、そのポートへのアクセスを提供するようにSELinuxを構成する必要があります。
Puppetには、ブール値やモジュールなど、SELinux関数を管理するためのリソースタイプがいくつか含まれています。ここでは、semanageコマンドを実行してポート設定を管理する必要があります。このツールはpolicycoreutils-pythonパッケージの一部であり、デフォルトではRedHatサーバーにインストールされていません。上記を実現するには、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はサービス要求を実行し、サービス要求は失敗します。
最後に、Puppetapplyコマンドを実行します
# 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ページをサーバーにコピーします。
filesディレクトリ内にindex.htmlファイルを作成します。
<html>
<head>
<title>Congratulations</title>
<head>
<body>
<h1>Congratulations</h1>
<p>Your puppet module has correctly applied your configuration.</p>
</body>
</html>マニフェストディレクトリ内にマニフェストapp.ppを作成し、次のコンテンツを追加します。
class test-module::app {
file { "/var/www/test-server/index.html":
ensure => file,
mode => 755,
owner => root,
group => root,
source => "puppet:///modules/test-module/index.html",
require => Class["test-module::httpd"],
}
}この新しいクラスには、単一のリソース減速が含まれています。これにより、モジュールのファイルディレクトリからWebサーバーにファイルがコピーされ、そのアクセス許可が設定されます。必要な属性により、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/index.html]/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強調表示された行は、index.htmlファイルがWebホストにコピーされた結果を示しています。
モジュールの完成
上記のすべての手順で、作成した新しいモジュールを使用する準備が整いました。モジュールのアーカイブを作成する場合は、次のコマンドを使用して作成できます。
# puppet module build test-module