新しい関数を作成する場合は、Cloud Run のコンソールのクイックスタートをご覧ください。このページの内容は、Cloud Functions v1 API で作成された既存のレガシー関数にのみ適用されます。

このページは Cloud Translation API によって翻訳されました。

第 1 世代の関数を Cloud Run functions にアップグレードする

このガイドでは、第 1 世代の HTTP 関数と Pub/Sub 関数を Cloud Run で実行される Cloud Run functions にアップグレードする方法について説明します。このガイドは、Cloud Functions v1 API を使用して作成された第 1 世代の関数にのみ適用されます。このガイドの手順は、Cloud Functions v2 API または Cloud Functions for Firebase（別のプロダクト）で作成された第 2 世代関数には適用されません。

アップグレードが完了すると、Cloud Run Admin API と Cloud Run ツールを使用してのみ、アップグレードされた関数を操作できます。

制限事項

現時点では、アップグレードツールは HTTP と Pub/Sub によってトリガーされる関数のアップグレードのみをサポートしています。

アップグレードプロセスの概要

アップグレードプロセスの概要は次のとおりです。

第 1 世代の関数を Cloud Run にアップグレードする概要。 — **図 1.** 第 1 世代関数を Cloud Run にアップグレードする手順の概要。

このプロセスの詳細については、以降のセクションで説明します。

アップグレードの開始の概要

アップグレードを開始すると（Google Cloud CLI または Google Cloud コンソールを使用）、アップグレードツールは元の第 1 世代関数のコピーである一時的な第 2 世代関数を作成します。この第 2 世代の関数:
- 元の第 1 世代の関数と完全にアップグレードされた最終的な関数の間のブリッジとして機能します。
- 元の第 1 世代の関数と同じ名前、コード、構成を持ちます。
  - HTTP 関数をアップグレードする場合、元の第 1 世代の関数と同じ cloudfunctions.net URL を持ち、run.app Cloud Run URL も持ちます。
    - アップグレードを開始すると、第 1 世代の関数と第 2 世代の関数のコピーの両方が同じ cloudfunctions.net URL に割り当てられます。cloudfunctions.net URL にリクエストを送信すると、トラフィックは引き続き第 1 世代の関数に転送されます。第 2 世代の関数コピーにも Cloud Runrun.app URL があります。次のステップでトラフィックをリダイレクトするまで、第 2 世代の関数 URL はトラフィックを受信しません。
  - Pub/Sub 関数をアップグレードする場合、第 1 世代の関数と同じ Pub/Sub トピックを使用しますが、サブスクリプションはまだありません。
- 依存関係を特定のバージョンに固定していない場合、新しく作成された第 2 世代関数のコピーで新しい依存関係のバージョンが使用されることがあります。
第 1 世代の関数は、第 1 世代の Google Cloud コンソールに引き続き表示され、その一時的な第 2 世代のコピーが Cloud Run コンソールに初めて表示されます。

例: この表は、最初のアップグレードステップでの HTTP 関数の状態を示しています。

関数	トラフィックの処理	コンソールに表示されるか？
元の第 1 世代の関数	はい、`cloudfunctions.net` URL から	はい、第 1 世代のコンソールです。
第 2 世代の新しいコピー	いいえ。この関数には `cloudfunctions.net` と `run.app` の両方の URL がありますが、リダイレクトステップまでトラフィックを処理しません。	はい。Cloud Run コンソールです。

トラフィックのリダイレクトの概要

トラフィックをリダイレクトする場合、結果はアップグレードする関数が HTTP 関数か Pub/Sub 関数かによって異なります。
- HTTP 関数をアップグレードする場合は、cloudfunctions.net URL に転送されたトラフィックは第 2 世代の関数に転送されます。第 1 世代の関数は引き続き存在しますが、トラフィックは受信しません。
- Pub/Sub 関数をアップグレードする場合、第 2 世代の関数トリガーは同じ Pub/Sub トピックを使用しますが、Cloud Run 関数にメッセージを送信する新しいサブスクリプションを作成します。古いサブスクリプションは削除されます。
第 1 世代の関数が第 1 世代のコンソールから消えます。
gcloud functions describe コマンドを実行すると、関数の環境が第 2 世代になっていることがわかります。
この移行フェーズにはリスクがあります。特に Pub/Sub 関数には次のリスクがあります。
- メッセージの重複: 古いサブスクリプションが削除される前に新しいサブスクリプションが作成されます。この移行期間中、同じ Pub/Sub メッセージが古い関数と新しい関数の両方に送信されることがあります。
- メッセージの損失: Pub/Sub 関数をアップグレードし、トラフィックのリダイレクト後に新しい関数がメッセージを処理できない場合、Pub/Sub メッセージが失われる可能性があります。関数で再試行が無効になっている場合は特にそうです。詳細については、Pub/Sub をアップグレードするをご覧ください。

例: この表は、トラフィックのリダイレクトステップにおける HTTP 関数の状態を示しています。

関数	トラフィックの処理	コンソールに表示されるか？
元の第 1 世代の関数	いいえ。	第 1 世代コンソールには表示されなくなりますが、引き続き存在します。
第 2 世代の新しいコピー	はい。`cloudfunctions.net` URL と `run.app` Cloud Run URL の両方からアクセスできます。	はい。Cloud Run コンソールです。

トラフィックのロールバックの概要

トラフィックをロールバックすると、アップグレードツールは第 2 世代の関数コピーから元の第 1 世代の関数にすべてのトラフィックをロールバックします。これにより、元の第 1 世代の関数がすべてのトラフィックを処理するようになります。第 2 世代の関数は引き続きテストに使用できます。
Pub/Sub 関数をロールバックすると、第 1 世代の関数サブスクリプションが再度作成され、第 2 世代の関数サブスクリプションが削除されます。
トラフィックをロールバックした後にアップグレードを続行する場合は、まずトラフィックを新しい第 2 世代の関数にリダイレクトしてから続行する必要があります。

例: この表は、トラフィックをロールバックした場合の HTTP 関数の状態を示しています。

関数	トラフィックの処理	コンソールに表示されるか？
元の第 1 世代の関数	はい。	はい、第 1 世代のコンソールです。
第 2 世代の新しいコピー	いいえ。	Cloud Run コンソールには表示されなくなりますが、引き続き存在します。

中止の概要

コミットする前であれば、いつでもアップグレードを中止できます。コミットすると、アップグレードは元に戻せなくなります。

例: この表は、アップグレードを中止した場合の HTTP 関数の状態を示しています。

関数	トラフィックの処理	コンソールに表示されるか？
元の第 1 世代の関数	はい。	はい、第 1 世代のコンソールです。
第 2 世代のコピー	いいえ。	Cloud Run コンソールに表示されなくなり、存在しなくなります。

コミットの概要（元に戻すことはできません）

アップグレードを確定すると、第 1 世代関数のアップグレードプロセスが完了します。この操作は取り消せません。
一時的な第 2 世代関数は、Cloud Run Admin API に基づく本格的な Cloud Run 関数に変換されます。
- これは、第 2 世代の関数で detach コマンドを実行することと同じです。detach コマンドは、Cloud Functions v2 関数を既存の API 環境からデタッチします。
- 以降は、Cloud Run Admin API と Cloud Run ツールを使用してのみ、アップグレードされた関数を操作できます。
第 1 世代関数が削除され、すべてのトラフィックがアップグレードされた Cloud Run 関数に転送されます。

例: 次の表に、アップグレードをコミットした後の HTTP 関数の状態を示します。

関数	トラフィックの処理	コンソールに表示されるか？
Cloud Run Admin API に基づく新しい Cloud Run 関数。	はい。`cloudfunctions.net` URL と `run.app` Cloud Run URL の両方からアクセスできます。	はい。Cloud Run コンソールです。
元の第 1 世代の関数	いいえ。	いいえ、存在しません。
第 2 世代のコピー	いいえ。	いいえ、存在しません。

テストのヒント

テストはアップグレードプロセスに不可欠な要素です。

アップグレードツールに慣れるため、非本番環境の関数でテストすることをおすすめします。プロセスを習得し、一貫して成功を収められるようになったら、本番環境の機能のアップグレードを開始できます。

アップグレード中に関数をテストするために使用できるツールと手法を次に示します。

関数の状態が変更されるたびに、Google Cloud CLI の describe コマンドを使用して、関数が存在し、その環境とバージョンが想定どおりであることを確認します。アップグレードする関数の現在の状態に応じて、次のいずれかを使用します。
- Cloud Run:
```
gcloud run services describe FUNCTION_NAME --format yaml
```
- Cloud Functions:
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```
第 1 世代と Cloud Run コンソールの [ロギング] ページを使用して、関数のトラフィックの詳細を確認します。
Cloud Run コンソールを使用して、アップグレードプロセスが進行するにつれて第 2 世代の関数コピーを表示してテストします。
- [トリガー] タブを使用して、アップグレードの開始後に第 2 世代の関数コピーをテストします。
- [YAML] タブを使用して、Cloud Run run.app URL など、関数の詳細を表示します。

始める前に

アップグレードを開始する前に、次の前提条件を満たしていることを確認してください。

Cloud Run API を有効にしている。

gcloud services enable run.googleapis.com

既存の第 1 世代の HTTP 関数または Pub/Sub 関数がある。
必要な IAM ロールがある。
- 関数のサービスアカウントに roles/iam.serviceAccountUser が設定されている必要があります。
- アップグレードを行うには、プロジェクトに対する roles/cloudfunctions.admin ロールまたは同等のロールが必要です。
- no-retry 設定の Pub/Sub 関数には、roles/serviceusage.consumer ロールまたは serviceusage.services.user 権限を持つカスタムロールがあります。
- Pub/Sub 関数のアップグレードを確定するには、roles/pubsub.admin ロールが必要です。ロール roles/pubsub.admin は、プロジェクト内のすべての Pub/Sub リソースに対する管理アクセス権を付与するプロジェクトレベルのロールです。
関数の IAM ポリシーは次のように表示できます。
```
gcloud functions get-iam-policy FUNCTION_NAME
```
関数のサービスアカウントに roles/cloudfunctions.admin が付与されている必要があります。roles/cloudfunctions.admin ロールを付与するには、gcloud functions add-iam-policy-binding コマンドを使用します。次に例を示します。
```
gcloud functions add-iam-policy-binding FUNCTION_NAME \
   --region=REGION \
   --member=serviceAccount:SERVICE_ACCOUNT \
   --role="roles/cloudfunctions.admin"
```
このコマンドの実行時にエラーが発生した場合は、関数が組織のポリシーに準拠していることを確認してください。たとえば、組織で未認証の HTTP 関数が許可されていない場合があります。

メンバーとロールの詳細については、プリンシパルを追加してロールを付与するをご覧ください。

HTTP 関数をアップグレードする

このセクションでは、第 1 世代の HTTP 関数を Cloud Run functions にアップグレードする方法について説明します。第 1 世代の Pub/Sub 関数をアップグレードする方法については、後述のセクションをご覧ください。

次のセクションで説明するように、トラフィックをリダイレクトしてアップグレードを確定すると、元の第 1 世代の HTTP 関数に関連付けられた cloudfunctions.net URL は引き続き機能し、新しい Cloud Run 関数にトラフィックを転送します。

HTTP 関数のアップグレードを開始する

このステップでは、第 1 世代の関数の第 2 世代のコピーが作成されます。

コンソール

Google Cloud コンソールで、[Functions（第 1 世代）] ページに移動します。

Functions（第 1 世代）に移動
アップグレードする第 1 世代の関数を見つけ、[アップグレードステータス] 列のステータスが [アップグレードの準備完了] であることを確認します。
関数名をクリックして、詳細ページを表示します。
関数の詳細ページで、[アップグレード可能] の [アップグレード] をクリックします。
画面の指示に沿ってアップグレードプロセスを開始します。

この手順を完了すると、[アップグレード進行中] パネルが表示され、[Cloud Run に移動] リンクをクリックしてアップグレードプロセスを続行するように求められます。

gcloud

--setup-config フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --setup-config

FUNCTION_NAME は、第 1 世代関数の名前に置き換えます。

アップグレードを開始した後:

第 1 世代の関数は、元の URL へのトラフィックの処理を続行します。この URL は、Functions（第 1 世代）コンソールで関数の詳細ページに移動し、[トリガー] タブを開くと確認できます。
第 1 世代の関数のコピーである一時的な第 2 世代の関数が作成されます。第 1 世代の関数と同じ cloudfunctions.net URL と、新しい Cloud Run run.app URL があります。これらの URL は、Cloud Run コンソールで関数の詳細ページに移動し、[YAML] タブを開くと確認できます。次のコマンドを使用することもできます。
```
gcloud run services describe YOUR_SERVICE_NAME \
    --region YOUR_REGION \
    --format="value(status.url)"
```
第 1 世代の関数の第 2 世代のコピーが存在することを確認できます。
```
gcloud run services describe FUNCTION_NAME --format yaml
```
第 1 世代の関数環境を確認できます。出力には、関数環境が 1st gen と表示されます。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```

アップグレード開始ステップのトラブルシューティング

次の条件では、アップグレードは失敗します。

同じ名前の関数が、同じリージョンとプロジェクトにすでに存在します。
第 1 世代の関数は廃止されたランタイムを使用しているため、サポートされているランタイムで再デプロイするまでアップグレードの対象になりません。
呼び出し元に cloudfunctions.functions.generationUpgrade 権限がない。呼び出し元には、プロジェクトに対する roles/cloudfunctions.admin ロールまたは同等のロールが必要です。

HTTP 関数のトラフィックをリダイレクトする

この時点で、元の関数とそのコピーの両方の URL をテストする必要があります。続行する前に、想定どおりに動作することを確認してください。問題が発生した場合は、アップグレードを中止してクリーンな状態に戻り、第 1 世代関数の根本的な問題に対処します。

リダイレクトステップでは、第 1 世代の Cloud Functions URL から第 2 世代の関数のコピーにトラフィックがリダイレクトされます。

コンソール

Cloud Run functions の詳細ページの [アップグレード進行中] パネルで、[Cloud Run に移動] をクリックします。
[関数をテスト] をクリックして、関数をテストします（省略可ですが、強く推奨します）。
準備ができたら、[トラフィックをリダイレクト] をクリックします。

gcloud

--redirect-traffic フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --redirect-traffic

トラフィックのリダイレクト後、第 2 世代の関数コピーは、関数 URL（cloudfunctions.net）と Cloud Run URL（run.app）の両方にトラフィックを転送します。

リダイレクト後に HTTP 関数をテストする

関数環境を確認します。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```
出力に、環境が 2nd gen として表示されます。
コンソールロギングツールを使用して、第 2 世代の関数のコピーと元の第 1 世代の関数を比較します。

リダイレクトのトラブルシューティング

次の条件では、リダイレクトは失敗します。

前の手順（--setup-config）を実行していません。

HTTP 関数のトラフィックをロールバックする

アップグレードを commit する準備が整っていない場合は、トラフィックを第 1 世代関数にロールバックできます。

コンソール

Cloud Run コンソールの Cloud Run functions の詳細ページの [アップグレード進行中] パネルで、[トラフィックをロールバック] をクリックします。

gcloud

--rollback-traffic フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic

トラフィックをロールバックした後:

第 1 世代の関数は、cloudfunctions.net URL にトラフィックを処理します。
第 2 世代の関数コピーは引き続き使用でき、その run.app URL を使用してトリガーできます。

関数環境は次のように確認できます。出力には、関数環境が 1st gen と表示されます。

gcloud functions describe --region REGION_NAME FUNCTION_NAME

トラフィックを第 2 世代の関数にリダイレクトしていない場合、ロールバックは失敗します。

HTTP 関数のアップグレードを commit する

この手順でアップグレードが完了します。完了後は、プロセスを中止できなくなります。この手順を実行する前に、関数を十分にテストしてください。

コンソール

Cloud Run コンソールの Cloud Run functions の詳細ページの [アップグレード進行中] パネルで、[アップグレードを確定] をクリックします。

gcloud

--commit フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --commit

アップグレードを確定した後:

第 1 世代の関数が削除され、第 2 世代の関数コピーが切り離され、本格的な Cloud Run functions になります。
Cloud Run functions は、新しい run.app URL とともに cloudfunctions.net URL を保持します。
第 1 世代の関数が存在しないことを確認できます。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```

Cloud Run サービスの詳細を確認できます。

gcloud run services describe FUNCTION_NAME --format yaml

出力には、新しい世代が作成され、Goog-managed-by ラベルの値が空になっていることが示されます。

トラフィックが Cloud Run functions の関数にリダイレクトされていない場合、commit は失敗します。

Pub/Sub 関数をアップグレードする

このセクションでは、第 1 世代の Pub/Sub 関数を Cloud Run 関数にアップグレードする方法について説明します。

第 1 世代の Pub/Sub 関数をアップグレードするプロセスは、HTTP 関数のアップグレードと同じ基本パターンに従いますが、いくつかの追加の考慮事項があります。

エラー時の再試行を無効にすることは、Cloud Run でサポートされている機能ではありませんが、第 1 世代ではデフォルト設定です。そのため、両方のタイプの関数が存在する可能性があります。アップグレードツールの動作は、この設定によって異なります。
- 第 1 世代の関数で再試行が無効になっている場合（第 1 世代のデフォルト設定）、アップグレードツールはデッドレターキュー（DLQ）とともに Eventarc Pub/Sub トリガーを作成します。アップグレードツールは、サブスクリプションとそのトピックに Identity and Access Management（IAM）ポリシーを設定します。アップグレードが完了すると、配信不能なメッセージはデッドレターキュートピックに保存されます。このメッセージは、デッドレターキューへの新しいサブスクリプションを作成することで取得できます。
- 第 1 世代の関数で再試行が有効になっている場合、アップグレードツールはデフォルト設定で Eventarc Pub/Sub トリガーを作成します。

Pub/Sub 関数のアップグレードを開始する

この手順では、第 1 世代の関数の第 2 世代のコピーを作成します。

コンソール

Google Cloud コンソールで、Cloud Functions（第 1 世代）ページに移動します。

Functions（第 1 世代）に移動
アップグレードする第 1 世代の関数を見つけ、[アップグレードステータス] 列のステータスが [アップグレードの準備完了] であることを確認します。
関数名をクリックして、詳細ページを表示します。
関数の詳細ページで、[アップグレード可能] の [アップグレード] をクリックします。

このフェーズが完了すると、[アップグレード進行中] パネルが表示され、[Cloud Run に移動] リンクをクリックしてアップグレードプロセスを続行するように求められます。

gcloud

--setup-config フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --setup-config

FUNCTION_NAME は、第 1 世代関数の名前に置き換えます。

必要に応じて、トリガーのサービスアカウントを指定します。

gcloud beta functions upgrade FUNCTION_NAME --setup-config --trigger-service-account=CUSTOM_SA_EMAIL

CUSTOM_SA_EMAIL は、カスタムサービスアカウントのメールアドレスに置き換えます。

トリガーサービスアカウント（デフォルトの Compute Engine サービスアカウントまたは指定されたカスタムサービスアカウント）に run.route.invoke 権限がない場合、システムは roles/run.invoker ロールをバインドするように求めるメッセージを表示します。

アップグレードを開始した後:

第 1 世代の関数は、元の URL へのトラフィックの処理を続行します。
第 1 世代の関数の第 2 世代のコピーが作成されます。Cloud Run URL を使用してトリガーできます。
第 1 世代の関数は、引き続き cloudfunctions.net URL にトラフィックを処理します。

アップグレード開始後の Pub/Sub 関数をテストする

第 1 世代の関数の第 2 世代のコピーが存在することを確認できます。
```
gcloud run services describe FUNCTION_NAME --format yaml
```
第 1 世代の関数環境を確認できます。出力には、関数環境が 1st gen と表示されます。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```
宛先トピックにメッセージを公開して、第 1 世代関数をトリガーします。
新しい関数をテストするには、Pub/Sub トリガーを追加して、関数がトリガーに想定どおりに応答することを確認します。
1. Cloud Run コンソールで関数を選択し、[トリガー] タブを開きます。
2. [トリガーを追加] をクリックし、[Eventarc トリガー] パネルで、関数をトリガーするトピックを選択します。デフォルトでは、メッセージがトピックに公開されると関数がトリガーされます。
3. [アップグレードの進行状況] パネルで、[関数をテスト] をクリックします。
4. 開いた Cloud Code for Cloud Shell ウィンドウで、[トリガー] タブで追加したトピックにメッセージをパブリッシュします。
5. Cloud Run コンソールで、[モニタリング] > [ログ] に移動し、関数がメッセージをパブリッシュしたことを確認します。また、Cloud Code for Cloud Shell のコマンドラインを使用して、ロギング出力を表示することもできます。
たとえば、挨拶を公開する基本的な Hello World 関数があるとします。新しいトリガーを指定したら、Cloud Code for Cloud Shell で次のようにテストできます。
```
gcloud pubsub topics publish YOUR_TOPIC_NAME --message YOUR_NAME
gcloud functions logs read --region YOUR_REGION --limit 50
```

Pub/Sub のアップグレード開始ステップのトラブルシューティング

次の条件では、アップグレードは失敗します。

同じ名前の Cloud Run 関数が、同じリージョンとプロジェクトにすでに存在します。
第 2 世代の関数をアップグレードしようとした。
第 1 世代の関数はすでにアップグレードプロセス中です。
第 1 世代の関数が存在しません。
第 1 世代の関数がエラー状態です。
第 1 世代の関数は、HTTP 関数でも Pub/Sub 関数でもありません。
呼び出し元に cloudfunctions.functions.generationUpgrade 権限がない。呼び出し元には、プロジェクトに対する roles/cloudfunctions.admin ロールまたは同等のロールが必要です。

Pub/Sub 関数のトラフィックをリダイレクトする

このステップでは、第 1 世代の Cloud Functions URL から第 2 世代の関数のコピーにトラフィックをリダイレクトします。

コンソール

Cloud Run functions の詳細ページの [アップグレード進行中] パネルで、[Cloud Run に移動] をクリックします。
[関数をテスト] をクリックして、関数をテストします（省略可ですが、強く推奨します）。
準備ができたら、[トラフィックをリダイレクト] をクリックします。

gcloud

--redirect-traffic フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --redirect-traffic

トラフィックをリダイレクトした後、第 2 世代関数は Cloud Functions URL と Cloud Run URL の両方にトラフィックを転送します。

トラフィックのリダイレクト後に Pub/Sub をテストする

関数環境を確認できます。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```
出力に、環境が 2nd gen として表示されます。
- eventTrigger.retryPolicy は、関数の作成時に指定された再試行ポリシーと一致します。
- eventTrigger.serviceAccountEmail は、デフォルトの Compute Engine サービスアカウントまたは指定されたカスタムサービスアカウントです。
- 宛先トピックにメッセージを公開すると、第 2 世代関数のコピーがトリガーされるようになります。

リダイレクトの Pub/Sub のトラブルシューティング

次の条件では、リダイレクトは失敗します。

前の手順（--setup-config）を実行していません。
Cloud Run functions の関数が手動で削除された。

Pub/Sub 関数のトラフィックをロールバックする

このステップでは、トラフィックが第 1 世代の関数に戻されます。

コンソール

Cloud Run functions の詳細ページの [アップグレード進行中] パネルで、[トラフィックをロールバック] をクリックします。

gcloud

--rollback-traffic フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic

トラフィックをロールバックした後:

関数は、最初のアップグレードステップの直後の状態に戻ります。
第 1 世代の関数は、cloudfunctions.net URL にトラフィックを処理します。
第 2 世代のコピーは引き続き使用でき、Cloud Run URL を使用してトリガーできます。
関数環境を確認できます。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```
出力には、関数環境が 1st gen と表示されます。
宛先トピックにメッセージを公開すると、第 1 世代の関数がトリガーされます。

トラフィックを Cloud Run functions の関数にリダイレクトしていない場合、ロールバックは失敗します。

Pub/Sub 関数のアップグレードを commit する

この手順でアップグレードが完了します。完了後は、プロセスを中止できなくなります。この手順は元に戻せません。この手順を行う前に、関数を十分にテストしてください。

コンソール

Cloud Run functions の詳細ページの [アップグレード進行中] パネルで、[アップグレードを確定] をクリックします。

gcloud

--commit フラグを指定して gcloud beta functions upgrade コマンドを実行します。

gcloud beta functions upgrade FUNCTION_NAME --commit

アップグレードを確定した後:

第 1 世代の関数が削除されます。
Cloud Run 関数は cloudfunctions.net URL を保持します。
関数がリストに表示されなくなったことを確認できます。
```
gcloud functions describe --region REGION_NAME FUNCTION_NAME
```
Cloud Run サービスの詳細を確認できます。
```
gcloud run services describe FUNCTION_NAME --format yaml
```
- 出力には、新しい世代が作成されたことが示されます。Goog-managed-by ラベルの値は空である必要があります。
[失敗時に再試行] をオンにせずに第 1 世代関数を作成した場合、トリガーの Pub/Sub サブスクリプションにはデッドレターキュー（DLQ）があります。
これで、宛先トピックにメッセージを公開すると、Cloud Run functions がトリガーされるようになります。

次の条件では、コミットは失敗します。

トラフィックが Cloud Run functions の関数にリダイレクトされていません。
Cloud Run functions の関数が手動で削除された。

アップグレードを中止する

この操作を行うと、アップグレードプロセスがキャンセルされます。新しい第 2 世代の関数コピーが削除され、第 1 世代の関数は元の cloudfunctions.net URL へのトラフィックの処理を続行します。この操作は、アップグレードをコミットする前のアップグレードプロセス中にいつでも実行できます。

Google Cloud コンソールを使用してアップグレードを実行している場合、UI でプロセスを中止できるのは、最初のアップグレードオペレーションの直後のみです。[中止] ボタンは、Functions（第 1 世代）コンソールの左上にあります。Google Cloud CLI を使用している場合は、アップグレードをコミットする前であればいつでもアップグレードを中止できます。アップグレードをコミットすると、プロセスは元に戻せなくなります。

Google Cloud コンソールを使用してアップグレードプロセスを実行した場合でも、Google Cloud CLI を使用して関数のアップグレードを中止できます。

gcloud beta functions upgrade FUNCTION_NAME --abort

アップグレードを中止した後:

第 2 世代の関数コピーが削除されます。
第 1 世代の関数は、cloudfunctions.net URL にトラフィックを処理します。
Google Cloud コンソールで、関数のアップグレードステータスが [構成がコピーされました] から [アップグレードの準備完了] に戻ります。
Cloud Run サービスがリストに表示されなくなったことを確認できます。
```
gcloud run services list
```

関数環境を確認できます。

gcloud functions describe --region REGION_NAME FUNCTION_NAME

出力には、関数環境が 1st gen として表示されます。

アップグレードをすでに commit している場合、中止オペレーションは失敗します。

変換された IAM ポリシーを確認する

アップグレードプロセス中に、このツールは第 1 世代の Cloud Functions と新しい Cloud Run functions の間で、ロールと権限の変換をベストエフォートで実行します。

アップグレードプロセスでは、第 1 世代の Cloud Functions IAM ロールが同等の Cloud Run ロールに変換されます。

コンバージョンのルール:

roles/cloudfunctions.invoker は roles/run.invoker に変換されます。
roles/cloudfunctions.developer は roles/run.sourceDeveloper に変換されます。
roles/cloudfunctions.viewer は roles/run.sourceViewer に変換されます。
roles/cloudfunctions.admin は roles/run.admin と roles/run.sourceDeveloper に変換されます。

呼び出し元に projects.getIamPolicy 権限または run.setIamPolicy 権限がない場合、IAM ポリシーのアップグレードは失敗します。呼び出し元には、プロジェクトに対する roles/cloudfunctions.admin ロールまたは同等のロールが必要です。

IAM ポリシーのアップグレードを確認する

IAM ポリシーが正しくアップグレードされていることを確認するには、アップグレードプロセスの各段階でポリシーをチェックし、期待どおりの値になっていることを確認します。

関数のアップグレードプロセスを開始します。
```
gcloud beta functions upgrade FUNCTION_NAME --setup-config
```
カスタムロールバインディングが検出されると、出力に警告メッセージが表示されます。
第 1 世代関数に設定された IAM ポリシーが Cloud Run 関数に変換され、アップグレードされていることを確認します。
```
gcloud functions get-iam-policy FUNCTION_NAME
gcloud run services get-iam-policy FUNCTION_NAME
```
プロジェクトレベルの Cloud Run functions 起動元ロールバインディングが変換され、Cloud Run 関数にアップグレードされたことを確認します。
```
gcloud projects get-iam-policy PROJECT_ID | grep "roles/cloudfunctions.invoker"
gcloud run services get-iam-policy FUNCTION_NAME
```

次のステップ

詳しくは、Cloud Run functions をご覧ください。

第 1 世代の関数を Cloud Run functions にアップグレードする

制限事項

アップグレード プロセスの概要

アップグレードの開始の概要

トラフィックのリダイレクトの概要

トラフィックのロールバックの概要

中止の概要

コミットの概要（元に戻すことはできません）

テストのヒント

始める前に

HTTP 関数をアップグレードする

HTTP 関数のアップグレードを開始する

コンソール

gcloud

アップグレード開始ステップのトラブルシューティング

HTTP 関数のトラフィックをリダイレクトする

コンソール

gcloud

リダイレクト後に HTTP 関数をテストする

リダイレクトのトラブルシューティング

HTTP 関数のトラフィックをロールバックする

コンソール

gcloud

HTTP 関数のアップグレードを commit する

コンソール

gcloud

Pub/Sub 関数をアップグレードする

Pub/Sub 関数のアップグレードを開始する

コンソール

gcloud

アップグレード開始後の Pub/Sub 関数をテストする

Pub/Sub のアップグレード開始ステップのトラブルシューティング

Pub/Sub 関数のトラフィックをリダイレクトする

コンソール

gcloud

トラフィックのリダイレクト後に Pub/Sub をテストする

リダイレクトの Pub/Sub のトラブルシューティング

Pub/Sub 関数のトラフィックをロールバックする

コンソール

gcloud

Pub/Sub 関数のアップグレードを commit する

コンソール

gcloud

アップグレードを中止する

変換された IAM ポリシーを確認する

IAM ポリシーのアップグレードを確認する

次のステップ

アップグレードプロセスの概要