סביבת ההפעלה של Cloud Functions
פונקציות Cloud Run פועלות בסביבה מנוהלת ללא שרת, שבה Google מטפלת בתשתית, במערכות ההפעלה ובסביבות זמן הריצה. כל פונקציה פועלת בהקשר ביצוע מאובטח ומבודד משלה, מתרחבת באופן אוטומטי ויש לה מחזור חיים עצמאי שלא תלוי בפונקציות אחרות.
זמני ריצה
פונקציות Cloud Run תומכות בסביבות ריצה בכמה שפות. כל אחד מהם מכיל קבוצה סטנדרטית של חבילות מערכת, וגם את הכלים והספריות שנדרשים לשפה הזו. תצטרכו את הערך של מזהה זמן הריצה אם אתם פורסים פונקציות משורת הפקודה או דרך Terraform.
עדכוני אבטחה ותחזוקה זמינים לכל סביבות ההפעלה מהדור הראשון והשני. העדכונים האלה מיושמים באופן אוטומטי או ידני, בהתאם לסביבה ולאופן ההגדרה שלה. מידע נוסף על עדכונים של סביבת ההפעלה זמין במאמר הגנה על פונקציית Cloud Run.
Node.js
Python
המשך
Java
| זמן ריצה | יצירה | סביבה | המזהה של סביבת זמן הריצה | תמונה נטענת לאפקט |
|---|---|---|---|---|
| Java 25 | דור שני | Ubuntu 24.04 | java25 | us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/java25 |
| Java 21 | דור שני | Ubuntu 22.04 | java21 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/java21 |
| Java 17 | דור ראשון, דור שני | Ubuntu 22.04 | java17 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/java17 |
| Java 11 | דור ראשון, דור שני | Ubuntu 18.04 | java11 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/java11 |
Ruby
| זמן ריצה | יצירה | סביבה | המזהה של סביבת זמן הריצה | תמונה נטענת לאפקט |
|---|---|---|---|---|
| Ruby 4.0 | דור שני | Ubuntu 24.04 | ruby40 | us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/ruby40 |
| Ruby 3.4 | דור שני | Ubuntu 22.04 | ruby34 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby34 |
| Ruby 3.3 | דור ראשון, דור שני | Ubuntu 22.04 | ruby33 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby33 |
| Ruby 3.2 | דור ראשון, דור שני | Ubuntu 22.04 | ruby32 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/ruby32 |
| Ruby 3.0 | דור ראשון, דור שני | Ubuntu 18.04 | ruby30 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby30 |
| Ruby 2.7 | דור ראשון, דור שני | Ubuntu 18.04 | ruby27 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby27 |
| Ruby 2.6 | דור ראשון, דור שני | Ubuntu 18.04 | ruby26 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/ruby26 |
PHP
| זמן ריצה | סביבה | יצירה | המזהה של סביבת זמן הריצה | תמונה נטענת לאפקט |
|---|---|---|---|---|
| PHP 8.5 | דור שני | Ubuntu 24.04 | php85 | us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/php85 |
| PHP 8.4 | דור שני | Ubuntu 22.04 | php84 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php84 |
| PHP 8.3 | דור שני | Ubuntu 22.04 | php83 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php83 |
| PHP 8.2 | דור ראשון, דור שני | Ubuntu 22.04 | php82 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/php82 |
| PHP 8.1 | דור ראשון, דור שני | Ubuntu 18.04 | php81 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/php81 |
| PHP 7.4 | דור ראשון, דור שני | Ubuntu 18.04 | php74 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/php74 |
.NET Core
| זמן ריצה | יצירה | סביבה | המזהה של סביבת זמן הריצה | תמונה נטענת לאפקט |
|---|---|---|---|---|
| .NET Core 10 | דור שני | Ubuntu 24.04 | dotnet10 | us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/dotnet10 |
| .NET Core 8 | דור שני | Ubuntu 22.04 | dotnet8 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/dotnet8 |
| .NET Core 6 | דור ראשון, דור שני | Ubuntu 22.04 | dotnet6 | us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/dotnet6 |
| .NET Core 3 | דור ראשון, דור שני | Ubuntu 18.04 | dotnet3 | us-central1-docker.pkg.dev/serverless-runtimes/google-18-full/runtimes/dotnet3 |
התנהגות של התאמה אוטומטית לעומס (autoscaling)
פונקציות Cloud Run מיישמות את פרדיגמת ה-serverless, שבה מריצים את הקוד בלי לדאוג לתשתית הבסיסית, כמו שרתים או מכונות וירטואליות. אחרי הפריסה, המערכת מנהלת את הפונקציות ומבצעת שינוי גודל שלהן באופן אוטומטי.
פונקציות Cloud Run מטפלות בבקשות נכנסות על ידי הקצאה שלהן למופעים של הפונקציה. בהתאם לנפח הבקשות ולמספר המופעים הקיימים של הפונקציה, פונקציות Cloud Run עשויות להקצות בקשה למופע קיים או ליצור מופע חדש.
במקרים שבהם נפח הבקשות הנכנסות חורג ממספר המופעים הקיימים, פונקציות Cloud Run עשויות להפעיל כמה מופעים חדשים כדי לטפל בבקשות. התנהגות ההתאמה האוטומטית לעומס הזו מאפשרת לפונקציות Cloud Run לטפל בהרבה בקשות במקביל, כשכל בקשה משתמשת במופע אחר של הפונקציה.
במקרים מסוימים, יכול להיות שלא תרצו להשתמש בהרחבה ללא הגבלה. כדי לפתור את הבעיה הזו, פונקציות Cloud Run מאפשרות להגדיר מספר מרבי של מופעים שיכולים להתקיים בו-זמנית עבור פונקציה מסוימת.
חוסר שמירת מצב
כדי להפעיל ניהול והתאמה לעומס אוטומטיים של הפונקציות, הפונקציות צריכות להיות בלי שמירת מצב – הפעלה של פונקציה לא יכולה להסתמך על מצב בזיכרון שהוגדר על ידי הפעלה קודמת. יכול להיות שקריאות לפונקציה יטופלו על ידי מופעים שונים של הפונקציה, שלא משתפים משתנים גלובליים, זיכרון, מערכות קבצים או מצב אחר.
אם צריך לשתף מצב בין הפעלות של פונקציות, הפונקציה צריכה להשתמש בשירות כמו Memorystore, Datastore, Firestore או Cloud Storage כדי לשמור את הנתונים. מידע נוסף על אפשרויות האחסון ומסדי הנתונים ש- Google Cloudמספקת זמין במאמרים בנושא Google Cloud מסדי נתונים וGoogle Cloud מוצרי אחסון.
בו-זמניות (concurrency)
פונקציות Cloud Run (דור שני)
פונקציות Cloud Run (דור שני) תומכות בטיפול בכמה בקשות בו-זמנית במופע פונקציה יחיד. השימוש בשיטה הזו יכול לעזור למנוע הפעלות קרות, כי מופע שכבר חומם יכול לעבד כמה בקשות בו-זמנית, וכך להקטין את זמן האחזור הכולל. פרטים נוספים זמינים במאמר בנושא שימוש בו-זמני.
פונקציות Cloud Run (דור ראשון)
בפונקציות Cloud Run (דור ראשון), כל מופע של פונקציה מטפל רק בבקשה מקבילה אחת בכל פעם. המשמעות היא שכשקוד מעבד בקשה אחת, אין אפשרות להפנות בקשה שנייה לאותו מופע. לכן, הבקשה המקורית יכולה להשתמש בכל כמות המשאבים (זיכרון ומעבד) שהקציתם.
מכיוון שבפונקציות Cloud Run (דור ראשון) בקשות מקבילות מעובדות על ידי מופעים שונים של פונקציות, הן לא משתפות משתנים או זיכרון מקומי. מידע נוסף זמין במאמרים בנושא Statelessness וFunction instance lifespan.
הפעלות במצב התחלתי (cold start)
מופע חדש של פונקציה מופעל בשני מקרים:
כשפורסים את הפונקציה.
כשנוצר באופן אוטומטי מופע חדש של פונקציה כדי להגדיל את הקיבולת בהתאם לעומס, או מדי פעם כדי להחליף מופע קיים.
כדי להפעיל מופע חדש של פונקציה, צריך לטעון את זמן הריצה ואת הקוד. בקשות שכוללות הפעלה של מופע פונקציה, שנקראות הפעלות קרות, עשויות להיות איטיות יותר מבקשות שמופנות למופעי פונקציה קיימים. עם זאת, אם הפונקציה מקבלת עומס קבוע, בדרך כלל מספר ההפעלות הקרות זניח, אלא אם הפונקציה קורסת לעיתים קרובות וצריך להפעיל מחדש את סביבת הפונקציה.
אם קוד הפונקציה יוצר חריגה שלא נתפסה או גורם לקריסה של התהליך הנוכחי, יכול להיות שמופע הפונקציה יופעל מחדש. זה עלול להוביל ליותר הפעלות קרות, וכתוצאה מכך לזמן אחזור ארוך יותר. לכן מומלץ לטפל בחריגים ולמנוע סיום של התהליך הנוכחי.
אם הפונקציה רגישה לזמן האחזור, כדאי להגדיר מספר מינימלי של מופעים כדי למנוע הפעלות במצב התחלתי (cold start).
משך החיים של מופע פונקציה
בדרך כלל, מופעים של פונקציות הם עמידים ונעשה בהם שימוש חוזר בהפעלות הבאות של הפונקציה, אלא אם מספר המופעים מצטמצם בגלל חוסר תנועה מתמשכת או שהפונקציה קורסת. כלומר, כשביצוע של פונקציה מסוימת מסתיים, אפשר לטפל בהפעלת פונקציה אחרת באמצעות אותו מופע של הפונקציה.
היקף הפונקציה לעומת היקף גלובלי
הפעלה אחת של פונקציה גורמת להרצה רק של גוף הפונקציה שהוגדרה כנקודת הכניסה. ההיקף הגלובלי של קוד המקור של הפונקציה מופעל רק בהפעלות קרות, ולא במופעים שכבר אותחלו.
Node.js
Python
המשך
Java
Ruby
אפשר להשתמש במשתנים גלובליים כדי לשפר את הביצועים, אבל אסור להסתמך על מצב שהוגדר בהיקף הגלובלי על ידי הפעלות קודמות של פונקציות. מידע נוסף זמין במאמר בנושא חוסר מצב.
אפשר להניח שלכל מופע של פונקציה, ההיקף הגלובלי בוצע בדיוק פעם אחת לפני הפעלת קוד הפונקציה. עם זאת, אסור להסתמך על המספר הכולל של ההפעלות בהיקף גלובלי או על התזמון שלהן, כי הם עשויים להשתנות בהתאם לפעילות של התאמה אוטומטית לעומס.
ציר הזמן של הפעלת הפונקציה
לפונקציה יש גישה למשאבים שהוקצו לה (זיכרון ומעבד) רק למשך הביצוע של הפונקציה. אין ערובה לכך שקוד שיופעל מחוץ לתקופת ההרצה יפעל, ותמיד אפשר להפסיק אותו. לכן, תמיד צריך לציין את סיום ההפעלה של הפונקציה בצורה נכונה, ולהימנע מהרצת קוד כלשהו מעבר לכך. מידע נוסף זמין במאמרים בנושא פונקציות HTTP, פונקציות ברקע ופונקציות CloudEvent.
הזמן שהוקצב להרצת הפונקציה תלוי גם במשך הזמן הקצוב לתפוגה של הפונקציה. מידע נוסף זמין במאמר בנושא הזמן הקצוב לתפוגה של פונקציות.
חשוב לקחת בחשבון את ציר הזמן של ההפעלה כשמפעילים את האפליקציה. אין ליצור משימות ברקע בהיקף גלובלי במהלך האתחול, כי הן יופעלו מחוץ למשך הזמן של הבקשה.
התחייבויות לביצוע
בדרך כלל, הפונקציות מופעלות פעם אחת לכל אירוע נכנס. עם זאת, פונקציות Cloud Run לא מבטיחות הפעלה יחידה בכל המקרים בגלל הבדלים בתרחישי שגיאות.
המספר המקסימלי או המינימלי של הפעמים שבהן אפשר להפעיל את הפונקציה עבור אירוע יחיד תלוי בסוג הפונקציה:
הפונקציות של HTTP מופעלות פעם אחת לכל היותר. הסיבה לכך היא האופי הסינכרוני של קריאות HTTP, והמשמעות היא שכל שגיאה שמתרחשת במהלך הפעלת הפונקציה תוחזר ללא ניסיון חוזר. המתקשר של פונקציית HTTP אמור לטפל בשגיאות ולנסות שוב אם צריך.
פונקציות מבוססות-אירועים מופעלות לפחות פעם אחת. הסיבה לכך היא האופי האסינכרוני של האירועים, שבו אין מתקשר שמחכה לתשובה. במקרים נדירים, המערכת עשויה להפעיל פונקציה מבוססת-אירועים יותר מפעם אחת כדי לוודא שהאירוע יועבר. אם הפעלת פונקציה מבוססת-אירועים נכשלת עם שגיאה, הפונקציה לא תופעל שוב אלא אם האפשרות retries on failure (ניסיונות חוזרים במקרה של כשל) מופעלת עבור הפונקציה הזו.
כדי לוודא שהפונקציה מתנהגת בצורה נכונה בניסיונות חוזרים להפעלה, צריך להפוך אותה לאידמפוטנטית. לשם כך, מטמיעים אותה כך שהתוצאות הרצויות (ותופעות הלוואי) יתקבלו גם אם אירוע מסוים מועבר כמה פעמים. במקרה של פונקציות HTTP, המשמעות היא גם החזרת הערך הרצוי גם אם המתקשר מנסה שוב לבצע קריאות לנקודת הקצה של פונקציית ה-HTTP. מידע נוסף על הפיכת הפונקציה לאידמפוטנטית זמין במאמר בנושא ניסיון חוזר של פונקציות מבוססות-אירועים.
זיכרון ומערכת קבצים
לכל פונקציה מוקצה נפח זיכרון מסוים לשימוש. אפשר להגדיר את כמות הזיכרון בזמן הפריסה. מידע נוסף מופיע במאמר בנושא הגדרת זיכרון.
סביבת ההפעלה של הפונקציה כוללת מערכת קבצים בזיכרון שמכילה את קובצי המקור והספריות שנפרסו עם הפונקציה (ראו מבנה קוד המקור). הספרייה שמכילה את קובצי המקור היא לקריאה בלבד, אבל שאר מערכת הקבצים היא לכתיבה (חוץ מקבצים שנמצאים בשימוש מערכת ההפעלה). השימוש במערכת הקבצים נכלל בשימוש בזיכרון של הפונקציה.
הפונקציה יכולה לקיים אינטראקציה עם מערכת הקבצים באמצעות שיטות סטנדרטיות בכל שפת תכנות.
רשת
הפונקציה יכולה לגשת לאינטרנט הציבורי באמצעות שיטות סטנדרטיות בכל שפת תכנות, בין אם באמצעות ספריות מובנות שמוצעות על ידי זמן הריצה או ספריות של צד שלישי שאתם כוללים כיחסי תלות.
כדאי לנסות לעשות שימוש חוזר בחיבורים לרשת בין הפעלות של פונקציות. עם זאת, חשוב לזכור שחיבור שלא נעשה בו שימוש במשך 10 דקות עשוי להיסגר על ידי המערכת, וניסיונות נוספים להשתמש בחיבור סגור יגרמו לשגיאה 'איפוס חיבור'. הקוד צריך להשתמש בספרייה שמטפלת היטב בחיבורים סגורים, או לטפל בהם באופן מפורש אם משתמשים במבני רשת ברמה נמוכה.
בידוד פונקציות
כל פונקציה שפורסתם מבודדת מכל הפונקציות האחרות – גם מאלה שנפרסו מאותו קובץ מקור. בפרט, הם לא חולקים זיכרון, משתנים גלובליים, מערכות קבצים או מצב אחר.
כדי לשתף נתונים בין פונקציות שפרסתם, אתם יכולים להשתמש בשירותים כמו Memorystore, Datastore, Firestore או Cloud Storage. לחלופין, אפשר להפעיל פונקציה אחת מתוך פונקציה אחרת באמצעות הטריגרים המתאימים שלהן ולהעביר את הנתונים הנדרשים. לדוגמה, אפשר לשלוח בקשת HTTP לנקודת הקצה של פונקציית HTTP או לפרסם הודעה בנושא Pub/Sub כדי להפעיל פונקציית Pub/Sub.