単にパッケージをインストールするだけのこんな感じのレシピをいくつか書いた後でふと気づきました。
if platform_family?('windows') windows_package node['hoge']['display_name'] do source node['hoge']['url'] installer_type :custom action :install options "/quiet" end end
わざわざchefを使うまでの話でもないな・・・
というわけで、単純なインストール作業はchocolateyに
お任せすることにしました。
そうすると、今までchefでやってた作業で残るものは
- C:\WORKの作成
- 環境変数HOMEの設定
- gitで管理しているドットファイルの取得
- ssh鍵の作成
- フォントのインストール
- 環境変数PATHの設定(viとかのインストール先を追加したい)
- 自動起動の設定(主にautohotkey)
といったところです。
このうち、1, 2, 3, 6, 7についてはpowershellのスクリプトに移行しました。
4,5は大した手間でもないので、手作業でやってます。*1
私が考えていたchefの利点というのは以下の3つでした。
- 冪等性
- platform independent
- DSL
ところが、1のケースで考えると、そもそも既存のディレクトリが存在したら、ディレクトリは生成できるわけがないので、どんな手段を使うにしても冪等性を考える必要はないわけです。*2
同じように、3のケースであればgitコマンド自体が冪等性を保証してくれますし、ソフトのインストールについてもインストール済みであればwindowsのインストーラが大抵は勝手に判定してくれます。
環境変数の設定はbashのexportでもsetxコマンドでも考慮してくれないので、PATHに同じディレクトリが複数回設定されるような状況が容易に起こるわけですが、この程度のことのためにchefを導入するのは、役不足でしょう。
platform依存性という観点では、そもそも設定している内容がwindows環境だから設定しないといけないという性質のものばかりなので、実際のところ、これまでの運用ではあまり活かせてませんでした。
vagrantやvirtualboxみたいな、どんなOSでも入れたいソフトもあるので、こういったもののインストールはお任せしたいところなんですが、現状のchefではaptやyumやdmgやwindowsのような、各プラットフォームに対応するためのcookbookも準備する必要があって、少々煩わしいです。*3
あと、pythonとかnode.jsのような、重要なソフトのコミュニティcookbookがwindowsに対応していなくて、結局自分でwindows専用のcookbookを
書く羽目になるのも悲しいところです。
最後のDSLというのは、スクリプトで書き直していると重要性を痛感できるんですが、これまた環境変数の件と同じく、これだけのためにchefを導入するもんでもないなぁと感じてます。
というわけで、ほぼすべての自作cookbookは闇に葬られて、いくつかのpowershellスクリプトに生まれ変わりました。
