במדריך הזה נסביר איך לארח יעד של webhook בשירות Knative Serving.
פונקציות Cloud Run לעומת Knative serving
פונקציות Cloud Run ו-Knative serving מספקים פתרונות טובים לאירוח של יעדי ה-webhook. בדרך כלל, ההגדרה של פונקציות Cloud Run מהירה, והן מתאימות ליצירת אב טיפוס ולתהליכי עבודה עם נפח נמוך יותר. Knative serving מספק גמישות רבה יותר ויכול לטפל בנפחים גדולים יותר עם מקביליות.
כדאי להשתמש ב-Knative serving אם:
- אתם משתמשים בשפות או בזמני ריצה שלא נתמכים בפונקציות Cloud Run
- אתם רוצים להגדיר פסק זמן ארוך יותר לבקשות (עד 15 דקות)
- אתם מצפים לנפח גדול של נתונים וצריכים תמיכה בהרצת כמה בקשות בו-זמנית (80 בקשות בו-זמנית או יותר לכל מופע של מאגר תגים)
יצירת יעד של webhook במילוי בקשות מסוג Knative
באמצעות Knative serving, אתם יכולים להגדיר יעד של webhook בכל שפה שתבחרו. צריך רק ליצור נקודת קצה (endpoint) של HTTP שיכולה לקבל את הנתונים.
בדרך כלל עושים את זה באמצעות POST, לדוגמה:
@app.route('/', methods=['POST'])
def index():
data = request.get_json()
בדוגמה שלמעלה, דף האינדקס של כתובת ה-URL מוגדר לקבל רק בקשות מסוג POST, והמערכת מצפה שהנתונים יועברו באמצעות מטען ייעודי (payload) בפורמט JSON.
שילוב עם ספק ה-webhook
ברוב השירותים שמספקים קריאות חוזרות (callback) של HTTP, נדרש אימות של הבעלות על כתובת ה-URL. בדרך כלל זה נעשה על ידי שליחת סוג מסוים של טוקן, הודעה או סוד, וציפייה לתשובה תקפה. תצטרכו לקבל את הדרישות האלה מספק השירות. בדוגמה שלמעלה, זה יכול להיראות כך:
def index():
data = request.get_json()
return data['challenge']
אחרי שהספק יאמת את הבעלות שלכם, תצטרכו להוסיף הרשאה גם בצד שלכם.
אישור בקשות
יעד של webhook הוא כתובת URL פתוחה וציבורית. רוב השירותים מספקים אסימון או סוד כדי לוודא שהבקשות הנכנסות מגיעות משירותים מורשים. מכיוון שכתובת ה-URL היא ציבורית, אי אפשר למנוע ניסיונות זדוניים לשלוח נתונים ליעד של ה-webhook. עם זאת, שימוש בטוקנים או בסודות מבטיח שרק נתונים ממקורות מורשים יעברו עיבוד.
כדי לאמת את הבקשה, אפשר להגדיר סודות, או לאחסן את העותק של הסוד כמשתנה סביבה או באמצעות מערכת לניהול מפתחות.
כשמאחסנים את העותק של הסוד כמשתנה סביבתי, לכל בקשה צריך להיות סוד או טוקן בכותרות הבקשה או במטען הייעודי (payload) של ה-JSON, ואתם צריכים לבדוק אותו כדי לוודא שהמקור תקף.
def index():
request_secret = request.headers['Secret']
if request_secret != os.environ['SECRET']:
return ('Unauthorized', 401)
אם ספק ה-webhook לא תומך בסוד או במנגנון אימות אחר, כל מי שיש לו את כתובת ה-URL של יעד ה-webhook יוכל לשלוח הודעות. במקרה כזה, ההטמעה של ה-webhook אמורה להיות בטוחה לחשיפה באינטרנט הציבורי.
מענה לבקשות
ברוב השירותים, צריך להגיב לבקשה תוך פרק זמן מוגדר, כפי שמצוין בשירות. חלק מה-webhook כוללים שיטות מובנות לניסיון חוזר אם יש תגובת שגיאה, כמו קוד סטטוס של HTTP מסוג 4xx או 5xx, ולכן צריך להחזיר קוד סטטוס של הצלחה (2xx) כדי שהשירות יידע שהאירוע עובד כמו שצריך.
def index():
data = request.get_json()
return ('', 200)
חסימות זמניות
גם למילוי בקשות מסוג Knative וגם לספק ה-webhook יש פסק זמן. התקופה הקצרה מבין השתיים תחול על הבקשה שלכם. אם עיבוד הנתונים חורג מהזמן שהוקצה על ידי Knative serving או ספק ה-webhook, תצטרכו להשתמש במוצר שמאפשר לכם להשלים את העיבוד באופן אסינכרוני, כמו Pub/Sub או Cloud Tasks. המוצרים האלה מאפשרים לכם להעביר את הנתונים במהירות, להחזיר מיד תגובת הצלחה לספק ה-webhook ולהמשיך את העיבוד בלי לדאוג לזמן הקצוב לתפוגה. האפשרויות האלה טובות גם לטיפול בכשלים ובניסיונות חוזרים.
תבניות נפוצות של תגובות לפעולות מאתרים אחרים (webhooks)
| סוג | דוגמאות |
|---|---|
| העברת נתונים | שליחת התראה באמצעות העברת הודעות בענן ב-Firebase בכל פעם שמתבצעת קריאה ל-webhook. |
| אחסון נתונים | אחסון הנתונים ב-BigQuery לניתוח מאוחר יותר. |
| הפעלת פעולות | ביצוע פעולות ב-Dialogflow, פרסום תשובות בטוויטר או העברה לסביבת הבדיקה בכל פעם שמתבצעת התחייבות לקוד חדש ב-GitHub. |
המאמרים הבאים
- מידע נוסף על ווּבּהוקים (טריגרים של HTTP) בפונקציות Cloud Run
- הגדרת התראות של ווּבּהוּקים ב-Google Cloud Observability
- שליחת הודעות Pub/Sub ל-webhook באמצעות מינויים מסוג push
- ביצוע פעולות ב-Dialogflow באמצעות Webhook