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

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

このガイドでは、第 1 世代の HTTP 関数と Pub/Sub 関数を、Cloud Run で実行される Cloud Run 関数にアップグレードする方法について説明します。このガイドは、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 世代の関数を作成します。移行プロセスを開始したら、Cloud Storage から関数のソースコードを削除したり、Artifact Registry から関数のコンテナを削除したりしないでください。この第 2 世代の関数は、次のようなものとなります。
- 元の第 1 世代の関数と、完全にアップグレードされた最終的な関数の間のブリッジとして機能します。
- 元の第 1 世代の関数と同じ名前、コード、構成を持ちます。
  - HTTP 関数をアップグレードする場合、元の第 1 世代の関数と同じ cloudfunctions.net URL を持ち、run.app Cloud Run URL も持ちます。
    - アップグレードを開始すると、第 1 世代の関数と第 2 世代の関数のコピーの両方が、同じ cloudfunctions.net URL に割り当てられます。cloudfunctions.net URL にリクエストを送信すると、トラフィックは引き続き第 1 世代の関数にルーティングされます。第 2 世代の関数のコピーには Cloud Run run.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 権限を持つカスタムロールが必要です。pubub.topic.getIAMPermissions ロールと pubsub.topic.setIAMPermissions ロールも必要です。
- 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 関数にアップグレードする方法について説明します。第 1 世代の Pub/Sub 関数をアップグレードする方法については、後のセクションをご覧ください。

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

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

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

コンソール

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

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

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

gcloud

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

gcloud beta functions upgrade FUNCTION_NAME --setup-config

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

アップグレードの開始後は次のようになります。

元の URL へのトラフィックは、引き続き第 1 世代の関数が処理します。この URL は、関数（第 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 関数のトラフィックをロールバックする

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

コンソール

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

gcloud

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

gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic

トラフィックをロールバックした後は、次のようになります。

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

関数の環境は次のコマンドで確認できます。出力で、関数の環境が 1st gen と表示されます。

gcloud functions describe --region REGION_NAME FUNCTION_NAME

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

HTTP 関数のアップグレードをコミットする

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

コンソール

Cloud Run コンソールの Cloud Run 関数の詳細ページの [アップグレード中です] パネルで、[アップグレードをコミット] をクリックします。

gcloud

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

gcloud beta functions upgrade FUNCTION_NAME --commit

アップグレードをコミットした後は、次のようになります。

第 1 世代の関数が削除されます。第 2 世代の関数のコピーが切り離され、完全な Cloud Run 関数になります。
Cloud Run 関数は cloudfunctions.net URL を維持し、同時に新しい run.app 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 関数にリダイレクトされていない場合、コミットは失敗します。

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

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

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

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

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

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

コンソール

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

[関数（第 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 ロールをバインドするように求めるメッセージを表示します。

アップグレードの開始後は次のようになります。

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

アップグレードステップの開始後に 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 関数が手動で削除された。

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

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

コンソール

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

gcloud

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

gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic

トラフィックをロールバックした後は、次のようになります。

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

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

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

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

コンソール

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 関数がトリガーされるようになります。

以下の場合、コミットは失敗します。

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

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

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

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

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

gcloud beta functions upgrade FUNCTION_NAME --abort

アップグレードを中止した後は、次のようになります。

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

次のコマンドで関数の環境を確認できます。

gcloud functions describe --region REGION_NAME FUNCTION_NAME

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

アップグレードがコミット済みの場合、中止オペレーションは失敗します。

変換された 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 関数呼び出し元ロールが変換され、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 関数にアップグレードする

制限事項

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

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

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

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

中止の概要

コミットの概要（元に戻せない）

テストのヒント

始める前に

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

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

コンソール

gcloud

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

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

コンソール

gcloud

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

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

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

コンソール

gcloud

HTTP 関数のアップグレードをコミットする

コンソール

gcloud

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

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

コンソール

gcloud

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

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

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

コンソール

gcloud

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

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

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

コンソール

gcloud

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

コンソール

gcloud

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

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

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

次のステップ

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

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