Obsługa zależności

Wybierz język: Node.js Python

Funkcja Cloud Functions może korzystać z modułów zewnętrznych i zależności lokalnych. Sposób określania zależności i zarządzania nimi zależy od języka środowiska wykonawczego.

Node.js

Funkcja może korzystać z zewnętrznych modułów Node.js oraz lokalnych danych. Zależności w Node.js są zarządzane za pomocą npm i wyrażane w pliku metadanych o nazwie package.json. Środowiska wykonawcze Node.js w Cloud Functions obsługują instalację za pomocą npm, yarn lub pnpm.

Aby określić zależność funkcji, dodaj ją do pliku package.json.

W tym przykładzie w pliku package.json wymieniono zależność:

{
  "dependencies": {
    "escape-html": "^1.0.3"
  }
}

Zależność jest następnie importowana do funkcji:

JavaScript

const onRequest = require("firebase-functions/https");
const escapeHtml = require("escape-html");

// Return a greeting with the input HTML-escaped.
exports.hello = onRequest((req, res) => {
  res.send(`Hello ${escapeHtml(req.query.name || req.body.name || "World")}!`);
});

TypeScript

import { onRequest } from "firebase-functions/https";
import * as escapeHtml from "escape-html";

// Return a greeting with the input HTML-escaped.
export let hello = onRequest((req, res) => {
  res.send(`Hello ${escapeHtml(req.query.name || req.body.name || "World")}!`);
});

Uwzględnianie lokalnych modułów Node.js

Możesz też uwzględnić lokalne moduły Node.js jako część funkcji. Możesz to zrobić, deklarując moduł w package.json za pomocą file: prefiksu. W tym przykładzie mymodule to nazwa modułu, a mymoduledir to katalog zawierający moduł:

{
  "dependencies": {
    "mymodule": "file:mymoduledir"
  }
}

Kod tego modułu lokalnego powinien być przechowywany w innym miejscu niż folder node_modules w katalogu głównym funkcji.

Dodatkowe czynności w przypadku TypeScript

TypeScript jest najbardziej przydatny, gdy używasz bibliotek zawierających informacje o typach. Dzięki temu TypeScript może wykrywać błędy składniowe, a edytory mogą wyświetlać lepsze sugestie autouzupełniania. Niektóre biblioteki, np. firebase-admin i firebase-functions, zawierają definicje TypeScript.

Wiele bibliotek nie udostępnia własnej definicji TypeScript. Projekt DefinitelyTyped udostępnia definicje najpopularniejszych bibliotek węzłów, które są utrzymywane przez społeczność. DefinitelyTyped publikuje te definicje pod tą samą nazwą pakietu NPM, ale w organizacji „@types”. Możesz na przykład zainstalować informacje o typie dla biblioteki uuid za pomocą tego polecenia:

npm install @types/uuid

Gdy lepiej poznasz TypeScript, możesz połączyć obie instalacje:

npm install uuid @types/uuid

Zależności typu powinny być tego samego rodzaju co zależność biblioteki. Nie należy na przykład zapisywać uuid jako zwykłej zależności, a @types/uuid jako zależności deweloperskiej lub zależności równorzędnej.

Wczytywanie modułów Node.js

Użyj funkcji Node.js require() , aby wczytać dowolny zainstalowany moduł Node.js. Możesz też użyć funkcji require(), aby zaimportować lokalne pliki wdrażane razem z funkcją.

Jeśli piszesz funkcje w TypeScript, użyj instrukcji import w ten sam sposób, aby załadować dowolny zainstalowany moduł Node.js.

Korzystanie z modułów prywatnych

Możesz użyć prywatnego modułu npm, podając ustawienia uwierzytelniania w rejestrze w pliku .npmrc w katalogu funkcji. Jeśli używasz Yarn w wersji 2 lub nowszej jako menedżera pakietów, ten plik ma nazwę .yarnrc.yml.

Prywatne moduły z Artifact Registry

Repozytorium pakietów Node.js w Artifact Registry może hostować prywatne moduły funkcji. Gdy wdrażasz funkcję Google Cloud Functions, proces kompilacji automatycznie generuje dane logowania Artifact Registry dla konta usługi Cloud Build. W .npmrc wystarczy podać repozytorium Artifact Registry bez generowania dodatkowych danych logowania. Przykład:

@SCOPE:registry=https://REGION_ID-npm.pkg.dev/PROJECT_ID/REPOSITORY_NAME
//REGION_ID-npm.pkg.dev/PROJECT_ID/REPOSITORY_NAME:always-auth=true

To podejście działa też w przypadku menedżera pakietów Yarn v1. Jeśli używasz Yarn w wersji 2 lub nowszej, wystarczy, że wymienisz repozytorium Artifact Registry w .yarnrc.yml bez dodatkowych danych logowania. Przykład:

npmScopes:
  SCOPE:
    npmRegistryServer: https://REGION_ID-npm.pkg.dev/PROJECT_ID/REPOSITORY_NAME
    npmAlwaysAuth: true

Moduły prywatne z innych repozytoriów

W dokumentacji npm znajdziesz informacje o tym, jak tworzyć niestandardowe tokeny dostępu tylko do odczytu. Nie zalecamy używania pliku .npmrc utworzonego w katalogu domowym, ponieważ zawiera on token odczytu i zapisu. Uprawnienia do zapisu nie są wymagane podczas wdrażania i mogą stanowić zagrożenie dla bezpieczeństwa.

Jeśli nie używasz prywatnych repozytoriów, nie uwzględniaj pliku .npmrc, ponieważ może to wydłużyć czas wdrażania funkcji.

Format pliku

Jeśli do ustawienia niestandardowego tokena uwierzytelniania używasz pliku .npmrc, powinien on zawierać wiersz pokazany poniżej.

//REGISTRY_DOMAIN/:_authToken=AUTH_TOKEN

Zastąp:

  • REGISTRY_DOMAIN: nazwa domeny prywatnego rejestru npm. Jeśli repozytorium jest hostowane w npmjs.org, ustaw w tym polu wartość registry.npmjs.org.

  • AUTH_TOKEN: token autoryzacji dla rejestru npm. Może to być dosłowna wartość tekstowa tokena lub ciąg tekstowy ${NPM_TOKEN}, w którym npm jest zastępowany rzeczywistą wartością tokena z danego środowiska.

    Zmienną środowiskową $NPM_TOKEN możesz ustawić za pomocą argumentu --set-build-env-vars w poleceniu gcloud functions deploy. Więcej informacji o tokenie uwierzytelniania NPM znajdziesz w samouczku NPM dotyczącym modułów prywatnych.

Python

Zależności dla funkcji Cloud Functions napisanych w Pythonie można określić na 2 sposoby: za pomocą pliku requirements.txt menedżera pakietów pip lub przez spakowanie lokalnych zależności wraz z funkcją.

Specyfikacja zależności za pomocą standardu Pipfile/Pipfile.lock nie jest obsługiwana. Projekt nie powinien zawierać tych plików.

Określanie zależności za pomocą narzędzia pip

Zależności w Pythonie są zarządzane za pomocą narzędzia pip i wyrażane w pliku metadanych o nazwie requirements.txt. Ten plik musi znajdować się w tym samym katalogu co plik main.py zawierający kod funkcji.

Gdy wdrażasz lub ponownie wdrażasz funkcję, Cloud Functions używa narzędzia pip do pobierania i instalowania najnowszej wersji zależności zadeklarowanych w pliku requirements.txt. Plik requirements.txt zawiera po jednym wierszu na pakiet. Każdy wiersz zawiera nazwę pakietu i opcjonalnie żądaną wersję. Więcej informacji znajdziesz w requirements.txt dokumentacji.

Aby zapobiec wpływowi zmian wersji zależności na kompilację, rozważ przypięcie pakietów zależności do konkretnej wersji.

Oto przykład pliku requirements.txt:

functions-framework
requests==2.20.0
numpy

Pakowanie zależności lokalnych

Możesz też spakować i wdrożyć zależności razem z funkcją. To podejście jest przydatne, jeśli zależności nie są dostępne w menedżerze pakietów pip lub jeśli dostęp do internetu w środowisku Cloud Functions jest ograniczony.

Możesz na przykład użyć takiej struktury katalogów:

myfunction/
├── main.py
└── localpackage/
    ├── __init__.py
    └── script.py

Następnie możesz zaimportować kod w zwykły sposób z localpackage za pomocą tego polecenia:import

# Code in main.py
from localpackage import script

Pamiętaj, że ta metoda nie uruchomi żadnych plików setup.py. Pakiety z tymi plikami nadal można łączyć, ale mogą one nie działać prawidłowo na urządzeniu Cloud Functions.