Możesz wdrażać, usuwać i modyfikować funkcje za pomocą poleceń interfejsu wiersza poleceń Firebase lub ustawiając opcje środowiska wykonawczego w kodzie źródłowym funkcji.
Wdrażanie funkcji
Aby wdrożyć funkcje, uruchom to polecenie interfejsu wiersza poleceń Firebase:
firebase deploy --only functions
Domyślnie interfejs wiersza poleceń Firebase wdraża wszystkie funkcje w źródle jednocześnie. Jeśli projekt zawiera więcej niż 5 funkcji, zalecamy użycie flagi --only z nazwami konkretnych funkcji, aby wdrożyć tylko te funkcje, które zostały zmodyfikowane. Wdrażanie określonych funkcji w ten sposób przyspiesza proces wdrażania i pomaga uniknąć przekroczenia limitów wdrażania. Przykład:
firebase deploy --only functions:addMessage,functions:makeUppercase
Podczas wdrażania dużej liczby funkcji możesz przekroczyć standardowy limit i otrzymać komunikaty o błędach HTTP 429 lub 500. Aby rozwiązać ten problem, wdrażaj funkcje w grupach liczących maksymalnie 10 funkcji.
Pełną listę dostępnych poleceń znajdziesz w dokumentacji interfejsu wiersza poleceń Firebase.
Domyślnie interfejs wiersza poleceń Firebase szuka kodu źródłowego w folderze functions/. Jeśli wolisz, możesz uporządkować funkcje w bazach kodu lub wielu zestawach plików.
Usuwanie artefaktów wdrożenia
W ramach wdrażania funkcji obrazy kontenerów są generowane i przechowywane w Artifact Registry. Te obrazy nie są wymagane do działania wdrożonych funkcji. Cloud Functions pobiera i zachowuje kopię obrazu podczas początkowego wdrożenia, ale przechowywane artefakty nie są niezbędne do działania funkcji w czasie działania.
Chociaż te obrazy kontenerów są często małe, z czasem mogą się gromadzić i zwiększać koszty przechowywania. Jeśli planujesz sprawdzić utworzone artefakty lub przeprowadzić skanowanie kontenerów pod kątem luk w zabezpieczeniach, możesz zachować je przez pewien czas.
Aby ułatwić zarządzanie kosztami miejsca na dane, interfejs wiersza poleceń Firebase w wersji 14.0.0 lub nowszej umożliwia skonfigurowanie zasad czyszczenia Artifact Registry w przypadku repozytoriów, które przechowują artefakty wdrożenia po każdym wdrożeniu funkcji.
Zasadę czyszczenia możesz skonfigurować lub edytować ręcznie za pomocą polecenia functions:artifacts:setpolicy:
firebase functions:artifacts:setpolicy
Domyślnie to polecenie konfiguruje Artifact Registry tak, aby automatycznie usuwać obrazy kontenerów starsze niż 1 dzień. Zapewnia to rozsądną równowagę między minimalizacją kosztów przechowywania a możliwością potencjalnej kontroli ostatnich kompilacji.
Okres przechowywania możesz dostosować za pomocą opcji --days:
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
Jeśli wdrażasz funkcje w wielu regionach, możesz skonfigurować zasadę czyszczenia dla konkretnej lokalizacji, używając opcji --location:
$ firebase functions:artifacts:setpolicy --location europe-west1
Rezygnacja z czyszczenia artefaktów
Jeśli wolisz zarządzać czyszczeniem obrazów ręcznie lub nie chcesz, aby jakiekolwiek obrazy były usuwane, możesz całkowicie zrezygnować z zasad czyszczenia:
$ firebase functions:artifacts:setpolicy --none
To polecenie usuwa wszystkie istniejące zasady czyszczenia skonfigurowane przez interfejs wiersza poleceń Firebase i uniemożliwia Firebase skonfigurowanie zasad czyszczenia po wdrożeniu funkcji.
Usuwanie funkcji
Wcześniej wdrożone funkcje możesz usunąć na te sposoby:
- wyraźnie w interfejsie wiersza poleceń Firebase za pomocą
functions:delete - wyraźnie w konsoli Google Cloud.
- niejawnie przez usunięcie funkcji ze źródła przed wdrożeniem.
Wszystkie operacje usuwania wymagają potwierdzenia, zanim funkcja zostanie usunięta ze środowiska produkcyjnego.
Jawne usuwanie funkcji w interfejsie wiersza poleceń Firebase obsługuje wiele argumentów, a także grupy funkcji, i umożliwia określenie funkcji działającej w konkretnym regionie. Możesz też zastąpić prośbę o potwierdzenie.
Usuwa wszystkie funkcje o określonej nazwie we wszystkich regionach:
firebase functions:delete FUNCTION-1_NAME
Usuwa określoną funkcję działającą w regionie innym niż domyślny:
firebase functions:delete FUNCTION-1_NAME --region REGION_NAME
Usuwa więcej niż 1 funkcję:
firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME
Usuwa określoną grupę funkcji:
firebase functions:delete GROUP_NAME
Pomija prośbę o potwierdzenie:
firebase functions:delete FUNCTION-1_NAME --force
W przypadku niejawnego usuwania funkcji firebase deploy analizuje źródło i usuwa z wersji produkcyjnej wszystkie funkcje, które zostały usunięte z pliku.
Modyfikowanie nazwy, regionu lub aktywatora funkcji
Jeśli zmieniasz nazwy lub regiony albo aktywatory funkcji, które obsługują ruch produkcyjny, wykonaj czynności opisane w tej sekcji, aby uniknąć utraty zdarzeń podczas modyfikacji. Zanim wykonasz te czynności, upewnij się, że funkcja jest idempotentna, ponieważ podczas wprowadzania zmian zarówno nowa, jak i stara wersja funkcji będą działać jednocześnie.
Zmienianie nazwy funkcji
Aby zmienić nazwę funkcji, utwórz w źródle nową wersję funkcji o zmienionej nazwie, a następnie uruchom 2 osobne polecenia wdrażania. Pierwsze polecenie wdraża funkcję nazwaną o nowej nazwie, a drugie usuwa wcześniej wdrożoną wersję. Jeśli na przykład masz webhook aktywowany przez HTTP, którego nazwę chcesz zmienić, zmodyfikuj kod w ten sposób:
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!")
Następnie uruchom te polecenia, aby wdrożyć nową funkcję:
# Deploy new function firebase deploy --only functions:webhookNew # Wait until deployment is done; now both functions are running # Delete webhook firebase functions:delete webhook
Zmienianie regionu lub regionów funkcji
Jeśli zmieniasz określone regiony funkcji, która obsługuje ruch produkcyjny, możesz zapobiec utracie zdarzeń, wykonując te czynności w podanej kolejności:
- Zmień nazwę funkcji i jej region lub regiony zgodnie z potrzebami.
- Wdróż funkcję o zmienionej nazwie, co spowoduje tymczasowe uruchomienie tego samego kodu w obu zestawach regionów.
- Usuń poprzednią funkcję.
Jeśli na przykład masz funkcję wywoływaną przez Cloud Firestore, która jest obecnie wdrożona w regionie us-central1, i chcesz ją przenieść do regionu asia-northeast1, musisz najpierw zmodyfikować kod źródłowy, aby zmienić nazwę funkcji i region.
Node.js
// before
exports.firestoreTrigger = onDocumentCreated(
"my-collection/{docId}",
(event) => {},
);
// after
exports.firestoreTriggerAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
Zaktualizowany kod powinien określać prawidłowy filtr zdarzeń (w tym przypadku document) oraz region. Więcej informacji znajdziesz w sekcji Cloud Functions dotyczącej lokalizacji.
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
Następnie wdróż, uruchamiając:
firebase deploy --only functions:firestoreTriggerAsia
Teraz działają 2 identyczne funkcje: firestoreTrigger w us-central1 i firestoreTriggerAsia w asia-northeast1.
Następnie usuń firestoreTrigger:
firebase functions:delete firestoreTrigger
Teraz jest tylko jedna funkcja – firestoreTriggerAsia, która działa w regionie asia-northeast1.
Zmienianie typu aktywatora funkcji
W miarę rozwoju wdrożenia Cloud Functions for Firebase z różnych powodów może być konieczna zmiana typu aktywatora funkcji. Możesz na przykład zmienić typ zdarzenia Firebase Realtime Database lub Cloud Firestore na inny.
Nie można zmienić typu zdarzenia funkcji przez samą zmianę kodu źródłowego i uruchomienie polecenia firebase deploy. Aby uniknąć błędów, zmień typ aktywatora funkcji, wykonując te czynności:
- Zmodyfikuj kod źródłowy, aby uwzględnić nową funkcję z odpowiednim typem aktywatora.
- Wdróż funkcję, co spowoduje tymczasowe uruchomienie zarówno starej, jak i nowej funkcji.
- Jawnie usuń starą funkcję z produkcji za pomocą interfejsu wiersza poleceń Firebase.
Jeśli na przykład masz funkcję, która jest aktywowana po usunięciu obiektu, ale potem włączysz obsługę wersji obiektów i chcesz zamiast tego subskrybować zdarzenie archiwizacji, najpierw zmień nazwę funkcji i zmodyfikuj ją, aby miała nowy typ aktywatora.
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):
# ...
Następnie uruchom te polecenia, aby najpierw utworzyć nową funkcję, a potem usunąć starą:
# 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
Ustawianie opcji środowiska wykonawczego
Cloud Functions for Firebase umożliwia wybór opcji środowiska wykonawczego, takich jak wersja środowiska wykonawczego Node.js, limit czasu dla poszczególnych funkcji, alokacja pamięci oraz minimalna i maksymalna liczba instancji funkcji.
Zgodnie ze sprawdzonymi metodami te opcje (z wyjątkiem wersji Node.js) powinny być ustawione w obiekcie konfiguracji w kodzie funkcji. Ten obiekt RuntimeOptions jest źródłem informacji o opcjach środowiska wykonawczego funkcji i zastępuje opcje ustawione za pomocą dowolnej innej metody (np. konsoli Google Cloud lub gcloud CLI).
Jeśli Twój proces programowania obejmuje ręczne ustawianie opcji środowiska wykonawczego za pomocą konsoli Google Cloud lub gcloud CLI i nie chcesz, aby te wartości były zastępowane przy każdym wdrożeniu, ustaw opcję preserveExternalChanges na true. Jeśli ta opcja jest ustawiona na true, Firebase scala opcje środowiska wykonawczego ustawione w kodzie z ustawieniami obecnie wdrożonej wersji funkcji z następującym priorytetem:
- Opcja jest ustawiona w kodzie funkcji: zastąp zmiany zewnętrzne.
- W kodzie funkcji opcja jest ustawiona na
RESET_VALUE: zastąp zmiany zewnętrzne wartością domyślną. - Opcja nie jest ustawiona w kodzie funkcji, ale jest ustawiona we wdrożonej funkcji: użyj opcji określonej we wdrożonej funkcji.
W większości przypadków nie zalecamy korzystania z opcji preserveExternalChanges: true, ponieważ kod nie będzie już jedynym źródłem informacji o opcjach środowiska wykonawczego funkcji. Jeśli go używasz, sprawdź konsolę Google Cloud lub użyj gcloud CLI, aby wyświetlić pełną konfigurację funkcji.
Ustawianie wersji Node.js
Pakiet SDK Firebase dla Cloud Functions umożliwia wybór środowiska wykonawczego Node.js. Możesz uruchamiać wszystkie funkcje w projekcie wyłącznie w środowisku wykonawczym odpowiadającym jednej z tych obsługiwanych wersji Node.js:
- Node.js 22
- Node.js 20
- Node.js 18 (wycofane)
Wersje 14 i 16 Node.js zostały wycofane na początku 2025 r. Wdrażanie z tymi wersjami jest wyłączone. Ważne informacje o bieżącej pomocy dotyczącej tych wersji Node.js znajdziesz w harmonogramie pomocy.
Aby ustawić wersję Node.js:
Wersję możesz ustawić w polu engines w pliku package.json, który został utworzony w katalogu functions/ podczas inicjowania.
Jeśli na przykład chcesz używać tylko wersji 20, zmodyfikuj ten wiersz w pliku package.json:
"engines": {"node": "20"}
Jeśli używasz systemu zarządzania pakietami Yarn lub masz inne wymagania dotyczące pola engines, możesz ustawić środowisko wykonawcze pakietu SDK Firebase dla Cloud Functions w firebase.json:
{
"functions": {
"runtime": "nodejs20" // or nodejs22
}
}
Interfejs wiersza poleceń używa wartości ustawionej w firebase.json, a nie wartości lub zakresu ustawionego osobno w package.json.
Uaktualnianie środowiska wykonawczego Node.js
Aby uaktualnić środowisko wykonawcze Node.js:
- Upewnij się, że Twój projekt jest objęty abonamentem Blaze.
- Upewnij się, że używasz interfejsu wiersza poleceń Firebase w wersji 11.18.0 lub nowszej.
- Zmień wartość
enginesw plikupackage.json, który został utworzony w katalogufunctions/podczas inicjowania. Jeśli na przykład uaktualniasz wersję 18 do wersji 20, wpis powinien wyglądać tak:"engines": {"node": "20"} - Opcjonalnie możesz przetestować zmiany za pomocą Firebase Local Emulator Suite.
- Ponownie wdróż wszystkie funkcje.
Wybieranie systemu modułów Node.js
Domyślnym systemem modułów w Node.js jest CommonJS (CJS), ale obecne wersje Node.js obsługują też moduły ECMAScript (ESM). Cloud Functions obsługuje obie te opcje.
Domyślnie funkcje używają CommonJS. Oznacza to, że import i eksport wyglądają tak:
const {onRequest} = require("firebase-functions/https");
exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));
Aby zamiast tego używać ESM, ustaw pole "type": "module" w pliku package.json:
{
...
"type": "module",
...
}
Po ustawieniu tej opcji użyj składni ESM import i export:
import {onRequest} from "firebase-functions/https";
export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));
Oba systemy modułów są w pełni obsługiwane. Możesz wybrać opcję, która najlepiej pasuje do Twojego projektu. Więcej informacji znajdziesz w dokumentacji Node.js dotyczącej modułów.
Ustawianie wersji Pythona
Pakiet SDK Firebase dla Cloud Functions w wersji 12.0.0 lub nowszej umożliwia wybór środowiska wykonawczego Pythona. Ustaw wersję środowiska wykonawczego w pliku firebase.json, jak pokazano poniżej:
{
"functions": {
"runtime": "python310" // or python311
}
}
Zarządzanie skalowaniem
Domyślnie Cloud Functions for Firebase skaluje liczbę działających instancji na podstawie liczby żądań przychodzących, potencjalnie skalując w dół do zera instancji w okresach mniejszego ruchu. Jeśli jednak Twoja aplikacja wymaga krótszego czasu oczekiwania i chcesz ograniczyć liczbę uruchomień „na zimno”, możesz zmienić to działanie domyślne, określając minimalną liczbę instancji kontenera, które mają być utrzymywane w gotowości do obsługi żądań.
Podobnie możesz ustawić maksymalną liczbę, aby ograniczyć skalowanie instancji w odpowiedzi na przychodzące żądania. Użyj tego ustawienia, aby kontrolować koszty lub ograniczyć liczbę połączeń z usługą pomocniczą, np. bazą danych.
Używając tych ustawień razem z ustawieniem współbieżności dla poszczególnych instancji (nowość w 2 generacji), możesz kontrolować i dostrajać zachowanie funkcji podczas skalowania. To, które ustawienia są najbardziej opłacalne i zapewniają najlepszą wydajność, zależy od charakteru aplikacji i funkcji.
W przypadku niektórych aplikacji o małym natężeniu ruchu optymalna jest opcja z mniejszą liczbą procesorów bez wielobieżności. W przypadku innych, gdzie uruchomienia „na zimno” są poważnym problemem, ustawienie wysokiej równoczesności i minimalnej liczby instancji oznacza, że zestaw instancji jest zawsze utrzymywany w gotowości do obsługi dużych skoków ruchu.
W przypadku aplikacji na mniejszą skalę, które generują bardzo mały ruch, ustawienie niskiej maksymalnej liczby instancji przy wysokiej równoczesności oznacza, że aplikacja może obsługiwać skoki ruchu bez ponoszenia nadmiernych kosztów. Pamiętaj jednak, że jeśli maksymalna liczba instancji jest ustawiona na zbyt niską wartość, żądania mogą zostać odrzucone po osiągnięciu limitu.
Zezwalaj na żądania równoczesne
W Cloud Functions for Firebase (1 generacji) każda instancja mogła obsługiwać jedno żądanie naraz, więc zachowanie skalowania było ustawiane tylko za pomocą ustawień minimalnej i maksymalnej liczby instancji.
Oprócz kontrolowania liczby instancji w Cloud Functions for Firebase (2 generacji) możesz kontrolować liczbę żądań, które każda instancja może obsłużyć jednocześnie, za pomocą opcji concurrency. Domyślna wartość równoczesności to 80, ale możesz ustawić dowolną liczbę całkowitą z zakresu od 1 do 1000.
Funkcje z wyższymi ustawieniami równoczesności mogą absorbować skoki ruchu bez uruchamiania na zimno, ponieważ każda instancja prawdopodobnie ma pewien zapas. Jeśli instancja jest skonfigurowana do obsługi maksymalnie 50 żądań równoczesnych, ale obecnie obsługuje tylko 25, może obsłużyć nagły wzrost o 25 dodatkowych żądań bez konieczności uruchamiania nowej instancji na zimno. Jeśli natomiast ustawienie równoczesności wynosi 1, taki skok liczby żądań może doprowadzić do 25 uruchomień „na zimno”.
Ten uproszczony scenariusz pokazuje potencjalne korzyści z równoczesności. W rzeczywistości skalowanie w celu optymalizacji wydajności i ograniczenia zimnych startów przy użyciu równoczesności jest bardziej złożone. Współbieżność w Cloud Functions for Firebase 2 generacji jest obsługiwana przez Cloud Run i podlega zasadom Cloud Run dotyczącym autoskalowania instancji kontenera.
Podczas eksperymentowania z wyższymi ustawieniami równoczesności w Cloud Functions for Firebase (2 generacji) pamiętaj o tych kwestiach:
- Wyższe ustawienia równoczesności mogą wymagać większej ilości pamięci RAM i procesora, aby zapewnić optymalną wydajność, aż do osiągnięcia praktycznego limitu. Funkcja, która wykonuje intensywne przetwarzanie obrazów lub filmów, może nie mieć zasobów do obsługi 1000 żądań równoczesnych, nawet jeśli jej ustawienia procesora i pamięci RAM są zmaksymalizowane.
- Ponieważ usługa Cloud Functions for Firebase (2 generacji) jest oparta na Cloud Run, możesz też zapoznać się ze wskazówkami dotyczącymi Google Cloud, aby zoptymalizować równoczesność.
- Przed przejściem na wielorównoczesność w środowisku produkcyjnym dokładnie przetestuj tę funkcję w środowisku testowym.
Utrzymywanie minimalnej liczby instancji w gotowości
Możesz ustawić minimalną liczbę instancji funkcji w kodzie źródłowym. Na przykład ta funkcja ustawia minimalną liczbę instancji, które mają być utrzymywane w stanie gotowości, na 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:
Oto kilka kwestii, które warto wziąć pod uwagę podczas ustawiania minimalnej liczby instancji:
- Jeśli Cloud Functions for Firebase przeskaluje aplikację powyżej ustawienia, każda instancja powyżej tego progu będzie uruchamiana na zimno.
- Uruchomienia „na zimno” mają największy wpływ na aplikacje, w których ruch jest nieregularny. Jeśli ruch w aplikacji jest nieregularny i ustawisz wartość na tyle wysoką, że zimne uruchomienia będą rzadsze przy każdym wzroście ruchu, zauważysz znaczne skrócenie czasu oczekiwania. W przypadku aplikacji o stałym ruchu uruchomienia „na zimno” raczej nie będą miały poważnego wpływu na wydajność.
Ustawienie minimalnej liczby instancji może mieć sens w środowiskach produkcyjnych, ale zwykle należy go unikać w środowiskach testowych. Aby skalować do zera w projekcie testowym, ale nadal ograniczać uruchomienia „na zimno” w projekcie produkcyjnym, możesz ustawić minimalną liczbę instancji w konfiguracji sparametryzowanej:
Node.js
const { onRequest } = require('firebase-functions/https'); 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 = onRequest( { minInstances: minInstancesConfig }, (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.")
Ograniczanie maksymalnej liczby instancji funkcji
Możesz ustawić wartość maksymalnej liczby instancji w kodzie źródłowym funkcji. Na przykład ta funkcja ustawia limit 100 instancji, aby nie przeciążyć hipotetycznej starszej bazy danych:
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
Jeśli funkcja HTTP zostanie przeskalowana do maksymalnego limitu instancji, nowe żądania będą umieszczane w kolejce na 30 sekund, a następnie odrzucane z kodem odpowiedzi 429 Too Many Requests, jeśli do tego czasu nie będzie dostępna żadna instancja.
Więcej informacji o sprawdzonych metodach korzystania z ustawień maksymalnej liczby instancji znajdziesz w artykule na temat sprawdzonych metod ustawiania maksymalnej liczby instancji.
Ustawianie konta usługi
Domyślne konta usługi dla funkcji mają szeroki zestaw uprawnień, które umożliwiają interakcję z innymi usługami Firebase i Google Cloud:
- Funkcje drugiej generacji: PROJECT_NUMBER-compute@developer.gserviceaccount.com (o nazwie Domyślne konto usługi Compute Engine)
- Funkcje 1 generacji: PROJECT_ID@
appspot.gserviceaccount.com (o nazwie Domyślne konto usługi App Engine)
Możesz zastąpić domyślne konto usługi i ograniczyć funkcję do dokładnie tych zasobów, których potrzebuje. W tym celu utwórz niestandardowe konto usługi i przypisz je do odpowiedniej funkcji za pomocą wartości konfiguracji serviceAccount:
const { onRequest } = require("firebase-functions/https");
exports.helloWorld = onRequest(
{
// This function doesn't access other Firebase project resources, so it uses a limited service account.
serviceAccount:
"my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
},
(request, response) => {
response.send("Hello from Firebase!");
},
);
Jeśli chcesz ustawić to samo konto usługi dla wszystkich funkcji, możesz to zrobić za pomocą funkcji setGlobalOptions.
Ustawianie czasu oczekiwania i alokacji pamięci
W niektórych przypadkach funkcje mogą mieć specjalne wymagania dotyczące długiego limitu czasu lub dużej ilości przydzielonej pamięci. Możesz ustawić te wartości w konsoli Google Cloud lub w kodzie źródłowym funkcji (tylko Firebase), używając wartości limitu czasu w ramach tych maksymalnych limitów czasu trwania:
- Funkcje HTTP i wywoływalne: 3600 sekund (60 minut)
- Funkcje zaplanowane i funkcje kolejki zadań: 1800 sekund (30 minut)
- Inne funkcje oparte na zdarzeniach: 540 sekund (9 minut)
Aby ustawić alokację pamięci i limit czasu w kodzie źródłowym funkcji, użyj globalnych opcji pamięci i limitu czasu w sekundach, aby dostosować maszynę wirtualną, na której działają funkcje. Na przykład ta funkcja Cloud Storage używa 1 GiB pamięci i kończy działanie po 300 sekundach:
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.
Aby ustawić alokację pamięci i limit czasu w konsoli Google Cloud:
- W konsoli Google Cloud wybierz Cloud Functions for Firebase z menu po lewej stronie.
- Wybierz funkcję, klikając jej nazwę na liście funkcji.
- W górnym menu kliknij ikonę Edytuj.
- Wybierz alokację pamięci z menu Przydzielona pamięć.
- Kliknij Więcej, aby wyświetlić opcje zaawansowane, i wpisz liczbę sekund w polu tekstowym Limit czasu.
- Kliknij Zapisz, aby zaktualizować funkcję.
Zastępowanie domyślnych ustawień procesora
Do 2 GB alokacji pamięci, każda funkcja w Cloud Functions for Firebase (2 generacji) domyślnie używa 1 procesora, a następnie zwiększa się do 2 procesorów w przypadku 4 i 8 GB. Pamiętaj, że to działanie znacznie różni się od domyślnego działania funkcji 1 generacji, co może prowadzić do nieco wyższych kosztów funkcji o małej ilości pamięci, jak pokazano w tej tabeli:
| Przydzielona pamięć RAM | Domyślny procesor w wersji 1 (ułamkowy) | Domyślny procesor w wersji 2 | Wzrost ceny za milisekundę |
|---|---|---|---|
| 128 MB | 1/12 | 1 | 10,5× |
| 256 MB | 1/6 | 1 | 5,3 raza |
| 512 MB | 1/3 | 1 | 2,7 raza |
| 1 GB | 7/12 | 1 | 1,6x |
| 2 GB | 1 | 1 | 1x |
| 4 GB | 2 | 2 | 1x |
| 8 GB | 2 | 2 | 1x |
| 16 GB | Nie dotyczy | 4 | Nie dotyczy |
Jeśli w funkcjach 2 generacji wolisz zachowanie funkcji 1 generacji, ustaw domyślne ustawienia 1 generacji jako opcję globalną:
Node.js
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
Python
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
W przypadku funkcji wymagających dużej mocy procesora 2 generacja zapewnia elastyczność konfigurowania dodatkowych procesorów. Możesz zwiększyć moc procesora dla poszczególnych funkcji, jak pokazano poniżej:
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