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

במסמך הזה מוצגות שתי הגדרות לדוגמה שלregional internal Application Load Balancer בסביבת VPC משותף עם קטגוריות של Cloud Storage:

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

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

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

אם אתם לא רוצים להשתמש ברשת VPC משותפת, אפשר לעיין במאמר בנושא הגדרת regional internal Application Load Balancer עם קטגוריות של Cloud Storage.

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

חשוב לוודא שההגדרה עומדת בדרישות המוקדמות הבאות.

יצירת Google Cloud פרויקטים

יוצרים Google Cloud פרויקטים למארח אחד ולשני פרויקטים של שירותים.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להגדרת regional internal Application Load Balancer בסביבת VPC משותף עם קטגוריות של Cloud Storage, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

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

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

הגדרת סביבת VPC משותפת

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

  1. מגדירים את רשת ה-VPC בפרויקט המארח.
  2. מגדירים את רשת המשנה של ה-proxy בלבד בפרויקט המארח.
  3. מגדירים כלל לחומת האש בפרויקט המארח.
  4. הגדרת VPC משותף בפרויקט המארח.

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

בדוגמה הזו נעשה שימוש ברשת VPC, באזור ובתת-רשת של פרוקסי בלבד:

  • רשת. הרשת היא רשת VPC במצב מותאם אישית בשם lb-network.

  • רשת משנה למאזן העומסים. רשת משנה בשם subnet-us באזור us-east1 משתמשת ב-10.1.2.0/24 כטווח ה-IP הראשי שלה.

  • רשת משנה עבור שרתי proxy של Envoy. רשת משנה בשם proxy-only-subnet-us באזור us-east1 משתמשת ב-10.129.0.0/23 לטווח ה-IP הראשי שלה.

הגדרת VPC לפרויקט המארח

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

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

המסוף

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על יצירת רשת VPC.

  3. בשדה שם מזינים lb-network.

  4. בקטע Subnet creation mode (מצב יצירת רשת משנה), בוחרים באפשרות Custom (בהתאמה אישית).

  5. בקטע New subnet (רשת משנה חדשה), מציינים את הפרטים הבאים:

    1. בשדה שם מזינים subnet-us.
    2. ברשימה Region בוחרים באזור us-east1.
    3. בשדה טווח IPv4, מזינים 10.1.2.0/24
    4. לוחצים על סיום.

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

gcloud

  1. יוצרים רשת VPC מותאמת אישית בשם lb-network באמצעות הפקודה gcloud compute networks create.

    gcloud compute networks create lb-network \
    --subnet-mode=custom \
    --project=HOST_PROJECT_ID

    מחליפים את HOST_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט שמופעל כפרויקט מארח בסביבת VPC משותף.

  2. יוצרים תת-רשת ברשת ה-VPC‏ lb-network באזור us-east1 באמצעות הפקודה gcloud compute networks subnets create.

    gcloud compute networks subnets create subnet-us \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-east1 \
    --project=HOST_PROJECT_ID

הגדרת רשת המשנה של ה-proxy בפרויקט המארח

תת-רשת של פרוקסי בלבד מספקת קבוצה של כתובות IP ש- Google Cloud משתמש בהן כדי להפעיל פרוקסי של Envoy בשמכם. הפרוקסיים מסיימים חיבורים מהלקוח ויוצרים חיבורים חדשים לשרתי הקצה.

כל מאזני העומסים האזוריים שמבוססים על Envoy באותו אזור כמו רשת ה-VPC משתמשים בתת-הרשת הזו שמוגדרת ל-proxy בלבד. יכולה להיות רק תת-רשת פעילה אחת של פרוקסי בלבד לכל מטרה נתונה, לכל אזור ולכל רשת. בדוגמה הזו, אנחנו יוצרים רשת משנה של proxy בלבד באזור us-east1.

המסוף

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על השם של רשת ה-VPC שיצרתם.

  3. בכרטיסייה Subnets (רשתות משנה), לוחצים על Add subnet (הוספת רשת משנה) ומזינים את הפרטים הבאים:

    1. בשדה שם מזינים proxy-only-subnet-us.
    2. ברשימה Region בוחרים באזור us-east1.
    3. בשדה מטרה, בוחרים באפשרות Regional Managed Proxy.
    4. בשדה טווח IPv4, מזינים 10.129.0.0/23.

  4. לוחצים על הוספה.

gcloud

  • יוצרים תת-רשת לשרת proxy בלבד באזור us-east1 באמצעות הפקודה gcloud compute networks subnets create.

    gcloud compute networks subnets create proxy-only-subnet-us \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-east1 \
    --network=lb-network \
    --range=10.129.0.0/23 \
    --project=HOST_PROJECT_ID

הגדרת כלל לחומת האש בפרויקט המארח

בדוגמה הזו נעשה שימוש בכלל חומת האש fw-allow-ssh שמאפשר קישוריות SSH נכנסת ביציאת TCP‏ 22 מכל כתובת. אפשר לבחור טווח כתובות IP של מקור שהוא יותר מגביל עבור הכלל הזה. לדוגמה, אפשר לציין רק את טווחי כתובות ה-IP של המערכת שממנה מתחילים סשנים של SSH. בדוגמה הזו נעשה שימוש בתג היעד allow-ssh כדי לזהות את המכונות הווירטואליות (VM) שכלל חומת האש חל עליהן. בלי כללי חומת האש האלה, הכלל default deny ingress חוסם תנועה נכנסת למופעי ה-Backend.

המסוף

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

    לדף Firewall policies

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

  3. עליך לספק את הפרטים הבאים:

    1. בשדה שם מזינים fw-allow-ssh.
    2. ברשימה Network בוחרים באפשרות lb-network.
    3. בשדה כיוון התנועה, בוחרים באפשרות תנועה נכנסת.
    4. בקטע פעולה בהתאמה, בוחרים באפשרות אישור.
    5. ברשימה Targets (יעדים), בוחרים באפשרות Specified target tags (תגי יעד ספציפיים).
    6. בשדה Target tags (תגי יעד), מזינים allow-ssh.
    7. ברשימה Source filter בוחרים באפשרות IPv4 ranges.
    8. בשדה Source IPv4 ranges (טווחי כתובות IPv4 של המקור), מזינים 0.0.0.0/0.
    9. בקטע פרוטוקולים ויציאות, בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
    10. מסמנים את תיבת הסימון TCP ומזינים 22 כמספר היציאה.

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

gcloud

  • יוצרים את כלל חומת האש fw-allow-ssh כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh. אם לא מציינים את source-ranges,‏Google Cloud מפרש את הכלל כאילו הוא מתייחס לכל מקור.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22 \
    --project=HOST_PROJECT_ID

הגדרת VPC משותף בפרויקט המארח

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

  1. הפעלת פרויקט מארח
  2. צירוף פרויקט שירות.

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

הגדרת מאזן עומסים בפרויקט השירות

בדוגמה הזו נוצרת regional internal Application Load Balancer שבה כל רכיבי איזון העומסים (כלל העברה, שרת proxy ביעד, מפת URL וקטגוריית קצה עורפי) וקטגוריות Cloud Storage נוצרים בפרויקט השירות.

משאבי הרשת של regional internal Application Load Balancer, כמו תת-הרשת של ה-proxy בלבד, נוצרים בפרויקט המארח.

Figure 1. מאזן עומסים חיצוני אזורי מסוג HTTP בסביבת VPC משותף עם קטגוריות של Cloud Storage
איור 1. מאזן עומסים פנימי אזורי של אפליקציות (ALB) בסביבת VPC משותף עם קטגוריות של Cloud Storage

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

בדוגמאות שבדף הזה מוגדרת במפורש כתובת IP שמורה לכלל ההעברה של regional internal Application Load Balancer, במקום לאפשר הקצאה של כתובת IP זמנית. מומלץ להקצות כתובות IP לכללי העברה.

הגדרת קטגוריות של Cloud Storage

תהליך ההגדרה של קטגוריות Cloud Storage הוא כדלקמן:

  1. יוצרים את הקטגוריות של Cloud Storage.
  2. מעתיקים את התוכן לקטגוריות.
  3. הגדרת הקטגוריות כקריאות באופן ציבורי.

יצירת קטגוריות ב-Cloud Storage

בדוגמה הזו, יוצרים שתי קטגוריות של Cloud Storage באזור us-east1.

המסוף

  1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.

    כניסה לדף Buckets

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

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

  4. לוחצים על בחירת המיקום לאחסון הנתונים.

  5. מגדירים את סוג המיקום לאזור.

  6. ברשימת האזורים, בוחרים באפשרות us-east1.

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

  8. לוחצים על Buckets כדי לחזור לדף Cloud Storage Buckets. פועלים לפי ההוראות הקודמות כדי ליצור קטגוריה שנייה באזור us-east1.

gcloud

  • יוצרים את הקטגוריות באזור us-east1 באמצעות הפקודה gcloud storage buckets create.

    gcloud storage buckets create gs://BUCKET1_NAME \
   --default-storage-class=standard \
   --location=us-east1 \
   --uniform-bucket-level-access \
   --project=SERVICE_PROJECT_ID

    gcloud storage buckets create gs://BUCKET2_NAME \
    --default-storage-class=standard \
    --location=us-east1 \
    --uniform-bucket-level-access \
    --project=SERVICE_PROJECT_ID

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

    • ‫BUCKET1_NAME: השם של הקטגוריה הראשונה שלכם ב-Cloud Storage
    • ‫BUCKET2_NAME: השם של הקטגוריה השנייה של Cloud Storage
    • ‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות

העתקת תוכן לקטגוריות של Cloud Storage

כדי לאכלס את הקטגוריות של Cloud Storage, מעתיקים קובץ גרפי מקטגוריה ציבורית של Cloud Storage לקטגוריות שלכם ב-Cloud Storage.

gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/

gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

הגדרת קטגוריות של Cloud Storage כקריאות באופן ציבורי

כדי שכל האובייקטים בקטגוריה יהיו קריאים לכולם באינטרנט הציבורי, צריך להעניק לחשבון הראשי allUsers את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer).

המסוף

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

  1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.

    כניסה לדף Buckets

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

  3. לוחצים על הלחצן Permissions (הרשאות). מופיעה תיבת הדו-שיח Permissions.

  4. בתיבת הדו-שיח Permissions, לוחצים על הלחצן Add principal. מופיעה תיבת הדו-שיח Grant access.

  5. בשדה New principals, מזינים allUsers.

  6. בשדה Select a role, מזינים Storage Object Viewer בתיבת הסינון ובוחרים Storage Object Viewer מהתוצאות המסוננות.

  7. לוחצים על Save.

  8. לוחצים על Allow public access.

gcloud

כדי להעניק לכל המשתמשים גישה לצפייה באובייקטים בקטגוריות, מריצים את הפקודה buckets add-iam-policy-binding.

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME \
    --member=allUsers \
    --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME \
    --member=allUsers \
    --role=roles/storage.objectViewer

שמירת כתובת IP פנימית סטטית

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

המסוף

  1. נכנסים לדף Reserve internal static IP address במסוף Google Cloud .

    איך שומרים כתובת IP סטטית פנימית

  2. בשדה שם, מזינים שם לכתובת החדשה.

  3. ברשימה IP version בוחרים באפשרות IPv4.

  4. ברשימה Network בוחרים באפשרות lb-network.

  5. ברשימה Subnetwork בוחרים באפשרות subnet-us.

  6. בשדה Region, בוחרים באפשרות us-east1.

  7. ברשימה Static IP address בוחרים באפשרות Assign automatically. אחרי שיוצרים את מאזן העומסים, כתובת ה-IP הזו מצורפת לכלל ההעברה של מאזן העומסים.

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

gcloud

  1. כדי לשמור כתובת IP פנימית סטטית באמצעות gcloud compute, משתמשים בפקודה compute addresses create.

     gcloud compute addresses create ADDRESS_NAME  \
     --region=REGION \
     --subnet=subnet-us \
     --project=SERVICE_PROJECT_ID

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

    • ‫ADDRESS_NAME: השם שרוצים לתת לכתובת הזו.
    • ‫REGION: האזור שבו רוצים לשריין את הכתובת הזו. האזור הזה צריך להיות זהה לאזור של מאזן העומסים. לדוגמה, us-east1.
    • ‫SERVICE_PROJECT_ID: מזהה הפרויקט שהוקצה לפרויקט השירות. Google Cloud

  2. משתמשים בפקודה compute addresses describe כדי לראות את התוצאה:

     gcloud compute addresses describe ADDRESS_NAME

    מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה כ-RESERVED_IP_ADDRESS בקטעים הבאים.

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

אם regional internal Application Load Balancer משתמש ב-HTTPS כפרוטוקול של בקשות ותגובות, אפשר ליצור משאב של אישור SSL באמצעות אישור SSL של Compute Engine או אישור של Certificate Manager.

בדוגמה הזו, יוצרים משאב של אישור SSL באמצעות Certificate Manager, כמו שמתואר באחד מהמסמכים הבאים:

אחרי שיוצרים את האישור, אפשר לצרף אותו לשרת proxy של יעד HTTPS.

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

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

בקטע הזה מוסבר איך ליצור את המשאבים הבאים עבורregional internal Application Load Balancer:

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

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

  1. יוצרים שתי קטגוריות עורפיות באזור us-east1 באמצעות הפקודה gcloud beta compute backend-buckets create. לקטגוריות הקצה העורפי יש סכמת איזון עומסים של INTERNAL_MANAGED.

      gcloud beta compute backend-buckets create backend-bucket-cats \
      --gcs-bucket-name=BUCKET1_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --region=us-east1 \
      --project=SERVICE_PROJECT_ID

      gcloud beta compute backend-buckets create backend-bucket-dogs \
      --gcs-bucket-name=BUCKET2_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --region=us-east1
      --project=SERVICE_PROJECT_ID

  2. יוצרים מפת URL כדי לנתב בקשות נכנסות לקטגוריית קצה עורפי באמצעות הפקודה gcloud beta compute url-maps create.

      gcloud beta compute url-maps create URL_MAP_NAME \
      --default-backend-bucket=backend-bucket-cats \
      --region=us-east1 \
      --project=SERVICE_PROJECT_ID

    מחליפים את URL_MAP_NAME בשם של מפת URL.

  3. מגדירים את כללי המארח והנתיב של מפת ה-URL באמצעות הפקודה gcloud beta compute url-maps add-path-matcher.

    בדוגמה הזו, קטגוריית הקצה העורפי שמוגדרת כברירת מחדל היא backend-bucket-cats, שמטפלת בכל הנתיבים שקיימים בתוכה. עם זאת, כל בקשה שמכוונת אל http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg משתמשת בבק-אנד backend-bucket-dogs. לדוגמה, אם התיקייה /love-to-fetch/ קיימת גם בקצה העורפי שמוגדר כברירת מחדל (backend-bucket-cats), מאזן העומסים נותן עדיפות לקצה העורפי backend-bucket-dogs כי יש כלל נתיב ספציפי ל-/love-to-fetch/*.

      gcloud beta compute url-maps add-path-matcher URL_MAP_NAME \
      --path-matcher-name=path-matcher-pets \
      --new-hosts=* \
      --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \
      --default-backend-bucket=backend-bucket-cats \
      --region=us-east1 \
      --project=SERVICE_PROJECT_ID

  4. יוצרים שרת proxy ליעד באמצעות הפקודה gcloud compute target-http-proxies create.

    HTTP

    לתנועת HTTP, יוצרים שרת proxy HTTP ליעד כדי להפנות בקשות למפת URL:

      gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --url-map=URL_MAP_NAME \
      --region=us-east1 \
      --project=SERVICE_PROJECT_ID

    מחליפים את TARGET_HTTP_PROXY_NAME בשם של פרוקסי ה-HTTP של היעד.

    HTTPS

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

    כדי לצרף אישור של Certificate Manager, מריצים את הפקודה הבאה:

      gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
      --url-map=URL_MAP_NAME \
      --certificate-manager-certificates=CERTIFICATE_NAME \
      --region=us-east1 \
      --project=SERVICE_PROJECT_ID

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

  5. יוצרים כלל העברה עם כתובת IP באזור us-east1 באמצעות הפקודה gcloud compute forwarding-rules create.

    שמירת כתובת IP היא אופציונלית לכלל העברה של HTTP, אבל היא נדרשת לכלל העברה של HTTPS.

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

    HTTP

    עבור תנועת HTTP, יוצרים כלל העברה אזורי כדי לנתב בקשות נכנסות לשרת ה-proxy של יעד HTTP:

      gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=subnet-us \
      --subnet-region=us-east1 \
      --address=RESERVED_IP_ADDRESS
      --ports=80 \
      --region=us-east1 \
      --target-http-proxy=TARGET_HTTP_PROXY_NAME \
      --target-http-proxy-region=us-east1 \
      --project=SERVICE_PROJECT_ID

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

    HTTPS

    לתעבורת HTTPS, יוצרים כלל העברה אזורי כדי לנתב בקשות נכנסות לשרת ה-proxy של יעד HTTPS:

      gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=subnet-us \
      --subnet-region=us-east1 \
      --address=RESERVED_IP_ADDRESS \
      --ports=443 \
      --region=us-east1 \
      --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
      --target-https-proxy-region=us-east1 \
      --project=SERVICE_PROJECT_ID

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

שליחת בקשת HTTP למאזן העומסים

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

  1. מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים, שנמצא באזור us-east1.

     gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
     --region=us-east1 \
     --project=SERVICE_PROJECT_ID

    מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה בתור FORWARDING_RULE_IP_ADDRESS.

  2. יוצרים מכונה וירטואלית (VM) של לקוח באזור us-east1.

    gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh

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

    gcloud compute ssh client-a --zone=us-east1-c

  4. בדוגמה הזו, ל- regional internal Application Load Balancer יש כתובת IP וירטואלית (VIP) של קצה קדמי באזור us-east1 ברשת ה-VPC. שולחים בקשת HTTP ל-VIP באזור הזה באמצעות curl.

    curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg

    curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg

    מחליפים את FORWARDING_RULE_IP_ADDRESS בכתובת ה-IP שהעתקתם בשלב הראשון.

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

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

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

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

  • כלל העברה, שרת Proxy ליעד ומפת URL בפרויקט המארח, וקטגוריות קצה עורפי בפרויקט שירות אחד
  • כלל העברה, שרת proxy ליעד ומפת URL בפרויקט שירות, ודליים של קצה עורפי בפרויקט שירות אחר

בקטע הזה נציג את ההגדרה השנייה כדוגמה.

סקירה כללית של ההגדרה

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

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

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

הגדרת קטגוריות של Cloud Storage וקטגוריות של קצה עורפי בפרויקט שירות B

צריך לבצע את כל השלבים בקטע הזה בפרויקט השירות B.

כדי ליצור קטגוריית קצה עורפי, צריך לבצע את הפעולות הבאות:

  1. יוצרים את הקטגוריות של Cloud Storage.
  2. מעתיקים את התוכן לקטגוריה.
  3. הגדרת הקטגוריות כקריאות באופן ציבורי.
  4. יוצרים קטגוריית קצה עורפי ומפנים אותה לקטגוריה של Cloud Storage.

יצירת קטגוריות ב-Cloud Storage

בדוגמה הזו, יוצרים את הקטגוריה של Cloud Storage באזור us-east1.

המסוף

  1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.

    כניסה לדף Buckets

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

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

  4. לוחצים על בחירת המיקום לאחסון הנתונים.

  5. מגדירים את סוג המיקום לאזור.

  6. ברשימת האזורים, בוחרים באפשרות us-east1.

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

  8. לוחצים על Buckets כדי לחזור לדף Cloud Storage Buckets. פועלים לפי ההוראות הקודמות כדי ליצור קטגוריה שנייה באזור us-east1.

gcloud

יוצרים את הקטגוריות באזור us-east1 באמצעות הפקודה gcloud storage buckets create.

 gcloud storage buckets create gs://BUCKET1_NAME \
     --default-storage-class=standard \
     --location=us-east1 \
     --uniform-bucket-level-access \
     --project=SERVICE_PROJECT_B_ID

  gcloud storage buckets create gs://BUCKET2_NAME \
      --default-storage-class=standard \
      --location=us-east1 \
      --uniform-bucket-level-access \
      --project=SERVICE_PROJECT_B_ID

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

  • ‫BUCKET1_NAME: השם של קטגוריית Cloud Storage הראשונה
  • ‫BUCKET2_NAME: השם של קטגוריית Cloud Storage השנייה
  • ‫SERVICE_PROJECT_B_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות ב'

העתקת קובצי גרפיקה לקטגוריות של Cloud Storage

כדי שתוכלו לבדוק את ההגדרה, אתם יכולים להעתיק קובץ גרפי מקטגוריה ציבורית של Cloud Storage לקטגוריות שלכם ב-Cloud Storage.

gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/

gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

הגדרת קטגוריות של Cloud Storage כקריאות באופן ציבורי

כדי שכל האובייקטים בקטגוריה יהיו קריאים לכולם באינטרנט הציבורי, צריך להעניק לחשבון הראשי allUsers את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer).

המסוף

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

  1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.

    כניסה לדף Buckets

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

  3. לוחצים על הלחצן Permissions (הרשאות). מופיעה תיבת הדו-שיח Permissions.

  4. בתיבת הדו-שיח Permissions, לוחצים על הלחצן Add principal. מופיעה תיבת הדו-שיח Grant access.

  5. בשדה New principals, מזינים allUsers.

  6. בשדה Select a role, מזינים Storage Object Viewer בתיבת הסינון ובוחרים Storage Object Viewer מהתוצאות המסוננות.

  7. לוחצים על Save.

  8. לוחצים על Allow public access.

gcloud

כדי להעניק לכל המשתמשים גישה לצפייה באובייקטים בקטגוריות, מריצים את הפקודה buckets add-iam-policy-binding.

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME \
    --member=allUsers \
    --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME \
    --member=allUsers \
    --role=roles/storage.objectViewer

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

כדי ליצור את דלי ה-Backend, פועלים לפי השלבים הבאים:

  1. יוצרים שתי קטגוריות עורפיות באזור us-east1 באמצעות הפקודה gcloud beta compute backend-buckets create. לקטגוריות הקצה העורפי יש סכמת איזון עומסים של INTERNAL_MANAGED.

      gcloud beta compute backend-buckets create backend-bucket-cats \
      --gcs-bucket-name=BUCKET1_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --region=us-east1 \
      --project=SERVICE_PROJECT_B_ID

      gcloud beta compute backend-buckets create backend-bucket-dogs \
      --gcs-bucket-name=BUCKET2_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --region=us-east1
      --project=SERVICE_PROJECT_B_ID

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

צריך לבצע את כל השלבים בקטע הזה בפרויקט השירות A.

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

  1. מגדירים משאב של אישור SSL שמצורף לשרת ה-proxy של היעד. מידע נוסף זמין בהמשך המאמר בקטע הגדרת משאב של אישור SSL.
  2. יוצרים ושומרים כתובת IP פנימית סטטית לכלל ההעברה של מאזן העומסים. מידע נוסף מופיע בקטע שמירת כתובת IP פנימית סטטית .

  3. יוצרים מפת URL כדי לנתב בקשות נכנסות אל קטגוריית הקצה העורפי בפרויקט השירות B באמצעות הפקודה gcloud beta compute url-maps create.

      gcloud beta compute url-maps create URL_MAP_NAME \
      --default-backend-bucket=backend-bucket-cats \
      --region=us-east1 \
      --project=SERVICE_PROJECT_A_ID

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

    • ‫URL_MAP_NAME: השם של מפת URL
    • ‫SERVICE_PROJECT_A_ID: Google Cloudמזהה הפרויקט שהוקצה לפרויקט השירות א'

  4. מגדירים את כללי המארח והנתיב של מפת ה-URL באמצעות הפקודה gcloud beta compute url-maps add-path-matcher.

    בדוגמה הזו, קטגוריית הקצה העורפי שמוגדרת כברירת מחדל היא backend-bucket-cats, שמטפלת בכל הנתיבים שקיימים בתוכה. עם זאת, כל בקשה שמכוונת אל http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg משתמשת בבק-אנד backend-bucket-dogs. לדוגמה, אם התיקייה /love-to-fetch/ קיימת גם בקצה העורפי שמוגדר כברירת מחדל (backend-bucket-cats), מאזן העומסים נותן עדיפות לקצה העורפי backend-bucket-dogs כי יש כלל נתיב ספציפי ל-/love-to-fetch/*.

      gcloud beta compute url-maps add-path-matcher URL_MAP_NAME \
      --path-matcher-name=path-matcher-pets \
      --new-hosts=* \
      --backend-bucket-path-rules="/love-to-fetch/*=projects/SERVICE_PROJECT_B_ID/regional/backendBuckets/backend-bucket-dogs" \
      --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/regional/backendBuckets/backend-bucket-cats \
      --region=us-east1
      --project=SERVICE_PROJECT_A_ID

  5. יוצרים שרת proxy ליעד באמצעות הפקודה gcloud compute target-http-proxies create.

    HTTP

    לתנועת HTTP, יוצרים שרת proxy HTTP ליעד כדי להפנות בקשות למפת URL:

      gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --url-map=URL_MAP_NAME \
      --region=us-east1 \
      --project=SERVICE_PROJECT_A_ID

    מחליפים את TARGET_HTTP_PROXY_NAME בשם של פרוקסי ה-HTTP של היעד.

    HTTPS

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

    כדי לצרף אישור של Certificate Manager, מריצים את הפקודה הבאה:

      gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
      --url-map=lb-map \
      --certificate-manager-certificates=CERTIFICATE_NAME \
      --region=us-east1 \
      --project=SERVICE_PROJECT_A_ID

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

  6. יוצרים כלל העברה עם כתובת IP באזור us-east1 באמצעות הפקודה gcloud compute forwarding-rules create.

    שמירת כתובת IP היא אופציונלית לכלל העברה של HTTP, אבל היא נדרשת לכלל העברה של HTTPS.

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

    HTTP

    עבור תנועת HTTP, יוצרים כלל העברה אזורי כדי לנתב בקשות נכנסות לשרת ה-proxy של יעד HTTP:

      gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=subnet-us \
      --address=RESERVED_IP_ADDRESS
      --ports=80 \
      --region=us-east1 \
      --target-http-proxy=TARGET_HTTP_PROXY_NAME \
      --target-http-proxy-region=us-east1 \
      --project=SERVICE_PROJECT_A_ID

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

    • ‫FORWARDING_RULE_NAME: השם של כלל ההעברה
    • RESERVED_IP_ADDRESS: כתובת ה-IP השמורה

    HTTPS

    לתעבורת HTTPS, יוצרים כלל העברה אזורי כדי לנתב בקשות נכנסות לשרת ה-proxy של יעד HTTPS:

      gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=subnet-us \
      --address=RESERVED_IP_ADDRESS \
      --ports=443 \
      --region=us-east1 \
      --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
      --target-https-proxy-region=us-east1 \
      --project=SERVICE_PROJECT_A_ID

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

    • ‫FORWARDING_RULE_NAME: השם של כלל ההעברה
    • RESERVED_IP_ADDRESS: כתובת ה-IP השמורה

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

אם רוצים שמאזני עומסים יפנו לקטגוריות של קצה עורפי בפרויקטים אחרים של שירותים, לאדמין של מאזן העומסים צריכה להיות הרשאה compute.backendBuckets.use. כדי להעניק את ההרשאה הזו, אפשר להשתמש בתפקיד המוגדר מראש ב-IAM שנקרא Compute Load Balancer Services User (משתמש בשירותי איזון עומסים של Compute) ‏(roles/compute.loadBalancerServiceUser). התפקיד הזה צריך להיות מוענק על ידי אדמין של פרויקט השירות, ואפשר להחיל אותו ברמת פרויקט השירות או ברמת קטגוריית קצה עורפי ספציפית.

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

המסוף

הרשאות ברמת הפרויקט

כדי להעניק הרשאות לכל קטגוריות ה-backend בפרויקט, פועלים לפי השלבים הבאים.

כדי להשלים את השלב הזה, צריך את ההרשאות compute.regionBackendBuckets.setIamPolicy ו-resourcemanager.projects.setIamPolicy.

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

    כניסה לדף IAM

  2. בוחרים את הפרויקט הרצוי.

  3. לוחצים על Grant access.

  4. בשדה New principals, מזינים את כתובת האימייל או מזהה אחר של החשבון הראשי.

  5. בקטע הקצאת תפקידים, לוחצים על הוספת תפקידים.

  6. בתיבת הדו-שיח Select roles (בחירת תפקידים), בשדה Search for roles (חיפוש תפקידים), מזינים את התפקיד Compute Load Balancer Services User.

  7. מסמנים את התיבה Compute Load Balancer Services User.

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

  9. אם רוצים, מוסיפים תנאי לתפקיד.

  10. לוחצים על Save.

הרשאות ברמת המשאב לקטגוריות ספציפיות של backend

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

כדי להשלים את השלב הזה, נדרשת ההרשאה compute.regionBackendBuckets.setIamPolicy.

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

    כניסה לדף Backends

  2. ברשימת ה-backends, בוחרים את קטגוריית הקצה העורפי שרוצים לתת לה גישה ולוחצים על Permissions.

  3. לוחצים על Add principal.

  4. בשדה New principals, מזינים את כתובת האימייל או מזהה אחר של החשבון הראשי.

  5. ברשימה Select a role בוחרים באפשרות Compute Load Balancer Services User.

  6. לוחצים על Save.

gcloud

הרשאות ברמת הפרויקט

כדי להעניק הרשאות לכל קטגוריות ה-backend בפרויקט, פועלים לפי השלבים הבאים.

כדי להשלים את השלב הזה, צריך את ההרשאות compute.regionBackendBuckets.setIamPolicy ו-resourcemanager.projects.setIamPolicy. 

  gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
      --member="user:LOAD_BALANCER_ADMIN" \
      --role="roles/compute.loadBalancerServiceUser"

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

  • ‫SERVICE_PROJECT_B_ID: מזהה הפרויקט שהוקצה לפרויקט השירות B Google Cloud
  • ‫LOAD_BALANCER_ADMIN: החשבון הראשי שרוצים להוסיף לו את הקישור

הרשאות ברמת המשאב לקטגוריות ספציפיות של backend

ברמת קטגוריית קצה עורפי, אדמינים של פרויקט שירות יכולים להשתמש באחת מהפקודות הבאות כדי להקצות את התפקיד 'משתמש בשירותי איזון עומסים ב-Compute' (roles/compute.loadBalancerServiceUser):

משתמשים בפקודה gcloud projects add-iam-policy-binding כדי להעניק את התפקיד 'משתמש בשירותים של מאזן עומסים של Compute'.

כדי להשלים את השלב הזה, צריך את ההרשאה compute.regionBackendBuckets.setIamPolicy.

  gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
      --member="user:LOAD_BALANCER_ADMIN" \
      --role="roles/compute.loadBalancerServiceUser" \
      --condition='expression=resource.name=="projects/SERVICE_PROJECT_B_ID/regions/REGION/backendBuckets/BACKEND_BUCKET_NAME",title=Shared VPC condition'
מחליפים את מה שכתוב בשדות הבאים:
  • ‫SERVICE_PROJECT_B_ID: מזהה הפרויקט שהוקצה לפרויקט השירות B Google Cloud
  • ‫LOAD_BALANCER_ADMIN: החשבון הראשי שרוצים להוסיף לו את הקישור
  • ‫REGION: Google Cloud האזור שבו נמצאת קטגוריית קצה עורפי
  • ‫BACKEND_BUCKET_NAME: השם של קטגוריית קצה עורפי
אפשר גם להשתמש בפקודה gcloud compute backend-buckets add-iam-policy-binding כדי להקצות את התפקיד 'משתמש בשירותי מאזן עומסים ב-Compute'. 
  gcloud compute backend-buckets add-iam-policy-binding BACKEND_BUCKET_NAME \
      --member="user:LOAD_BALANCER_ADMIN" \
      --role="roles/compute.loadBalancerServiceUser" \
      --project=SERVICE_PROJECT_B_ID \
      --region=REGION

שליחת בקשת HTTP למאזן העומסים

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

  1. מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים, שנמצא באזור us-east1.

     gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
     --region=us-east1 \
     --project=SERVICE_PROJECT_A_ID

    מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה בתור FORWARDING_RULE_IP_ADDRESS.

  2. יוצרים מכונה וירטואלית (VM) של לקוח באזור us-east1.

    gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh

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

    gcloud compute ssh client-a --zone=us-east1-c

  4. בדוגמה הזו, ל- regional internal Application Load Balancer יש כתובת VIP של חזית האתר באזור us-east1 ברשת ה-VPC. שולחים בקשת HTTP לכתובת ה-VIP באזור הזה באמצעות curl.

    curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg

    curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg

    מחליפים את FORWARDING_RULE_IP_ADDRESS בכתובת ה-IP שהעתקתם בשלב הראשון.

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