6
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

GitHub ActionsAdvent Calendar 2023

Day 11

GitHub Actions × Google Cloud Workload Identityを使ってCloud RunへデプロイしてSlackへ通知する

Last updated at Posted at 2023-12-10

はじめに

Advent Calendar 2023 2本目の投稿です。
以下の記事等でも何度か投稿しているCI/CD関連の投稿になります。

今回は、Google Cloud Workload Identityを使ってGitHub ActionsからCloud RunへアプリをデプロイしてSlackへ通知する、ということをやってみたいと思います。

構築するCI/CD環境構成

今回構築するCI/CD環境構成は以下の通りです。

Qiita_GitHubActions.png

トリガー

正直ここではなんでも良いのですが、今回は該当リポジトリにソースがPushされたことをトリガーに実行したいと思います。

ワークフロー

  1. ビルドとテストを行いコンテナイメージの作成
  2. 作成したコンテナイメージをArtifact Registryへ登録
  3. Cloud Runへデプロ
  4. デプロイ結果をSlackへ通知

事前準備

1. Google Cloud側でWorkload Identityの作成

事前準備として、GitHub ActionsとGoogle Cloudを連携させるために、Google Cloud側でWorkload Identity の設定をします。Workload Identityとは、Google Cloud外部のワークロードの中(GitHub ActionsやAWS、Azure等)からGoogle Cloudのサービスを利用するための認証設定になります。
こちらを参考に設定させていただきました。

Workload Identityの設定内容としてはこんな感じです。
image.png
image.png

また、GitHub Actions用に作成したサービスアカウントの権限に一番下の形式でプリンシパルを追加する必要があります。

ここの追加をするのを忘れておりハマりました

projets/の後ろはプロジェクト番号(下の設定図のプロジェクト番号)、attribute.repository/の後ろはGitHubのユーザー名となります。
image.png
image.png

サービスアカウントのロールは以下の通りです。
image.png

2. Google Cloud側でArtifact Registryでリポジトリの作成

Artifact Registryでリポジトリを作成します。リポジトリ名や形式(今回はDockerイメージを利用するのでDockerを選択)、リージョンを指定して作成しておきます。
image.png

3. GitHub Actions側でsecretの設定

何をsecretに持たせて何をenvに持たせるかは要検討ですが、今回は以下をsecretに持たせました。
image.png
・ PROJECT_ID
Google CloudのプロジェクトIDです、dockerイメージをArtifact RegistryへPushする際に必要になります。

・ WIF_PROVIDER
Google Workload Identityのプロバイダの識別子です。以下の形式で設定します。

projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider

値はGoogle CloudのWorkload Identityの編集画面で確認できます(デフォルトのオーディエンスの下にあるURLのproject以降を指定します)。
image.png

・ WIF_SERVICE_ACCOUNT
Google Cloud側で利用するサービスアカウントです。以下の形式で設定します。

my-service-account@my-project.iam.gserviceaccount.com

・ SLACK_WEBHOOK_URL
SlackのWebhookのURLです。こちらを参照ください。

構築してみる

1. Dockerfileの作成

まずはDockerfileを作成します。今回は以前「GCPでJenkins Pipelineを使ってSonarQubeと連携させたCI/CD環境を構築し結果をSlackへ通知する」で作成したファイルを流用します。

# Spring BootアプリをビルドするためMaven/Java8のDockerイメージを利用
FROM maven:3.5-jdk-8-alpine AS builder

# ビルド時のワークディレクトリの設定
WORKDIR /app
COPY pom.xml .
COPY src ./src

RUN mvn package

# Spring Bootアプリの実行環境にopenjdk:8-jre-alpineを利用
FROM openjdk:8-jre-alpine

COPY --from=builder /app/target/Spring-Boot-RESTful-API-Test-Sample-1.0.0-SNAPSHOT.jar /app.jar

# Docker Run時にjavaコマンドでSpring Bootを起動(Embedded Tomcatを起動)
CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/app.jar"]

2. GitHub Actions側でワークフローファイルの作成

続いて、GitHub Actions側でワークフローファイルの作成です。
構成としては、build、test、deployを行うジョブとSlackへ通知するジョブを分けています(1つのジョブで全部やっても良かったのですが、分けている意図は特にありません)。

build-deploy-to-cloudrun.yml
name: build, test and deploy to cloud run
on:
  push:

jobs:
  build-test-deploy-to-cloudrun:
    runs-on: ubuntu-latest
    # Google Cloudの認証でgoogle-github-actions/authを利用する際に必要なpermissions設定
    # see. https://github.com/google-github-actions/auth?tab=readme-ov-file#usage
    permissions:
      id-token: write
      contents: read
    env:
      ARTIFACT_REGISTRY: github-actions
      REGION: asia-northeast1
      APP_NAME: spring-boot-restful-api-test
      
    steps:
      - uses: actions/checkout@v4
      - name: 'Google auth'
        uses: 'google-github-actions/auth@v1'
        with:
          # Google Cloud認証を通すためのInput、公式のコードはproject_idになっているがservice_account
          workload_identity_provider: '${{secrets.WIF_PROVIDER}}'
          service_account: '${{secrets.WIF_SERVICE_ACCOUNT}}'
          
      - name: 'Set up Cloud SDK'
        uses: 'google-github-actions/setup-gcloud@v1'
        with:
          version: '>= 379.0.0'
          
      - name: 'Docker auth'
        run: |-
          gcloud auth configure-docker ${{env.REGION}}-docker.pkg.dev
      
      - name: 'Build and push container'
        run: |-
          docker build -t "${{env.REGION}}-docker.pkg.dev/${{secrets.PROJECT_ID}}/${{env.ARTIFACT_REGISTRY}}/${{env.APP_NAME}}:${{github.sha}}" .
          docker push "${{env.REGION}}-docker.pkg.dev/${{secrets.PROJECT_ID}}/${{env.ARTIFACT_REGISTRY}}/${{env.APP_NAME}}:${{github.sha}}"

      - name: 'Deploy to Cloud Run'
        uses: 'google-github-actions/deploy-cloudrun@v0'
        with:
          service: ${{env.APP_NAME}}
          region: ${{env.REGION}}
          image: ${{env.REGION}}-docker.pkg.dev/${{secrets.PROJECT_ID}}/${{env.ARTIFACT_REGISTRY}}/${{env.APP_NAME}}:${{github.sha}}
    
  slack-notification:
    name: send-notification
    # needs指定をすると前のジョブが失敗した場合は実行されない。Slack通知は成功、失敗に限らず必ず実行させるため以下を指定することで常に通知されるよう設定
    if: always()
    # build-test-deploy-to-cloudrunジョブ後に実行したいためneeds指定
    needs: build-test-deploy-to-cloudrun
    runs-on: ubuntu-latest
    steps:
      - name: Send GitHub Action trigger data to Slack workflow failure
        if: ${{needs.build-test-deploy-to-cloudrun.result == 'failure'}}
        uses: slackapi/slack-github-action@v1.24.0
        with:
          payload: |
            {
              "text": "Build, Test and Deploy Failure."
            }
        env:
          SLACK_WEBHOOK_URL: ${{secrets.SLACK_WEBHOOK_URL}}
      - name: Send GitHub Action trigger data to Slack workflow success
        if: ${{needs.build-test-deploy-to-cloudrun.result == 'success'}}
        uses: slackapi/slack-github-action@v1.24.0
        with:
          payload: |
            {
              "text": "Build, Test and Deploy Success."
            }
        env:
          SLACK_WEBHOOK_URL: ${{secrets.SLACK_WEBHOOK_URL}}

動作確認

今回はPushをトリガーにしているので、適当にPushをしてGitHub Actionsが動作するか見てみます。当然ですが、実行はされます(一番上の実行中のがそれになります)。
image.png

少し待つと無事成功しました。
image.png
image.png

Slack側も確認してみます。こちらも無事通知が来ていました。
image.png

Google Cloud側でArtifact Registryも確認してみます。こちらも問題なくDockerイメージがPushされていました(何回も実行しているでたくさん表示されていますが、一番上のイメージが今回のものになります)
image.png

Cloud Run側も確認しデプロイされているか確認します。問題なくデプロイされていますね。
image.png
image.png

実際に任意のAPIを叩いてみても期待通りのレスポンスが返ってきました
image.png

以上です。

参考

6
3
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
6
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?