Puppetのススメ
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Puppetのススメ

on

  • 21,967 views

 

Statistics

Views

Total Views
21,967
Views on SlideShare
20,692
Embed Views
1,275

Actions

Likes
30
Downloads
184
Comments
1

13 Embeds 1,275

http://d.hatena.ne.jp 778
http://0.0.0.0 196
http://pascal.plustar.jp 106
http://coderwall.com 92
http://www.slideshare.net 59
http://www.techgig.com 18
http://s.deeeki.com 9
http://webcache.googleusercontent.com 7
https://twitter.com 4
https://si0.twimg.com 2
http://192.168.33.10 2
http://a0.twimg.com 1
http://b.hatena.ne.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Puppetのススメ Presentation Transcript

  • 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、役割、設定の異なるサーバ群の集中管理ができる
    マニフェストはテキストファイルなので、バージョン管理ツールによるトラッキングが可能
  • 14.
  • 15.
  • 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 見てください。(といっても、古いのでそのまま利用できないかもですが。)
    ちなみに、CentOSだと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
    --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
    --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変数などで吸収
    本番環境では、テスト環境で作り上げたマニフェストを適用するだけ
    テスト環境できっちりテストしておけば、本番でも大丈夫と自信が持てる
  • 39. Puppetを利用する上で知っておくべきこと
  • 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’ ,
    }
  • 50. クラスと継承
    マニフェストにはクラスと継承があるけど、オブジェクト指向言語として十分な機能を備えてるわけではない
    クラスはあくまでもリソースのコレクションにすぎない
  • 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
    /var/log/puppet/error.log
  • 58. ノード情報の管理
    シンプルなやりかたは、ノード情報をマニフェストに記述する
    node‘www.hoge.com’ {
    include‘base’
    include‘www’
    }
  • 59. ノード情報の管理
    ExternalNode機能を使えば、既存で持ってるノード情報を使いまわせる
    具体的には、ノード名を与えると、既存のノード情報を変換してYAML形式で出力するようなスクリプトを用意して、puppetに設定する
  • 60. External Nodeの設定例
    /etc/puppet/puppet.confでの設定
    [puppetmasterd]
    external_nodes =
    /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
    && /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
    /d+$/.match(Facter.hostname)
    end
    end
  • 71. カスタムFactを利用したテンプレート
    /etc/my.cnfのテンプレ
    [mysqld]
    server-id=<%= serverid %>
  • 72. 0.25.xの利用推奨
    いろいろなところで正規表現使えるようになってるので、0.25.xの利用がお勧めです
  • 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“
    }
    }
    ただし、記述が冗長
  • 78. といった感じで…
    変数がグローバルになる、記述が冗長になるなど、いずれにしてもいまいち
  • 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
    }
  • 84. External/LDAPNodeと変数オーバーライド
    前ページのモジュール変数オーバーライド手法は、LDAPNodeやExternalNodeでは使えない
    External/LDAPNodeではクラスのincludeとパラメータ設定ぐらいしかできない
  • 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
  • 95. --noopのdiffが読みづらい
    puppetdに—noopオプションをつけると、ファイルリの内容が変更された場合、実際にファイルは書き変えないけど、diff出力してくれる
    だけど、ノーマルな形式のdiffで、ユニファイド形式じゃないので、読みづらい
  • 96. ロールバックできない
    「トランザクショナルレイヤー」というのがドキュメントを見るとあるんだけど、ロールバックはできない
  • 97. puppetrunの微妙なところ
    LDAPNodeつかわないと、--allや--classが使えない
  • 98. サーバ間の依存関係が記述できない
    リソース間の依存関係は記述できる
    このサービスデーモンはこの設定ファイルに依存する、など
    サーバ間の依存関係は記述できない
    このサーバは、データベースサーバがセットアップされてからマニフェストを適用する、といったことができない
  • 99. パッケージ削除が微妙
    パッケージの追加は、依存関係勝手に解決してくれる(これはPuppetではなく、利用しているパッケージプロバイダ依存)
    パッケージ削除は解決してくれない
    RedHat系の場合、追加はyumコマンドでやるけど、削除はrpmコマンドでやってるっぽい
    他のパッケージシステムは不明
    余計なパッケージを最初から入れないのが吉
  • 100. とはいうものの
    色々微妙な点を挙げてみたけど、Puppet以上にシンプルで使いやすいものはなさそう
    というわけで、当分はPuppet使い続けることになりそう
    だけどChefの今後の動きにも要注目
    内部DSLなので言語の自由度は高そう
  • 101. 結論
    微妙なところもあるけど、現存するこの手のツールの中ではベストだと思う
    なのでみんなPuppet使ってみよう
  • 102. ご清聴ありがとうございました