はじめに

「GitHub Actions は GitHub に依存してしまう。AWS だけで CI/CD を完結させたい」——そんなニーズに応えるのが AWS Code 4 兄弟（CodeCommit・CodeBuild・CodeDeploy・CodePipeline） です。さらに共通ライブラリは AWS CodeArtifact で管理するフルマネージドな AWS CI/CD パイプラインを構築します。

前のハンズオン（EC2 + GitHub Actions）との最大の違いは、すべてが AWS の中で完結することです。ソース管理・ビルド・ライブラリ管理・デプロイ、すべてを AWS サービスで担います。

[CodeCommit リポジトリ] ← git push
         ↓
[CodePipeline: my-cp-pipeline]
  Stage 1: Source  — CodeCommit からソースを取得
  Stage 2: Build   — CodeBuild で mvn package
                        ├─ CodeArtifact から認証トークン取得
                        ├─ common-lib を CodeArtifact に publish
                        ├─ CodeArtifact から common-lib を取得
                        └─ webapp.war を生成
  Stage 3: Deploy  — CodeDeploy で EC2 に配備
                        ├─ Tomcat を停止
                        ├─ WAR を配置
                        └─ Tomcat を再起動
         ↓
[EC2: Tomcat + Spring Boot]  my-cpapp
         ↓
[ALB: my-cp-alb] ← インターネット
         ↓
[RDS MySQL: my-cp-rds]

このハンズオンで体験できること：

• CodeCommit + CodeBuild + CodeDeploy + CodePipeline による完全 AWS CI/CD
• CodeArtifact による Maven ライブラリの社内管理（Maven Central のプロキシも体験）
• buildspec.yml でビルド手順をコード化する
• git-remote-codecommit で AWS CLI 認証のまま CodeCommit に push する
• CloudFormation で全リソース（パイプラインを含む）を一括構築

コード詳細は GitHub を参照してください。

-->

キーワード解説

① 全体構成を理解する

CodeArtifact とは

CodeArtifact は AWS が提供するマネージドな Maven リポジトリです。GitHub Packages との大きな違いの一つが Maven Central のプロキシ機能です。

mvn package
  └─ CodeArtifact (my-cp-libs)
       ├── 社内ライブラリ: com.example:common-utils:1.0.0  ← CodeBuild が publish
       └── 外部ライブラリ: org.springframework.boot:*      ← Maven Central から透過的に取得

外部依存関係も CodeArtifact 経由でキャッシュされるため、インターネット接続なしでも再現性の高いビルドが可能になります。

buildspec.yml の処理フロー

buildspec.yml は CodeBuild が実行するビルド手順を定義します：

phases:
  install:
    runtime-versions:
      java: corretto17    # Amazon Corretto 17 を使用

  pre_build:
    commands:
      # settings.xml に書き込んで Maven 認証を設定
      - CODEARTIFACT_TOKEN=$(aws codeartifact get-authorization-token ...)
      - CODEARTIFACT_URL=$(aws codeartifact get-repository-endpoint ...)

  build:
    commands:
      # common-lib を CodeArtifact に publish（すでに存在する場合はスキップ）
      - mvn deploy -f common-lib/pom.xml -Dcodeartifact.url="$CODEARTIFACT_URL"
      # app の WAR をビルド（CodeArtifact から common-lib を取得）
      - mvn package -f app/pom.xml -DskipTests -Dcodeartifact.url="$CODEARTIFACT_URL"
      - cp app/target/webapp.war webapp.war

artifacts:
  files:
    - webapp.war
    - appspec.yml
    - scripts/**/*   # CodeDeploy のフックスクリプト

ポイント：pom.xml の CodeArtifact URL はプレースホルダー（${codeartifact.url}）で、buildspec.yml が -Dcodeartifact.url= で実行時に渡します。pom.xml を事前に編集する必要はありません。

② CloudFormation スタックを作成する

自分の IP アドレスを確認し（curl https://checkip.amazonaws.com）、CloudFormation でインフラを一括作成します：

aws cloudformation deploy ^
  --template-file ec2-codepipeline/infra/template.yaml ^
  --stack-name my-cpapp-stack ^
  --parameter-overrides EmployeeId=my DBPassword=Handson1234! MyIP=123.456.78.901/32 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --region ap-northeast-1

所要時間：約 10〜15 分（VPC・EC2・RDS の作成に時間がかかります）

CloudFormation スタックが作成するリソース：

③ Outputs を確認する

aws cloudformation describe-stacks ^
  --stack-name my-cpapp-stack ^
  --query "Stacks[0].Outputs" ^
  --output table ^
  --region ap-northeast-1

CodeCommitCloneUrlHttp と ALBEndpoint の値を控えておきます。

④ git-remote-codecommit をインストールする

CodeCommit への push には git-remote-codecommit を使います。AWS CLI の認証情報をそのまま使えるため、Git 専用の認証情報を別途作成する必要がありません：

pip install git-remote-codecommit

インストール後、codecommit:: プレフィックスの URL で clone・push が可能になります。

⑤ ソースコードを CodeCommit に push する

⑤-1 CodeCommit リポジトリを clone する

git clone codecommit::ap-northeast-1://my-cpapp %TEMP%\my-cpapp

codecommit:: プレフィックスを使うことで、AWS CLI の認証情報が自動的に使われます（認証プロンプトは出ません）。

⑤-2 ソースコードをコピーして push する

xcopy ec2-codepipeline\* %TEMP%\my-cpapp\ /E /I /H /Y
cd %TEMP%\my-cpapp

git add .
git commit -m "initial commit"
git branch -M main
git push origin main

push が完了すると CodePipeline が自動的に起動します。

⑥ CodePipeline の動作を確認する

AWS コンソール → CodePipeline → my-cp-pipeline

3 つのステージが順番に実行されます：

合計：約 8〜10 分

⑦ CodeBuild のログを確認する

AWS コンソール → CodeBuild → my-cpapp-build → 「ビルド履歴」タブ

ビルド実行をクリックするとインラインログが確認できます。以下が表示されれば正常です：

=== CodeArtifact 認証トークン取得 ===
CodeArtifact URL = https://my-domain-XXXX.d.codeartifact.ap-northeast-1.amazonaws.com/maven/my-libs/
Maven settings.xml 生成完了
=== common-lib を CodeArtifact に publish ===
[INFO] BUILD SUCCESS
=== webapp WAR をビルド ===
[INFO] BUILD SUCCESS
=== デプロイパッケージを準備 ===
ビルド完了

CodeArtifact の認証トークンは 12 時間有効な一時トークンです。有効期限が切れても次のビルド時に自動取得されるため、管理の手間がありません。

⑧ CodeDeploy の状況を確認する

AWS コンソール → CodeDeploy → アプリケーション → my-cpapp → デプロイグループ → 最新のデプロイメント

各フックスクリプト（stop_server → install → start_server → validate_service）の実行結果が確認できます。デプロイが失敗した場合はここでエラー詳細を確認します。

⑨ アプリの動作確認をする

パイプラインが成功したら ALB 経由でアクセスします：

curl http://<ALBEndpoint の値>/api/health
rem → {"status":"ok","message":null,"data":"OK"}

curl http://<ALBEndpoint の値>/api/items
rem → {"status":"ok","message":null,"data":[]}

ブラウザで ALBEndpoint にアクセスするとアイテム管理 UI が表示されます。

⑩ CI/CD サイクルを体験する

CodeCommit にコードを push するだけでパイプラインが自動実行される CI/CD を体験します：

cd %TEMP%\my-cpapp

app\src\main\resources\templates\index.html を開いてタイトルを変更します：

<!-- 変更後 -->
<h1>Spring Boot + RDS Item Manager (EC2 v2) <span class="badge">CodePipeline</span></h1>

git add app\src\main\resources\templates\index.html
git commit -m "feat: update title to EC2 v2"
git push origin main

CodePipeline コンソール（my-cp-pipeline）で全ステージが成功になるまで待ちます（約 8〜10 分）。ALB にアクセスしてタイトルが変わっていることを確認します。

⑪ CodeArtifact のパッケージを確認する

AWS コンソール → CodeArtifact → ドメイン my-domain → リポジトリ my-libs → パッケージ一覧

com.example:common-utils:1.0.0 が登録されていることを確認します。CLI でも確認できます：

aws codeartifact list-packages ^
  --domain my-domain ^
  --domain-owner 123456789012 ^
  --repository my-libs ^
  --region ap-northeast-1

また、Maven Central のプロキシとして機能しているため、org.springframework.boot なども一覧に表示されます。これらは外部から初回取得時にキャッシュされたものです。

⑫ SSM Session Manager で EC2 に接続する（オプション）

キーペアなしで EC2 内部を確認できます：

aws ssm start-session ^
  --target i-xxxxxxxxxxxxxxxxx ^
  --region ap-northeast-1

# Tomcat のステータス確認
sudo systemctl status tomcat

# CodeDeploy エージェントのログ確認
sudo cat /var/log/aws/codedeploy-agent/codedeploy-agent.log

# SSM から取得した DB 接続情報の確認
sudo cat /opt/tomcat/current/bin/setenv.sh

# Tomcat ログの確認
sudo journalctl -u tomcat -n 50

⑬ リソースを削除する

CodeArtifact にパッケージが存在するとドメインが削除できないため、先にパッケージを手動削除します。

① CodeArtifact のパッケージを削除する

aws codeartifact delete-package-versions ^
  --domain my-domain ^
  --domain-owner 123456789012 ^
  --repository my-libs ^
  --format maven ^
  --namespace com.example ^
  --package common-utils ^
  --versions 1.0.0 ^
  --region ap-northeast-1

aws codeartifact delete-package ^
  --domain my-domain ^
  --domain-owner 123456789012 ^
  --repository my-libs ^
  --format maven ^
  --namespace com.example ^
  --package common-utils ^
  --region ap-northeast-1

② S3 バケットを空にする

aws cloudformation describe-stacks ^
  --stack-name my-cpapp-stack ^
  --query "Stacks[0].Outputs[?OutputKey=='ArtifactBucketName'].OutputValue" ^
  --output text ^
  --region ap-northeast-1

aws s3 rm s3://<ArtifactBucketName の値> --recursive

③ CloudFormation スタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-cpapp-stack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-cpapp-stack ^
  --region ap-northeast-1

echo 削除完了

④ ローカルの clone ディレクトリを削除する

rmdir /S /Q %TEMP%\my-cpapp

まとめ：学んだ概念

GitHub Actions を使った前のハンズオンと比較すると、CodePipeline は すべてが AWS 内で完結する一方、GitHub Actions は Git リポジトリと AWS の柔軟な組み合わせが強みです。どちらを使うかはチームの方針や既存インフラに合わせて選択しましょう。

次のステップとして、CDK + ECS Fargate ハンズオンで EC2 からコンテナ化への移行も体験してみましょう。

The post EC2 + CodePipeline（Code 3兄弟）で WebアプリをCI/CDデプロイする【完全 AWS CI/CD 体験】 first appeared on CayTech Lab.

はじめに

「インフラは AWS でいいけど、デプロイは GitHub Actions でやりたい」——クラウドと Git を組み合わせたハイブリッドな CI/CD 構成は、多くの現場で採用されています。このハンズオンでは、EC2（Tomcat）への自動デプロイを GitHub Actions + AWS CodeDeploy で実現します。

さらに実務でよく見かける「社内共通ライブラリを GitHub Packages で管理・共有する」仕組みも体験できます。Spring Boot WAR をビルドする際に共通ライブラリを GitHub Packages からフェッチし、CodeDeploy で EC2 にデプロイするまでの一連のフローです。

[GitHub リポジトリ]
  ├── common-lib/ → push → GitHub Actions → GitHub Packages に publish
  └── app/        → push → GitHub Actions
                               ├── GitHub Packages から common-utils を取得
                               ├── mvn package → webapp.war
                               ├── zip → S3 にアップロード
                               └── CodeDeploy を呼び出す
                                        ↓
                          [EC2: Tomcat + Spring Boot WAR]  my-ec2app
                                        ↓
                          [ALB: my-ec2app-alb] ← インターネット
                                        ↓
                          [RDS MySQL: my-ec2app-rds]

このハンズオンで体験できること：

• GitHub Packages を使った共通ライブラリの管理・共有
• GitHub Actions（OIDC 認証）で AWS にキーレスアクセス
• CodeDeploy + appspec.yml を使った EC2 へのデプロイ自動化
• SSM Parameter Store でデータベースパスワードを安全に管理
• CloudFormation によるインフラ一括構築（VPC / EC2 / ALB / RDS / CodeDeploy）

コード詳細は GitHub を参照してください。

-->

キーワード解説

① 全体構成を理解する

このハンズオンの主役は 2 つのワークフローです。

①-1 common-lib のパブリッシュ（ec2-publish-lib.yml）

common-lib/ が変更されると起動し、Maven ライブラリを GitHub Packages に publish します。actions/setup-java が settings.xml を自動生成するため、認証設定は不要です。

①-2 アプリのデプロイ（ec2-app-deploy.yml）

app/ が変更されると起動します。処理の流れは次の通りです：

① OIDC で AWS に認証
② GitHub Packages から common-utils を取得しながら mvn package で WAR をビルド
③ zip 化して S3 にアップロード（webapp.war + appspec.yml + scripts/）
④ CodeDeploy でローリングデプロイ（〜1〜2 分）

デプロイパッケージの構造：

deploy.zip
├── webapp.war         ← Tomcat の webapps/ に配置
├── appspec.yml        ← CodeDeploy の設定
└── scripts/
    ├── stop_server.sh      ← Tomcat を停止・古い WAR を削除
    ├── start_server.sh     ← SSM から DB 情報を取得・Tomcat 起動
    └── validate_service.sh ← /api/health を最大 60 秒リトライ確認

② OIDC 認証と IAM ロールを設定する

GitHub Actions が AWS に安全にアクセスするための OIDC（OpenID Connect）認証 を設定します。アクセスキーをリポジトリに保存せずに AWS を操作できる現代的な方式です。

②-1 OIDC プロバイダーを登録する（初回のみ）

AWS コンソール → IAM → 「IDプロバイダー」→「プロバイダーを追加」

ECS ハンズオン（cdk-ecs-webapp）完了済みの場合はスキップ可。

②-2 IAM ロールを作成する

AWS CloudShell で以下を実行します（GITHUB_OWNER と REPO は自分のリポジトリに合わせて変更）：

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
GITHUB_OWNER="your-github-username"   # ← 自分の GitHub ユーザー名
REPO="your-github-repo"               # ← 自分の GitHub リポジトリ名
EMPLOYEE_ID="my"                      # ← 好きなプレフィックス（例: 123456）
ROLE_NAME="${EMPLOYEE_ID}-github-actions-role"

cat > /tmp/trust-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      },
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:${GITHUB_OWNER}/${REPO}:ref:refs/heads/main"
      }
    }
  }]
}
EOF

aws iam create-role \
  --role-name $ROLE_NAME \
  --assume-role-policy-document file:///tmp/trust-policy.json

# 権限ポリシーを付与（S3 + CodeDeploy）
cat > /tmp/permissions.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::${EMPLOYEE_ID}-ec2app-deploy-*/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "codedeploy:CreateDeployment",
        "codedeploy:GetDeployment",
        "codedeploy:GetDeploymentConfig",
        "codedeploy:RegisterApplicationRevision"
      ],
      "Resource": "*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name $ROLE_NAME \
  --policy-name "${ROLE_NAME}-policy" \
  --policy-document file:///tmp/permissions.json

# ロール ARN を表示
aws iam get-role --role-name $ROLE_NAME --query Role.Arn --output text

出力された ロール ARN（arn:aws:iam::...）をコピーしておきます。

③ GitHub Variables を設定する

GitHub リポジトリ → Settings → Secrets and variables → Actions → 「Variables」タブ

「New repository variable」で以下を追加します：

Variables vs Secrets：ARN や ID は機密情報ではないため Variables に保存します（パスワード類は Secrets を使う）。

④ CloudFormation スタックを作成する

自分の IP アドレスを確認し（curl https://checkip.amazonaws.com）、CloudFormation でインフラを一括作成します：

aws cloudformation deploy ^
  --template-file ec2-github-actions/infra/template.yaml ^
  --stack-name my-ec2app ^
  --parameter-overrides EmployeeId=my DBPassword=Handson1234! MyIP=123.456.78.901/32 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --region ap-northeast-1

所要時間：約 10〜15 分（RDS の作成に時間がかかります）

CloudFormation スタックが作成するリソース：

⑤ スタックの Outputs を確認する

aws cloudformation describe-stacks ^
  --stack-name my-ec2app ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs" ^
  --output table

⑥ common-lib を GitHub Packages に publish する

common-lib/pom.xml と app/pom.xml にある GitHub ユーザー名・リポジトリ名のプレースホルダーを自分のものに変更してから push します：

<!-- common-lib/pom.xml と app/pom.xml の両方を変更 -->
<url>https://maven.pkg.github.com/your-github-username/your-github-repo</url>

変更を push すると Publish common-utils to GitHub Packages ワークフローが自動起動します：

cd C:\my-aws\aws-learning-projects
git add ec2-github-actions/common-lib/ ec2-github-actions/app/pom.xml
git commit -m "feat: configure GitHub Packages URL for ec2-github-actions"
git push

GitHub リポジトリ → Actions タブ → Publish common-utils to GitHub Packages の実行を確認します。完了後、Packages タブに common-utils 1.0.0 が表示されます。

ResponseWrapper クラスとは：このハンズオンの共通ライブラリは API レスポンスを {"status":"ok","data":{...}} の統一形式にラップするユーティリティです。チーム開発でレスポンス形式を統一する際によく使われるパターンです。

⑦ アプリを初回デプロイする

app/ の変更を push して Deploy App to EC2 ワークフローを起動します：

cd C:\my-aws\aws-learning-projects
git add ec2-github-actions/app/
git commit -m "feat: initial deploy via GitHub Actions (EC2)"
git push

nothing to commit と表示された場合：index.html に空白行を追加して変更を作ります：

echo. >> ec2-github-actions\app\src\main\resources\templates\index.html
git add ec2-github-actions/app/src/main/resources/templates/index.html
git commit -m "chore: trigger initial deploy"
git push

⑧ GitHub Actions の進行を確認する

GitHub → Actions タブ → Deploy App to EC2 で各ステップの実行状況を確認します：

合計：約 3〜5 分

ポイントは 「Set up Java」ステップです。actions/setup-java に server-id: github を指定するだけで、GitHub Packages の認証情報を含む settings.xml が自動生成されます。Maven のパスワード設定を手書きする必要はありません。

⑨ ブラウザで動作確認する

ALBEndpoint の URL にアクセスすると「Spring Boot + RDS Item Manager (EC2)」が表示されます。

/api/health にアクセスして以下が返ることも確認します：

{"status":"ok","message":null,"data":"OK"}

このレスポンス形式こそが common-utils の ResponseWrapper が GitHub Packages 経由で取得・ビルドされた証拠です。

⑩ CI/CD サイクルを体験する

index.html のタイトルを変更して push すると、約 3〜5 分でブラウザに反映されます：

<!-- 変更後 -->
<h1>Spring Boot + RDS Item Manager (EC2 v2) <span class="badge">GitHub Actions</span></h1>

git add ec2-github-actions/app/src/main/resources/templates/index.html
git commit -m "feat: update title to EC2 v2"
git push

これが CI/CD の醍醐味です。コードを push するだけで自動的にデプロイが完了します。

⑪ SSM Session Manager で EC2 に接続する（オプション）

キーペアなしで EC2 内部を確認できます：

aws ssm start-session ^
  --target i-xxxxxxxxxxxxxxxxx ^
  --region ap-northeast-1

# Tomcat のステータス確認
sudo systemctl status tomcat

# デプロイログの確認
sudo cat /var/log/aws/codedeploy-agent/codedeploy-agent.log

# SSM から取得した DB 接続情報の確認
sudo cat /opt/tomcat/current/bin/setenv.sh

# Tomcat ログの確認
sudo journalctl -u tomcat -n 50

setenv.sh を確認すると、SSM Parameter Store から取得した DB ホスト名とパスワードが環境変数としてセットされていることがわかります。パスワードをコードに書かずに安全に注入できています。

⑫ リソースを削除する

① S3 バケットを空にする（デプロイアーティファクトが蓄積されているため先に削除）

aws s3 rm s3://my-ec2app-deploy-123456789012 --recursive

② CloudFormation スタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-ec2app ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-ec2app ^
  --region ap-northeast-1

echo スタック削除完了

まとめ：学んだ概念

GitHub Actions と AWS を組み合わせることで、Git push だけでインフラから独立してアプリをデプロイできる柔軟な CI/CD パイプラインを構築できます。次のステップとして、EC2 + CodePipeline ハンズオンで完全 AWS ネイティブな CI/CD も体験してみましょう。

The post EC2 + GitHub Actions で WebアプリをCI/CDデプロイする【GitHub Packages + CodeDeploy 体験】 first appeared on CayTech Lab.