🐳

【Private Preview】Docker ComposeからCloud Runへ直接デプロイする新機能を検証してみた

に公開
Docker
Google Cloud
Cloud Run
Google Cloud
compose
tech

はじめに

Google Cloud RunにDocker Composeファイルから直接デプロイできる新機能「gcloud alpha run compose up」がPrivate Previewで提供されています。この機能により、従来のCI/CDパイプラインを構築することなく、ローカルのDocker Compose環境からCloud Runへワンコマンドでデプロイが可能になりました。

詳細は公式ブログをご覧ください：
https://cloud.google.com/blog/products/serverless/cloud-run-and-docker-collaboration

従来のデプロイ方法との違い

従来の方法:

  1. Dockerイメージをビルド
  2. Container RegistryやArtifact Registryにプッシュ
  3. Cloud Runサービスを作成・更新
  4. マルチコンテナの場合は複雑な設定が必要

新機能での方法:

gcloud alpha run compose up

たったこれだけでDocker Composeの設定からCloud Runサービスが作成されます。

この記事で分かること

  • Cloud Run Compose機能の実際の使用感
  • ドキュメントに載っていない制限事項や問題点
  • 設定例とトラブルシューティング
  • 推測を含む内部動作の調査結果

実際に3コンテナ構成のWebアプリケーションを使って検証した結果をもとに、リアルな使用感をお伝えします。

検証環境とデモアプリケーション

サンプルアプリケーションの構成

今回の検証には、以下の3コンテナから構成されるマルチコンテナWebアプリケーションを使用しました：

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Frontend      │    │   Backend API   │    │   Redis Cache   │
│   (web)         │◄──►│   (api)         │◄──►│   (redis)       │
│                 │    │                 │    │                 │
│ TypeScript      │    │ TypeScript      │    │ redis:7-alpine  │
│ Express         │    │ Express         │    │                 │
│ Port: 8080      │    │ Port: 3000      │    │ Port: 6379      │
│ (Dockerfile)    │    │ (api/Dockerfile)│    │ (Docker Hub)    │
└─────────────────┘    └─────────────────┘    └─────────────────┘

各コンテナの役割

  • Frontend (web): TypeScript/Express - ユーザーインターフェース、外部からのアクセスを受け付ける
  • API (api): TypeScript/Express - ビジネスロジック、Redisとの連携処理
  • Redis (redis): キャッシュサーバー、訪問カウンター等のデータ保存

compose.yamlの基本構成

services:
  web:
    build: .
    cpus: 0.5
    x-google-cloudrun-ingress-container: true
    ports:
      - "8080:8080"
    environment:
      - API_URL=http://api:3000
    depends_on:
      - api
      - redis

  api:
    build: ./api
    cpus: 0.5
    expose:
      - "3000"
    environment:
      - REDIS_URL=redis://redis:6379
    depends_on:
      - redis

  redis:
    image: redis:7-alpine
    cpus: 0.5
    expose:
      - "6379"

ファイル構成

├── compose.yaml          # 3サービス定義
├── Dockerfile            # Frontend用
├── package.json          # Frontend依存関係
├── tsconfig.json         # TypeScript設定
├── src/
│   └── index.ts          # Frontend
├── api/
│   ├── Dockerfile        # API用
│   ├── package.json      # API依存関係
│   ├── tsconfig.json     # TypeScript設定
│   └── src/
│       └── index.ts      # API
└── README.md

このサンプルアプリケーションは、マルチコンテナ構成でよく見られるパターン（フロントエンド + API + データベース）の検証用デモです。

基本的な使い方

前提条件

# gcloud v532.0以上が必要
gcloud components install alpha
gcloud auth login
gcloud config set project YOUR_PROJECT_ID

デプロイ実行

compose.yamlがあるディレクトリで以下のコマンドを実行するだけです：

gcloud alpha run compose up --region=asia-northeast1

デプロイが成功すると、以下のような出力が表示されます：

✓ Building and deploying... Done.
✓ Service URL: https://cloud-run-docker-compose-xxxxxxxxxx-an.a.run.app

動作確認

デフォルトで認証が必要に設定されているため、プロキシ経由でアクセスします：

gcloud run services proxy cloud-run-docker-compose --region=asia-northeast1 --port=8081
# http://localhost:8081 にアクセス

サービス削除

gcloud run services delete cloud-run-docker-compose --region=asia-northeast1

たったこれだけでマルチコンテナアプリケーションがCloud Runにデプロイされます。しかし、実際に使ってみると様々な制限事項や問題に遭遇しました。

対応している機能・制限事項

✅ 実際に使用できた機能

基本的なサービス設定

  • build: ビルドコンテキスト指定（内部でCloud Buildが実行される）
  • image: 事前ビルドイメージの使用（Redisで使用）
  • ports: ポートマッピング
  • expose: 内部通信用ポート公開
  • depends_on: サービス起動順序の定義
  • environment: 環境変数の設定
  • cpus: CPU割当の指定

実際に遭遇した問題と解決法

問題1: CPU/メモリ設定の制約

症状: ERROR: Invalid value specified for container memory

メモリの直接指定ができず、CPU値からの自動割当のみ。ドキュメントによると自動割当ルールは以下の通りですが、実際には問題がありました：

  • ≤2 CPU: 1Gi メモリ
  • ≤4 CPU: 2Gi メモリ

  • 4 CPU: 4Gi メモリ

原因: 0.08 CPUを指定すると1Giメモリが割り当てられるが、Cloud Runの制約では0.08 CPUには128Mi〜512Miのメモリが必要。この不整合によりエラーが発生。

解決策: 0.5 CPU以上を指定することで正常にデプロイできた。

問題2: Container NameとService Nameの不一致

症状: ERROR: Dependent container 'xxx' does not exist

原因: container_nameを設定すると、Cloud Runのcontainer-dependenciesはコンテナ名を期待するが、compose.yamlのdepends_onはサービス名を参照するため不整合が発生。

解決策: container_nameを削除してサービス名をそのままコンテナ名として使用する。

これらの問題を解決するため、最初に示した設定のCPU値を0.5に変更し、container_nameを削除することで、3コンテナ構成のアプリケーションが正常にCloud Runにデプロイできました。

内部動作の解析

gcloud --verbosity=debugで詳細ログを確認し、内部でどのような処理が行われているかを調査しました。

処理フロー

  1. run-composeツールの実行

    • 内部でrun-compose up compose.yaml --repo [ARTIFACT_REGISTRY_URL]が実行される

  2. YAML変換

    • compose.yamlをKnative Service YAML形式に変換
    • out/cloud-run-docker-compose-service.yamlに出力される

  3. Cloud Buildでのイメージビルド

    • ソースコードがGCSバケットにアップロード
    • gcr.io/cloud-builders/dockerを使用してビルド
    • Artifact Registryにプッシュ

  4. Cloud Runサービスのデプロイ

    • 生成されたYAMLを使用してgcloud run services replace相当の処理を実行（推測）

注目すべき点

  • 自動イメージビルド: gcloud builds submit相当の処理が内部で実行される（推測）
  • YAML生成: compose.yamlが直接使われるのではなく、Cloud Run用のYAMLに変換される
  • リソース自動割当: CPU値からメモリが自動計算される（ここで前述の問題が発生）

実際に生成されたYAMLを確認することで、どのような設定がCloud Runに適用されているかを把握できます。

従来手法との比較

メリット

1コマンドでのデプロイ

従来の方法では複数のステップが必要でしたが、gcloud alpha run compose up一つでデプロイが完了します。

ローカル開発との親和性

Docker Composeファイルをそのまま利用できるため、ローカル開発環境とデプロイ環境の設定を統一できます。

デメリット

Docker Compose互換性の制限

すべてのDocker Compose機能がサポートされているわけではなく、思わぬエラーに遭遇することがあります。

詳細な設定制御が困難

CPU/メモリの細かい調整など、Cloud Run固有の詳細設定は従来の方法の方が柔軟に行えます。

まとめ

Cloud Run Compose機能（gcloud alpha run compose up）は、Docker ComposeからCloud Runへの直接デプロイを可能にする便利な機能です。

実際に使ってみた感想

良かった点

  • ワンコマンドでマルチコンテナアプリケーションがデプロイできる手軽さ
  • ローカル開発環境との設定統一による開発効率の向上
  • 内部動作の調査により、compose.yamlがどのようにCloud Runに変換されるかを理解できた

苦労した点

  • CPU/メモリ自動割当の不整合による予期しないエラー
  • container_nameと依存関係の名前解決問題
  • Docker Compose機能の一部制限

今後への期待

Private Preview段階のため現在は制限事項もありますが、開発・プロトタイピングには有用な機能です。GA版では、より多くのDocker Compose機能のサポートや、リソース設定の改善が期待されます。

課題はありつつも、ワンコマンドでマルチコンテナアプリケーションをCloud Runにデプロイできる体験は便利でした。

参考リポジトリ

本記事で使用したサンプルコード：
https://github.com/cozy-corner/cloud-run-docker-compose

Discussion