העברת דומיין מותאם אישית של 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) ללא שרתים. התעבורה לנקודת הקצה של שירות ה-frontend של 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 של הדומיין המותאם אישית.
יצירת מאזן עומסים ורכיבי רשת אדמין של רשת מחשוב
יצירה ושינוי של קבוצות של ישויות בעלות שם אדמין מכונות של Compute
יצירה ושינוי של אישורי SSL אדמין לענייני אבטחה ב-Compute
מחיקת דומיינים מותאמים אישית בהגדרות של App Engine התפקיד App Engine Admin או תפקיד שמכיל את ההרשאה appengine.applications.update.

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

אישור SSL בניהול Google (שנקרא גם אישור TLS במסמכים) מאפשר Google Cloud לקבל, לנהל ולחדש אישורים באופן אוטומטי. כדי לבצע מיגרציה לחלק הקדמי של Cloud Load Balancing בלי לגרום להשבתה של שירות App Engine הקיים, צריך להשתמש ב-Certificate Manager כדי ליצור הרשאת 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 בלי שרת.

הפצת תעבורה לאפליקציית 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. מקצים שם לכתובת הסטטית, לדוגמה, appengine-external-ip.

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

  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 בלי שרת (serverless), ואז להגדיר את שירות לקצה העורפי, את כללי הניתוב ואת שירות הקצה הקדמי ב-Cloud Load Balancing.

  1. יוצרים NEG ללא שרת (serverless) לאפליקציית 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 בלי שרת (serverless) לשירות הקצה העורפי של 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. נכנסים לדף איזון עומסים במסוף Google Cloud .
    כניסה לדף איזון עומסים
  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