Go×GCP

Go×GCPで実践クラウド開発入門：Cloud Run + Cloud Buildで始めるモダンなマイクロサービス構築

1. はじめに

クラウド技術の進化により、アプリケーションの開発・運用は従来のオンプレミスから、マイクロサービスやサーバーレスといった柔軟かつスケーラブルな形態へとシフトしています。その中で、Go（Golang）とGoogle Cloud Platform（GCP）の組み合わせは、軽量・高速・シンプルな構成を好むエンジニアにとって非常に魅力的な選択肢です。

本記事では、GoとGCPを活用したモダンなクラウドアプリケーション開発の第一歩として、Cloud RunとCloud Buildを用いたマイクロサービスの構築と自動デプロイの手法を丁寧に解説します。

単なる"Hello, World"で終わるのではなく、以下のような一連のステップを通じて、実践的なクラウド開発を体験できる構成としています：

  • ローカルでのGoアプリ開発
  • Dockerによるコンテナ化
  • Cloud Buildを使った自動ビルド＆デプロイ
  • Cloud Runでのマイクロサービス公開
  • ログの収集とモニタリング（Cloud Logging）

また、シリーズの今後の記事では、以下のような実践的テーマに発展予定です：

  • Cloud Firestoreによるデータ永続化
  • Pub/Subによる非同期処理
  • Cloud Schedulerを使った定期実行
  • Cloud Monitoringを活用した可観測性の強化

GCP初心者の方にもわかりやすく、Goでクラウドネイティブな開発を始めたい方には最適な内容となっているので、ぜひ最後までお付き合いください。

2. GoとGCPの相性の良さとは？

Go言語はGoogleによって開発された静的型付けのコンパイル言語であり、その設計思想には以下のような特長があります：

  • シンプルで明快な構文
  • 高速なビルドと実行性能
  • 並行処理（goroutine）への強力なサポート
  • 単一バイナリの生成による移植性の高さ

これらの性質は、クラウド環境でのマイクロサービスやサーバーレスアーキテクチャとの相性が非常に良く、Google Cloud Platformとの組み合わせにおいて特に力を発揮します。

2-1. GCP公式サポートが充実

GCPは、Go言語に対して豊富な公式サポートを提供しています：

  • Cloud Storage や Firestore、Pub/Sub など主要サービス向けのGoクライアントライブラリ
  • Cloud Functions / Cloud Run / App Engine でのGoサポート
  • Google公式が提供するGo SDKやツール群
  • 初心者向けのチュートリアルやサンプルコードも充実

2-2. Cloud Runとの親和性

Cloud Runは、以下のような点でGoと非常に相性が良いです：

  • 軽量なGoバイナリが高速に起動し、Cold Start対策にも有効
  • HTTPサーバを標準ライブラリ（net/http）だけで実装可能
  • 小規模でも低コストでスケール可能（0インスタンス運用も可能）

たとえば、Cloud Run上でGoアプリをデプロイすると、リクエストが来たタイミングでインスタンスが起動し、必要に応じて自動スケーリングするため、開発初期段階でも気軽にクラウドに載せられます。

2-3. シンプルな構成と高い生産性

GoはCI/CDパイプラインにも強く、以下のような利点があります：

  • go build コマンド一発で単一バイナリが作れる
  • go mod による依存管理が簡潔
  • テスト・フォーマット・静的解析が標準ツールで完結（go test, go fmt, go vet）
  • Dockerfileとの相性も良く、軽量なAlpineベースのイメージが容易に構築可能

これらの特徴は、Cloud BuildやGitHub Actionsとの統合時にも非常に効果を発揮します。

このように、GoとGCPは思想的にも技術的にも自然なペアであり、これからクラウドネイティブな開発を学びたい開発者にとっては、非常に学習コストが低く、効率よく実践的なスキルを習得できる理想的な環境といえるでしょう。

3. プロジェクトとローカル環境の準備

ここでは、GCPの契約手順と、開発に必要な環境構築方法を含めて解説します。

3-0. GCPアカウントの作成と契約手順

  1. Google Cloud公式サイト にアクセス
  2. 右上の「コンソール」からGoogleアカウントでログイン
  3. 初回利用時は、支払い情報の登録が求められます：
    • クレジットカードの登録（本人確認目的）
    • 無料枠（$300相当、12ヶ月間）の提供あり
  4. 支払いアカウントが作成された後、GCPコンソールを自由に利用可能になります

注意：無料枠を超過した場合、自動で課金されることはなく、明示的なアップグレードを行うまで課金されません。

ここからは、GoアプリケーションをGCP上で動かすための準備作業について解説していきます。以下のステップを順番に進めれば、Cloud Runへのデプロイ環境が整います。

3-1. GCPプロジェクトの作成とAPIの有効化

まずはGCPで新しいプロジェクトを作成し、必要なAPIを有効にしましょう。

  1. Google Cloud Console にアクセス
  2. プロジェクトを新規作成
  3. 以下のAPIを有効化：

⚠️ Cloud Run Admin APIを有効にしていない場合、Cloud Buildからのデプロイ時に PERMISSION_DENIED エラーになります。
エラー例：

PERMISSION_DENIED: Cloud Run Admin API has not been used in project ... or it is disabled.

こちらのリンク から手動でAPIを有効化できます。
有効化後は数分待ってから再度ビルドまたはデプロイをお試しください。

3-2. ローカル環境に必要なツールのインストール

開発とデプロイを行うには、以下のツールが必要です：

インストール後は、以下のコマンドでログインと初期設定を行ってください：

gcloud auth login
gcloud config set project [YOUR_PROJECT_ID]
gcloud auth configure-docker

3-3. サービスアカウントと権限の確認

Cloud BuildがCloud Runへデプロイできるよう、適切な権限を持つサービスアカウントが必要です。

  • Cloud Build のデフォルトサービスアカウントに以下のロールを付与：
    • Cloud Run Admin
    • Storage Admin
    • Artifact Registry Writer

これらは IAM 管理画面から設定可能です。

以上で、GCPとローカルの準備が整いました。

🌐 gcloud CLIのプロキシ設定について

企業ネットワークやセキュリティ制限のある環境下で gcloud CLI がインターネットに接続できない場合は、以下のようにプロキシ設定を行うことができます：

Unix/Linux/macOS の場合：

export https_proxy=http://[username:password@]proxyhost:port
export http_proxy=http://[username:password@]proxyhost:port

Windows（PowerShell）の場合：

$env:https_proxy = "http://proxyhost:port"
$env:http_proxy = "http://proxyhost:port"
  • 認証が必要な場合は username:password@ を含めます。
  • 必要に応じて .bashrc や .zshrc に設定を追記しておくと便利です。
  • gcloud CLIの通信に問題がある場合、gcloud info や gcloud config list で設定状況を確認すると良いです。

🗾 東京リージョンと他リージョンの違い（Cloud Run）

Cloud RunやArtifact Registryは、**リージョン（地域）**を指定してリソースを作成します。ここでは代表的な違いを簡単に比較します：

リージョン例特徴
東京（asia-northeast1）日本国内から高速アクセス・国内法準拠日本ユーザー向けに最適、レイテンシが低い
大阪（asia-northeast2）フェイルオーバー先として活用東京と併用して可用性向上に活用可能
us-central1米国アイオワ料金が比較的安価、グローバル対応向き

リージョン選定のポイント：

  • 日本国内ユーザー向けサービス → asia-northeast1（東京）推奨
  • コスト重視・検証用 → us-central1 も選択肢
  • 本番運用では複数リージョン構成（冗長化）を検討するのが理想

gcloud run deploy や gcloud artifacts repositories create 時に --region オプションで指定します。

💰 この構成での動作確認にかかる費用の目安

このチュートリアル構成（Cloud Run + Cloud Build + Artifact Registry）は非常に軽量なため、以下のような費用想定です：

サービス無料枠概算コスト（1回実行）
Cloud Run月200万リクエスト / 360,000 GB秒約 ¥0〜¥5
Cloud Build月120分約 ¥0（5分以内）
Artifact Registry月0.5GB（標準）約 ¥0〜¥1

目安として、1回のデプロイ＋数回アクセスする程度であれば、月額無料枠内で完結します。

ただし、アクセスを繰り返す・デプロイ回数が増える・大規模イメージを使用するなどのケースでは課金対象となるため、GCP料金計算ツールを活用して試算するのがおすすめです。次は、実際にGoで簡単なWebアプリケーションを作成し、Cloud Runに載せるまでを解説していきます。

4. Goで簡単なHTTPサーバを構築

ここでは、Go言語の標準ライブラリである net/http を使って、シンプルなWebサーバを実装します。このWebサーバは、Cloud Run上で動かす基本構成の土台となります。

4-1. ディレクトリ構成の準備

まずは、以下のようなシンプルなディレクトリを作成しましょう：

go-cloudrun-app/
├── main.go
├── go.mod
└── Dockerfile

4-2. main.goの実装

以下は、"Hello, Cloud Run"と表示するだけの最小構成のHTTPサーバです：

package main

import (
	"fmt"
	"net/http"
	"os"
)

func handler(w http.ResponseWriter, r *http.Request) {
	name := os.Getenv("TARGET")
	if name == "" {
		name = "World"
	}
	fmt.Fprintf(w, "Hello, %s!\n", name)
}

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":8080", nil)
}

4-3. go.modの作成

Goモジュールを初期化するには、以下のコマンドを実行します：

go mod init example.com/go-cloudrun-app

（※ example.com の部分は任意のモジュール名に変更可能）

4-4. Dockerfileの作成

Cloud Runでデプロイ可能なコンテナイメージを作成するための Dockerfile は以下の通りです：

# Use the official Golang image to create a build artifact.
# This is known as a multi-stage build.
FROM golang:1.24 AS builder
# Set the Current Working Directory inside the container
WORKDIR /app
# Copy go mod file
COPY go.mod ./
# Download all dependencies. Dependencies will be cached if the go.mod file is not changed
RUN go mod download
# Copy the source code from the current directory to the Working Directory inside the container
COPY . .
# Build the Go app
RUN CGO_ENABLED=0 GOOS=linux go build -v -o server .
# Start a new stage from scratch for a smaller image
FROM alpine:latest
# Set the Current Working Directory inside the container
WORKDIR /root/
# Copy the Pre-built binary file from the previous stage
COPY --from=builder /app/server .
# Expose port 8080 to the outside world
EXPOSE 8080
# Command to run the executable
CMD ["./server"]

この構成では、ビルドステージと実行ステージを分けることで、最小限の軽量な本番用イメージを構築しています。

ここまでで、Cloud Runにデプロイ可能なGoアプリケーションの最小構成が完成しました。次のステップでは、これを実際にGCPにデプロイし、Cloud Run上で公開する方法を解説します。

5. Cloud BuildでCI的にCloud Runへ自動デプロイ

ここからは、ローカルで作成したGoアプリケーションをGCPへ自動的にビルド・デプロイする仕組みを構築していきます。手動でのビルドやデプロイを都度行うのではなく、Cloud BuildとGitHubを連携させることで、ソースコードの更新をトリガーにCloud Runへ自動デプロイされる流れを作ります。

5-1. Cloud Buildとは？

Cloud Build は、Google Cloud の CI/CD サービスです。以下の特徴があります：

  • 任意のビルドステップを記述した cloudbuild.yaml に従ってビルド処理を実行
  • Docker イメージのビルドや GCP へのデプロイが可能
  • GitHub などのソースリポジトリと連携可能
  • IAM によるアクセス制御、ロギング、通知も統合

Cloud Build を使うことで、完全マネージドなCI/CDパイプラインを構築できます。

5-2. cloudbuild.yaml を作成

Cloud Build の動作は cloudbuild.yaml で定義します。以下は、Goアプリをビルドし、Artifact Registry へイメージをPushし、Cloud Runへデプロイする構成です：

---
steps:
  # Build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/cloud-run-source-deploy/go-cloudrun-example:$COMMIT_SHA'
      - '.'

  # Push the container image to Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/cloud-run-source-deploy/go-cloudrun-example:$COMMIT_SHA'

  # Deploy container image to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - 'run'
      - 'deploy'
      - 'go-cloudrun-example'
      - '--image'
      - 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/cloud-run-source-deploy/go-cloudrun-example:$COMMIT_SHA'
      - '--region'
      - 'asia-northeast1'
      - '--platform'
      - 'managed'
      - '--allow-unauthenticated'

options:
  logging: CLOUD_LOGGING_ONLY

5-3. Artifact Registryのリポジトリ作成

本ステップに入る前に、Cloud Build が Cloud Run にデプロイできるようにするための サービスアカウントの作成とロール付与 を行っておくと安全です。

🔧 サービスアカウントの作成（Cloud Build専用）

gcloud iam service-accounts create cloudbuild-deployer \
  --display-name="Cloud Build Deployer"

🔑 ロールの付与

以下の3つのロールを、先ほど作成したサービスアカウントに付与します：

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:cloudbuild-deployer@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/run.admin"

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:cloudbuild-deployer@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/artifactregistry.writer"

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:cloudbuild-deployer@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

🛠 Cloud Build で使用するサービスアカウントを指定（任意）

Cloud Build トリガーの詳細設定で「サービスアカウント」を cloudbuild-deployer に指定すると、権限の最小化とセキュリティ確保に繋がります。

ビルドしたDockerイメージを保存するには、Artifact Registryにリポジトリを作成しておく必要があります。

ビルドしたDockerイメージを保存するには、Artifact Registryにリポジトリを作成しておく必要があります。

gcloud artifacts repositories create go-cloudrun-app \
  --repository-format=docker \
  --location=asia-northeast1 \
  --description="Go Cloud Run App"

5-4. GitHubとの連携設定（Build Trigger）

Cloud BuildでGitHubを接続して自動トリガーを設定するには、以下の手順を丁寧に行う必要があります。

🔑 重要：最初に「新しいホストに接続」を行う

初回連携時には、GitHubリポジトリをGCPプロジェクトにリンク（ホスト接続）する必要があります。

  1. Cloud Buildのトリガー画面 にアクセス
  2. 画面上部の「リポジトリを接続」ボタンをクリック
  3. 「GitHub（Cloud Build GitHub App）」を選択し、「続行」
  4. GitHubにログイン後、Cloud Build GitHub App にリポジトリアクセスを許可（全リポジトリ or 特定リポジトリ）
  5. 接続が成功すると「接続済みのホスト」として一覧に表示され、トリガー作成時に選択可能になります

🔒 GitHub連携は最初にこの「ホスト接続」を行わないと、後続のリポジトリ選択やトリガー作成ができません。

事前条件

  • GitHubアカウントを持っている
  • 該当リポジトリをGitHub上に作成済み
  • GCPプロジェクトでCloud Build APIを有効化済み

ステップバイステップ解説

  1. Cloud Buildのトリガー画面にアクセス
  2. リポジトリの接続
    • 「ソースリポジトリを選択」で「GitHub（Cloud Build GitHub App）」を選択
    • 初回接続時は「GitHubアカウントと連携」を求められる →「GitHubと接続」を選び、OAuth認可画面で承認
    • 表示されたGitHub組織とリポジトリ一覧から対象リポジトリを選択
  3. トリガーの設定
    • トリガー名：go-cloudrun-build
    • イベント：ブランチに push されたとき
    • ブランチ：main（または ^main$）
    • ビルド構成：cloudbuild.yaml を選択（または リポジトリにあるファイルを使用）
  4. 確認と作成
    • 設定内容を確認して「作成」をクリック

よくあるエラーと対処法

症状原因対策
GitHubアカウントが表示されないGCPとGitHub連携未認可GitHub Marketplace: Cloud Build Appで手動承認
リポジトリが一覧に出ないGitHubに対するOAuth権限不足Cloud Build GitHub App のアクセス範囲を「全リポジトリ」に一時的に変更
トリガー作成後に自動ビルドが発火しないPush先ブランチ名の不一致main ではなく master や develop を使っていないか確認

これでGitHubにコードをPushするたびにCloud Buildが自動で実行され、Cloud Runへのデプロイまで完了します。

5-5. 動作確認とログの確認

🔥 よくあるエラーと対処（実体験ベース）

❌ エラー1：Cloud Buildがリージョン制限で失敗
failed precondition: due to quota restrictions, Cloud Build cannot run builds in this region
  • 原因：新しいGCPプロジェクトでは asia-northeast1 でのCloud Build実行にクォータ制限があることがある
  • 対処：Cloud Buildのリージョンを --region=global に変更すると実行可能
❌ エラー2：サービスアカウントにログ出力権限がなく失敗
The service account ... does not have permission to write logs to Cloud Logging.
  • 原因：サービスアカウントに roles/logging.logWriter が付与されていない
  • 対処：以下のコマンドで権限を追加
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:cloudbuild-deployer@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/logging.logWriter"
❌ エラー3：Cloud Buildでlogs_bucketが指定されていない
if 'build.service_account' is specified, ... must specify 'logs_bucket' or use logging option
  • 原因：Cloud Buildトリガーでサービスアカウントを指定したが、ログ出力先のバケットまたはロギングオプションが未設定
  • 対処：cloudbuild.yaml に以下を追記することで解決
options:
  logging: CLOUD_LOGGING_ONLY
  • 補足：この設定により Cloud Logging のみにログ出力され、logs_bucket を指定せずにビルドが成功するようになります
❌ エラー4：Artifact Registry リポジトリが存在しない
name unknown: Repository "cloud-run-source-deploy" not found
  • 原因：指定されたリポジトリ cloud-run-source-deploy が作成されていない
  • 対処：以下のコマンドで事前にリポジトリを作成する必要があります：
gcloud artifacts repositories create cloud-run-source-deploy \
  --repository-format=docker \
  --location=asia-northeast1 \
  --description="Cloud Run Auto Deploy Repo"
  • または、cloudbuild.yaml 内のリポジトリ名を既存のもの（例：go-cloudrun-app）に合わせて変更する

💡 GCPでは、Artifact Registry のリポジトリは明示的に作成する必要があり、存在しないと push や deploy に失敗します。

以下は、実際にこの構成を動作させた際に発生したエラーとその解決策です。

GitHubに変更をPushしてトリガーを発火させた後、以下のように確認できます：

成功すれば、変更が自動でCloud Runに反映されるCI/CDの仕組みが完成しています。

6. Cloud Runでアプリを公開

ビルドとデプロイの自動化が完了したら、実際にCloud Run上でアプリケーションが公開されているかを確認しましょう。

6-1. サービスの確認

Cloud ConsoleのCloud Runセクションから、go-cloudrun-appというサービスが作成されていることを確認できます。

6-2. 公開URLへのアクセス

Cloud Runのサービスページに記載された URL にアクセスすれば、先ほどの"Hello, Cloud Run"アプリが動作していることが確認できます。

例：https://go-cloudrun-app-xxxxx.a.run.app

ブラウザでアクセスして Hello, World! のようなレスポンスが得られれば成功です。

6-3. 環境変数の更新と再デプロイ

アプリの挙動を変更するには、TARGET 環境変数を変更してCloud Runに再デプロイすればOKです。

gcloud run deploy go-cloudrun-app \
  --image asia-northeast1-docker.pkg.dev/$PROJECT_ID/go-cloudrun-app/server:$TAG \
  --region asia-northeast1 \
  --platform managed \
  --set-env-vars TARGET=Gopher \
  --allow-unauthenticated

6-4. Cloud Run サービスの停止・削除（Console 操作）

開発検証が終わったら、不要な課金を防ぐために Console からサービスを停止または削除 します。

操作Console 手順補足
Traffic を 0 にして一時停止1. Cloud Console → Cloud Run2. 対象サービスをクリック3. 編集 & デプロイ新しいリビジョン を選択4. トラフィック分割 で 0 % に設定し、保存 & デプロイ料金は 0、設定は保持される
サービスを削除1. Cloud Console → Cloud Run2. サービス右端の ︙ メニュー → 削除3. 確認ダイアログで 削除 をクリック設定ごと完全削除。Artifact Registry のイメージは別途削除可
イメージを削除1. Cloud Console → Artifact Registry2. 該当リポジトリを開く3. イメージのチェックボックスを選択 → 削除ストレージ費用を削減

ポイント: Cloud Run はアクセスがなければ自動で 0 インスタンスになりますが、トラフィック 0 % にしておくと確実に課金されません。完全に不要ならサービス削除まで行いましょう。

7. モニタリングとログ確認

Cloud Runにデプロイされたアプリは、すべてのログをCloud Loggingに出力しています。これにより、アプリの挙動やエラーをリアルタイムで把握可能です。

7-1. Cloud Loggingでの確認

  1. ログビューア にアクセス
  2. 「リソース」で Cloud Run Revision を選択
  3. 関連ログが表示される（Hello, World! のレスポンスなど）

7-2. Goアプリからログを出力する

Goコード内で以下のように log パッケージを使えば、Cloud Loggingに自動で反映されます：

import "log"

log.Println("Request received")

Cloud Loggingにはタイムスタンプや構造化情報も付与されるため、問題発生時のトラブルシュートにも有効です。

8. より実用的な構成への展望

ここまでで最低限のGo×GCP構成が完成しましたが、現実的なサービスを開発するにはさらなる要素が必要です。次回以降のステップとして以下のような拡張が考えられます：

8-1. Cloud Firestoreとの連携

  • Cloud Firestoreを用いたデータ永続化
  • Go SDKを利用したドキュメントの読み書き
  • JSON APIとの組み合わせ

8-2. Pub/Subによる非同期処理

  • 非同期イベント処理の導入
  • Cloud RunとPub/Subの連携（Pushサブスクリプション）
  • イベントドリブンアーキテクチャの基本

8-3. Cloud Schedulerとの定期実行

  • バッチ処理や定期実行の構成
  • Cloud Run JobsまたはHTTPエンドポイントとの統合

8-4. Cloud MonitoringとError Reporting

  • サービスのパフォーマンス可視化
  • エラーレポート自動通知（Slackやメール連携）

これらを取り入れることで、開発・運用しやすく、スケーラブルかつ信頼性の高いシステムを構築できます。

9. まとめ

本記事では、Goで書いたWebアプリをCloud Run上で動作させるまでの一連の手順を解説しました。

  • GoとGCPの相性の良さを確認
  • プロジェクトと環境の初期セットアップ
  • GoでのHTTPサーバ作成とDocker化
  • Cloud BuildでのCI/CDパイプライン構築
  • Cloud Runでのアプリ公開とログ監視

この構成は小規模なアプリケーションに留まらず、大規模なマイクロサービス構成にも発展可能なベースになります。今後はFirestoreやPub/Subなどを用いた構成にも挑戦し、クラウドネイティブなアーキテクチャをより深く理解していきましょう。

次回はCloud Firestoreとの連携を深掘りします。お楽しみに！

補足：Cloud Runと他サービスの使い分け

GCPにはCloud Runの他にも、アプリケーションを実行できる選択肢がいくつか存在します。目的やユースケースに応じて適切に選択しましょう。

サービス特徴向いているユースケース
Cloud Runコンテナをフルマネージドで実行。0スケールも可。HTTPリクエスト駆動。Web API、Webhook、小〜中規模マイクロサービス
App Engineアプリコードのみをデプロイすれば動作。古くからあるPaaS型。フルマネージドでサクッと動かしたい場合
Cloud Functions関数単位でのデプロイ。イベント駆動。最小単位のサーバーレス。簡易処理、Webhook、Pub/Subトリガー
GKE (Kubernetes)自由度が高く、大規模構成が可能。運用コストは高め。複雑なワークロード、大規模分散処理

Cloud Runは中でも「ちょうどいい自由度と手軽さ」を提供するサービスとして位置づけられており、マイクロサービス開発の第一歩に最適です。

公開リポジトリ（GitHub）

この記事のコード一式は以下のGitHubリポジトリで公開しています。

👉 GitHub: https://github.com/lancelot89/go-cloudrun-example

リポジトリには以下が含まれています：

  • main.go（Goアプリケーション本体）
  • Dockerfile（マルチステージビルド対応）
  • cloudbuild.yaml（Cloud Build設定）
  • README.md（セットアップ・デプロイ手順）

ご自由にクローン・フォークしてお使いください。スターも歓迎です！

  • この記事を書いた人

ふくまる

機械設計業をしていたが25歳でエンジニアになると決意して行動開始→ 26歳でエンジニアに転職→ 28歳でフリーランスエンジニアに→ 現在、34歳でフリーランス7年目 Go案件を受注中 Go,GCPが得意分野

-Go×GCP