將第 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 觸發的函式。
升級程序總覽
以下是升級程序的概略說明：
以下各節將詳細說明這個程序。
開始升級總覽
- 開始升級時 (使用 Google Cloud CLI 或 Google Cloud 控制台)，升級工具會建立臨時的第 2 代函式，這是原始第 1 代函式的副本。這個第 2 代函式：
- 做為原始第 1 代函式與最終完全升級函式之間的橋樑。
- 名稱、程式碼和設定與原始第 1 代函式相同。
- 如果升級 HTTP 函式，會與原始第 1 代函式使用相同的
cloudfunctions.net網址，並具有run.appCloud Run 網址。- 升級開始後，第 1 代函式和第 2 代函式副本都會指派至同一個
cloudfunctions.net網址。向cloudfunctions.net網址傳送要求時，流量仍會轉送至第 1 代函式。複製的第 2 代函式也有 Cloud Runrun.app網址。在下一個步驟中重新導向流量前，第 2 代函式網址不會收到流量。
- 升級開始後，第 1 代函式和第 2 代函式副本都會指派至同一個
- 如果是升級 Pub/Sub 函式，請使用與第 1 代函式相同的 Pub/Sub 主題，但目前沒有訂閱項目。
- 如果升級 HTTP 函式，會與原始第 1 代函式使用相同的
- 請注意，如果您未將依附元件固定在特定版本，新建立的第 2 代函式副本可能會使用較新的依附元件版本。
- 第 1 代函式會繼續列在第 1 代Google Cloud 控制台中，而第 2 代臨時副本則會首次出現在 Cloud Run 控制台中。
範例：下表顯示初始升級步驟期間的 HTTP 函式狀態。
| 函式 | 提供流量？ | 控制台是否顯示？ |
|---|---|---|
| 原始第 1 代函式 | 是，從 cloudfunctions.net 網址 |
是，第一代主機。 |
| 新第 2 代副本 | 不會。這個函式同時有 cloudfunctions.net 和 run.app 網址，但必須完成重新導向步驟，才會開始提供流量。 |
是，Cloud Run 控制台。 |
重新導向流量總覽
- 重新導向流量時，結果取決於要升級的函式是 HTTP 函式還是 Pub/Sub 函式：
- 如果您要升級 HTTP 函式，導向
cloudfunctions.net網址的流量會前往第 2 代函式。第 1 代函式仍會存在，但不會收到任何流量。 - 如果您要升級 Pub/Sub 函式，第 2 代函式觸發程序會使用相同的 Pub/Sub 主題，但會建立新的訂閱項目，將訊息傳送至 Cloud Run 函式。舊的訂閱方案會遭到刪除。
- 如果您要升級 HTTP 函式，導向
- 第 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 代函式 | 是。 | 是，第一代主機。 |
| 新第 2 代副本 | 不用 | 不再顯示在 Cloud Run 控制台中，但仍存在。 |
中止總覽
您可以在提交前隨時中止升級。一旦確認，升級就無法復原。
範例：下表顯示如果中止升級，HTTP 函式的狀態會如何。
| 函式 | 提供流量？ | 控制台是否顯示？ |
|---|---|---|
| 原始第 1 代函式 | 是。 | 是，第一代主機。 |
| 第 2 代副本 | 不用 | 不再顯示於 Cloud Run 控制台，且已不存在。 |
提交總覽 (不可逆)
- 完成升級後，第 1 代函式的升級程序就會完成。這項操作無法復原。
- 系統會根據 Cloud Run Admin API，將臨時第 2 代函式轉換為正式的 Cloud Run 函式。
- 這等同於對第 2 代函式執行
detach指令。detach指令會將 Cloud Functions 第 2 代函式從現有 API 環境中分離。 - 升級後，您只能使用 Cloud Run Admin API 和 Cloud Run 工具與函式互動。
- 這等同於對第 2 代函式執行
- 系統會刪除第 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」YAML分頁標籤查看函式詳細資料，包括 Cloud Run
run.app網址。
事前準備
開始升級前，請確認您符合下列先決條件：
您已啟用 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 函式。如要瞭解如何升級第 1 代 Pub/Sub 函式，請參閱後續章節。
如後續章節所述重新導向流量並完成升級後，與原始第 1 代 HTTP 函式相關聯的 cloudfunctions.net 網址會繼續運作，並將流量導向新的 Cloud Run 函式。
開始升級 HTTP 函式
這個步驟會建立第 1 代函式的第 2 代副本。
主控台
前往 Google Cloud 控制台的「Functions (1st gen)」(函式 (第 1 代)) 頁面：
找出要升級的第 1 代函式，並確認「升級狀態」欄中的狀態為「可升級」。
按一下函式名稱，顯示詳細資料頁面。
在函式詳細資料頁面中，按一下「Upgrade eligible」(符合升級資格) 下方的「Upgrade」(升級)。
按照提示開始升級程序。
完成這個步驟後，系統會顯示「升級進行中」面板，提示您點選「前往 Cloud Run」連結，繼續進行升級程序。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --setup-config 旗標：
gcloud beta functions upgrade FUNCTION_NAME --setup-config
將 FUNCTION_NAME 替換為第 1 代函式的名稱。
開始升級後：
- 第 1 代函式會繼續將流量導向原始網址。如要查看這個網址，請前往Functions (第 1 代) 控制台的函式詳細資料頁面，然後開啟「Trigger」(觸發條件) 分頁。
系統會建立第 2 代函式，做為第 1 代函式的副本。第 2 代函式與第 1 代函式使用相同的
cloudfunctions.net網址，以及新的 Cloud Runrun.app網址。如要查看這兩個網址，請前往 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 函式的流量
此時，您應測試原始函式和副本的網址。請先確認這些功能正常運作，再繼續操作。如果遇到問題，請中止升級，返回乾淨狀態，解決第 1 代函式中的任何基本問題。
重新導向步驟會將流量從第 1 代 Cloud Functions 網址重新導向至第 2 代函式副本。
主控台
- 在 Cloud Run functions 詳細資料頁面的「Upgrade in progress」(升級進行中) 面板中，按一下「Go to Cloud Run」(前往 Cloud Run)。
- 按一下「測試函式」測試函式 (選用，但強烈建議)。
- 準備就緒後，請按一下「重新導向流量」。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --redirect-traffic 旗標：
gcloud beta functions upgrade FUNCTION_NAME --redirect-traffic
重新導向流量後，第 2 代函式副本會將流量提供給函式網址 (cloudfunctions.net) 和 Cloud Run 網址 (run.app)。
重新導向後測試 HTTP 函式
驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出結果會顯示環境為
2nd gen。使用控制台記錄工具，比較第 2 代函式副本與原始第 1 代函式。
排解重新導向問題
在下列情況下，重新導向會失敗：
- 您未執行上一個步驟 (
--setup-config)。
復原 HTTP 函式的流量
如果還沒準備好升級，可以將流量復原至第 1 代函式。
主控台
在 Cloud Run 控制台的 Cloud Run functions 詳細資料頁面中，從「Upgrade in progress」(升級進行中) 面板點選「Rollback traffic」(回溯流量)。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --rollback-traffic 旗標：
gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic
復原流量後：
- 第 1 代函式會將流量提供給
cloudfunctions.net網址。 - 第 2 代函式副本仍可使用，您可以使用其
run.app網址觸發該副本。
您可以按照下列步驟驗證函式環境。輸出內容應顯示函式環境為 1st gen：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
如果尚未將流量重新導向至第 2 代函式，系統就無法復原。
完成 HTTP 函式升級
這個步驟會完成升級程序，之後就無法中止程序。執行這個步驟前，請務必徹底測試函式。
主控台
在 Cloud Run 控制台的 Cloud Run functions 詳細資料頁面中，按一下「升級進行中」面板中的「確認升級」。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --commit 旗標：
gcloud beta functions upgrade FUNCTION_NAME --commit
升級完成後：
- 系統會刪除第 1 代函式，並分離第 2 代函式副本，使其成為完整的 Cloud Run 函式。
- Cloud Run 函式會保留
cloudfunctions.net網址和新的run.app網址。 您可以驗證第 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 函式相同，但有幾項額外考量：
Cloud Run 不支援在失敗時停用重試功能，但這是第 1 代的預設設定。因此您可能同時擁有這兩種函式。升級工具的用途取決於這項設定：
- 如果第 1 代函式已停用重試功能 (第 1 代的預設設定)，升級工具會建立 Eventarc Pub/Sub 觸發程序，以及無法傳送郵件的佇列 (DLQ)。升級工具會為訂閱項目及其主題設定身分與存取權管理 (IAM) 政策。升級完成後，無效信件佇列主題會儲存未傳送的訊息，您可以建立無效信件佇列的新訂閱項目，以便擷取這些訊息。
- 如果第 1 代函式已啟用重試功能，升級工具會建立具有預設設定的 Eventarc Pub/Sub 觸發程序。
開始升級 Pub/Sub 函式
這個步驟會建立第 1 代函式的第 2 代副本。
主控台
前往 Google Cloud 控制台的「Cloud Functions (第 1 代)」頁面：
找出要升級的第 1 代函式，並確認「升級狀態」欄中的狀態為「可升級」。
按一下函式名稱，顯示詳細資料頁面。
在函式詳細資料頁面中，按一下「Upgrade eligible」(符合升級資格) 下方的「Upgrade」(升級)。
這個階段完成後，系統會顯示「升級進行中」面板，提示您點選「前往 Cloud Run」連結，繼續升級程序。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --setup-config 旗標：
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 代函式會繼續將流量導向原始網址。
- 系統會建立第 1 代函式的第 2 代副本。您可以使用 Cloud Run 網址觸發這項函式。
- 第 1 代函式會繼續將流量導向至其
cloudfunctions.net網址。
在開始升級步驟後測試 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 觸發條件，並確認函式是否如預期般回應觸發條件：
- 在 Cloud Run 控制台中選取函式，然後開啟「觸發條件」分頁。
- 按一下「新增觸發條件」，然後在「Eventarc 觸發條件」面板中，選取要觸發函式的主題。根據預設，函式會在訊息發布至主題時觸發。
- 在「升級進行中」面板中，按一下「測試函式」。
- 在開啟的 Cloud Shell 專用 Cloud Code 視窗中，將訊息發布至「觸發條件」分頁中新增的主題。
- 前往 Cloud Run 控制台的「可觀測性」>「記錄」，確認函式已發布訊息。或者，您也可以使用 Cloud Shell 適用的 Cloud Code 中的指令列，查看記錄輸出內容。
舉例來說，假設您有一個基本的 Hello World 函式，會發布問候訊息。指定新觸發條件後，您可以在 Cloud Shell 適用的 Cloud Code 中測試，方法如下：
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 網址重新導向至第 2 代函式副本。
主控台
- 在 Cloud Run functions 詳細資料頁面的「Upgrade in progress」(升級進行中) 面板中，按一下「Go to Cloud Run」(前往 Cloud Run)。
- 按一下「測試函式」測試函式 (選用，但強烈建議)。
- 準備就緒後，請按一下「重新導向流量」。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --redirect-traffic 旗標：
gcloud beta functions upgrade FUNCTION_NAME --redirect-traffic
重新導向流量後，第 2 代函式會同時透過 Cloud Functions 網址和 Cloud Run 網址提供流量。
重新導向流量後測試 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 詳細資料頁面的「Upgrade in progress」(升級進行中) 面板中，按一下「Rollback traffic」(回溯流量)。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --rollback-traffic 旗標：
gcloud beta functions upgrade FUNCTION_NAME --rollback-traffic
復原流量後：
- 函式會還原至初始升級步驟後立即的狀態。
- 第 1 代函式會將流量提供給
cloudfunctions.net網址。 第 2 代副本仍可使用，您可以使用 Cloud Run 網址觸發該副本。
您可以驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出內容應顯示函式環境為
1st gen。將訊息發布至目的地主題，即可觸發第 1 代函式。
如果尚未將流量重新導向至 Cloud Run 函式，系統就無法復原。
完成 Pub/Sub 函式升級
這個步驟會完成升級程序，之後就無法中止程序。這個步驟無法復原。 執行這個步驟前，請務必徹底測試函式。
主控台
在 Cloud Run functions 詳細資料頁面的「升級進行中」面板中，按一下「完成升級」。
gcloud
執行 gcloud beta functions upgrade 指令並加上 --commit 旗標：
gcloud beta functions upgrade FUNCTION_NAME --commit
升級完成後：
- 系統會刪除第 1 代函式。
- Cloud Run 函式會保留
cloudfunctions.net網址。 - 您可以確認清單中不再顯示該函式：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
- 您可以驗證 Cloud Run 服務詳細資料：
gcloud run services describe FUNCTION_NAME --format yaml
- 輸出內容會顯示已建立新一代的執行個體。「
Goog-managed-by」標籤的值應為空白。
- 輸出內容會顯示已建立新一代的執行個體。「
- 如果您建立第 1 代函式時未勾選「Retry on Failures」(失敗時重試)，觸發條件的 Pub/Sub 訂閱項目就會有死信佇列 (DLQ)。
- 現在只要將訊息發布至目的地主題，就會觸發 Cloud Run 函式。
在下列情況下，提交會失敗：
- 流量尚未重新導向至 Cloud Run 函式。
- Cloud Run 函式已手動刪除。
取消升級
這項操作會取消升級程序。系統會刪除新的第 2 代函式副本，第 1 代函式則會繼續將流量導向至原始的「cloudfunctions.net」網址。您可以在升級過程中隨時執行這項動作，但必須在提交升級前完成。
如果您使用 Google Cloud 控制台執行升級，使用者介面只允許您在初始升級作業後立即中止程序。「Abort」(中止) 按鈕位於 Functions (第 1 代) 控制台的左上角。如果您使用 Google Cloud CLI，可以在升級作業完成前隨時中止升級，升級完成後就無法復原。
即使您使用 Google Cloud 控制台執行升級程序，仍可使用 Google Cloud CLI 中止函式升級：
gcloud beta functions upgrade FUNCTION_NAME --abort
中止升級後：
- 第 2 代函式副本會遭到刪除。
- 第 1 代函式會將流量提供給
cloudfunctions.net網址。 - 在 Google Cloud 控制台中，函式的升級狀態會從「已複製設定」變回「準備升級」。
您可以確認 Cloud Run 服務不再顯示於清單中：
gcloud run services list
您可以驗證函式環境：
gcloud functions describe --region REGION_NAME FUNCTION_NAME
輸出結果會顯示函式環境為 1st gen。
如果已提交升級作業，取消作業就會失敗。
檢查轉換後的 IAM 政策
在升級過程中，這項工具會盡可能轉換第 1 代 Cloud Functions 與新版 Cloud Run 函式之間的角色和權限。
升級程序會將第 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 權限，身分與存取權管理政策升級就會失敗。呼叫者必須具備專案的 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 function：
gcloud projects get-iam-policy PROJECT_ID | grep "roles/cloudfunctions.invoker" gcloud run services get-iam-policy FUNCTION_NAME
後續步驟
- 進一步瞭解 Cloud Run 函式。