GKE x Cloud Deploy：GREE BizcenにおけるCI/CDパイプライン活用事例

はじめに

こんにちは、GREE Bizcen開発チームです。ビジネス支援プラットフォーム「GREE Bizcen」の開発では、迅速かつ安定した機能提供を実現するため、Google Kubernetes Engine (GKE) 上に構築したアプリケーションのCI/CDパイプラインの改善を継続的に行っています。

本記事では、GREE Bizcenプロジェクトで実践している、GitHub Actions、Cloud Build、Skaffold、そしてCloud Deployを組み合わせたGKEへの継続的デプロイメントパイプラインについて、その全体像と具体的な設定内容を解説します。

BizcenのCI/CDパイ-プライン全体像

BizcenのCI/CDパイプラインは、以下のツール群を連携させることで実現されています。

GitHub Actions: Pull RequestやmainブランチへのマージをトリガーにCI/CDプロセスを開始します。
Cloud Build: DockerイメージのビルドとArtifact Registryへのプッシュを担当します。
Skaffold: Kubernetesのマニフェストを管理し、ビルドとデプロイの定義を一元化します。
Cloud Deploy: GKEへの安全なデプロイとリリース管理を行います。

これらのツールが連携し、ソースコードの変更からGKEクラスタへのデプロイまでを自動化しています。

各コンポーネントの役割と設定

1. GitHub Actionsによるワークフロー

Bizcenでは、ci.yml、deploy.yml、promote.yml の3つのGitHub Actionsワークフローを定義しています。

`ci.yml`: Pull Request時の自動テスト

Pull Requestが作成されると、ci.ymlが実行され、Goのユニットテストが実行されます。これにより、マージ前のコード品質を担保します。

# .github/workflows/ci.yml
name: CI
on: pull_request
 
jobs:
  unit-tests:
    name: runner / tests / unit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: 1.24
      - name: Unit Tests
        run: 'make test'

`deploy.yml`: Staging環境へのデプロイ

ここから先は、全てデプロイ関連の処理です。 mainブランチにマージされると、deploy.ymlがトリガーされます。このワークフローは、Cloud BuildでDockerイメージをビルドし、Cloud Deployのリリースを作成してStaging環境へデプロイします。

# .github/workflows/deploy.yml
name: Deploy to Staging
on:
  push:
    branches:
      - main
 
jobs:
  deploy:
    name: Create Cloud Deploy Release
    runs-on: ubuntu-latest
    environment: staging
    permissions:
      contents: 'read'
      id-token: 'write'
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
 
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v2'
        with:
          workload_identity_provider: 'projects/${{ vars.PROJECT_NUMBER }}/...'
          service_account: 'github-actions@${{ vars.PROJECT_ID }}.iam.gserviceaccount.com'
 
      - name: 'Create Cloud Deploy release'
        id: 'release'
        uses: 'google-github-actions/create-cloud-deploy-release@v1'
        with:
          delivery_pipeline: ${{ vars.PIPELINE_NAME }}
          name: ${{ env.RELEASE_NAME }}
          region: ${{ vars.REGION }}
          skaffold_file: 'skaffold.yaml'
          images: 'bizcen-backend=${{ env.IMAGE_REF }}'

`promote.yml`: Production環境へのデプロイ

Production環境へのデプロイを行うpromote.yml の中身は、Staging環境へのデプロイを行うdeploy.ymlとほとんど同じです。 1点だけ違う点はトリガーで、Production環境へのデプロイは手動実行のみとしています。

# .github/workflows/promote.yml
name: Promote to Production
 
on:
  workflow_dispatch: # 手動実行

Production環境へのデプロイは、慣習的にヒューマンゲートを通す仕様となっています。最初、Cloud Deployのpromote機能を利用しましたが分かりづらかったため、ボタン押下をトリガーにStaging同様の処理を行うように変更しました。

2. Cloud Buildによるイメージビルド

GitHub Actionsから呼び出されるCloud Buildは、cloudbuild.yaml に基づいてマルチアーキテクチャ（amd64, arm64）のDockerイメージをビルドし、Artifact Registryにプッシュします。

# cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['buildx', 'create', '--name', 'multiarch-builder', '--use']
    id: 'setup-buildx'
 
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'buildx'
      - 'build'
      - '--push'
      - '--builder=multiarch-builder'
      - '--platform=linux/amd64,linux/arm64'
      - '-t'
      - '${_IMAGE_NAME}'
      - '.'
    id: 'build-and-push-backend'

3. Cloud Deployによる安全なリリース

Skaffoldによるビルドとデプロイの定義

Skaffoldは、BizcenのCI/CDパイプラインの心臓部です。 skaffold.yamlには、ローカル開発、Staging、Productionの各環境におけるビルドとデプロイの方法が定義されています。

プロファイル機能: dev, staging, production の各環境に応じた設定を切り替えます。
kustomize連携: 環境ごとのKubernetesマニフェストの差分を管理します。
Cloud Build連携: Staging/Production環境では、googleCloudBuild を使用してイメージをビルドします。

つまり、skaffold.yaml は、Cloud Deployの設定ファイルとして機能します。

# skaffold.yaml
apiVersion: skaffold/v4beta7
kind: Config
metadata:
  name: bizcen-backend
 
profiles:
  - name: staging
    build:
      googleCloudBuild:
        projectId: your-project-id
      artifacts:
        - image: asia-northeast1-docker.pkg.dev/your-project-id/bizcen/staging/backend
          platforms: ['linux/amd64', 'linux/arm64']
    manifests:
      kustomize:
        paths:
          - kubernetes/app/overlays/staging/

Skaffolodは単独のツールとして様々な機能がありますが、Cloud Deployはマニフェストのレンダリングに利用します。また、設定しておけば、リリース前後の自動確認も行うことができます。 GREE Bizcenでは、リリース後に正常起動したか確認して、問題があれば自動切り戻しをかけています。 Cloud Deploy は、skaffoldのマネージド実行環境と考えると分かりやすいかと思います。

Cloud Deploy

Cloud Deployは、GKEへのデプロイを管理し、承認プロセスや段階的なロールアウトを可能にします。例えば、カナリアリリースを行い、Prometheusからエラーレートを取得して、問題なければ自動的に全体リリースすることも可能です。 GitHub Actionsの create-cloud-deploy-release アクションによって新しいリリースが作成され、定義されたデリバリーパイプラインに従ってGKEクラスタに展開されます。

似たような名前の AWS Code Deploy は、アプリケーションのコードを配布します。しかし、GCP Cloud Deploy は、マニフェストを配布します。 GKEやCloudRunがマニフェストの更新を検知して、システムを更新します。つまり、Cloud Deployはアプリケーションコードの配布だけではなく、Argo CD が行うような GitOps の機能も併せ持ちます。

まとめ

Cloud Deployを利用するためには、アプリケーションと同じ GitHub Repository で GKE マニフェストを管理する必要があります。つまり、マイクロサービスを担当するストリームアラインドチームがあり、そこでアプリケーションからマニフェストまで管理しているケースに適しています。逆にプラットフォームチームが一元的にマニフェストを管理するケースでは、 Argo CD 及び Argo Rollout を使って集中管理する方が良さそうです。サービスも組織もマイクロサービス化していないと使いづらいという点は、Google Cloudっぽいなと感じました。この事例が、GKE上でCI/CDパイプラインを構築しようとしている方々の参考になれば幸いです。