MItamaeでdotfilesを管理してみた

MItamaeを使ってdotfilesを管理してみたら、お手軽に良い感じになったので紹介します。

そもそもMItamaeって？

プロビジョニングツール(Infrastructure as Code)であるitamaeを、mrubyで実装したものになります。

itamaeの文法が使えるため、シェルスクリプトやMakefileと違った、Ruby DSLライクな構成管理が可能になります。そのため、RubyやChefを触ったことがある人は特に導入がしやすいかと思います(itamaeはChefの簡易版)。

itamaeじゃダメなの？

itamaeでは、実行時にRubyの環境が必要です。MacのようにデフォルトでRubyがインストールされていれば問題ありませんが、そうではない場合、Rubyの環境を自前で用意する必要があります。

MItamaeは環境に左右されないの？

mruby実装を生かして、コンパイルされた実行用のシングルバイナリが配布されています。カーネルによって対象のバイナリを変える必要があるため、そこだけはローカル環境に合ったものを、 wget や curl で落とす必要があります。

MItamaeを用いたdotfiles

私のdotfilesを参考にしながら、ディレクトリ構成と処理の流れを整理していきます。

github.com

ディレクトリの構成

以下のようになりました。

➜  tree -aL 2
.
├── .gitignore
├── LICENSE
├── README.md
├── bin
│   ├── mitamae -> mitamae-1.9.5
│   ├── mitamae-1.9.5
│   └── setup
├── cookbooks
│   ├── fish
│   ├── functions
│   ├── git
│   ├── homebrew
│   ├── nvim
│   ├── python2
│   ├── python3
│   ├── rbenv
│   ├── tfenv
│   └── tig
├── install.sh
├── lib
│   ├── recipe.rb
│   └── recipe_helper.rb
└── roles
    ├── base
    └── darwin

上から順に

bin/ ... シングルバイナリの管理ディレクトリ。
cookbooks/ ... パッケージごとの設定ディレクトリ。
install.sh ... dotfilesの起点スクリプト。
lib/ ... MItamaeの起点ディレクトリ。
roles/ ... カーネルごとの設定ディレクトリ。

処理の流れ

install.sh を実行する。
bin/setup がキックされる。
1. カーネルに合ったMItamaeバイナリを落とす。
2. バイナリに bin/mitame という名前でシンボリックリンクを貼る。
install.sh に戻り、 bin/mitamae local lib/recipe.rb を実行する。
1. bin/mitamae が itamae コマンドの起点になる。
ローカルのカーネルと同じ roles 設定ファイルを実行する。例えばMacなら、 roles/darwin/ の設定を読み込むといったもの。
パッケージごとの設定を記した、 cookbooks を実行する。

dotfilesをMItamaeにして感じたメリット

Ruby DSLで書ける

経験不足もありますが、シェルスクリプトやMakefileのみのコードを保守し続けるのは少し敷居が高いです。その点MItamaeは、慣れているRuby DSLを使って保守し続けることができます。導入しようと思ったきっかけのひとつです。

itamaeのレールに乗れる

dotfilesの管理にプロビジョニングツールを使えるのは、メリットのひとつだと思います。例えば、itamaeの文法そのままにディレクトリを掘ったり、シンボリックリンクを貼る処理が書けます。公式が提供している構成のベストプラクティスも利用できます。

MItamaeのdotfiles実践プラクティス

ここでは開発中に、「こうすると良いのでは」と感じたことを整理したいと思います。

開発はitamaeで

開発環境では、itamaeコマンドを使えるようにしておくと良いです。例えばディレクトリを掘るために、 mkdir cookbooks/fish を打つといった手作業がなくなります。主に使うコマンドは

itamae generate [cookbook | role]
itamae destroy [cookbook | role]

のふたつだと思います。詳しくは itamae help で確認しましょう。

シンボリックリンク処理を再定義しない

シンボリックリンクを貼る処理を、 dotfile や ln といった名前で再定義しているケースがあります。私も最初は以下のように処理をまとめていました。

define :ln do   
  name = params[:name]  
  link node[:xdg_config_home] do    
    to File.expand_path("../../#{name}/files/#{name}", __FILE__)    
    user node[:user]    
    force true  
  end   
end

しかし、これだと以下のような問題が発生します。

リンク先をブロック内で再定義する必要がある
リンク元ディレクトリ(ファイル)をブロック内で再定義する必要がある
ln 処理の変更が全体に影響する

結局ブロック内で再定義する状況が生まれるなら、わざわざ ln 関数を作る必要はないと思います。また ln 内を変更するとき、処理が破壊されていないか気を揉む必要があります。
こうなると例外として、 link リソースを使いたくなるケースもあるかもしれません。ですが、シンボリックリンクを貼る処理が複数あるのは混乱の元です。どちらかにまとめたほうが保守はしやすいでしょう。

おわりに

MItamaeを使ったdotfiles管理は初めてだったのですが、今のところ不満はありません。
俗に言う「学習コスト」も

ディレクトリを掘る
シンボリックリンクをはる

が主になるので、取り立てて難しくないでしょう。
時期も時期ですので、新しいPC移行用のdotfilesをMItamaeで作ってみてはどうでしょうか。

ls /asapon/blog

基本tech、時々多趣味