Łączenie aplikacji z emulatorem Cloud Functions

Zanim połączysz aplikację z emulatorem Cloud Functions, upewnij się, że znasz ogólny Firebase Local Emulator Suiteprzepływ pracy oraz zainstalujesz i skonfigurujesz Local Emulator Suite i zapoznasz się z jego poleceniami CLI.

Wybieranie projektu Firebase

Firebase Local Emulator Suite emuluje usługi dla jednego projektu Firebase.

Aby wybrać projekt, którego chcesz używać, przed uruchomieniem emulatorów wpisz 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 i projektów demonstracyjnych.

Typ projektu Funkcje Korzystanie z emulatorami
Real

Prawdziwy projekt Firebase to projekt, który został utworzony i skonfigurowany (najprawdopodobniej w Firebasekonsoli).

Prawdziwe projekty mają aktywne zasoby, takie jak instancje baz danych, zasobniki pamięci, funkcje lub inne zasoby skonfigurowane w tym projekcie Firebase.

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

W przypadku wszystkich usług, których nie emulujesz, Twoje aplikacje i kod będą wchodzić w interakcje z zasobem na żywo (instancją bazy danych, zasobnikiem pamięci, funkcją itp.).

Prezentacja

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

Identyfikatory projektów demonstracyjnych mają prefiks demo-.

Podczas pracy z demonstracyjnymi projektami Firebase aplikacje i kod wchodzą w interakcje tylko z emulatorami. Jeśli aplikacja spróbuje wejść w interakcję z zasobem, dla którego nie działa emulator, kod nie zadziała.

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

  • Łatwiejsza konfiguracja, ponieważ emulatory można uruchamiać bez tworzenia projektu Firebase.
  • Większe bezpieczeństwo, ponieważ jeśli Twój kod przypadkowo wywoła zasoby nieemulowane (produkcyjne), nie ma możliwości zmiany danych, wykorzystania zasobów ani naliczenia opłat.
  • Lepsza obsługa offline, ponieważ nie musisz uzyskiwać dostępu do internetu, aby pobrać konfigurację pakietu SDK.

Dostosuj aplikację, aby komunikowała się z emulatorami

Dostosowywanie aplikacji do funkcji wywoływanych

Jeśli prototyp i testy obejmują funkcje backendu, które można wywoływać, skonfiguruj interakcję z emulatorem Cloud Functions for Firebase w ten sposób:

Kotlin
// 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().useEmulator(withHost: "localhost", port: 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

Dostosowywanie aplikacji do emulacji funkcji HTTPS

Każda funkcja HTTPS w Twoim kodzie będzie obsługiwana z lokalnego emulatora przy użyciu tego formatu adresu URL:

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

Dostosowywanie aplikacji do emulacji funkcji kolejki zadań

Emulator automatycznie konfiguruje emulowane kolejki zadań na podstawie definicji wyzwalaczy, a pakiet Admin SDK przekierowuje żądania umieszczone w kolejce do emulatora, jeśli wykryje, że działa on za pomocą zmiennej środowiskowej CLOUD_TASKS_EMULATOR_HOST.

Pamiętaj, że system wysyłania używany w środowisku produkcyjnym jest bardziej złożony niż ten zaimplementowany w emulatorze, więc nie oczekuj, że emulowane zachowanie będzie dokładnie odzwierciedlać środowiska produkcyjne. Parametry w emulatorze określają górne limity szybkości wysyłania i ponawiania zadań.

Dostosowywanie aplikacji do emulacji 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
  • Authentication emulator
  • Pub/Sub emulator
  • Emulator alertów Firebase

Aby wywoływać zdarzenia w tle, zmodyfikuj zasoby backendu za pomocą Emulator Suite UIlub połącz aplikację lub kod testowy z emulatorami za pomocą pakietu SDK dla swojej platformy.

Testowanie modułów obsługi zdarzeń niestandardowych emitowanych przez rozszerzenia

W przypadku funkcji, które implementujesz do obsługi Firebase Extensionszdarzeń niestandardowych w Cloud Functionswersji 2, emulator Cloud Functions współpracuje z emulatorem Eventarc, aby obsługiwać aktywatory Eventarc.

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

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

Gdy zmienne środowiskowe są prawidłowo skonfigurowane, Firebase Admin SDKautomatycznie wysyła zdarzenia do emulatora Eventarc. Z kolei emulator Eventarc wysyła wywołanie zwrotne do emulatora Cloud Functions, aby wywołać zarejestrowane moduły.

Szczegółowe informacje o wykonywaniu funkcji obsługi 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 projektu, konfigurując plik .env.local. Zawartość pliku .env.local ma pierwszeństwo przed plikami .env i .env dotyczącymi konkretnego projektu.

Na przykład projekt może zawierać te 3 pliki z nieco innymi wartościami na potrzeby programowania i testowania lokalnego:

.env .env.dev .env.local
PLANET=Earth

AUDIENCE=Humans

AUDIENCE=Dev Humans AUDIENCE=Local Humans

Po uruchomieniu w kontekście lokalnym emulator wczytuje zmienne środowiskowe w ten sposób:

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

Utajnione informacje i dane logowania w emulatorze Cloud Functions

Emulator Cloud Functions obsługuje używanie obiektów tajnych do przechowywania poufnych informacji o konfiguracji i uzyskiwania do nich dostępu. Domyślnie emulator będzie próbował uzyskać dostęp do obiektów tajnych środowiska produkcyjnego za pomocą domyślnych danych logowania aplikacji. W niektórych sytuacjach, np. w środowiskach CI, emulator może nie mieć dostępu do wartości tajnych z powodu ograniczeń uprawnień.

Podobnie jak w przypadku emulatora Cloud Functions, który obsługuje zmienne środowiskowe, możesz zastąpić wartości kluczy tajnych, konfigurując plik .secret.local. Ułatwia to lokalne testowanie funkcji, zwłaszcza jeśli nie masz dostępu do wartości tajnej.

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

Emulator Cloud Functions jest uzupełniany przez inne narzędzia do prototypowania i testowania:

  • Powłoka Cloud Functions, która umożliwia interaktywne, iteracyjne prototypowanie i tworzenie funkcji. Powłoka korzysta z emulatora Cloud Functions z interfejsem w stylu REPL do programowania. Nie zapewniamy integracji z emulatorami Cloud Firestore ani Realtime Database. Za pomocą powłoki możesz symulować dane i wykonywać wywołania funkcji, aby symulować interakcje z usługami, których Local Emulator Suite obecnie nie obsługuje: Analytics, Zdalna konfiguracja i Crashlytics.
  • Pakiet Firebase Test SDK dla Cloud Functions, czyli framework Node.js z biblioteką mocha do tworzenia funkcji. W praktyce pakiet Cloud Functions Test SDK zapewnia automatyzację w powłoce Cloud Functions.

Więcej informacji o powłoce Cloud Functions i zestawie Cloud Functions Test SDK znajdziesz w sekcjach Interaktywne testowanie funkcji i Testy jednostkowe funkcji Cloud Functions.

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

W większości przypadków emulator Cloud Functions jest dość podobny do środowiska produkcyjnego. Włożyliśmy wiele pracy w to, aby wszystko w środowisku wykonawczym Node było jak najbardziej zbliżone do środowiska produkcyjnego. Emulator nie odzwierciedla jednak w pełni środowiska produkcyjnego w kontenerze, więc chociaż kod funkcji będzie wykonywany w realistyczny sposób, 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 uwzględniać żadnych zachowań związanych z IAM podczas działania. Emulatory są zgodne z podanymi regułami zabezpieczeń Firebase, ale w sytuacjach, w których zwykle używa się IAM, np. do ustawienia konta usługi wywołującej Cloud Functions, a tym samym uprawnień, emulator nie jest konfigurowalny i będzie używać globalnie dostępnego konta na komputerze dewelopera, podobnie jak w przypadku bezpośredniego uruchamiania lokalnego skryptu.

Ograniczenia dotyczące pamięci i procesora

Emulator nie wymusza ograniczeń pamięci ani procesora w przypadku Twoich funkcji. Emulator obsługuje jednak przekroczenie limitu czasu funkcji za pomocą argumentu środowiska wykonawczego timeoutSeconds.

Pamiętaj, że czas wykonywania funkcji może się różnić od czasu w środowisku produkcyjnym, gdy funkcje są uruchamiane w emulatorze. Zalecamy, aby po zaprojektowaniu i przetestowaniu funkcji za pomocą emulatora przeprowadzić ograniczone testy w środowisku produkcyjnym, aby potwierdzić czasy wykonania.

Planowanie różnic między środowiskami lokalnym i produkcyjnym

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

Pamiętaj, że środowisko lokalne do programowania 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ą działać inaczej niż w środowisku produkcyjnym, zwłaszcza jeśli potrzebujesz innej wersji lub tworzysz aplikację 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 powłoki, takie jak ls, mkdir) mogą różnić się od wersji dostępnych w środowisku produkcyjnym, zwłaszcza jeśli programujesz w środowisku innym niż Linux (np. macOS). Możesz rozwiązać ten problem, używając alternatywnych poleceń natywnych tylko w Node.js lub tworząc pliki binarne systemu Linux do spakowania z wdrożeniem.

Ponawiam próbę

Emulator Cloud Functions nie obsługuje ponawiania funkcji w przypadku niepowodzenia.

Co dalej?