こんにちは！エンタープライズクラウド部技術2課の日高です。
本日は、AWS CodeBuild（今後はCodeBuildと表記）を使い始めたいという方に向けて、構築するうえで設定が必要なパラメータについて、概要を理解していただけるようにブログを書きたいと思います！
- AWS CodeBuildの概要
- AWS CodeBuildのパラメータ一覧
- まとめ
AWS CodeBuildの概要
フルマネージドなビルドサービスでソースコードの コンパイル、テスト実行、ソフトウェア パッケージの作成を実行できます。
下記の特徴があります。
- 個々のビルドを新規 Dockerコンテナで実行するためビルド環境は完全に分離されており、利用者がサーバを管理する必要がなくなります。
- AWS CodePipelineと統合することでCI/CDパイプラインの一部として利用することができます。
- buildspec.ymlというビルド仕様を定義するファイルで定義された内容に沿ってビルドを行います。
AWS CodeBuildのパラメータ一覧
すべてのパラメータを記載するとボリュームが大きくなってしまうので、パッと見て理解が難しそうなものを独断と偏見で抜粋して記載していきます。
プロジェクトの設定
ビルドバッジ（Build badge）
プロジェクトの設定にて有効/無効を選択できます。
有効にすることで上記画像のように、CodeBuild プロジェクトのステータスを誰でも確認できるバッジになっています。
ビルドバッジにはセキュリティ情報が含まれないため、認証は不要になっています。
バッジ URL のコピーボタンをクリックするとURLがコピーされ先ほどの画像のようにビルドバッジが表示されます。
このバッジのステータスは、下記の４つあります。
- PASSING ：該当するブランチで最新ビルドが成功しました。
- FAILING ：該当するブランチで最新ビルドがタイムアウト、失敗、途中終了、または停止しました。
- IN_PROGRESS： 該当するブランチで最新ビルドが進行中です。
- UNKNOWN ：該当するブランチでプロジェクトがビルドをまだ実行していないか、まったく実行したことがありません。また、ビルドバッジ機能が無効になっている可能性もあります。
私の場合はビルドしていない状態なので、 UNKNOWNと画像では表示されています。
AWS環境にはアクセスさせたくないけど、CodeBuild プロジェクトのステータスは確認したいといった場合などには利用できそうです。
また、個人的にはGitHubのREADME等によくいる印象があります。
※詳しくは以下をご覧ください
ソース
下記の画像の赤枠で囲っている箇所の説明を簡潔に記載していきます。
Git のクローンの深さ（Git clone depth）
クローン時に取得する、コミットの最新履歴からのバージョン数の上限を指定します。
画像のように指定できる値は1、5、25、Full（すべて）から選択できデフォルトでは１が選択されています。
最新のコミット以外にもクローンしたい要件がある場合は、その要件に合わせて設定する必要があります。
Git サブモジュール（Git submodules）
Gitのサブモジュール機能(別の外部プロジェクト)を含める場合に有効にします。（デフォルトでは無効。）
Gitのサブモジュール機能とは、Gitリポジトリ内に別のGitリポジトリを含むための機能のことでサブモジュールは、独自の履歴を持ち、親リポジトリとは独立して更新することができます。
大規模なプロジェクトなどで、複数の小さなリポジトリに分割しそれぞれを独立に管理する必要がある場合などに利用できます。
環境（Environment）
下記の画像の赤枠で囲っている箇所の説明を簡潔に記載していきます。
特権付与（Privileged）
CodeBuild作成時に選択することができ、コンテナがDocker実行環境内でDockerコマンドを実行できるようにする権限を与えるか否かを指定します。
CodeBuildでDockerコマンドを利用する場合は有効にする必要があります。（有効にしない状態でDockerコマンドを利用するとエラーになります。）
タイムアウト（Timeout）
ビルドジョブに対してのタイムアウト時間を5分から8時間の間から指定できます。（デフォルトは1時間になっています。）
ユースケースとして考えられるのは、ビルドが無限に続いたり予期しない時間がかかることによりコスト増加を防ぐだったり、ビルドの最大実行時間を制御することで、全体のパイプラインのフローをスムーズに維持するなどが挙げられます。
つまり要件によって適切なタイムアウト時間は変わりますが、特に要件がない場合はデフォルトのままでも問題ないと考えています。
キュータイムアウト（Queued timeout）
CodeBuildはビルドジョブの実行にキューを使用します。
ビルドジョブが実行待ち状態になると、そのジョブはキューに入り、利用可能なリソースが確保されるまで待機します。
この際の待機時間を「キュータイムアウト」と呼び、5 分～ 8 時間の間で値を指定できます。（デフォルトは8時間です。） ビルドプロジェクトの要件やスケジュールに応じて値は変わってきますが、特に要望がなければデフォルトで問題ないと思います。
※詳しくは以下をご覧ください。
証明書(Certificate)
GitHubなどで証明書をインストールしている場合に、アクセス許可をするための証明書を設定します。
証明書自体はS3にアップロードをし、アップロード先のS3を設定時に指定する必要があります。
適切なS3を指定しなかったり証明書がインストールされていないと、ソースリポジトリにアクセスできないエラーが発生します。
※詳しくは以下をご覧ください
VPC
ビルドコンテナのアクセス先のVPCを設定します。
指定したVPCのプライベートネットワークに配置しているリソースにアクセスさせたいなどの要件がある際に利用できそうです。
環境変数（Environment variables）
CodeBuildでの変数の指定方法の１つで、CodeBuildプロジェクトに対して環境変数を登録することができます。
変数の他の指定方法はbuildspec.ymlで指定する方法もあります。
次の3種類の環境変数を使用することができます。
- プレーンテキスト：入力された値が直接使用されます。
- パラメータ：AWS Systems Manager Parameter Storeに保存されている環境変数を取得します。
- Secrets Manager ：AWS Secrets Manager に保存されている環境変数を取得します。
※補足（環境変数の指定方法の使い分け）
大枠の使い分けとしては下記のようになると考えています。（具体的な使用法はプロジェクトの要件によります。）
- ビルドプロジェクト全体で指定が必要な変数を利用したい場合などには、ビルドプロジェクトの設定で環境変数を設定する。
- ビルドの挙動を動的に変更したい場合や環境変数の設定をバージョン管理したい場合などには、buildspec.ymlファイルで環境変数を設定する。
ファイルシステム（File systems）
Amazon EFS（今後はEFSと表記）のマウントの定義を行うことができます。（buildspec.yml内でmountコマンドを定義することも可能です。）
これは、ビルド中に利用可能な追加のディスクスペースとしてEFSを利用することができる設定になります。
ビルド中に一時的に大量のディスクスペースを必要とする処理がある場合や、ビルド間でファイルを共有する必要がある場合などに利用するといいと思います。
Buildspec
どのbuildspec.ymlを利用するかを指定します。
デフォルトではソースコードのルートディレクトリにあるbuildspec.ymlが選択されています。
バッチ設定（Batch configuration）
バッチ設定をすることで、複数のビルドをまとめて一度に実行できます。
ビルドが相互に依存している場合や、同じソースコードリポジトリから複数のビルドを実行する必要がある場合などに利用できそうです。
現在、下記の３種類のバッチ方法があります。
- build-graph：順番にビルドタスクを実行する
- batch-list：ビルドタスクを並列実行する。
- batch-matrix：ビルドタスクを異なる環境や変数ごとに並列実行する。
※詳しくは以下をご覧ください。
アーティファクト（Artifacts）
下記の画像の赤枠で囲っている箇所の説明を簡潔に記載していきます。
キャッシュタイプ（Cache type）
アーティファクトをキャッシュする場合に指定します。 キャッシュする場所としては、Amazon S3もしくはローカルから選択できます。
依存関係のダウンロードや中間成果物の生成などに時間がかかる場合などに、キャッシュすることでビルド時間の短縮を狙うことができます。
※詳しくは以下をご覧ください。
暗号化キー（Encryption key）
アーティファクトを暗号化する場合に使用されるAWS KMS カスタマーマスターキーを指定します。
デフォルトはAmazon S3 用の AWS 管理のカスタマーマスターキーが選択されています。
ログ（Logs）
CodeBuildのログをAmazon S3に保存するかAmazon CloudWatch Logsに保存するかを選択することができます。
細かい要件によって選択するサービスは変わってきます。
ただ、大雑把な使い分けとしてはログを保存するコストを低くしたい場合はS3、リアルタイムでログの取得や分析をしたい場合はCloudWatch Logsに保存するといいと思います。
まとめ
CodeBuildのパラメータを、パッと見て理解が難しそうなものを独断と偏見で抜粋して簡単に記載してみました。
なんとなくの概要はつかめたでしょうか！？
本記事が誰かの助けになれば幸いです。
日高 僚太(執筆記事の一覧)
2024 Japan AWS Jr. Champions / 2024 Japan AWS All Certifications Engineers
EC部クラウドコンサルティング課所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
