小規模なWebアプリや、個人・小さなチームで運営するサイトでは、サーバーの管理に時間をかけたくないものです。
当社でも、複数のサイトを、Dockerコンテナ化してGoogle CloudのCloud Runで運用し、GitHubへのpushをきっかけに自動でデプロイしています。
この記事では、その基本的な構成と、運用で気を付けたい点を紹介します。
全体の流れ
- 開発者が、GitHubのmainブランチへ変更を取り込む（マージする）。
- GitHub Actionsのワークフローが起動する。
- テストを実行し、Dockerイメージをビルドする。
- イメージをArtifact Registryに登録（push）する。
- Cloud Runが、新しいイメージで新しいリビジョンを作成し、トラフィックを切り替える。
登場するサービスの役割
| サービス | 役割 |
|---|---|
| Cloud Run | コンテナをそのまま実行できるマネージドな実行基盤。 リクエストに応じて自動でスケールし、リクエストがないときは、インスタンスを0まで減らせる。 |
| Artifact Registry | Dockerイメージを保管するレジストリ。 リージョンを指定して、Cloud Runと同じ地域に置ける。 |
| GitHub Actions | テストからデプロイまでを自動化するCI/CD。 リポジトリ内のYAMLで定義する。 |
| IAM（サービスアカウント） | デプロイを実行する権限を、必要最小限に絞って付与する。 |
ワークフローの骨格
実際の定義は、次のような構成になります（値は例です）。
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: google-github-actions/auth@v2 # Google Cloudへの認証
- uses: google-github-actions/setup-gcloud@v2
- run: gcloud auth configure-docker REGION-docker.pkg.dev
- run: |
docker build -t IMAGE:${{ github.sha }} .
docker push IMAGE:${{ github.sha }}
- uses: google-github-actions/deploy-cloudrun@v2
with:
service: SERVICE_NAME
region: REGION
image: IMAGE:${{ github.sha }}
イメージのタグにコミットのハッシュ（github.sha）を使うと、どのコミットのコードが動いているかを、あとから追跡できます。
運用で気を付けたいポイント
1. 認証情報の扱い
サービスアカウントのキーやプロジェクトIDは、リポジトリに書かず、GitHubのシークレットに保存します。
より安全にするには、長期間有効なキーを使わない「Workload Identity連携」の利用を検討してください。
付与する権限は、Cloud Runへのデプロイとイメージのpushに必要なものだけに絞ります。
2. mainブランチの保護と、ローカルでの確認
mainへのマージが本番デプロイに直結するため、マージ前にローカルで docker build して動作を確認します。
ブランチを切ってプルリクエストを作る運用や、プッシュ前の検査（pre-pushフック）で、誤って本番に反映してしまうことを防ぎます。
3. テストと検査を、デプロイの前に置く
テストやリンク切れチェックなどの検査が失敗したら、デプロイしないようにします。
当社の静的サイトでは、ビルド結果の検査をCIに組み込んでいます。
4. コンテナを軽く、起動を速く
Cloud Runは、リクエストがないとインスタンスが0になり、次のリクエストで起動します（コールドスタート）。
イメージを軽くし、起動時の処理を減らすことで、初回のレスポンスを速くできます。
Pythonなら slim 系のベースイメージ、静的サイトならnginxの利用が定番です。
5. 設定値は環境変数で渡す
公開URLやアクセス解析のIDなど、環境で変わる値は、コードに埋め込まず環境変数やビルド引数で渡します。
同じイメージを、複数の環境で使い回せます。
6. 公開範囲の設定
Webサイトとして公開する場合は、未認証のアクセスを許可する設定（roles/run.invoker を allUsers に付与）が必要です。
逆に、社内向けのAPIなどでは、認証を必須にして、意図しない公開を避けます。
7. ログとコストの確認
Cloud Runのログは、Cloud Loggingで確認できます。
最大インスタンス数を設定し、想定外のアクセスでコストが膨らまないよう上限を決めておきます。
Cloud Run以外の選択肢
常時起動のサーバーや、複数のコンテナを細かく制御したい場合は、GKE（Kubernetes）や、Compute Engineが選択肢になります。
当社でも、Kubernetesのマニフェスト（Deployment／Service／Ingress）を用意しているアプリがあります。
一方、静的なサイトであれば、GitHub Pagesで十分な場合もあります。
アクセス量や運用の手間に応じて選ぶのがよいでしょう。
まとめ
Cloud Runと、GitHub Actionsの組み合わせは、小規模なWebアプリを、少ない運用負荷で継続的に届けるのに向いています。
認証情報の管理、デプロイ前の検査、コンテナの軽量化の3点を押さえておけば、安心して運用できます。
当社では、こうした運用を含めて、システム開発の案件を支援しています。
