SyntaxHighlighter

2012/12/19

Package Installer

Cookbook情報

概要

Chefのビルトインリソースpackageをラップして、各種パッケージの構成をAttributeとして管理できるCookbook。

解説

レシピが内部DSLで良かったと思える一品、packageリソースが対応するプラットフォームすべてに有効だ。

パッケージの導入&削除およびバージョン指定&自動更新をEnvironmentRoleのメタデータとして管理できるので多少の構成変更ならCookbookの変更が不要になることも大きい。
もしパッケージをインストール/アンインストールするだけのCookbookを書いていたらpackage_installerに統合したらよい。

recipe

defaultが一つだけ、そして10行しか無いのでまるごと掲載する。

余談だがattributeの指定にシンボルを使うのはFoodcritic FC001に引っかかるので、一応覚えておこう。

default

node[:package_installer][:packages].each do |pkg_name, pkg_info|
  if(pkg_info)
    pkg_action = pkg_info[:action] || :install
    pkg_version = pkg_info[:version]
  end
  package pkg_name do
    action pkg_action
    version pkg_version if pkg_version
  end
end

バージョンを貰えば指定つきで、各種パッケージを指定したactionで構成するだけと非常にシンプルだ。

Attributes

  • ['package_installer']['packages']
  • ['package_installer']['packages']['$pkgname']
    • ['action']:省略時は:install
    • ['version']: 省略可

Attribute設定の例

このCookbookに限った話ではないが、packages以下の要素を複数のRole,Environmentで同じように指定した場合上書きでなくマージされる

あるRoleでvimを指定して、

"package_installer": {
  "packages": {
    "vim": nill
  } 
}

ほかのRoleでtmuxを指定したとする。

"package_installer": {
  "packages": {
    "tmux": {"action": "upgrade"}
  }
}

Nodeの持つ最終的なAttributesはこのようになる。

"package_installer": {
  "packages": {
    "vim": null,
    "tmux": {"action": "upgrade"}
  }
}

当然どこかでrun_listrecipe[package_installer]を一度入れておけば、Chef-clientサーバの状態をそのようにしておいてくれる。

適用例1

ubuntu_baseというRoleを作って、よく使うユーティリティをdefault_attiributesにて指定するというような使い方が便利だろう。

{"name": "base_ubuntu",
  "description": "Server Basic Settings",
  "json_class": "Chef::Role",
  "default_attributes": {
    "package_installer": {
      "packages": {
        "dstat": null,
        "vim": null,
        "curl": {
          "action": "upgrade"
        },
        "yajl-tools": null,
        "tmux": null,
        "iotop": null,
        "nano": {
          "action": "remove"
        },
        "bsd-mailx": null
      }
    }
  },
  "override_attributes": {},
  "chef_type": "role",
  "run_list": [
    "recipe[package_installer::default]"
  ],
  "env_run_lists": {}
}

例ではopscodeのaptのCookbookも入れている、Chefサーバかcookbookのパスに一緒に入れておくことをお勧め。

実行ログ例1

INFO: Processing package[curl] action upgrade (package_installer::default line 7) 
INFO: package[curl] upgraded from uninstalled to 7.22.0-3ubuntu4 
INFO: Processing package[tmux] action install (package_installer::default line 7) 
INFO: Processing package[bsd-mailx] action install (package_installer::default line 7) 
INFO: Processing package[yajl-tools] action install (package_installer::default line 7) 
INFO: Processing package[nano] action remove (package_installer::default line 7) 
INFO: package[nano] removed INFO: Processing package[dstat] action install (package_installer::default line 7) 
INFO: Processing package[iotop] action install (package_installer::default line 7) 
INFO: Processing package[vim] action install (package_installer::default line 7) 

適用例2

syslog-ngのレシピを適用したいが、他のsyslog系を止めたい。これをRoleに書くことでCookbook修正の手間を軽減できる。

-- snip --
"default_attributes": {
  "package_installer": {
    "packages": {
      "rsyslog": { "action": "remove" },
      "syslog": { "action": "remove" }
    }
  }
},
"run_list": [ "recipe[syslog-ng::default]" ]
-- snip -- 

この場合はもちろん、How to write a good Chef cookbookのようにレシピ内で書いても良いが。

あとがき

このCookbookはOpscode作でなくコミュニティでShareされているもので、なおかつ1コミットで終了してライセンス表記もない。
しかし『Chef導入≠レシピ書く』を印象付けるのにとてもわかりやすいため紹介することにした。

1 件のコメント: