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

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

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

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

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

• תמיכה ב-VPC Flow Logs: אתם יכולים להפעיל VPC Flow Logs ברשת המשנה כדי לרשום תעבורת יציאה משירות App Engine.

מגבלות

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

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

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

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

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

• VPC Flow Logs: לא מציג את גרסת השירות של App Engine ברשומות היומן. שם השירות מוצג בשדה AppEngineServiceDetails.

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

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

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

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

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

כדי להרחיב אנכית בהתאם לעומס (scale up) מהר יותר בזמן עלייה חדה בתעבורת נתונים, 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
• כיתה 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 או בהרשאות מותאמות אישית, אתם צריכים להעניק את התפקיד Compute Network User ‏ (roles/compute.networkUser) לחשבון השירות של סוכן השירות של App Engine. ברשתות משנה עם כתובות 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, כדאי להשתמש בשיטות הבאות:

• טווח כתובות 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. חשוב לוודא שהענקתם את ההרשאות הנדרשות לחשבון השירות שדרכו אתם פורסים את הפונקציה. אם נתקלים בשגיאות הרשאה במהלך הפריסה, צריך לוודא שחשבון השירות קיבל את התפקידים הנוספים הבאים:

  • חשבון שירות של Cloud Build (roles/cloudbuild.builds.builder)
  • יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator)

מיצוי של כתובות 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 שדלפה.