この記事は Progate Advent Calendar 2017 の11日目です。
今日はJenkins上のCIをAWSのCodebuildに移して幸せになった話をしようと思います。
前提
現在のProgateでは、コンテンツの制作にリソースの多くを注いでいるため、コードのコミット自体は多い方ではありません。
しかし、コミットの時間帯が集中したり、他のJenkinsタスクが走る時間帯とかぶると、なかなかテストが通らないことがあり、エンジニアから苦情が出る、ということが起こります。
Jenkinsのしんどいところ
弊社でもつい最近まで、m4.xlarge上のJenkinsを使ってPull Requestにテストを走らせていました。
機械的なチェックで、linterやユニットテストなど、最低限の品質を担保する上で大いに役立っていたのですが、課題もありました。
いくつか例を挙げると
- スペック的にもうテストが足せない…
- テスト項目同士の依存関係の管理が大変
- ディスク容量との兼ね合いで、数日経つとビルド結果が消える
- Jenkinsが混むと、なかなかビルドが始まらない
- 長時間実行しているJenkinsでなぜかエラーになる
- メモリが足りなくなったりDNSエラーで
git pull
が落ちてたり…
- メモリが足りなくなったりDNSエラーで
- etc...
CI as a Service なソリューションは高い
これらの解決策として、一番に思いつくのは Circle CI や Travis CI などの活用です。
しかし、Pricing のページを見るとわかるように、これらのサービスは 高い!
たとえば Circle CI だと、4人が同時にCIをまわそうとすると 1万5千円もします。
「問題をカネで解決して時間を買う」という考え方をするなら妥当な選択肢ではあるのですが、常時なにかしらコミットがなされている、というわけでもないので、ちょっと勿体無い感じがしますよね。
そこでCodebuildですよ
今回、弊社のCIで「つらい」部分をまとめると次のようになりました。
- 実行環境のスペックを気にせず、必要なテストを足したい
- ただし実行時間が伸びるのはNG
- 並列にスケールしてほしい
- 「なぜかエラーになる」というのはNG
- CI項目はリポジトリ側で管理できる
- 結果はいつでも見られる
Codebuild は去年の re:Invent で発表されたもので、Dog Year なこの業界においてはそこまで新しい選択肢でもないのですが、今回の弊社のユースケースにおいてはぴったりでした。
Codebuildの特徴を簡単にまとめると、以下のような感じになります。
完全マネージド型
実行環境に関してほとんど気を使わなくてよくなります。
従量課金
深夜などの待機時間には課金されません。
実行環境はDocker
dockerのイメージ化しておけば、特殊なビルド環境でも利用できます。
今回Progateでは利用していませんが、ビルドの成果物をS3などに置くこともできます。
Codebuild の使い方
GitHub上のリポジトリに対して、Codebuildで何か実行しようとすると、一般的には次のようになるかと思います。
- AWSのコンソールからCodebuildにプロジェクトを作る
- プロジェクトにリポジトリを登録する
- リポジトリの適当なところに
buildspec.yml
を置く - どうにかして
aws codebuild start-build --project-name={プロジェクト名}
を叩く
buildspec.yml
はS3に置いたりAWSのコンソールからCodebuildのプロジェクトに登録することもできますが、CI項目をリポジトリ側で管理することを考えると取りづらい選択肢でしょう。
また、Circle CI や Travis CI のように「git push
に反応して自動でビルドする」といった機能は現在のところ提供されていないので、自前でなんとかする必要があります。
実装方針
今回は、Lambda で解決することにしました。
GitHub PUSH -> Amazon SNS -> Lambda
の流れで実行して、
-
start-build
を叩く動作 - GitHub側に Commit Status (
pending
) をつける動作
を Lambda にやらせます。
GitHub と Amazon SNS の連携は こちら が参考になります。
また、ビルドの終了をCloudWatch Eventで拾って、そこから別の Lambda にやらせます。
Cloudwatch Event -> Lambda
ここで、success
または failure
の Commit Status をつけます。
実行時間・並列度について
buildspec.yml
中に
build:
commands:
- bundle install
- npm install
- rspec
- eslint
- flow
- ...
と書き連ねても良いのですが、これだと、項目が増えるごとにCI時間が長くなってしまい、あんまり幸せになれないです。
さいわい Codebuildでは、プロジェクト作成時だけでなく、start-build
の際にも buildspec.yml
について設定することができます。
そこで、Progateでは、各 buildspec.yml
の実行時間が大体同じになるよう、リポジトリ上の buildspec/
の下にファイルを複数用意することにしました。
用意した buildspec.yml
たちの一覧は、GitHub API を使えば次のように取得できます。
curl \
-u {username}:{token} \
'https://api.github.com/repos/{owner}/{repository}/contents/{path_to_file_or_directory}?ref={branch}'
あとは各 buildspec.yml
について、aws codebuild start-build
してやれば、無事に望みのものが手に入るはずです!
実行結果は https://${region}.console.aws.amazon.com/codebuild/home?region=${region}#/builds/${id}/view/new
で取得できます(コンソールへのアクセス権が必要です)
実行時間について
docker pull
以後の動作時間については課金対象としてカウントされるので、bundle install
やら npm install
やらは buildspec.yml
の中でやりたくないですよね。
実行環境で使用する docker イメージは指定できるので、こういった準備を事前に済ませたイメージをビルドして、ECRに入れて置くのが良さそうです。
移行した結果
冒頭で挙げた、「Jenkinsのしんどいところ」はほぼ解消されました。
- コンテナのプロビジョニングにかかる時間で多少前後するものの、おおむね5〜10分でテスト結果が出るようになった
- ビルド結果が消える、ディスクが溢れる、ときどきエラーになる、といった煩わしさから解放された
- CI項目を
buildspec.yml
としてコード上で管理できるようになった
課題
CodebuildのLimitにも書いてあるのですが、同時に実行できるビルドの数には上限があります。
節操なく start-build
しまくって上限を超えてしまうと、ビルドが失敗します。
とりあえずQueueに突っ込んでよしなに処理する、みたいな機能はCodebuild側には用意されていませんので、そこも自前でやる必要があります。
最後に
プロダクトのフェーズが変わってコミットが増えてくるとまた状況が変わるかとは思いますが、現状では、安くて便利なビルド環境が確保できて生産性が向上しました。
コードがほとんど公開できないために味気ない記事になってしまいましたが、ご興味を持たれた方は是非試してみていただけると幸いです。