[2014-01-09-1]
からmasutaka.netのCIを開始したが、残念ながら
masutaka.netに直接serverspecする、なんちゃってCIだった。
masutaka.netにcookしてからPRを出して、WerckerにCIさせていた。
WerckerとAWSを連携させて、テストのたびにサーバをまっさらな状態から
作り、終わったら破棄することが可能になったので、ここに記録しておく。
去年くらいに話題になったこの辺の話。
Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
naoya/circleci-serverspec
なんで今までやらなかったかというと、cookが一発で通らないレシピになっ
ていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえ
すればよかったし。。。
こちらの記事でいうところの、Orchestrationの仕事までChefにやらせてい
たのが敗因。GitHubのprivateリポジトリにおいてあるdotfilesや、
growthforecast、tiarra、mobircまでもChefにインストールさせていた。
ユーザmasutakaに依存しないレシピに変更して、手元の
Vagrant+VirtualBoxで一発でspecが通るまでがステップ１。
次に手元のVagrant+AWSで同じことが出来るまでがステップ２。
これをWercker上で実行できるようにwercker.ymlを書き換えたのがステッ
プ３。
最終的なVagrantfileとwercker.ymlは以下のとおり。
いくつかハマったけど、凡ミスだったので特には触れない。上の設定に従
えば同じことは出来るはず。(CircleCIだと各インスタンスにssh出来るの
で、調査は早かったんだろうと夢想。)
でも一点だけad hocな対応をしていて、plenvやrbenvを使ったPerl/Rubyの
インストールはビルド済みのtar ballを展開するだけに変更した。
Werckerはビルドが5分間止まると失敗だと見なすから。ビルド全体の時間
は25分までOK。
そもそもImmutable Infrastructure的にplenvやrbenvを使うのはどうなの？
という節もあって、そこは今後変えるかもしれない。
wercker.ymlも毎回Vagrantをインストールして、vagrant upするという無
駄なことをしているので、Docker使って時短させるかもしれない。
とりあえずCI出来るようになったので、今回はこれで良しとする。