במאמר הבא אסביר כיצד ניתן לנהל בסביבת GCP פעולות שונות לניטור ואוטומציה של תשתית המחשוב. חלק מפעולות הניטור והאוטומציה, מתנהל באמצעות סקריפטים ומשימות שמריצות את הסקריפטים האלה בתזמון קבוע.
תקציר:
הרצת אותן משימות בסביבת הענן מתבצעת באמצעות Job מתוזמנים שמריצים קונטיינרים בשירות Cloud Run. הקונטיינרים מכילים כבר את כל הסקריפטים.
Job מוגדר כך שבהפעלה שלו, הוא קורא ל-PowerShell. כ-Argument הוא מכניס ל-Powershell את השם והנתיב של הסקריפט שרוצים להריץ באותו Job.
הסקריפט מבצע את הפעולה שלו, ולבסוף כשיש לו תוצאות, הוא פונה לביצוע הליך שליחת מייל.
הליך שליחת המייל פונה ל-Secret-Manager כדי לקבל Secret של אפליקציה ב-AzureAD. עם ה-Secret מתבצעת פניה מול Microsoft Graph API כדי לקבל Token. את ה-Token מכניסים לפורמט של Modern Authentication כדי לאמת זהות מול Exchange Online. אז מתבצעת פניה נוספת ל-Microsoft Graph API שמפעילה את המתודה של שליחת מייל.
תרשים הפעולות:
תיאור כללי של הרכיבים:
Secure Source Manager:
שירות GIT של GCP בו מאחסנים את כל הסקריפטים והקבצים הנדרשים להרצת המשימות. כמו כל GIT Repository, ניתן לנהל גרסאות ולקבוע הרשאות גישה ל-Repository. בגלל שזה בענן של גוגל, ההרשאות מתנהלות באמצעות Cloud Identity.
יוצרים Instance של השירות, ואז מתחברים ופותחים Repository. שם יושבים כל הקבצים שבאמצעותם מתנהלות משימות הניטור, הדיווח והאוטומציה הקשורות לניהול סביבת הענן.
ב-Repository מוגדר Webhook שמפעיל Build ב-Cloud Build בכל פעם שיש push ל-repository.
Cloud Build:
ב-Cloud Build מוגדר Trigger שמפעיל סדר פעולות של Build ובונה קונטיינר בכל פעם שמופעל ה-Webhook ב-Repository.
ה-Trigger מעתיק את תוכך ה-Repository. אז באמצעות אותו Dockerfile שיש שם, ה-Build בונה Container Image. הקונטיינר יודע להפעיל Powershell, Google CLI SDK, ומכיל תיקיה עם עותק עדכני של ה-Repository.
הקונטיינר שנוצר עולה ל-Artifact Registry.
Artifact Registry:
שירות אחסון ה-Image של GCP. לשם מעלים את ה-Image שמהם מריצים את הקונטיינרים. ה-Image שממנו מפעילים את הקונטיינרים של המשימות זהו Image שמכיל PowerShell וגם Cloud SDK (gcloud, gsutil, bq), נוכל לקרוא לו gcloud-pwsh. תמיד כדאי להריץ את הגרסה האחרונה שלו, היא אמורה להכיל את כל הקבצים הכי מעודכנים מה-Repository.
Cloud Run Jobs:
Cloud Run הוא שירות של GCP שמריץ קונטיינרים ללא הצורך לדאוג לתשתית שמפעילה אותם. Job יפעיל משימה באמצעות קונטיינר, ובסיומה הקונטיינר יכבה וימחק.
עבור כל דוח שנרצה להפיק וכל משימת אוטומציה שנרצה לבצע, צריך ליצור Job. אם ה-Job הוא משימה מתוזמנת שצריכה לרוץ במחזוריות מסוימת, צריך ליצור Trigger שיפעיל אותו במועדים הנדרשים.
בעת יצירת Job צריך להגדיר לו לרוץ באמצעות חשבון השירות שנוצר עבור משימה זו. לאותו חשבון יש הרשאות Viewer ברמת כלל הארגון וכל הפרויקטים.
– אם ישנה משימת אוטומציה שדורשת הרשאות לביצוע פעולות ושינויים, היא תרוץ באמצעות חשבון שירות יחודי עבור אותה משימה. חשבון שיקבל בדיוק את ההרשאות הנדרשות לאותה המשימה.
ריצת התכנית:
עם הפעלת ה-Job – בהפעלה יזומה או על פי תזמון, עולה קונטיינר ומריץ את הקוד שמעבד את הנתונים ואוסף את המידע הנדרש.
במקרים מסוימים הסקריפטים יבצעו פעולות של ישור קו. למשל – לוודא שבכל הפרוייקטים ישנה הגדרה מסויימת, או שכל הרשתות מחוברות לאיזה שירות DNS שהגדרנו.
במקרים של ניטור, נרצה להוציא פלט כלשהו, ששולחים במייל לנמענים. במקרה כזה נצטרך ליצור תבנית מייל שתוכל לכלול את הפלט ולהשלח לנמענים שנגדיר.
כאמור, כל סקריפט שכותבים ומתכוונים להעלות ל-Repository על מנת שיעבוד בתצורה הזו, צריך לייצא את הפלט והצרופות כפי שצוין לעיל. אז מכניסים קריאה לסקריפט ששולח את המייל.
שליחת המייל מתבצעת באמצעות הרכיבים הבאים במערך.
Enterprize App:
שירות בתוך Entra ID (AzureAD) שמאפשר התממשקות בין Entra ID ובין שירותים ואפליקציות אחרים. כך ניתן להתחבר לאותם שירותים או להשתמש בהם, באמצעות מערכות ההזדהות והסינון של Entra ID.
שם צריך ליצור אפליקציה מותאמת עבור פעולה זו. נקרא לה GCP-Monitor . בשירות App Registration (גם הוא בתוך Entra ID) ניתן לערוך תצורות עבודה ופרטים של אפליקציות. שם נוצר Secret המאפשר הזדהות חיצונית דרך קוד מול האפליקציה.
יש לחדש את ה-Secret כל חצי שנה.
לאפליקציה ניתנה הרשאה לביצוע המתודה Send.Mail ב-API של Microsoft Graph.
Exchange Online:
שירות הדואר בענן של מיקרוסופט (SAAS).
בסביבת מיקרוסופט – כמו EntraID או סביבה היברידית שמסתנכרנת ל-EntraID, ניצור חשבון שירות ונקרא לו GCP-Monitor-Mail. עבורו ניצור תיבת דואר ב-Exchange Online. דרך תיבה זו תתבצע שליחת המיילים של כל התהליכים המתנהלים דרך Cloud Run Jobs. אז נגדיר לו אפשרויות שליחת מייל דרך Microsoft Graph. חלק מההגדרות צריך לבצע דרך Exchange Shell – שורת הפקודה של Microsoft Exchange.
נקבע Policy שמגביל את שליחת המיילים של האפליקציה, רק באמצעות חברי הקבוצה שנפתח למטרה זו. החבר היחיד בקבוצה הוא חשבון השירות שבאמצעותו נשלח את המיילים – GCP-Monitor-Mail.
Secret Manager:
שירות של GCP לניהול סיסמאות ומידע רגיש שאמור להיות מוצפן. מידע כזה לא שמים ישירות בקוד. בצורה זו, מי שעורך את הקוד או מריץ אותו, אין לו גישה לסיסמאות.
לחשבון השירות GCP-Monitor-Mail שמריץ את ה-Job, יש גישה ל-Secret ספציפי. זה מכיל App Secret של האפליקציה GCP-Monitor. באמצעות אותו Secret ניתן לשלוח את המייל.
כל חצי שנה יש לחדש את ה-Secret ב-Entra ID ואז לעדכן את ה-Secret ב-Secret Manager.
– גם את הליך חידוש ה-Secret ניתן להגדיר באמצעות אוטומציה, או לכל הפחות התרעה שמכריזה על תפוגת ה-Secret מבעוד מועד.
הליך שליחת המייל:
1. התהליך אוסף את ה-Secret של האפליקציה GCP-Monitor מתוך Secret Manager. אז באמצעות ה-Secret פונה ל-API של Microsoft Graph ומקבל Token.
2. התהליך אוסף את פרטי הנמענים והצרופות בתוך הקונטיינר שמריץ את התהליך.
3. התהליך אוסף את תצורת ההודעה של המייל מתוך הקובץ mail-body שנוצר באותו מקום.
4. התהליך אוסף את תבנית ה-JSON לשליחת מייל מתוך הקובץ msg-template.txt. קובץ זה יושב יחד עם כל שאר קבצי הקוד שנכנסו לקונטיינר מה-Repository.
5. התהליך בונה JSON חדש על בסיס התבנית ובחישוב הנמענים והצרופות (אם ישנן), לשם מתווספת הפניה לתצורת ההודעה עצמה של המייל, כפי שנאספה מתוך הקובץ mail-body.
6. התהליך מבצע פניה ל-API של Microsoft Graph, ושם מפעיל את המתודה Send.Mail כדי לשלוח את המייל. ההזדהות והאימות הם באמצעות ה-Token שנאסף בשלב מס'1. כאשר תצורת המייל ופרטיו כלולים ב-JSON שנוצר עם התהליך.