Puppet
Linuxのシステム管理ツール。
多数のLinuxを管理者の定義した管理ポリシー(manifest)に従わせることができ、
まさに操り人形。
ファイルの配布、サービスの起動/停止、パッケージのインスト、等々を集中管理。
Cfengineの後継と目されていて、柔軟なmanifestの定義が魅力。
Rubyで作られている。
最新は0.24系。
リンク
書籍
ダウンロード
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (-76_AA240_SH20_OU01_.jpg)
注意点
- RedHat EL5.2標準でインストールされるruby-1.8.5はメモリリークするらしい。
ruby-1.8.6以上を使うのが良いらしい。
- 0.24.7でpuppetrunを実行すると"Failed to load ruby LDAP library."のエラーになる。
最新版で修正されているかは未確認。
サーバー側のインストールと設定
環境はRedHat EL5.2 Server(x86)のCDから構築した。
EPELより以下をDLしてyumでインストールした。
- puppet-server-0.24.7-4.el5.noarch.rpm
- puppet-0.24.7-4.el5.noarch.rpm
- facter-1.5.2-2.el5.noarch.rpm
- ruby-augeas-0.2.0-1.el5.i386.rpm
- ruby-shadow-1.4.1-7.el5.i386.rpm
- augeas-libs-0.3.6-2.el5.i386.rpm
インストール後、/etc/puppet/puppet.confに以下の記述を追加。
[puppetmasterd]
autosign = true
ちなみに、puppetmasterd --genconfig するとパラメータを全部見せてくれる。
その後、
% touch /etc/puppet/manifests/site.pp →空のマニフェストを作成
% chkconfig puppetmaster on
% service puppetmaster start
としてpuppetmasterdを常駐起動する。puppetmasterdはpuppetユーザーで起動される。
サーバー側のファイルサーバー設定
puppetでファイルを配布させることができる。
例えば、/root/puppetfiles/ディレクトリを配布ファイルの置き場所とする。
/etc/puppet/fileserver.confを以下のように設定すると、
[files]
path = /root/puppetfiles
allow = *.test.com
puppet://puppet-server/files/ で /root/puppetfiles/ がアクセスできるようになる。
クライアント側のインストールと設定
環境はRedHat EL5.2 Client(x86)のCDから構築した。
EPELより以下をDLしてyumでインストールした。
- puppet-0.24.7-4.el5.noarch.rpm
- facter-1.5.2-2.el5.noarch.rpm
- ruby-augeas-0.2.0-1.el5.i386.rpm
- ruby-shadow-1.4.1-7.el5.i386.rpm
- augeas-libs-0.3.6-2.el5.i386.rpm
インストール後、/etc/puppet/puppet.confの[puppetd]セクションに以下の記述を追加。
[puppetd]
...
server = puppet-server.test.com
runinterval = 1800
ちなみに、puppetd --genconfig するとパラメータを全部見せてくれる。
その後、
% chkconfig puppet on
% service puppet start
でpuppetdを常駐起動させる。puppetdはrootユーザーで起動される。
すると、puppetdはpuppetmasterdに証明書(CA)のサインを要求しにいく。
サーバー側のpuppetmasterdはautosign設定になっているのでクライアントの証明書にサインする。
以後、puppetdは30分に1回(runinterval=1800)、puppetmasterdにマニフェストをリクエストし、自分のコンピュータ内でマニフェストと異なっている所をチェックして補正するようになる。
マニフェストの例
実例を交えてマニフェストの設定例。
File
/root以下に例えばreadme.txtファイルを配布しておきたい、という場合。
file { "/root/readme.txt":
owner => "root",
group => "root",
mode => 440,
source => "puppet://puppet-server/files/root/readme.txt",
}
ユーザーが配布されたreadme.txtを書き換えたり、削除したりしても、puppetが復活させてくれる。
Service
dhcpサービスは勝手に立ち上げられてると困るので止めさせたい、という場合。
service { "dhcpd":
name => "dhcpd",
enable => false,
ensure => false,
}
ユーザーがservice dhcpd startしたら停止させられるし、
chkconfig dhcpd onしたらoffにさせられる。
Package
必ずインストールしておいて欲しいパッケージ(仮にパッケージ名はxyzとする)がある場合。
package { "xyz":
name => "xyz",
ensure => installed,
}
但し、yumで参照できるレポジトリにxyzのrpmが存在すること。
逆に削除したい場合、ensure => absent とする。
アップデータしたい場合、ensure => latest とする。
FileとServiceとPackageの組み合わせ
- xyzパッケージを必ずインストールさせたい
- xyzパッケージはサービスとして動くので必ずサービス起動させておきたい
- xyzサービスの設定ファイル/etc/xyz/xyz.confは同じものを皆に配布したい
- /etc/xyz/xyz.confを変更したらサービスを再起動させたい
package { "xyz":
name => "xyz",
ensure => installed,
}
file { "/etc/xyz/xyz.conf":
owner => "root",
group => "root",
mode => 600,
source => "puppet://puppet-server/files/etc/xyz/xyz.conf",
notify => Service["xyz"],
require => Package["xyz"]
}
service { "xyz":
name => "xyz",
enable => true,
ensure => true,
require => File["/etc/xyz/xyz.conf"]
} puppetrun
クライアントからpuppetdがマニフェストを定期的にリクエストするPULL型がpuppetの通常の使われ方である。
一方、サーバーからマニフェストの実行を強制するPUSH型も可能である。
PUSH型のためのコマンドがpuppetrunである。
以下はPUSH型にするためのクライアント側の設定例。
puppet-server.test.comがpuppetmasterdが動作するサーバーとする。
/etc/puppet/namespaceauth.conf
[puppetrunner]
allow puppet-server.test.com
/etc/puppet/puppet.conf
[puppetd]
...
listen = true
これで、クライアント側のpuppetdはサーバー側からのpuppetrunコマンドを受け付けるようになる。
PUSH型だけでPULL型を行わないようにしたい場合、/etc/sysconfig/puppetを編集して、
PUPPET_EXTRA_OPTS=--no-client
とする。
本当はこの設定も/etc/puppet/puppet.confの[puppetd]セクションに書きたい所だが。。。
設定後、クライアント側のpuppetdを再起動し、サーバー側から、
% puppetrun --host client001.test.com
と実行するとクライアント側がマニフェストを取りに行くのが分かる。
ちなみに--allオプション、--classオプションはLDAPでノード管理していないと使えない。
最終更新：2009年02月28日 10:43
