chef雑感
chef
仕事きっかけでchefけっこうやる機会があったので思った事を書いておく。
昔から興味あったけど、個人の遊びプロジェクトでは複数台とか管理する動機あまりないから、本格的にやる機会があるのはラッキーだったと思う。
丸3日くらいでなんとかなるだろくらいに考えてたのが、実際には倍くらいかかったし、家でもけっこう時間使った。
というのも、chefはengineyardのレシピで少しなじみがあったが、バージョン上がってて細かいところで変わってるところとか結構あると思った。
感想
感想を一言でまとめると、定番と呼ばれるベストプラクティス、ベストレシピがあまり無いと思った。
Rails3.0とかRuby1.9のころのバージョン違いによる互換性の荒波がある感じ。
その時にBundlerが役に立ったのと同様、Berkshelfというのがあった。でも、公式のレシピでさえも使い方が人それぞれでまとまっていない感じで結構苦労した。
定番のものが見つからないというように、問題を難しくしているのはプラットフォームが多い事が一つあると思う。
でも、chefみたいのが無い世界よりはずっとまし。PaaS楽だわーというのを実感する。
それぞれが、思い思いにやっている情報があるだけでも、恵まれてると思う。ものによっては、情報自体がほとんどないジャンルも世の中にはいっぱいある。Rubyやってるとたいていの事は既にやっていて公開されているものがあるので、ギャップに苦しむ。
（RubyToolboxとかGitHub上にも指標がいっぱいある）
テスト
テストは、docker流行ってると思って本とか情報を最初に見たんだけど、結局プロジェクトの規模感とか目的からして全然あっていなくて実践では必要なさそうな結論になった。結局ローカルのテストはVagrantで十分だった。
ただ、Vagrantもよく分からないところがまだある。
ある程度レシピができてから、また0の状態からのテストのために壊して再度作り直したつもりでも前のものが残ってたり、複数台テストしようとしたらhomeディレクトリ以下が同じものでどうなっているんだという感じで、実体がどうなっているのかの部分で理解しきれていないところがある。
どこに書けばいいか問題
これが一番苦労する問題。
chef自体まだベストプラクティスが分からないところがある。
どこにでも書けて、どこに書いて良いか分からないという問題。
- credentialな情報の置き場など
- databags
- node
- env var
- recipe
- attribute
- どこに実行レシピを書けば良いか
- node (run_list)
- site-cookbooks
- recipe
- attribute
順番の問題
順番も結構気をつけないといけない問題が結構あった。
ローカルで開発中のものは、追加開発ごと問題は起きなくても、0の状態で走らすとこけるみたいなことが良く起こる。
具体例としては、rbenvのレシピをテストした後、user関連でgitを使うレシピを追加したのだが、0から走らせた時エラーになった。
userの後にrbenvを走らせているのだが、userのレシピでgitが無いエラーになった。
rbenvがgitをインストールしてくれていたことが原因だった。解決としては最初にyumでgitインストールを追加した。
全体としては、順番的に気をつけるのは、最初に持ってくる順で言うと、
Permission系(user作成、ssh設定とか)
→システムワイドのライブラリインストール
→userの設定系
→ruby, db, webサーバーなどアプリで利用するもの
という感覚でいる。
書籍
これを機に読んだ本。助かった。
Amazon.co.jp: Chef活用ガイド コードではじめる構成管理 (アスキー書籍) 電子書籍: 澤登 亨彦, 樋口 大輔, クリエーションライン株式会社: Kindleストア
「Chef実践入門」は電子書籍になっていなかったが、電子書籍だったら目を通してみたかった。
サイトは数えきれないくらい調べた中で特に
さくらVPSの初期設定をChef Soloでやってみた〜サードパーティcookbookの使い方〜 | tsuchikazu blog
良かった
その他
やってみたいこともいくつかある
1つはserverspec
もう一つはJenkinsとかに毎日のようにレシピのテストをさせること
家では会社のことはあまりやらないを近年は心がけていたけど、今回は自分のVPSとかにも展開できるというメリットがあるのでその点は良しとした。
個人的にはネットワークがとにかく苦手だなというのを実感した。
プロジェクト自体の問題でいうと、技術選定とか人選とかでもなく、プロジェクトに関わる他社の構造がすべての問題の根源になっている。おそらく関わっている会社が多すぎ（看板上は数社でも実情は派遣・出向も多い）て、細かいところで責任を持つキープレイヤーが曖昧になり、すぐボールが宙に浮く。自分たちが指摘しないと前に進まない。肝心な情報、要望が突然湧いてくる。遅れている開発チームはスケジュール遅れのプレッシャーだけに意識がいって、要所要所で改善する方向に動かない。Excelでは問題（履歴）が追えない。
納品の無い開発の情報をよく見かけて、そういう世界ができたらいいなあと切に思う今日この頃。
まだ読んでいないが、電子書籍出たら読もうというのは決めている。
自社側でプロジェクトを手伝ってくれている人が新たに加わっているのだが、予想・期待していたのに比べ150%以上くらいにやってもらえているので、ラッキーだし、自分個人としても流れが良いと感じている。ありがたい。
だから、燃え尽きない程度に頑張ろうと思える。
Ruby5みたく意味も無く音楽貼っていこうと思っていたけど、良いのが見つかった。
