Łączenie aplikacji z emulatorem Cloud Functions

Zanim połączysz aplikację z emulatorem Cloud Functions, zapoznaj się z całym procesem Firebase Local Emulator Suite oraz zainstaluj i skonfiguruj Local Emulator Suite i sprawdź jego polecenia CLI.

Wybieranie projektu Firebase

Firebase Local Emulator Suite emuluje usługi w pojedynczym projekcie Firebase.

Aby wybrać projekt, który ma być używany, przed uruchomieniem emulatorów uruchom w CLI polecenie firebase use w katalogu roboczym. Możesz też przekazać flagę --project do każdego polecenia emulatora.

Local Emulator Suite obsługuje emulację prawdziwych projektów Firebase oraz projektów demonstracyjnych.

Typ projektu Funkcje Używanie z emulatorami
Real

Prawdziwy projekt Firebase to projekt utworzony i skonfigurowany przez Ciebie (najprawdopodobniej za pomocą konsoli Firebase).

Prawdziwe projekty mają aktywne zasoby, takie jak instancje bazy danych, kontenery magazynu, funkcje lub inne zasoby skonfigurowane w danym projekcie Firebase.

Podczas pracy z prawdziwymi projektami Firebase możesz uruchomić emulatory dowolnej lub wszystkich obsługiwanych usług.

W przypadku usług, których nie emulujesz, aplikacje i kod będą współdziałać z aktywnym zasobem (instancją bazy danych, zasobnikiem na dane, funkcją itp.).

Wersja demonstracyjna

Projekt demonstracyjny Firebase nie ma rzeczywistej konfiguracji Firebase ani aktywnych zasobów. Dostęp do tych projektów uzyskuje się zwykle w ramach ćwiczeń z programowania lub innych samouczków.

Identyfikatory projektów demonstracyjnych mają prefiks demo-.

Podczas pracy z demonstracyjnymi projektami Firebase aplikacje i kod będą wchodzić w interakcje z emulatorami tylko. Jeśli aplikacja próbuje wchodzić w interakcję z zasobem, dla którego nie działa emulowany system, kod nie zadziała.

Zalecamy, aby w miarę możliwości korzystać z projektów demonstracyjnych. W ten sposób możesz zapewnić im dostęp do tych korzyści:

  • Łatwiejsza konfiguracja, ponieważ możesz uruchamiać emulatory bez tworzenia projektu Firebase.
  • Większe bezpieczeństwo, ponieważ jeśli Twój kod przypadkowo wywoła nieemulowane (produkcyjne) zasoby, nie ma możliwości zmiany danych, ich użycia ani rozliczenia.
  • lepszą obsługę offline, ponieważ do pobrania konfiguracji pakietu SDK nie jest potrzebny dostęp do internetu;

Przeprowadź testy aplikacji z użyciem emulatorów

Dostosuj aplikację pod kątem funkcji wywoływanych

Jeśli w prototypie i testach występują wyzwalane funkcje zaplecza, skonfiguruj interakcję z emulatorem Cloud Functions for Firebase w ten sposób:

Kotlin+KTX
// 10.0.2.2 is the special IP address to connect to the 'localhost' of
// the host computer from an Android emulator.
val functions = Firebase.functions
functions.useEmulator("10.0.2.2", 5001)
MainActivity.kt
Java
// 10.0.2.2 is the special IP address to connect to the 'localhost' of
// the host computer from an Android emulator.
FirebaseFunctions functions = FirebaseFunctions.getInstance();
functions.useEmulator("10.0.2.2", 5001);
MainActivity.java
Swift
Functions.functions().useFunctionsEmulator(origin: "http://127.0.0.1:5001")
ViewController.swift

Web

import { getApp } from "firebase/app";
import { getFunctions, connectFunctionsEmulator } from "firebase/functions";

const functions = getFunctions(getApp());
connectFunctionsEmulator(functions, "127.0.0.1", 5001);
fb_functions_emulator_connect.js

Web

firebase.functions().useEmulator("127.0.0.1", 5001);
emulator-suite.js

Dostosuj aplikację do emulacji funkcji HTTPS

Każda funkcja HTTPS w kodzie będzie obsługiwana przez lokalny emulator przy użyciu adresu URL w tym formacie:

http://$HOST:$PORT/$PROJECT/$REGION/$NAME

Na przykład prosta funkcja helloWorld z domyślnym portem hosta i regionem będzie obsługiwana pod adresem:

https://localhost:5001/$PROJECT/us-central1/helloWorld

Przeprowadź emulację funkcji kolejki zadań w aplikacji

Na podstawie definicji wyzwalaczy emulator automatycznie konfiguruje kolejki zadań emulowanych, a pakiet Admin SDK przekierowuje oczekujące żądania do emulatora, jeśli wykryje, że działa on za pomocą zmiennej środowiska CLOUD_TASKS_EMULATOR_HOST.

Pamiętaj, że system wysyłania używany w produkcji jest bardziej złożony niż ten zaimplementowany w emulatorze, więc nie należy oczekiwać, że emulowane działanie będzie dokładnie odzwierciedlać środowisko produkcyjne. Parametry w emulatorze określają górne granice szybkości wysyłania i ponawiania zadań.

Emulacja funkcji wywoływanych w tle

Emulator Cloud Functions obsługuje funkcje wywoływane w tle z tych źródeł:

  • Realtime Database emulator
  • Cloud Firestore emulator
  • Emulator usługi Authentication
  • Pub/Sub emulator
  • Emulator alertów Firebase

Aby aktywować zdarzenia w tle, zmodyfikuj zasoby backendu za pomocą Emulator Suite UI albo połącz aplikację lub przetestuj kod z emulatorami, korzystając z pakietu SDK przeznaczonego na Twoją platformę.

testowanie obsługi zdarzeń niestandardowych emitowanych przez rozszerzenia.

W przypadku funkcji implementowanych do obsługi zdarzeń niestandardowych Firebase Extensions w wersji 2.0 Cloud Functions emuluje emulację Cloud Functions z emulacją Eventarc, aby obsługiwać aktywatorów Eventarc.

Aby przetestować obsługę zdarzeń niestandardowych w przypadku rozszerzeń, które emitują zdarzenia, musisz zainstalować emulatory Cloud Functions i Eventarc.

Jeśli emulowany jest emulator Eventarc, środowisko wykonawcze Cloud Functions ustawia zmienną środowiskową EVENTARC_EMULATOR na localhost:9299 w bieżącym procesie. Firebase Admin SDK automatycznie łączą się z emulatorem Eventarc, gdy ustawiona jest zmienna środowiskowa EVENTARC_EMULATOR. Możesz zmienić domyślny port zgodnie z instrukcjami w sekcji Konfigurowanie Local Emulator Suite.

Gdy zmienne środowiskowe są prawidłowo skonfigurowane, Firebase Admin SDKautomatycznie wysyła zdarzenia do emulatora Eventarc. Następnie emulowany Eventarc wywołuje emulowany Cloud Functions, aby wywołać zarejestrowane moduły.

Szczegółowe informacje o wykonywaniu funkcji znajdziesz w logach funkcji w Emulator Suite UI.

Konfigurowanie lokalnego środowiska testowego

Jeśli Twoje funkcje korzystają z konfiguracji środowiska opartej na dotenv, możesz emulować to zachowanie w lokalnym środowisku testowym.

Jeśli używasz lokalnego emulatora Cloud Functions, możesz zastąpić zmienne środowiskowe w projekcie, konfigurując plik .env.local. Treści pliku .env.local mają pierwszeństwo przed plikiem .env i plikiem .env dotyczącym projektu.

Projekt może np. zawierać te 3 pliki zawierające nieco inne wartości na potrzeby testów programistycznych i lokalnych:

.env .env.dev .env.local
PLANET=Ziemia

AUDIENCE=ludzie

AUDIENCE=Dev Humans AUDIENCE=Lokalni ludzie

Gdy zostanie uruchomiony w kontekście lokalnym, emulator wczytuje zmienne środowiska w ten sposób:

  $ firebase emulators:start
  i  emulators: Starting emulators: functions
  # Starts emulator with following environment variables:
  #  PLANET=Earth
  #  AUDIENCE=Local Humans

Obiekty tajne i dane logowania w emulatorze Cloud Functions

Emulator Cloud Functions obsługuje używanie obiektów tajnych do przechowywania informacji konfiguracyjnych o charakterze poufnym i dostępu do nich. Domyślnie emulator będzie próbować uzyskać dostęp do tajnych danych produkcyjnych za pomocą domyślnych danych logowania aplikacji. W niektórych sytuacjach, np. w środowiskach CI, emulowany system może nie mieć dostępu do wartości tajnych ze względu na ograniczenia uprawnień.

Podobnie jak w przypadku obsługi zmiennych środowiskowych przez emulator Cloud Functions, możesz zastąpić wartości sekretów, konfigurując plik .secret.local. Ułatwia to lokalne testowanie funkcji, zwłaszcza jeśli nie masz dostępu do wartości obiektu tajnego.

Jakie są inne narzędzia do testowania Cloud Functions?

Emulator Cloud Functions jest uzupełniany o inne prototypy i narzędzia testowe:

  • Powłoka Cloud Functions umożliwiająca tworzenie prototypów i programowanie interaktywnych funkcji iteracyjnych. Powłoka korzysta z emulatora Cloud Functions z interfejsem w stylu REPL do celów programowania. Nie ma integracji z emulatorami Cloud Firestore ani Realtime Database. Za pomocą powłoki możesz symulować interakcję z usługami, których Local Emulator Suite obecnie nie obsługuje (Analytics, Zdalna konfiguracja i Crashlytics), podając dane symulowane i wykonywując wywołania funkcji.
  • Pakiet SDK testów Firebase dla Cloud Functions, czyli Node.js z ramką Mocha do tworzenia funkcji. W efekcie pakiet SDK do testowania Cloud Functions zapewnia automatyzację na poziomie powłoki Cloud Functions.

Więcej informacji o powłoce Cloud Functions i Test SDK Cloud Functions znajdziesz w artykułach Testowanie funkcji w sposób interaktywny i Testowanie jednostkowe funkcji w Cloud Functions.

Różnice między emulatorem Cloud Functions a wersją produkcyjną

W większości przypadków emulator Cloud Functions jest dość zbliżony do środowiska produkcyjnego. Dołożyliśmy wszelkich starań, aby wszystko w środowisku wykonawczym Node było jak najbardziej zbliżone do środowiska produkcyjnego. Jednak emulator nie odwzorowuje w pełni środowiska produkcyjnego z kontenerami, więc chociaż kod funkcji będzie działał realistycznie, inne aspekty środowiska (np. pliki lokalne, zachowanie po awarii funkcji itp.) będą się różnić.

Cloud IAM

Pakiet emulatorów Firebase nie próbuje replikować ani nie przestrzegać żadnych działań związanych z uprawnieniami dotyczącymi uruchamiania. Emulatory przestrzegają reguł zabezpieczeń Firebase, ale w sytuacjach, w których zwykle używane jest IAM, np. do konfigurowania wywołań konta usługi Cloud Functions i odpowiednich uprawnień, emulator nie jest konfigurowalny i używa konta dostępnego globalnie na Twoim urządzeniu dewelopera, podobnie jak w przypadku bezpośredniego uruchamiania skryptu lokalnego.

Ograniczenia dotyczące pamięci i procesora

Emulator nie narzuca ograniczeń pamięci ani procesora dla Twoich funkcji. Emulator obsługuje jednak funkcje z czasem oczekiwania za pomocą argumentu środowiska wykonawczego timeoutSeconds.

Czas wykonywania funkcji może się różnić od czasu rzeczywistego, gdy funkcje są uruchamiane w emulatorze. Zalecamy, aby po zaprojektowaniu i przetestowaniu funkcji za pomocą emulatora przeprowadzić ograniczone testy w wersji produkcyjnej w celu potwierdzenia czasu wykonywania.

Planowanie uwzględniające różnice w środowiskach lokalnych i produkcyjnych

Emulator działa na komputerze lokalnym, więc zależy to od lokalnego środowiska aplikacji oraz wbudowanych programów i narzędzi.

Pamiętaj, że Twoje lokalne środowisko do tworzenia aplikacji Cloud Functions może się różnić od środowiska produkcyjnego Google:

  • Aplikacje instalowane lokalnie w celu symulowania środowiska produkcyjnego (np. ImageMagick z tego samouczka) mogą zachowywać się inaczej niż w środowisku produkcyjnym, zwłaszcza jeśli wymagają innej wersji lub są rozwijane w środowisku innym niż Linux. Rozważ wdrożenie własnej kopii binarnej brakującego programu wraz z wdrożeniem funkcji.

  • Podobnie wbudowane narzędzia (np. polecenia w powłoce, takie jak ls, mkdir) mogą różnić się od wersji dostępnych w środowisku produkcyjnym, zwłaszcza jeśli pracujesz w środowisku innym niż Linux (np. macOS). Możesz rozwiązać ten problem, używając alternatyw dla poleceń natywnych tylko dla Node.js lub budując binarne pliki wykonywalne systemu Linux, aby utworzyć pakiet z wdrożeniami.

Ponawiam próbę

Emulator Cloud Functions nie obsługuje ponownego próbowania funkcji w przypadku niepowodzenia.

Co dalej?