AWSのCI/CDパイプライン設計｜CodePipeline・CodeBuild・CodeDeployでBlue/Greenデプロイを自動化する構成パターン入門

この記事のポイント

・CodePipeline・CodeBuild・CodeDeployの3役割を正しく理解して設計する
・buildspec.ymlとappspec.ymlがCI/CDパイプラインの動作を定義するコアファイル
・ECS Blue/Greenデプロイでゼロダウンタイムリリースと即座のロールバックを実現できる
・IAM権限ミスがパイプライン停止の最大原因、最小権限設計で事前に防ぐ

# AWS CI/CDパイプラインの全体フロー

[Git Push]
    |
    v
[CodePipeline] ←パイプライン全体のオーケストレーション
    |
    +--> [Sourceステージ]
    |        GitHub / CodeCommit からコードを取得してS3に保存
    |
    +--> [Buildステージ（CodeBuild）]
    |        buildspec.yml に従いDocker build → ECRへイメージプッシュ
    |
    +--> [Deployステージ（CodeDeploy）]
             appspec.yml に従いECS Blue/GreenデプロイでALBトラフィック切り替え

# buildspec.yml（ECS Blue/Green向け基本構成）
version: 0.2

phases:
  pre_build:
    commands:
      - echo ECRにログイン中
      - aws ecr get-login-password --region ap-northeast-1           | docker login --username AWS --password-stdin $ECR_REPOSITORY_URI
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
  build:
    commands:
      - echo Dockerイメージをビルド中
      - docker build -t $ECR_REPOSITORY_URI:$IMAGE_TAG .
      - docker tag $ECR_REPOSITORY_URI:$IMAGE_TAG $ECR_REPOSITORY_URI:latest
  post_build:
    commands:
      - echo ECRにプッシュ中
      - docker push $ECR_REPOSITORY_URI:$IMAGE_TAG
      - docker push $ECR_REPOSITORY_URI:latest
      - printf '[{"name":"app","imageUri":"%s"}]'           $ECR_REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

# buildspec.yml でSSMパラメータを参照する例
env:
  variables:
    ECR_REPOSITORY_URI: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp
  parameter-store:
    DB_PASSWORD: /myapp/prod/db_password
    API_KEY: /myapp/prod/api_key

# NG: buildspec.yml にシークレットを直書きしない
# NG: Gitリポジトリにパスワードやトークンを混入させない

# ECS Blue/Greenデプロイのトラフィック切り替えフロー

[デプロイ前]
ALB --100%--> Blue環境（現行バージョン）

[デプロイ中]
ALB --10%---> Green環境（新バージョン）
    --90%---> Blue環境（現行バージョン）

[デプロイ完了]
ALB --100%--> Green環境（新バージョン）
Blue環境は指定した待機時間後に終了

[問題発生時]
CodeDeployコンソールから「ロールバック」を選択
 → ALBのトラフィックが即座にBlue環境に戻る

# appspec.yml（ECS Blue/Green用）
version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: 
        LoadBalancerInfo:
          ContainerName: "app"
          ContainerPort: 80
Hooks:
  - BeforeAllowTraffic: "LambdaFunctionForPreTrafficHook"
  - AfterAllowTraffic: "LambdaFunctionForPostTrafficHook"

# プライベートサブネット内のCodeBuildに必要なVPCエンドポイント一覧

インターフェース型エンドポイント（ENI作成）:
  com.amazonaws.ap-northeast-1.ecr.api        # ECR API
  com.amazonaws.ap-northeast-1.ecr.dkr        # Dockerイメージプル・プッシュ
  com.amazonaws.ap-northeast-1.logs           # CloudWatch Logs
  com.amazonaws.ap-northeast-1.ssm            # Systems Manager パラメータ参照

ゲートウェイ型エンドポイント（ルートテーブルに追加）:
  com.amazonaws.ap-northeast-1.s3             # アーティファクトのS3格納

# 直近のビルドIDを確認する
$ aws codebuild list-builds-for-project     --project-name myapp-build     --sort-order DESCENDING     --query 'ids[:3]'     --output text

# ビルドの詳細（フェーズの成否）を確認する
$ aws codebuild batch-get-builds     --ids xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx     --query 'builds[0].phases[*].{phase:phaseType,status:phaseStatus}'     --output table

# 出力例（PRE_BUILDフェーズで失敗している場合）
# +--------------+----------------+
# |    phase     |    status      |
# +--------------+----------------+
# | SUBMITTED    | SUCCEEDED      |
# | INSTALL      | SUCCEEDED      |
# | PRE_BUILD    | FAILED         |
# | BUILD        | SKIPPED        |
# | POST_BUILD   | SKIPPED        |
# +--------------+----------------+

# ECSサービスの直近イベントを確認する（デプロイの失敗理由が記録されている）
$ aws ecs describe-services     --cluster myapp-cluster     --services myapp-service     --query 'services[0].events[:5]'     --output table

# ALBターゲットグループのヘルスチェック状態を確認する
$ aws elbv2 describe-target-health     --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/myapp-tg/abcdef123456

# 出力例（Unhealthyの場合）
# {
#   "Target": { "Id": "10.0.1.23", "Port": 80 },
#   "TargetHealth": {
#     "State": "unhealthy",
#     "Reason": "Target.FailedHealthChecks"
#   }
# }