Cloud Foundry から Cloud Run への移行ガイドでは、Cloud Foundry サービスと Cloud Run サービスの違いに関する背景情報を提供し、Cloud Foundry アプリケーションを移行して Cloud Run のコンテナで実行するために必要な内容について説明します。この移行ページでデータ移行は説明されていません。
移行対象の Cloud Foundry アプリケーション
Cloud Run は、ステートレス HTTP アプリケーションまたは HTTP/2 アプリケーションを実行するように設計されています。Cloud Foundry アプリケーションは、次の条件を満たさない限り移行できません。
- HTTP または HTTP/2（gRPC を含む）を使用する。
PORT環境変数に基づいてトラフィックをリッスンする。- アプリケーションごとに異なるパスでの転送を必要としない。
- トラフィックをプロキシするための、従来の Cloud Foundry の「転送サービス」を必要としない。
- インスタンス ID や特定の起動順序を必要としない。
- 個々のインスタンスをアドレス指定できることを必要としない。
- 環境に副作用を与えることなく開始できる（データベースの移行開始など）。
Cloud Foundry と Cloud Run の違いを理解する
Cloud Foundry と Cloud Run はどちらもソースのデプロイ エクスペリエンスは共通していますが、ワークロードのコンテナ化、アプリケーション構成、サービス定義に対するプラットフォームのアプローチ方法に大きな違いがあります。次の表に、Cloud Foundry と Cloud Run の違いを示します。
| アプリ コンポーネント | Cloud Foundry | Cloud Run コンテナ イメージのデプロイ |
Cloud Run ソースのデプロイ Dockerfile |
Cloud Run ソースのデプロイ Buildpack |
|---|---|---|---|---|
| コンテナ化 | CF Buildpacks v2 | なし | Cloud Build | Cloud Build |
| ベースイメージ |
cflinuxfs3（Ubuntu 18.04） cflinuxfs4（Ubuntu 22.04） |
独自のコンテナ イメージを使用する | Dockerfile 指定 | Ubuntu 18.04 または Ubuntu 22.04 |
| Service の定義 | manifest.yaml |
service.yaml |
||
| 無視リスト | .cfignore |
.gcloudignore |
||
| サービス メタデータ | VCAP_* 環境変数 |
Workload Identity、クラウド シークレット | ||
| サポートされているコンテナ形式 | Droplet | Docker イメージ Manifest V2、スキーマ 1、スキーマ 2、OCI 形式 | ||
移行方法
Cloud Foundry アプリケーションを移行するには:
移行の例
Spring Music の例では、Cloud Foundry のコア コンポーネントを使用して Spring Music を OCI 互換のイメージとして再ビルドし、Cloud Run にデプロイします。この例は、リフト＆シフトの OCI コンプライアンス戦略に従っています。