GitHubで複数コンテナを利用したビルドを試してみたこんにちは、Cariot事業部の遠藤です。Salesforceブログに続き、クラウドblogでも初投稿になります。GitHubを組み合わせて、CodeBuild上で複数コンテナを使ったビルドを実行する仕組みを試してみたので、紹介します。「RDBMSやRedisなどの外部リソースを利用したテストを、CodeBuild上で走らせたい」「クリーンな実行環境でCI/CDを回したい」という方のヒントになれば幸いです。それではどうぞ↓↓CodeBuildについてCodeBuildは、AWSが提供するフルマネージドなビルドサービスです。CodeBuild」ですが、本エントリでは省略してCodeBuildと書きます。ビルドサービスと謳っているように、CodeBuildがカバーする領域はあくまでビルド処理(コンパイル、テスト、パッケージング)だけです。そのため、コードリポジトリやCI/CDパイプラインに関しては、別のものを使う必要があります。AWSのマネージドサービスで言えば、リポジトリにCodeCommit、パイプラインにCodePipelineがそれぞれ該当します。このあたりの関係は下記のスライドにわかりやすくまとまっています。Japanというわけで、CodeBuildはJenkinsをまるっと置き換えるようなものではないので、目的・制約などに合わせた組み合わせを考える必要があります。EC2)を利用しました。GitHubとJenkinsで組んでいたジョブがあった、といのが理由です。Jenkinsマスタ1台で運用していたのですが、1日数回のビルド時にだけCPUが100%近くに貼り付き、リソース効率が悪いので、マシンパワーを使うビルド処理の部分だけをCodeBuildにオフロードしたい、というのが動機です。ビルド処理(Worker)としてCodeBuildを利用することで、次の利点が得られると期待しました。Jenkinsマスターのような常時稼働型のインスタンスに、ビルド処理に必要十分なスペックを用意する必要がなくなるので、スケールダウンができる(コストメリット)ジョブ同士が干渉することなく同時実行できるようになるので、待ちがなくなるクリーンな環境でのビルドができるようになり、ビルドの安定化が見込めるデータベースやJavaのバージョンなど、面倒なビルド環境の組み合わせテストが簡単に行える(こちらは、後述する複数コンテナを使ったビルドによって、実行環境のポータビリティが向上したことによるものです)いいことずくめですね!ちなみに、Workerとしてコンテナを使うのであれば、CodeBuildではなくECSを利用する、というのも一つの選択肢です。今回は、ECSをJenkinsのスレーブとして使う場合の設定が面倒(煩雑)そうという理由で見送りました。単純にCodeBuildを使いたかったから、という動機もなくはないですが...。Redisを利用しました。紹介する方法は、他の実行環境でも応用可能かな、と思います。試行錯誤の結果、以下のような全体像に落ち着きました。それぞれ見ていきます。ジョブ(パイプライン)については大きく2つに分けることにしました。PipelineCodeBuildでビルドを行なうためのカスタムのDockerイメージ(便宜上ランタイムイメージと呼びます)を作成し、ECR(Dockerレジストリ)に登録するためのジョブ。このランタイムイメージには、DBなどは含めず、docker-composeとJDKだけがインストールされた状態にしておきます。Pipelineランタイムイメージ上で実行されるアプリケーションのビルド用ジョブ。メインのビルドはこちらです。ビルドに必要なDBやRedisは、ビルドの前処理としてdocker-composeを使ってコンテナを起動します。2つに分けた理由は、メインのビルドの実行時間の短縮のためです。アプリケーションコードやミドルウェアの更新頻度に比べ、ランタイムイメージは更新が少ないため、毎回のイメージ作成は無駄になることが多いからです。