AWS LambdaでCI環境を作れるOSS「LambCI」試用メモ
これまでそれほど縁がなかったサーバレスですが、LambCIというOSSを使うとAWS LambdaでCI環境が作れるという話を聞き、ちょっと使ってみました。
GitHub - lambci/lambci: A continuous integration system built on AWS Lambda
LambCIとは
LambCIの紹介としては作者がMediumに投稿した記事がわかりやすいです。
Introducing LambCI — a serverless build system – Michael Hart – Medium
LambCI開発の背景部分をかいつまんで書き出すと、以下のような感じです。
- CircleCIみたいなサービスは、運用は楽なんだけど、結構高い
- Jenkinsみたいな自前環境は、運用が大変
- サーバレスアーキテクチャでCIサービスを作れば、運用は楽だし、ビルド処理分だけのお金で済みそう
LambCIの主な構成要素としては、以下のような感じです。ほとんどの構成要素は、CloudFormationで数分で作成できます。
- GitHub: Push等のイベントをAmazon SNSに伝える
- Amazon SNS: イベントをトリガーにAWS Lambdaを起動する
- AWS Lambda: ビルド処理を実行し、Amazon S3、Amazon DynamoDB、Slackに結果を保存・通知する
- Amazon S3: ビルド結果のhtmlや成果物を保存する
- Amazon DynamoDB: ビルド結果と設定値を保存する
ビルド処理は、レポジトリ内の.lambci.json
あるいは.lambci.js
というファイルに書きます。以下は.lambci.json
の例で、Pythonのtoxでテストを実行しています。
{ "cmd": "pip install --user tox && tox" }
実際にビルドしてみると、以下のような画面でビルド結果を確認できます。この画面はS3内にhtmlファイルとして保存されています。
AWS Lambda内の処理について
Lambda Function内の処理はNode.jsで記述されています。Node.jsが、.lambci.json
で指定されたコマンドをbash経由で実行します。
実行できる処理
Lambda Functionの実行環境内でできる処理はなんでもできますが、足りないバイナリやライブラリは自分で用意する必要があります。例えばGoツールは含まれていないので、go test
とかしたい場合は、Goツールをダウンロードする必要があります。
そのほか、Lambda Functionの実行環境については、以下の記事に書かれています。
ちなみにPythonはやや特別扱いされています。PythonはLambdaの実行環境に元々含まれている上に、LambCIがpipをバンドルしてくれているので、いきなりpipを使用できます。
ビルドの並列化と実行時間制限
TravisやCircleCIだと、設定ファイルを読んでビルドの並列化をしてくれますが、LambCIにはまだそういう機能はまだありません。これに、Lambda Functionの最大実行時間5分という制限が加わると、ちょっと厄介です。ビルドを並列化なしで5分で済ませないといけません。
LambCIとしては、ビルドをAmazon ECS(EC2 Container Service)上で実行することで、この制限を超える方法を用意しています。Dockerコンテナの中でさらにDockerコンテナを動かす仕組みになっていて、内側のDockerコンテナでビルド処理が動きます。このECSを使った方法ですが、避けたはずの「運用」の二文字が再び見え隠れしてきて、個人的にはイヤな感じがします。
まぁビルドの並列化についてはv1.0へのロードマップにも出ているので、そのうち実装されると思います。
感想
これまでCI環境を用意するとなると、それなりの運用コストを払って自前環境を作るか、お金を払ってCircleCIとか使うか、という選択肢だった気がします。LambCIはここに、運用コストを大幅に抑えつつ自前環境を作る、という選択肢をもたらすかも、と思いました。現状はまだ最低限の機能しかありませんが、v1.0が出る頃にはかなり使えるモノになっている気がします。
個人的には、LambCIに対するCircleCIとかの反応が気になります。例えば、課金モデルはどうなるでしょうか。CircleCIとかは、並列度を上げたいならもっとお金を払ってね、というモデルです。対してLambCIは、どれだけ並列度を上げてもAWSに払う金額は変わりません。あくまで合計ビルド時間に応じた料金が発生するだけです。
ユーザは、最初はCircleCIを使っていたとしても、並列実行するために高いお金を払うぐらいならLambCIに移行しようと考えそうです。そんな感じでユーザーが離れていくと、並列度に対して課金するモデルは成立しなくなり、合計ビルド時間に対して課金するモデルとかに移行せざるを得なくなるのでは、とか妄想しています。
追記: LambCIと似たコンセプトで、LambStatusというOSSを作っています。サービスの稼働状況をユーザに伝えるステータスページ(例:GitHubのステータスページ、Travis CIのステータスページ)を、サーバレスに実現するOSSです。よかったら見てみてください。