[.note]#Note:このチュートリアルの新しいバージョンは、Puppet with Passengerの代わりにPuppetサーバーを使用しており、How To Install Puppet 4 in a Master-Agent Setup on Ubuntu 14.04。
#にあります。
前書き
Puppet LabsのPuppetは、システム管理者がサーバーインフラストラクチャのプロビジョニング、構成、および管理を自動化するのに役立つ構成管理ツールです。 事前に計画し、Puppetなどの構成管理ツールを使用すると、基本的なタスクの繰り返しに費やす時間を削減でき、インフラストラクチャ全体で構成の一貫性と正確性を確保できます。 Puppetやその他の自動化ツールを使用してサーバーを管理すると、時間を節約でき、全体的なセットアップの他の側面の改善に費やすことができます。
Puppetには、Puppet EnterpriseとオープンソースPuppetの2種類があります。 ほとんどのLinuxディストリビューション、さまざまなUNIXプラットフォーム、およびWindowsで実行されます。
このチュートリアルでは、オープンソースのPuppetをAgent / Masterセットアップにインストールする方法について説明します。 このセットアップは、すべての構成データが管理および配布される中央のPuppet Masterサーバーで構成され、残りのすべてのサーバーは、パペットマスターサーバーで構成できるPuppet Agentノードになります。
前提条件
このチュートリアルを実行するには、Puppetを設定するすべてのサーバーへのルートアクセスが必要です。 また、Puppetマスターサーバーとして機能する新しいUbuntu 14.04 VPSを作成する必要があります。 既存のインフラストラクチャがない場合は、前提条件のDNSセットアップチュートリアルに従って、サンプルインフラストラクチャ(後述)を自由に再作成してください。
Puppetのインストールを開始する前に、次の前提条件を満たしていることを確認してください。
-
Private Network DNS:順方向および逆方向DNSを構成する必要があり、すべてのサーバーに一意のホスト名が必要です。 これがconfigure your own private network DNS serverのチュートリアルです。 DNSが構成されていない場合は、名前解決に
hosts
ファイルを使用する必要があります。 インフラストラクチャ内の通信にプライベートネットワークを使用すると想定します。 -
Firewall Open Ports:Puppetマスターはポート8140で到達可能である必要があります。 ファイアウォールの制限が厳しすぎる場合は、このUFW Tutorialをチェックして、ポート8140での着信要求を許可する方法を確認してください。
インフラストラクチャの例
次のインフラストラクチャを使用して、Puppetのセットアップ方法を示します。
ホスト名 | Role | プライベートFQDN |
---|---|---|
host1 |
汎用Ubuntu14.04 VPS |
host1.nyc2.example.com |
host2 |
汎用Ubuntu14.04 VPS |
host2.nyc2.example.com |
ns1 |
プライマリネームサーバー |
ns1.nyc2.example.com |
ns2 |
セカンダリネームサーバー |
ns2.nyc2.example.com |
これらのすべてのホストにpuppetエージェントがインストールされます。 これらのホストは、プライベートネットワークインターフェイスによって参照され、DNSの「.nyc2.example.com」サブドメインにマップされます。 これは、前提条件のチュートリアルで説明されているものと同じインフラストラクチャです:How To Configure BIND as a Private Network DNS Server on Ubuntu 14.04
。
すべての前提条件が揃ったら、Puppetマスターサーバーの作成に進みましょう!
Puppet Master Serverを作成する
ホスト名として「puppet」を使用して、新しいUbuntu 14.04 x64VPSを作成します。 次の詳細を使用して、プライベートネットワークをDNSに追加します。
ホスト名 | Role | プライベートFQDN |
---|---|---|
人形 |
パペットマスター |
puppet.nyc2.example.com |
DNSを設定したばかりで、ホストをDNSに追加する方法がわからない場合は、DNSチュートリアルのMaintaining DNS Recordsセクションを参照してください。 基本的に、「A」および「PTR」レコードを追加し、新しいホストが再帰クエリを実行できるようにする必要があります。 また、サーバーが短いホスト名を使用して相互に検索できるように、検索ドメインを構成してください。
Puppetマスターのホスト名として「puppet」を使用すると、エージェントへの接続を試みる際にエージェントが使用するデフォルトの名前であるため、エージェントのセットアップが若干簡素化されます。
次に、NTPをセットアップする必要があります。
NTPをインストールする
puppetマスターサーバーはエージェントノードの認証局として機能するため、エージェント証明書を発行する際に潜在的な問題を回避するために正確なシステム時間を維持する必要があります。 この目的のためにNetwork Time Protocol(NTP)を使用します。
まず、ntpdate
コマンドを使用して1回限りの同期を実行します。
sudo ntpdate pool.ntp.org
システム時刻は更新されますが、NTPデーモンをインストールして時刻を自動的に更新し、時間のずれを最小限に抑える必要があります。 次のaptコマンドを使用してインストールします。
sudo apt-get update && sudo apt-get -y install ntp
NTPサーバーに地理的に近い「プールゾーン」を使用するようにNTP構成を更新するのが一般的な方法です。 Webブラウザーで、NTP Pool Projectに移動し、使用しているデータセンターに地理的に近いpool zoneを検索します。 サーバーはニューヨークのデータセンターにあるため、この例では米国のプール(http://www.pool.ntp.org/zone/us)を使用します。
編集のためにntp.conf
を開きます。
sudo vi /etc/ntp.conf
NTP Pool Projectページからファイルの先頭にタイムサーバーを追加します。
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
保存して終了。 NTPを再起動して、新しいタイムサーバーを追加します。
sudo service ntp restart
サーバーが正確な時間を保持しているので、Puppetマスターソフトウェアをインストールしましょう。
Puppet Masterをインストールする
オープンソースのPuppetをインストールするには、さまざまな方法があります。 Puppet Labsが提供するpuppetmaster-passengerというdebianパッケージを使用します。 puppetmaster-passengerパッケージには、Puppetマスターと本番環境に対応したWebサーバー(Passenger with Apache)が含まれているため、基本的なpuppetmasterパッケージを使用する場合に比べていくつかの構成手順が不要です。
Puppet Labsパッケージをダウンロードします。
cd ~; wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
パッケージをインストールしてください。
sudo dpkg -i puppetlabs-release-trusty.deb
aptの利用可能なパッケージのリストを更新します。
sudo apt-get update
puppetmaster-passenger
パッケージをインストールします。
sudo apt-get install puppetmaster-passenger
Puppet master、Passenger、Apache、およびその他の必要なパッケージがインストールされました。 PassengerとApacheを使用しているため、PuppetマスタープロセスはApacheによって制御されます。 Apacheの実行中に実行されます。
続行する前に、apache2
サービスを停止してPuppetマスターを停止します。
sudo service apache2 stop
次に、Puppetのバージョンをロックします。
バージョンをロックする
バージョンごとに変更すると、Puppet環境が正常に動作しなくなる場合があります。 このため、インフラストラクチャ全体で一貫したPuppetバージョンを維持する必要があります。 新しいバージョンにアップグレードする場合は、エージェントノードの前に必ずmasterをアップグレードしてください。マスターは、バージョン番号が大きいエージェントを管理できないためです。
次のコマンドを使用して、Puppetインストールのバージョンを検索します。
puppet help | tail -n 1
書き込み中、前のコマンドからの出力はPuppet v3.6.2
です。 aptのピン機能を使用してPuppetのインストールを3.6.*
にロックできます。これにより、aptがPuppetをより高いメジャーリリースにアップグレードできなくなります。 aptプリファレンスディレクトリで呼び出される新しいファイルを作成します。
sudo vi /etc/apt/preferences.d/00-puppet.pref
次の行を追加して、puppet
、puppet-common
、およびpuppetmaster-passenger
パッケージを3.6.*
にロックします(インストールされているバージョンに一致するようにこれを変更します)。
# /etc/apt/preferences.d/00-puppet.pref
Package: puppet puppet-common puppetmaster-passenger
Pin: version 3.6*
Pin-Priority: 501
保存して終了。 Puppetバージョンがロックされました。
次のステップは、Puppetマスター名と証明書をセットアップすることです。
名前と証明書を設定する
PuppetはSSL証明書を使用して、マスターノードとエージェントノード間の通信を認証します。 Puppetマスターは認証局(CA)として機能し、エージェント証明書要求に署名するために使用される独自の証明書を生成する必要があります。 マスターの証明書をセットアップします。
既存の証明書を削除する
パッケージのインストール中に作成された既存のSSL証明書を削除します。 PuppetのSSL証明書のデフォルトの場所は/var/lib/puppet/ssl
です。
sudo rm -rf /var/lib/puppet/ssl
証明書を構成する
パペットマスターの証明書を作成するとき、エージェントノードがマスターに接続できるすべてのDNS名を含めます。 この例の場合、短いホスト名とFQDNである「puppet」と「puppet.nyc2.example.com」をそれぞれ使用します。
マスターのpuppet.confファイルを編集します。
sudo vi /etc/puppet/puppet.conf
それは次のようになります。
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
[master]
# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
templatedir
オプションは非推奨であるため、この行を削除してください。
[main]
セクションの最後に次の2行を追加します(強調表示されたテキストをプライベートFQDNに置き換えます)。
certname = puppet
dns_alt_names = puppet,puppet.nyc2.example.com
Apache / Passenger構成では証明書の名前が「puppet」であることが想定されているため、assigncertname
を「puppet」に使用することが重要です。 別のcertname
設定が必要な場合は、必ずApache構成ファイル(/etc/apache2/sites-available/puppetmaster.conf
)を編集して、SSL証明書パスの名前を変更してください。
保存して終了。
新しい証明書を生成する
次のコマンドを実行して、新しいCA証明書を作成します。
sudo puppet master --verbose --no-daemonize
SSLキーと証明書が作成されていることを示す出力が数行表示されます。 Notice: Starting Puppet master version 3.6.2
が表示されたら、証明書のセットアップは完了です。 CTRL-C
を押してシェルに戻ります。
出力例:
Info: Creating a new SSL key for ca
Info: Creating a new SSL certificate request for ca
Info: Certificate Request fingerprint (SHA256): EC:7D:ED:15:DE:E3:F1:49:1A:1B:9C:D8:04:F5:46:EF:B4:33:91:91:B6:5D:19:AC:21:D6:40:46:4A:50:5A:29
Notice: Signed certificate request for ca
...
Notice: Signed certificate request for puppet
Notice: Removing file Puppet::SSL::CertificateRequest puppet at '/var/lib/puppet/ssl/ca/requests/puppet.pem'
Notice: Removing file Puppet::SSL::CertificateRequest puppet at '/var/lib/puppet/ssl/certificate_requests/puppet.pem'
Notice: Starting Puppet master version 3.6.2
作成されたばかりの証明書の証明書情報を確認するには、次のように入力します。
sudo puppet cert list -all
上記のコマンドは、実際にすべての署名済み証明書と未署名の証明書要求をリストします。 現在、他の証明書がまだ追加されていないため、マスター証明書のみが表示されます。
+ "puppet" (SHA256) 05:22:F7:65:64:CF:46:0E:09:2C:5D:FD:8C:AC:9B:31:17:2B:7B:05:93:D5:D1:01:52:72:E6:DF:84:A0:07:37 (alt names: "DNS:puppet", "DNS:puppet.nyc2.example.com")
Puppetマスターサービスを開始する準備がほぼ整いました。 最初にマスター構成を見てみましょう。
Puppet Masterを構成する
メインのPuppet構成ファイルpuppet.conf
は、[main]
、[master]
、および[agent]
の3つのセクションで構成されています。 ご想像のとおり、「メイン」セクションにはグローバル構成が含まれ、「マスター」セクションはパペットマスターに固有であり、「エージェント」はパペットエージェントの構成に使用されます。 前に行った変更は別として、デフォルトは基本的なセットアップでは正常に機能します。
構成ファイルには、独自のセットアップに関連する可能性のある多くのオプションがあります。 ファイルの完全な説明は、Puppet Labs:Main Config File (puppet.conf)で入手できます。
編集する場合は、次のコマンドを実行します。
sudo vi /etc/puppet/puppet.conf
メインのマニフェストファイルを見てみましょう。
メインマニフェストファイル
Puppetはドメイン固有言語を使用してシステム構成を記述し、これらの記述は「マニフェスト」と呼ばれるファイルに保存されます。このファイルの拡張子は.pp
です。 デフォルトのメインマニフェストファイルは/etc/puppet/manifests/site.pp
にあります。 いくつかの基本的なマニフェストについては後で説明しますが、ここではプレースホルダーファイルを作成します。
sudo touch /etc/puppet/manifests/site.pp
Puppet Masterを起動します
これで、Puppetマスターを起動する準備が整いました。 apache2
サービスを実行して開始します。
sudo service apache2 start
Puppetマスターは実行されていますが、まだエージェントノードを管理していません。 Puppetエージェントをインストールして追加する方法を学びましょう!
Puppet Agentをインストールする
Puppetマスターが管理するサーバーにPuppetエージェントをインストールする必要があります。 ほとんどの場合、これにはインフラストラクチャ内のすべてのサーバーが含まれます。 概要で説明したように、Puppetエージェントはすべての主要なLinuxディストリビューション、一部のUNIXプラットフォーム、およびWindowsで実行できます。 インストールは各OSでわずかに異なるため、UbuntuおよびDebianサーバーでのインストールのみを扱います。
他のプラットフォームにPuppetをインストールする手順は、Puppet Labs Docsにあります。選択したOSの「エージェントノードへのPuppetのインストール」セクションに必ず従ってください。
Note:エージェントノードを含むすべてのPuppetノードがDNSを使用するように構成されていると想定されています。 新しいサーバーを作成する場合は、Puppetエージェントをインストールする前に必ずadd it to your DNSにしてください。
Ubuntu / Debianエージェントノード
Note:サンプルエージェントノード、host1、host2、ns1、およびns2はすべて、Ubuntu 14.04VPSです。 サーバーごとにこの手順を繰り返すため、各サーバーはPuppetマスターによって管理できます。
Puppetエージェントノードで、Puppet Labsパッケージをダウンロードします。
cd ~; wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
パッケージをインストールしてください。
sudo dpkg -i puppetlabs-release-trusty.deb
aptの利用可能なパッケージのリストを更新します。
sudo apt-get update
Puppetエージェントパッケージ(puppet
)をインストールします。
sudo apt-get install puppet
パペットエージェントはデフォルトで無効になっています。 これを変更するには、デフォルトファイルを更新します。
sudo vi /etc/default/puppet
そして、START
の値を「yes」に変更します。
START=yes
/etc/default/puppet
を保存して終了します。
バージョンをロックする
Puppetマスターと同様に、aptピン機能を使用して、Puppetエージェントのバージョンをロックします。
sudo vi /etc/apt/preferences.d/00-puppet.pref
次の行を追加して、puppet
およびpuppet-common
パッケージを3.6.*
にロックします(インストールされているバージョンに一致するようにこれを変更します)。
# /etc/apt/preferences.d/00-puppet.pref
Package: puppet puppet-common
Pin: version 3.6*
Pin-Priority: 501
保存して終了。 Puppetバージョンがロックされました。
エージェントを構成する
エージェントを実行する前に、いくつかの構成変更を行う必要があります。
エージェントのpuppet.conf
を編集します。
sudo vi /etc/puppet/puppet.conf
Puppetマスターの初期設定ファイルとまったく同じように見えます。
ここでも、templatedir
行を削除します。 次に、[master]
セクションとその下のすべての行を削除します。
Puppetマスターが「人形」で到達可能であると仮定すると、エージェントはマスターに接続できるはずです。 マスターが「puppet」で利用できない場合、PuppetマスターのFQDNを追加する必要があります。 関係なく、これを構成することをお勧めします(FQDNを独自のものに置き換えます)。
[agent]
server = puppet.nyc2.example.com
保存して終了。
Puppetエージェントを実行する準備ができました。 これを行うには、次のコマンドを実行します。
sudo service puppet start
すべてが正しく構成されている場合、出力は表示されません。 Puppetエージェントを初めて実行すると、SSL証明書が生成され、署名要求がPuppetマスターに送信されます。 Puppetマスターがエージェントの証明書に署名すると、エージェントノードと通信できるようになります。
Note:これが最初のPuppetエージェントである場合は、他のエージェントを追加する前に、Puppetマスターで証明書に署名することをお勧めします。 すべてが正しく機能することを確認したら、戻って自信を持って残りのエージェントノードを追加できます。
マスターに署名要求
エージェントノードで初めてPuppetを実行すると、証明書署名要求がPuppetマスターに送信されます。 マスターは、エージェントノードと通信して制御できるようになる前に、その特定のエージェントノードの証明書に署名する必要があります。 署名方法および署名リクエストの確認方法について説明します。
現在の証明書要求を一覧表示する
Puppetマスターで、次のコマンドを実行して、すべての未署名の証明書要求を一覧表示します。
sudo puppet cert list
最初のエージェントノードをセットアップしたばかりの場合、1つのリクエストが表示されます。 ホスト名としてエージェントノードのFQDNを使用して、次のようになります。
"host1.nyc2.example.com" (SHA256) B1:96:ED:1F:F7:1E:40:53:C1:D4:1B:3C:75:F4:7C:0B:A9:4C:1B:5D:95:2B:79:C0:08:DD:2B:F4:4A:36:EE:E3
その前に+
がないことに注意してください。 これは、まだ署名されていないことを示しています。
リクエストに署名する
証明書要求に署名するには、署名する証明書のホスト名を指定して、puppet cert sign
コマンドを使用します。 たとえば、host1.nyc2.example.com
に署名するには、次のコマンドを使用します。
sudo puppet cert sign host1.nyc2.example.com
次の出力が表示されます。これは、証明書要求が署名されたことを示しています。
Notice: Signed certificate request for host1.nyc2.example.com
Notice: Removing file Puppet::SSL::CertificateRequest host1.nyc2.example.com at '/var/lib/puppet/ssl/ca/requests/host1.nyc2.example.com.pem'
Puppetマスターは、署名された証明書が属するノードと通信および制御できるようになりました。
現在のすべてのリクエストに署名する場合は、次のように-all
オプションを使用します。
sudo puppet cert sign --all
証明書を取り消す
Puppetからホストを削除するか、ホストを再構築してからPuppetに追加し直すことができます。 この場合、Puppetマスターからホストの証明書を失効させる必要があります。 これを行うには、clean
アクションを使用する必要があります。
sudo puppet cert clean hostname
指定されたホストの関連証明書はPuppetから削除されます。
すべての署名済みリクエストを表示
署名付きおよび署名なしのすべてのリクエストを表示するには、次のコマンドを実行します。
sudo puppet cert list --all
すべてのリクエストのリストが表示されます。 署名された要求の前には` and unsigned requests do not have the `
が付きます。
"ns2.nyc2.example.com" (SHA256) E4:F5:26:EB:B1:99:1F:9D:6C:B5:4B:BF:86:14:40:23:E0:50:3F:C1:45:D0:B5:F0:68:6E:B2:0F:41:C7:BA:76
+ "host1.nyc2.example.com" (SHA256) 71:A2:D3:82:15:0D:80:20:D4:7E:E3:42:C2:35:87:83:79:2B:57:1D:D5:5A:EC:F6:8B:EE:51:69:53:EB:6B:A1
+ "host2.nyc2.example.com" (SHA256) F4:79:A6:7C:27:0C:EA:8E:BC:31:66:FF:F2:01:AB:B1:35:7B:9F:5E:C8:C9:CE:82:EE:E8:2F:23:9F:0C:2B:ED
+ "puppet" (SHA256) 05:22:F7:65:64:CF:46:0E:09:2C:5D:FD:8C:AC:9B:31:17:2B:7B:05:93:D5:D1:01:52:72:E6:DF:84:A0:07:37 (alt names: "DNS:puppet", "DNS:puppet.nyc2.example.com")
おめでとうございます。 これで、Puppetでインフラストラクチャを管理する準備が整いました!
Puppetの使用開始
インフラストラクチャがPuppetで管理されるように設定されたので、開始するためのいくつかの基本的なタスクを実行する方法を示します。
事実の収集方法
Puppetは、facterというツールを使用して、各ノードに関する事実を収集します。 デフォルトでは、Facterはシステム構成に役立つ情報を収集します(例: OS名、ホスト名、IPアドレス、SSHキーなど)。 構成を実行するために他のファクトが必要な場合は、カスタムファクトを追加できます。
収集された事実は、多くの状況で役立ちます。 たとえば、Webサーバー構成テンプレートを作成し、特定の仮想ホストに適切なIPアドレスを自動的に入力できます。 または、サーバーのOSが「Ubuntu」であると判断できるため、httpd
ではなくapache2
サービスを実行する必要があります。 これらは基本的な例ですが、事実をどのように使用できるかについてのアイデアを提供する必要があります。
エージェントノードで自動的に収集されているファクトのリストを表示するには、次のコマンドを実行します。
facter
メインマニフェストの実行方法
パペットエージェントは定期的にパペットマスターにチェックインします(通常は30分ごと)。 この間に、それ自体に関する事実をマスターに送信し、現在のカタログ(メインマニフェストによって決定されたエージェントに関連するリソースとその望ましい状態のコンパイル済みリスト)を取得します。 次に、エージェントノードは適切な変更を加えて、目的の状態を達成しようとします。 このサイクルは、Puppetマスターが実行され、エージェントノードと通信している限り続きます。
特定のエージェントノードでの即時実行
次のコマンドを(問題のエージェントノードで)実行することにより、特定のエージェントノードのチェックを手動で開始することもできます。
puppet agent --test
これを実行すると、テストを実行しているエージェントにメインマニフェストが適用されます。 次のような出力が表示される場合があります。
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Caching catalog for host1.nyc2.example.com
Info: Applying configuration version '1407966707'
このコマンドは、メインマニフェストが単一サーバーにどのように影響するかをすぐに確認するのに役立ちます。
一回限りのマニフェスト
puppet apply
コマンドを使用すると、メインマニフェストに関連しないマニフェストをオンデマンドで実行できます。 マニフェストは、適用元のノードからのみ適用されます。 これが一例です。
sudo puppet apply /etc/puppet/modules/test/init.pp
この方法でマニフェストを実行することは、エージェントノードで新しいマニフェストをテストする場合、またはマニフェストを1回だけ実行する場合に便利です(例: エージェントノードを目的の状態に初期化する)。
シンプルなマニフェスト
ご存知かもしれませんが、Puppetマスターのメインマニフェストファイルは/etc/puppet/manifests/site.pp
にあります。
masterで、今すぐ編集します。
sudo vi /etc/puppet/manifests/site.pp
次に、ファイルリソースを説明する次の行を追加します。
file {'/tmp/example-ip': # resource type file and filename
ensure => present, # make sure it exists
mode => 0644, # file permissions
content => "Here is my Public IP Address: ${ipaddress_eth0}.\n", # note the ipaddress_eth0 fact
}
ここで保存して終了します。 インラインコメントは、定義しているリソースを説明するものでなければなりません。 平易な英語では、これにより、すべてのエージェントノードが/tmp/example-ip
にファイルを持ち、-rw-r--r--
権限と、ノードのパブリックIPアドレスを含むテキストを持つensureが作成されます。
エージェントがマスターに自動的にチェックインするまで待つか、(エージェントノードの1つから)puppet agent --test
コマンドを実行することができます。 次に、次のコマンドを実行してファイルを印刷します。
cat /tmp/example-ip
次のような出力が表示されるはずです(そのノードのIPアドレスを使用)。
Here is my Public IP Address: 128.131.192.11.
ノードを指定する
特定のノードのリソースを定義する場合は、マニフェストでnode
を定義します。
マスターで、site.pp
を編集します。
sudo vi /etc/puppet/manifests/site.pp
次の行を追加します。
node 'ns1', 'ns2' { # applies to ns1 and ns2 nodes
file {'/tmp/dns': # resource type file and filename
ensure => present, # make sure it exists
mode => 0644,
content => "Only DNS servers get this file.\n",
}
}
node default {} # applies to nodes that aren't explicitly defined
保存して終了。
これで、Puppetは、/tmp/dns
のファイルがns1とns2に存在することを確認します。 スケジュールされたPuppetエージェントのプルを待ちたくない場合は、(ns1またはns2から)puppet agent --test
コマンドを実行することをお勧めします。
リソースを定義しない場合、Puppetはリソースに触れないように最善を尽くします。 したがって、これらのリソースをマニフェストから削除した場合、Puppetは作成したファイルを削除しません。 ファイルを削除する場合は、ensure
をabsent
に変更します。
これらの例は何の役にも立ちませんが、Puppetが適切に機能していることを証明しています。
モジュールを使用する
それでは、モジュールを使用しましょう。 モジュールは、タスクをグループ化するのに役立ちます。 Puppetコミュニティーには多くのモジュールが用意されており、独自のモジュールを作成することもできます。
Puppetマスターで、forgeapiからpuppetlabs-apache
モジュールをインストールします。
sudo puppet module install puppetlabs-apache
Warning:既存のApacheセットアップでこのモジュールを使用しないでください。 Puppetによって管理されていないApache構成はすべて削除されます。
次に、site.pp
を編集します。
sudo vi /etc/puppet/manifest/site.pp
次に、次の行を追加して、host2にApacheをインストールします。
node 'host2' {
class { 'apache': } # use apache module
apache::vhost { 'example.com': # define vhost resource
port => '80',
docroot => '/var/www/html'
}
}
保存して終了。 次回Puppetがhost2を更新するときに、Apacheパッケージをインストールし、「example.com」と呼ばれる仮想ホストを構成し、ポート80でリッスンし、ドキュメントルート/var/www/html
を使用します。
host2で、次のコマンドを実行します。
sudo puppet agent --test
Apacheがインストールされていることを示す大量の出力が表示されます。 完了したら、host2のパブリックIPアドレスに移動します。 デフォルトのApacheウェルカムページが表示されます。
おめでとうございます。 最初のPuppetモジュールを使用しました!
結論
基本的なエージェント/マスターPuppetのインストールが完了したので、Puppetを使用してサーバーインフラストラクチャを管理する方法についてさらに学習する準備が整いました。 次のチュートリアルを確認してください:Getting Started With Puppet Code: Manifests and Modules。