0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ryota__py

AWS CodeBuild入門

0
Posted at

AWS CodeBuild入門：マネージドビルドサービスでCI/CDを加速する

このブログはこんな人向け

  • CI/CDパイプラインでビルド・テストを自動化したい方
  • Jenkinsサーバーの管理から解放されたい方
  • CodePipelineと連携してデプロイを自動化したい方

この記事で得られること

  • CodeBuildの基本概念と仕組み
  • buildspec.ymlの書き方
  • 実践的なビルド設定方法
  • 他のAWSサービスとの連携

目次

  1. はじめに
  2. CodeBuildとは
  3. buildspec.ymlの基本
  4. まとめ
  5. 参考リンク

1. はじめに

AWS CodeBuildは、ソースコードのコンパイル、テスト実行、デプロイ可能なアーティファクトの生成を行うフルマネージドなビルドサービスです。Jenkinsのようなビルドサーバーの管理が不要で、使った分だけ課金されます。

2. CodeBuildとは

ひとことで

「サーバー管理不要なビルド・テスト実行サービス」

特徴

  • フルマネージド: ビルドサーバーの管理不要
  • 従量課金: ビルド実行時間のみ課金（アイドル時間は無料）
  • スケーラブル: 複数ビルドを並列実行可能
  • セキュア: VPC内での実行、シークレット管理

Jenkinsとの比較

項目 CodeBuild Jenkins
サーバー管理 不要 必要
料金 従量課金（使った分のみ） サーバー費用（常時稼働）
スケーリング 自動 手動設定
初期設定 簡単 複雑
プラグイン 限定的 豊富
カスタマイズ性 中 高
学習コスト 低 高

CodeBuildを選ぶべきケース

  • サーバー管理の手間を減らしたい
  • 小〜中規模のビルド処理
  • AWS環境での開発
  • CodePipeline、CodeCommitとの連携

Jenkinsを選ぶべきケース

  • 高度なカスタマイズが必要
  • 複雑なビルドパイプライン
  • 既存のJenkinsプラグインに依存
  • オンプレミス環境との連携

3. buildspec.ymlの基本

GitHub ActionsのWorkflowと似てる？

結論: 似ているが、より単純

共通点:

  • YAMLファイルでビルド手順を定義
  • フェーズ（ステップ）ごとにコマンドを実行
  • 環境変数の設定が可能
  • アーティファクト（成果物）の保存

違い:

項目 buildspec.yml GitHub Actions Workflow
複雑さ シンプル 複雑（多機能）
ジョブ数 1つのみ 複数ジョブ並列実行可能
マトリクスビルド なし あり（複数バージョンで並列テスト）
if文 なし 豊富な条件分岐
アクション/再利用 なし Marketplaceから再利用可能
トリガー CodeBuild設定 workflowファイル内で定義
実行環境 AWS管理 GitHub管理

例: GitHub Actions Workflow

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm install
      - run: npm test

同じことをbuildspec.ymlで:

# buildspec.yml
version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 18
  pre_build:
    commands:
      - npm install
      - npm test

ポイント:

  • buildspec.ymlはビルド手順だけに集中
  • GitHub Actionsはワークフロー全体（トリガー、複数ジョブ、デプロイ等）を管理
  • buildspec.ymlの方がシンプルで学習コストが低い

3.1 基本構造

buildspec.ymlは、ビルド手順を定義するYAMLファイルです。リポジトリのルートに配置します。

基本テンプレート:

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 18
    commands:
      - echo "Installing dependencies..."
  
  pre_build:
    commands:
      - echo "Running pre-build commands..."
  
  build:
    commands:
      - echo "Building the application..."
  
  post_build:
    commands:
      - echo "Running post-build commands..."

artifacts:
  files:
    - '**/*'
  base-directory: dist

cache:
  paths:
    - 'node_modules/**/*'

3.2 フェーズの説明

install

目的: 依存関係のインストール、ランタイムのセットアップ

使用例:

install:
  runtime-versions:
    nodejs: 18
    python: 3.11
  commands:
    - npm install -g yarn
    - pip install -r requirements.txt

pre_build

目的: ビルド前の準備作業（テスト、コード解析など）

使用例:

pre_build:
  commands:
    - npm install
    - npm run lint
    - npm test
    - echo "Logging in to Amazon ECR..."
    - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com

build

目的: 実際のビルド処理

使用例:

build:
  commands:
    - npm run build
    - docker build -t my-app:$CODEBUILD_RESOLVED_SOURCE_VERSION .
    - docker tag my-app:$CODEBUILD_RESOLVED_SOURCE_VERSION $ECR_REPOSITORY_URI:latest

post_build

目的: ビルド後の処理（アーティファクトのプッシュ、通知など）

使用例:

post_build:
  commands:
    - docker push $ECR_REPOSITORY_URI:latest
    - echo "Build completed on `date`"
    - printf '[{"name":"my-container","imageUri":"%s"}]' $ECR_REPOSITORY_URI:latest > imagedefinitions.json

3.3 アーティファクト

アーティファクトとは？

アーティファクト（Artifact）= ビルドの成果物のこと

具体例:

  • コンパイル済みのバイナリファイル（app.exe、app.jar）
  • ビルドされたフロントエンドファイル（dist/フォルダ）
  • Dockerイメージの定義ファイル（imagedefinitions.json）
  • ZIPファイル（build.zip）
  • テストレポート、カバレッジレポート

なぜ必要？

  • ビルド結果を次のステップ（デプロイ）で使うため
  • S3に保存してバックアップ・配布するため
  • CodePipelineの次のステージに渡すため

イメージ:

ソースコード (GitHub)
  ↓ ビルド (CodeBuild)
  ↓
成果物 (アーティファクト) → S3に保存
  ↓
デプロイ (Elastic Beanstalkなど)

ビルド成果物の定義:

artifacts:
  files:
    - '**/*'                    # すべてのファイル
    - 'dist/**/*'               # distディレクトリ配下のみ
    - 'build/app.zip'           # 特定ファイル
  name: my-app-$(date +%Y%m%d-%H%M%S)  # アーティファクト名
  discard-paths: yes          # ディレクトリ構造を平坦化
  base-directory: build       # ベースディレクトリ

複数アーティファクト:

artifacts:
  files:
    - 'dist/**/*'
  name: frontend
  
  secondary-artifacts:
    backend:
      files:
        - 'build/**/*'
      base-directory: server

3.4 キャッシュ

キャッシュとは？

キャッシュ = 前回のビルドで使ったファイルを再利用する仕組み

なぜ必要？

  • ビルドのたびに依存関係をダウンロードするのは遅い・無駄
  • キャッシュがあれば2回目以降のビルドが爆速になる

具体例:

初回ビルド（キャッシュなし）:
  npm install → 2分（依存関係を全部ダウンロード）
  npm run build → 1分
  合計: 3分

2回目以降（キャッシュあり）:
  npm install → 10秒（キャッシュから復元）
  npm run build → 1分
  合計: 1分10秒

節約できる時間:

  • Node.js: node_modules → 1〜3分短縮
  • Maven: .m2 → 2〜5分短縮
  • Docker: レイヤーキャッシュ → 5〜10分短縮

注意点:

  • キャッシュはS3に保存される（料金発生）
  • でもビルド時間短縮によるコスト削減の方が大きい

依存関係のキャッシュ:

cache:
  paths:
    - 'node_modules/**/*'
    - '/root/.npm/**/*'
    - '/root/.m2/**/*'        # Maven
    - '/root/.gradle/**/*'    # Gradle

S3キャッシュ:

  • ビルド時間を短縮
  • 依存関係のダウンロード回数を削減
  • コスト削減

3.5 環境変数

環境変数の注入方法は3つ:

1. CodeBuildコンソールで設定（推奨）

手順:

  1. CodeBuildプロジェクトを開く
  2. 「編集」→「環境」
  3. 「追加の設定」→「環境変数」
  4. 名前と値を入力

メリット:

  • buildspec.ymlにハードコードしない（セキュア）
  • 環境ごとに異なる値を設定可能
  • 機密情報はSecretsタイプで非表示化

例:

名前: NODE_ENV
値: production
タイプ: プレーンテキスト

名前: API_KEY
値: /myapp/api-key  (Parameter Storeのパス)
タイプ: Parameter Store

2. buildspec.yml内で定義

使用例:

env:
  variables:
    NODE_ENV: production
    API_URL: https://api.example.com
  
  parameter-store:
    DB_PASSWORD: /myapp/db/password
  
  secrets-manager:
    API_KEY: myapp/api:key

注意点:

  • variables: 平文の環境変数（機密情報は避ける）
  • parameter-store: Systems Manager Parameter Storeから取得
  • secrets-manager: Secrets Managerから取得（自動ローテーション対応）

3. 使い方（コマンド内でアクセス）

シェルスクリプト内:

build:
  commands:
    - echo "Environment is $NODE_ENV"
    - echo "API URL is $API_URL"
    - npm run build --env=$NODE_ENV

Node.js内で使う:

// アプリケーションコード
const apiUrl = process.env.API_URL;
const dbPassword = process.env.DB_PASSWORD;

Python内で使う:

import os
api_url = os.environ.get('API_URL')
db_password = os.environ.get('DB_PASSWORD')

セキュリティのベストプラクティス

機密情報の扱い:

# ❌ 悪い例: buildspec.ymlに直接書く
env:
  variables:
    DATABASE_PASSWORD: "my-secret-password"  # 絶対NG!

# ✅ 良い例: Secrets Managerから取得
env:
  secrets-manager:
    DATABASE_PASSWORD: myapp/db:password

推奨される使い分け:

  • 平文でOK: NODE_ENV, AWS_REGION, APP_NAME
  • Parameter Store: DB接続文字列、API URL
  • Secrets Manager: パスワード、APIキー、トークン

ビルド時の環境変数（自動で設定される）:

  • CODEBUILD_BUILD_ID: ビルドID
  • CODEBUILD_SOURCE_VERSION: コミットID/タグ
  • CODEBUILD_RESOLVED_SOURCE_VERSION: 解決済みコミットID
  • CODEBUILD_SOURCE_REPO_URL: リポジトリURL

4. まとめ

CodeBuildは、サーバー管理不要なビルドサービスです。

重要ポイント

  1. buildspec.yml

    • install、pre_build、build、post_buildのフェーズ
    • アーティファクトとキャッシュの設定
    • 環境変数とシークレット管理

  2. 最適化

    • キャッシュでビルド時間を短縮
    • 適切なコンピューティングタイプの選択
    • 並列ビルドの活用

  3. セキュリティ

    • Secrets Managerでシークレット管理
    • IAMロールで最小権限
    • VPC内でのビルド実行

CodeBuildの限界

以下の場合は他ツールを検討：

  • 超複雑なビルドパイプライン → Jenkins
  • ビルド時間が15分以上常に超える → セルフホスティング
  • 高度なプラグインが必要 → Jenkins、GitLab Runner

5. 参考リンク

公式ドキュメント

ベストプラクティス

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?