作業ノート

様々なまとめ、雑感など

Chef実践入門を読んだ

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

本書を読む前に実践 Vagrantを読んでいて、vagrantコマンドを試したり、boxを作ったり、shellでプロビジョニングを試した。 そのときにプロビジョニングにChef Soloが使えることを知ったが、Chefに対しては少し面倒な印象を持っていたため、Chef Soloをプロビジョニングで利用するつもりはなかった。

本書のことを知って目次を確認したところ、Vagrantを使ったChefの解説があるようだったのでそこに興味を持って読んだ。

主に読んだのは、2章、5章と6章。6章のmysqlの構築までは、実際にVagrantを使って試した。また、試しているときにリソースの確認で3章を読んだ。

Chefに対する認識が変わったのは、2.10節の「Chefの考え方」に述べられている

  • 「手順」ではなく「状態」を定義する
  • 状態を「収束」(convergence)させる

というところ。

それまでは環境を構築するため手順書を記述しているような感じで、それを完璧に行えるように細かく設定していたため設定内容が煩雑になってしまっていた。

これでChefに対して少し面倒な印象を持つことになったのだが、手順ではなく状態として、そしてそれを収束させる、という捉え方によって「自分がその環境に期待する状態を少しずつ定義する」と考えるようになった。

今では、VagrantのプロビジョニングはChef Soloで行っている。Cookbookの作成は6章の手順を参考にした。

例えば、fooというCookbookを作成するなら以下のとおり。

1. site-cookbooksディレクトリにCookbookを作成する

$ bundler exec knife cookbook create foo -o site-cookbooks

2. Berksfileに作成したCookbookを記述する

cookbook "php", path: "./site-cookbooks/foo"

3. レシピを記述する

$ vi site-cookbooks/foo/recipes/default.rb

ひとまずdefaultのレシピにすべて記述。

4. berksコマンドでcookbooksディレクトリを最新にする

$ rm -rf cookbooks && bundle exec berk vendor cookbooks

これは本書の方法とは異なる。本書では

$ bundle exec berks install --path ./cookbooks

とあるが、berkshelfの3.1.5でこれを実行したところ

DEPRECATED: `berks install --path [PATH}` has been replaced by `berks vendor`.
DEPRECATED: Re-run your command as `berks vendor [PATH]` or see `berks help vendor`.

と表示されたので、このメッセージに従って、上述のコマンドを実行している。

5. Vagrantに自作したCookbookのレシピを追加

chef.run_list = %w[
  ...
  recipe[foo]
]

6. vagrantのプロビジョンを実行

$ vagrant provision

この流れでひとまずレシピを作成。動作を確認したら

  • defaultのレシピを分割して動作確認
  • 定数をattributeに定義して動作確認
  • Vagrantfileにattributeを設定して動作確認

のように少しずつ繰り返し変更して、再利用しやすいように変更している。

ちなみに、対象のボックスはCentOS 6.5 minimal x86_64のボックスを自作していて、rvmとChefをインストール済。

rvmをインストールしたのは、開発環境用としてmailcatcherをインストールしたかったが、CentOS 6.5のruby(1.8.6)ではインストールできなかったため。

ただそうしたところ、vagrant-omnibusプラグインとの相性が悪くて利用できなくなったため、rvm上にChefをインストールし、box化した。

本書によってChefの印象が変わり、VagrantのプロビジョンをChef Soloで行うようになるなど、自分の認識と環境を大きく変えた 一冊となった。

Subversionのリポジトリからgitリポジトリに移行する

会社で管理していたリポジトリをsvnからgitに移行したときの方法。

1.コミッターのリストを作成する

移行対象のsvnリポジトリをローカルにチェックアウト(svn checkout)している状態で、そのルートディレクトリ下で

$ svn log ^/ --xml | perl -ne 'print if /^<author/' | sort -u | perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt

を実行。 こうするとusers.txtには

foo =
bar =

のようなリストが作成される。それを編集して

foo = foo <foo@example.com>
bar = bar <bar@example.com>

のように、氏名 + <メールアドレス> を追記する。

2. git svnでcloneを作成する

次にgit svnコマンドで該当svnリポジトリをcloneする。

$ git svn clone http://www.example.com/path/to/hoge --no-metadata --authors-file=users.txt --trunk=trunk hoge

--no-metadataオプションは、コミットログにsvnのメタ情報を残さないための設定。 --authors-fileオプションには、1で編集したファイルを指定する。こうすると、コミットログのコミッターがusers.txtで編集した内容に置換される。

また今回、対象のリポジトリにはtrunkしか存在しなかったため、--trunkオプションでtrunkのみを指定した。

3. svn:ignoreの設定をgitに反映する

次に、svn:ignoreの設定を反映させるために、gitignoreファイルを作成する。

$ cd hoge/
$ git svn show-ignore > .gitignore

ファイルを作成したらコミットする。

$ git add .gitignore
$ git commit

4. 移行先のgitリポジトリにpushする

最後に、移行先のリモートリポジトリを設定してpushする。

$ git remote add origin username@example.com:/path/to/hoge.git
$ git push origin

参考