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

Puppetのススメ

on

  • 21,518 views

 

Statistics

Views

Total Views
21,518
Views on SlideShare
20,244
Embed Views
1,274

Actions

Likes
30
Downloads
179
Comments
1

13 Embeds 1,274

http://d.hatena.ne.jp 777
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

11 of 1

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

    Puppetのススメ Puppetのススメ Presentation Transcript

    • 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)
      puppetクライアント
      (puppetd)
      puppetクライアント
      (puppetd)
      プロトコルは XMLRPC over HTTPS
    • Puppet用語
      マニフェスト
      システムのあるべき状態が記述されたファイル
      Puppetサーバで一括して維持管理する
      Puppetクライアントで取得し、システムに適用
      リソース
      Puppetマニフェスト内で扱うオブジェクト
      ユーザ、ファイル、パッケージなど
    • Puppetの動作概要パターン1
      puppetサーバ
      (puppetmasterd)
      ③ 適用結果をレポート
      ① マニフェストを取りに行く(デフォルトは30分に1回)
      puppetクライアント
      (puppetd)
      ② 取得したマニフェストを適用する
    • Puppetの動作概要パターン2
      puppetサーバ
      (puppetmasterd)
      ④ 適用結果をレポート
      ② マニフェストを取りに行く
      ① サーバ上でpuppetrunを実行してpuppetdをキックする
      puppetクライアント
      (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 見てください。(といっても、古いのでそのまま利用できないかもですが。)
      ちなみに、CentOSだと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でクライアントをキックしたりします
    • Puppetの使いどころ
    • Puppetの使いどころ
      大量にサーバがある
      異なる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’];
      }
    • Apacheマニフェスト(つづき)
      defineapache_module() {
      ....
      }
      apache_module { ‘rewrite’:
      config => “puppet://$server/rewrite.conf”,
      }
    • Apacheマニフェスト(つづき)
      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 {
      file {"/tmp/testvar":
      content => "$myvar",
      }
      }
      classchild_class {
      $myvar= 'fred‘
      includebase_class
      }
      ただし、$myvarがグローバルになる
    • 想定通りにするには(別パターン)
      classbase_class {
      $myvar = 'bob'
      file {"/tmp/testvar":
      content => "$myvar",
      }
      }
      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使ってみよう
    • ご清聴ありがとうございました