管理功能


您可以使用 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/ 資料夾中尋找原始碼。如要整理程式碼庫或多組檔案中的函式,請參閱這篇文章

清除部署構件

部署函式時,系統會產生容器映像檔並儲存在 Artifact Registry 中。部署的函式不需要這些映像檔即可執行;Cloud Functions會在初始部署時擷取並保留映像檔副本,但函式在執行階段運作時不需要儲存的構件。

雖然這些容器映像檔通常很小,但長期下來可能會累積,進而增加儲存空間費用。如果您打算檢查建構成果或執行容器安全漏洞掃描,可能需要保留這些項目一段時間。

為協助管理儲存空間費用,Firebase CLI 14.0.0 以上版本可讓您為存放部署構件的存放區,設定Artifact Registry清除政策,以便在每次函式部署後清除構件。

您可以使用 functions:artifacts:setpolicy 指令手動設定或編輯清除政策:

firebase functions:artifacts:setpolicy

根據預設,這項指令會將 Artifact Registry 設定為自動刪除超過 1 天的容器映像檔。這樣一來,就能在盡量減少儲存空間成本,以及允許檢查近期建構作業之間取得合理平衡。

您可以使用 --days 選項自訂保留期限:

firebase functions:artifacts:setpolicy --days 7  # Delete images older than 7 days

如果您將函式部署至多個區域,可以使用 --location 選項,為特定位置設定清除政策:

$ firebase functions:artifacts:setpolicy --location europe-west1

選擇停用構件清理作業

如要手動管理圖片清理作業,或不想刪除任何圖片,可以完全停用清理政策:

$ firebase functions:artifacts:setpolicy --none

這項指令會移除 Firebase CLI 建立的所有現有清理政策,並防止 Firebase 在函式部署後設定清理政策。

刪除函式

您可以透過下列方式刪除先前部署的函式:

  • 使用 functions:deleteFirebase CLI 中明確設定
  • 明確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 會剖析來源,並從正式版中移除已從檔案中移除的函式。

修改函式的名稱、區域或觸發條件

如要重新命名或變更處理正式版流量的函式區域或觸發條件,請按照本節中的步驟操作,以免在修改期間遺失事件。請先確認函式為等冪,再按照下列步驟操作,因為在變更期間,新舊版本的函式會同時執行。

重新命名函式

如要重新命名函式,請在來源中建立函式的新版本 (已重新命名),然後分別執行兩個部署指令。第一個指令會部署新命名的函式,第二個指令則會移除先前部署的版本。舉例來說,如果您有想要重新命名的 HTTP 觸發 Webhook,請按照下列方式修改程式碼:

Node.js

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

Python

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

接著,請執行下列指令來部署新函式:

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

變更函式的區域

如果要變更處理正式環境流量的函式指定區域,請依序執行下列步驟,避免遺失事件:

  1. 重新命名函式,並視需要變更其區域。
  2. 部署重新命名的函式,導致兩組區域暫時執行相同的程式碼。
  3. 刪除先前的函式。

舉例來說,如果您有目前位於 us-central1 預設函式區域的 Cloud Firestore 觸發函式,並想將其遷移至 asia-northeast1,您需要先修改原始碼,重新命名函式並修訂區域。

Node.js

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

更新後的程式碼應指定正確的事件篩選器 (在本例中為 document) 和區域。詳情請參閱 Cloud Functions 位置

Python

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

然後執行下列指令來部署:

firebase deploy --only functions:firestoreTriggerAsia

現在有兩個相同的函式正在執行:firestoreTriggerus-central1 中執行,而 firestoreTriggerAsiaasia-northeast1 中執行。

然後刪除 firestoreTrigger

firebase functions:delete firestoreTrigger

現在只有一個函式 - firestoreTriggerAsia,在 asia-northeast1 中執行。

變更函式的觸發類型

隨著時間推移,您可能會基於各種原因,需要變更函式的觸發類型。Cloud Functions for Firebase舉例來說,您可能想將某種 Firebase Realtime DatabaseCloud Firestore 事件改為另一種。

您無法只變更來源程式碼並執行 firebase deploy,藉此變更函式的事件類型。為避免發生錯誤,請按照下列程序變更函式的觸發類型:

  1. 修改原始碼,加入具有所需觸發類型的新函式。
  2. 部署函式,這會導致舊函式和新函式暫時同時執行。
  3. 使用 Firebase CLI 從正式環境明確刪除舊函式。

舉例來說,如果您有一個在物件遭刪除時觸發的函式,但後來啟用了物件版本管理,且想改為訂閱封存事件,請先重新命名函式,然後編輯函式,使其具有新的觸發條件類型。

Node.js

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

Python

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

然後執行下列指令,先建立新函式,再刪除舊函式:

# Create new function objectArchived
firebase deploy --only functions:objectArchived

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

設定執行階段選項

Cloud Functions for Firebase 可讓您選取執行階段選項,例如 Node.js 執行階段版本,以及每個函式的逾時、記憶體配置和函式執行個體下限/上限。

根據最佳做法,這些選項 (Node.js 版本除外) 應在函式程式碼內的設定物件中設定。這個 RuntimeOptions 物件是函式執行階段選項的資訊來源,會覆寫透過任何其他方法 (例如 Google Cloud 控制台或 gcloud CLI) 設定的選項。

如果您的開發工作流程涉及透過 Google Cloud 控制台或 gcloud CLI 手動設定執行階段選項,且您希望在每次部署時覆寫這些值,請將 preserveExternalChanges 選項設為 true。 如果將這個選項設為 true,Firebase 會合併程式碼中設定的執行階段選項,以及目前部署的函式版本設定,並依下列優先順序處理:

  1. 在函式程式碼中設定選項:覆寫外部變更。
  2. 在函式程式碼中,選項設為 RESET_VALUE:以預設值覆寫外部變更。
  3. 函式程式碼中未設定選項,但目前部署的函式已設定選項:使用部署函式中指定的選項。

在大多數情況下,不建議使用 preserveExternalChanges: true 選項,因為您的程式碼將不再是函式執行階段選項的完整事實來源。如果使用,請檢查 Google Cloud 控制台,或使用 gcloud CLI 查看函式的完整設定。

設定 Node.js 版本

Firebase SDK for Cloud Functions 允許選取 Node.js 執行階段。 您可以選擇在專案中,只在與下列其中一個支援的 Node.js 版本對應的執行階段環境中執行所有函式:

  • Node.js 22
  • Node.js 20
  • Node.js 18 (已淘汰)

Node.js 14 和 16 版已於 2025 年初停用。已停用使用這些版本進行部署的功能。請參閱支援時間表,瞭解這些 Node.js 版本持續支援的重要資訊。

如要設定 Node.js 版本,請按照下列步驟操作:

您可以在初始化期間於 functions/ 目錄中建立的 package.json 檔案中,設定 engines 欄位的版本。舉例來說,如要只使用第 20 版,請在 package.json 中編輯這行程式碼:

  "engines": {"node": "20"}

如果您使用 Yarn 套件管理工具,或對 engines 欄位有其他特定需求,可以在 firebase.json 中為 Cloud Functions 設定 Firebase SDK 的執行階段:

  {
    "functions": {
      "runtime": "nodejs20" // or nodejs22
    }
  }

CLI 會優先使用 firebase.json 中設定的值,而非您在 package.json 中另外設定的任何值或範圍。

升級 Node.js 執行階段

如要升級 Node.js 執行階段:

  1. 確認專案採用 Blaze 定價方案
  2. 請確認您使用的是 Firebase CLI 11.18.0 以上版本。
  3. 在初始化期間於 functions/ 目錄中建立的 package.json 檔案中,變更 engines 值。舉例來說,如果您要從版本 18 升級至版本 20,項目應如下所示:"engines": {"node": "20"}
  4. 您也可以選擇使用 Firebase Local Emulator Suite 測試變更。
  5. 重新部署所有函式。

設定 Python 版本

Firebase Cloud Functions 12.0.0 以上版本的 SDK 可選取 Python 執行階段。在 firebase.json 中設定執行階段版本,如下所示:

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

控管資源調度行為

根據預設,Cloud Functions for Firebase 會根據傳入要求數量調整執行個體數量,流量減少時甚至可能縮減至零個執行個體。不過,如果應用程式需要縮短延遲時間,而您希望限制冷啟動次數,則可變更這項預設行為。僅須指定要保持暖機狀態、準備好處理要求的最低容器執行個體數量即可。

同樣地,您也可以設定數量上限,限制執行個體因應傳入要求而進行的資源調度。您可以透過這項設定控管費用,或限制與後端服務 (例如資料庫) 的連線數量。

搭配使用這些設定和每個執行個體的並行設定 (第 2 代的新功能),即可控管及調整函式的縮放行為。應用程式和函式的性質會決定哪些設定最符合成本效益,且能帶來最佳成效。

對於流量較低的應用程式,建議選擇 CPU 較低的選項,且不使用多重並行。對於冷啟動是重大問題的函式,設定高並行和最少執行個體數,表示系統會讓一組執行個體保持暖機狀態,以處理流量大幅增加的情況。

如果應用程式規模較小,流量極少,設定較低的執行個體上限和較高的並行數,代表應用程式可以處理流量爆增的情況,且不會產生過多費用。不過請注意,如果將 maximum instances 設得太低,達到上限時可能會捨棄要求。

允許並行要求

Cloud Functions for Firebase (第 1 代) 中,每個執行個體一次只能處理一個要求,因此只能透過設定執行個體數量下限和上限來調整規模。除了控管執行個體數量,在 Cloud Functions for Firebase (第 2 代) 中,您還可以使用 concurrency 選項,控管每個執行個體可同時處理的要求數量。並行作業的預設值為 80,但您可以將其設為 1 到 1000 之間的任何整數。

由於每個執行個體可能都有一些空間,因此並不會冷啟動,具有較高並行設定的函式可以吸收流量尖峰。如果執行個體設為最多可處理 50 個並行要求,但目前只處理 25 個,則可處理額外 25 個要求,無須冷啟動新執行個體。相反地,如果並行設定僅為 1,要求量暴增可能會導致 25 次冷啟動。

這個簡化的情境說明瞭並行作業可帶來的效率提升。實際上,為了盡量提高效率並減少並行冷啟動,擴充行為會更加複雜。第 2 代的 Cloud Functions for Firebase 並行作業是由 Cloud Run 支援,並遵循 Cloud Run容器執行個體自動調度資源規則。

Cloud Functions for Firebase(第 2 代) 中測試較高的並行設定時,請注意下列事項:

  • 如要達到最佳效能,並行設定越高,可能就需要越高的 CPU 和 RAM,直到達到實際上限為止。舉例來說,即使函式的 CPU 和 RAM 設定已達上限,如果函式需要大量處理圖片或影片,可能還是沒有足夠資源來處理 1000 項並行要求。
  • 由於 Cloud Functions for Firebase (第 2 代) 是由 Cloud Run 供電,您也可以參考Google Cloud指南,瞭解如何最佳化並行
  • 請務必先在測試環境中徹底測試多重並行功能,再切換至正式環境。

將特定數量的執行個體維持在暖機狀態

您可以在原始碼中設定函式的執行個體數量下限。舉例來說,這個函式會設定至少 5 個執行個體來保持暖機狀態:

Node.js

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

Python

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

設定執行個體數量下限值時,請考慮下列事項:

  • 如果 Cloud Functions for Firebase 將應用程式擴展到超出設定的範圍,超過該門檻的每個執行個體都會冷啟動。
  • 冷啟動對流量尖峰的應用程式影響最大。如果應用程式的流量會突然暴增,且您設定的值夠高,可減少每次流量增加時的冷啟動次數,延遲時間就會大幅縮短。對於流量穩定的應用程式,冷啟動不太可能嚴重影響效能。
  • 設定最少的執行個體適用於正式環境,但通常應避免在測試環境中設定。如要在測試專案中縮減至零,但仍要減少正式版專案中的冷啟動次數,可以在參數化設定中設定執行個體數量下限:

    Node.js

    const functions = require('firebase-functions/v1');
    const { defineInt, defineString } = require('firebase-functions/params');
    
    // Define some parameters
    const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
    const welcomeMessage = defineString('WELCOME_MESSAGE');
    
    // To use configured parameters inside the config for a function, provide them 
    // directly. To use them at runtime, call .value() on them.
    export const helloWorld = functions.runWith({ minInstances: minInstancesConfig}).https.onRequest(
      (req, res) => {
        res.send(`${welcomeMessage.value()}! I am a function.`);
      }
    );
    

    Python

    MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
    WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")
    
    @https_fn.on_request(min_instances=MIN_INSTANCES.value())
    def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
        return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
    

限制函式的執行個體數量上限

您可以在函式原始碼中設定執行個體上限值。舉例來說,這個函式會將執行個體數量上限設為 100,以免負擔過重 (假設是舊版資料庫):

Node.js

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

Python

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

如果 HTTP 函式擴充至執行個體數量上限,系統會將新要求排入佇列 30 秒,如果屆時沒有可用的執行個體,就會以 429 Too Many Requests 回應代碼拒絕要求。

如要進一步瞭解使用最大執行個體設定的最佳做法,請參閱設定最大執行個體的最佳做法

設定逾時時間和記憶體分配方式

在某些情況下,函式可能需要較長的逾時值或大量記憶體配置。您可以在 Google Cloud 控制台或函式原始碼中設定這些值 (僅限 Firebase)。

如要在函式原始碼中設定記憶體配置和逾時,請使用記憶體和逾時秒數的全域選項,自訂執行函式的虛擬機器。舉例來說,這個 Cloud Storage 函式會使用 1 GiB 的記憶體,並在 300 秒後逾時:

Node.js

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

Python

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

逾時秒數的最大值為 540,也就是 9 分鐘。

如要在 Google Cloud 控制台中設定記憶體配置和逾時:

  1. Google Cloud 控制台中,從左側選單選取 Cloud Functions for Firebase
  2. 在函式清單中點選函式名稱,即可選取函式。
  3. 按一下頂端選單中的「編輯」圖示。
  4. 從標示為「已分配的記憶體」的下拉式選單中,選取記憶體分配量。
  5. 按一下「更多」顯示進階選項,然後在「逾時」文字方塊中輸入秒數。
  6. 按一下「儲存」即可更新函式。

覆寫 CPU 預設值

最多可分配 2 GB 的記憶體,Cloud Functions for Firebase (第 2 代) 中的每個函式預設為一個 CPU,然後增加至 4 GB 和 8 GB 的 2 個 CPU。請注意,這與第 1 代的預設行為有顯著差異,可能會導致低記憶體函式的成本略為提高,如下表所示:

分配的 RAM 第 1 版預設 CPU (小數) 第 2 版預設 CPU 每毫秒價格增幅
128MB 1/12 1 10.5x
256MB 1/6 1 5.3x
512MB 1/3 1 2.7 倍
1GB 7/12 1 1.6 倍
2GB 1 1 1x
4GB 2 2 1x
8GB 2 2 1x
16 GB 不適用 4 不適用

如果希望第 2 代函式採用第 1 代的行為,請將第 1 代預設值設為全域選項:

Node.js

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

Python

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

對於 CPU 密集型函式,第 2 代函式可彈性設定額外 CPU。您可以根據函式提升 CPU 效能,如下所示:

Node.js

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

Python

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here