כתיבה של פונקציות Cloud Run

פונקציות Cloud Run תומכות בכתיבת קוד מקור במספר שפות תכנות. השפה שבוחרים בזמן הריצה וסוג הפונקציה שרוצים לכתוב קובעים את מבנה הקוד ואת אופן ההטמעה של הפונקציה. בדף הזה מופיעה סקירה כללית של סוגי הפונקציות של Cloud Run והציפיות לגבי קוד המקור.

סוגים של פונקציות Cloud Run

יש שני סוגים של פונקציות Cloud Run:

משתמשים בפונקציית HTTP כשרוצים שלפונקציה תהיה נקודת קצה (endpoint) של כתובת URL והיא תגיב לבקשות HTTP, למשל עבור webhook. משתמשים בפונקציה מבוססת-אירועים כשהפונקציה צריכה להיות מופעלת ישירות בתגובה לאירועים ב Google Cloud פרויקט, כמו הודעות בנושא Pub/Sub או שינויים בקטגוריה של Cloud Storage.

המבנה של ספריית קובצי המקור

כדי שפונקציות Cloud Run יוכלו לאתר את הגדרת הפונקציה, לכל סביבת זמן ריצה של שפה יש דרישות לגבי המבנה של קוד המקור. בהמשך מוצגת מבנה הספריות הבסיסי של פונקציה בכל זמן ריצה.

Node.js

מבנה הספריות הבסיסי של פונקציות Node.js הוא כזה:

.
├── index.js
└── package.json

כברירת מחדל, פונקציות Cloud Run מנסות לטעון קוד מקור מקובץ בשם index.js בספריית הבסיס של הפונקציה. כדי לציין קובץ מקור ראשי אחר, משתמשים בשדה main בקובץ package.json.

קובץ package.json צריך לכלול גם את Functions Framework for Node.js כתלות:

{
  "main": "index.js",
  "dependencies": {
    "@google-cloud/functions-framework": "^3.0.0"
  }
}

הקוד בקובץ הראשי צריך להגדיר את נקודת הכניסה של הפונקציה, ויכול לייבא קוד אחר ומודולים של Node.js כרגיל. בנוסף, בקובץ הראשי אפשר להגדיר כמה נקודות כניסה לפונקציות שאפשר לפרוס בנפרד.

Python

מבנה הספריות הבסיסי של פונקציות Python הוא כדלקמן:

.
├── main.py
└── requirements.txt

פונקציות Cloud Run טוענות קוד מקור מקובץ בשם main.py שנמצא בספריית הבסיס של הפונקציה. הקובץ הראשי צריך להיקרא main.py.

קובץ requirements.txt צריך לכלול את Functions Framework for Python כתלות:

functions-framework==3.*

הקוד בקובץ main.py צריך להגדיר את נקודת הכניסה של הפונקציה, ויכול לייבא קוד אחר ותלות חיצונית כרגיל. קובץ main.py יכול להגדיר גם כמה נקודות כניסה לפונקציות שאפשר לפרוס בנפרד.

Go

המבנה הבסיסי של ספריית פונקציות Go הוא כדלקמן:

.
├── myfunction.go
└── go.mod

הפונקציה צריכה להיות בחבילת Go בשורש הפרויקט. לחבילה ולקובצי המקור שלה יכול להיות כל שם, אבל הפונקציה לא יכולה להיות ב-package main. אם אתם צריכים חבילת main, למשל לצורך בדיקות מקומיות, אתם יכולים ליצור אותה בספריית משנה:

.
├── myfunction.go
├── go.mod
└── cmd/
    └── main.go

קובץ go.mod צריך לכלול את Functions Framework for Go כתלות:

module example.com/my-module

require (
  github.com/GoogleCloudPlatform/functions-framework-go v1.5.2
)

הקוד בחבילת הבסיס צריך להגדיר את נקודת הכניסה של הפונקציה, ויכול לייבא קוד אחר מחבילות משנה ומקובצי תלות כרגיל. החבילה יכולה להגדיר גם כמה נקודות כניסה של פונקציות שאפשר לפרוס בנפרד.

Java

מבנה הספריות הבסיסי של פונקציות Java הוא כדלקמן:

.
├── pom.xml
└── src/
    └── main/
        └── java/
            └── MyFunction.java

קבצי המקור של Java צריכים להיות בתיקייה src/main/java/, והשם שלהם יכול להיות כל שם. אם קובצי המקור מגדירים חבילה, מוסיפים עוד ספרייה מתחת ל-src/main/java עם שם החבילה:

.
├── pom.xml
└── src/
    └── main/
        └── java/
            └── mypackage/
                └── MyFunction.java

מומלץ למקם את הבדיקות המשויכות בספריית משנה src/test/java/.

קובץ ה-pom.xml צריך לכלול את Functions Framework for Java כתלות:

...
    <dependency>
      <groupId>com.google.cloud.functions</groupId>
      <artifactId>functions-framework-api</artifactId>
      <version>1.0.4</version>
    </dependency>
...

הקוד בקובצי המקור צריך להגדיר את נקודת הכניסה של הפונקציה, ואפשר לייבא קוד אחר ותלות חיצונית כרגיל. בנוסף, קובצי המקור יכולים להגדיר כמה נקודות כניסה של פונקציות שאפשר לפרוס בנפרד.

C#‎

מבנה הספריות הבסיסי של פונקציות ‎ .NET הוא כדלקמן:

.
├── MyFunction.cs
└── MyProject.csproj

אתם יכולים לבנות את הפרויקטים שלכם כמו כל קוד מקור אחר של ‎ .NET. קובצי המקור יכולים להיות בכל שם.

קובץ הפרויקט צריך לכלול את Functions Framework for .NET כתלות:

...
    <PackageReference Include="Google.Cloud.Functions.Hosting" Version="1.0.0" />
...

הקוד בקובצי המקור צריך להגדיר את נקודת הכניסה של הפונקציה, ואפשר לייבא קוד אחר ותלות חיצונית כרגיל. בנוסף, קובצי המקור יכולים להגדיר כמה נקודות כניסה של פונקציות שאפשר לפרוס בנפרד.

אפשר גם להשתמש בחבילת תבניות הפונקציות של Cloud Run עבור ‎ .NET כדי ליצור את הקבצים הנדרשים.

Ruby

מבנה הספריות הבסיסי של פונקציות Ruby הוא כדלקמן:

.
├── app.rb
├── Gemfile
└── Gemfile.lock

פונקציות Cloud Run טוענות קוד מקור מקובץ בשם app.rb שנמצא בספריית הבסיס של הפונקציה. הקובץ הראשי צריך להיקרא app.rb.

קובץ ה-Gemfile צריך לכלול את Functions Framework for Ruby כתלות:

source "https://rubygems.org"
gem "functions_framework", "~> 1.0"

הקוד בקובץ app.rb צריך להגדיר את נקודת הכניסה של הפונקציה, ויכול לייבא קוד אחר ותלות חיצונית כרגיל. קובץ app.rb יכול להגדיר גם כמה נקודות כניסה לפונקציות שאפשר לפרוס בנפרד.

PHP

מבנה הספריות הבסיסי של פונקציות PHP הוא כזה:

.
├── index.php
└── composer.json

פונקציות Cloud Run טוענות קוד מקור מקובץ בשם index.php שנמצא בספריית הבסיס של הפונקציה. הקובץ הראשי צריך להיקרא index.php.

קובץ composer.json צריך לכלול את Functions Framework for PHP כתלות:

{
  "require": {
    "google/cloud-functions-framework": "^1.1"
  }
}

הקוד בקובץ index.php צריך להגדיר את נקודת הכניסה של הפונקציה, ויכול לייבא קוד אחר ותלות חיצונית כרגיל. קובץ index.php יכול להגדיר גם כמה נקודות כניסה לפונקציות שאפשר לפרוס בנפרד.

אם אתם מתכננים לקבץ כמה פונקציות בפרויקט אחד, חשוב לדעת שכל הפונקציות עשויות לחלוק את אותה קבוצת תלות. עם זאת, יכול להיות שחלק מהפונקציות לא יזדקקו לכל התלויות.

במקרים שבהם זה אפשרי, מומלץ לפצל בסיסי קוד גדולים עם כמה פונקציות ולהציב כל פונקציה בספרייה משלה ברמה העליונה, כמו שמוצג למעלה, עם קובצי מקור וקובצי הגדרות פרויקט משלה. הגישה הזו מצמצמת את מספר התלויות שנדרשות לפונקציה מסוימת, וכך מקטינה את כמות הזיכרון שהפונקציה צריכה.

נקודת כניסה לפונקציה

בקוד המקור צריך להגדיר נקודת כניסה לפונקציה, כלומר הקוד הספציפי שמופעל כשמפעילים את פונקציית Cloud Run. מציינים את נקודת הכניסה הזו כשפורסים את הפונקציה.

הדרך להגדיר את נקודת הכניסה תלויה בסביבת זמן הריצה של השפה שבה אתם משתמשים. בשפות מסוימות, נקודת הכניסה היא פונקציה, ובשפות אחרות נקודת הכניסה היא מחלקה. מידע נוסף על הגדרת נקודות כניסה ועל הטמעה של פונקציות Cloud Run בשפות שונות זמין במאמרים כתיבת פונקציות HTTP וכתיבת פונקציות מבוססות-אירועים.

תלויות

אפשר לנהל את התלויות באמצעות כלים סטנדרטיים לכל סביבת ריצה. מידע נוסף זמין בדפים הבאים:

השלבים הבאים