Puppetのススメ

Puppetのススメ
hbstudy#8
(株)paperboy&co. 宮下剛輔
2010/02/23

自己紹介
宮下剛輔
mizzy, id:MIZZY
gosukenator(twitter, gmail)
http://mizzy.org/
ペパボで技術責任者というのをやってます
インフラからウェブ開発まで広く見てます
子だくさん
2009/11/24に4人目が生まれました

自己紹介
最近はまってること
WiiFitPlusで筋トレ
ホームベーカリーでパンを焼く
アサシンクリード2 シーケンス13プレイ中
ホットドクターペッパー牛乳

Puppetのススメ

アジェンダ
Puppetの概要
Puppetの動作概要
マニフェストの基礎
Puppetを動かしてみる
Puppetの使いどころ
Puppetを利用する上で知っておくべきこと
Puppetの微妙なところ

Puppetの概要

Puppet情報リソース
http://reductivelabs.com/products/puppet/
http://gihyo.jp/admin/serial/01/puppet
http://trac.mizzy.org/puppet
Software Design 2007年12月号
Software Design 総集編【2000~2009】

Puppetとは？
Ruby製のシステム管理ツール
でも、使う上ではRubyかどうかはあまり関係ない
Facter（後述）の拡張時にはRubyの知識必要

システム管理ツール？
Puppetはサーバの状態を定義し、維持するためのツール
以下はPuppetの対象外
ハードウェアの設置
ネットワーク接続
OSインストール/初期設定
ネットワークの設定
Puppet自身のインストール

Puppetの対象範囲
OSインストール/ネットワーク設定/Puppetインストール後のフェーズがPuppetの対象範囲
パッケージインストール/設定
ユーザ追加
cron設定
パッケージアップデート
などなど

なぜPuppetが必要か？
手動作業に伴う問題
手作業は時間がかかる
手を動かしてる時間はもちろん
待ち時間も大幅に効率下げる要因
並行して別作業するのも大変
あるべき状態との乖離
正しい手順書があっても、作業漏れ、ミスなどが出る
手順書自体が間違ってたり、古かったりすることもある

なぜPuppetが必要か？
他の自動化手法に伴う問題
カスタムスクリプトでの自動化
解読、メンテが大変
自由度が高すぎて、書く人のスキルの差によるばらつきが大きい
HDDイメージ複製、PXEブート＋NFS、rsyncといった手法
複数OS、複数の役割を持つサーバが混在した環境では、一括管理が難しい
サーバによって異なる部分をどう吸収するか？
Apache の ServerName、MySQLの server-id など

Puppet導入のメリット
システム構築/アップデートの自動化
システムの状態を目に見える形で記録できる
マニフェストと呼ばれる独自言語による記述
システムのあるべき状態と実際の状態の乖離を防ぐ
マニフェストで状態を定義し、システムへ適用する
マニフェストの独自言語は、スクリプト言語より自由度が低いが、その分属人的なスキルに依存しにくい
OS、役割、設定の異なるサーバ群の集中管理ができる
マニフェストはテキストファイルなので、バージョン管理ツールによるトラッキングが可能

Puppetの動作概要

Puppetのネットワーク構成
puppetサーバ
(puppetmasterd)
実行結果レポート
マニフェストの取得と実行
puppetクライアント
(puppetd)
(puppetd)
(puppetd)
プロトコルは XMLRPC over HTTPS

Puppet用語
マニフェスト
システムのあるべき状態が記述されたファイル
Puppetサーバで一括して維持管理する
Puppetクライアントで取得し、システムに適用
リソース
Puppetマニフェスト内で扱うオブジェクト
ユーザ、ファイル、パッケージなど

Puppetの動作概要パターン1
puppetサーバ
(puppetmasterd)
③ 適用結果をレポート
① マニフェストを取りに行く（デフォルトは30分に1回）
(puppetd)
② 取得したマニフェストを適用する

Puppetの動作概要パターン2
puppetサーバ
(puppetmasterd)
④ 適用結果をレポート
② マニフェストを取りに行く
① サーバ上でpuppetrunを実行してpuppetdをキックする
(puppetd)
③ 取得したマニフェストを適用

マニフェストの基礎

リソースの定義
リソースタイプ
リソースのタイトル
リソースの属性
file { '/etc/hosts':
owner => $default_owner,
group => $default_group,
mode => 644,
source => 'puppet://server/module/hosts',
}
/etc/hosts を puppetサーバから取得し、オーナー、グループ、モードを適切に設定するためのリソース定義
これ全体が「リソース」

クラスでリソースをまとめる
「sudo」クラスを定義
class sudo{
package { ‘sudo’:
ensure => latest,
alias => sudo
}
file { ‘/etc/sudoers’:
source => 'puppet://server/module/sudoers',
mode => 440,
owner => $default_owner,
group => $default_group,
alias => sudoers
}
}
node ‘mail.hoge.com’ { include sudo }
package リソース
file リソース
クラスをノードに適用

クラスを継承する
base クラスを定義
class base {
file { "/my/file":
content => template("base.erb")
}
}
class sub inherits base { # override the content
File["/my/file"] {
content => template("other.erb")
}
}
base クラスを継承した sub クラスを定義
base クラスの /my/file リソースの属性を上書き

リソースの依存関係
file { '/etc/ssh':
source => puppet://server/module/ssh,
recurse => true,
notify => Service[ssh]
}
service { 'ssh':
name => sshd,
ensure => running,
subscribe => File[‘/etc/ssh’]
}
/etc/ssh以下のファイルに変更があれば、sshサービスリソースに再起動を促す
/etc/sshリソースに変更があれば、サービスを再起動する
notifyかsubscribeのどちらか一方だけ定義すればOK

Puppetを動かしてみる

インストール
詳細は略。gihyo.jp 見てください。（といっても、古いのでそのまま利用できないかもですが。）
ちなみに、CenｔOSだとEPELリポジトリに割と新しめのパッケージがあります。
依存するパッケージもそれほど多くありません。（augeas-libs, facter, ruby, ruby-augeas, ruby-libs, ruby-shadow）

デフォルトの設定ファイルを削除
基本的に、設定は最低限必要なところだけすれば良いので、デフォルトの設定ファイル群は消してしまうのが吉
自分がタッチしてない余分なファイルがあると、その挙動に悩むこともあるし
というわけで、インストールしたらおもむろに rm –rf /etc/puppet/* してしまう

マニフェストを書く
簡単なマニフェストを書いてみる
まずはディレクトリ作成
# mkdir /etc/puppet/manifets

マニフェストを書く
/etc/puppet/manifests/site.pp
file{ '/etc/passwd':
owner => 'root',
group => 'root',
mode => 644,
}

マニフェストを適用（スタンドアロン版）
# puppet /etc/puppet/manifests/site.pp
notice: //File[/etc/passwd]/mode: mode changed '777' to '644'

マニフェスト適用（クライアント/サーバ版）
サーバ起動
# /usr/sbin/puppetmasterd --verbose
--no-daemonize --nonodes
info: Starting server for Puppet version 0.24.8
info: Listening on port 8140
notice: Starting Puppet server version 0.24.8

マニフェストを適用（クライアント/サーバ版）
クライアントで適用
# /usr/sbin/puppetd --server puppet.hoge.com
--no-daemonize --verbose --onetime
info: No classes to store
info: Caching catalog at /var/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //File[/etc/passwd]/mode: mode changed '777' to '644'
notice: Finished catalog run in 0.03 seconds

以上
簡単ですよね？
サーバとクライアントが別の場合は、証明書の署名が手順に入ります
/etc/puppet/autosign.confを設定すれば、署名手順は自動化できます
実運用では、デーモンとして常駐させたり、puppetrunでクライアントをキックしたりします

大量にサーバがある
異なるOSや環境のサーバが混在
台数少なくても、同じような手順を何度も実行する可能性がある
開発環境、検証環境等の、ベースになる部分
自分以外の人も同じ手順を実行するかもしれない
システムの状態を何らかの形で記録しておきたい、バージョン管理したい
インクリメンタル/テスト駆動サーバ構築

バージョン管理ツールによるトラッキング
なぜこんな設定してるんだろう？という瞬間ありませんか？
こんな時でも、バージョン管理ツールで誰がどんな意図で設定、あるいは修正したのかが記録されていると安心です
デプロイツールと組み合わせて、サーバのアップデートもできます（ペパボではArcherつかってます）
ただし、適切なバージョン管理ツールの利用が必要です。特にコメントをしっかり残す、という習慣が大事
システム管理者にバージョン管理ツールを根付かせるのは難しい？

インクリメンタル/テスト駆動サーバ構築
テスト環境では、Puppetマニフェストを少しづつ書き足し、修正、テストしながら、構築すべき内容を詰めていく
Puppet化しておくと、一からつくりなおすのも簡単
マニフェストは、テスト環境、本番環境どちらでも使えるように作成。環境の違いはFacter変数などで吸収
本番環境では、テスト環境で作り上げたマニフェストを適用するだけ
テスト環境できっちりテストしておけば、本番でも大丈夫と自信が持てる

Puppetを利用する上で知っておくべきこと

Puppetのコンセプトに馴染む
マニフェストでは、リソースとリソース間の関係を記述する
静的な状態を記述する
Puppetでどうシステムを管理するか、を考える場合、リソースとリソースの関係にブレイクダウンすること
システム上で何を実行するのか、ではなく、どういう状態にするのか、を考える

リソースとその関係へのブレイクダウン
例えばApacheの場合、以下のようなリソースへとブレイクダウンし、各リソースとその関係を記述する
パッケージ
サービス
設定ファイル群
バーチャルホスト
Apacheモジュール

Apacheマニフェスト
package { ‘httpd’: ensure => installed }
service { ‘httpd’:
enable => true,
ensure => running,
require => Package[‘httpd’],
}

Apacheマニフェスト（つづき）
file {
‘/etc/httpd/conf.d/hoge.conf’:
source => “puppet://$server/hoge.conf”,
notify => Service[‘httpd’];
‘/etc/httpd/conf.d/fuga.conf’:
source => “puppet://$server/fuga.conf”,
notify => Service[‘httpd’];
}

defineapache_module() {
....
}
apache_module { ‘rewrite’:
config => “puppet://$server/rewrite.conf”,
}

definevirtual_host() {
...
}
virtual_host { ‘www.example.jp’:
docroot => ‘/var/www/html’ ,
}

マニフェストは宣言型言語
マニフェストは設定ではなく、言語である
手続型言語ではなく宣言型言語
「何を実行するか」ではなく最終的な「状態」を定義する
通常のシステム管理タスクは手続型なので、発想の転換が必要

手続型と宣言型
手続型
OpenSSHをインストールする
設定ファイルを修正する
サービスを起動する
宣言型
OpenSSHがインストールされた状態にする
設定ファイルの内容を決められた通りにする
サービスが起動した状態とする

手続型と宣言型
同じことをしているように見えるが、実は異なる
手続型はプロセスを記述する
同じことを何度も繰り返すと、違った状態になることがあり得る
宣言型は最終的な状態を記述する
マニフェストを何度適用しても、最終的な状態は同じ

defined type
defineは関数/機能を定義しているように見えるけど、実際はリソースタイプを定義しているので注意
definevirtual_host() {
...
}
virtual_host { ‘www.example.jp’:
docroot => ‘/var/www/html’ ,
}

クラスと継承
マニフェストにはクラスと継承があるけど、オブジェクト指向言語として十分な機能を備えてるわけではない
クラスはあくまでもリソースのコレクションにすぎない

以上はPuppetBest Practices 3.0から
http://plathrop.tertiusfamily.net/puppet/best-practice-draft.html

モジュールの活用
モジュールは、よく利用するマニフェストを汎用的に利用できるようにまとめたもの
よくある処理や、複雑な処理はモジュールとしてまとめるとすっきり
でも、本当に汎用的なモジュールを作成するのは難しい…コピペになりがち
モジュールをうまく共有する仕組みがないのもイマイチ
でも、できるだけ早い段階から活用した方がいい
汎用的とか共有とか考慮しなくても、メンテナンス性は向上する

iptablesモジュールの利用例
include'iptables'
file {
'/etc/iptables.d/filter':
content => template('filter'),
notify => Exec["rebuild_iptables"];
'/etc/iptables.d/nat':
content => template('nat'),
notify => Exec["rebuild_iptables"];
}

iptablesモジュールでやってること
iptablesパッケージのインストール
必要なファイルの配布
全サーバ共通ルールファイル
rebuild用スクリプト
ルールファイルをがっちゃんこして /etc/sysconfig/iptables に書き込む
サーバ個別ルールファイルの配布
ルールファイルが変更された場合にrebuildスクリプト実行

モジュール公開してるところ
http://reductivelabs.com/trac/puppet/wiki/PuppetModules
外部へのリンクもあり
http://github.com/n0ts/puppet

エラー通知
Puppetにはエラーだけ通知する仕組みがない？
tagmailは特定のクラスに関するログの通知先アドレスを指定できるが、エラーのみ通知、ということができない
という話をクックパッドテックライフLTで話したけど、実は0.24.6からは、tagでログレベルも指定できるようになってたことに気づいた
/etc/puppet/tagmail.conf
err: error@example.jp

syslogでエラー通知を分離
puppet.conf
[puppetd]
syslogfacility = local0
syslog.conf
local0.err
/var/log/puppet/error.log

ノード情報の管理
シンプルなやりかたは、ノード情報をマニフェストに記述する
node‘www.hoge.com’ {
include‘base’
include‘www’
}

ノード情報の管理
ExternalNode機能を使えば、既存で持ってるノード情報を使いまわせる
具体的には、ノード名を与えると、既存のノード情報を変換してYAML形式で出力するようなスクリプトを用意して、puppetに設定する

External Nodeの設定例
/etc/puppet/puppet.confでの設定
[puppetmasterd]
external_nodes =
/usr/bin/cobbler-ext-nodes
node_terminus = exec

cobbler-ext-nodesの実行結果
$ cobbler-ext-nodes web-proxy.example.jp
classes: [base, web-proxy]
parameters: {from_cobbler: 1}

Cobblerでノード情報管理
最近はCobblerを利用しているので、こいつのノード情報をマスターとしてます
cobbler-ext-nodesコマンドが付属してるので、Puppetと即連携可
Cobblerはdnsmasqと連携できるので、DNS/DHCPのノード情報としても利用できる

LDAPによるノード情報管理
puppetrun –all とか –class オプションの利用には、LDAPでノード情報を管理する必要がある
でも、あまりお勧めしない。めんどうだけどあまりメリットない。
puppetrun –all や –class 相当のことがしたければ、スクリプト組むのがよい

execは最小限に
Puppetマニフェストは基本的に、最終的な「状態」を定義するもの
なので、何度適用しても、最終的な状態は同じになる
ただしexecリソースは例外で、何を実行するかを定義する
副作用のあるコマンドを実行すると、何度実行しても同じ結果になるという保証がないので危険
execを濫用するとマニフェストのメンテもしづらくなる
Puppetの考え方に馴染んでない人は、何でもexecで実行してしまおうとするので注意

execを濫用したマニフェスト
exec { 'sysctl add':
command => 'echo "net.ipv4.netfilter.ip_conntrack_max = 131072" >> /etc/sysctl.conf
&& /sbin/sysctl -p',
onlyif => "test -f /etc/sysctl.conf",
unless => "grep 'net.ipv4.netfilter.ip_conntrack_max' /etc/sysctl.conf 2>/dev/null"
}

execを適切に利用したマニフェスト
file {'/etc/sysctl.conf':
ensure => present,
source => "puppet://$server/sysctl.conf",
}
exec { '/sbin/sysctl -p':
subscribe => File['/etc/sysctl.conf'],
refreshonly=> true,
}

Facterの活用
FacterというライブラリをPuppetは利用している
システムに関する情報（プロセッサアーキテクチャ，利用OSとそのバージョン，ドメイン名，FQDN，IPアドレスなど）を収集するための，クロスプラットフォームなRubyライブラリ
FacterによってFacter変数が定義される

Facter変数
$ facter
architecture => x86_64
domain => hoge.com
facterversion => 1.5.7
fqdn => puppet.hoge.com
hardwareisa => x86_64
hardwaremodel => x86_64
hostname => h026
id => miya
interfaces => eth0,eth1,sit0
ipaddress => 192.168.10.26
ipaddress_eth0 => 192.168.10.26
ipaddress_eth1 => 192.168.122.106
is_virtual => false
...

Facter変数を利用したマニフェスト例
$ntp_package= $operatingsystem? {
freebsd => 'openntpd',
default => 'ntp',
}
package { $ntp_package: ensure => present }

カスタムFact
Facter.add(:serverid) do
setcodedo
/d+$/.match(Facter.hostname)
end
end

カスタムFactを利用したテンプレート
/etc/my.cnfのテンプレ
[mysqld]
server-id=<%= serverid %>

0.25.xの利用推奨
いろいろなところで正規表現使えるようになってるので、0.25.xの利用がお勧めです

Puppetの微妙なところ

変数のスコープとオーバーライド
この関係がわかりづらく、仕様がいまいち
意図通りのオーバーライドができない
柔軟なオーバーライドができない

想定通りに動かない例
classbase_class {
$myvar = 'bob'
file {"/tmp/testvar":
content => "$myvar",
}
}
classchild_classinheritsbase_class {
$myvar= 'fred'
}

想定通りにするには
$myvar= ‘bob‘
classbase_class {
}
}
classchild_class {
$myvar= 'fred‘
includebase_class
}
ただし、$myvarがグローバルになる

想定通りにするには（別パターン）
classbase_class {
$myvar = 'bob'
}
}
classchild_classinheritsbase_class {
$myvar= 'fred‘
File[‘/tmp/testvar’]{
content => "$myvar“
}
}
ただし、記述が冗長

といった感じで…
変数がグローバルになる、記述が冗長になるなど、いずれにしてもいまいち

理想的な例
classfile {
$var= ‘hoge’
file {
‘/tmp/file’: content => $var
}
}
classfile_fugainherits file {
$var= ‘fuga’
}

もうひとつの理想的な例
継承ではなく委譲
classfile {
$var= ‘hoge’
file { ‘/tmp/file’: content => $var}
}
classfile_fuga {
file.new( var => ‘fuga’ ).apply
}

理想的な例（ノードの場合）
ノード定義でもこんな風にできればいいのに
node‘www.example.com’ {
file.new( var => ‘fuga’ ).apply
}

変数オーバーライドとモジュール
モジュールも結局はクラスなので、同じ問題が起こる
汎用的なモジュールつくるのが難しい一因
無理やり実現する方法はあるけど、ちょっと面倒

モジュールでの変数オーバーライド
詳しくはPuppetBestPractices? at Cookpadの資料参照
node"sample1.example.com"{
classapache_config
inheritsapache_defaults {
$ssl = false
}
includeapache
}

External/LDAPNodeと変数オーバーライド
前ページのモジュール変数オーバーライド手法は、LDAPNodeやExternalNodeでは使えない
External/LDAPNodeではクラスのincludeとパラメータ設定ぐらいしかできない

柔軟性とメンテナンス性のバランス
以上のような感じで、マニフェスト言語については柔軟性不足な感がある
そもそも、クラスはリソースのコレクションでしかない
柔軟性が低いのは、誰が書いても同じになりやすく、メンテしやすい、というメリットはある
バランスが難しい

内部DSL実装
マニフェストは外部DSL
内部DSL実装も実はある
Ruby DSL
http://reductivelabs.com/trac/puppet/wiki/RubyDSL
あまり使われてないって書いてある
ShadowPuppet
http://reductivelabs.com/trac/puppet/wiki/ShadowPuppet

ShadowPuppet
class ManifestExample< ShadowShadow::Manifest
recipe :sample
recipe :mysql, {
:root_password=> 'OMGSEKRET'
}
defsample
exec :foo, :command => '/bin/echo "foo" > /tmp/foo.txt'
package :foo, :ensure => :installed
file '/tmp/example.txt', :ensure => :present, :contents => Facter.to_hash_inspect
end
def mysql(options)
...
end
end

変数オーバーライド以外のモジュールに関する問題
CPAN的な仕組みがない。PRM(Puppet Recipe Manager)というのがあったけど、現在はウェブサイトは残ってるが、ソースが見当たらない
PRMのウェブサイトから辿れなかったけど、 http://people.redhat.com/~alikins/prm/にはあった
1年ほど更新されてない

クラス設計が難しい
これも言語の柔軟性が低いゆえ？
特に、リソースの重複が悩ましい
複数クラスにまたがるリソースの定義が難しい
仮想リソースという仕組みはあるが、これはこれで面倒ではある
でも、柔軟性が増すと別の悩みが出てきそう

ドキュメントが読みづらくなった
例えば TypeReference
現行ページ http://docs.reductivelabs.com/references/stable/type.html
旧ページ http://reductivelabs.com/trac/puppet/wiki/TypeReference.

現行ページ

旧ページ

リソースタイプに微妙なものが
リソースタイプには、file, user, group, package, service, cron といったものがある
上の例は、割りとOSに普遍的なものだけど、中にはnagios_command, nagios_contact, nagios_hostといった、Nagios固有のものがある。（Nagios固有のタイプで14もあり、リファレンスの中でも目立ってる）
アプリケーション固有のものは、コアに入れないでモジュールにした方がいいのでは？

パッケージ利用がほぼ必須
Puppetを利用する場合は、RPMなどパッケージ利用がほぼ必須
execでmakeは各サーバにコンパイラとかいれないといけないし、時間もかかる
Puppetでファイル配布できるけど、大量にファイルがあるとかなり遅い
rsyncをPuppetで実行するのも、微妙な感じ
でもパッケージングめんどくさい
とは言っても、パッケージングのメリットもある
ソースRPMつかってれば、異なるディストリビューション/アーキテクチャでもパッケージリビルドするだけでOK

--noopのdiffが読みづらい
puppetdに—noopオプションをつけると、ファイルリの内容が変更された場合、実際にファイルは書き変えないけど、diff出力してくれる
だけど、ノーマルな形式のdiffで、ユニファイド形式じゃないので、読みづらい

ロールバックできない
「トランザクショナルレイヤー」というのがドキュメントを見るとあるんだけど、ロールバックはできない

puppetrunの微妙なところ
LDAPNodeつかわないと、--allや--classが使えない

サーバ間の依存関係が記述できない
リソース間の依存関係は記述できる
このサービスデーモンはこの設定ファイルに依存する、など
サーバ間の依存関係は記述できない
このサーバは、データベースサーバがセットアップされてからマニフェストを適用する、といったことができない

パッケージ削除が微妙
パッケージの追加は、依存関係勝手に解決してくれる（これはPuppetではなく、利用しているパッケージプロバイダ依存）
パッケージ削除は解決してくれない
RedHat系の場合、追加はyumコマンドでやるけど、削除はrpmコマンドでやってるっぽい
他のパッケージシステムは不明
余計なパッケージを最初から入れないのが吉

とはいうものの
色々微妙な点を挙げてみたけど、Puppet以上にシンプルで使いやすいものはなさそう
というわけで、当分はPuppet使い続けることになりそう
だけどChefの今後の動きにも要注目
内部DSLなので言語の自由度は高そう

結論
微妙なところもあるけど、現存するこの手のツールの中ではベストだと思う
なのでみんなPuppet使ってみよう

ご清聴ありがとうございました

http://d.hatena.ne.jp	685
http://coderwall.com	92
http://www.slideshare.net	59
http://www.techgig.com	11
http://webcache.googleusercontent.com	7
https://twitter.com	4
http://s.deeeki.com	3
https://si0.twimg.com	2
http://b.hatena.ne.jp	1
http://a0.twimg.com	1

Puppetのススメ

by Gosuke Miyashita

Accessibility

Categories

Upload Details

Usage Rights

10 Embeds 865

Statistics

Puppetのススメ Presentation Transcript