העברה של דומיין מותאם אישית ב-App Engine ל-Cloud Load Balancing

מזהה אזור

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, המחרוזת REGION_ID.r כלולה בכתובות ה-URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

מידע נוסף על מזהי אזורים

במדריך הזה מוסבר איך להגדיר נקודת קצה ציבורית חדשה לאפליקציית App Engine באמצעות Cloud Load Balancing.

באמצעות Cloud Load Balancing, אתם מגדירים את נקודת הקצה של הדומיין המותאם אישית כשירות קצה קדמי, ואת אפליקציית App Engine כשירות לקצה העורפי באמצעות קבוצה של נקודות קצה ברשת (NEG) מסוג Serverless. התעבורה לנקודת הקצה של שירות הקצה הקדמי של Cloud Load Balancing מנותבת באותו אופן כמו קודם, כולל כל כללי הניתוב שמוגדרים בקובץ dispatch.yaml של האפליקציה.

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

לקחת דומיין מותאם אישית של App Engine ולהעביר בקשות נכנסות לשירות קצה קדמי של Cloud Load Balancing שמפיץ בקשות לשירות קצה עורפי של App Engine.

המעבר ל-Cloud Load Balancing מאפשר לכם גמישות רבה יותר בטיפול בתעבורה שמגיעה לדומיין שלכם, למשל הצגת תוכן סטטי מ-Cloud Storage או הוספת שירותים שפועלים בפלטפורמות מחשוב אחרות כמו Cloud Run ו-Google Kubernetes Engine.

בנוסף, תקבלו גישה ליכולות Google Cloud חשובות שלא זמינות ב-App Engine, כולל:

  • ‫Google Cloud Armor, לאבטחה משופרת עם הגנה מתקדמת מפני DDoS, אמצעי בקרה של גישה מבוססת-IP וגישה מבוססת-מיקום גיאוגרפי, כללים של חומת אש לאפליקציות אינטרנט ועוד
  • ‫Cloud CDN, להעברת תוכן שנשמר במטמון
  • מדיניות SSL, לניהול התכונות של SSL וגרסאות TLS שהאפליקציה תקבל

במדריך הזה מפורטות הוראות להעברת בקשות נכנסות משירות App Engine עם דומיין מותאם אישית לשירות קצה קדמי של Cloud Load Balancing:

  1. מוודאים שיש לכם את ההרשאות הנדרשות
  2. יצירת אישור בניהול Google
  3. הגדרת Cloud Load Balancing
  4. בדיקת מאזן העומסים
  5. חיבור הדומיין למאזן העומסים
  6. מחיקת מיפוי של דומיין מותאם אישית ב-App Engine
  7. הגדרת בקרת תעבורת נתונים נכנסת (ingress) כדי לאפשר גישה רק דרך Cloud Load Balancing

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

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

הגדרת ההרשאות

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

משימה תפקיד נדרש
יצירת אישור SSL בניהול Google באמצעות Certificate Manager בעלים של Certificate Manager או עורך של Certificate Manager, וגם אדמין של איזון עומסים ב-Compute
עדכון רשומות ה-DNS של הדומיין המותאם אישית Cloud DNS Administrator אם אתם משתמשים ב-Cloud DNS כפתרון ה-DNS שלכם.

אם אתם משתמשים בספק DNS אחר, תצטרכו הרשאות להוספה ולעדכון של רשומות ה-DNS בדומיין המותאם אישית.
יצירת מאזן עומסים ורכיבי רשת אדמין של רשת מחשוב
יצירה ושינוי של קבוצות NEG Compute Instance Admin
יצירה ושינוי של אישורי SSL אדמין לענייני אבטחה ב-Compute
מחיקת דומיינים מותאמים אישית בהגדרות של App Engine התפקיד App Engine Admin או תפקיד שמכיל את ההרשאה appengine.applications.update.

יצירת אישור SSL בניהול Google

אישור SSL בניהול Google (שנקרא גם אישור TLS במסמכים) מאפשר Google Cloud לקבל, לנהל ולחדש אישורים באופן אוטומטי. כדי לעבור לחלק הקדמי של Cloud Load Balancing בלי לגרום להשבתה של שירות App Engine הקיים, צריך להשתמש במנהל האישורים כדי ליצור אישור DNS ואת האישור שמנוהל על ידי Google.

שימו לב שבמסמכי התיעוד של Cloud Load Balancing יש הוראות דומות ליצירת אישור SSL בניהול Google, אבל ההוראות שם מתייחסות לאישור של מאזן העומסים, שדורש השבתה של שירות App Engine שיכולה להימשך עד כמה שעות. מידע נוסף זמין במאמר בנושא אישור דומיין לאישורים בניהול Google.

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

יצירת הרשאת DNS

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

    gcloud certificate-manager dns-authorizations create AUTHORIZATION_NAME \
    --domain="DOMAIN_NAME"
gcloud certificate-manager dns-authorizations describe AUTHORIZATION_NAME

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

    • ‫AUTHORIZATION_NAME הוא שם ייחודי שמתאר את הרשאת ה-DNS הזו.
    • ‫DOMAIN_NAME הוא שם הדומיין המותאם אישית של App Engine שעבורו אתם יוצרים את הרשאת ה-DNS הזו.

  2. שימו לב לרשומת ה-CNAME שמוחזרת על ידי הפקודה gcloud. צריך להשתמש בו כדי לעדכן את רשומת ה-DNS לפי השלבים הבאים.

הוספת רשומת ה-CNAME להגדרת ה-DNS

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

Cloud DNS

כשיוצרים הרשאה ל-DNS, הפקודה gcloud מחזירה את רשומת ה-CNAME המתאימה. צריך להוסיף את רשומת ה-CNAME הזו להגדרת ה-DNS בתחום ה-DNS של דומיין היעד באופן הבא:

  1. מתחילים את העסקה של רשומת ה-DNS:

    gcloud dns record-sets transaction start --zone="DNS_ZONE_NAME"

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

  2. מוסיפים את רשומת ה-CNAME לתחום ה-DNS של היעד:

    gcloud dns record-sets transaction add CNAME_RECORD \
  --name="_acme-challenge.DOMAIN_NAME." \
  --ttl="30" \
  --type="CNAME" \
  --zone="DNS_ZONE_NAME"

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

    • ‫CNAME_RECORD הוא הערך המלא של רשומת ה-CNAME שהוחזרה על ידי הפקודה gcloud שיצרה את הרשאת ה-DNS המתאימה.
    • ‫DOMAIN_NAME הוא שם הדומיין המותאם אישית של App Engine. צריך לכלול את הנקודה בסוף אחרי שם דומיין היעד.
    • ‫DNS_ZONE_NAME הוא השם של אזור ה-DNS של היעד מהשלב הקודם.

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

    gcloud dns record-sets transaction execute --zone="DNS_ZONE_NAME"

    מחליפים את DNS_ZONE_NAME בשם של תחום ה-DNS של היעד מהשלב הקודם.

פתרון DNS אחר

מוסיפים רשומת CNAME להגדרת ה-DNS של הדומיין, באמצעות השדות (מארח) שם (_acme-challenge.DOMAIN_NAME) ונתונים מהקטע הקודם. כדאי לעיין בתיעוד של פתרון ה-DNS של הצד השלישי.

יצירת אישור בניהול Google שמפנה להרשאת ה-DNS

כדי ליצור אישור בניהול Google שמפנה להרשאת ה-DNS שיצרתם בשלבים הקודמים, מריצים את הפקודות הבאות:

  1. יצירת אישור שמנוהל על ידי Google:

    gcloud certificate-manager certificates create CERTIFICATE_NAME \
--domains=DOMAIN_NAME --dns-authorizations=AUTHORIZATION_NAME

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

    • ‫CERTIFICATE_NAME הוא שם ייחודי שמתאר את האישור.
    • ‫DOMAIN_NAME הוא השם של הדומיין המותאם אישית ב-App Engine.
    • ‫AUTHORIZATION_NAME הוא השם של הרשאת ה-DNS שנוצרה קודם.

  2. מוודאים שהאישור פעיל.

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

    gcloud certificate-manager certificates describe CERTIFICATE_NAME

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

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

    certificatePem: myPEM
createTime: '2021-10-20T12:19:53.370778666Z'
expireTime: '2022-05-07T05:03:49Z'
managed:
  authorizationAttemptInfo:
  - domain: example.com
    state: AUTHORIZED
  dnsAuthorizations:
  - projects/my-project/locations/global/dnsAuthorizations/myAuth
  domains:
  - example.com
  state: ACTIVE
name: projects/myProject/locations/global/certificates/myCert
scope: myScope
sanDnsnames:
- example.com
updateTime: '2021-10-20T12:19:55.083385630Z'

    אם הכלי gcloud מחזיר פלט שונה, אפשר לעיין במאמר פתרון בעיות ב-Certificate Manager.

יצירת מיפוי אישורים

  1. יוצרים מיפוי אישורים:

    gcloud certificate-manager maps create CERTIFICATE_MAP_NAME

    מחליפים את CERTIFICATE_MAP_NAME בשם ייחודי שמתאר את מיפוי האישורים.

  2. יוצרים רשומת מיפוי לאישורים ומקשרים אותה לאישור ולמפת האישורים שיצרתם קודם: 

    gcloud certificate-manager maps entries create CERTIFICATE_MAP_ENTRY_NAME \
    --map=CERTIFICATE_MAP_NAME \
    --certificates=CERTIFICATE_NAME \
    --set-primary

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

    • ‫CERTIFICATE_MAP_ENTRY_NAME הוא שם ייחודי שמתאר את רשומת המיפוי לאישורים.
    • ‫CERTIFICATE_MAP_NAME הוא השם של מיפוי האישורים שאליו מצורפת רשומת מיפוי האישורים הזו.
    • ‫CERTIFICATE_NAME הוא שם האישור שרוצים לשייך לרשומת מיפוי לאישורים זו.

    כדי לוודא שהאישור ישמש כאישור ברירת המחדל אם לא מצוין שם דומיין, אפשר להוסיף את הדגל --set-primary.

  3. מוודאים שמיפוי האישורים פעיל.

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

    gcloud certificate-manager maps entries describe CERTIFICATE_MAP_ENTRY_NAME \
    --map=CERTIFICATE_MAP_NAME

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

    • ‫CERTIFICATE_MAP_ENTRY_NAME הוא השם של הרשומה במפת האישורים שצוין קודם.
    • ‫CERTIFICATE_MAP_NAME הוא השם של מפת האישורים שאליה מצורפת רשומת מיפוי האישורים הזו.

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

    createTime: '2021-09-06T10:01:56.229472109Z'
name: projects/my-project/locations/global/certificateMaps/myCertMap/certificateMapEntries/myCertMapEntry
state: ACTIVE
updateTime: '2021-09-06T10:01:58.277031787Z'

מידע נוסף על השימוש ב-Certificate Manager זמין במאמר איך Certificate Manager פועל.

הגדרת Cloud Load Balancing

אחרי שיש לכם אישור בניהול Google, אתם יכולים להחליף את הדומיין המותאם אישית של App Engine בשירות קצה קדמי של Cloud Load Balancing.

בתרשים הבא מוצג מאזן עומסים מסוג HTTPS עם שירות קצה עורפי יחיד ו-NEG בלי שרת (serverless).

הפצת תעבורה לאפליקציית App Engine

כללי העברה מנתבים בקשות נכנסות מכתובות IP חיצוניות ומפנים בקשות לשרת ה-proxy של HTTPS. מאזני העומסים של HTTPS משתמשים במפות של כתובות URL כדי להפנות בקשות לשירות לקצה העורפי, שמכיל NEG בלי שרת (serverless) לשירות App Engine.

שמירת כתובת IP חיצונית

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

המסוף

  1. נכנסים לדף כתובות IP חיצוניות במסוף Google Cloud .

    נכנסים אל External IP addresses

  2. לוחצים על Reserve static address כדי לשריין כתובת IPv4.

  3. מקצים Name לכתובת הסטטית, לדוגמה, appengine-external-ip.

  4. מגדירים את מסלול הרשת לפרימיום.

  5. מגדירים את IP version ל-IPv4.

  6. מגדירים את האפשרות Type (סוג) בתור Global (כללי).

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

gcloud

  1. יוצרים שמירת כתובת IP חיצונית:

    gcloud compute addresses create EXTERNAL_IP \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

    ‫EXTERNAL_IP הוא שם הכתובות שרוצים ליצור.

  2. שימו לב לכתובת ה-IPv4 שהוקצתה:

    gcloud compute addresses describe EXTERNAL_IP \
    --format="get(address)" \
    --global

הגדרת שירות לקצה העורפי ב-App Engine

קבוצה של נקודות קצה ברשת (NEG) משמשת לציון קבוצה של נקודות קצה בעורף של מאזן עומסים. כדי לציין קצה עורפי שמפנה לשירות App Engine, צריך להגדיר את ה-NEG ללא שרת, ואז להגדיר את שירות הקצה העורפי, כללי הניתוב ושירות הקצה הקדמי ב-Cloud Load Balancing.

  1. יוצרים NEG ללא שרת לאפליקציית App Engine:

    gcloud compute network-endpoint-groups create APP_ENGINE_NEG \
--network-endpoint-type=serverless \
--app-engine-app \
--region=APP_ENGINE_REGION

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

    • ‫APP_ENGINE_NEG הוא השם של קבוצת נקודות הקצה ברשת.
    • ‫APP_ENGINE_REGION הוא האזור שהוגדר ב-App Engine.

    אפשר להוסיף את הדגל --app-engine-app שמופיע למעלה כדי להשתמש בניתוב ברירת מחדל, במקום בניסיון להגיע לשירות ספציפי של App Engine. שימוש בניתוב ברירת מחדל אומר שהבקשות יישלחו לשירות ברירת המחדל (https://PROJECT_ID.REGION_ID.r.appspot.com), אחרת הן יפעלו לפי כל כללי הניתוב שהגדרתם בקובץ dispatch.yaml. זוהי התנהגות זהה לזו של דומיינים מותאמים אישית שהוגדרו באמצעות App Engine.

  2. יוצרים את שירות הקצה העורפי:

    gcloud compute backend-services create APP_ENGINE_BACKEND \
  --global \
  --load-balancing-scheme=EXTERNAL_MANAGED

    מחליפים את APP_ENGINE_BACKEND בשם של שירות לקצה העורפי שרוצים ליצור.

  3. מוסיפים את ה-NEG ללא שרת לשירות הקצה העורפי של App Engine:

    gcloud compute backend-services add-backend APP_ENGINE_BACKEND \
--global --network-endpoint-group=APP_ENGINE_NEG \
--network-endpoint-group-region=APP_ENGINE_REGION

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

    • ‫APP_ENGINE_BACKEND הוא השם של שירות ה-Backend מהשלב הקודם.
    • ‫APP_ENGINE_NEG הוא השם של קבוצת נקודות הקצה ברשת.
    • ‫APP_ENGINE_REGION הוא האזור שהוגדר ב-App Engine.

  4. יוצרים מפת URL כדי לנתב בקשות נכנסות לשירות לקצה העורפי:

    gcloud compute url-maps create URL_MAP_NAME \
      --default-service APP_ENGINE_BACKEND

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

    • ‫URL_MAP_NAME הוא שם ייחודי למשאב של מפת URL שמגדיר את המיפוי של כתובות URL לשירותי קצה עורפי.
    • ‫APP_ENGINE_BACKEND הוא השם של שירות ה-Backend מהשלב הקודם.

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

    gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
      --certificate-map=CERTIFICATE_MAP_NAME \
      --url-map=URL_MAP_NAME

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

    • ‫TARGET_HTTPS_PROXY_NAME הוא שם ייחודי שבחרתם כדי לתאר את שרת ה-proxy של HTTPS.
    • ‫CERTIFICATE_MAP_NAME הוא השם של מפת האישורים שמפנה לרשומה במפת האישורים ולאישור שמשויך אליה.
    • ‫URL_MAP_NAME הוא השם של מפת URL שצוין קודם.

  6. יוצרים כלל העברה כדי לנתב בקשות נכנסות לשרת ה-proxy:

    gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
      --load-balancing-scheme=EXTERNAL_MANAGED \
      --network-tier=PREMIUM \
      --address=EXTERNAL_IP \
      --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
      --global \
      --ports=443

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

    • ‫HTTPS_FORWARDING_RULE_NAME הוא שם ייחודי שמתאר את כלל ההעברה להפניית תנועת רשת לשרת ה-proxy של HTTPS.
    • ‫TARGET_HTTPS_PROXY_NAME הוא השם של שרת ה-proxy של HTTPS מהשלב הקודם.
    • ‫EXTERNAL_IP הוא שם כתובת ה-IPv4 שנוצרה קודם.

בדיקת מאזן העומסים

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

  1. נכנסים לדף Load balancing במסוף Google Cloud .
    כניסה לדף Load balancing
  2. לוחצים על מאזן העומסים שיצרתם.
  3. שימו לב לכתובת ה-IP של מאזן העומסים.

  4. במאזן עומסים מסוג HTTPS, אפשר לבדוק את מאזן העומסים באמצעות דפדפן אינטרנט. לשם כך, עוברים אל https://IP_ADDRESS ומחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים, לדוגמה, 30.90.80.100.

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

    אפשרויות הגדרה נוספות מפורטות במאמר הגדרת מאזן עומסים גלובלי חיצוני מסוג HTTP(S) עם פלטפורמות Serverless.

חיבור הדומיין למאזן העומסים

אחרי שיוצרים את מאזן העומסים, רושמים את כתובת ה-IP שמשויכת למאזן העומסים – לדוגמה, 30.90.80.100. כדי להפנות את הדומיין למאזן העומסים, צריך ליצור רשומת A באמצעות שירות הרישום של הדומיין. אם הוספתם מספר דומיינים לאישור ה-SSL, צריך להוסיף רשומת A לכל אחד מהם, כשכולם מפנים לכתובת ה-IP של מאזן העומסים. לדוגמה, כדי ליצור רשומות A בשביל www.example.com ובשביל example.com, משתמשים בפקודה הבאה:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

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

מחיקת המיפוי של הדומיין המותאם אישית ב-App Engine

במסוף Google Cloud :

  1. עוברים לכרטיסייה דומיינים מותאמים אישית בדף הגדרות של App Engine.

    אל "דומיינים מותאמים אישית"

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

לחלופין, אפשר להשתמש בפקודות gcloud או ב-Admin API כדי למחוק את הדומיין המותאם אישית.

הגדרת שליטה בתעבורת נתונים נכנסת (ingress) כדי לאפשר גישה רק דרך Cloud Load Balancing

אחרי בדיקת מאזן העומסים, מומלץ לעדכן את אפליקציית App Engine כדי לקבל תנועה רק מ-Cloud Load Balancing. כדי ללמוד איך להגדיר internal-and-cloud-load-balancing אמצעי בקרה לתעבורת נתונים נכנסת, אפשר לעיין במאמר הגדרות לתעבורת נתונים נכנסת.