‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הצגת תנועה מכמה אזורים

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

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

אתם יכולים להגדיר מעבר אוטומטי למצב של יתירות כשל בין אזורים באמצעות Service Health של Cloud Run.

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

נכנסים לחשבון 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.

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.

הגדרת סביבת הפיתוח של Cloud Run בפרויקט ב- Google Cloud .
מתקינים ומפעילים את ה-CLI של gcloud.
מוודאים שבחשבון שלכם מוגדרים תפקידי ה-IAM הבאים:
- אדמין ב-Cloud Run‏ (roles/run.admin)
- אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin)
- Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)

מתן התפקידים

המסוף

נכנסים לדף IAM במסוף Google Cloud .
כניסה לדף IAM
בוחרים את הפרויקט.
לוחצים על Grant access.
בשדה New principals, מזינים את מזהה המשתמש. בדרך כלל זו כתובת האימייל בחשבון Google שמשמשת לפריסת שירות Cloud Run.
בוחרים תפקיד מהרשימה Select a role.
כדי לתת עוד תפקידים, לוחצים על Add another role ובוחרים את התפקידים הנוספים.
לוחצים על Save.

gcloud

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

        gcloud projects add-iam-policy-binding PROJECT_ID \
            --member=PRINCIPAL \
            --role=ROLE

מחליפים את:

‫PROJECT_NUMBER במספר הפרויקט ב- Google Cloud .
‫PROJECT_ID במזהה הפרויקט ב- Google Cloud .
PRINCIPAL עם החשבון שאליו מוסיפים את הקישור. בדרך כלל זו כתובת האימייל בחשבון Google שמשמשת לפריסת השירות של Cloud Run.
‫ROLE בתפקיד שאתם מוסיפים לחשבון הפריסה.

למחירון של Cloud Run כדי להעריך את העלויות בהתאם לשימוש הצפוי, אתם יכולים להשתמש במחשבון העלויות.
מפעילים את ממשקי ה-API הבאים: Artifact Registry, ‏ Cloud Build, ‏ Cloud Run Admin API, ‏ Compute Engine ו-Network Services API. כדי לעשות את זה, מריצים את הפקודה הבאה:

  gcloud services enable artifactregistry.googleapis.com \
    cloudbuild.googleapis.com \
    run.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

פריסת השירות בכמה אזורים

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

אתם פורסים את אותו שירות בכמה אזורים באחת מהשיטות הבאות:

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

פריסת שירות במספר אזורים

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

gcloud

כדי ליצור ולפרוס שירות בכמה אזורים, מריצים את הפקודה gcloud run deploy באמצעות הדגל --regions:
```
gcloud run deploy SERVICE_NAME \
  --image=IMAGE_URL \
  --regions=REGIONS
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: השם של השירות במספר אזורים שרוצים לפרוס.
- ‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/hello:latest.
- ‫REGIONS: רשימת האזורים שרוצים לפרוס בהם. לדוגמה, europe-west1,asia-east1.

YAML

יוצרים את קובץ ה-YAML של השירות, ומשתמשים במאפיין run.googleapis.com/regions כדי להגדיר את האזורים שבהם רוצים לפרוס את השירות:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
spec:
  template:
    spec:
      containers:
      - image: IMAGE_URL
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: השם של השירות במספר אזורים שאליו רוצים לפרוס.
- ‫REGIONS: רשימת האזורים שרוצים לעדכן. לדוגמה, europe-west1,asia-east1.
- ‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/hello:latest.
יוצרים את השירות באמצעות הפקודה הבאה:
```
gcloud run multi-region-services replace service.yaml
```

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מוסיפים את הקוד הבא למשאב google_cloud_run_v2_service בהגדרות של Terraform.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-multi-region"
  location = "global"

  multi_region_settings {
    regions = [
      "REGION_1",
      "REGION_2",
    ]
  }

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
  }
}

מחליפים את "REGION_1" ואת "REGION_2" בכל אחד מהאזורים הנדרשים ב-Google Cloud . לדוגמה, europe-west1 ו-us-central1.

עדכון שירות במספר אזורים

בקטע הזה מוסבר איך להוסיף או להסיר אזורים משירות בכמה אזורים באמצעות פקודה אחת של ה-CLI של gcloud או קובץ YAML.

gcloud

כדי להוסיף או להסיר אזורים משירות במספר אזורים, מריצים את הפקודה gcloud run multi-region-services update.

כדי להוסיף את השירות במספר אזורים לאזור אחד או יותר, משתמשים בדגל --add-regions:
```
gcloud run multi-region-services update SERVICE_NAME \
  --add-regions=REGIONS
```
כדי להסיר את השירות במספר אזורים מאזור אחד או יותר, משתמשים בדגל --remove-regions:
```
gcloud run multi-region-services update SERVICE_NAME \
  --remove-regions=REGIONS
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: השם של השירות במספר אזורים שרוצים לעדכן.
- ‫REGIONS: האזור או האזורים שרוצים להוסיף אליהם את השירות או להסיר מהם את השירות. לדוגמה, us-central1,asia-east1.

YAML

כדי לעדכן שירות קיים במספר אזורים, מורידים את הגדרת ה-YAML שלו:
```
gcloud run multi-region-services describe SERVICE_NAME --format export > service.yaml
```
מעדכנים את המאפיין run.googleapis.com/regions כדי להוסיף או להסיר את רשימת האזורים שבהם רוצים לפרוס את השירות:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/regions: REGIONS
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: השם של השירות במספר אזורים שרוצים לפרוס.
- ‫REGIONS: הרשימה החדשה של האזורים שאליהם רוצים לפרוס את גרסת השירות.
מעדכנים את השירות באמצעות הפקודה הבאה:
```
gcloud run multi-region-services replace service.yaml
```

מחיקת שירות במספר אזורים

כדי למחוק שירות בכמה אזורים, מריצים את הפקודה gcloud run multi-region-services delete:
```
gcloud run multi-region-services delete SERVICE_NAME
```
מחליפים את SERVICE_NAME בשם של השירות בכמה אזורים שרוצים למחוק.

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

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

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

כדי להגדיל את הזמינות של שירות במספר אזורים:

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

הגדרת קבוצות של נקודות קצה ברשת אזורית

בכל אזור שבו פרסתם את האפליקציה בשלב הקודם, צריך ליצור קבוצות של נקודות קצה ללא שרת (serverless) ברשת (NEG) לפי ההוראות הבאות:

‫CLI של gcloud

יוצרים קבוצה של נקודות קצה ברשת בשביל שירות Cloud Run ב-REGION:
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --region=REGION \
  --network-endpoint-type=serverless \
  --cloud-run-service=SERVICE_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NEG_NAME בשם של המשאב של קבוצת נקודות הקצה ברשת, לדוגמה myservice-neg-uscentral1.
- ‫REGION באזור שבו השירות פרוס.
- SERVICE_NAME בשם של השירות.
חוזרים על השלב הקודם בכל אזור.

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מגדירים קבוצה של נקודות קצה ברשת בשם myservice-neg לשירות Cloud Run לכל אזור שצוין במשתנה run_regions:

resource "google_compute_region_network_endpoint_group" "lb_default" {
  provider              = google-beta
  count                 = length(local.run_regions)
  name                  = "myservice-neg"
  network_endpoint_type = "SERVERLESS"
  region                = local.run_regions[count.index]
  cloud_run {
    service = google_cloud_run_v2_service.run_default[count.index].name
  }
}

יצירת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)

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

gcloud

שומרים כתובת IP סטטית כדי שלא תצטרכו לעדכן את רשומות ה-DNS כשתיצרו מחדש את מאזן העומסים.
```
gcloud compute addresses create --global SERVICE_IP
```
בפקודה שלמעלה, מחליפים את SERVICE_IP בשם של משאב כתובת ה-IP (למשל myservice-ip).
כתובת ה-IP הזו היא כתובת IPv4 גלובלית מסוג anycast, שמנתבת למרכז הנתונים של Google או לנקודת הנוכחות (PoP) הכי קרובה למבקרים.
יוצרים שירות לקצה העורפי.
```
gcloud compute backend-services create \
  --global BACKEND_NAME \
  --load-balancing-scheme=EXTERNAL_MANAGED
```
מחליפים את BACKEND_NAME בשם שרוצים לתת לשירות לקצה העורפי. לדוגמה, myservice-backend.
מוסיפים את קבוצת נקודות הקצה ברשת לשירות לקצה העורפי:
```
gcloud compute backend-services add-backend --global BACKEND_NAME 

  --network-endpoint-group-region=REGION 

  --network-endpoint-group=NEG_NAME
```
מציינים את ה-NEG_NAME שיצרתם בשלב הקודם לאזור.
יוצרים מפת URL.
```
gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME
```
מחליפים את URLMAP_NAME בשם שרוצים לתת למפת URL (למשל myservice-urlmap).
כדי להציג תנועת HTTPS, צריך ליצור אישור TLS מנוהל לדומיין. (מחליפים את example.com בשם הדומיין שלכם).
```
gcloud compute ssl-certificates create CERT_NAME \
  --domains=example.com
```
מחליפים את CERT_NAME בשם שרוצים לתת לאישור ה-SSL המנוהל (למשל myservice-cert).
יוצרים שרת proxy ל-HTTPS.
```
gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
  --ssl-certificates=CERT_NAME \
  --url-map=URLMAP_NAME
```
מחליפים את HTTPS_PROXY_NAME בשם שרוצים לתת לשרת ה-proxy ל-HTTPS (לדוגמה, myservice-https).
יוצרים כלל העברה שמקשר בין משאבי הרשת שיצרתם לבין כתובת ה-IP.
```
gcloud compute forwarding-rules create --global FORWARDING_RULE_NAME \
  --target-https-proxy=HTTPS_PROXY_NAME \
  --address=SERVICE_IP \
  --ports=443 \
  --load-balancing-scheme=EXTERNAL_MANAGED 
```
מחליפים את FORWARDING_RULE_NAME בשם של משאב כלל ההעברה שרוצים ליצור. לדוגמה, myservice-lb.

Terraform

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

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מגדירים את כתובת ה-IP:
```
resource "google_compute_global_address" "lb_default" {
  provider = google-beta
  name     = "myservice-service-ip"

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.compute_api
  ]
}
output "load_balancer_ip_addr" {
  value = google_compute_global_address.lb_default.address
}
```
מגדירה את שם המשאב של כתובת ה-IP בתור myservice-service-ip. אתם יכולים לשנות את הערך הזה לערך משלכם. כתובת ה-IP הזו היא כתובת IPv4 גלובלית מסוג anycast, שמנתבת למרכז הנתונים או ל-point of presence (PoP) של Google שהכי קרובים למבקרים שלכם.

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

resource "google_compute_backend_service" "lb_default" {
  provider              = google-beta
  name                  = "myservice-backend"
  load_balancing_scheme = "EXTERNAL_MANAGED"

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[0].id
  }

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[1].id
  }

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.compute_api,
  ]
}

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

מגדירים את מפת URL:

resource "google_compute_url_map" "lb_default" {
  provider        = google-beta
  name            = "myservice-lb-urlmap"
  default_service = google_compute_backend_service.lb_default.id

  path_matcher {
    name            = "allpaths"
    default_service = google_compute_backend_service.lb_default.id
    route_rules {
      priority = 1
      url_redirect {
        https_redirect         = true
        redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
      }
    }
  }
}

מקשר את המשאב של שירות לקצה העורפי (myservice-backend) למשאב החדש של מפת URL‏ (myservice-lb-urlmap). אתם יכולים לשנות את הערכים האלה לערכים משלכם.

כדי להציג תנועת HTTPS, צריך ליצור אישור TLS מנוהל לדומיין. מחליפים את example.com בשם הדומיין שלכם במשאב google_compute_managed_ssl_certificate:
```
resource "google_compute_managed_ssl_certificate" "lb_default" {
  provider = google-beta
  name     = "myservice-ssl-cert"

  managed {
    domains = ["example.com"]
  }
}
```

מגדירים את ה-Proxy ל-HTTPS:

resource "google_compute_target_https_proxy" "lb_default" {
  provider = google-beta
  name     = "myservice-https-proxy"
  url_map  = google_compute_url_map.lb_default.id
  ssl_certificates = [
    google_compute_managed_ssl_certificate.lb_default.name
  ]
  depends_on = [
    google_compute_managed_ssl_certificate.lb_default
  ]
}

יוצר משאב google_compute_target_https_proxy עם שם היעד myservice-https-proxy ומחבר את אישור ה-TLS (myservice-ssl-cert) ומשאבי מפת URL (myservice-lb-urlmap) שנוצרו קודם. אפשר לשנות אותם לערכים משלכם.

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

resource "google_compute_global_forwarding_rule" "lb_default" {
  provider              = google-beta
  name                  = "myservice-lb-fr"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  target                = google_compute_target_https_proxy.lb_default.id
  ip_address            = google_compute_global_address.lb_default.id
  port_range            = "443"
  depends_on            = [google_compute_target_https_proxy.lb_default]
}

יוצר משאב מסוג google_compute_global_forwarding_rule עם שם היעד myservice-https-proxy ומחבר את יעד ה-Proxy ל-HTTPS שנוצר קודם (myservice-https-proxy) ואת משאב כתובת ה-IP‏ (myservice-service-ip). אפשר לשנות את הערכים האלה לערכים משלכם.

החלת ההגדרה הזו:

כך מחילים את ההגדרות של Terraform בפרויקט ב- Google Cloud :

הכנת Cloud Shell
1. מפעילים את Cloud Shell.
2. מגדירים את פרויקט ברירת המחדל ב- Google Cloud שבו רוצים להחיל את ההגדרות של Terraform.
  
  תצטרכו להריץ את הפקודה הזו רק פעם אחת לכל פרויקט, ותוכלו לעשות זאת בכל ספרייה.
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
  אם תגדירו ערכים ספציפיים בקובץ התצורה של Terraform, הם יבטלו את ערכי ברירת המחדל של משתני הסביבה.
הכנת הספרייה

לכל קובץ תצורה של Terraform צריכה להיות ספרייה משלו (שנקראת גם מודול ברמה הבסיסית).
1. יוצרים ספרייה חדשה ב-Cloud Shell ובה יוצרים קובץ חדש. שם הקובץ חייב לכלול את הסיומת .tf, למשל main.tf. במדריך הזה, הקובץ נקרא main.tf.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
2. אם אתם עוקבים אחרי המדריך, תוכלו להעתיק את הקוד לדוגמה בכל קטע או שלב.
  
  מעתיקים את הקוד לדוגמה בקובץ main.tf החדש שיצרתם.
  
  לחלופין, אפשר גם להעתיק את הקוד מ-GitHub. כדאי לעשות את זה כשקטע הקוד של Terraform הוא חלק מפתרון מקצה לקצה.
3. בודקים את הפרמטרים לדוגמה ומשנים אותם בהתאם לסביבה שלכם.
4. שומרים את השינויים.
5. מפעילים את Terraform. צריך לעשות זאת רק פעם אחת לכל ספרייה.
```
terraform init
```
  אופציונלי: תוכלו לכלול את האפשרות -upgrade, כדי להשתמש בגרסה העדכנית ביותר של הספק של Google:
```
terraform init -upgrade
```
החלה של השינויים
1. בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם:
```
terraform plan
```
  מתקנים את ההגדרות לפי הצורך.
2. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform:
```
terraform apply
```
  ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!‎".
3. פותחים את הפרויקט ב- Google Cloud כדי להציג את התוצאות. במסוף Google Cloud , נכנסים למשאבים בממשק המשתמש כדי לוודא שהם נוצרו או עודכנו ב-Terraform.
הערה: בדרך כלל הנחת העבודה בדוגמאות של Terraform היא שממשקי ה-API הנדרשים מופעלים בפרויקט ב- Google Cloud .

הגדרת קבוצות של נקודות קצה ברשת אזורית

בכל אזור שבו פרסתם את האפליקציה בשלב הקודם, צריך ליצור קבוצות של נקודות קצה ברשת (NEG) ללא שרת ולהוסיף אותן לשירות לקצה העורפי לפי ההוראות הבאות:

‫CLI של gcloud

יוצרים קבוצה של נקודות קצה ברשת בשביל שירות Cloud Run ב-REGION:
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --region=REGION \
  --network-endpoint-type=serverless \
  --cloud-run-service=SERVICE_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NEG_NAME בשם של המשאב של קבוצת נקודות הקצה ברשת. (לדוגמה, myservice-neg-uscentral1)
- ‫REGION באזור שבו השירות פרוס.
- SERVICE_NAME בשם של השירות.
מוסיפים את קבוצת נקודות הקצה ברשת לשירות לקצה העורפי:
```
gcloud compute backend-services add-backend --global BACKEND_NAME \
  --network-endpoint-group-region=REGION \
  --network-endpoint-group=NEG_NAME
```
מציינים את ה-NEG_NAME שיצרתם בשלב הקודם לאזור.
חוזרים על השלבים הקודמים בכל אזור.

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מגדירים קבוצה של נקודות קצה ברשת בשם myservice-neg לשירות Cloud Run בכל אזור שצוין במשתנה run_regions:

resource "google_compute_region_network_endpoint_group" "lb_default" {
  provider              = google-beta
  count                 = length(local.run_regions)
  name                  = "myservice-neg"
  network_endpoint_type = "SERVERLESS"
  region                = local.run_regions[count.index]
  cloud_run {
    service = google_cloud_run_v2_service.run_default[count.index].name
  }
}

מגדירים שירות לקצה העורפי כדי לצרף את קבוצת נקודות הקצה ברשת (myservice-neg):

resource "google_compute_backend_service" "lb_default" {
  provider              = google-beta
  name                  = "myservice-backend"
  load_balancing_scheme = "EXTERNAL_MANAGED"

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[0].id
  }

  backend {
    group = google_compute_region_network_endpoint_group.lb_default[1].id
  }

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.compute_api,
  ]
}

הגדרת רשומות DNS בדומיין

כדי להפנות את שם הדומיין לכלל ההעברה שיצרתם, צריך לעדכן את רשומות ה-DNS שלו עם כתובת ה-IP שיצרתם.

מריצים את הפקודה הבאה כדי למצוא את כתובת ה-IP השמורה של מאזן העומסים:
```
gcloud compute addresses describe SERVICE_IP \
  --global \
  --format='value(address)'
```
מחליפים את SERVICE_IP בשם של כתובת ה-IP שיצרתם קודם. הפקודה הזו מדפיסה את כתובת ה-IP לפלט.
צריך לעדכן את רשומות ה-DNS של הדומיין על ידי הוספה של רשומת A עם כתובת ה-IP הזו.

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

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

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

המתנה להקצאת מאזן העומסים

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

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

כשהוא יהיה מוכן, אפשר יהיה לנסות אותו בכתובת ה-URL של האתר עם הקידומת https://.

אמת את הסטטוס

כדי לבדוק את הסטטוס של הפצת רשומת ה-DNS, משתמשים בכלי שורת הפקודה dig:
```
dig A +short example.com
```
בפלט מוצגת כתובת ה-IP שהגדרתם ברשומות ה-DNS.
כדי לבדוק את סטטוס ההנפקה של האישור המנוהל, מריצים את הפקודה הבאה:
```
gcloud compute ssl-certificates describe CERT_NAME
```
מחליפים את CERT_NAME בשם שבחרתם קודם למשאב של אישור ה-SSL.

בפלט תופיע שורה עם הערך status: ACTIVE.

הגדרת הפניה אוטומטית מ-HTTP ל-HTTPS

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

‫CLI של gcloud

יוצרים מפת URL עם כלל הפניה אוטומטית.

gcloud compute url-maps import HTTP_URLMAP_NAME \
  --global \
  --source /dev/stdin <<EOF
        name: HTTP_URLMAP_NAME
        defaultUrlRedirect:
          redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
          httpsRedirect: True
        EOF

מחליפים את HTTP_URLMAP_NAME בשם של משאב מפת URL שתיצרו (לדוגמה, myservice-httpredirect).

יוצרים שרת proxy ל-HTTP עם מפת URL.
```
gcloud compute target-http-proxies create HTTP_PROXY_NAME \
  --url-map=HTTP_URLMAP_NAME
```
מחליפים את HTTP_PROXY_NAME בשם של שרת ה-Proxy ל-HTTP עם היעד שתיצרו (לדוגמה, myservice-http).
יוצרים כלל העברה ביציאה 80 עם אותה כתובת IP שמורה.
```
gcloud compute forwarding-rules create --global HTTP_FORWARDING_RULE_NAME \
  --target-http-proxy=HTTP_PROXY_NAME \
  --address=SERVICE_IP \
  --ports=80
        
```
מחליפים את HTTP_FORWARDING_RULE_NAME בשם של כלל ההעברה החדש שתיצרו (לדוגמה, myservice-httplb).

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

יוצרים משאב של מפת URL עם כלל הפניה אוטומטית:

resource "google_compute_url_map" "https_default" {
  provider = google-beta
  name     = "myservice-https-urlmap"

  default_url_redirect {
    redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
    https_redirect         = true
    strip_query            = false
  }
}

יוצרים שרת proxy ל-HTTP עם יעד, באמצעות המשאב החדש של מפת URL ‏ (myservice-https-urlmap):

resource "google_compute_target_http_proxy" "https_default" {
  provider = google-beta
  name     = "myservice-http-proxy"
  url_map  = google_compute_url_map.https_default.id

  depends_on = [
    google_compute_url_map.https_default
  ]
}

יוצרים כלל העברה ביציאה 80 עם אותו משאב של כתובת IP שמורה (myservice-http-proxy):

resource "google_compute_global_forwarding_rule" "https_default" {
  provider   = google-beta
  name       = "myservice-https-fr"
  target     = google_compute_target_http_proxy.https_default.id
  ip_address = google_compute_global_address.lb_default.id
  port_range = "80"
  depends_on = [google_compute_target_http_proxy.https_default]
}

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

איך להגדיר יתירות כשל אוטומטית בין אזורים באמצעות Service Health של Cloud Run

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

שימוש במינויי דחיפה מאומתים של Pub/Sub עם פריסה במספר אזורים

כברירת מחדל, שירות Pub/Sub מעביר הודעות לנקודות קצה (endpoints) של Push באותו אזור ב- Google Cloud שבו השירות מאחסן את ההודעות. כדי לעקוף את הבעיה הזו, אפשר לעיין במאמר שימוש במינוי דחיפה מאומת של Pub/Sub עם פריסה של Cloud Run בכמה אזורים.

הגדרה של יתירות כשל ידנית

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

כדי לעדכן את מפת כתובות ה-URL של מאזן העומסים הגלובלי החיצוני של אפליקציות, מסירים את ה-NEG משירות הקצה העורפי באמצעות הדגל --global:
```
gcloud compute backend-services remove-backend BACKEND_NAME \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-region=REGION \
--global
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BACKEND_NAME: השם של שירות הקצה העורפי.
- ‫NEG_NAME: השם של משאב קבוצת נקודות הקצה ברשת, לדוגמה myservice-neg-uscentral1.
- ‫REGION: האזור שבו נוצרה קבוצת ה-NEG ושממנו רוצים להסיר את השירות. לדוגמה, us-central1,asia-east1.
כדי לוודא שהאזור התקין מטפל עכשיו בתנועה, נכנסים לכתובת https://<domain-name>.

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

איך מגדירים בדיקות תקינות לשירותי Cloud Run, כולל בדיקות מוכנות.

דוגמת קוד ב-Go לבדיקת מוכנות של Cloud Run ולבדיקת Service Health.

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

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

מתן התפקידים

המסוף

gcloud

פריסת השירות בכמה אזורים

פריסת שירות במספר אזורים

gcloud

YAML

Terraform

עדכון שירות במספר אזורים

gcloud

YAML

מחיקת שירות במספר אזורים

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

הגדרת קבוצות של נקודות קצה ברשת אזורית

‫CLI של gcloud

Terraform

יצירת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)

gcloud

Terraform

הכנת Cloud Shell

הכנת הספרייה

החלה של השינויים

הגדרת קבוצות של נקודות קצה ברשת אזורית

‫CLI של gcloud

Terraform

הגדרת רשומות DNS בדומיין

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

המתנה להקצאת מאזן העומסים

אמת את הסטטוס

הגדרת הפניה אוטומטית מ-HTTP ל-HTTPS

‫CLI של gcloud

Terraform

איך להגדיר יתירות כשל אוטומטית בין אזורים באמצעות Service Health של Cloud Run

שימוש במינויי דחיפה מאומתים של Pub/Sub עם פריסה במספר אזורים

הגדרה של יתירות כשל ידנית

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

הצגת תנועה מכמה אזורים