תעבורת נתונים יוצאת (egress) ישירה מ-VPC

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

יתרונות מרכזיים

  • ניהול פשוט יותר: אין יותר צורך בניהול של מופעי מחברים, סוגי מכונות והגדרות קנה מידה. App Engine מטפל בהגדרות ישירות בקובץ app.yaml של השירות.
  • יעילות בעלויות: אין חיוב נוסף על שימוש ביציאה ישירה מ-VPC, ולא צריך לשלם חיובים חודשיים קבועים על מכונות וירטואליות של מחברים.
  • ביצועים ואמינות משופרים: על ידי ביטול הצורך בשימוש במחבר, Direct VPC egress מציע חיבור מהיר ואמין יותר למשאבי רשת ה-VPC. הוא מתרחב במהירות כמו שירות App Engine, ומונע ניתוקים של חיבורים שעלולים להתרחש עם מחברים במהלך תחזוקה.
  • אבטחה ברמת גרנולריות גבוהה: אפשר להחיל תגי רשת ישירות על גרסאות השירות של App Engine, וכך להגדיר כללי חומת אש ומדיניות רשת מדויקים שספציפיים לשירות.

מגבלות

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

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

  • הפעלות במצב התחלתי (cold start): זמני ההפעלה הראשוניים במצב התחלתי תלויים באזור ובמקרה השימוש הספציפי. במקרים נדירים, הפעלה במצב התחלתי (cold start) עשויה להימשך עד דקה.

  • Direct VPC ingress: ‏ App Engine לא תומך ב-Direct VPC ingress.

  • מספר המופעים: אפשר להגדיר עד 100 מופעים לכל גרסה של App Engine לשימוש ביציאה ישירה מ-VPC.

הקצאת כתובות IP

כדי למקם את שירות App Engine ברשת VPC, צריך לציין רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, רשת המשנה מקבלת את אותו שם כמו הרשת. ‫App Engine מקצה כתובות IP מתת-הרשת שלכם.

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

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

הגדלה והקטנה של נפח הפעילות

כדי להרחיב אנכית בהתאם לעומס מהר יותר בזמן עלייה חדה בתעבורת נתונים, App Engine שומר כתובות IP בחסימות של 16 (28 מסכה של רשת משנה) בכל פעם. כדי לוודא שיש לכם מספיק כתובות IPv4 זמינות לשימוש ב-App Engine, טווח כתובות ה-IPv4 של רשת המשנה צריך להיות /26 או גדול יותר.

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

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

שימוש בכתובות IP בשירותים

במצב יציב, App Engine משתמש בפי שניים (2X) כתובות IP ממספר המופעים. כשגרסה מצטמצמת, App Engine שומר את כתובות ה-IP שלה למשך עד 20 דקות. בסך הכול, כדאי להקצות לפחות פי 2 ממספר כתובות ה-IP, בתוספת מקום לשינויים שיידרשו בעקבות עדכוני גרסה.

לדוגמה, אם משדרגים גרסאות כך ש-version 1 מתרחב מ-100 מופעים עד לאפס, ו-version 2 מתרחב מאפס עד 100, מערכת App Engine שומרת את כתובות ה-IP של version 1 למשך עד 20 דקות אחרי ההתכווצות. במהלך חלון השמירה של 20 דקות, אתם צריכים להזמין לפחות 400 כתובות IP‏ ((100 + 100) * 2).

טווחים נתמכים של IPv4

‫App Engine תומך בטווחים הבאים של כתובות IPv4 עבור רשת המשנה:

  • RFC 1918
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • Class E
    • 240.0.0.0/4

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

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

  2. מפעילים את Compute Engine API ואת Cloud Build API:

    הפעלת ממשקי API

  3. כדי להשתמש בתעבורת נתונים יוצאת (egress) ישירה של VPC, צריך לוודא שאתם מריצים את הגרסה העדכנית ביותר של Google Cloud CLI:

    gcloud components update

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

כדי לוודא של-App Engine יש גישה לרשת ה-VPC, צריך להקצות את התפקידים הבאים לחשבון השירות שמשמש לפריסה:

  • תפקיד סוכן השירות של App Engine: כברירת מחדל, לסוכן השירות של App Engine יש את תפקיד סוכן השירות של App Engine (roles/appengine.serviceAgent) שמכיל את ההרשאות הנדרשות.

  • הרשאות בהתאמה אישית: כדי לקבל שליטה מפורטת יותר, צריך לתת לסוכן השירות של App Engine את ההרשאות הנוספות הבאות בפרויקט:

    • compute.networks.get
    • compute.subnetworks.get
    • ‫compute.subnetworks.use בפרויקט או ברשת המשנה הספציפית
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create
    • compute.addresses.delete
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get

  • התפקיד Compute Network User: אם לא משתמשים בתפקיד ברירת המחדל App Engine Service Agent או בהרשאות המותאמות אישית, צריך להעניק את התפקיד Compute Network User ‏ (roles/compute.networkUser) בחשבון השירות App Engine Service Agent. ברשתות משנה עם IPv6 חיצוני נדרש גם התפקיד Compute Public IP Admin ‏ (roles/compute.publicIpAdmin).

    לדוגמה, כדי להעניק את התפקיד Compute Network User, מריצים את הפקודה הבאה:

    gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"

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

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫PROJECT_NUMBER: מספר הפרויקט שבו אתם פורסים את שירות App Engine.

הגדרת שירות App Engine עם Direct VPC egress

כדי לאפשר לשירות חדש או קיים של App Engine להתחבר ישירות לרשת ה-VPC, פועלים לפי השלבים הבאים:

  1. מוסיפים את ההגדרה הבאה vpc_access לקובץ app.yaml:

    vpc_access:
  network_interface:
    network: NETWORK
    subnet: SUBNET
    tags:
        - NETWORK_TAGS
  vpc_egress: EGRESS_SETTING

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

    • ‫NETWORK: השם של הרשת הקיימת שאליה מתחברים מופעי האפליקציה, לדוגמה, default. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, רשת המשנה מקבלת את אותו שם כמו הרשת.

    • ‫SUBNET: השם של רשת המשנה הקיימת שאליה מתחברים מופעי האפליקציה, למשל default. אפשר לציין רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, רשת המשנה מקבלת את אותו שם כמו הרשת.

    • אופציונלי: NETWORK_TAGS: רשימה של תגי רשת לשיוך למופעים של שירות App Engine לשימוש בכללי חומת אש ובמדיניות ניתוב.

    • אופציונלי: EGRESS_SETTING: קובע איך תעבורה יוצאת מנותבת. השדה הזה תומך בהגדרות הבאות:

      • ‫all-traffic: כל הבקשות היוצאות מנותבות דרך רשת ה-VPC.
      • ‫private-ranges-only (ברירת מחדל): רק תעבורת נתונים לכתובות IP פנימיות מנותבת דרך רשת ה-VPC. תעבורת נתונים מהאינטרנט משתמשת בנתיב ברירת המחדל של App Engine.

  2. מבצעים פריסה ל-App Engine על ידי הרצת הפקודה הבאה:

    gcloud beta app deploy

ניתוק שירות

כדי לנתק את השירות מרשת ה-VPC:

  1. מסירים את הקטע vpc_access מהקובץ app.yaml.

  2. פורסים מחדש את השירות:

    gcloud beta app deploy

שיטות מומלצות לניהול קניין רוחני

חשוב לנהל את כתובות ה-IP, כי כל מופע של השירות צורך כתובת IP מתת-הרשת. אפשר להשתמש באסטרטגיות הבאות לניהול כתובות ה-IP:

  • טווח כתובות IP מומלץ: כדי להבטיח את התאימות הטובה ביותר, מומלץ להתחיל עם הטווח RFC 6598 ‏ (100.64.0.0/10).

  • טווחים חלופיים של כתובות IP: אם אתם כבר משתמשים בטווח כתובות ה-IP המומלץ 100.64.0.0/10, אתם יכולים להשתמש בטווחים שלא תואמים ל-RFC 1918, כמו Class E ‏(240.0.0.0/4) ברשת המשנה.

  • גודל תת-הרשת: כדי לספק מספיק כתובות להרחבה, חשוב לוודא שטווח כתובות ה-IPv4 של תת-הרשת הוא /26 או גדול יותר.

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

פתרון בעיות

בקטע הזה מתוארות שגיאות נפוצות שאתם עשויים להיתקל בהן במהלך פריסת שירות App Engine עם Direct VPC egress.

אי אפשר למחוק רשת משנה

כדי למחוק תת-רשת, קודם צריך למחוק או לפרוס מחדש את כל המשאבים שמשתמשים בה. אם App Engine משתמש בתת-רשת, צריך לנתק את השירות של App Engine מרשת ה-VPC או להעביר אותו לתת-רשת אחרת לפני שמוחקים את תת-הרשת.

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

כשלים בפריסה

אם הפריסה נכשלת, Google Cloud CLI מציג הודעות שגיאה שמציינות את הסיבה הבסיסית. הנה כמה בעיות נפוצות:

  • מטא-נתונים שגויים של VPC, כמו שם רשת או שם רשת משנה עם שגיאת כתיב בקובץ app.yaml. כדי לתקן שגיאות פוטנציאליות, צריך לבדוק את הגדרות ה-VPC בקובץ app.yaml.

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

מיצוי של כתובות IP

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

דליפות של כתובות IP

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

  • לחשבון השירות שמשמש לפריסה יש הרשאות רק להזמנת כתובות (create, createInternal) ואין לו הרשאות לשחרור כתובות (delete, deleteInternal).
  • חשבון השירות שלכם נמחק בזמן שהיו פעילות הזמנות אחרות של כתובות Google Cloud .
  • החשבון לחיוב ב-Cloud הוסר מהפרויקט ואחר כך הופעל בו מחדש, בזמן שהזמנות של כתובות ללא שרת היו פעילות.
  • הפרויקט Google Cloud נמחק ואז שוחזר, בזמן שהזמנות של כתובות Serverless עדיין היו קיימות.

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

  1. כדי לזהות את הכתובות שנחשפו, מריצים שאילתה ב-Logs Explorer לגבי היומנים הבאים:

    protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*"
protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses"
protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*"
severity>=WARNING

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

  2. אם השאילתה מחזירה תוצאות, מוודאים שחשבון השירות שמשמש לפריסה מכיל את התפקיד App Engine Service Agent ‏ (roles/appengine.serviceAgent). אם אי אפשר להשתמש בתפקיד הזה, צריך לוודא שנתתם לחשבון השירות שמשמש לפריסה הרשאות ותפקידים נדרשים אחרים.

  3. מחיקה ידנית של כתובות IP שדלפו באמצעות מסוף Google Cloud או Google Cloud CLI:

    המסוף

    1. נכנסים לדף IP addresses במסוף Google Cloud :

      עוברים אל כתובות IP

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

    3. לוחצים על Release static address כדי להסיר את הכתובות שנחשפו.

    gcloud

    מריצים את הפקודה gcloud compute addresses delete:

    gcloud compute addresses delete ADDRESS_NAME --region=REGION

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

    • ‫ADDRESS_NAME: השם של כתובת ה-IP שדלפה.
    • ‫REGION: האזור של כתובת ה-IP שדלפה.