קריאה או הפעלה של שירות כמו פונקציות Cloud Run או Cloud Run מ-Workflows מתבצעת באמצעות בקשת HTTP. Google Cloud לשיטות הנפוצות ביותר של בקשות HTTP יש קיצור דרך לקריאה (למשל http.get ו-http.post), אבל אפשר לשלוח כל סוג של בקשת HTTP על ידי הגדרת השדה call לערך http.request וציון סוג הבקשה באמצעות השדה method. מידע נוסף זמין במאמר בנושא שליחת בקשת HTTP.
כדי לשלוח בקשות מאומתות:
תהליך העבודה צריך להיות משויך לחשבון שירות שקיבל תפקיד אחד או יותר של ניהול זהויות והרשאות גישה (IAM) שכוללים את ההרשאות הנדרשות.
צריך להוסיף באופן מפורש פרטי אימות להגדרת תהליך העבודה. כברירת מחדל, בקשות HTTP לא מכילות אסימוני זהות או אסימוני גישה מטעמי אבטחה.
מידע נוסף זמין במאמר בנושא הענקת הרשאה לזרימת עבודה לגשת למשאבים ב- Google Cloud .
מתי כדאי להתקשר לשירות
איך יודעים מתי כדאי ליצור שלבים ב-YAML או ב-JSON באמצעות תחביר Workflows, ומתי כדאי ליצור שירות – לדוגמה, שירות Cloud Run או פונקציית Cloud Run – כדי לבצע את העבודה במקום זאת?
ליצור שירותים לביצוע עבודות מורכבות מדי בשביל Workflows, למשל הטמעה של לוגיקה עסקית לשימוש חוזר, חישובים מורכבים או טרנספורמציות שלא נתמכות בביטויים של Workflows ובספרייה הרגילה שלו. בדרך כלל קל יותר להטמיע תרחיש מורכב בקוד, במקום להשתמש ב-YAML או ב-JSON ובתחביר של Workflows.
הפעלת שירותים שמוגבלים לכניסה פנימית
תהליכי עבודה יכולים להפעיל פונקציות Cloud Run או שירותי Cloud Run באותו פרויקט שבו הכניסה מוגבלת לתנועה פנימית. Google Cloud במקרה כזה, אי אפשר לגשת לשירותים שלכם מהאינטרנט, אבל אפשר לגשת אליהם מתהליכי עבודה.
כדי להחיל את ההגבלות האלה, צריך לשנות את הגדרות הכניסה של השירות או הפונקציה. שימו לב שאפשר להגיע לשירות Cloud Run בכתובת ה-URL שלו ולא בדומיין מותאם אישית.run.app מידע נוסף זמין במאמרים הגבלת תעבורת נכנסת ברשת (ל-Cloud Run) והגדרת הגדרות רשת (לפונקציות של Cloud Run). לא צריך לבצע שינויים אחרים בתהליך העבודה.
שימוש בחשבון שירות עם ההרשאות הנדרשות
כששולחים בקשות לשירותים אחרים של Google Cloud , צריך לשייך את תהליך העבודה לחשבון שירות שיש לו את ההרשאות הנכונות לגשת למשאבים המבוקשים. כדי לדעת איזה חשבון שירות משויך לזרימת עבודה קיימת, אפשר לעיין במאמר אימות חשבון השירות שמשויך לזרימת עבודה.
כשמגדירים חשבון שירות, משייכים את הזהות המבקשת למשאב שרוצים לתת לה גישה אליו – הופכים את הזהות המבקשת לגורם ראשי של המשאב – ואז מקצים לה את התפקיד המתאים. התפקיד מגדיר אילו הרשאות יש לזהות בהקשר של המשאב.
לדוגמה, כדי להגדיר פונקציית Cloud Run שמקבלת בקשות מפונקציה או משירות ספציפיים שמפעילים אותה, צריך להוסיף את חשבון השירות של הפונקציה או השירות שמפעילים אותה כגורם ראשי בפונקציה שמקבלת את הבקשות, ולהקצות לגורם הראשי הזה את התפקיד Cloud Run functions Invoker (הפעלת פונקציות Cloud Run) (roles/cloudfunctions.invoker). באופן דומה, כדי להגדיר חשבון שירות בשביל Cloud Run, צריך להקצות לחשבון השירות הזה את התפקיד Cloud Run Invoker (roles/run.invoker). מידע נוסף זמין במאמר בנושא בקרת גישה באמצעות IAM או בסקירה הכללית על אימות ב-Cloud Run.
הפעלת פונקציות Cloud Run
בפונקציות Cloud Run, הרשאות ההפעלה זמינות באמצעות ניהול שירות Cloud Run הבסיסי. אם תהליך העבודה שלכם מפעיל שירות של פונקציות Cloud Run, אתם לא צריכים להקצות לחשבון השירות של המתקשר את התפקיד Cloud Functions Invoker (roles/cloudfunctions.invoker). במקום זאת, צריך להקצות את התפקיד Cloud Run Invoker (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 של האסימון.
כברירת מחדל, הערך שמוגדר הוא אותו ערך כמו url, אבל צריך להגדיר אותו לכתובת ה-URL הבסיסית של השירות. לדוגמה: https://region-project.cloudfunctions.net/hello_world.
מציינים את סוג המדיה של נתוני התגובות
אם הכותרת 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.
דוגמה מקצה לקצה להרצת משימת Cloud Run שמעבדת נתונים שמועברים למשימה כמשתני סביבה מופיעה במאמר הרצת משימת Cloud Run באמצעות Workflows.
דוגמה מקצה לקצה להרצת משימת Cloud Run לעיבוד נתונים שמאוחסנים בקטגוריה של Cloud Storage, שמאפשרת להצפין את הנתונים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK), מופיעה במאמר הרצת משימת Cloud Run לעיבוד נתוני אירועים ב-Cloud Storage.