AWS CodeBuildの超詳細解説

# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。

この記事ではCodeBuildとはどういうサービスで何ができるのかを超詳細にまとめています。

具体的には以下流れで説明します。
- AWS CodeBuildとは
- AWS CodeBuildの仕組み
- AWS CodeBuildのローカルビルド
- AWS CodeBuildのVPC内起動
- AWS CodeBuildの環境変数
- AWS CodeBuildのセキュリティ
- AWS CodeBuildのテストレポート

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

# この記事を読んでほしい人
- CodeBuildがどういうサービスか説明できるようになりたい人
- CodeBuildを採用するときのベストプラクティスを説明できるようになりたい人
- AWS Certified DevOps Engineer Professionalを目指している人

# AWS CodeBuildとは
AWS CodeBuildはフルマネージドのCIサービスです。
ビルドキューも含めてサーバーの管理やプロビジョニングが不要なので、Jenkinsなどに比べて簡単にCIを始めることができます。

CodeBuildの実態はコンテナサービスでDockerイメージを利用して起動しています。
そのため、カスタムDockerイメージを用いることで細かい要件も満たすことが可能です。

これはAWS CodeBuildの仕組みで詳しくまとめます。

ビルド処理自体はbuildspec.ymlにコード化することが再現性の観点からもベストプラクティスです。

なお、ソースとしてはCodeCommit以外にもS3、Bitbucket、GitHub、GitLabをサポートしています。

残念な点としては自分で構築したGitLabはサポート外な点です。
自分で構築したGitLabをソースにしたい場合にはCodeCommitへのミラーリングを間にかませて疑似的にソースとして扱うことになるので注意してください。

![](https://storage.googleapis.com/zenn-user-upload/82381791bf99-20231105.png)

# AWS CodeBuildの仕組み
すでに述べた通り、AWS CodeBuildは裏側にコンテナの技術が使われています。

![](https://storage.googleapis.com/zenn-user-upload/6e4efdf56594-20231105.png)

AWS側で準備しているイメージで事足りる場合にはそれでよいです。
しかし、特殊な用件がありカスタムイメージを使いたい場合には、ECRにイメージをプッシュし、そのイメージからAWS CodeBuildを起動するようにするとよいでしょう。

# AWS CodeBuildのセキュリティ
AWS CodeBuildはKMSを用いた暗号化を有効にできます。
具体的には出力するアーティファクトをKMSを用いて暗号化することが可能です。

また、転送データも暗号化されるので安心して利用することが可能です。

AWSのリソースにアクセスできるように認可するためにはCodeBuildにサービスロールを割り当てる必要があるので忘れないようにしましょう。

サービスロールが必要だ、という内容はたまに、認定試験で聞かれます。

# AWS CodeBuild for Advance
## AWS CodeBuildのローカルビルド
実はCodeBuild Agentを導入することでAWS CodeBuildをローカルで実行することが可能になります。

buildspec.ymlを書くたびにAWSのマネジメントコンソールに入る、あるいはパイプラインを動作させる、という方法でCodeBuildの試験をしているととても時間がかかります。

これを解消するためにローカル環境にCodeBuildの実行環境を構築することが可能です。

ただし、Dockerのインストールが必要などそれなりに設定を要するので開発者ごとに異なる設定でCodeBuildの試験をした結果、結合すると動かないというトラブルを引き起こす可能性があります。

試験環境管理ができないのであれば、素直にAWS上のCodeBuildで試験を行うのがおすすめです。

## AWS CodeBuildのVPC内起動
AWS CodeBuildはデフォルトだとVPC外で起動します。
しかし、VPC内リソースにアクセスする必要がある場合にはVPC内に起動する必要があります。

例えば、EC2にネットワーク通信したい要件がある場合にはVPC内リソースへの通信が発生するのでVPC内に起動する必要があります。

VPC内に起動する場合、AWS CodeBuildの実態がコンテナであり、起動した分だけIPアドレスを消費する、という点に注意してください。

特に並列実行をする場合にはその分だけVPC内のIPアドレスを消費します。
もちろん、コンテナなので実行完了すればIPアドレスは解放されますが、経験上CodeBuildの実行完了から解放まで平均で5分程度はかかります。

なのでVPC内でAWS CodeBuildを起動する場合にはIPアドレス数に余裕を持ったネットワーク設計が必要です。

## AWS CodeBuildの環境変数
AWSで環境変数を持たせるというのは試験頻出の内容です。

AWS CodeBuildの環境変数にはAWSから提供されているデフォルトの環境変数とカスタムして使う環境変数の2つが存在します。

AWSから提供されている環境変数にはリージョン名やビルドIDなどです。
詳しくは[AWS公式サイト](https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-env-vars.html)をご覧ください。

試験によく出るのはAWS CodeBuildが実行されているリージョンを読み取り、処理の分岐をさせる、という処理です。

2つ目の環境変数、カスタムの環境変数は文字通り自由に定義して使える環境変数です。
静的と動的があるので用途に応じて使い分けましょう。

ベストプラクティスはParamater StoreあるいはSecrets Managerにパラメータを保存し、それを読みだすという処理の流れで、これは試験でもよく聞かれます。

Secrets ManagerとParamater Storeの区別をつけられていない人がたまにいますがSecrets Manangerはセキュアに保存したいパラメータ、あるいは定期的なローテーションが必要なパラメータを保存します。

Secrets Managerに保存する例でよくあるのはRDSの接続情報です。

## AWS CodeBuildのテストレポート
テストレポートは文字通り、単体テストなどのテスト結果を結果をレポート形式で出力してくれるサービスです。

このサービスを用いることでテスト結果の可視化が簡易になります。

JUnit XMLやVisual Studio TRXなど様々な形式で出力でいるので詳細は[AWS公式サイト](https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/test-reporting.html)の確認をお願いします。

テストレポートを作成する場合にはbuildspec.ymlに出力内容を記載する必要があるので忘れないようにしましょう。

```yml
reports:
  php-reports:
    files:
      - "reports/php/*.xml"
    file-format: "JUNITXML"
  nunit-reports:
    files:
      - "reports/nunit/*.xml"
    file-format: "NUNITXML"
```

# まとめ
この記事ではCodeBuildとはどういうサービスで何ができるのかを超詳細にまとめました。

具体的には以下流れで説明します。
- AWS CodeBuildとは
- AWS CodeBuildの仕組み
- AWS CodeBuildのローカルビルド
- AWS CodeBuildのVPC内起動
- AWS CodeBuildの環境変数
- AWS CodeBuildのセキュリティ
- AWS CodeBuildのテストレポート

次回はCodeDeployについて超詳細解説を行います。