פתרון בעיות בפונקציות Cloud Run (דור ראשון)

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

פריסה

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

חסרות הרשאות Pub/Sub לחשבון השירות של הפריסה כשפורסים פונקציה מבוססת-אירועים

שירות Cloud Functions משתמש בחשבון השירות של סוכן השירות של Cloud Functions ‏ ([e-mail]) כדי לבצע פעולות ניהול. כברירת מחדל, לחשבון הזה מוקצה התפקיד cloudfunctions.serviceAgent ב-Cloud Functions. כדי לפרוס פונקציות מבוססות-אירועים, שירות Cloud Functions צריך גישה ל-Pub/Sub כדי להגדיר נושאים ומינויים. אם התפקיד שמוקצה לחשבון השירות משתנה וההרשאות המתאימות לא מתעדכנות, שירות Cloud Functions לא יכול לגשת ל-Pub/Sub והפריסה נכשלת.

הודעת השגיאה

המסוף

Failed to configure trigger PubSub projects/PROJECT_ID/topics/FUNCTION_NAME

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=13, message=Failed to configure trigger PubSub projects/PROJECT_ID/topics/FUNCTION_NAME

הפתרון

אפשר לאפס את חשבון השירות לתפקיד ברירת המחדל cloudfunctions.serviceAgent.

חשבון השירות שמוגדר כברירת מחדל לזמן הריצה לא קיים

אם לא מציינים חשבון שירות בניהול המשתמש, פונקציות Cloud Run (דור ראשון) משתמשות בחשבון השירות של App Engine כברירת מחדל. פריסות נכשלות אם מוחקים את חשבון ברירת המחדל בלי לציין חשבון שירות שמנוהל על ידי המשתמש.

הודעת השגיאה

gcloud

ERROR: (gcloud.functions.deploy) ResponseError: status=[400], code=[Ok], message=[Default service account '[e-mail]' doesn't exist. Please recreate this account or specify a different account. Please visit https://cloud.google.com/functions/docs/troubleshooting for in-depth troubleshooting documentation.]

הפתרון

כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:

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

• יוצרים מחדש את חשבון השירות שמוגדר כברירת מחדל ‫[e-mail] בפרויקט.

• מבטלים את המחיקה של חשבון השירות שמוגדר כברירת מחדל.

למשתמש חסרות הרשאות לחשבון שירות של זמן ריצה במהלך פריסת פונקציה

כל פונקציה משויכת לחשבון שירות שמשמש כזהות שלה כשהיא ניגשת למשאבים אחרים. חשבון השירות של זמן הריצה יכול להיות חשבון השירות שמוגדר כברירת מחדל או חשבון שירות שמנוהל על ידי משתמש. כדי ש-Cloud Functions יוכל להשתמש בחשבון שירות של זמן ריצה, למשתמש שפורס את הפונקציה צריכה להיות ההרשאה iam.serviceAccounts.actAs בחשבון השירות הזה. משתמש שיוצר חשבון שירות של זמן ריצה שאינו ברירת המחדל מקבל את ההרשאה הזו באופן אוטומטי, אבל משתמשים אחרים שפורסים צריכים לקבל את ההרשאה הזו ממשתמש עם ההרשאות המתאימות.

משתמש שהוקצה לו התפקיד 'צפייה בפרויקט', 'מפתח Cloud Functions' או 'אדמין Cloud Functions' צריך לקבל בנוסף את ההרשאה iam.serviceAccounts.actAs בחשבון השירות של זמן הריצה.

הודעת השגיאה

המסוף

You must have the iam.serviceAccounts.actAs permission on the selected service account. To obtain this permission, you can grant a role that includes it like the Service Account User role, on the project.

gcloud

השגיאה הבאה מתרחשת בחשבון השירות שמוגדר כברירת מחדל:

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Caller USER is missing permission 'iam.serviceaccounts.actAs' on service account [e-mail]. Grant the role 'roles/iam.serviceAccountUser' to the caller on the service account [e-mail]. You can do that by running 'gcloud iam service-accounts add-iam-policy-binding
[e-mail] --member MEMBER --role roles/iam.serviceAccountUser' where MEMBER has a prefix like 'user:' or 'serviceAccount:'.

השגיאה הבאה מתרחשת בחשבון שירות שלא מוגדר כברירת מחדל:

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Caller USER is missing permission 'iam.serviceaccounts.actAs' on service account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com. Grant the role 'roles/iam.serviceAccountUser' to the caller on the service account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com. You can do that by running 'gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com --member MEMBER --role roles/iam.serviceAccountUser' where MEMBER has a prefix like 'user:' or 'serviceAccount:'.

הערה: [e-mail] הוא חשבון השירות שמוגדר כברירת מחדל לזמן הריצה של פונקציות Cloud Run(דור ראשון). המחרוזת הזו מוחלפת בחשבון השירות SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com בניהול המשתמש בהודעת השגיאה כשמשתמשים בחשבון שירות שאינו ברירת המחדל.

הפתרון

מקצים למשתמש את התפקיד roles/iam.serviceAccountUser בחשבון השירות שמוגדר כברירת מחדל או בחשבון שירות שמנוהל על ידי משתמש. התפקיד הזה כולל את ההרשאה iam.serviceAccounts.actAs.

חסרות הרשאות לחשבון השירות של סוכן השירות של פונקציות Cloud Run בדלי של הפרויקט במהלך פריסת פונקציה

אפשר להפעיל פונקציות של Cloud Run רק באמצעות אירועים מקטגוריות של Cloud Storage באותו פרויקט Google Cloud . בנוסף, לחשבון השירות של סוכן השירות של Cloud Functions‏ ([e-mail]) צריך להיות התפקיד cloudfunctions.serviceAgent בפרויקט.

הודעת השגיאה

המסוף

Deployment failure: Insufficient permissions to (re)configure a trigger
(permission denied for bucket BUCKET_ID). Please, give owner permissions
to the editor role of the bucket and try again.

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=7, message=Insufficient
permissions to (re)configure a trigger (permission denied for bucket BUCKET_ID).
Please, give owner permissions to the editor role of the bucket and try again.

הפתרון

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

משתמש עם הרשאת עריכה בפרויקט לא יכול להגדיר פונקציה כציבורית

לתפקיד 'עורך פרויקט' יש הרשאות רחבות לניהול משאבים בפרויקט, אבל הוא לא מעניק באופן מובנה את היכולת להפוך פונקציות Cloud Run לציבוריות. צריך להעניק את ההרשאה cloudfunctions.functions.setIamPolicy למשתמש או לשירות שפורס את הפונקציה.

הודעת השגיאה

gcloud

 ERROR: (gcloud.functions.add-iam-policy-binding) ResponseError: status=[403], code=[Forbidden], message=[Permission 'cloudfunctions.functions.setIamPolicy' denied on resource 'projects/PROJECT_ID/locations/LOCATION/functions/FUNCTION_NAME (or resource may not exist).]

הפתרון

כדי לפתור את השגיאה, אפשר לנסות את הפתרונות הבאים:

• מקצים למשתמש שמבצע את הפריסה את התפקיד בעלי הפרויקט או את התפקיד אדמין של Cloud Functions. שני התפקידים האלה כוללים את ההרשאה cloudfunctions.functions.setIamPolicy.

• אפשר להעניק את ההרשאה באופן ידני על ידי יצירת תפקיד בהתאמה אישית.

• בודקים אם הגבלת השיתוף בדומיין נאכפת בפרויקט.

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

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

הודעת השגיאה

gcloud

  ERROR: (gcloud.functions.deploy) ResponseError: status=[400], code=[Ok], message=[The request has violated one or more Org Policies. Please refer to the respective violations for more information. violations {
    type: "constraints/gcp.resourceLocations"
    subject: "orgpolicy:projects/PROJECT_ID"
    description: "Constraint constraints/gcp.resourceLocations violated for projects/PROJECT_ID attempting GenerateUploadUrlActionV1 with location set to RESTRICTED_LOCATION. See https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints for more information."
  }

הפתרון

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

פריסת הפונקציה נכשלת במהלך ביצוע ההיקף הגלובלי של הפונקציה

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

הודעת השגיאה

המסוף

Deployment failure: Function failed on loading user code. This is likely due to a bug in the user code.

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=3, message=Function
failed on loading user code. This is likely due to a bug in the user code.

ביומנים של Cloud Logging:

  "Function failed on loading user code. This is likely due to a bug in the user code."

הפתרון

כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:

• כדי לראות הודעת שגיאה מפורטת יותר, אפשר לעיין ביומני הבנייה של הפונקציה.

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

• הגדלת הזמן הקצוב לתפוגה של הפונקציה.

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

משתמש עם הרשאת צפייה לא יכול לפרוס פונקציה

למשתמשים עם התפקיד Project Viewer או Cloud Functions Viewer יש גישת קריאה בלבד לפונקציות ולפרטי הפונקציות, והם לא יכולים לפרוס פונקציות חדשות. התכונה Create function מושבתת במסוףGoogle Cloud עם השגיאה הבאה:

הודעת השגיאה

gcloud

ERROR: (gcloud.functions.deploy) PERMISSION_DENIED: Permission
'cloudfunctions.functions.sourceCodeSet' denied on resource
'projects/PROJECT_ID/locations/LOCATION` (or resource may not exist)

הפתרון

מקצים למשתמש את התפקיד Cloud Functions Developer.

חסרות הרשאות לחשבון השירות של Build

הודעת השגיאה

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

The service account running this build does not have permission to write logs.
To fix this, grant the Logs Writer (roles/logging.logWriter) role to the service
account.

Step #0 - "fetch": failed to Fetch: failed to download archive gs://gcf-sources-PROJECT_NUMBER-LOCATION/FUNCTION_NAME/version-VERSION_NUMBER/function-source.zip: Access to bucket gcf-sources-PROJECT_NUMBER-LOCATION denied. You must grant Storage Object Viewer permission to [e-mail].

Step #2 - "build": ERROR: failed to create image cache: accessing cache image "LOCATION-docker.pkg.dev/PROJECT/gcf-artifacts/FUNCTION_NAME/cache:latest": connect to repo store "LOCATION-docker.pkg.dev/PROJECT/gcf-artifacts/FUNCTION_NAME/cache:latest": GET https://LOCATION-docker.pkg.dev/v2/token?scope=repository%3APROJECT%2Fgcf-artifacts%2FFUNCTION_NAME%2Fcache%3Apull&service=: DENIED: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/PROJECT/locations/LOCATION/repositories/gcf-artifacts" (or it may not exist)

Could not build the function due to a missing permission on the build service account. If  you didn't revoke that permission explicitly, this could be caused by a change in the organization policies.

הפתרון

לחשבון השירות של ה-build צריכה להיות הרשאת קריאה מקטגוריית המקור והרשאות קריאה וכתיבה במאגר של Artifact Deployment. יכול להיות שתיתקלו בשגיאה הזו בגלל שינוי בהתנהגות ברירת המחדל של השימוש בחשבונות שירות ב-Cloud Build, שמפורט במאמר בנושא שינוי בחשבונות השירות שמשמשים כברירת מחדל ב-Cloud Build.

כדי לפתור את הבעיה, אפשר לנסות אחד מהפתרונות הבאים:

• יוצרים חשבון שירות בהתאמה אישית לבנייה לפריסות של פונקציות.
• מוסיפים את התפקיד של חשבון השירות ב-Cloud Build (roles/cloudbuild.builds.builder) לחשבון השירות שמוגדר כברירת מחדל ב-Compute.
• כדאי לעיין בהנחיות של Cloud Build בנושא השינויים בחשבון השירות שמוגדר כברירת מחדל ולבטל את ההסכמה לשינויים האלה.

האפשרות 'יצירת חשבון שירות' מושבתת

הודעת השגיאה

Could not build the function due to disabled service account used by Cloud Build. Please make sure that the service account is active.

הפתרון

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

כדי לפתור את הבעיה, אפשר לנסות אחד מהפתרונות הבאים:

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

השרת ממלא את הבקשה

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

שגיאת הרשאה להצגת מודעות בגלל שהפונקציה דורשת אימות

פונקציות HTTP ללא הפעלת האפשרות Allow unauthenticated invocations מגבילות את הגישה למשתמשי קצה ולחשבונות שירות שאין להם הרשאות מתאימות.

כשנכנסים לכתובת ה-URL של פונקציות Cloud Run בדפדפן, כותרת האימות לא מתווספת אוטומטית.

הודעת השגיאה

קוד תגובת שגיאת HTTP: ‏ 403 Forbidden

התוכן של תגובת שגיאת HTTP:

Error: Forbidden Your client does not have permission
to get URL /FUNCTION_NAME from this server.

הפתרון

כדי לפתור את השגיאה, אפשר לנסות את אחד מהפתרונות הבאים:

• מקצים למשתמש את התפקיד Cloud Run functions Invoker.

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

שגיאת הרשאה להצגת מודעות בגלל הגדרת allow internal traffic only

הגדרות התעבורה הנכנסת (ingress) מגבילות את האפשרות להפעיל פונקציית HTTP על ידי משאבים מחוץ ל Google Cloud פרויקט או לגבולות גזרה לשירות של VPC Service Controls. כשמגדירים את האפשרות allow internal traffic only (אפשרות שמאפשרת רק תנועה פנימית) עבור Ingress רישות, הודעת השגיאה הזו מציינת שמותרות רק בקשות מרשתות VPC באותו פרויקט או ב-perimeter של VPC Service Controls.

הערה: כשנכנסים לכתובת ה-URL של פונקציות Cloud Run בדפדפן, כותרת האימות לא נוספת באופן אוטומטי.

הודעת השגיאה

קוד תגובת שגיאת HTTP: ‏ 404 NOT FOUND

התוכן של תגובת שגיאת HTTP:

404 Page not found

הפתרון

כדי לפתור את השגיאה, אפשר לנסות את אחד מהפתרונות הבאים:

• מוודאים שהבקשה מגיעה מהפרויקט Google Cloud או מגבולות גזרה לשירות של VPC Service Controls.

• משנים את הגדרות הכניסה לallow all traffic (התרת כל התנועה) עבור הפונקציה.

• קוד המקור של פונקציות Cloud Run עלול לגרום לשגיאת 404 בגלל כתובת URL שגויה של פונקציה, שיטות HTTP או שגיאות לוגיות.

להפעלת הפונקציה חסרים פרטי כניסה תקינים לאימות

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

הודעת השגיאה

קוד תגובת שגיאת HTTP: ‏ 401 Unauthorized

התוכן של תגובת שגיאת HTTP:

Your client does not have permission to the requested URL </FUNCTION_NAME>

הפתרון

כדי לפתור את השגיאה, אפשר לנסות את אחד מהפתרונות הבאים:

• מוודאים שהבקשות כוללות כותרת Authorization: Bearer ID_TOKEN, ושהאסימון הוא אסימון מזהה, ולא אסימון גישה או אסימון רענון. אם יוצרים את האסימון הזה באופן ידני באמצעות מפתח פרטי של חשבון שירות, צריך להחליף את אסימון ה-JWT בחתימה עצמית באסימון זהות בחתימה של Google. מידע נוסף זמין במאמר בנושא אימות להפעלה.

• מפעילים את פונקציית ה-HTTP באמצעות פרטי אימות בכותרת הבקשה. לדוגמה, אפשר לקבל אסימון זהות באמצעות gcloud באופן הבא:

  curl  -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
    https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME

  מידע נוסף זמין במאמר אימות להפעלה .

הפונקציה מפסיקה באמצע ההרצה או ממשיכה לפעול אחרי שהקוד מסתיים

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

התנהגות השגיאה

הפונקציה שלכם מציגה אחת מההתנהגויות הבאות:

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

הפתרון

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

• החזרת ערך
• פתרון או דחייה של אובייקט Promise שהוחזר (פונקציות Node.js בלבד)
• הקפצת הודעת שגיאה (throw) לחריגים ושגיאות שלא נתפסו
• שליחת תגובת HTTP
• הפעלת פונקציית קריאה חוזרת

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

שגיאת זמן ריצה כשניגשים למשאבים שמוגנים על ידי VPC Service Controls

כברירת מחדל, פונקציות Cloud Run משתמשות בכתובות IP ציבוריות כדי לשלוח בקשות יוצאות לשירותים אחרים. יכול להיות שפונקציות שלא נמצאות בתוך גבולות הגזרה של VPC Service Controls יקבלו תגובות HTTP 403 כשהן מנסות לגשת לשירותים שמוגנים על ידי VPC Service Controls, בגלל דחיות של גבולות גזרה לשירות. Google Cloud

הודעת השגיאה

ביומנים של משאבים שנבדקו, רשומה כמו הבאה:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {
    "principalEmail": "CLOUD_FUNCTION_RUNTIME_SERVICE_ACCOUNT",
  ...
  "metadata": {
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
    "securityPolicyInfo": {
      "organizationId": "ORGANIZATION_ID",
      "servicePerimeterName": "accessPolicies/NUMBER/servicePerimeters/SERVICE_PERIMETER_NAME"
  ...

הפתרון

כדי לפתור את השגיאה, אפשר לנסות את אחד מהפתרונות הבאים:

• הפונקציה צריכה לנתב את כל התנועה היוצאת דרך רשת ה-VPC. מידע נוסף זמין בקטע פריסת פונקציות שתואמות ל-VPC Service Controls.

• אפשרות אחרת היא להעניק לחשבון השירות של זמן הריצה של הפונקציה גישה להיקף. אפשר לעשות את זה על ידי יצירת רמת גישה והוספת רמת הגישה לגבולות הגזרה לשירות, או על ידי יצירת מדיניות תעבורת נתונים נכנסת בגבולות הגזרה. מידע נוסף זמין במאמר שימוש ב-VPC Service Controls עם פונקציות מחוץ לגבולות הגזרה.

מדרגיות

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

שגיאות ב-Cloud Logging שקשורות לביטולים של בקשות בתור בהמתנה

התנאים הבאים יכולים להיות קשורים לכשלים בהרחבה.

• עלייה פתאומית ומשמעותית בנפח התנועה.
• זמן הפעלה ארוך במצב התחלתי (cold start).
• זמן עיבוד הבקשה ארוך.
• שיעור גבוה של שגיאות בפונקציה.
• הגעתם למגבלת המופעים המקסימלית.
• גורמים חולפים שמשויכים לשירות פונקציות Cloud Run.

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

הודעת השגיאה

 The request was aborted because there was no available instance.

לפונקציות Cloud Run יש את רמות החומרה הבאות:

* `severity=WARNING` ( Response code: 429 ) Cloud Run functions cannot scale due
  to the [`max-instances`](/functions/docs/configuring/max-instances) limit you set
  during configuration.
* `severity=ERROR` ( Response code: 500 ) Cloud Run functions intrinsically
  cannot manage the rate of traffic.

הפתרון

• בפונקציות שמבוססות על טריגר HTTP, צריך להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) וניסיונות חוזרים לבקשות שאסור להפסיק. אם מפעילים פונקציות Cloud Run מ-Workflows, אפשר להשתמש בתחביר try/retry כדי לעשות זאת.
• פונקציות Cloud Run תומכות במסירה של לפחות פעם אחת עבור פונקציות ברקע או פונקציות מבוססות-אירועים. גם אם לא מפעילים במפורש ניסיון חוזר, האירוע מועבר מחדש באופן אוטומטי והפעלת הפונקציה תתבצע מחדש. מידע נוסף זמין במאמר בנושא הפעלת ניסיונות חוזרים של פונקציות מבוססות-אירועים.
• אם שגיאות חולפות רבות הן הגורם העיקרי לבעיה, והן משויכות רק לפונקציות Cloud Run, או אם אתם צריכים עזרה בפתרון הבעיה, תוכלו לפנות אל Cloud Customer Care.

רישום ביומן

בקטע הבא מוסבר על בעיות שקשורות לרישום ביומן ואיך לפתור אותן.

רשומות ביומן לא כוללות רמות חומרה או שהן שגויות

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

הפתרון

כדי לכלול חומרת יומן, צריך לשלוח רשומה מובנית ביומן.

הערה: החל מספטמבר 2020, כל סביבת ריצה חדשה שמופצת תשתמש בהתנהגות ברירת המחדל של רמת חומרת היומן, כפי שהוגדרה בספריית סביבת הריצה עצמה. לדוגמה, ב-Python 3.8, רמת החומרה של יומן ברירת המחדל מוגדרת ל-WARNING או לרמה גבוהה יותר. אם רוצים לתעד אירועים ברמת חומרה DEBUG או INFO באמצעות Python 3.8, צריך גם להגדיר באופן פרוגרמטי את רמת היומן כך שתכלול את הרמות האלה.

טיפול בחריגות או רישום שלהן ביומן באופן שונה במקרה של קריסה

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

הפתרון

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

הוספה של בלוק try עלולה לגרום לתופעת לוואי לא מכוונת בפונקציות מבוססות-אירועים עם הגדרת retry on failure. יכול להיות שהניסיון החוזר של אירועים שנכשלו ייכשל בעצמו.

דוגמה

import logging
import traceback
def try_catch_log(wrapped_func):
  def wrapper(*args, **kwargs):
    try:
      response = wrapped_func(*args, **kwargs)
    except Exception:
      # Replace new lines with spaces so as to prevent several entries which
      # would trigger several errors.
      error_message = traceback.format_exc().replace('\n', '  ')
      logging.error(error_message)
      return 'Error';
    return response;
  return wrapper;

#Example hello world function

@try_catch_log
def python_hello_world(request):
  request_args = request.args

  if request_args and 'name' in request_args:
    1 + 's'
  return 'Hello World!'

היומנים גדולים מדי ב-Node.js 10+,‏ Python 3.8,‏ Go 1.13 ו-Java 11

הגודל המקסימלי של רשומה רגילה ביומן בזמני הריצה האלה הוא 105KiB.

הפתרון

שליחת רשומות ביומן שקטנות מהמגבלה הזו.

יומנים חסרים למרות שפונקציות Cloud Run מחזירות שגיאות

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

הפתרון

מפעילים את יומני ברירת המחדל ומוודאים שלא מוגדר מסנן החרגה.

הערה: הפעלת Cloud Logging עשויה להיות כרוכה בחיובים.

יומנים של פונקציות Cloud Run לא מופיעים ב-Logs Explorer

חלק מספריות הלקוח של Cloud Logging משתמשות בתהליך אסינכרוני כדי לכתוב רשומות ביומן. אם פונקציה קורסת או מסתיימת מסיבה אחרת, יכול להיות שחלק מרישומי היומן עדיין לא נכתבו ויכול להיות שהם יופיעו מאוחר יותר. יכול להיות שחלק מהיומנים יאבדו ולא יוצגו בכלי Logs Explorer.

הפתרון

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

יומנים של פונקציות Cloud Run לא מופיעים באמצעות יעד של Log Router

מאגרי Log Router מעבירים רשומות של יומני פעילות ליעדים שונים.

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

הפתרון

הסרת קבוצת מסנני ההחרגה של resource.type="cloud_functions".

חיבורים למסד נתונים

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

Networking

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

קישוריות רשת

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

מחבר הגישה ל-VPC מאפליקציית serverless לא מוכן או לא קיים

אם מחבר Serverless VPC Access נכשל, יכול להיות שהוא לא משתמש במסכה של רשת משנה /28 שמוקדשת למחבר, כפי שנדרש.

הודעת השגיאה

VPC connector projects/xxxxx/locations/REGION/connectors/xxxx
is not ready yet or does not exist.

כשפונקציות Cloud Run נפרסות עם מחבר במצב לא תקין בגלל הרשאה חסרה בחשבון השירות Google APIs Service Agent [e-mail], מתקבלת השגיאה הבאה:

הודעת השגיאה

Failed to prepare VPC connector. Please try again later.

הפתרון

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

כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:

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

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

• מוודאים שפונקציות Cloud Run והמחבר המשויך להן נפרסו באותו אזור.

• בהגדרת VPC משותף :

  • חשוב לוודא שלחשבונות השירות [e-mail] ו[e-mail] שמשמשים את VPC Connector להקצאת משאבים בפרויקט יש את ההרשאות הנדרשות. לחשבונות השירות האלה צריך להיות התפקיד roles/compute.networkUser בפרויקט המארח של הגדרת ה-VPC המשותף, כשהמחבר נמצא בפרויקט השירות. אחרת, חובה להזין ערך בroles/compute.networkAdmin.

  • אם המחבר נוצר בפרויקט המארח, צריך לוודא שהתפקיד Serverless VPC Access User מוענק ב-Cloud Run functions Service Agent בפרויקט המארח.

  • אם סטטוס המחבר הוא Connector is in a bad state, manual deletion recommended error, ול-סוכן שירות של Google APIs חסרות ההרשאות הנדרשות להקצאת משאבי מחשוב בפרויקט של המחבר, צריך להעניק את ההרשאה roles/compute.admin לחשבון השירות [e-mail]. במקרים מסוימים, יכול להיות שתצטרכו ליצור מחדש את המחבר אחרי עדכון ההרשאות.

תנועת SMTP לכתובות IP חיצוניות של יעד באמצעות יציאת TCP ‏25 חסומה

מטעמי אבטחה, Google Cloud החיבורים ליעד של יציאת TCP ‏25 חסומים כששולחים אימיילים מפונקציות Cloud Run.

הפתרון

כדי לבטל את החסימה של החיבורים האלה, בוחרים באחת מהאפשרויות הבאות:

• מתחברים לשרת ה-SMTP ביציאה אחרת, כמו יציאת TCP‏ 587 או 465.

• שימוש בשירות אימייל של צד שלישי.

אחר

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

שגיאה ב-VPC Service Controls בשיטה google.storage.buckets.testIamPermissions ב-Cloud Audit Logs

כשפותחים את הדף Function details במסוףGoogle Cloud , המערכת של פונקציות Cloud Run בודקת אם יש לכם אפשרות לשנות את מאגר האחסון של תמונת הקונטיינר ולגשת אליו באופן ציבורי. כדי לאמת, פונקציות Cloud Run שולחות בקשה לקטגוריה של Container Registry באמצעות השיטה google.storage.buckets.testIamPermissions בפורמט הבא: [REGION].artifacts.[PROJECT_ID].appspot.com. ההבדל היחיד בין הבדיקות הוא שאחת מהן מופעלת עם אימות כדי לוודא שלמשתמש יש הרשאות לשנות את הדלי, והבדיקה השנייה מופעלת ללא אימות כדי לוודא שהדלי נגיש לכולם.

אם גבולות הגזרה של VPC Service Controls מגבילים את ה-API‏ storage.googleapis.com, במסוף מוצגת שגיאה בשיטה google.storage.buckets.testIamPermissions ביומני הביקורת של Cloud. Google Cloud

הודעת השגיאה

במקרה של בדיקת גישה ציבורית ללא פרטי אימות, ביומני הביקורת של מדיניות הדחייה של VPC SC מופיעה רשומה שדומה לזו:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {},
  "requestMetadata": {
    "callerIp": "END_USER_IP"
  },
  "serviceName": "storage.googleapis.com",
  "methodName": "google.storage.buckets.testIamPermissions",
  "resourceName": "projects/PROJECT_NUMBER",
  "metadata": {
    "ingressViolations": [
      {
        "servicePerimeter": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
        "targetResource": "projects/PROJECT_NUMBER"
      }
    ],
    "resourceNames": [
      "projects/_/buckets/REGION.artifacts.PROJECT_ID.appspot.com"
    ],
    "securityPolicyInfo": {
      "servicePerimeterName": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
      "organizationId": "ORG_ID"
    },
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
  ...

במקרה של בדיקת גישה ציבורית עם פרטי אימות, ביומני הביקורת של VPC SC Denial Policy מופיעה רשומה שמאפשרת למשתמש לשנות את הגדרות הקטגוריה, בדומה לדוגמה הבאה:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {
    "principalEmail": "END_USER_EMAIL"
  },
  "requestMetadata": {
    "callerIp": "END_USER_IP",
    "requestAttributes": {},
    "destinationAttributes": {}
  },
  "serviceName": "storage.googleapis.com",
  "methodName": "google.storage.buckets.testIamPermissions",
  "resourceName": "projects/PROJECT_NUMBER",
  "metadata": {
    "ingressViolations": [
      {
        "servicePerimeter": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
        "targetResource": "projects/PROJECT_NUMBER"
      }
    ],
    "resourceNames": [
      "projects/_/buckets/REGION.artifacts.PROJECT_ID.appspot.com"
    ],
    "securityPolicyInfo": {
      "servicePerimeterName": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
      "organizationId": "ORG_ID"
    },
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
  ...

הפתרון

אם הקטגוריה של Container Registry לא נגישה לציבור, אפשר להתעלם מהשגיאות של VPC Service Controls.

לחלופין, אפשר להוסיף כלל תעבורת נתונים נכנסת (ingress) של VPC Service Controls כדי לאפשר את השימוש בשיטה google.storage.buckets.testIamPermissions, כמו בדוגמה הבאה:

ingress_from {
  sources {
    access_level: "*"
  }
  identity_type: ANY_IDENTITY
}
ingress_to {
  operations {
    service_name: "storage.googleapis.com"
    method_selectors {
      method: "google.storage.buckets.testIamPermissions"
    }
  }
  resources: "projects/PROJECT_NUMBER"
}

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