הפעלת פונקציות Cloud Run או Cloud Run

כדי להפעיל שירות של Google Cloud , כמו פונקציות Cloud Run או Cloud Run, מ-Workflows, צריך לשלוח בקשת HTTP. לשיטות הנפוצות ביותר של בקשות HTTP יש קיצור דרך לקריאה (כמו http.get ו-http.post), אבל אפשר לשלוח כל סוג של בקשת HTTP על ידי הגדרת השדה call לערך http.request וציון סוג הבקשה באמצעות השדה method. מידע נוסף מופיע במאמר שליחת בקשת HTTP.

כדי לשלוח בקשות מאומתות:

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

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

מידע נוסף זמין במאמר מתן הרשאה לתהליך עבודה כדי לגשת למשאבי Google Cloud .

מתי להתקשר לשירות

איך יודעים מתי ליצור שלבים ב-YAML או ב-JSON באמצעות התחביר של Workflows, ומתי ליצור שירות (לדוגמה, שירות Cloud Run או פונקציית Cloud Run) שיבצע את העבודה במקום זאת?

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

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

הזמן הקצוב לתפוגת הבקשה ומגבלות המטען הייעודי (payload)

כשקוראים לשירות Cloud Run או לפונקציית Cloud Run דרך HTTP, חשוב לזכור שבקשות HTTP סינכרוניות (http.get,‏ http.post,‏ http.request) ב-Workflows מוגדרות כברירת מחדל לזמן קצוב לתפוגה של 5 דקות (300 שניות), תומכות בזמן קצוב לתפוגה מקסימלי של 30 דקות (1,800 שניות) ומאפשרות גודל תגובה מקסימלי של 2MB (בכפוף למגבלת הזיכרון המשתנה של 512KB אם הן מאוחסנות במשתנים).

למרות ששירותי Cloud Run ופונקציות Cloud Run (דור שני) תומכים בזמן קצוב לתפוגה של בקשות עד 60 דקות, כל שלב סינכרוני של http.* ב-Workflows מסתיים עם TimeoutError אחרי הזמן הקצוב לתפוגה שהוגדר (עד 30 דקות). לעומסי עבודה שפועלים יותר מ-30 דקות או מחזירים עומסי נתונים גדולים, השתמשו במשימות של Cloud Run או בנקודות קצה (endpoints) של קריאה חוזרת (callback). במאמר התאמת זמני קצובות לתפוגה וגודלי מטען ייעודי (payload) בשירותים שונים תוכלו למצוא השוואה בין המגבלות והתבניות המומלצות.

להפעיל שירותים שמוגבלים ל-ingress פנימי

ב-Workflows אפשר להפעיל פונקציות Cloud Run או שירותי Cloud Run באותו פרויקט או באותו היקף שירות של VPC Service Controls, שבהם תעבורת הנתונים הנכנסת מוגבלת לתנועה פנימית. Google Cloud בהגדרה הזו, אי אפשר לגשת לשירותים מהאינטרנט, אבל אפשר לגשת אליהם מ-Workflows.

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

שימוש בחשבון שירות עם ההרשאות הנדרשות

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

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

לדוגמה, כדי להגדיר פונקציית Cloud Run מקבלת (דור ראשון) כך שתקבל בקשות מפונקציה או משירות ספציפיים ששולחים קריאה, צריך להוסיף את חשבון השירות של הפונקציה או השירות ששולחים קריאה כחשבון משתמש בפונקציה המקבלת, ולהקצות לחשבון המשתמש הזה את התפקיד "מפעיל פונקציות של Cloud Functions"‏ (roles/cloudfunctions.invoker). באופן דומה, כדי להגדיר חשבון שירות לשירותי Cloud Run או לפונקציות Cloud Run (דור שני), מקצים לחשבון השירות את התפקיד Cloud Run Invoker‏ (roles/run.invoker). מידע נוסף זמין במאמר בנושא בקרת גישה באמצעות IAM או בסקירה הכללית על אימות ב-Cloud Run.

הפעלת פונקציות Cloud Run

בפונקציות Cloud Run, הרשאות ההפעלה זמינות באמצעות ניהול שירות Cloud Run הבסיסי. אם תהליך העבודה מפעיל שירות של פונקציות Cloud Run, אתם לא צריכים להקצות לחשבון השירות של הגורם המפעיל את התפקיד מפעיל פונקציות של Cloud Functions (roles/cloudfunctions.invoker) ב-IAM. במקום זאת, צריך להקצות את תפקיד ה-IAM מפעיל Cloud Run (roles/run.invoker).

מידע נוסף זמין במאמר השוואה בין פונקציות Cloud Run.

הוספת פרטי אימות לתהליך העבודה

כששולחים בקשות לפונקציות Cloud Run או ל-Cloud Run, צריך להשתמש ב-OIDC לאימות.

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

YAML

  - step_A:
      call: http.get
      args:
          url: https://us-central1-project.cloudfunctions.net/functionA
          query:
              firstNumber: 4
              secondNumber: 6
              operation: sum
          auth:
              type: OIDC
              audience: OIDC_AUDIENCE

JSON

    [
      {
        "step_A": {
          "call": "http.get",
          "args": {
            "url": "https://us-central1-project.cloudfunctions.net/functionA",
            "query": {
              "firstNumber": 4,
              "secondNumber": 6,
              "operation": "sum"
            },
            "auth": {
              "type": "OIDC",
              "audience": "OIDC_AUDIENCE"
            }
          }
        }
      }
    ]
הפרמטר האופציונלי audience מציין את קהל היעד של OIDC (OIDC_AUDIENCE) בשביל האסימון. כברירת מחדל, הוא מוגדר לאותו ערך כמו url. עם זאת, אם url כולל קטעי נתיב נוספים מעבר לכתובת ה-URL הבסיסית של השירות או הפונקציה, צריך להגדיר את audience לכתובת ה-URL הבסיסית (לדוגמה, https://us-central1-project.cloudfunctions.net/functionA).

מציינים את סוג המדיה של נתוני התגובה

אם הכותרת Content-Type של התגובה מציינת סוג מדיה application/json, תגובת ה-JSON שמאוחסנת במשתנה מומרת באופן אוטומטי למפה שאפשר לגשת אליה.

אם צריך, משנים את ה-API שאליו מתבצעת הקריאה כדי לציין סוג מדיה application/json לכותרת התגובה Content-Type. אחרת, אתם יכולים להשתמש בפונקציות json.decode ו-text.encode כדי להמיר את גוף התגובה למפה. לדוגמה:

json.decode(text.encode(RESPONSE_FROM_API))

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

הפעלת משימות ב-Cloud Run

בניגוד לשירותי Cloud Run, משימות Cloud Run לא מאזינות לבקשות HTTP או משרתות אותן. כדי להריץ משימות של Cloud Run מתהליך עבודה, משתמשים במחבר של Cloud Run Admin API. אם העבודה נמשכת יותר מ-30 דקות, צריך להגדיר גם את זמן הקצוב לתפוגה של המשימה (10 דקות כברירת מחדל, וניתן להגדיר עד 168 שעות או 7 ימים) וגם את connector_params.timeout בקריאה למחבר (שמוגדרת כברירת מחדל ל-1,800 שניות וניתן להגדיר עד 31,536,000 שניות או שנה אחת).

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

במאמר הפעלת משימה ב-Cloud Run שמעבדת נתוני אירועים ב-Cloud Storage מופיעה דוגמה מקצה לקצה להפעלת משימה ב-Cloud Run שמעבדת נתונים שמאוחסנים בקטגוריה של Cloud Storage, ומאפשרת להצפין את הנתונים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK).

המאמרים הבאים