如要部署、刪除及修改函式,您可以使用 Firebase CLI 指令,或是在函式原始碼中設定執行階段選項。
部署函式
如要部署函式,請執行以下 Firebase CLI 指令:
firebase deploy --only functions
根據預設,Firebase CLI 會同時在來源內部署所有函式。如果您的專案包含超過 5 個函式,建議您使用 --only
旗標搭配特定函式名稱,只部署您編輯的函式。以這種方式部署特定函式可加快部署程序,並避免超出部署配額。例如:
firebase deploy --only functions:addMessage,functions:makeUppercase
部署大量函式時,您可能會超過標準配額,並收到 HTTP 429 或 500 錯誤訊息。如要解決這個問題,請將函式部署在 10 個以下的群組。
如需可用指令的完整清單,請參閱 Firebase CLI 參考資料。
根據預設,Firebase CLI 會在 functions/
資料夾中尋找原始碼。您可以視需要在程式碼集中或多組檔案整理函式。
刪除函式
您可以透過下列方式刪除先前部署的函式:
- 在 Firebase CLI 中透過
functions:delete
明確提出 - 明確用於 Google Cloud 控制台。
- ,默示。
所有刪除作業都會提示您進行確認,然後再將函式從實際工作環境中移除。
Firebase CLI 中的明確函式刪除支援多個引數和函式群組,可讓您指定在特定地區執行的函式。 此外,您也可以覆寫確認提示。
# Delete all functions that match the specified name in all regions. firebase functions:delete myFunction
# Delete a specified function running in a specific region. firebase functions:delete myFunction --region us-east-1
# Delete more than one function firebase functions:delete myFunction myOtherFunction
# Delete a specified functions group. firebase functions:delete groupA
# Bypass the confirmation prompt. firebase functions:delete myFunction --force
透過隱含函式刪除功能,firebase deploy
會剖析來源,並從實際工作環境中移除所有已從檔案中移除的函式。
修改函式的名稱、區域或觸發條件
如果您要重新命名或變更區域或觸發條件,以處理處理實際工作環境流量的函式,請按照本節的步驟操作,以免在修改期間遺失事件。在執行這些步驟前,請先確認您的函式為「冪等」,因為新版本和舊版函式會在變更期間同時執行。
重新命名函式
如要重新命名函式,請在來源中建立新的函式經過重新命名版本,然後執行兩個獨立的部署指令。第一個指令會部署新命名的函式,第二個指令則會移除先前部署的版本。例如,如果您有要呼叫 webhook
的 Node.js 函式,且希望改為 webhookNew
,請修改程式碼,如下所示:
// before
const functions = require('firebase-functions');
exports.webhook = functions.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions');
exports.webhookNew = functions.https.onRequest((req, res) => {
res.send("Hello");
});
接著執行下列指令,部署新函式:
# Deploy new function called webhookNew firebase deploy --only functions:webhookNew # Wait until deployment is done; now both webhookNew and webhook are running # Delete webhook firebase functions:delete webhook
變更函式的區域或區域
如果您要為處理實際工作環境流量的函式變更指定地區,可以依序執行下列步驟,避免事件遺失:
- 重新命名函式,並視需要變更區域或區域。
- 部署重新命名的函式,以便在兩組區域中暫時執行相同的程式碼。
- 刪除前一個函式。
例如,如果您有一個呼叫 webhook
的函式目前位於 us-central1
的預設函式區域,而您想要將其遷移至 asia-northeast1
,則必須先修改原始碼,將函式重新命名並修改區域。
// before
const functions = require('firebase-functions');
exports.webhook = functions
.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions');
exports.webhookAsia = functions
.region('asia-northeast1')
.https.onRequest((req, res) => {
res.send("Hello");
});
接著執行下列指令來部署:
firebase deploy --only functions:webhookAsia
現在有兩個相同的函式正在執行:webhook
在 us-central1
中執行,webhookAsia
是在 asia-northeast1
中執行。
然後刪除 webhook
:
firebase functions:delete webhook
現在只有一個函式 - webhookAsia
,且在 asia-northeast1
中執行。
變更函式的觸發條件類型
隨著時間開發 Cloud Functions for Firebase 的部署作業時,您可能需要基於各種原因變更函式的觸發條件類型。舉例來說,您可能會想要從 Firebase 即時資料庫或 Cloud Firestore 事件類型變更為另一種類型。
您無法僅透過變更原始碼並執行 firebase deploy
來變更函式的事件類型。為避免發生錯誤,請透過下列方式變更函式的觸發條件類型:
- 修改原始碼,加入包含所需觸發條件類型的新函式。
- 部署函式,會導致新舊函式暫時同時執行。
- 使用 Firebase CLI 將舊函式從實際工作環境中刪除。
舉例來說,如果您有名為 objectChanged
的 Node.js 函式,且該函式採用舊版 onChange
事件類型,而您想將其變更為 onFinalize
,請先重新命名函式,並編輯函式,使其包含 onFinalize
事件類型。
// before
const functions = require('firebase-functions');
exports.objectChanged = functions.storage.object().onChange((object) => {
return console.log('File name is: ', object.name);
});
// after
const functions = require('firebase-functions');
exports.objectFinalized = functions.storage.object().onFinalize((object) => {
return console.log('File name is: ', object.name);
});
接著執行下列指令,先建立新函式,然後再刪除舊函式:
# Create new function objectFinalized firebase deploy --only functions:objectFinalized # Wait until deployment is done; now both objectChanged and objectFinalized are running # Delete objectChanged firebase functions:delete objectChanged
設定執行階段選項
Cloud Functions for Firebase 可讓您選取執行階段選項,例如 Node.js 執行階段版本、每個函式逾時、記憶體分配,以及函式執行個體下限/上限。
根據最佳做法,建議在函式程式碼內的設定物件上設定這些選項 (Node.js 版本除外)。這個 RuntimeOptions
物件是函式執行階段選項的可靠資料來源,並會覆寫透過任何其他方法設定的選項 (例如透過 Google Cloud 控制台或 gcloud CLI)。
如果您的開發工作流程需要透過 Google Cloud 控制台或 gcloud CLI 手動設定執行階段選項,而且您「不」希望在每次部署時覆寫這些值,請將 preserveExternalChanges
選項設為 true
。將這個選項設為 true
時,Firebase 會將程式碼中設定的執行階段選項,與目前已部署的函式版本設定合併,優先順序如下:
- 函式程式碼中已設定選項:覆寫外部變更。
- 函式程式碼中的選項設為
RESET_VALUE
:以預設值覆寫外部變更。 - 選項未在函式程式碼中設定,而是在目前部署的函式中設定:請使用已部署函式中指定的選項。
在大多數情況下,不建議使用 preserveExternalChanges: true
選項,因為您的程式碼就不會再是函式的執行階段選項完整可靠來源。如果發生這種情況,請檢查 Google Cloud 控制台或使用 gcloud CLI,檢視函式的完整設定。
設定 Node.js 版本
Cloud Functions 專用的 Firebase SDK 可讓您選取 Node.js 執行階段。您可以選擇只在與下列任一受支援 Node.js 版本的執行階段環境中,執行專案中的所有函式:
- Node.js 20 (預先發布版)
- Node.js 18
- Node.js 16
- Node.js 14
如要設定 Node.js 版本:
您可以在初始化期間透過 functions/
目錄建立的 package.json
檔案,在 engines
欄位中設定版本。舉例來說,如果只要使用 18 版,請在 package.json
中編輯下列程式碼:
"engines": {"node": "18"}
如果您使用 Yarn 套件管理員,或對 engines
欄位有其他特定要求,可以改為在 firebase.json
中為 Cloud Functions 設定 Firebase SDK 的執行階段:
{
"functions": {
"runtime": "nodejs18" // or nodejs14, nodejs16 or nodejs20
}
}
CLI 使用在 firebase.json
中設定的值,而不是您在 package.json
中另外設定的任何值或範圍。
升級 Node.js 執行階段
如要升級 Node.js 執行階段:
- 請確認您的專案採用 Blaze 定價方案。
- 確認您使用的是 Firebase CLI v11.18.0 以上版本。
- 針對在初始化期間於
functions/
目錄中建立的package.json
檔案,變更engines
值。舉例來說,如果您從 16 版升級至 18 版,項目應如下所示:"engines": {"node": "18"}
- 您也可以使用 Firebase 本機模擬器套件測試變更。
- 重新部署所有函式。
控管資源調度行為
根據預設,Cloud Functions for Firebase 會根據傳入要求的數量調整運作中的執行個體數量,可能會在流量降低時縮減為零個執行個體。不過,如果您的應用程式需要縮短延遲時間,而您想要限製冷啟動的次數,則可變更這個預設行為。指定必須保持暖機狀態且準備好處理要求的最低容器執行個體數量。
同樣地,您可以設定上限數字,限制執行個體的資源調度,以回應傳入要求。使用這項設定來控制費用,或限制與服務 (例如資料庫) 的連線數量。
減少冷啟動次數
如要設定原始碼中函式的執行個體數量下限,請使用 runWith
方法。此方法接受符合 RuntimeOptions
介面的 JSON 物件,該介面定義 minInstances
的值。例如,這個函式會將至少 5 個執行個體設為暖機:
exports.getAutocompleteResponse = functions
.runWith({
// Keep 5 instances warm for this latency-critical function
minInstances: 5,
})
.https.onCall((data, context) => {
// Autocomplete a user's search term
});
設定 minInstances
的值時,請注意下列事項:
- 如果 Cloud Functions for Firebase 將應用程式的資源調度率高於
minInstances
設定,則每個超過該門檻的執行個體都會遇到冷啟動。 - 對於流量暴增的應用程式而言,冷啟動的效果最為嚴重。如果應用程式有激增的流量,並將
minInstances
值設為夠高,使每次流量增加時冷啟動,就能大幅縮短延遲時間。如果應用程式的流量穩定,冷啟動不太可能嚴重影響效能。 在實際工作環境中設定最低執行個體是合理的,但通常應避免在測試環境中使用。如要在測試專案中將資源調度降至零,同時減少實際工作環境專案中的冷啟動次數,您可以根據
FIREBASE_CONFIG
環境變數設定minInstances
:// Get Firebase project id from `FIREBASE_CONFIG` environment variable const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId; exports.renderProfilePage = functions .runWith({ // Keep 5 instances warm for this latency-critical function // in production only. Default to 0 for test projects. minInstances: envProjectId === "my-production-project" ? 5 : 0, }) .https.onRequest((req, res) => { // render some html });
限制函式的執行個體數量上限
如要在函式原始碼中設定執行個體上限,請使用 runWith
方法。此方法接受符合 RuntimeOptions
介面的 JSON 物件,該介面定義 maxInstances
的值。舉例來說,這個函式會將限制設為 100 個執行個體,以免因假定的舊版資料庫超載:
exports.mirrorOrdersToLegacyDatabase = functions
.runWith({
// Legacy database only supports 100 simultaneous connections
maxInstances: 100,
})
.firestore.document("orders/{orderId}")
.onWrite((change, context) => {
// Connect to legacy database
});
如果 HTTP 函式擴充為 maxInstances
的限制,系統會將新要求排入佇列 30 秒。如果屆時沒有可用執行個體,則新要求會排入佇列,並傳回回應代碼 429 Too Many Requests
。
如要進一步瞭解使用執行個體上限設定的最佳做法,請參閱使用 maxInstances
的最佳做法。
設定逾時和記憶體分配
在某些情況下,您的函式對於長時間的逾時值或大量記憶體配置可能有特殊需求。您可以在 Google Cloud 控制台或函式原始碼 (僅限 Firebase) 中設定這些值。
如要在函式原始碼中設定記憶體分配和逾時,請使用在 Cloud Functions 2.0.0 專用 Firebase SDK 中導入的 runWith
參數。此執行階段選項接受符合 RuntimeOptions
介面的 JSON 物件,該介面定義 timeoutSeconds
和 memory
的值。舉例來說,這個儲存函式會使用 1 GB 記憶體,並在 300 秒後逾時:
exports.convertLargeFile = functions
.runWith({
// Ensure the function has enough memory and time
// to process large files
timeoutSeconds: 300,
memory: "1GB",
})
.storage.object()
.onFinalize((object) => {
// Do some complicated things that take a lot of memory and time
});
timeoutSeconds
的最大值是 540
或 9 分鐘。
授予函式的記憶體量相當於針對函式分配的 CPU,如下方的 memory
有效值清單中詳細說明:
128MB
- 200 MHz256MB
- 400 MHz512MB
- 800 MHz1GB
- 1.4 GHz2GB
- 2.4 GHz4GB
- 4.8 GHz8GB
- 4.8 GHz
如何在 Google Cloud 控制台中設定記憶體分配和逾時:
- 在 Google Cloud 控制台中,從左側選單選取「Cloud Functions」。
- 在函式清單中按一下函式名稱以選取函式。
- 按一下頂端選單中的「編輯」圖示。
- 從標示為「Memory allocation」的下拉式選單中,選取記憶體分配情形。
- 按一下「更多」顯示進階選項,然後在「逾時」文字方塊中輸入秒數。
- 按一下「Save」(儲存) 以更新函式。