פתרון התחלתי: אפליקציית אינטרנט תלת-שכבתית

Last reviewed 2024-10-08 UTC

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

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

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

המוצרים שהשתמשו בהם

הפתרון מתבסס על המוצרים הבאים: Google Cloud

  • ‫Cloud Run: שירות מנוהל מלא שמאפשר לכם ליצור ולפרוס אפליקציות בקונטיינרים ללא שרת. Google Cloud מטפל בהתאמה לעומס ובמשימות אחרות שקשורות לתשתית, כדי שתוכלו להתמקד בלוגיקה העסקית של הקוד.
  • ‫Cloud SQL: מסד נתונים מנוהל של MySQL או PostgreSQL ב- Google Cloud.
  • ‫Memorystore for Redis: שירות שמאפשר שמירה במטמון של אפליקציות באמצעות שירות בזיכרון שניתן להתאמה, מאובטח וזמין מאוד ל-Redis ול-Memcached.
  • רשת של ענן וירטואלי פרטי (VPC): רשת וירטואלית גלובלית שמתפרסת על פני כל האזורים Google Cloud ומאפשרת לכם לקשר בין משאבי הענן שלכם.

בקטע הבא מוסבר איך המוצרים האלה מוגדרים ואיך הם פועלים יחד.

ארכיטקטורה

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

ארכיטקטורה של התשתית שנדרשת לפתרון של אפליקציית אינטרנט בשלוש שכבות.

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

תהליך הבקשה

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

  1. קצה קדמי מבוסס-אינטרנט מקבל בקשות מלקוחות לאפליקציה למעקב אחרי משימות. הקצה הקדמי הוא שירות Cloud Run, שמבצע עיבוד של לקוח HTML בדפדפן של המשתמש.
  2. הקצה הקדמי שולח בקשות לשכבת API, שגם היא נפרסת כשירות Cloud Run.
  3. נתונים שנקראים לעיתים קרובות נשמרים במטמון ומוצגים ממכונה של Memorystore for Redis.
  4. בקשות שלא ניתן לטפל בהן ממטמון Redis בזיכרון נשלחות על ידי שכבת ה-API למסד נתונים של Cloud SQL.

הגדרת משאבים

בקטע הזה מוסבר על ההגדרה של Cloud Run,‏ Memorystore,‏ Cloud SQL ומשאבי הרשת שהפתרון פורס. אם אתם מכירים את שפת ההגדרות של Terraform, תוכלו לשנות חלק מההגדרות האלה, כמו שמתואר בהמשך המדריך הזה.

כדי לראות את הגדרות התצורה, לוחצים על אחד מהקטעים הבאים:

שירותי Cloud Run

פרמטר הגדרה מוגדרת מראש
קיבולת מחשוב לכל מופע של קונטיינר ‫‎1 vCPU, זיכרון בנפח 512MiB
טווח ההתאמה האוטומטית לעומס (מספר מופעי קונטיינר)

קצה קדמי: 0-8

שכבת API‏: 0-8

מכונה של Memorystore for Redis

פרמטר הגדרה מוגדרת מראש
גרסת Redis גרסה 6.x
רמת שירות בסיסי, ללא זמינות גבוהה (HA)
זיכרון ‎1GB
הצפנת נתונים

במצב מנוחה: Google-owned and Google-managed encryption key

בזמן ההעברה: לא מוצפן

מסד נתונים של Cloud SQL

פרמטר הגדרה מוגדרת מראש
גרסת מסד הנתונים ‫PostgreSQL 14 או MySQL 8.0
סוג המכונה ‫db-g1-small: 1 vCPU, ‏ 1.7GB זיכרון
זמינות אזור יחיד
אחסון כונן SSD בנפח 10GB, עם הפעלה של שינוי גודל אוטומטי

משאבים ליצירת קשרים עסקיים

מופע Cloud SQL מצורף ל רשת VPC שנוצרה על ידי הלקוח, ויש לו כתובת IP פנימית.

‫Serverless VPC Access מספק קישוריות ממופע Cloud Run שמארח את שכבת ה-API למופע Cloud SQL. בקשות משירות Cloud Run למופע Cloud SQL משתמשות ב-DNS פנימי ובכתובות IP פנימיות. תעבורת הנתונים בתגובה משתמשת גם ברשת הפנימית. במילים אחרות, תעבורת הנתונים בין האפליקציה למסד הנתונים לא חשופה לאינטרנט. בנוסף, זמן האחזור של תעבורת נתונים דרך חיבור לרשת (VPC) מאפליקציית serverless יכול להיות קצר יותר בהשוואה לזמן האחזור של תעבורת נתונים שעוברת באינטרנט.

הקישוריות בין מופע Memorystore לבין מסד הנתונים של Cloud SQL מתבצעת באמצעות חיבור ישיר של רשתות וירטואליות.

עלות

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

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

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

  • המיקומים שבהם נפרסים המשאבים. Google Cloud
  • משך הזמן שבו נעשה שימוש במשאבים.

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

כדי לפרוס את הפתרון הזה, קודם צריך פרויקט Google Cloud וכמה הרשאות IAM.

יצירה או בחירה של Google Cloud פרויקט

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

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

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

  1. Ensure that you have the Project Creator IAM role (roles/resourcemanager.projectCreator). Learn how to grant roles.

  2. In the Google Cloud console, go to the project selector page.

    Go to project selector

  3. Click Create project.

  4. Name your project. Make a note of your generated project ID.

  5. Edit the other fields as needed.

  6. Click Create.

קבלת הרשאות ה-IAM הנדרשות

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

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

נדרשת הרשאת IAM תפקיד מוגדר מראש שכולל את ההרשאות הנדרשות

serviceusage.services.enable

 אדמין בשימוש בשירות
(roles/serviceusage.serviceUsageAdmin)

iam.serviceAccounts.create

 אדמין בחשבון שירות
(roles/iam.serviceAccountAdmin)

resourcemanager.projects.setIamPolicy

 אדמין IAM בפרויקט
(roles/resourcemanager.projectIamAdmin)
config.deployments.create
config.deployments.list		 אדמין של Cloud Infrastructure Manager
(roles/config.admin)
iam.serviceAccount.actAs משתמש בחשבון שירות
(roles/iam.serviceAccountUser)

מידע על הרשאות זמניות לחשבון שירות

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

צפייה בתפקידים שהוקצו לחשבון השירות

התפקידים האלה מפורטים כאן למקרה שאדמין של פרויקט או ארגון ב-Google Cloud יזדקק למידע הזה.

  • roles/artifactregistry.admin
  • roles/cloudsql.admin
  • roles/compute.networkAdmin
  • roles/iam.serviceAccountAdmin
  • roles/iam.serviceAccountUser
  • roles/redis.admin
  • roles/resourcemanager.projectIamAdmin
  • roles/run.admin
  • roles/servicenetworking.serviceAgent
  • roles/serviceusage.serviceUsageViewer
  • roles/vpcaccess.admin

פריסת הפתרון

כדי לעזור לכם לפרוס את הפתרון הזה במאמץ מינימלי, אנחנו מספקים הגדרת Terraform ב-GitHub. ההגדרות של Terraform מגדירות את כלGoogle Cloud המשאבים שנדרשים לפתרון.

אפשר לפרוס את הפתרון באחת מהשיטות הבאות:

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

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

  • שימוש ב-Terraform CLI: כדאי להשתמש בשיטה הזו אם רוצים להתאים אישית את הפתרון או אם רוצים להפוך את הקצאת המשאבים והניהול שלהם לאוטומטיים באמצעות הגישה של תשתית כקוד (IaC). מורידים את ההגדרות של Terraform מ-GitHub, משנים את הקוד לפי הצורך ופורסים את הפתרון באמצעות Terraform CLI. אחרי פריסת הפתרון, אפשר להמשיך להשתמש ב-Terraform כדי לנהל אותו.

    כדי להשתמש בשיטת הפריסה הזו, פועלים לפי ההוראות במאמר פריסה באמצעות Terraform CLI.

פריסה דרך המסוף

כדי לפרוס את הפתרון שהוגדר מראש:

  1. בקטלוג הפתרונות של Jump Start, עוברים לפתרון Three-tier web app. Google Cloud

    מעבר לפתרון של אפליקציית אינטרנט תלת-שכבתית

  2. בודקים את המידע שמופיע בדף, כמו העלות המשוערת של הפתרון וזמן ההטמעה המשוער.

  3. כדי להתחיל לפרוס את הפתרון, לוחצים על פריסה.

    מוצגת חלונית הגדרה עם הוראות מפורטות.

  4. משלימים את השלבים בחלונית ההגדרה.

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

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

  5. ממתינים עד שהפתרון יופעל.

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

    אחרי שהפריסה מסתיימת, השדה סטטוס משתנה לנפרס.

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

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

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

    התחלת הסיור

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

פריסה באמצעות Terraform CLI

בקטע הזה מוסבר איך אפשר להתאים אישית את הפתרון או להפוך את ההקצאה והניהול של הפתרון לאוטומטיים באמצעות Terraform CLI. פתרונות שפורסים באמצעות Terraform CLI לא מוצגים בדף Solution deployments במסוף Google Cloud .

הגדרת לקוח Terraform

אפשר להריץ את Terraform ב-Cloud Shell או במארח המקומי. במדריך הזה מוסבר איך להריץ את Terraform ב-Cloud Shell, שבו Terraform מותקן מראש ומוגדר לאימות באמצעות Google Cloud.

קוד ה-Terraform של הפתרון הזה זמין במאגר GitHub.

  1. משכפלים את מאגר GitHub ל-Cloud Shell.

    Cloud Shell-פתיחה ב

    תוצג בקשה לאישור ההורדה של מאגר GitHub אל Cloud Shell.

  2. לוחצים על אישור.

    ‫Cloud Shell מופעל בכרטיסיית דפדפן נפרדת, והקוד של Terraform מורד לספרייה $HOME/cloudshell_open של סביבת Cloud Shell.

  3. ב-Cloud Shell, בודקים אם ספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-google-three-tier-web-app/. זו הספרייה שמכילה את קובצי ההגדרות של Terraform לפתרון. אם אתם צריכים לעבור לספרייה הזו, מריצים את הפקודה הבאה:

    cd $HOME/cloudshell_open/terraform-google-three-tier-web-app/

  4. מפעילים את Terraform באמצעות הפקודה הבאה:

    terraform init

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

    Terraform has been successfully initialized!

הגדרת משתני Terraform

קוד ה-Terraform שהורדתם כולל משתנים שבהם אפשר להשתמש כדי להתאים אישית את הפריסה בהתאם לדרישות שלכם. לדוגמה, אפשר לציין את הפרויקט Google Cloud ואת האזור שבהם רוצים לפרוס את הפתרון.

  1. מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-google-three-tier-web-app/. אם לא, עוברים לספרייה הזו.

  2. באותה ספרייה, יוצרים קובץ טקסט בשם terraform.tfvars.

  3. בקובץ terraform.tfvars, מעתיקים את קטע הקוד הבא ומגדירים ערכים למשתנים הנדרשים.

    • פועלים לפי ההוראות שמופיעות כהערות בקטע הקוד.
    • קטע הקוד הזה כולל רק את המשתנים שחובה להגדיר להם ערכים. התצורה של Terraform כוללת משתנים אחרים עם ערכי ברירת מחדל. כדי לבדוק את כל המשתנים ואת ערכי ברירת המחדל, אפשר לעיין בקובץ variables.tf שזמין בספרייה $HOME/cloudshell_open/terraform-google-three-tier-web-app/.
    • חשוב לוודא שכל ערך שמוגדר בקובץ terraform.tfvars תואם לסוג המשתנה שמוצהר בקובץ variables.tf. לדוגמה, אם הסוג שמוגדר למשתנה בקובץ variables.tf הוא bool, צריך לציין true או false כערך של המשתנה הזה בקובץ terraform.tfvars.
    # This is an example of the terraform.tfvars file.
# The values in this file must match the variable types declared in variables.tf.
# The values in this file override any defaults in variables.tf.

# ID of the project in which you want to deploy the solution
project_id = "PROJECT_ID"

# Google Cloud region where you want to deploy the solution
# Example: us-central1
region = "REGION"

# Google Cloud zone where you want to deploy the solution
# Example: us-central1-a
zone = "ZONE"

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

אימות ובדיקה של הגדרות Terraform

  1. מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-google-three-tier-web-app/. אם לא, עוברים לספרייה הזו.

  2. מוודאים שאין שגיאות בהגדרות של Terraform:

    terraform validate

    אם הפקודה מחזירה שגיאות, מבצעים את התיקונים הנדרשים בהגדרה ומריצים שוב את הפקודה terraform validate. חוזרים על השלב הזה עד שהפקודה מחזירה את ההודעה הבאה:

    Success! The configuration is valid.

  3. בודקים את המשאבים שמוגדרים בהגדרה:

    terraform plan

  4. אם לא יצרתם את הקובץ terraform.tfvars כמו שמתואר למעלה, Terraform יבקש מכם להזין ערכים למשתנים שאין להם ערכי ברירת מחדל. מזינים את הערכים הנדרשים.

    הפלט של הפקודה terraform plan הוא רשימה של המשאבים ש-Terraform מקצה כשמחילים את ההגדרות.

    אם רוצים לבצע שינויים, עורכים את ההגדרה ומריצים שוב את הפקודות terraform validate ו-terraform plan.

הקצאת המשאבים

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

  1. מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-google-three-tier-web-app/. אם לא, עוברים לספרייה הזו.

  2. מחילים את ההגדרות של Terraform:

    terraform apply

  3. אם לא יצרתם את הקובץ terraform.tfvars כמו שמתואר למעלה, Terraform יבקש מכם להזין ערכים למשתנים שאין להם ערכי ברירת מחדל. מזינים את הערכים הנדרשים.

    ב-Terraform מוצגת רשימה של המשאבים שייווצרו.

  4. כשמופיעה בקשה לבצע את הפעולות, מזינים yes.

    ב-Terraform מוצגות הודעות שמראות את התקדמות הפריסה.

    אם אי אפשר להשלים את הפריסה, Terraform מציג את השגיאות שגרמו לכשל. בודקים את הודעות השגיאה ומעדכנים את ההגדרה כדי לתקן את השגיאות. ואז מריצים שוב את הפקודה terraform apply. אם אתם צריכים עזרה בפתרון שגיאות ב-Terraform, תוכלו לקרוא את המאמר שגיאות בפריסת הפתרון באמצעות Terraform CLI.

    אחרי שכל המשאבים נוצרים, מוצגת ב-Terraform ההודעה הבאה:

    Apply complete!

    בפלט של Terraform מופיעה גם כתובת ה-URL של חזית האפליקציה למעקב אחרי משימות (endpoint) והשם של מופע Cloud SQL (sqlservername), כמו בדוגמה הבאה:

    endpoint = "https://three-tier-app-fe-pn4ngg7gnq-uc.a.run.app"
sqlservername = "three-tier-app-db-75c2"

  5. כדי להציג את אפליקציית המעקב אחרי משימות שהפתרון פרס, מעתיקים את כתובת ה-URL‏ endpoint מהשלב הקודם ופותחים את כתובת ה-URL בדפדפן.

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

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

    התחלת הסיור

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

התאמה אישית של הפתרון

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

בקטע Resource configuration (למעלה במדריך הזה) מפורטים הפרמטרים שהוגדרו מראש של משאביGoogle Cloud שהפתרון של אפליקציית האינטרנט בתלת-שכבות מספק. אפשר להתאים אישית את הפתרון על ידי שינוי פרמטרים מסוימים בקובץ main.tf.

כדי להתאים אישית את הפתרון, מבצעים את השלבים הבאים ב-Cloud Shell:

  1. מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-google-three-tier-web-app/. אם לא, עוברים לספרייה הזו.

  2. פותחים את הקובץ main.tf ומבצעים את השינויים הנדרשים, כמו שמוצג בדוגמאות בטבלה הבאה:

    פרמטר קוד Terraform
    שינוי קנה מידה ב-Cloud Run הארגומנט בקובץ main.tf: autoscaling.knative.dev/maxScale

    קטע קוד 

    resource "google_cloud_run_service" "api" {
...
  template {
  ...
    metadata {
      annotations = {
        "autoscaling.knative.dev/maxScale" = "COUNT"
        ...
      }
    }
  }
}
    גרסת Redis הארגומנט בקובץ main.tf: redis_version

    קטע קוד

    resource "google_redis_instance" "main" {
  ...
  redis_version = "VERSION"
  ...
}

    זהירות: התצורה של Terraform שסופקה על ידי Google אומתה לגרסה 6.x של Redis. אם תשנו את הגרסה, יכול להיות שהפתרון שנפרס לא יפעל כמצופה.

    רמת Redis הארגומנט בקובץ main.tf: tier

    קטע קוד

    resource "google_redis_instance" "main" {
  ...
  tier = "TIER"
  ...
}
    זיכרון Redis הארגומנט בקובץ main.tf: memory_size_gb

    קטע קוד

    resource "google_redis_instance" "main" {
  ...
  memory_size_gb = SIZE
  ...
}
    גרסת PostgreSQL או MySQL הארגומנט בקובץ main.tf: database_version

    קטע קוד

    resource "google_sql_database_instance" "main" {
  ...
  database_version = "VERSION"
  ...
...
}

    שימו לב: ההגדרות האישיות של Terraform שסופקו על ידי Google אומתו לגרסה 14 של PostgreSQL ולגרסה 8.0 של MySQL. אם תשנו את הגרסה, יכול להיות שהפתרון שנפרס לא יפעל כמצופה.

    סוג המכונה של מסד הנתונים הארגומנט בקובץ main.tf: settings.tier

    קטע קוד

    resource "google_sql_database_instance" "main" {
  ...
  settings {
    tier = "MACHINE_TYPE"
    ...
  }
...
}
    אחסון מסדי נתונים הארגומנט בקובץ main.tf: settings.disk_size

    קטע קוד

    resource "google_sql_database_instance" "main" {
  ...
  settings {
    ...
    ...
    disk_size = SIZE
    ...
  }
  ...
}

  3. אימות ובדיקה של ההגדרות ב-Terraform.

  4. הקצאת המשאבים.

המלצות לעיצוב

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

כדי לראות את המלצות העיצוב לכל אזור, לוחצים על הכרטיסייה המתאימה.

אבטחה

עיצוב המלצות
הצפנת נתונים
  • כברירת מחדל, Cloud Run מצפין נתונים באמצעות Google-owned and Google-managed encryption key. כדי להגן על הקונטיינרים באמצעות מפתח שאתם שולטים בו, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח. מידע נוסף זמין במאמר בנושא שימוש במפתחות הצפנה בניהול הלקוח .
  • כברירת מחדל, Memorystore משתמש ב- Google-owned and Google-managed encryption keys כדי להצפין נתונים באחסון. כדי להצפין נתונים באמצעות מפתח שאתם שולטים בו, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח. מידע נוסף זמין במאמר מידע על מפתחות הצפנה בניהול הלקוח (CMEK).
  • אתם יכולים להפעיל הצפנה של נתונים בזמן ההעברה ב-Memorystore באמצעות פרוטוקול Transport Layer Security ‏ (TLS). מידע נוסף זמין במאמר מידע על הצפנה במעבר.
אבטחת שרשרת האספקה של תוכנות כדי לוודא שרק קובצי אימג' מורשים של קונטיינרים נפרסים בשירותי Cloud Run, אפשר להשתמש ב-Binary Authorization.
בקרת גישה
  • שירות Cloud Run שמפעיל את שכבת ה-API מאפשר תעבורת נכנסת מכל מקור. כדי לשפר את האבטחה, אפשר להגביל את תעבורת הנתונים הנכנסת (ingress) כך שתתאפשר רק תנועה ממקורות פנימיים. מידע נוסף זמין במאמר הגבלת תעבורת נתונים נכנסת (ingress) ב-Cloud Run.
  • כדי להגן על האפליקציה מפני גישה לא מורשית, אפשר להפעיל את התכונה AUTH ב-Memorystore, כך שחיבורי לקוח נכנסים יאומתו. מידע נוסף זמין במאמר מידע על Redis AUTH.

אמינות

עיצוב המלצות
שינוי גודל האפליקציה שירותי Cloud Run בפתרון מוגדרים להתאמה אוטומטית לעומס (autoscaling) של מופעי הקונטיינר באופן אופקי, בהתאם לעומס הבקשות. בודקים ומתאימים את הפרמטרים של התאמה אוטומטית לעומס בהתאם לדרישות שלכם. מידע נוסף זמין במאמר מידע על שינוי גודל אוטומטי של מופעי קונטיינר.
טיפול בבקשות כדי לשפר את מהירות התגובה של שירותי Cloud Run שמאחסנים מצב ספציפי ללקוח במופעי קונטיינר, אפשר להשתמש בזיקה לסשן (session affinity). בקשות מאותו לקוח מנותבות לאותו מופע של מאגר, על בסיס האפשרות הטובה ביותר. מידע נוסף מופיע במאמר בנושא הגדרת זיקה לסשן (session affinity) (שירותים).
עמידות הנתונים כדי להגן על הנתונים מפני אובדן, אפשר להשתמש בגיבויים אוטומטיים של מסד הנתונים ב-Cloud SQL. מידע נוסף זמין במאמר מידע על גיבויים ב-Cloud SQL.
זמינות גבוהה (HA) של מסד נתונים

מסד הנתונים של Cloud SQL בפתרון נפרס בתחום אחד. כדי להגדיר זמינות גבוהה, אפשר להשתמש בהגדרה של כמה אזורים. מידע נוסף זמין במאמר בנושא זמינות גבוהה.

אם זמינות גבוהה של מסד הנתונים היא דרישה קריטית, אפשר לשקול את שירות AlloyDB ל-PostgreSQL כחלופה. Google Cloud

מהימנות מסד הנתונים

האינטס של Cloud SQL בפתרון הזה משתמש בסוג המכונה db-g1-small, שמשתמש במעבד עם ליבת מעבד משותפת. סוג המכונה הזה נועד לספק משאבים למסד נתונים בעלות נמוכה, שיכול להתאים רק לסביבות בדיקה ופיתוח. אם אתם צריכים אמינות ברמת הייצור, כדאי להשתמש בסוג מכונה שמספק יותר CPU וזיכרון.

מכונה של Cloud SQL שמשתמשת בסוג המכונה db-g1-small לא נכללת בהסכם רמת השירות (SLA) של Cloud SQL. מידע נוסף על הגדרות שלא נכללות בהסכם רמת השירות זמין במאמר הנחיות תפעוליות.

מטמון HA כדי להבטיח זמינות גבוהה לשכבת המטמון בזיכרון בפתרון הזה, אפשר להשתמש במסלול הרגיל של Memorystore for Redis. השירות יוצר רפליקות לקריאה לפעולות קריאה מבוזרות, ומספק יתירות כשל אוטומטית. מידע נוסף זמין במאמר בנושא יכולות של רמות שירות ב-Redis.

עלות

עיצוב המלצות
יעילות המשאבים

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

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

שימוש במשאבים

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

ביצועים

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

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

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

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

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

אם ביצועי מסד הנתונים הם דרישה קריטית, אפשר לשקול להשתמש בשירות AlloyDB ל-PostgreSQL. Google Cloud

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

שימו לב לנקודות הבאות:

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

מחיקת הפריסה

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

מחיקה דרך המסוף

משתמשים בהליך הזה אם פרסתם את הפתרון דרך המסוף.

  1. נכנסים לדף Solution deployments במסוף Google Cloud .

    מעבר אל 'פריסות פתרונות'

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

  3. מאתרים את הפריסה שרוצים למחוק.

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

    יכול להיות שתצטרכו לגלול כדי לראות את הפעולות בשורה.

  5. מזינים את שם הפריסה ולוחצים על אישור.

    בשדה סטטוס מוצג הערך בתהליך מחיקה.

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

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

מחיקה באמצעות Terraform CLI

משתמשים בהליך הזה אם פרסתם את הפתרון באמצעות Terraform CLI.

  1. ב-Cloud Shell, מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-google-three-tier-web-app/. אם לא, עוברים לספרייה הזו.

  2. מסירים את המשאבים שהוקצו על ידי Terraform:

    terraform destroy

    ב-Terraform מוצגת רשימה של המשאבים שיוסרו.

  3. כשמופיעה בקשה לבצע את הפעולות, מזינים yes.

    ב-Terraform מוצגות הודעות שמראות את ההתקדמות. אחרי שכל המשאבים נמחקים, Terraform מציגה את ההודעה הבאה:

    Destroy complete!

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

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

אופציונלי: מחיקת הפרויקט

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

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

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. בהנחיה, מקלידים את מזהה הפרויקט ולוחצים על Shut down (סגירה).

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

אופציונלי: מחיקה של חשבון השירות

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

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

  • אם פרסתם את הפתרון דרך מסוף Google Cloud , עוברים לדף Solution deployments. (אם כבר נמצאים בדף הזה, צריך לרענן את הדפדפן). תהליך מחיקת חשבון השירות מופעל ברקע. אין צורך בפעולה נוספת.

  • אם פרסתם את הפתרון באמצעות Terraform CLI, מבצעים את השלבים הבאים:

    1. נכנסים לדף Service accounts במסוף Google Cloud .

      כניסה לדף Service accounts

    2. בוחרים את הפרויקט שבו השתמשתם כדי ליצור את הפתרון.

    3. בוחרים את חשבון השירות שרוצים למחוק.

      מזהה האימייל של חשבון השירות שנוצר עבור הפתרון הוא בפורמט הבא:

      goog-sc-DEPLOYMENT_NAME-NNN@PROJECT_ID.iam.gserviceaccount.com

      מזהה האימייל מכיל את הערכים הבאים:

      • ‫DEPLOYMENT_NAME: שם הפריסה.
      • ‫NNN: מספר אקראי בן 3 ספרות.
      • ‫PROJECT_ID: מזהה הפרויקט שבו פרסתם את הפתרון.

    4. לוחצים על Delete.

פתרון בעיות במקרה של שגיאות

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

שגיאות בהטמעה דרך המסוף

אם הפריסה נכשלת כשמשתמשים במסוף, צריך לבצע את הפעולות הבאות:

  1. עוברים לדף פריסות של פתרונות.

    אם הפריסה נכשלה, בשדה סטטוס יופיע הערך נכשל.

  2. צופים בפרטי השגיאות שגרמו לכשל:

    1. בשורה של הפריסה, לוחצים על פעולות.

      יכול להיות שתצטרכו לגלול כדי לראות את הפעולות בשורה.

    2. בוחרים באפשרות הצגת יומני Cloud Build.

  3. בודקים את היומן של Cloud Build ופועלים בהתאם כדי לפתור את הבעיה שגרמה לכשל.

שגיאות בפריסה באמצעות Terraform CLI

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

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

שגיאה: ה-API לא מופעל

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

Error: Error creating Network: googleapi: Error 403: Compute Engine API has not
been used in project PROJECT_ID before or it is disabled. Enable it by visiting
https://console.developers.google.com/apis/api/compute.googleapis.com/overview?project=PROJECT_ID
then retry. If you enabled this API recently, wait a few minutes for the action
to propagate to our systems and retry.

אם השגיאה הזו מופיעה, צריך לחכות כמה דקות ואז להריץ שוב את הפקודה terraform apply.

שגיאה: אי אפשר להקצות את הכתובת המבוקשת

כשמריצים את הפקודה terraform apply, יכול להיות שתופיע שגיאה cannot assign requested address עם הודעה כמו זו:

Error: Error creating service account:
 Post "https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts:
 dial tcp [2001:db8:ffff:ffff::5f]:443:
 connect: cannot assign requested address

אם השגיאה הזו מופיעה, מריצים שוב את הפקודה terraform apply.

שגיאת הגדרה

אם לאחד מארגומנטי המשאב יש ערכים שלא נתמכים, תופיע שגיאה כמו זו שבהמשך:

Error: Error creating Instance: googleapi: Error 400: Provided Redis version is
not supported: REDIS_5_X
│ com.google.apps.framework.request.StatusException:
  <eye3 title='INVALID_ARGUMENT'/>
  generic::INVALID_ARGUMENT: Provided Redis version is not supported: REDIS_5_X
Details:
│ [
│   {
│     "@type": "type.googleapis.com/google.rpc.BadRequest",
│     "fieldViolations": [
│       {
│         "description": "Invalid value: REDIS_5_X",
│         "field": "instance.redis_version"
│       }
│     ]
│   }
│ ]
│
│   with google_redis_instance.main,
│   on main.tf line 96, in resource "google_redis_instance" "main":
│   96: resource "google_redis_instance" "main" {

במקרה הזה, הכוונה הייתה להשתמש ב-Redis גרסה 5, אבל הערך שצוין לארגומנט instance.redis_version (REDIS_5_X) בקובץ main.tf לא תקין. הערך הנכון הוא REDIS_5_0, כפי שמפורט במאמרי העזרה של ה-API בארכיטקטורת REST של Memorystore.

שגיאה במחיקת פריסה

במקרים מסוימים, יכול להיות שהניסיונות למחוק פריסה ייכשלו:

  • אחרי שמפעילים פתרון דרך המסוף, אם משנים משאב כלשהו שהוקצה על ידי הפתרון, ואז מנסים למחוק את הפריסה, יכול להיות שהמחיקה תיכשל. בשדה סטטוס בדף פריסות של פתרונות מופיע הערך נכשל, ובלוג של Cloud Build מופיע הגורם לשגיאה.
  • אחרי פריסת פתרון באמצעות Terraform CLI, אם משנים משאב כלשהו באמצעות ממשק שאינו Terraform (לדוגמה, המסוף), ואז מנסים למחוק את הפריסה, יכול להיות שהמחיקה תיכשל. ההודעות בפלט של הפקודה terraform destroy מציגות את הסיבה לשגיאה.

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

אם פריסה מבוססת-מסוף לא נמחקת ואם אי אפשר לאבחן את השגיאה באמצעות יומן Cloud Build, אפשר למחוק את הפריסה באמצעות Terraform CLI, כמו שמתואר בקטע הבא.

מחיקת פריסה שמבוססת על המסוף באמצעות Terraform CLI

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

  1. מזהים את האזור שבו מאוחסנים קוד ה-Terraform, היומנים ונתונים אחרים של הפריסה. יכול להיות שהאזור הזה יהיה שונה מהאזור שבחרתם כשפרסתם את הפתרון.

    1. נכנסים לדף Solution deployments במסוף Google Cloud .

      מעבר אל 'פריסות פתרונות'

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

    3. ברשימת הפריסות, מזהים את השורה של הפריסה שרוצים למחוק.

    4. לוחצים על הצגת כל התוכן בשורה.

    5. בעמודה מיקום, שימו לב למיקום השני, כפי שמודגש בדוגמה הבאה:

      המיקום של קוד הפריסה, היומנים ופריטים אחרים.

  2. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

    export REGION="REGION"
export PROJECT_ID="PROJECT_ID"
export DEPLOYMENT_NAME="DEPLOYMENT_NAME"

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

    • REGION: המיקום שציינתם קודם בהליך הזה.
    • ‫PROJECT_ID: מזהה הפרויקט שבו פרסתם את הפתרון.
    • ‫DEPLOYMENT_NAME: השם של הפריסה שרוצים למחוק.

  4. מאתרים את המזהה של הגרסה האחרונה של הפריסה שרוצים למחוק:

    export REVISION_ID=$(curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://config.googleapis.com/v1alpha2/projects/${PROJECT_ID}/locations/${REGION}/deployments/${DEPLOYMENT_NAME}" \
    | jq .latestRevision -r)
    echo $REVISION_ID

    הפלט אמור להיראות כך:

    projects/PROJECT_ID/locations/REGION/deployments/DEPLOYMENT_NAME/revisions/r-0

  5. מוצאים את המיקום ב-Cloud Storage של ההגדרות של Terraform לפריסה:

    export CONTENT_PATH=$(curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://config.googleapis.com/v1alpha2/${REVISION_ID}" \
    | jq .applyResults.content -r)
    echo $CONTENT_PATH

    הדוגמה הבאה היא של הפלט שמתקבל מהפקודה הזו:

    gs://PROJECT_ID-REGION-blueprint-config/DEPLOYMENT_NAME/r-0/apply_results/content

  6. מורידים את ההגדרות של Terraform מ-Cloud Storage אל Cloud Shell:

    gcloud storage cp $CONTENT_PATH $HOME --recursive
cd $HOME/content/

    ממתינים עד להצגת ההודעה Operation completed, כמו שמוצג בדוגמה הבאה:

    Operation completed over 45 objects/268.5 KiB

  7. מאתחלים את Terraform:

    terraform init

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

    Terraform has been successfully initialized!

  8. מסירים את המשאבים שנפרסו:

    terraform destroy

    ב-Terraform מוצגת רשימה של המשאבים שיוסרו.

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

  9. כשמופיעה בקשה לבצע את הפעולות, מזינים yes.

    ב-Terraform מוצגות הודעות שמראות את ההתקדמות. אחרי שכל המשאבים נמחקים, Terraform מציג את ההודעה הבאה:

    Destroy complete!

  10. מוחקים את פריט המידע שנוצר בתהליך פיתוח (Artifact) של הפריסה:

    curl -X DELETE \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://config.googleapis.com/v1alpha2/projects/${PROJECT_ID}/locations/${REGION}/deployments/${DEPLOYMENT_NAME}?force=true&delete_policy=abandon"

  11. ממתינים כמה שניות ואז מוודאים שפריט הפריסה נמחק:

    curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://config.googleapis.com/v1alpha2/projects/${PROJECT_ID}/locations/${REGION}/deployments/${DEPLOYMENT_NAME}" \
    | jq .error.message

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

    אחרי שמחיקת ארטיפקט הפריסה מסתיימת, מוצגת הודעה כמו בדוגמה הבאה:

    Resource 'projects/PROJECT_ID/locations/REGION/deployments/DEPLOYMENT_NAME' was not found

    12. שליחת משוב

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

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

    כדי לשלוח משוב:

    • כדי לשלוח משוב על מסמכי התיעוד, על מדריכים במסוף או על הפתרון, לוחצים על הלחצן שליחת משוב בדף.
    • אם לא שיניתם את קוד Terraform, אתם יכולים ליצור בעיות במאגר GitHub. אנחנו בודקים את הבעיות ב-GitHub כמיטב יכולתנו, והן לא מיועדות לשאלות כלליות על השימוש.
    • אם נתקלתם בבעיות במוצרים שבהם נעשה שימוש בפתרון, תוכלו לפנות אל Cloud Customer Care.

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

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