hiroshima.rb

広島Ruby勉強会#35 - Chefについて話しました

広島Ruby勉強会#035に参加しました。
半年くらいChefを使い込んで、大分慣れてきたので
今回はChefについて話してきました。

スライドの内容は、

  • chef-server,knife,chef-clientのインストールとか設定
  • Cookbookの中身についての説明
  • 便利Cookbookの紹介
  • nodeって何なのかなど
  • Tips

みたいな構成になってます。

chef-server,knife,chef-clientのインストールとか設定

Chefはchef-serverの構築が割と面倒だったり、
はまりどころが多かったりという理由で
敬遠されがちだったりします。

Chefの10.x系までは結構大変でしたが、
11.x系からは割と簡単になった気がしてます。

chef-soloも便利なのですが、
chef-serverじゃないと出来ない事も色々とあったりするので、
自分としては運用はchef-server有りの構成が良いと思います。

vagrant等でchef-solo動かして開発環境をサクッと作ったり、
Cookbookのテストを書いてみたりなど、今後やっていきたい所。

Cookbookの中身についての説明

Cookbookは正直、ソースをどこから読んで良いのか分からない感じでした。

初めはrecipesの中から読んでいくのが良いかなと思ったのですが、
Cookbookによってはprovidersしか使ってなかったり、
providersの処理がlibの中に入ってたり、
書き方が色々とあるみたいで悩んだ所です。

「metadata.rbて何？」みたいな質問もありました。
スライドからは抜け落ちてる感じだったので
ざっくり説明すると、

  • Cookbookの名称 … ここで設定した名称でchef-serverに登録される
  • Cookbookのversion … chef-serverはversionごとにCookbookを管理
  • Cookbookの依存関係 … chef-clientは実行時に勝手に依存関係のCookbookを取得してくれる
  • recipeの概要を書いたりなど … 10.x系だとmetadata.rb内のrecipe名が間違っててもエラーにはならないらしい

という感じです。
ただ、11.xから色々と記述が加わってるぽいですが、
調べきれていないです。

便利Cookbookの紹介

apache2やmysqlなどのCookbookを紹介しました。
htpasswdは便利ですが、
sudoは諸刃の剣なので気をつけましょうという。

Chef10.x系を使ってる間に、
その頃使ってたCookbookもChef11.x系対応になってたりしてるので、
Cookbook管理用のリポジトリは別途、自分の環境用に用意したほうが良いです。

Cookbookをコピーしてきても、自分の環境でそのまま動かない事があり、
例えば、AWS製のLinux(Amazon Linux)の場合は
Cookbookに処理自体が書かれてない場合があり、
そういうCookbookは自分用に修正して、別のリポジトリに登録しておくほうが無難です。
（よくあるのは、recipe内に:centosや:redhatというシンボルが登場するけど:amazonだけが無いとか）

あと、よく知られたミドルウェアのCookbookほど、
ぐぐったら沢山出てきてどれ選んで良いのか分からない事があるのですが、
迷ったときはOpscode社のgithubに上がってるCookbookを使うといいと思います。

nodeって何なのか など

nodeについて理解するまでCookbookのパラメータはattributesに全部書いてました。
attributesにはデフォルト値だけ書けばよいらしいです。
nodeとattributes両方に別々に値が設定された場合、どちらが優先されるかなど
気にしないといけない事が結構あるようです。
（nodeのほうが優先される）

Tips

roleの説明をざっくりと行いました。

時間があれば、environmentやdatabugなども説明したかったのですが、
スライド作る時間が無くなってしまったのでTipsとしては微妙な感じになってしまいました。

今後やっていきたい事

  • 自作Cookbookのテスト書いてないので書く
  • chef-clientをエージェントで動かす
  • Chefを10.x系から11.x系にバージョン上げる