実践 CI/CD クラウドインフラ構築・運用省力化

2025-10-20

実践 CI/CD クラウドインフラ構築・運用省力化

記事をシェアする

はじめに

私はTerraformを用いたクラウドインフラ構築・GitHubによるコード管理や、IaaS上の仮想サーバー設定の業務を担当しています。
この記事では、私が担当する業務で発生する課題と、その対応策としてのGitHub Actionsを用いたCI/CD実装例をご紹介します。

※ ご紹介するGitHub Actionsのワークフロー実装例には、サードパーティ製のアクションが含まれています。
サードパーティ製のアクションはサプライチェーン攻撃の対象となるケースがあります。
利便性とセキュリティリスクのトレードオフを認識したうえで活用する必要があります。

課題

Terraformを用いたクラウドインフラ構築・GitHubによるコード管理やIaaS上の仮想サーバー設定の業務では、以下3つの課題が発生し得ます。

PullRequest(PR)でのコミュニケーション

PR上では、レビュアーとレビュイーがコミュニケーションを取りながら、コードの変更内容や意図について認識を合わせる必要があります。
PRのテンプレートを用意して記載ルールを整備する方法もありますが、担当者ごとに説明の粒度や精度が異なります。
レビュイーがどの観点でセルフチェックを行ったのか、レビュアーにどこを重点的に確認して欲しいのかが読み取れないケースも少なくありません。
その結果、コミュニケーションに摩擦が生じ、関係性が悪化してしまうこともあります。

`terraform plan`の実行結果を取得する

PRを作成・レビューする際には、terraform planの実行結果が適切であることを確認することが必須となります。
しかし、PRのたびに手作業でterraform planを実行して結果を添付するのは大きな負担となりがちです。
作業の過程で誤ってterraform applyを実行してしまうといったヒューマンエラーのリスクも発生します。

サーバーに対する手動操作

特に運用フェーズでは、各種サーバーにログインして様々なコマンドを実行する必要があります。
事前に検証済みのコマンドであっても、接続先の指定ミスや実行順の誤りといったヒューマンエラーの余地が残されています。

また、サーバー管理のためにクライアントソフトなどのツールを利用する場合、多くの場合は接続元として踏み台サーバーを用意します。
踏み台サーバーは作業用環境であることから「必要なツールをすぐに導入したい」という要望も多く、勝手に設定を変更されてしまうこともあります。
災害対策やセキュリティ対策、保守運用などの維持コストも発生します。

以降、それぞれ以下を例に取って、各種課題の軽減につながるCI/CDの仕組みをご紹介します。

Terraformによるインフラ構築：AWSを用いた基盤構築
サーバーに対する手動操作：AWS環境でのDBマイグレーション作業

対応策

各課題に対して、それぞれ以下の対応策をご紹介します。

課題：PullRequest(PR)でのコミュニケーション
- 対応策：PRの内容の説明や確認観点の抽出をAIに補助してもらう
課題：terraform planの実行結果を取得する
- 対応策：PRを契機に自動的にterraform planを実行する
課題：サーバーに対する手動操作
- 対応策：git pushを契機に自動的にECSタスクを起動してコマンドを実行する

対応策の全体像

構成図

arch_all

GitHub設定

ディレクトリ構成

1
GitHubリポジトリー/
2
      ├── .github/
3
      |   ├── workflows/
4
      |   |   ├── pr_agent.yml
5
      |   |   ├── tf_fmt.yml
6
      |   |   ├── tf_plan.yml
7
      |   |   └── db_migrate.yml
8
      |   └── actions/
9
      |       ├── call_aws_step_functions
10
      |       |   └── action.yml
11
      |       └── generate_aws_credential_string
12
      |           └── action.yml
13
      └── environments/
14
          └── dev/
15
              ├── docker/
16
              |   ├── app/
17
              |   |   ├── prisma/
18
              |   |   |   ├── .env
19
              |   |   |   └── schema.prisma
20
              |   |   └── migrate.sh
21
              |   └── Dockerfile
22
              ├── lambda_function/
23
              |   └── index.js
24
              ├── main.tf
25
              └── terraform.tf

シークレット設定

1
Repository secrets
2
    ├── OPENAI_KEY
3
    ├── AWS_BACKEND_EXTERNAL_ID
4
    ├── AWS_BACKEND_ROLE_ARN
5
    ├── AWS_DEPLOY_EXTERNAL_ID
6
    ├── AWS_DEPLOY_ROLE_ARN
7
    ├── AWS_ROLE_ARN
8
    ├── DB_MGR_ECR_IMAGE_TAG
9
    ├── DB_MGR_ECR_REGISTRY
10
    ├── DB_MGR_ECR_REPOSITORY
11
    ├── DB_MGR_ROLE_ARN
12
    ├── DB_MGR_ROLE_EXTERNAL_ID
13
    └── DB_MGR_SFN_ARN

以降、個々の対応策の詳細についてご紹介します。

対応策：PRの内容の説明や確認観点の抽出をAIに補助してもらう

PR-Agent ⧉というツールを使用して、AIによるフィードバックを実現します。
利用するAIは、OpenAI、Azure OpenAI、Amazon Bedrockなどの中からユーザーが選択できます。
AIの利用には別途料金が発生しますが、PR-Agent自体は無料で使用することができます。

レビュイーはAIによるフィードバックを受けて、セルフチェックの質を高めた上でレビューを依頼します。
レビュアーはAIによるフィードバックを参考にして、レビューの観点を考えることができます。

構成図

arch_pr_agent

対応策導入後のシーケンス

展開

  sequenceDiagram
      actor レビュイー
      participant GitHub as GitHub
Repository
      participant pr_agent as pr_agent
(GHA)
      participant OpenAI
      actor レビュアー

      %% 初回プッシュとPR作成
      rect rgba(224,242,254,0.3)
      note over レビュイー,GitHub: 初回プッシュとPR作成
      レビュイー ->> GitHub: Terraformコードをgit push
      レビュイー ->> GitHub: PRを作成
      GitHub ->> pr_agent: PR作成イベント通知
      end

      %% PR-Agent によるレビュー
      rect rgba(224,242,254,0.3)
      note over pr_agent,OpenAI: PR-Agent によるレビュー
      pr_agent ->> OpenAI: PRの内容を送信して分析
      OpenAI ->> pr_agent: 概要・難易度・レビューコメント
      Note left of pr_agent: PR内容の説明や確認観点をAIで補助
      pr_agent ->> GitHub: レビューコメントを投稿
      GitHub ->> レビュイー: コメント通知

      loop 1, PR-Agentによる指摘数
          レビュイー ->> GitHub: レビュー結果を確認
          alt 修正が必要
              レビュイー ->> レビュイー: Terraformコードを修正
              レビュイー ->> GitHub: Terraformコードをgit push
              GitHub ->> pr_agent: PR更新イベント通知
              pr_agent ->> OpenAI: レビュー依頼
              OpenAI ->> pr_agent: レビューコメント
              pr_agent ->> GitHub: レビューコメントを更新
              GitHub ->> レビュイー: コメント通知
          else 修正不要
              レビュイー ->> GitHub: 修正不要である旨コメントを投稿
          end
      end
      end

      %% レビュアーによるレビュー
      rect rgba(224,242,254,0.3)
      note over レビュイー,レビュアー: レビュアーによるレビュー
      レビュイー ->> レビュアー: レビュー依頼
      レビュアー ->> GitHub: PRを確認

      alt 指摘事項あり
          レビュアー ->> GitHub: レビュー指摘コメント投稿
          GitHub ->> レビュイー: コメント通知

          loop 1, 指摘事項の数
              レビュイー ->> GitHub: レビュー結果を確認
              レビュイー ->> レビュイー: Terraformコードを修正
              レビュイー ->> GitHub: Terraformコードをgit push
              レビュイー ->> レビュアー: レビュー依頼
              レビュアー ->> GitHub: 指摘が解消されたことを確認
          end
      end

      レビュアー ->> GitHub: PRを承認
      end

導入方法

1. OpenAIのAPIキーを発行する@OpenAI

前提
- PR-AgentからAIにアクセスするためにAPIキーが必要です。
- Azure OpenAIやAmazon Bedrockも使用可能ですが、この記事ではOpenAIを使用することとします。
  - 様々なモデルに対応していますが、以下のドキュメントに記載の通り、2025年10月現在ではデフォルトでGPT-5が使用されます。
    - https://qodo-merge-docs.qodo.ai/usage-guide/changing_a_model/ ⧉
  - 以降の手順は、OpenAIのアカウントを取得済みであることを前提とします。

以下にてAPIキーを発行する
- https://platform.openai.com/api-keys ⧉
OpenAIの支払い情報を設定する
- OpenAIのAPIキーを使用するためには、課金が必要なので以下の画面から支払い情報の設定を行います。
  - https://platform.openai.com/settings/organization/billing/overview ⧉

2. 取得したAPIキーをGitHubリポジトリーのシークレットに登録する@GitHub Repository

取得したAPIキーをGitHubリポジトリーのシークレットOPENAI_KEYに設定する

3. PR-Agentを実行するワークフローを作成する@GitHub Repository

以下のドキュメントを参照し、PR-Agentを実行するワークフローを作成する

https://qodo-merge-docs.qodo.ai/installation/github/#run-as-a-github-action ⧉

今回は、.github/workflows/pr_agent.ymlを以下のように設定しました。

.github/workflows/pr_agent.yml

1
name: Pr Agent
2

3
on:
4
  pull_request:
5
  issue_comment:
6

7
jobs:
8
  pr_agent_job:
9
    if: ${{ github.event.sender.type != 'Bot' }}
10
    runs-on: ubuntu-latest
11
    permissions:
12
      issues: write
13
      pull-requests: write
14
      contents: write
15
    name: Run pr agent on every pull request, respond to user comments
16

17
    steps:
18
      - name: PR Agent action step
19
        id: pragent
20
        uses: qodo-ai/pr-agent@main
21
        env:
22
          OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
23
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
24
          github_action_config.auto_review: "true"
25
          github_action_config.auto_describe: "true"
26
          github_action_config.auto_improve: "true"
27
          github_action_config.pr_actions: '["opened", "reopened", "ready_for_review", "review_requested", "synchronize"]'

使用感

PR作成時には"example"というコメントしか記載していない

github_create_pr

PR Agentによる変更内容の要約が追記される

github_created_pr github_change_walkthrough

タイポを含むコードをpushした場合

pragent_code_suggest_detail_typo

機密情報を含むコードをpushした場合

pragent_code_suggest_detail_sensitive

パラメーターを設定することで、PR-Agentによるコメントを日本語化することができます。

.github/workflows/pr_agent.ymlの設定で、PR-Agentによるコメントを日本語化する

1
name: Pr gent
2

3
on:
4
  pull_request:
5
  issue_comment:
6

7
jobs:
8
  pr_agent_job:
9
  if: ${{ github.event.sender.type != 'Bot' }}
10
  runs-on: ubuntu-latest
11
  permissions:
12
      issues: write
13
      pull-requests: write
14
      contents: write
15
  name: Run pr agent on every pull request, respond to user comments
16

17
  steps:
18
    - name: PR Agent action step
19
      id: pragent
20
      uses: qodo-ai/pr-agent@main
21
      env:
22
        OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
23
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
24
        github_action_config.auto_review: "true"
25
        github_action_config.auto_describe: "true"
26
        github_action_config.auto_improve: "true"
27
        github_action_config.pr_actions: '["opened", "reopened", "ready_for_review", "review_requested", "synchronize"]'
28
        CONFIG.RESPONSE_LANGUAGE: 'ja-JP' # 日本語化のための設定

日本語によるコメント

pragent_japanese_comment

効果

本対応策を導入すると、開発効率を向上させるのに十分なクオリティのコメントが素早く自動的に生成されます。
結果として、レビュアーとレビュイーの間にAIが入り込み、コミュニケーションの摩擦が軽減されます。

対応策：PRを契機に自動的に`terraform plan`を実行する

PRの作成や変更のタイミングで、GitHub Actionsから自動的にterraform planを実行します。

構成図

arch_auto_tf_plan

対応策導入後のシーケンス

展開

  sequenceDiagram
      actor 作業者
      participant GitHub as GitHub
Repository
      participant tf_fmt as tf_fmt
(GHA)
      participant tf_plan as tf_plan
(GHA)
      participant AWS

      %% 初回プッシュとPR作成
      rect rgba(224,242,254,0.3)
      note over 作業者,GitHub: 初回プッシュとPR作成
      作業者 ->> GitHub: Terraformコードをgit push
      作業者 ->> GitHub: PRを作成
      end

      %% Terraform plan 自動実行
      rect rgba(224,242,254,0.3)
      note over GitHub,AWS: Terraform plan 自動実行

      par terraform fmt
          GitHub ->> tf_fmt: PR作成イベント通知
          tf_fmt ->> tf_fmt: terraform fmt
          tf_fmt ->> GitHub: terraform fmt結果コメントを投稿
      and terraform plan
          GitHub ->> tf_plan: PR作成イベント通知
          tf_plan ->> AWS: terraform plan
          Note left of tf_plan: PRを契機に自動的に
`terraform plan`を実行
          tf_plan ->> GitHub: terraform plan結果コメントを投稿
      end
      end

      %% Terraform plan 自動実行結果確認
      rect rgba(224,242,254,0.3)
      note over GitHub,作業者: 結果確認
      GitHub ->> 作業者: コメント通知
      作業者 ->> GitHub: コメント確認
      end

導入方法

1. OIDC providerを作成する@AWSアカウント

以下のドキュメントを参照し、AWS IAMにてOIDC providerを作成する
- https://docs.github.com/ja/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services ⧉
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html ⧉

今回は以下のように設定しました。

2. IAMロールを作成する@AWSアカウント

GitHub ActionsにてAssumeRoleするIAMロールを作成する

以下のドキュメントを参考にIAMロールを作成します。
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html#idp_oidc_Create_GitHub ⧉
GitHub ActionsからAssumeRoleするIAMロールには、Terraformのバックエンドへのアクセスやデプロイに使用するIAMロールとStepFunctions実行用IAMロールへのスイッチロールを許可します。
- GitHub Actionsのワークフロー内でAWS Profileを設定することで、それぞれのIAMロールにスイッチロールします。
- OIDC providerを作成するAWSアカウントとTerraformでAWSリソースをデプロイしたいAWSアカウントが異なる場合もあるかと思いますので、このような方式にしています。

今回は以下のように設定しました。

※ 各種ポリシーの内容は必要に応じて絞り込みや追加を行う必要があります。

IAM Role 信頼ポリシー許可ポリシー

IAM Role	信頼ポリシー	許可ポリシー
AWS_ROLE GitHub Actions が OIDC により AssumeRole	展開 `{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWSAccountId}: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:${GitHubOrganizationName}/${GitHubRepositoryName}:*" } } } ] }`	展開 `{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "${AWS_BACKEND_ROLEのARN}", "${AWS_DEPLOY_ROLEのARN}", "${AWS_MGR_ROLEのARN}" ] } }`
AWS_BACKEND_ROLE Terraform バックエンド用 S3	展開 `{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "${AWS_ROLEのARN}" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "${外部ID}" } } } ] }`	展開 `AmazonS3FullAccess`
AWS_DEPLOY_ROLE AWS リソースデプロイ用	展開 `{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "${AWS_ROLEのARN}" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "${外部ID}" } } } ] }`	展開 `AmazonS3FullAccess`

AWS_ROLE
GitHub Actions が OIDC により AssumeRole

展開

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Federated": "arn:aws:iam::${AWSAccountId}: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:${GitHubOrganizationName}/${GitHubRepositoryName}:*"
          }
        }
      }
    ]
  }

展開

{
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "${AWS_BACKEND_ROLEのARN}",
        "${AWS_DEPLOY_ROLEのARN}",
        "${AWS_MGR_ROLEのARN}"
      ]
    }
  }

AWS_BACKEND_ROLE
Terraform バックエンド用 S3

展開

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "${AWS_ROLEのARN}"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "sts:ExternalId": "${外部ID}"
          }
        }
      }
    ]
  }

展開

AmazonS3FullAccess

AWS_DEPLOY_ROLE
AWS リソースデプロイ用

展開

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "${AWS_ROLEのARN}"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "sts:ExternalId": "${外部ID}"
          }
        }
      }
    ]
  }

展開

AmazonS3FullAccess

3. 作成したIAMロールの情報をGitHubリポジトリーのシークレットに登録する@GitHub Repository

各種IAMロールのARNと外部IDについて、以下のGitHubリポジトリーのシークレットに設定する
- AWS_ROLE_ARN：AWS_ROLEのARN
- AWS_BACKEND_ROLE_ARN：AWS_BACKEND_ROLEのARN
- AWS_BACKEND_EXTERNAL_ID：AWS_BACKEND_ROLEの外部ID
- AWS_DEPLOY_ROLE_ARN：AWS_DEPLOY_ROLEのARN
- AWS_DEPLOY_EXTERNAL_ID：AWS_DEPLOY_ROLEの外部ID

4. terraform fmtと修正提案を実行するワークフローを作成する@GitHub Actions

以下のページを参照して、terraform fmt実行と提案を自動化します。
- https://github.com/reviewdog/action-terraform-validate ⧉

今回は、.github/workflows/tf_fmt.ymlを以下のように設定しました。

.github/workflows/tf_fmt.yml

1
name: Terraform fmt
2

3
on:
4
  pull_request:
5

6
env:
7
  TF_VERSION: 1.12.1
8

9
permissions:
10
  id-token: write
11
  contents: read
12
  pull-requests: write
13

14
jobs:
15
  fmt:
16
    name: Terraform fmt
17
    runs-on: ubuntu-latest
18

19
    steps:
20
      - name: Check out repository
21
        uses: actions/checkout@v4
22
        with:
23
          ref: ${{ github.event.pull_request.head.sha }}
24

25
      - name: Setup Terraform
26
        uses: hashicorp/setup-terraform@v3
27
        with:
28
          terraform_version: ${{ env.TF_VERSION }}
29

30
      - name: Terraform fmt
31
        run: terraform fmt -recursive
32

33
      - name: suggest
34
        uses: reviewdog/action-suggester@v1
35
        with:
36
          toolname: terraform fmt
37
          fail_on_error: true

5. terraform planを実行するワークフローを作成する@GitHub Actions

terraform planの実行を自動化します。

今回は、以下のように設定しました。

.github/workflows/tf_plan.yml

1
name: Terraform plan
2

3
on:
4
  pull_request:
5

6
env:
7
  TF_VERSION: 1.12.1
8
  AWS_DEFAULT_REGION: ap-northeast-1
9

10
permissions:
11
  id-token: write
12
  contents: read
13
  pull-requests: write
14
  issues: write
15

16
jobs:
17
  tf_plan:
18
    name: Terraform plan
19
    runs-on: ubuntu-latest
20
    strategy:
21
      matrix:
22
        workdir:
23
          - environments/dev
24

25
    steps:
26
      - name: Git checkout
27
        uses: actions/checkout@v4
28
        with:
29
          ref: ${{ github.event.pull_request.head.sha }}
30

31
      - name: Generate aws Backend credential string
32
        id: gen_aws_backend_cred_str
33
        uses: ./.github/actions/generate_aws_credential_string
34
        with:
35
          profile: "terraform-backend"
36
          aws_role_arn: ${{ secrets.AWS_BACKEND_ROLE_ARN }}
37
          aws_role_external_id: ${{ secrets.AWS_BACKEND_EXTERNAL_ID }}
38

39
      - name: Generate aws deploy credential string
40
        id: gen_aws_deploy_cred_str
41
        uses: ./.github/actions/generate_aws_credential_string
42
        with:
43
          profile: "terraform-deploy"
44
          aws_role_arn: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
45
          aws_role_external_id: ${{ secrets.AWS_DEPLOY_EXTERNAL_ID }}
46

47
      - name: Write aws credential string
48
        run: |
49
          mkdir -p $HOME/.aws
50
          echo "${{ steps.gen_aws_backend_cred_str.outputs.aws_credential }}" >> $HOME/.aws/config
51
          echo "${{ steps.gen_aws_deploy_cred_str.outputs.aws_credential }}" >> $HOME/.aws/config
52

53
      - name: Get aws credential
54
        uses: aws-actions/configure-aws-credentials@v4
55
        with:
56
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
57
          role-session-name: iar-gha-con-${{ github.run_id }}
58
          aws-region: ${{ env.AWS_DEFAULT_REGION }}
59

60
      - run: aws sts get-caller-identity
61

62
      - name: Setup Terraform
63
        uses: hashicorp/setup-terraform@v3
64
        with:
65
          terraform_version: ${{ env.TF_VERSION }}
66

67
      - name: Setup tfcmt
68
        env:
69
          GH_TOKEN: ${{ github.token }}
70
        run: |
71
          gh release download -R suzuki-shunsuke/tfcmt v4.14.4 -p tfcmt_linux_amd64.tar.gz
72
          tar -xzf tfcmt_linux_amd64.tar.gz
73
          sudo mv tfcmt /usr/local/bin/tfcmt
74
          tfcmt --version
75

76
      - name: Terraform init
77
        run: terraform init
78
        working-directory: ${{ matrix.workdir }}
79

80
      - name: Terraform validate
81
        run: terraform validate
82
        working-directory: ${{ matrix.workdir }}
83

84
      - name: Terraform plan
85
        run: tfcmt -var "target:${{ matrix.workdir }}" plan -patch -- terraform plan -parallelism=30 -no-color
86
        working-directory: ${{ matrix.workdir }}
87
        env:
88
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/actions/generate_aws_credential_string/action.yml

1
name: Generate aws credential string
2

3
inputs:
4
  profile:
5
    required: true
6
    type: string
7
  aws_role_arn:
8
    required: true
9
    type: string
10
  aws_role_external_id:
11
    required: true
12
    type: string
13

14
outputs:
15
  aws_credential:
16
    value: ${{ steps.gen_aws_cred_str.outputs.aws_credential }}
17

18
runs:
19
  using: composite
20
  steps:
21
    - name: Generate aws credential string
22
      id: gen_aws_cred_str
23
      shell: bash
24
      run: |
25
        CREDENTIAL=$(
26
          echo -e "[profile $PROFILE]
27
          credential_source = Environment
28
          role_arn = $AWS_ROLE_ARN
29
          external_id = $AWS_ROLE_EXTERNAL_ID
30

31
          "
32
        )
33

34
        echo "aws_credential<<EOF" >> $GITHUB_OUTPUT
35
        echo -e "$CREDENTIAL" >> $GITHUB_OUTPUT
36
        echo "EOF" >> $GITHUB_OUTPUT
37
      env:
38
        PROFILE: ${{ inputs.profile }}
39
        AWS_ROLE_ARN: ${{ inputs.aws_role_arn }}
40
        AWS_ROLE_EXTERNAL_ID: ${{ inputs.aws_role_external_id }}

使用感

自動的にterraform plan結果をコメント

terraform_plan_result

formatされていないコードをpushした場合にはワンクリックで修正をコミットできる

reviewdog_fmt

効果

本対応策を導入すると、terraform planが成功するか否かを常に確認することができます。
結果として、Terraformファイルの作成が大幅に効率化されます。

対応策：git pushを契機に自動的にECSタスクを起動してコマンドを実行する

コンテナのビルドコンテキストが格納されているenvironments/dev/docker配下に変更をgit pushすると、自動的にdocker build・docker pushして、そのイメージを用いてECSタスクを起動します。

拡張性やセキュリティを考慮して、GitHub ActionsからStepFunctionsを経由してECSタスクを起動する構成としました。
StepFunctionsを経由することで、承認や通知の処理を簡単に追加できます。また、GitHub Actionsに許可する権限はStepFunctionsの呼び出し権限のみとシンプルになります。

構成図

arch_db_migrate

対応策導入後のシーケンス

展開

  sequenceDiagram
      actor 作業者
      participant GitHub as GitHub
Repository
      participant db_migrate as db_migrate
(GHA)
      participant StepFunctions
      participant ECS
      participant ECR
      participant Servers

      %% コンテナイメージ作成
      rect rgba(224,242,254,0.3)
      note over 作業者,ECR: コンテナイメージ作成
      作業者 ->> 作業者: Dockerfileや
build contextを作成
      作業者 ->> GitHub: git push
      GitHub ->> db_migrate: Push作成イベント通知
      db_migrate ->> ECR: docker login
      db_migrate ->> db_migrate: docker build
      db_migrate ->> ECR: docker push
      end

      %% ECSタスクからのコマンド実行
      rect rgba(224,242,254,0.3)
      note over db_migrate,Servers: ECSタスクからのコマンド実行
      db_migrate ->> StepFunctions: ECSタスク起動用
ステートマシン実行
      StepFunctions ->> ECS: ECSタスクの最新リビジョン取得
      StepFunctions ->> ECS: ECSタスク実行
      ECS ->> ECR: docker pull
      ECS ->> ECS: コンテナ実行
      ECS ->> Servers: 各種コマンド実行

      Note left of ECS: git pushを契機に自動的にECSタスクを
起動してコマンドを実行
      end

導入方法

1. OIDC providerを作成する@AWSアカウント

対応策：PRを契機に自動的にterraform planを実行するで作成済みのものを使用します。

2. IAMロールを作成する@AWSアカウント

GitHub ActionsにてAssumeRoleするIAMロール(DB_MGR_ROLE)を作成する

今回は以下のように設定しました。

※ 各種ポリシーの内容は必要に応じて絞り込みや追加を行う必要があります。

信頼ポリシー

1
{
2
  "Version": "2012-10-17",
3
  "Statement": [
4
    {
5
      "Effect": "Allow",
6
      "Principal": {
7
        "AWS": "${AWS_ROLEのARN}"
8
      },
9
      "Action": "sts:AssumeRole",
10
      "Condition": {
11
        "StringEquals": {
12
          "sts:ExternalId": "${外部ID}"
13
        }
14
      }
15
    }
16
  ]
17
}

許可ポリシー

1
{
2
  "Version": "2012-10-17",
3
  "Statement": [
4
    {
5
      "Sid": "PublishEcsLogs",
6
      "Effect": "Allow",
7
      "Action": [
8
        "logs:CreateLogStream",
9
        "logs:CreateLogGroup",
10
        "logs:PutLogEvents"
11
      ],
12
      "Resource": [
13
        "arn:aws:logs:ap-northeast-1:${AWSAccountId}:log-group:/ecs/${TaskDefinitionName}:*"
14
      ]
15
    },
16
    {
17
      "Sid": "ExecuteStepFunctions",
18
      "Effect": "Allow",
19
      "Action": [
20
        "states:ListStateMachines",
21
        "states:DescribeStateMachine",
22
        "states:StartExecution",
23
        "states:DescribeExecution"
24
      ],
25
      "Resource": "*"
26
    },
27
    {
28
      "Sid": "EcrPush",
29
      "Effect": "Allow",
30
      "Action": [
31
        "ecr:CompleteLayerUpload",
32
        "ecr:UploadLayerPart",
33
        "ecr:InitiateLayerUpload",
34
        "ecr:BatchCheckLayerAvailability",
35
        "ecr:PutImage",
36
        "ecr:BatchGetImage"
37
      ],
38
      "Resource": "arn:aws:ecr:ap-northeast-1:${AWSAccountId}:repository/${RepositoryName}"
39
    },
40
    {
41
      "Sid": "EcrLogin",
42
      "Effect": "Allow",
43
      "Action": "ecr:GetAuthorizationToken",
44
      "Resource": "*"
45
    }
46
  ]
47
}

3. 作成したIAMロールの情報をGitHubリポジトリーのシークレットに登録する@GitHub Repository

各種IAMロールのARNと外部IDについて、以下のGitHubリポジトリーのシークレットに設定する
- DB_MGR_ROLE_ARN：AWS_MGR_ROLEのARN
- DB_MGR_ROLE_EXTERNAL_ID：AWS_MGR_ROLEの外部ID

4. ECSタスクを起動するVPCを作成する@AWSアカウント

ECSタスクを起動するVPC・サブネットを作成する
- 前提として、VPCやサブネット、Aurora等のデータベースサーバーが存在している必要があります。
- ECSタスクで使用するコンテナレジストリにアクセスするための経路が必要になります。
ECSタスクに関連付けるセキュリティグループを作成する
- ECSタスクからコマンドを実行する対象のデータベースサーバーにアクセスできるようにする必要があります。

5. ECS関連リソースを作成する@AWSアカウント

ECRリポジトリーを作成する
- 今回はDBマイグレーションを想定しているので、dev/db-migrateというリポジトリーを作成しました。
- latest運用を想定しているため、ミュータブルとしています。
  - latest運用とは、コンテナイメージを変更する際常にlatestタグを付与することで、ECSタスク定義を更新せずとも常に最新のコンテナイメージを使用する運用を指しています。
ECSクラスターを作成する
- 今回は、ECSクラスターのインフラとしてFargateを使用することとしました。

ECSタスクに関連づけるIAMロールを作成する

信頼ポリシー

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "",
6
            "Effect": "Allow",
7
            "Principal": {
8
                "Service": "ecs-tasks.amazonaws.com"
9
            },
10
            "Action": "sts:AssumeRole"
11
        }
12
    ]
13
}

許可ポリシー

1
AmazonEC2ContainerRegistryReadOnly
2
AmazonECSTaskExecutionRolePolicy

RDSのDBユーザーのパスワードをシークレットマネージャで管理する場合には許可ポリシーを追加

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Effect": "Allow",
6
            "Action": [
7
                "secretsmanager:GetSecretValue"
8
            ],
9
            "Resource": "*" # 必要に応じて制限する
10
        }
11
    ]
12
}

ECSタスクを作成する
- ECRリポジトリーdev/db-migrateのlatestタグのイメージを実行するECSタスクを作成します。

6. ステートマシンを作成する@AWSアカウント

ステートマシンに関連づけるIAMロールを作成する

信頼ポリシー

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "",
6
            "Effect": "Allow",
7
            "Principal": {
8
                "Service": "states.amazonaws.com"
9
            },
10
            "Action": "sts:AssumeRole"
11
        }
12
    ]
13
}

許可ポリシー

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Effect": "Allow",
6
            "Action": [
7
                "ecs:RunTask",
8
                "ecs:StopTask",
9
                "ecs:DescribeTasks",
10
                "ecs:DescribeTaskDefinition"
11
            ],
12
            "Resource": "*"
13
        },
14
        {
15
            "Effect": "Allow",
16
            "Action": [
17
                "events:PutTargets",
18
                "events:PutRule",
19
                "events:DescribeRule"
20
            ],
21
            "Resource": [
22
                "arn:aws:events:ap-northeast-1:${AWSAccountId}:rule/StepFunctionsGetEventsForECSTaskRule"
23
            ]
24
        },
25
        {
26
            "Effect": "Allow",
27
            "Action": [
28
                "iam:PassRole"
29
            ],
30
            "Resource": [
31
                "arn:aws:iam::${AWSAccountId}:role/${ステートマシンに関連づけるIAMロール名}"
32
            ]
33
        }
34
    ]
35
}

ステートマシンを作成する

ステートマシン定義

1
{
2
  "Comment": "A description of my state machine",
3
  "StartAt": "DescribeTaskDefinition",
4
  "States": {
5
    "DescribeTaskDefinition": {
6
      "Type": "Task",
7
      "Arguments": {
8
        "TaskDefinition": "arn:aws:ecs:ap-northeast-1:${AWSAccountId}:task-definition/${ECSタスク名}"
9
      },
10
      "Resource": "arn:aws:states:::aws-sdk:ecs:describeTaskDefinition",
11
      "Next": "ECS RunTask",
12
      "Assign": {
13
        "ecsTaskDefArn": "{% $states.result.TaskDefinition.TaskDefinitionArn %}"
14
      }
15
    },
16
    "ECS RunTask": {
17
      "Type": "Task",
18
      "Resource": "arn:aws:states:::ecs:runTask.sync",
19
      "End": true,
20
      "Arguments": {
21
        "LaunchType": "FARGATE",
22
        "Cluster": "arn:aws:ecs:ap-northeast-1:${AWSAccountId}:cluster/${ECSクラスター名}",
23
        "TaskDefinition": "{% $ecsTaskDefArn %}",
24
        "NetworkConfiguration": {
25
          "AwsvpcConfiguration": {
26
            "AssignPublicIp": "ENABLED", # コンテナリポジトリにアクセスするために付与しているが、NAT GatewayやVPC Endpointでアクセスできる場合には不要
27
            "SecurityGroups": [
28
              "${ECSタスクに関連付けるSGのID}"
29
            ],
30
            "Subnets": [
31
              "${ECSタスクを配置するサブネットのID}"
32
            ]
33
          }
34
        }
35
      }
36
    }
37
  },
38
  "QueryLanguage": "JSONata"
39
}

7. DBマイグレーション用AWSリソースの情報をGitHubリポジトリーのシークレットに登録する@GitHub Repository

ECSとStepFunctions関連の情報について、以下のGitHubリポジトリーのシークレットに設定する
- DB_MGR_ECR_IMAGE_TAG：latest
- DB_MGR_ECR_REGISTRY：ECRレジストリURL (${AWSAccountId}.dkr.ecr.${Region}.amazonaws.com)
- DB_MGR_ECR_REPOSITORY：ECRリポジトリー名
- DB_MGR_SFN_ARN：ステートマシンのARN

8. StepFunctionsを実行するワークフローを作成する@GitHub Actions

以下を参考に、コンテナイメージの準備とStepFunction実行自動化を行います。
- https://github.com/aws-actions/amazon-ecr-login ⧉
- https://github.com/docker/build-push-action ⧉

今回は、以下のように設定しました。

.github/workflows/db_migrate.yml

1
name: DB migration
2

3
on:
4
  push:
5
    branches:
6
      - main
7
    path:
8
      - 'environments/dev/docker/**'
9

10
env:
11
  AWS_DEFAULT_REGION: ap-northeast-1
12

13
permissions:
14
  id-token: write
15
  contents: read
16

17
jobs:
18
  tf_plan:
19
    name: DB Migration
20
    runs-on: ubuntu-latest
21
    strategy:
22
      matrix:
23
        build_context:
24
          - ./environments/dev/docker
25

26
    steps:
27
      - name: Git checkout
28
        uses: actions/checkout@v4
29
        with:
30
          ref: ${{ github.event.pull_request.head.sha }}
31

32
      - name: Get aws credential
33
        uses: aws-actions/configure-aws-credentials@v4
34
        with:
35
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
36
          role-session-name: iar-gha-con-${{ github.run_id }}
37
          aws-region: ${{ env.AWS_DEFAULT_REGION }}
38

39
      - run: aws sts get-caller-identity
40

41
      - name: Switch to db-migrate role
42
        uses: aws-actions/configure-aws-credentials@v4
43
        with:
44
          role-to-assume: ${{ secrets.DB_MGR_ROLE_ARN }}
45
          role-external-id: ${{ secrets.DB_MGR_ROLE_EXTERNAL_ID }}
46
          role-session-name: iar-gha-mgr-${{ github.run_id }}
47
          role-chaining: true
48
          aws-region: ${{ env.AWS_DEFAULT_REGION }}
49
          role-skip-session-tagging: true
50

51
      - run: aws sts get-caller-identity
52

53
      - name: Set up Docker Buildx
54
        uses: docker/setup-buildx-action@v3
55
        with:
56
          install: true
57

58
      - name: Login to Amazon ECR
59
        uses: aws-actions/amazon-ecr-login@v2
60

61
      - name: Build and push docker iamge
62
        uses: docker/build-push-action@v2
63
        with:
64
          context: ${{ matrix.build_context }}
65
          push: true
66
          no-cache: true
67
          tags: ${{ secrets.DB_MGR_ECR_REGISTRY }}/${{ secrets.DB_MGR_ECR_REPOSITORY }}:${{ secrets.DB_MGR_ECR_IMAGE_TAG }}
68

69
      - name: Call aws stepfunctions
70
        uses: ./.github/actions/call_aws_step_functions
71
        with:
72
          aws_sfn_arn: ${{ secrets.DB_MGR_SFN_ARN }}

.github/actions/call_aws_step_functions/action.yml

1
name: Build and push docker image
2

3
inputs:
4
  aws_sfn_arn:
5
    required: true
6
    type: string
7

8
runs:
9
  using: composite
10
  steps:
11
    - name: Execute StepFunctions
12
      shell: bash
13
      run: |
14
        SFN_EXEC_ARN=$(aws stepfunctions start-execution \
15
          --state-machine-arn "$STATE_MACHINE" \
16
          --no-cli-pager \
17
          | jq -r '.executionArn')
18

19
        if [ -z "$SFN_EXEC_ARN" ]; then
20
          echo "Error: 実行 ARN の取得に失敗しました。"
21
          exit 1
22
        fi
23

24
        echo "Step Functions 実行開始: $SFN_EXEC_ARN"
25

26
        while true; do
27
          STATUS=$(aws stepfunctions describe-execution \
28
            --execution-arn "$SFN_EXEC_ARN" --no-cli-pager \
29
            | jq -r '.status')
30

31
          if [ "$STATUS" != "RUNNING" ]; then
32
            break
33
          fi
34

35
          sleep 5
36
        done
37

38
        echo "実行完了。最終ステータス: $STATUS"
39
      env:
40
        STATE_MACHINE: ${{ inputs.aws_sfn_arn }}

※ dockerコンテナのbuild cacheについて
今回は運用時に必要なワンショットのコマンド実行が目的の、ビルドに長時間を要さないコンテナを想定しています。
そこで、build cacheの有無でビルド結果が変わることを避けるため、build cacheを使用しない設定としました。
ECRを用いたremote cacheには料金がかかりますし、GitHubのキャッシュ機能 ⧉は期限を過ぎると削除される仕様です。
ビルドに時間がかかりコストとメリットのバランスが取れる場合には、何らかの方法でbuild cacheを導入することが推奨されます。

使用感

GitHub Actionsワークフロー実行ログ

db_migrate_workflow

StepFunctions実行ログ

db_migrate_ecs_sfn_result

JavascriptのORMツールであるPrismaを用いて、ECSタスクからAuroraの情報を取得する例

db_migrate_ecs_task_result

効果

本対応策を導入すると、コンテナで実行するよう事前に記述したコマンドのみが実行されます。
結果として、踏み台サーバーの維持コストやオペレーションミスのリスクを軽減することができます。

おわりに

この記事では、GitHub Actionsを用いたCI/CDによるインフラ構築・運用の省力化についてご紹介しました。

PR-Agentの導入によって、AIによるレビューを手軽に導入することができます。
PRのテンプレートを充実させることやコーディング規約をチームに浸透させることも重要ですが、別視点でのアプローチとして有効であると感じています。

terraform planの自動実行は非常に便利で、手動実行にはもう戻れないと感じています。
「いざterraform applyを実行したところでエラーが発覚し、手戻りが発生してしまった」といった事態が起きにくくなります。

ECSタスク起動によるコマンドの実行については、セキュリティ強化やオペレーションミスへの有効な対策になります。
「作業者の判断で手順書外のオペレーションを実施し、システム障害を招いてしまった」といった事態が非常に起きにくくなります。

CI/CDの仕組みが整っていないケースは少ないかもしれませんが、この記事が快適な開発体験の一助となれば幸いです。

記事をシェアする