ה-webhook של GitHub לא מגיע ל-Jenkins פרטי: תקנו את הנתיב

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

הפעלת דפדפן מוכיחה כיוון אחד בלבד

חיבור VPN עונה על שאלה אחת: האם המחשב הנייד הזה יכול להגיע למארח הפנימי. מסירת webhook שואלת שאלה אחרת: האם שירות חיצוני יכול לפתוח חיבור אל אותו מארח. משיכת מאגר על ידי Jenkins היא תעבורה יוצאת ואינה אומרת דבר על נגישות נכנסת. שמרו את שני הכיוונים על קווים נפרדים בתרשים שלכם, כולל איזה צד יוזם כל אחד מהם.

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

אפשרות א׳: לחשוף נקודת קצה צרה

אם הארגון כבר מפרסם נקודת כניסה מאושרת, חשפו את נתיב ה-webhook במקום את לוח הבקרה. בדרך כלל משמעות הדבר היא כלל פרוקסי הפוך שמקבל POST בכתובת ה-URL של ההוק ומעביר אותם ל-Jenkins, בעוד ממשק הניהול נשאר בלתי נגיש מבחוץ.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

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

אפשרות ב׳: להפוך את הכיוון עם ממסר

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

ssh -N -R 9000:localhost:8080 relay.example.net

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

אפשרות ג׳: לסקור את המאגר במקום

סקירה מחליפה השהיה בפשטות ואינה זקוקה לנתיב נכנס כלל. Jenkins יכול לסקור לפי לוח זמנים, או משימה קטנה יכולה לשאול את ה-API ולהתחיל בנייה כשהיא רואה גרסה לא מוכרת.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

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

קבלו מסירה אמיתית, לא טעינת דף

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

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