פריסת עומס עבודה של Confidential Space עם קבוצות של מכונות מופעלות (MIG) באמצעות התאמה אוטומטית לעומס (autoscaling), תיקון אוטומטי (autohealing) ועדכוני תמונות

1. סקירה כללית

‫Confidential Space (CS)‎ מספקת סביבה מאובטחת, מאומתת ומוצפנת לעיבוד מידע אישי רגיש. הסתמכות על מופעים עצמאיים של מכונות וירטואליות יוצרת תקורה תפעולית, כי לתזמור ידני חסרה יכולת המדרגיות הנדרשת לשירותים קריטיים. בלי תזמור אוטומטי, ביצוע עדכונים בהדרגה מסונכרנים או פריסת קובצי אימג' חדשים של מערכת ההפעלה ב-Fleet הופכים למשימה קשה מבחינה טכנית ומועדים לזמן השבתה.

ב-Codelab הזה תלמדו איך לפרוס עומס עבודה של Confidential Space בקבוצת מופעי מכונה מנוהלים (MIG). תלמדו גם איך להפעיל תיקון תוכנה אוטומטי (autohealing) באמצעות בדיקות תקינות, התאמה אוטומטית לעומס (automatic scaling) על סמך ניצול המעבד (CPU) ועדכון בהדרגה (rolling) של קובץ אימג' של מערכת ההפעלה ועומסי עבודה (workload).

התהליכים שמוצגים בשיעור Codelab הזה יעזרו לכם להגדיר Confidential Space משלכם שמוכן לייצור ומאובטח לפריסות ארוכות טווח שחיוניות לפעילות העסקית.

מה תלמדו

איך יוצרים תבנית של הגדרות מכונה מיוחדת עבור Confidential Space.
איך משתמשים ב-Google Compute Engine ואיך מגדירים קבוצות של מופעי מכונה מנוהלים (MIG) וקבוצות של מופעים
איך יוצרים כלל חומת אש ובדיקת תקינות לתיקון אוטומטי.
איך מגדירים קבוצת MIG אזורית באמצעות התבנית ובדיקת התקינות.
איך מגדירים התאמה אוטומטית לעומס של קבוצת ה-MIG.
איך מגדירים עדכונים של תמונות מערכת הפעלה בלחיצה אחת באמצעות סקריפטים ב-MIG, גם לתמונות של עומסי עבודה וגם לגרסאות חדשות של תמונות מערכת הפעלה ל-Confidential Space

מה תצטרכו

פרויקט ב-Google Cloud שהחיוב בו מופעל.
היכרות עם עורכי טקסט, פריסות של Docker וסקריפטים של Bash
כלי שורת הפקודה של Google Cloud מותקן ומאומת.
הבנה בסיסית של Compute Engine, ‏ Confidential Space, ‏ IAM, ‏ Confidential VMs, טכנולוגיית קונטיינרים, מאגרי מידע מרוחקים, חשבונות שירות, Cloud Run ו-Cloud Scheduler
קובץ אימג' של קונטיינר של עומס עבודה ב-Confidential Space שכבר נוצר והועבר ל-Artifact Registry.

2. איך פועל Confidential Space עם קבוצות של מכונות מנוהלות

שימוש בקבוצת מופעי מכונה מנוהלים (MIG) לפריסת עומס עבודה של Confidential Space הופך אפליקציה מאובטחת לחזקה יותר, בעלת יכולת מדרגיות וקלה יותר לתפעול.

הצרכים התפעוליים והאבטחתיים של שירות הפקה מחולקים באופן לוגי בין שני הרכיבים. ‫Confidential Space מספק את האבטחה הנדרשת על ידי הפעלת עומס העבודה בסביבה מבודדת מאוד, מוצפנת ומאומתת שנקראת סביבת מחשוב אמינה (TEE). לעומת זאת, קבוצות MIG מספקות את היכולות התפעוליות החיוניות שנדרשות להפעלת האפליקציה המאובטחת בהיקף גדול, בדומה ל-Kubernetes. קבוצות MIG מבטלות את הסיכונים שקיימים בהפעלת עומס עבודה קריטי לעסק במכונה וירטואלית אחת, שעלולה להיות איטית או רגישה לכשלים. השילוב הזה מבטיח הגנה על הנתונים ומהימנות של המערכת. הפתרון הזה מבטיח זמינות גבוהה ותיקון אוטומטי כי עומס העבודה פועל על פני כמה מכונות וירטואליות במאגר. אם מכונה וירטואלית אחת קורסת, השירות ממשיך לפעול באופן מלא בזכות איזון העומסים והנוכחות של המופעים שנותרו.

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

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

בנוסף, קבוצות MIG מאפשרות לבצע עדכונים ללא השבתה באמצעות עדכונים מדורגים. יתרון מרכזי הוא האפשרות לבצע שדרוג בלחיצה אחת של תמונת מערכת ההפעלה הבסיסית של Confidential Space או של קובץ אימג' של קונטיינר של האפליקציה (או שתיהן), בלי לגרום לזמן השבתה של השירות. קבוצת ה-MIG מנהלת את השינוי הזה על ידי החלפה הדרגתית של המופעים הישנים במופעים חדשים יותר שמופעלת בהם התמונה המעודכנת, וכך מבטיחה זמינות קבועה לאורך הפריסה. שימו לב: יכול להיות שהאפליקציה שלכם תצטרך להיות תואמת לאחור כדי לתמוך בשדרוג הדרגתי מסוג כזה.

3. הגדרת משאבים בענן

לפני שמתחילים

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

export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>

מפעילים את Confidential Computing API ואת ממשקי ה-API הבאים בפרויקט.

gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com

ב-Cloud Shell של פרויקט Google Cloud, משכפלים את מאגר GitHub של Codelab בנושא Confidential Space ומשתמשים בפקודה שלמטה כדי לקבל את הסקריפטים המתאימים שנדרשים להשלמת ה-Codelab הזה.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

עוברים לספריית הסקריפטים של קבוצת המכונות של ה-codelab

cd confidential-space/codelabs/mig_cs_codelab/scripts

מעדכנים את השורה של מזהה הפרויקט בקובץ config_env.sh כך שתשקף את מזהה הפרויקט שבחרתם.
מגדירים משתנים קיימים. החלפת שמות המשאבים באמצעות המשתנים האלה

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

מריצים את הסקריפט config_env.sh כדי להגדיר את שמות המשתנים שנותרו בפרויקט הזה לערכים שמבוססים על מזהה הפרויקט של שמות המשאבים

source config_env.sh

מוסיפים הרשאות לפרויקט. אפשר להוסיף הרשאות לפי הפרטים שמופיעים בדף האינטרנט בנושא מתן תפקיד IAM.

צריך את ההרשאות הבאות בפרויקט הזה

כותב של Artifact Registry
אדמין Cloud Scheduler
סוכן שירות של Compute
משתמש בעומס עבודה של Confidential Computing
בעל הרשאת כתיבה של יומנים
Cloud Run Developer
Cloud Run Invoker

gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'

בדיקה של test_workload.py

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

4. הגדרת עומס העבודה

קודם צריך ליצור קובץ אימג' של Docker בשביל עומס העבודה שמשמש ב-Codelab הזה. עומס העבודה הוא סקריפט פשוט שמדפיס את הגרסה של עומס העבודה שמופעלת כרגע. הוא ידפיס שעומס העבודה מתחיל, ואז ידפיס את הגרסה של עומס העבודה, ישהה למשך 5 שניות ואז ידפיס שעומס העבודה הסתיים.

השלבים ליצירת עומס עבודה

מריצים את create_workload.sh כדי ליצור את עומס העבודה. הסקריפט הזה:

יצירה של Artifact Registry בבעלות הפרויקט שבו יפורסם עומס העבודה
יוצר את הקוד ואורז אותו בקובץ אימג' של Docker. מידע נוסף מופיע בהגדרות של קובץ ה-Docker המשויך כאן.
מפרסם את קובץ אימג' של Docker ב-Artifact Registry שבבעלות הפרויקט
מעניק לחשבון השירות <your service account name> הרשאות קריאה למאגר Artifact Registry ‏ <artifact registry repo name>

5. הגדרת תבנית מכונה ו-MIG

שלבים ליצירת תבנית של מכונה וירטואלית

קודם צריך ליצור תבנית מכונה. התבנית הזו היא תוכנית האב הנדרשת שקבוצת מופעי מכונה מנוהלים (MIG) תשתמש בה כדי להקצות ולהפעיל את עומסי העבודה שלכם ב-Confidential Space.

תבנית המכונה חיונית כי היא מגדירה את כל הפרמטרים המיוחדים:

סוג המכונה: בדוגמה הזו אנחנו משתמשים בסוג מכונה של Confidential VM (למשל, n2d-standard-2) שתומך בטכנולוגיית Confidential Computing של AMD SEV ‏ (--confidential-compute-type=SEV).
קובץ אימג' של מערכת ההפעלה של המכונה הווירטואלית: אנחנו משתמשים בפרויקט confidential-space-images ובמשפחת התמונות confidential-space-debug כדי לשלוף את קובץ האימג' העדכני של מערכת ההפעלה של Confidential Space.
הערה: במדריך הזה אנחנו משתמשים בתמונה debug כדי להקל על פתרון בעיות. בניגוד לתמונת הייצור, גרסת הניפוי באגים משאירה את המכונה הווירטואלית פועלת אחרי שהעומס מסתיים, ומאפשרת גישה ל-SSH לצורך בדיקה. כדי להשתמש בפריסות לייצור באמצעות נתונים רגישים מהעולם האמיתי, צריך לעבור למשפחת תמונות הייצור.
הפניה לעומס העבודה: השורה הנדרשתtee-image-reference במטא-נתונים מכילה את קובץ האימג' של הקונטיינר הספציפי (עומס העבודה של האפליקציה) שהמכונה הווירטואלית של Confidential Space תפעיל.

ההגדרה הזו מבטיחה שכל מכונת VM שנוצרת על ידי קבוצת ה-MIG היא Confidential Space שהוגדרה כראוי ומוכנה להרצת עומס העבודה.

שלבים ליצירת קבוצת מופעי מכונה מנוהלים

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

הסקריפט create_launch_mig.sh משיג שלוש מטרות עיקריות:

1. יצירת קבוצת ה-MIG

פקודה: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
מטרה: הפקודה הזו יוצרת את הקבוצה שתנהל את המכונות הווירטואליות.
‫--size 3: מציין שקבוצת ה-MIG צריכה ליצור ולתחזק בהתחלה 3 מופעים של עומס העבודה.
‫--template ${TEMPLATE_NAME}: חשוב לשים לב שהתבנית מפנה לתבנית המופע שנוצרה קודם, כדי להבטיח שכל 3 המופעים יוגדרו כמכונות וירטואליות של Confidential Space שמריצות את קונטיינר עומס העבודה הספציפי שלכם tee-image-reference.
‫--zone ${CURRENT_PROJECT_ZONE}: ציון מיקום הפריסה של המופעים.

2. אחזור מספר הפרויקט

פקודה: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
מטרה: הסקריפט מאחזר את המזהה המספרי של הפרויקט. לרוב, המספר הזה נדרש כדי ליצור תפקידים והרשאות לחשבונות שירות, במיוחד לסוכני שירות בניהול Google.

3. מתן הרשאות IAM

פקודה: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
מטרה: בשלב הזה מוקצה התפקיד סוכן שירות של Compute Engine לחשבון השירות של עומס העבודה (${SERVICE_ACCOUNT}). ההרשאה הזו חשובה כי היא מאפשרת לחשבון השירות לפעול בשם שירות Compute Engine של הפרויקט – דבר שלעתים קרובות נדרש לתכונות האוטומטיות של קבוצת ה-MIG, כמו ניהול מופעים, הגדרת רשתות ואינטראקציה עם שירותים אחרים של Google Cloud.

מריצים את הפקודה create_launch_mig.sh כדי ליצור את הקבוצה של מופעי מכונה מנוהלים.

6. שלבים להפעלת תיקון אוטומטי והתאמה אוטומטית לעומס

הגדרה של תיקון אוטומטי

כדי להבטיח זמינות גבוהה, אנחנו מוודאים שעומס העבודה מגיב. אם האפליקציה נתקעת, קבוצת ה-MIG צריכה להחליף את מכונת ה-VM. כללי חומת אש לטווחי כתובות IP של מקור מוגדרים במסמך הזה.

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

הגדרת התאמה אוטומטית לעומס

אנחנו נגדיר את הקבוצה כך שהיא תבצע באופן אוטומטי שינוי גודל בין 1 ל-5 מופעים כדי לטפל בעליות חדות בתנועה.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. אימות עומס העבודה והגדרת עדכוני תמונות

אימות עומס עבודה

אחרי שקבוצת מופעי מכונה מנוהלים (MIG) מפעילה את המכונות הווירטואליות, צריך לוודא שעומס העבודה של Confidential Space פועל בצורה תקינה.

אפשר לעשות את זה דרך מסוף Google Cloud או שורת הפקודה.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

אפשר גם לבדוק את הפלט של היציאה הטורית של המופע הספציפי כדי לראות את היומן של עומס העבודה.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

הגדרת עדכוני תמונות

בסביבת ייצור, צריך לעדכן את קבוצת מופעי המכונה המנוהלים (MIG) באופן קבוע כדי לטפל בשני תרחישים שונים:

עדכוני עומס עבודה: פרסום גרסה חדשה של קוד האפליקציה (לדוגמה, עדכון של test_workload.py מגרסה 1 לגרסה 2).
עדכוני תשתית: Google מפרסמת תיקון אבטחה או עדכון למערכת ההפעלה הבסיסית של Confidential Space. חשוב לזכור שהשיטה המומלצת היא להשתמש בתמונת ה-CS העדכנית לפחות פעם בחודש.

מכיוון שהגדרנו את תבנית המופע עם קישור דינמי לתמונה (‎.../images/family/‎) ותג דינמי של מאגר (‎:latest‎), אנחנו יכולים לטפל בשני התרחישים האלה באמצעות פעולה אחת של החלפה מתגלגלת. כך תוכלו לוודא ש-Fleet מכונות ה-VM שלכם תמיד יפעיל את הסטאק העדכני ביותר ללא זמן השבתה, ולא תצטרכו ליצור תבנית של הגדרות מכונה חדשה לכל שינוי קל.

הסקריפט Rolling Replace

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

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

במקרה של הסקריפט הזה, אפשר להשתמש באפשרות 'החלפה' במקום באפשרות 'הפעלה מחדש'.

הפעלה מחדש היא פשוט הפעלה מחדש של המחשב. הוא שומר על דיסק מערכת ההפעלה הקיים, כלומר לא יכלול תיקוני אבטחה חדשים למערכת ההפעלה.
החלפה מוחקת את המכונה הווירטואלית ויוצרת מכונה חדשה מהתבנית. הפעולה הזו גורמת למערכת לחפש את קובץ האימג' העדכני ביותר של מערכת ההפעלה של Confidential Space מהמשפחה, וגם לשלוף את קובץ האימג' של הקונטיינר 'העדכני ביותר' מהרישום.

‫‎–max-surge=1: האפשרות הזו מאפשרת לקבוצת ה-MIG ליצור באופן זמני מכונה וירטואלית אחת נוספת מעבר לגודל היעד. הוא מפעיל מכונה וירטואלית חדשה (מעודכנת) וממתין עד שהיא תהיה תקינה לפני שהוא מוחק מכונה וירטואלית ישנה (לא מעודכנת).

‫‎–max-unavailable=0: האפשרות הזו מבטיחה אפס זמן השבתה. ההגדרה הזו מציינת לקבוצת ה-MIG שאסור להעביר מכונה למצב אופליין אלא אם היא כבר העבירה בהצלחה מכונה חלופית למצב אונליין.

סקריפט להפעלה מחדש של שרתים

בספרייה update_images יש גם סקריפט נוסף בשם update_workload_image_script.sh. הסקריפט הזה מפעיל הפעלה מחדש מדורגת, שהיא שיטה מהירה יותר שמשמשת רק לרענון עומס העבודה. מכיוון ש-Confidential Space שולף את קובץ אימג' של קונטיינר מהרישום בכל אתחול, הפעלה מחדש מספיקה כדי לעדכן את האפליקציה לגרסה :latest בלי לשנות את המארח הבסיסי.

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

אימות של עומס העבודה המעודכן

אנחנו יכולים לבדוק את השדרוג בלחיצה אחת על ידי סימול של פרסום אפליקציה בעולם האמיתי. נשנה את קוד עומס העבודה, נדחוף אותו אל Artifact Registry, נעדכן את ה-MIG ונוודא שהגרסה החדשה פועלת ללא השבתה.

שלב 1: פריסת גרסה חדשה של עומס עבודה

קודם צריך ליצור גרסה חדשה של האפליקציה.

פותחים את הקובץ המקומי test_workload.py.
משנים את הצהרת ההדפסה של הגרסה מ-print("Workload Version A")‎ ל-print("Workload Version B")‎
מריצים את create_workload.sh כדי לבנות מחדש את קובץ האימג' של הקונטיינר ולהעביר אותו בדחיפה ל-Artifact Registry. שימו לב, אנחנו מעבירים את השינויים לאותו תג (:latest).

שלב 2: הפעלת העדכון המתגלגל

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

# Run your update script
./update_images/update_images_script.sh

המתנה לסיום התסריט

שלב 3: אימות העדכון דרך היציאה הטורית

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

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

כדי לקבל את השם של מופע חדש:

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

בדיקת היומנים:

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

אחרי שהמופעים פועלים, בוחרים שם של מופע כלשהו מפקודת gcloud הקודמת כדי לראות את היציאה הטורית שלו.

פלט צפוי: אמורה להופיע הודעה מעודכנת ביומן, שמאשרת שהפריסה בוצעה בהצלחה:

‫… Workload Version B …

שלב 4: אימות הגדרת התשתית (אופציונלי)

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

מריצים את הפקודה הבאה כדי לראות את ההפניה הדינמית לקונטיינר:

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

תוצאה: קובץ אימג' של קונטיינר אמור להופיע עם הסיומת ‎ :latest.

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

(אופציונלי) עדכונים אוטומטיים

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

אנחנו יכולים לארוז את סקריפט העדכון שלנו במשימת Cloud Run כדי להפוך את התהליך 'החלפה מתגלגלת' לאוטומטי. ב-codelab הזה, נפעיל אותו כל 15 דקות. בסביבת ייצור, צריך להריץ אותו בתדירות נמוכה בהרבה. בהתאם לצרכים של המשתמש, הוא יכול להגדיר את התזמון על בסיס שבועי או חודשי.

שלב 1: יצירת קונטיינר לסקריפט של כלי העדכון

קודם כול, צריך לארוז את update_images_script.sh (שכולל את הלוגיקה של gcloud ... rolling-action replace) במאגר Docker כדי שיוכל לפעול בענן.

הכנו סקריפט עזר שיוצר את הקונטיינר הזה ומעביר אותו בדחיפה ל-Artifact Registry.

מריצים את הפקודה הבאה:

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

מה זה אומר:

הסקריפט update_images_script.sh נלקח מהספרייה update_images/.
הוא יוצר קובץ אימג' של Docker שמכיל את Google Cloud SDK ואת הסקריפט שלכם.
התמונה נדחפת אל ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

שלב 2: פריסה ותזמון של העבודה

עכשיו צריך להגדיר ב-Google Cloud להפעיל את הקונטיינר הזה מדי פעם. אנחנו משתמשים ב-Cloud Run Jobs כדי להפעיל את הקונטיינר וב-Cloud Scheduler כדי להפעיל אותו.

מריצים את סקריפט הגדרת התזמון:

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

בתוך הסקריפט: הסקריפט הזה מבצע שתי פעולות קריטיות:

יצירת משימה ב-Cloud Run: המשימה נקראת mig-updater-job והיא מריצה את הקונטיינר שדחפנו.
יצירת טריגר של Scheduler: המערכת מגדירה משימה של Cloud Scheduler כדי להפעיל את Cloud Run Job API כל 15 דקות.

# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

שלב 3: אימות האוטומציה

לא צריך לחכות 15 דקות כדי לבדוק את זה. אתם יכולים להריץ את הכלי לתזמון באופן מיידי כדי לאמת את צינור הנתונים.

הפעלת המשימה בכוח:

gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}

בדיקת ההפעלה: עוברים אל מסוף Cloud Run > Jobs. אמורה להתחיל הרצה חדשה.
בודקים את ה-MIG: מריצים את הפקודה gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. תראו שהמופעים עוברים למצב RECREATING כשהעבודה מפעילה את העדכון המתגלגל.

למה 15 דקות? הגדרנו את לוח הזמנים ל-‎ */15 * * * * ב-Codelab הזה כדי שתוכלו לראות את התוצאות במהירות. בסביבת ייצור אמיתית, סביר להניח שתשנו את ההגדרה כך שהסקריפט יפעל מדי יום (למשל, 0 3 * * * בשעה 3:00) או מדי שבוע.

8. הסרת המשאבים

אפשר להשתמש בסקריפט הניקוי cleanup.sh כדי לנקות את המשאבים שיצרנו כחלק מה-Codelab הזה. כחלק מהניקוי הזה, המשאבים הבאים יימחקו:

קבוצת מופעי המכונה המנוהלים (${CURRENT_MIG_NAME}) והמכונות הווירטואליות שמתחתיה.
תבנית המופע (${TEMPLATE_NAME}).
בדיקת תקינות וכללי חומת אש (${HEALTH_CHECK_NAME}).
מאגר Artifact Registry‏ (${REPOSITORY}).
חשבון השירות (אם יצרתם חשבון ייעודי למעבדה הזו).

אם סיימתם את הבדיקה, כדאי למחוק את הפרויקט. במאמר השבתה (מחיקה) של פרויקטים מוסבר איך עושים את זה.

מזל טוב

כל הכבוד, סיימתם את ה-Codelab!

למדתם איך להרחיב באופן מאובטח את עומסי העבודה של Confidential Space באמצעות קבוצות מנוהלות של מופעים (MIG). הגדרתם בהצלחה תיקון אוטומטי כדי להתאושש מכשלים, שינוי גודל אוטומטי כדי לטפל בעליות פתאומיות בטראפיק, וביצעתם עדכונים ללא השבתה גם לתמונה של מערכת ההפעלה של Confidential Space וגם לקונטיינר של עומס העבודה.

מה השלב הבא?

כדאי לעיין ב-Codelabs נוספים של Confidential Space:

הגנה על מודלים של למידת מכונה ועל קניין רוחני באמצעות Confidential Space
הדרכה: איך מבצעים עסקאות בנכסים דיגיטליים באמצעות חישוב רב-משתתפים ו-Confidential Space
ניתוח נתונים סודיים באמצעות Confidential Space
שימוש ב-Confidential Space עם משאבים מוגנים שלא מאוחסנים אצל ספק שירותי ענן