Chef で MySQL を入れようとして make が無くてコケるとき
DevOps 系の技術や話題にキャッチアップすべく、ここ 1 ~ 2 ヶ月でいろいろ新しいことを始めました。
さくら VPS 上に手作業で構築していた Apache x mod_php な環境で運用してましたが、全て Chef (というか knife solo) で構築するようにして、構成も Nginx x PHP-FPM に変更。
あとはアクセスログなんかは LTSV 形式で出力するようにし、それを Fluentd で吸い上げ Elasticsearch に突っ込み、Kibana を眺めてニヤニヤする、みたいな感じになってます。
なお、Chef に入門するにあたっては伊藤直也さんの書籍入門Chef Solo
で、今度は AWS に引っ越そうとしているんですが、あんまり AWS に関係ないところでハマったので、それについて書きます。
正直まだよくわかってない部分が多いので、ツッコミ大歓迎です。
起きた問題
EC2 の Ubuntu Linux 12.04 LTS に knife solo によるプロビジョニングを行ったところ、MySQL のビルドでコケました。
長いですが、 make コマンドが見つからなくてコケていることがわかります。
なお、 MySQL は Opscode Community の mysql クックブック 4.0.6 を Berkshelf を利用してインストールし、make のインストールは自前のクックブックでインストールするようにしています。
そして run_list 上は MySQL より先に make がインストールされるように指定していました。
対処
make をインストールするクックプックのレシピに、以下のような修正を行いました。
元はこれ。
これを、run_action メソッドを呼ぶように修正しています。
run_action メソッドとは何か
いろいろ調べた結果、以下の記事にたどり着きました。
Evaluate and Run Resources at Compile Time
Chef によるレシピの実行はコンパイルと実行の 2 フェーズに分かれていて、まずコンパイルフェーズではレシピを Ruby コードとして実行し、取り扱うべきリソースや、それに対して行うアクションを識別します。
それを一気に実行するのが実行フェーズです。
ですが、run_action メソッドを呼ぶことで、コンパイルフェーズでそのアクション (例えばパッケージのインストール) を実行することができてしまいます。
これにより、本来 make のインストールが先に行われるべきところが、コンパイルフェーズにおいて MySQL のインストール (厳密には Ruby の mysql gem のビルド) が行われるも、make はまだインストールされてないのでコケる、ということになっていました。
それならば、ということで make のインストールも run_action でコンパイルフェーズに行ってしまえば、MySQL のビルドよりも make のインストールが先行するので、問題なくプロビジョニングが完了する、というわけです。
本当にそれでよいのか
どうにもバッドノウハウ感があります。
おそらく、run_action は本来できる限り使うべきでない禁じ手で、Opscode の mysql クックブックは run_action を使わない形に修正されるべきなんじゃないかと思ってます。
mysql クックブックを自前でそのように作ってしまってもいいのかもしれません。
その他、いい方法をご存知の方は是非教えてください。
まぁ面倒なので MySQL は Amazon RDS に移行する予定です。
ブログ書いたらお腹空いたので目黒においしいトンカツでも食べにいこうと思います。