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?

@super-flyers

DVA-C02対策 (Codexx)

0
Posted at

AWS Certified Developer – Associate 試験対策として AWS CodeBuild を整理して説明しますね。

🔹AWS CodeBuild 概要

  • フルマネージド型のビルドサービス
    ソースコードをコンパイルしたり、テストを実行したり、アプリケーションの成果物（artifact）を生成したりするためのサービス。
  • Jenkins のような自前のビルドサーバーを管理せずに、スケーラブルにビルドを実行できる。

🔹特徴

  1. サーバーレス

    • ビルド環境（EC2など）を自分で用意・管理する必要なし。
    • AWS が裏側のコンテナを用意し、リクエストごとに実行。

  2. スケーラビリティ

    • 並列で複数ビルドが走っても自動的にスケール。
    • 待ち行列が発生しにくい。

  3. 従量課金制

    • ビルド時間（分単位）に応じて課金。
    • アイドル時間のコストが不要。

  4. 統合しやすい

    • CodeCommit / GitHub / Bitbucket などからソース取得。
    • CodePipeline と組み合わせて CI/CD を構築可能。

🔹基本の流れ

  1. ソースコードを取得

    • CodeCommit / GitHub / S3 など

  2. buildspec.yml を解釈

    • ビルド手順やコマンドを記述した YAML ファイル

    • 例:

      version: 0.2
phases:
  install:
    commands:
      - echo "installing dependencies"
  build:
    commands:
      - echo "building app"
      - mvn package
artifacts:
  files:
    - target/*.jar

  3. ビルド環境で実行

    • 事前定義された Docker イメージ（Linux / Windows）またはカスタムイメージ。

  4. 成果物を出力

    • S3 / CodePipeline に渡す。

🔹よく問われる試験ポイント

  • buildspec.yml

    • ビルドの命令書。ソースに含める or コンソールに直接記載可能。

  • 環境変数

    • AWS マネジメントコンソール / SSM Parameter Store / Secrets Manager から参照可能。

  • キャッシュ

    • S3 やローカルキャッシュを利用してビルド高速化。

  • ログ出力

    • CloudWatch Logs に保存。トラブルシュートに必須。

  • IAM 権限

    • CodeBuild のサービスロールに S3 / ECR / CloudWatch などへのアクセス権限を付与。

  • コンテナビルド

    • Docker をビルドする場合は 特別な権限 (Privileged mode) を有効化する必要あり。

🔹試験で狙われやすい例題パターン

  1. Docker イメージをビルドして ECR にプッシュしたい → Privileged mode が必要

  2. Secrets Manager の値をビルド環境で使いたい → 環境変数として参照可能

  3. ビルドの依存関係を高速化 → キャッシュ (S3 / ローカル)

  4. CI/CD の構成要素

    • CodeCommit: ソース管理
    • CodeBuild: ビルド
    • CodeDeploy: デプロイ
    • CodePipeline: それらをつなぐパイプライン

👉 試験対策としては「CodeBuild が何を担うか」「buildspec.yml の役割」「Docker ビルドの特殊要件」「IAM 権限まわり」を理解しておくのが重要です。

🔹CodeBuild のビルドプロセスの流れ（フックに相当するもの）

CodeBuild は buildspec.yml を読み取り、以下のフェーズ順に処理を進めます。
（イメージとしては CodeDeploy の「フック」に近い「ライフサイクルフック」）

1. install フェーズ

  • ビルド環境に必要な依存関係をインストール。
  • 例: yum install、SDK、ライブラリなど。
phases:
  install:
    runtime-versions:
      java: corretto11
    commands:
      - echo "Installing dependencies"

2. pre_build フェーズ

  • ビルド前の準備。
  • 例: Docker ログイン、環境変数設定、テストデータ準備など。
  pre_build:
    commands:
      - echo "Logging in to Amazon ECR..."
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin <account-id>.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com

3. build フェーズ

  • 実際のビルド処理。
  • 例: mvn package、npm run build、Docker build。
  build:
    commands:
      - echo "Building the application..."
      - mvn package

4. post_build フェーズ

  • ビルド後の処理。
  • 例: テスト結果のアップロード、Docker イメージのプッシュ、通知処理。
  post_build:
    commands:
      - echo "Pushing Docker image to ECR..."
      - docker push <account-id>.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/my-app:latest

5. artifacts

  • 成果物を指定して出力。
  • S3 に配置、CodePipeline に渡す、など。
artifacts:
  files:
    - target/*.jar

6. cache（オプション）

  • ビルドの効率化のために依存ファイルをキャッシュ。
  • 例: ~/.m2 や node_modules。
cache:
  paths:
    - '/root/.m2/**/*'

🔹フックの流れまとめ（試験用暗記ポイント）

  1. install → 環境準備（依存関係）
  2. pre_build → ビルド前の準備（認証・設定）
  3. build → メイン処理（コンパイル・パッケージ）
  4. post_build → 結果処理（デプロイ準備・アップロード）
  5. artifacts → 成果物出力
  6. cache → 高速化のための依存キャッシュ

👉 試験では「pre_build で Docker ログイン」「post_build で ECR にプッシュ」といった流れを理解しているかがよく問われます。

Developer Associate 試験で混同されやすい CodeBuild のフック（buildspec.yml） と CodeDeploy のフック（appspec.yml） を比較表にまとめました。

🔹CodeBuild と CodeDeploy のフック比較表

サービス 設定ファイル フック（フェーズ）の流れ 役割・用途
CodeBuild buildspec.yml 1. install: 依存関係のインストール
2. pre_build: ビルド前準備（認証・設定など）
3. build: 実際のビルド・テスト
4. post_build: 成果物のアップロード・通知など
5. artifacts: 成果物の指定
6. cache: 高速化のための依存キャッシュ		 CI（ビルド／テスト）を担当
Docker イメージ作成や成果物の出力まで
CodeDeploy appspec.yml EC2/オンプレ環境:
- ApplicationStop
- DownloadBundle
- BeforeInstall
- Install
- AfterInstall
- ApplicationStart
- ValidateService

Lambda:
- BeforeAllowTraffic
- AfterAllowTraffic

ECS:
- BeforeInstall
- AfterInstall
- AllowTestTraffic
- BeforeAllowTraffic
- AfterAllowTraffic		 CD（デプロイ）を担当
アプリをサーバーに配置・開始・検証する

🔹混同しやすい試験ポイント

  • CodeBuild → CI（ビルド工程）。buildspec.yml の install → pre_build → build → post_build の流れ。
  • CodeDeploy → CD（デプロイ工程）。appspec.yml の BeforeInstall → AfterInstall → ValidateService などのライフサイクルフック。
  • Docker イメージを作って ECR にプッシュ → CodeBuild
  • EC2 にアプリをデプロイしてサービス再起動 → CodeDeploy

👉 まとめると、

  • CodeBuild = ソースコードをビルドして成果物をつくる人
  • CodeDeploy = 成果物をサーバーやECSに配置して動かす人

CodeDeploy はデプロイ先によって フック（ライフサイクルイベント）の種類 が変わります。
試験では EC2/オンプレ・Lambda・ECS の違いを問われることが多いので、それぞれの appspec.yml サンプルを紹介します。

🔹1. EC2 / オンプレミス 用 appspec.yml 

version: 0.0
os: linux
files:
  - source: /           # デプロイするファイル（アーティファクト）のパス
    destination: /var/www/html  # 配置先
hooks:
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root
  BeforeInstall:
    - location: scripts/before_install.sh
      timeout: 300
      runas: root
  Install:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root
  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 300
      runas: root

✅ 流れ

  1. 既存アプリを停止（ApplicationStop）
  2. 新しいコード配置前の準備（BeforeInstall）
  3. ファイル配置（Install）
  4. 設定や権限調整（AfterInstall）
  5. サービス起動（ApplicationStart）
  6. 正常性確認（ValidateService）

🔹2. Lambda 用 appspec.yml 

version: 0.0
Resources:
  - myLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: my-function
        Alias: live
        CurrentVersion: 1
        TargetVersion: 2
hooks:
  BeforeAllowTraffic:
    - location: scripts/validate_before.sh
      timeout: 180
  AfterAllowTraffic:
    - location: scripts/validate_after.sh
      timeout: 180

✅ 流れ

  • CodeDeploy が エイリアス（例: live）を新しい Lambda バージョンに切り替える。
  • BeforeAllowTraffic: トラフィック切替前に検証（テスト呼び出しなど）。
  • AfterAllowTraffic: 切替後に追加確認（ログ確認など）。

👉 EC2 と違い「ファイル配置」はなく、バージョンとエイリアス切り替えが主な作業。

🔹3. ECS（Amazon Elastic Container Service） 用 appspec.yml 

version: 0.0
Resources:
  - myECSService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: my-task-def:2
        LoadBalancerInfo:
          ContainerName: my-app
          ContainerPort: 80
hooks:
  BeforeInstall:
    - location: scripts/pre_traffic.sh
      timeout: 180
  AfterInstall:
    - location: scripts/post_install.sh
      timeout: 180
  AllowTestTraffic:
    - location: scripts/allow_test.sh
      timeout: 180
  BeforeAllowTraffic:
    - location: scripts/before_prod.sh
      timeout: 180
  AfterAllowTraffic:
    - location: scripts/after_prod.sh
      timeout: 180

✅ 流れ

  1. 新しいタスク定義を ECS に登録（BeforeInstall, AfterInstall）。
  2. AllowTestTraffic: 新しいタスクにテスト用トラフィックを流す。
  3. BeforeAllowTraffic: 本番切替前に検証。
  4. AfterAllowTraffic: 本番トラフィックを流したあと確認。

👉 Blue/Green デプロイ を想定しており、ALB 経由で段階的にトラフィックを切り替えるのがポイント。

🔹まとめ

  • EC2/オンプレ: サーバーにファイル配置 → サービス起動 → 正常性確認
  • Lambda: 新バージョンのエイリアス切替 → Before/After AllowTraffic で検証
  • ECS: 新しいタスク定義を登録 → テストトラフィック → 本番トラフィック切替

👉 試験では 「どのフックがどのサービスに存在するか」 を問われやすいです。
例:

  • Lambda には ApplicationStart フックは存在しない
  • ECS には AllowTestTraffic フックがある
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?