管理函數部署和運行時選項

您可以使用 Firebase CLI 命令或通過在函數源代碼中設置運行時選項來部署、刪除和修改函數。

部署功能

要部署函數，請運行以下 Firebase CLI 命令：

$ firebase deploy --only functions

默認情況下，火力地堡CLI部署所有的內部功能index.js在同一時間。如果您的項目包含超過5個功能，我們建議您使用--only具有特定功能的名稱標誌，你已經編輯只部署的功能。部署特定的功能這樣加快了部署過程，並幫助您避免陷入部署配額。例如：

$ firebase deploy --only functions:addMessage,functions:makeUppercase

部署大量函數時，您可能會超出標準配額並收到 HTTP 429 或 500 錯誤消息。要解決此問題，請以 10 個或更少為一組部署函數。

見火力地堡CLI參考可用命令的完整列表。

默認情況下，火力地堡CLI看起來在functions/的源代碼文件夾。您可以通過添加下面的行指定另一個文件夾firebase.json ：

"functions": {
  "source": "another-folder"
}

刪除函數

您可以通過以下方式刪除以前部署的函數：

• 明確在火力地堡CLI與functions:delete
• 明確使用在上下文菜單的功能列表中火力地堡控制台
• implictly通過從除去功能index.js部署之前。

所有刪除操作都會提示您在從生產中刪除該功能之前進行確認。

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解析index.js從生產，並刪除已經從文件中刪除的任何功能。

修改函數的名稱、區域或觸發器

如果您要重命名或更改處理生產流量的函數的區域或觸發器，請按照本節中的步驟操作以避免在修改期間丟失事件。請按照下列步驟之前，首先要確保你的函數是冪等，因為這兩個新版本和舊版本的功能將在同一時間的變化過程中運行。

重命名函數

要重命名功能，創建函數的一個新的重命名版本index.js並運行兩個單獨的部署命令。第一個命令部署新命名的函數，第二個命令刪除以前部署的版本。舉例來說，如果你有一個調用的函數webhook ，你想改變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

更改函數的一個或多個區域

如果要更改指定區域的功能的操控性生產流量，可以通過按順序執行這些步驟防止事件損失：

1. 重命名函數，並根據需要更改其區域。
2. 部署重命名的函數，這會導致在兩組區域中臨時運行相同的代碼。
3. 刪除之前的函數。

舉例來說，如果你有一個功能叫做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 。

更改函數的觸發器類型

隨著時間的推移，隨著您為 Firebase 部署開發 Cloud Functions，您可能需要出於各種原因更改函數的觸發器類型。例如，您可能想要：

• 從傳統存儲更改onChange事件onFinalize ， onDelete ， onArchive和onMetadataUpdate 。 （了解更多有關此方面的測試，以V1或V2升級指南）。
• 從到另一個，一種類型的火力地堡實時數據庫或雲公司的FireStore事件的變化，如通用onWrite事件顆粒onCreate事件。

這是不可能通過只更改源代碼和運行改變功能的事件類型firebase deploy 。為避免錯誤，請通過以下過程更改函數的觸發器類型：

1. 修改源代碼以包含具有所需觸發器類型的新函數。
2. 部署函數，這會導致臨時運行舊函數和新函數。
3. 使用 Firebase CLI 從生產中顯式刪除舊函數。

舉例來說，如果你有一個函數objectChanged具有傳統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 版本

適用於 Cloud Functions 2.0.0 及更高版本的 Firebase SDK 允許選擇 Node.js 運行時。您可以選擇在與這些受支持的 Node.js 版本之一對應的運行時環境中專門運行項目中的所有函數：

• Node.js 16（測試版）
• 節點.js 14
• 節點.js 12
• 節點.js 10
• Node.js的8（不建議使用於2020年6月8日）的功能，Node.js的8運行在火力地堡CLI被禁用部署12月15日，2020年執行的已經部署的功能將停止在未來的某一時刻;如果你已經部署功能Node.js的8運行時，我們建議您升級到Node.js的14運行。

要設置 Node.js 版本：

坐落在版本engines領域package.json這是在你創建的文件functions/目錄初始化過程中。例如，僅使用14版，編輯這一行package.json ：

  "engines": {"node": "14"}

該engines領域是必需的;它必須要指定支持Node.js的版本之一為您部署並運行的功能。目前firebase init functions設置此字段為14 。

升級你的 Node.js 運行時

要升級您的 Node.js 運行時：

1. 請確保您的項目是在大火定價計劃。
2. 確保您使用的是 Firebase CLI v8.6.0 或更高版本。
3. 更換engines的值package.json這是在你創建的文件functions/目錄初始化過程中。例如，如果您是從版本10升級到14版，該條目應該是這樣的： "engines": {"node": "14"}
4. 或者，測試使用的更改火力地堡本地模擬器套房。
5. 使用 Firebase CLI v8.1.0 或更高版本重新部署函數。

控制縮放行為

默認情況下，Cloud Functions for Firebase 根據傳入請求的數量擴展正在運行的實例的數量，在流量減少時可能會縮減到零個實例。但是，如果您的應用程序需要減少延遲並且您想要限製冷啟動次數，您可以通過指定最少數量的容器實例來保持溫暖並準備好服務請求來更改此默認行為。

同樣，您可以設置一個最大數量來限制實例響應傳入請求的擴展。使用此設置作為控製成本或限制與後備服務（如數據庫）的連接數的一種方式。

減少冷啟動次數

用於在源代碼中的函數的實例設置的最小數目，則使用runWith參數。此運行選項接受符合JSON對象RuntimeOptions接口，它定義為值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
    });
index.js

這裡有一些事情設定的值時要考慮minInstances ：

• 如果火力地堡雲功能擴展你上面的您的應用程序minInstances設置，你會經歷一個冷啟動的高於閾值的每個實例。
• 冷啟動對流量激增的應用程序的影響最為嚴重。如果您的應用程序有高低不平的交通和你設置一個minInstances價值足夠高，使得冷啟動在每個流量的增加減少了，你會看到顯著減少延遲。對於流量恆定的應用程序，冷啟動不太可能嚴重影響性能。

• 設置最少實例對生產環境有意義，但在測試環境中通常應避免。為了擴展到零在您的測試項目，但仍降低你的生產項目冷啟動時，您可以設置minInstances基礎上， FIREBASE_CONFIG環境變量：

  // 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
      });
  index.js
  

限制函數的最大實例數

在函數的源代碼設定的最大的情況下，使用runWith參數。此運行選項接受符合JSON對象RuntimeOptions接口，它用於限定值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
    });
index.js

如果HTTP函數被縮放到maxInstances限制，新請求進行排隊30秒，然後用一個響應碼拒絕429 Too Many Requests如果沒有實例可用通過然後。

要了解更多有關最佳做法，使用最大實例的設置，檢查出這些最佳實踐使用maxInstances 。

設置超時和內存分配

在某些情況下，您的函數可能對長超時值或大量內存分配有特殊要求。您可以在 Google Cloud Console 或函數源代碼（僅限 Firebase）中設置這些值。

在函數的源代碼集的存儲器分配和超時，使用runWith在火力地堡SDK引入用於雲功能2.0.0參數。此運行選項接受符合JSON對象RuntimeOptions接口，它用於限定值timeoutSeconds和memory 。比如這個存儲函數使用1GB內存，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
    });
index.js

為最大值timeoutSeconds是540 ，或9分鐘。為有效值memory是：

• 128MB
• 256MB
• 512MB
• 1GB
• 2GB
• 4GB
• 8GB

要在 Google Cloud Console 中設置內存分配和超時：

1. 在谷歌谷歌雲端控制台中選擇從左邊的菜單功能的雲。
2. 通過單擊函數列表中的名稱來選擇函數。
3. 點擊頂部菜單中的編輯圖標。
4. 選擇從分配的下拉菜單鍵存儲內存分配。
5. 點擊更多顯示高級選項，並在超時文本框中輸入秒數。
6. 點擊保存更新功能。