שימוש בתיקון אוטומטי באפליקציות עם זמינות גבוהה

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

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

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

מטרות

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

עלויות

במדריך הזה משתמשים ברכיבים של Google Cloud שהשימוש בהם כרוך בתשלום, כולל:

  • Compute Engine

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

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

    In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

    Verify that billing is enabled for your Google Cloud project.

    Enable the Compute Engine API, if it is not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the API

    In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

    Verify that billing is enabled for your Google Cloud project.

    Enable the Compute Engine API, if it is not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the API

אם אתם מעדיפים לעבוד משורת הפקודה, אתם יכולים להתקין את Google Cloud CLI.

ארכיטקטורת האפליקציה

האפליקציה כוללת את הרכיבים הבאים של Compute Engine:

ארכיטקטורת מערכת לבדיקת תקינות ולקבוצת מכונות.

איך בדיקת התקינות בודקת את שירות האינטרנט של ההדגמה

בבדיקת תקינות נשלחות בקשות בדיקה למכונה וירטואלית באמצעות פרוטוקול שצוין, כמו HTTP(S),‏ SSL או TCP. למידע נוסף, אפשר לעיין במאמרים בנושא איך בדיקות התקינות פועלות וקטגוריות, פרוטוקולים ויציאות של בדיקות תקינות.

במדריך הזה, בדיקת התקינות היא בדיקת תקינות HTTP שבודקת את נתיב ה-HTTP‏ /health ביציאה 80. בבדיקת תקינות של HTTP, בקשת הבדיקה עוברת רק אם הנתיב מחזיר תגובה של HTTP 200 (OK). במדריך הזה, שרת האינטרנט של ההדגמה מגדיר את הנתיב /health כדי להחזיר תגובה HTTP 200 (OK) כשהוא תקין או תגובה HTTP 500 (Internal Server Error) כשהוא לא תקין. מידע נוסף זמין במאמר בנושא קריטריונים להצלחה של HTTP,‏ HTTPS ו-HTTP/2.

יצירת בדיקת התקינות

כדי להגדיר תיקון תוכנה אוטומטי, צריך ליצור בדיקת תקינות בהתאמה אישית ולהגדיר את חומת האש של הרשת כך שתאפשר בדיקות תקינות.

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

המסוף

  1. יוצרים בדיקת תקינות.

    1. נכנסים לדף Create health check במסוף Google Cloud .

      מעבר אל Create health check

    2. בשדה Name, מזינים autohealer-check.

    3. מגדירים את Scope ל-Regional.

    4. בתפריט הנפתח אזור, בוחרים באפשרות europe-west1.

    5. בשדה פרוטוקול, בוחרים באפשרות HTTP.

    6. מגדירים את Request path (נתיב הבקשה) ל-/health. השדה הזה מציין את נתיב ה-HTTP שבו נעשה שימוש בבדיקת תקינות. במדריך הזה, שרת האינטרנט להדגמה מגדיר את הנתיב /health כך שיחזיר תגובה מסוג HTTP 200 (OK) כשהוא תקין, או תגובה מסוג HTTP 500 (Internal Server Error) כשהוא לא תקין.

    7. מגדירים את קריטריוני התקינות:

      1. מגדירים את Check interval ל-10. ההגדרה הזו קובעת את פרק הזמן שחלף בין תחילת בדיקה אחת לתחילת הבדיקה הבאה.
      2. מגדירים את Timeout לערך 5. ההגדרה הזו קובעת את משך הזמן שבוGoogle Cloud ממתין לתגובה לבדיקה. הערך הזה צריך להיות קטן מפרק הזמן בין הבדיקות או שווה לו.
      3. מגדירים את Healthy threshold ל-2. ההגדרה הזו קובעת את מספר הבדיקות הרצופות שצריכות להצליח כדי שהמכונה הווירטואלית תיחשב תקינה.
      4. מגדירים את Unhealthy threshold ל-3. ההגדרה הזו מגדירה את מספר הבדיקות הרצופות שצריכות להיכשל כדי שהמכונה הווירטואלית תיחשב כלא תקינה.

    8. משאירים את ערכי ברירת המחדל בשאר האפשרויות.

    9. לוחצים על יצירה בתחתית המסך.

  2. יוצרים כלל של חומת אש שמאפשר לבקשות לבדיקת תקינות (probes) לשלוח בקשות HTTP.

    1. נכנסים לדף Create firewall rule במסוף Google Cloud .

      כניסה לדף Create firewall rule

    2. בשדה Name (שם), מזינים default-allow-http-health-check.

    3. בשדה Network, בוחרים באפשרות default.

    4. בקטע יעדים, בוחרים באפשרות All instances in the network.

    5. בקטע מסנן מקור, בוחרים באפשרות IPv4 ranges.

    6. בשדה Source IPv4 ranges, מזינים 130.211.0.0/22, 35.191.0.0/16.

    7. בקטע Protocols and ports, בוחרים באפשרות TCP ומזינים את הערך 80.

    8. משאירים את ערכי ברירת המחדל בשאר האפשרויות.

    9. לוחצים על יצירה.

gcloud

  1. יוצרים בדיקת תקינות באמצעות הפקודה health-checks create http.

    gcloud compute health-checks create http autohealer-check \
    --region europe-west1 \
    --check-interval 10 \
    --timeout 5 \
    --healthy-threshold 2 \
    --unhealthy-threshold 3 \
    --request-path "/health"
    • ‫check-interval מגדיר את משך הזמן מתחילת בדיקה אחת לתחילת הבדיקה הבאה.
    • ‫timeout מגדיר את משך הזמן שבו Google Cloud הכלי ממתין לתגובה לבדיקה. הערך הזה חייב להיות קטן או שווה למרווח הזמן לבדיקה.
    • ‫healthy-threshold מגדיר את מספר הבדיקות הרציפות שצריכות להצליח כדי שהמכונה הווירטואלית תיחשב תקינה.
    • הערך של unhealthy-threshold מגדיר את מספר הבדיקות הרציפות שצריכות להיכשל כדי שהמכונה הווירטואלית תיחשב לא תקינה.
    • ‫request-path מציין את נתיב ה-HTTP שבו משתמשת בדיקת התקינות. במדריך הזה, שרת האינטרנט להדגמה מגדיר את הנתיב /health להחזרת תגובה HTTP 200 (OK) כשהוא תקין, או תגובה HTTP 500 (Internal Server Error) כשהוא לא תקין.

  2. יוצרים כלל של חומת אש שמאפשר לבקשות לבדיקות תקינות לשלוח בקשות HTTP.

    gcloud compute firewall-rules create default-allow-http-health-check \
    --network default \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16

מה הופך בדיקת תקינות לתיקון אוטומטי לטובה

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

  • unhealthy-threshold. צריך להיות יותר מ-1. מומלץ להגדיר ערך של 3 או יותר. ההגדרה הזו מספקת הגנה מפני כשלים נדירים כמו אובדן מנות ברשת.
  • ‫healthy-threshold. ערך של 2 מספיק לרוב האפליקציות.
  • ‫timeout. הגדירו ערך זמן נדיב (פי חמישה או יותר מזמן התגובה הצפוי). ערך הזמן הקצוב לתפוגה חייב להיות קטן מ-check-interval או שווה לו. כך אפשר למנוע עיכובים לא צפויים, כמו מכונות וירטואליות עמוסות או חיבור איטי לרשת.
  • ‫check-interval. הערך הזה צריך להיות בין שנייה אחת לבין כפליים של הזמן הקצוב לתפוגה (לא ארוך מדי ולא קצר מדי). כשהערך ארוך מדי, מופע שנכשל לא מזוהה מספיק מהר. אם הערך קצר מדי, המכונות והרשת עלולות להיות עמוסות מאוד, בגלל המספר הגבוה של בדיקות תקינות שנשלחות בכל שנייה.

הגדרת שירות האינטרנט

במדריך הזה נעשה שימוש באפליקציית אינטרנט שמאוחסנת ב-GitHub. כדי לקבל מידע נוסף על אופן ההטמעה של האפליקציה, אפשר לעיין במאגר GoogleCloudPlatform/python-docs-samples ב-GitHub.

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

המסוף

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

    1. במסוף Google Cloud , עוברים לדף יצירת תבנית של הגדרות מכונה.

      כניסה לדף Create instance template

    2. מגדירים את Name לערך webserver-template.

    3. בקטע Location, בתפריט הנפתח Region בוחרים באפשרות europe-west1.

    4. בקטע Machine configuration, בתפריט הנפתח Machine type, בוחרים באפשרות e2-medium.

    5. בקטע Firewall, מסמנים את תיבת הסימון Allow HTTP traffic.

    6. מרחיבים את הקטע אפשרויות מתקדמות כדי לראות את ההגדרות המתקדמות. מופיעים כמה תת-קטעים.

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

      apt-get update
apt-get -y install git python3-pip python3-venv
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
python3 -m venv venv
./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
./venv/bin/pip3 install gunicorn
./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo

    8. משאירים את ערכי ברירת המחדל בשאר האפשרויות.

    9. לוחצים על יצירה.

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

    1. נכנסים לדף Create instance group במסוף Google Cloud .

      כניסה לדף Create instance group

    2. מגדירים את Name לערך webserver-group.

    3. בשדה תבנית של הגדרות מכונה, בוחרים באפשרות webserver-template.

    4. בשדה Region בוחרים את europe-west1.

    5. בשדה Zone (אזור), בוחרים באפשרות europe-west1-b.

    6. בקטע Autoscaling, בוחרים באפשרות Off: do not autoscale בשדה Autoscaling mode.

    7. גוללים חזרה לשדה Number of instances ומגדירים אותו לערך 3.

    8. בקטע Autohealing, מבצעים את הפעולות הבאות:

      1. בתפריט הנפתח Health check, בוחרים באפשרות autohealer-check.

      2. מגדירים את Initial delay (השהיה ראשונית) ל-300.

    9. משאירים את ערכי ברירת המחדל בשאר האפשרויות.

    10. לוחצים על יצירה.

  3. יוצרים כלל של חומת אש שמאפשר בקשות HTTP לשרתי האינטרנט.

    1. נכנסים לדף Create firewall rule במסוף Google Cloud .

      כניסה לדף Create firewall rule

    2. בשדה Name, מזינים default-allow-http.

    3. בשדה Network, בוחרים באפשרות default.

    4. בקטע יעדים, בוחרים באפשרות Specified target tags.

    5. בשדה Target Tags (תגי יעד), מזינים http-server.

    6. בשדה מסנן מקור, בוחרים באפשרות IPv4 ranges.

    7. בשדה Source IPv4 ranges (טווחים של כתובות IPv4 של המקור), מזינים 0.0.0.0/0 כדי לאפשר גישה לכל כתובות ה-IP.

    8. בקטע Protocols and ports, בוחרים באפשרות TCP ומזינים את הערך 80.

    9. משאירים את ערכי ברירת המחדל בשאר האפשרויות.

    10. לוחצים על יצירה.

gcloud

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

    gcloud compute instance-templates create webserver-template \
    --instance-template-region europe-west1 \
    --machine-type e2-medium \
    --tags http-server \
    --metadata startup-script='
  apt-get update
  apt-get -y install git python3-pip python3-venv
  git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
  python3 -m venv venv
  ./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
  ./venv/bin/pip3 install gunicorn
  ./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo'

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

    gcloud compute instance-groups managed create webserver-group \
    --zone europe-west1-b \
    --template projects/PROJECT_ID/regions/europe-west1/instanceTemplates/webserver-template \
    --size 3 \
    --health-check projects/PROJECT_ID/regions/europe-west1/healthChecks/autohealer-check \
    --initial-delay 300

  3. יוצרים כלל של חומת אש שמאפשר בקשות HTTP לשרתי האינטרנט.

    gcloud compute firewall-rules create default-allow-http \
    --network default \
    --allow tcp:80 \
    --target-tags http-server

מחכים כמה דקות עד שקבוצת מופעי מכונה מנוהלים תיצור את מכונות ה-VM ותאמת אותן.

הדמיה של כשלים בבדיקות התקינות

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

המסוף

  1. עוברים אל מכונת VM של שרת אינטרנט.

    1. נכנסים לדף VM instances במסוף Google Cloud .

      כניסה לדף VM instances

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

    בשרת האינטרנט לדוגמה מוצג דף שדומה לזה:

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

  2. בדף האינטרנט של ההדגמה, לוחצים על Make unhealthy (הפיכת האתר ללא תקין).

    כתוצאה מכך, שרת האינטרנט נכשל בבדיקת התקינות. במילים אחרות, שרת האינטרנט גורם לכך שהנתיב /health יחזיר את הערך HTTP 500 (Internal Server Error). אתם יכולים לאמת את זה בעצמכם בלחיצה מהירה על הלחצן Check health (הוא מפסיק לפעול אחרי שהתיקון האוטומטי מתחיל להפעיל מחדש את ה-VM).

  3. מחכים שהתיקון האוטומטי יתבצע.

    1. נכנסים לדף VM instances במסוף Google Cloud .

      כניסה לדף VM instances

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

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

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

gcloud

  1. עוקבים אחרי הסטטוס של קבוצת מופעי מכונה מנוהלים. (כשמסיימים, לוחצים על Ctrl+C כדי להפסיק).

    while : ; do
  gcloud compute instance-groups managed list-instances webserver-group \
  --zone europe-west1-b
  sleep 5  # Wait for 5 seconds
done

      NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  NAME: webserver-group-4qbx
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  NAME: webserver-group-m5v5
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

    כל המכונות הווירטואליות בקבוצה צריכות להציג את STATUS: RUNNING ו-ACTION: NONE. אם לא, מחכים כמה דקות עד שהמכונות הווירטואליות יסיימו את ההגדרה ומנסים שוב.

  2. פותחים סשן חדש ב-Cloud Shell שבו מותקן Google Cloud CLI.

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

    gcloud compute instances list --filter webserver-group

    בעמודה EXTERNAL_IP, מעתיקים את כתובת ה-IP של כל מכונה וירטואלית של שרת אינטרנט ושומרים אותה כמשתנה bash מקומי.

    export IP_ADDRESS=EXTERNAL_IP_ADDRESS

  4. מוודאים שהגדרת שרת האינטרנט הסתיימה. השרת מחזיר תשובה מסוג HTTP 200 OK.

    curl --head $IP_ADDRESS/health

    HTTP/1.1 200 OK
Server: gunicorn
...

    אם מופיעה השגיאה Connection refused, צריך להמתין דקה כדי שהשרת יסיים את ההגדרה ולנסות שוב.

  5. הופכים את שרת האינטרנט ללא תקין.

    curl $IP_ADDRESS/makeUnhealthy > /dev/null

    כתוצאה מכך, שרת האינטרנט נכשל בבדיקת התקינות. באופן ספציפי, שרת האינטרנט גורם לנתיב /health להחזיר HTTP 500 INTERNAL SERVER ERROR. אתם יכולים לאמת את זה בעצמכם על ידי שליחת בקשה מהירה אל /health (הפעולה הזו מפסיקה לעבוד אחרי שהתיקון האוטומטי מתחיל להפעיל מחדש את ה-VM).

    curl --head $IP_ADDRESS/health

    HTTP/1.1 500 INTERNAL SERVER ERROR
Server: gunicorn
...

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

    1. כשתהליך התיקון האוטומטי מתחיל, העמודות STATUS ו-ACTION מתעדכנות ומציינות שהכלי לתיקון אוטומטי התחיל להפעיל מחדש את המכונה הווירטואלית הלא תקינה.

        NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: STOPPING
  HEALTH_STATE: UNHEALTHY
  ACTION: RECREATING
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  ...

    2. תהליך התיקון האוטומטי מסתיים כשהמכונה הווירטואלית מדווחת שוב על STATUS של RUNNING ועל ACTION של NONE, מה שמצביע על כך שהמכונה הווירטואלית הופעלה מחדש בהצלחה.

        NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  ...

    3. כשמסיימים את המעקב אחרי קבוצת מופעי מכונה מנוהלים, לוחצים על Ctrl+C.

מומלץ לחזור על התרגיל הזה. הנה כמה רעיונות:

  • מה קורה אם כל המכונות הווירטואליות לא תקינות בו-זמנית? מידע נוסף על אופן הפעולה של תיקון אוטומטי במהלך כשלים בו-זמניים זמין במאמר בנושא אופן הפעולה של תיקון אוטומטי.

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

  • לקבוצת מופעי מכונה מנוהלים יש הגדרת תצורה של initial delay. מהו העיכוב המינימלי שנדרש לשרת האינטרנט הזה להדגמה? (בפועל, כדאי להגדיר את העיכוב למשך זמן ארוך יותר (10% עד 20%) מזה שנדרש להפעלת מכונה וירטואלית ולהתחלת הצגת בקשות לאפליקציה. אחרת, המכונה הווירטואלית עלולה להיתקע בלולאת אתחול של תיקון תוכנה אוטומטי (autohealing).

הצגת ההיסטוריה של התיקון האוטומטי (אופציונלי)

כדי לראות את ההיסטוריה של פעולות התיקון האוטומטי, משתמשים בפקודה gcloud הבאה:

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

מידע נוסף זמין במאמר בנושא צפייה בפעולות היסטוריות של תיקון אוטומטי

הסרת המשאבים

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

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

מחיקת הפרויקט

  1. נכנסים לדף Manage resources במסוף Google Cloud .

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת משאבים ספציפיים

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

מחיקת קבוצת המכונות

console

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. מסמנים את התיבה של קבוצת המכונות webserver-group.
  3. כדי למחוק את קבוצות המכונות, לוחצים על Delete.

gcloud

gcloud compute instance-groups managed delete webserver-group --zone europe-west1-b -q

מחיקת תבנית של הגדרות מכונה

console

  1. נכנסים לדף Instance templates במסוף Google Cloud .

    כניסה לדף Instance templates

  2. מסמנים את התיבה לצד התבנית של הגדרות המכונה.

  3. לוחצים על Delete בחלק העליון של הדף. בחלון החדש, לוחצים על מחיקה כדי לאשר את המחיקה.

gcloud

gcloud compute instance-templates delete webserver-template -q \
    --region=europe-west1

מחיקת בדיקת התקינות

console

  1. נכנסים לדף Health checks במסוף Google Cloud .

    מעבר אל "בדיקות תקינות"

  2. לוחצים על תיבת הסימון לצד בדיקת התקינות.

  3. לוחצים על מחיקה בחלק העליון של הדף. בחלון החדש, לוחצים על Delete כדי לאשר את המחיקה.

gcloud

gcloud compute health-checks delete autohealer-check -q \
    --region=europe-west1

מחיקת הכללים של חומת האש

console

  1. נכנסים לדף Firewall rules במסוף Google Cloud .

    לכללי חומת אש

  2. לוחצים על תיבות הסימון לצד כללי חומת האש שנקראים default-allow-http ו-default-allow-http-health-check.

  3. לוחצים על מחיקה בחלק העליון של הדף. בחלון החדש, לוחצים על מחיקה כדי לאשר את המחיקה.

gcloud

gcloud compute firewall-rules delete default-allow-http default-allow-http-health-check -q

המאמרים הבאים