פתרון Jump Start: פלטפורמת מסחר אלקטרוני עם מחשוב ללא שרת

Last reviewed 2023-08-24 UTC

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

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

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

מטרות

המדריך הזה יעזור לכם:

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

מוצרים

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

  • ‫Cloud Run: שירות שמנוהל במלואו שמאפשר לכם לפתח ולפרוס אפליקציות בקונטיינרים ללא שרת.‏ Google Cloud מטפל בהתאמה לעומס ובמשימות אחרות שקשורות לתשתית, כדי שתוכלו להתמקד בלוגיקה העסקית של הקוד.
  • ‫Cloud SQL: מסד נתונים של PostgreSQL מבוסס-ענן שמנוהל באופן מלא בתשתית של Google Cloud .
  • ‫Secret Manager: שירות שמאפשר לאחסן, לנהל ולגשת לסודות כ-blob בינארי או כמחרוזות טקסט. אתם יכולים להשתמש ב-Secret Manager כדי לאחסן סיסמאות למסדי נתונים, מפתחות API או אישורי TLS שנדרשים לאפליקציה בזמן הריצה.
  • ‫Cloud Storage: שירות שמוכן לשימוש בארגונים ומספק אחסון אובייקטים ללא הגבלה בעלות נמוכה למגוון סוגי נתונים. הגישה לנתונים אפשרית מתוך Google Cloud ומחוצה לו, והם משוכפלים עם יתירות גיאוגרפית.
  • אירוח ב-Firebase: שירות אירוח מנוהל במלואו לפריסה ולהצגה של אפליקציות אינטרנט ותוכן סטטי.
  • ‫Cloud Logging: שירות שמאפשר לכם לאחסן, לחפש, לנתח, לעקוב ולקבל התראות לגבי נתונים ואירועים ביומן מ- Google Cloud ומעננים אחרים.
  • ‫Cloud Trace: מערכת מעקב מבוזרת שעוזרת להבין כמה זמן לוקח לאפליקציה לטפל בבקשות נכנסות ממשתמשים או מאפליקציות אחרות, וכמה זמן לוקח להשלים פעולות כמו קריאות RPC שמתבצעות במהלך הטיפול בבקשות. Google Cloud
  • ‫Error Reporting: השירות הזה מצבר ומציג שגיאות שנוצרות בשירותי הענן הפועלים שלכם. ‫Error Reporting מקבץ שגיאות שנחשבות לכאלה שנובעות מאותה סיבה בסיסית.

ארכיטקטורה

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

אפליקציית אינטרנט למסחר אלקטרוני שנפרסה באמצעות Cloud Run

תהליך הבקשה

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

  1. קצה קדמי של לקוח אירוח ב-Firebase. החלק הקדמי של האפליקציה משתמש ב-Lit וברכיבי אינטרנט לעיבוד בצד הלקוח של נתוני ה-API.
  2. לקוח האינטרנט שולח קריאה לעורף ה-API שפועל כשירות Cloud Run. שרת ה-API של Cloud Run כתוב ב-Django באמצעות Django REST Framework.
  3. ההגדרות וסודות אחרים של אפליקציית Python מאוחסנים ב-Secret Manager.
  4. נכסים סטטיים של האפליקציה מאוחסנים ב-Cloud Storage.
  5. מסד נתונים של Cloud SQL, באמצעות PostgreSQL, משמש כמסד נתונים רלציוני בקצה העורפי של אפליקציית Python.
  6. ב-Cloud Logging, ב-Cloud Trace וב-Error Reporting נשמרים יומנים, עקבות של OpenTelemetry ודוחות שגיאות שנשלחים ממוצרי ענן אחרים ומשרת ה-API של Cloud Run. הנתונים האלה מאפשרים לעקוב אחרי התנהגות האפליקציה ולפתור בעיות בהתנהגות לא צפויה.

עלות

כדי לקבל הערכה של עלות המשאבים שבהם נעשה שימוש בפלטפורמת המסחר האלקטרוני עם פתרון מחשוב בלי שרת (serverless computing), אפשר לעיין בהערכה שחושבה מראש ב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 יזדקק למידע הזה.

פריסת הפתרון

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

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

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

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

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

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

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

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

  1. בקטלוג Google Cloud Jump Start Solutions, עוברים לפתרון פלטפורמה למסחר אלקטרוני עם מחשוב ללא שרת.

    מעבר לפלטפורמת המסחר האלקטרוני עם פתרון מחשוב בלי שרת (serverless computing)

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

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

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

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

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

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

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

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

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

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

  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-dynamic-python-webapp/infra. זו הספרייה שמכילה את קובצי ההגדרות של Terraform לפתרון. אם אתם צריכים לעבור לספרייה הזו, מריצים את הפקודה הבאה:

    cd $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra

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

    terraform init

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

    Terraform has been successfully initialized!

הגדרת משתני Terraform

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

  1. מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra. אם לא, עוברים לספרייה הזו.

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

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

    • פועלים לפי ההוראות שמופיעות כהערות בקטע הקוד.
    • קטע הקוד הזה כולל רק את המשתנים שחובה להגדיר להם ערכים. התצורה של Terraform כוללת משתנים אחרים עם ערכי ברירת מחדל. כדי לבדוק את כל המשתנים ואת ערכי ברירת המחדל, אפשר לעיין בקובץ variables.tf שזמין בספרייה $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra.

    • חשוב לוודא שכל ערך שמוגדר בקובץ 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"

# Container Registry that hosts the client image
client_image_host = "hsa-public/serverless-ecommerce"

# Container Registry that hosts the server image
server_image_host = "hsa-public/serverless-ecommerce"

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

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

  1. מוודאים שספריית העבודה הנוכחית היא $HOME/cloudshell_open/terraform-dynamic-python-webapp/infra. אם לא, עוברים לספרייה הזו.

  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-dynamic-python-webapp/infra. אם לא, עוברים לספרייה הזו.

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

    terraform apply

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

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

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

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

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

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

    Apply complete!

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

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

    התחלת הסיור

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

עיון בפריסת Avocano

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

מה זה Avocano?

הפתרון הזה משתמש באפליקציה לדוגמה בשם Avocano כדי להדגים את ה-Deployment (פריסה) והניהול של אפליקציית אינטרנט עם הרבה מהכלים והמוצרים שמשמשים לאפליקציות בלי שרת (serverless). ‫Avocano היא אפליקציה שמדמה הטמעה בעולם האמיתי של אפליקציית מסחר אלקטרוני באינטרנט.

הקצה הקדמי של Avocano מציג חנות וירטואלית מזויפת, שבה אפשר להוסיף פריטים לעגלת הקניות ולנסות להשלים את תהליך התשלום, אבל אז מתגלה שהחנות מזויפת (Avoca--no!). אי אפשר לקנות אבוקדו, אבל האפליקציה מדגימה ניהול מלאי על ידי הפחתת כמות המוצרים הזמינים באחד.

דף הנחיתה של Avocano

היכרות עם הקצה הקדמי

כדי להפעיל את הקצה הקדמי של פריסת הפתרון:

  1. פותחים את מסוף Firebase.
  2. בוחרים את הפרויקט הקיים.
  3. עוברים לקטע Build > Hosting (פיתוח > אירוח).
  4. בוחרים באפשרות Domain (דומיין) שמסתיימת ב-web.app. הקצה הקדמי של אפליקציית הדוגמה ייפתח בחלון דפדפן חדש.

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

צפייה בהגדרות של התאמה לעומס (autoscaling) ושל מספר הפעולות בו-זמנית

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

הסבר על ההגדרות של התאמה אוטומטית לעומס (autoscaling) ושל פעולות בו-זמניות

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

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

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

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

הצגת הגדרות של התאמה לעומס (autoscaling) ושל מספר הבקשות המקבילות

כדי לראות את ההגדרות הנוכחיות של מספר המכונות המינימלי והמקסימלי ואת הגדרות הבו-זמניות (concurrency) בשירות Cloud Run:

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

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

צפייה ביומני תעבורת נתונים

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

כדי לראות את היומנים של שירות Cloud Run:

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

ב-Cloud Run, יומנים נשמרים באופן אוטומטי ממקומות רבים: כל מה שנכתב ב-standard out וב-standard error, כל מה שנמצא ב-/var/log/ ועוד. גם רישום ידני שמתבצע באמצעות ספריות Cloud Logging נרשם. אפשר גם לראות את היומנים של השירות הזה ישירות ב-Cloud Logging. לשם כך, לוחצים על הצגה ב-Logs Explorer.

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

פעולת משתמש פלט של יומן
הרכישה של עגלת הקניות מתבצעת באמצעות איסוף כאמצעי התשלום, וכמות המוצרים בעגלה לא עולה על מספר הפריטים במלאי. פלט היומן מציג יומן info, עם סטטוס httpRequest של 200.
הלקוח רוכש את עגלת הקניות באמצעות אמצעי התשלום Collect, אבל סכום המוצרים בעגלה גבוה ממספר הפריטים במלאי. פלט היומן מציג יומן אזהרה, עם סטטוס httpRequest של 400.
רוכשים את עגלת הקניות באמצעות Credit כסוג התשלום. פלט היומן מציג יומן Error, עם סטטוס httpRequest של 501.

אפשר לראות את הקוד שגורם לשגיאה שמובילה לתגובת ה-HTTP‏ 400/501 בקובץ serializers.py. ‫Cloud Run מציין את התגובה ויוצר רשומה תואמת ביומן הבקשות.

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

הצגת אינסטרומנטציית מעקב ופרטי מעקב שנאספו

הפתרון הזה משתמש באינסטרומנטציה אוטומטית של Open Telemetry Python כדי לתעד נתוני טלמטריה עבור אפליקציית Avocano.

הסבר על הטמעה של מעקב

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

  1. מוסיפים יחסי תלות ל-Cloud Trace בקובץ requirements.txt, כולל השורות הבאות:
    • ‫opentelemetry-distro: מתקין את Open Telemetry API,‏ SDK וכלי שורת פקודה.
    • ‫opentelemetry-instrumentation: נוספה תמיכה בהגדרה אוטומטית של Python.
    • ‫opentelemetry-exporter-gcp-trace: מספק תמיכה בייצוא של עקבות ל-Cloud Trace.
    • ‫opentelemetry-resource-detector: מספק תמיכה בזיהוי משאבים Google Cloud .
    • ‫opentelemetry-instrumentation-django: מאפשר מעקב אחר בקשות לאפליקציית Django.
  2. מגדירים את הקישור ב-IAM בקובץ iam.tf כדי לאפשר לשרת לכתוב ל-Cloud Trace.
  3. מגדירים את משתנה הסביבה OTEL_TRACES_EXPORTER בקובץ services.tf כדי להשתמש ב-exporter ל-Cloud Trace.
  4. ב-server/Procfile, מגדירים את השרת להפעלת הפקודה opentelemetry-instrument באפליקציית Avocano. הפקודה הזו מזהה חבילות ב-Avocano ומחיל עליהן אינסטרומנטציה אוטומטית למעקב, אם אפשר.

מידע נוסף על איסוף נתונים של Cloud Trace עבור Python זמין במאמר בנושא Python ו-OpenTelemetry.

הצגת נתוני זמן ההמתנה לתגובה

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

  1. כניסה ל-Cloud Trace
  2. בקטע Select a trace בדף Trace list, לוחצים על הנקודה הכחולה שמייצגת את הנתונים שנאספו. בעמודה חביון מוצג החביון של העקבות שתועדו.

אפשר גם לראות את נתוני העקבות באמצעות אמצעי הוויזואליזציה הבאים בדף רשימת העקבות:

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

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

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

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

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

שיפור האבטחה

עיצוב המלצות
הצפנת נתונים

כברירת מחדל, Cloud Run מצפין נתונים באמצעות Google-owned and Google-managed encryption key. כדי להגן על הקונטיינרים באמצעות מפתח שאתם שולטים בו, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח. מידע נוסף מופיע במאמר בנושא שימוש במפתחות הצפנה בניהול הלקוח.

אבטחת שרשרת האספקה של תוכנות כדי לוודא שרק קובצי אימג' מורשים של קונטיינרים נפרסים בשירותי Cloud Run, אפשר להשתמש ב-Binary Authorization.

שיפור האמינות

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

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

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

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

מכונת Cloud SQL בפתרון הזה משתמשת בסוג המכונה db-custom-2-4096, שכוללת שני מעבדים עם זיכרון של 4GB. סוג המכונה הזה נועד לספק משאבים למסד נתונים בעלות נמוכה, שיכול להתאים רק לסביבות בדיקה ופיתוח. אם אתם צריכים אמינות ברמת הייצור, כדאי להשתמש בסוג מכונה שמספק יותר CPU וזיכרון.

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

מכסות ומגבלות

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

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

אופטימיזציה של העלויות

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

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

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

שיפור הביצועים

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

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

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

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

  • לפני שמבצעים שינויים בעיצוב, חשוב להעריך את ההשפעה על העלויות ולשקול את הפשרות הפוטנציאליות עם תכונות אחרות. אפשר להשתמש ב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-dynamic-python-webapp/infra. אם לא, עוברים לספרייה הזו.

  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.

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

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

  • אחרי שמפעילים פתרון דרך המסוף, אם משנים משאב כלשהו שהוקצה על ידי הפתרון, ואז מנסים למחוק את הפריסה, יכול להיות שהמחיקה תיכשל. בשדה סטטוס בדף פריסות של פתרונות מופיע הערך נכשל, ובלוג של 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/infra

    ממתינים עד להצגת ההודעה 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.

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

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

    • אם הקוד לא שונה, צריך ליצור בעיות במאגר המתאים ב-GitHub:

      אנחנו בודקים את הבעיות ב-GitHub כמיטב יכולתנו, והן לא מיועדות לשאלות כלליות על השימוש.

    • אם נתקלתם בבעיות במוצרים שבהם נעשה שימוש בפתרון, תוכלו לפנות אל Cloud Customer Care.

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

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