Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Puppetのススメ
Similar to Puppetのススメ (20)
More from Gosuke Miyashita
More from Gosuke Miyashita (20)
Recently uploaded
Recently uploaded (9)
Puppetのススメ
- 1. Puppetのススメ hbstudy#8 (株)paperboy&co. 宮下 剛輔 2010/02/23
- 2. 自己紹介 宮下 剛輔 mizzy, id:MIZZY gosukenator(twitter, gmail) http://mizzy.org/ ペパボで技術責任者というのをやってます インフラからウェブ開発まで広く見てます 子だくさん 2009/11/24に4人目が生まれました
- 3. 自己紹介 最近はまってること WiiFitPlusで筋トレ ホームベーカリーでパンを焼く アサシンクリード2 シーケンス13プレイ中 ホットドクターペッパー牛乳
- 4. Puppetのススメ
- 5. アジェンダ Puppetの概要 Puppetの動作概要 マニフェストの基礎 Puppetを動かしてみる Puppetの使いどころ Puppetを利用する上で知っておくべきこと Puppetの微妙なところ
- 6. Puppetの概要
- 7. 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】
- 8. Puppetとは？ Ruby製のシステム管理ツール でも、使う上ではRubyかどうかはあまり関係ない Facter（後述）の拡張時にはRubyの知識必要
- 9. システム管理ツール？ Puppetはサーバの状態を定義し、維持するためのツール 以下はPuppetの対象外 ハードウェアの設置 ネットワーク接続 OSインストール/初期設定 ネットワークの設定 Puppet自身のインストール
- 10. Puppetの対象範囲 OSインストール/ネットワーク設定/Puppetインストール後のフェーズがPuppetの対象範囲 パッケージインストール/設定 ユーザ追加 cron設定 パッケージアップデート などなど
- 11. なぜPuppetが必要か？ 手動作業に伴う問題 手作業は時間がかかる 手を動かしてる時間はもちろん 待ち時間も大幅に効率下げる要因 並行して別作業するのも大変 あるべき状態との乖離 正しい手順書があっても、作業漏れ、ミスなどが出る 手順書自体が間違ってたり、古かったりすることもある
- 12. なぜPuppetが必要か？ 他の自動化手法に伴う問題 カスタムスクリプトでの自動化 解読、メンテが大変 自由度が高すぎて、書く人のスキルの差によるばらつきが大きい HDDイメージ複製、PXEブート＋NFS、rsyncといった手法 複数OS、複数の役割を持つサーバが混在した環境では、一括管理が難しい サーバによって異なる部分をどう吸収するか？ Apache の ServerName、MySQLの server-id など
- 13. Puppet導入のメリット システム構築/アップデートの自動化 システムの状態を目に見える形で記録できる マニフェストと呼ばれる独自言語による記述 システムのあるべき状態と実際の状態の乖離を防ぐ マニフェストで状態を定義し、システムへ適用する マニフェストの独自言語は、スクリプト言語より自由度が低いが、その分属人的なスキルに依存しにくい OS、役割、設定の異なるサーバ群の集中管理ができる マニフェストはテキストファイルなので、バージョン管理ツールによるトラッキングが可能
- 16. Puppetの動作概要
- 17. Puppetのネットワーク構成 puppetサーバ (puppetmasterd) 実行結果レポート マニフェストの取得と実行 puppetクライアント (puppetd) puppetクライアント (puppetd) puppetクライアント (puppetd) プロトコルは XMLRPC over HTTPS
- 18. Puppet用語 マニフェスト システムのあるべき状態が記述されたファイル Puppetサーバで一括して維持管理する Puppetクライアントで取得し、システムに適用 リソース Puppetマニフェスト内で扱うオブジェクト ユーザ、ファイル、パッケージなど
- 19. Puppetの動作概要パターン1 puppetサーバ (puppetmasterd) ③ 適用結果をレポート ① マニフェストを取りに行く（デフォルトは30分に1回） puppetクライアント (puppetd) ② 取得したマニフェストを適用する
- 20. Puppetの動作概要パターン2 puppetサーバ (puppetmasterd) ④ 適用結果をレポート ② マニフェストを取りに行く ① サーバ上でpuppetrunを実行してpuppetdをキックする puppetクライアント (puppetd) ③ 取得したマニフェストを適用
- 21. マニフェストの基礎
- 22. リソースの定義 リソースタイプ リソースのタイトル リソースの属性 file { '/etc/hosts': owner => $default_owner, group => $default_group, mode => 644, source => 'puppet://server/module/hosts', } /etc/hosts を puppetサーバから取得し、オーナー、グループ、モードを適切に設定するためのリソース定義 これ全体が「リソース」
- 23. クラスでリソースをまとめる 「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 リソース クラスをノードに適用
- 24. クラスを継承する 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 リソースの属性を上書き
- 25. リソースの依存関係 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
- 26. Puppetを動かしてみる
- 27. インストール 詳細は略。gihyo.jp 見てください。（といっても、古いのでそのまま利用できないかもですが。） ちなみに、CenｔOSだとEPELリポジトリに割と新しめのパッケージがあります。 依存するパッケージもそれほど多くありません。（augeas-libs, facter, ruby, ruby-augeas, ruby-libs, ruby-shadow）
- 28. デフォルトの設定ファイルを削除 基本的に、設定は最低限必要なところだけすれば良いので、デフォルトの設定ファイル群は消してしまうのが吉 自分がタッチしてない余分なファイルがあると、その挙動に悩むこともあるし というわけで、インストールしたらおもむろに rm –rf /etc/puppet/* してしまう
- 29. マニフェストを書く 簡単なマニフェストを書いてみる まずはディレクトリ作成 # mkdir /etc/puppet/manifets
- 30. マニフェストを書く /etc/puppet/manifests/site.pp file{ '/etc/passwd': owner => 'root', group => 'root', mode => 644, }
- 31. マニフェストを適用（スタンドアロン版） # puppet /etc/puppet/manifests/site.pp notice: //File[/etc/passwd]/mode: mode changed '777' to '644'
- 32. マニフェスト適用（クライアント/サーバ版） サーバ起動 # /usr/sbin/puppetmasterd --verbose br /> --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
- 33. マニフェストを適用（クライアント/サーバ版） クライアントで適用 # /usr/sbin/puppetd --server puppet.hoge.com br />--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
- 34. 以上 簡単ですよね？ サーバとクライアントが別の場合は、証明書の署名が手順に入ります /etc/puppet/autosign.confを設定すれば、署名手順は自動化できます 実運用では、デーモンとして常駐させたり、puppetrunでクライアントをキックしたりします
- 35. Puppetの使いどころ
- 36. Puppetの使いどころ 大量にサーバがある 異なるOSや環境のサーバが混在 台数少なくても、同じような手順を何度も実行する可能性がある 開発環境、検証環境等の、ベースになる部分 自分以外の人も同じ手順を実行するかもしれない システムの状態を何らかの形で記録しておきたい、バージョン管理したい インクリメンタル/テスト駆動サーバ構築
- 37. バージョン管理ツールによるトラッキング なぜこんな設定してるんだろう？という瞬間ありませんか？ こんな時でも、バージョン管理ツールで誰がどんな意図で設定、あるいは修正したのかが記録されていると安心です デプロイツールと組み合わせて、サーバのアップデートもできます（ペパボではArcherつかってます） ただし、適切なバージョン管理ツールの利用が必要です。特にコメントをしっかり残す、という習慣が大事 システム管理者にバージョン管理ツールを根付かせるのは難しい？
- 38. インクリメンタル/テスト駆動サーバ構築 テスト環境では、Puppetマニフェストを少しづつ書き足し、修正、テストしながら、構築すべき内容を詰めていく Puppet化しておくと、一からつくりなおすのも簡単 マニフェストは、テスト環境、本番環境どちらでも使えるように作成。環境の違いはFacter変数などで吸収 本番環境では、テスト環境で作り上げたマニフェストを適用するだけ テスト環境できっちりテストしておけば、本番でも大丈夫と自信が持てる
- 40. Puppetのコンセプトに馴染む マニフェストでは、リソースとリソース間の関係を記述する 静的な状態を記述する Puppetでどうシステムを管理するか、を考える場合、リソースとリソースの関係にブレイクダウンすること システム上で何を実行するのか、ではなく、どういう状態にするのか、を考える
- 41. リソースとその関係へのブレイクダウン 例えばApacheの場合、以下のようなリソースへとブレイクダウンし、各リソースとその関係を記述する パッケージ サービス 設定ファイル群 バーチャルホスト Apacheモジュール
- 42. Apacheマニフェスト package { ‘httpd’: ensure => installed } service { ‘httpd’: enable => true, ensure => running, require => Package[‘httpd’], }
- 43. 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’]; }
- 44. Apacheマニフェスト（つづき） defineapache_module() { .... } apache_module { ‘rewrite’: config => “puppet://$server/rewrite.conf”, }
- 45. Apacheマニフェスト（つづき） definevirtual_host() { ... } virtual_host { ‘www.example.jp’: docroot => ‘/var/www/html’ , }
- 46. マニフェストは宣言型言語 マニフェストは設定ではなく、言語である 手続型言語ではなく宣言型言語 「何を実行するか」ではなく最終的な「状態」を定義する 通常のシステム管理タスクは手続型なので、発想の転換が必要
- 47. 手続型と宣言型 手続型 OpenSSHをインストールする 設定ファイルを修正する サービスを起動する 宣言型 OpenSSHがインストールされた状態にする 設定ファイルの内容を決められた通りにする サービスが起動した状態とする
- 48. 手続型と宣言型 同じことをしているように見えるが、実は異なる 手続型はプロセスを記述する 同じことを何度も繰り返すと、違った状態になることがあり得る 宣言型は最終的な状態を記述する マニフェストを何度適用しても、最終的な状態は同じ
- 49. defined type defineは関数/機能を定義しているように見えるけど、実際はリソースタイプを定義しているので注意 definevirtual_host() { ... } virtual_host { ‘www.example.jp’: docroot => ‘/var/www/html’ , }
- 51. 以上はPuppetBest Practices 3.0から http://plathrop.tertiusfamily.net/puppet/best-practice-draft.html
- 52. モジュールの活用 モジュールは、よく利用するマニフェストを汎用的に利用できるようにまとめたもの よくある処理や、複雑な処理はモジュールとしてまとめるとすっきり でも、本当に汎用的なモジュールを作成するのは難しい…コピペになりがち モジュールをうまく共有する仕組みがないのもイマイチ でも、できるだけ早い段階から活用した方がいい 汎用的とか共有とか考慮しなくても、メンテナンス性は向上する
- 53. 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"]; }
- 54. iptablesモジュールでやってること iptablesパッケージのインストール 必要なファイルの配布 全サーバ共通ルールファイル rebuild用スクリプト ルールファイルをがっちゃんこして /etc/sysconfig/iptables に書き込む サーバ個別ルールファイルの配布 ルールファイルが変更された場合にrebuildスクリプト実行
- 55. モジュール公開してるところ http://reductivelabs.com/trac/puppet/wiki/PuppetModules 外部へのリンクもあり http://github.com/n0ts/puppet
- 56. エラー通知 Puppetにはエラーだけ通知する仕組みがない？ tagmailは特定のクラスに関するログの通知先アドレスを指定できるが、エラーのみ通知、ということができない という話をクックパッドテックライフLTで話したけど、実は0.24.6からは、tagでログレベルも指定できるようになってたことに気づいた /etc/puppet/tagmail.conf err: error@example.jp
- 57. syslogでエラー通知を分離 puppet.conf [puppetd] syslogfacility = local0 syslog.conf local0.err br />/var/log/puppet/error.log
- 58. ノード情報の管理 シンプルなやりかたは、ノード情報をマニフェストに記述する node‘www.hoge.com’ { include‘base’ include‘www’ }
- 60. External Nodeの設定例 /etc/puppet/puppet.confでの設定 [puppetmasterd] external_nodes = br /> /usr/bin/cobbler-ext-nodes node_terminus = exec
- 61. cobbler-ext-nodesの実行結果 $ cobbler-ext-nodes web-proxy.example.jp classes: [base, web-proxy] parameters: {from_cobbler: 1}
- 62. Cobblerでノード情報管理 最近はCobblerを利用しているので、こいつのノード情報をマスターとしてます cobbler-ext-nodesコマンドが付属してるので、Puppetと即連携可 Cobblerはdnsmasqと連携できるので、DNS/DHCPのノード情報としても利用できる
- 63. LDAPによるノード情報管理 puppetrun –all とか –class オプションの利用には、LDAPでノード情報を管理する必要がある でも、あまりお勧めしない。めんどうだけどあまりメリットない。 puppetrun –all や –class 相当のことがしたければ、スクリプト組むのがよい
- 64. execは最小限に Puppetマニフェストは基本的に、最終的な「状態」を定義するもの なので、何度適用しても、最終的な状態は同じになる ただしexecリソースは例外で、何を実行するかを定義する 副作用のあるコマンドを実行すると、何度実行しても同じ結果になるという保証がないので危険 execを濫用するとマニフェストのメンテもしづらくなる Puppetの考え方に馴染んでない人は、何でもexecで実行してしまおうとするので注意
- 65. execを濫用したマニフェスト exec { 'sysctl add': command => 'echo "net.ipv4.netfilter.ip_conntrack_max = 131072" >> /etc/sysctl.conf br /> && /sbin/sysctl -p', onlyif => "test -f /etc/sysctl.conf", unless => "grep 'net.ipv4.netfilter.ip_conntrack_max' /etc/sysctl.conf 2>/dev/null" }
- 66. execを適切に利用したマニフェスト file {'/etc/sysctl.conf': ensure => present, source => "puppet://$server/sysctl.conf", } exec { '/sbin/sysctl -p': subscribe => File['/etc/sysctl.conf'], refreshonly=> true, }
- 67. Facterの活用 FacterというライブラリをPuppetは利用している システムに関する情報（プロセッサアーキテクチャ，利用OSとそのバージョン，ドメイン名，FQDN，IPアドレスなど）を収集するための，クロスプラットフォームなRubyライブラリ FacterによってFacter変数が定義される
- 68. 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 ...
- 69. Facter変数を利用したマニフェスト例 $ntp_package= $operatingsystem? { freebsd => 'openntpd', default => 'ntp', } package { $ntp_package: ensure => present }
- 70. カスタムFact Facter.add(:serverid) do setcodedo /+$/.match(Facter.hostname) end end
- 71. カスタムFactを利用したテンプレート /etc/my.cnfのテンプレ [mysqld] server-id=<%= serverid %>
- 73. Puppetの微妙なところ
- 74. 変数のスコープとオーバーライド この関係がわかりづらく、仕様がいまいち 意図通りのオーバーライドができない 柔軟なオーバーライドができない
- 75. 想定通りに動かない例 classbase_class { $myvar = 'bob' file {"/tmp/testvar": content => "$myvar", } } classchild_classinheritsbase_class { $myvar= 'fred' }
- 76. 想定通りにするには $myvar= ‘bob‘ classbase_class { file {"/tmp/testvar": content => "$myvar", } } classchild_class { $myvar= 'fred‘ includebase_class } ただし、$myvarがグローバルになる
- 77. 想定通りにするには（別パターン） classbase_class { $myvar = 'bob' file {"/tmp/testvar": content => "$myvar", } } classchild_classinheritsbase_class { $myvar= 'fred‘ File[‘/tmp/testvar’]{ content => "$myvar“ } } ただし、記述が冗長
- 79. 理想的な例 classfile { $var= ‘hoge’ file { ‘/tmp/file’: content => $var } } classfile_fugainherits file { $var= ‘fuga’ }
- 80. もうひとつの理想的な例 継承ではなく委譲 classfile { $var= ‘hoge’ file { ‘/tmp/file’: content => $var} } classfile_fuga { file.new( var => ‘fuga’ ).apply }
- 81. 理想的な例（ノードの場合） ノード定義でもこんな風にできればいいのに node‘www.example.com’ { file.new( var => ‘fuga’ ).apply }
- 82. 変数オーバーライドとモジュール モジュールも結局はクラスなので、同じ問題が起こる 汎用的なモジュールつくるのが難しい一因 無理やり実現する方法はあるけど、ちょっと面倒
- 83. モジュールでの変数オーバーライド 詳しくはPuppetBestPractices? at Cookpadの資料参照 node"sample1.example.com"{ classapache_config inheritsapache_defaults { $ssl = false } includeapache }
- 85. 柔軟性とメンテナンス性のバランス 以上のような感じで、マニフェスト言語については柔軟性不足な感がある そもそも、クラスはリソースのコレクションでしかない 柔軟性が低いのは、誰が書いても同じになりやすく、メンテしやすい、というメリットはある バランスが難しい
- 86. 内部DSL実装 マニフェストは外部DSL 内部DSL実装も実はある Ruby DSL http://reductivelabs.com/trac/puppet/wiki/RubyDSL あまり使われてないって書いてある ShadowPuppet http://reductivelabs.com/trac/puppet/wiki/ShadowPuppet
- 87. 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
- 88. 変数オーバーライド以外のモジュールに関する問題 CPAN的な仕組みがない。PRM(Puppet Recipe Manager)というのがあったけど、現在はウェブサイトは残ってるが、ソースが見当たらない PRMのウェブサイトから辿れなかったけど、 http://people.redhat.com/~alikins/prm/にはあった 1年ほど更新されてない
- 89. クラス設計が難しい これも言語の柔軟性が低いゆえ？ 特に、リソースの重複が悩ましい 複数クラスにまたがるリソースの定義が難しい 仮想リソースという仕組みはあるが、これはこれで面倒ではある でも、柔軟性が増すと別の悩みが出てきそう
- 90. ドキュメントが読みづらくなった 例えば TypeReference 現行ページ http://docs.reductivelabs.com/references/stable/type.html 旧ページ http://reductivelabs.com/trac/puppet/wiki/TypeReference.
- 91. 現行ページ
- 92. 旧ページ
- 93. リソースタイプに微妙なものが リソースタイプには、file, user, group, package, service, cron といったものがある 上の例は、割りとOSに普遍的なものだけど、中にはnagios_command, nagios_contact, nagios_hostといった、Nagios固有のものがある。（Nagios固有のタイプで14もあり、リファレンスの中でも目立ってる） アプリケーション固有のものは、コアに入れないでモジュールにした方がいいのでは？
- 94. パッケージ利用がほぼ必須 Puppetを利用する場合は、RPMなどパッケージ利用がほぼ必須 execでmakeは各サーバにコンパイラとかいれないといけないし、時間もかかる Puppetでファイル配布できるけど、大量にファイルがあるとかなり遅い rsyncをPuppetで実行するのも、微妙な感じ でもパッケージングめんどくさい とは言っても、パッケージングのメリットもある ソースRPMつかってれば、異なるディストリビューション/アーキテクチャでもパッケージリビルドするだけでOK
- 98. サーバ間の依存関係が記述できない リソース間の依存関係は記述できる このサービスデーモンはこの設定ファイルに依存する、など サーバ間の依存関係は記述できない このサーバは、データベースサーバがセットアップされてからマニフェストを適用する、といったことができない
- 99. パッケージ削除が微妙 パッケージの追加は、依存関係勝手に解決してくれる（これはPuppetではなく、利用しているパッケージプロバイダ依存） パッケージ削除は解決してくれない RedHat系の場合、追加はyumコマンドでやるけど、削除はrpmコマンドでやってるっぽい 他のパッケージシステムは不明 余計なパッケージを最初から入れないのが吉
- 100. とはいうものの 色々微妙な点を挙げてみたけど、Puppet以上にシンプルで使いやすいものはなさそう というわけで、当分はPuppet使い続けることになりそう だけどChefの今後の動きにも要注目 内部DSLなので言語の自由度は高そう
- 102. ご清聴ありがとうございました