הקצאת ארגון לצורך הערכה ללא קישור בין רשתות VPC שכנות (peering)

הדף הזה מתייחס ל-Apigee, אבל לא ל-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

מגבלות

לאפשרות ההתקנה של קישור בין רשתות וירטואליות שמתוארת במסמך הזה יש כמה מגבלות:

• VPC Service Controls אינו נתמך.

רשימה מלאה של התכונות וגישות הרישות שנתמכות ושלא נתמכות בקישור בין רשתות שכנות (peering) שאינו VPC מופיעה במאמר איך בוחרים אפשרות רשת.

סיכום השלבים

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

• שלב 1: הגדרת משתני סביבה: מגדירים את gcloud ומגדירים משתני סביבה. ה-CLI של Google Cloud מנהל את האימות, את ההגדרה המקומית, את תהליך העבודה של המפתחים ואת האינטראקציות עם ממשקי Google Cloud API.
• שלב 2: הפעלת ממשקי API: כדי להשתמש ב-Apigee, צריך להפעיל כמה ממשקי API של Google Cloud.
• שלב 3: יוצרים ארגון: ארגון Apigee (לפעמים נקרא org) הוא מאגר ברמה העליונה ב-Apigee. הוא כולל את כל הסביבות וקבוצות הסביבות, המשתמשים, שרתי ה-proxy של ה-API והמשאבים הקשורים.
• שלב 4: הגדרת ניתוב: מאפשרים גישה חיצונית או גישה פנימית בלבד ל-API.
• שלב 5: קריאה ל-proxy ל-API לדוגמה: כדי לבדוק את ההקצאה, צריך לפרוס proxy ל-API ולקרוא לו.

שלב 1: הגדרת משתני סביבה

מגדירים את gcloud ומגדירים משתני סביבה לשימוש בשלבים הבאים:

1. חשוב לוודא שהשלמתם את הדרישות שמפורטות בקטע דרישות מוקדמות.
2. צריך להתקין את ה-CLI של gcloud. אם צריך להתקין אותו, אפשר לעיין במאמר בנושא התקנת ה-CLI של gcloud.
3. מאתחלים את ה-CLI של gcloud, כמו שמתואר במאמר אתחול ה-CLI של gcloud. אם ה-CLI כבר מאותחל, מוודאים שהפרויקט בענן של Google שיצרתם בשלב דרישות מוקדמות הוא פרויקט ברירת המחדל של gcloud.
4. מגדירים את משתני הסביבה הבאים:

   AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
   PROJECT_ID="YOUR_PROJECT_ID"
   RUNTIME_LOCATION="YOUR_RUNTIME_LOCATION"
   ANALYTICS_REGION="YOUR_ANALYTICS_REGION"

   כאשר:

   • הכותרת AUTH מוגדרת עם אסימון Bearer.Authentication תשתמשו בכותרת הזו כשתיגשו לממשקי Apigee API. שימו לב שהאסימון יפוג אחרי פרק זמן מסוים, ואז תוכלו פשוט ליצור אותו מחדש באמצעות אותה פקודה. מידע נוסף זמין בדף העיון בנושא הפקודה print-access-token.
   • ‫PROJECT_ID הוא מזהה הפרויקט ב-Cloud שיצרתם במסגרת הדרישות המוקדמות.

   • ‫RUNTIME_LOCATION הוא המיקום הפיזי שבו נמצא מופע Apigee. רשימת המיקומים הזמינים של סביבות זמן ריצה מופיעה במאמר מיקומי Apigee.

     הערה: במקרה של RUNTIME_LOCATION, חשוב להשתמש בשם אזור ולא בשם אזור. לדוגמה, us-west1 הוא שם של אזור, ואילו us-west1-a הוא אזור בתוך האזור. מידע נוסף זמין במאמר זיהוי אזור או תחום.

   • ‫ANALYTICS_REGION הוא המיקום הפיזי שבו יאוחסנו נתוני הניתוח של Apigee. רשימת האזורים שבהם אפשר להשתמש ב-Apigee API Analytics זמינה במאמר מיקומי Apigee.

     הערכים של RUNTIME_LOCATION ושל ANALYTICS_REGION יכולים להיות זהים, אבל הם לא חייבים להיות זהים. עם זאת, יכול להיות שיהיה שיפור בביצועים אם הם זהים.

5. (אופציונלי) כדי לבדוק את העבודה, אפשר להציג את הערכים שהגדרתם. שימו לב: כשרוצים להשתמש במשתנה בפקודות, צריך להוסיף לפני שם המשתנה סימן דולר ($).

   echo $AUTH
   echo $PROJECT_ID
   echo $RUNTIME_LOCATION
   echo $ANALYTICS_REGION
   

   התגובות לפקודות echo אמורות להיראות כך:

   Authorization: Bearer ya29.a123456678940B63hPSAMPLEsampleKKYVsample0f3pWDWZDuH2-hENkNa
   TvgZ1PD977TMvv6edBQPJezdHw040880Ol_LoD5ZDkt-i-knizia_KhA9L20sSvztL81-SAMPLE42ELPMASk2_
   1CxN
   my-cloud-project
   us-west1
   us-west1
   

שלב 2: הפעלת ממשקי API

ההרשאות שנדרשות למשימה הזו

אתם יכולים להקצות למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות. תפקידים מוגדרים מראש והרשאות להפעלת API

1. כדי להשתמש ב-Apigee, צריך להפעיל כמה ממשקי Google Cloud API. כדי להפעיל אותם, מריצים את הפקודה services enable:

   gcloud services enable apigee.googleapis.com \
     cloudkms.googleapis.com --project=$PROJECT_ID

2. (אופציונלי) כדי לבדוק את העבודה, משתמשים בפקודה services list כדי להציג את כל ממשקי ה-API המופעלים:

   gcloud services list

   התשובה מציגה את כל השירותים המופעלים, כולל ממשקי ה-API שהפעלתם זה עתה (Apigee,‏ Cloud KMS ו-Compute Engine).

שלב 3: יצירת ארגון

ארגון הוא מאגר ברמה העליונה ב-Apigee. הוא מכיל את כל שרתי ה-proxy של ה-API והמשאבים שקשורים אליהם. פרטים נוספים זמינים במאמר הסבר על ארגונים.

ההרשאות שנדרשות למשימה הזו

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

• תפקידים מוגדרים מראש
• הרשאות של אשף הקצאת ההרשאות
• הרשאות ליצירת ארגון (ארגון בתשלום).

1. יוצרים ארגון חדש לצורך הערכה באמצעות provisionOrganization API:
   הערה: אפשר ליצור באמצעות provisionOrganization API רק ארגונים לצורך הערכה. אי אפשר להשתמש בו כדי ליצור ארגונים לייצור.

   curl "https://apigee.googleapis.com/v1/projects/$PROJECT_ID:provisionOrganization"  \
     -H "$AUTH" \
     -X POST \
     -H "Content-Type:application/json" \
     -d '{
       "analyticsRegion":"'"$ANALYTICS_REGION"'",
       "runtimeLocation":"'"$RUNTIME_LOCATION"'",
       "disableVpcPeering":"true",
     }'

   כאשר:

   • ‫-d מגדיר את מטען הנתונים של הבקשה. המטען הייעודי (payload) הזה חייב לכלול את הפרטים הבאים:

     • ‫ANALYTICS_REGION: מציין את המיקום הפיזי שבו יישמרו נתוני הניתוח.

     • ‫RUNTIME_LOCATION: המיקום הפיזי שבו נמצאת מכונת Apigee.

     • ‫disableVpcPeering: בתהליך ההקצאה הזה, אנחנו לא משתמשים ב-VPC Peering, ולכן צריך להגדיר את הדגל הזה לערך true. ברירת מחדל: false

2. ‫Apigee מתחיל LRO כדי ליצור את הארגון להערכה. הפעולה הזו נמשכת עד 40 דקות.

3. כדי לבדוק את הסטטוס של בקשת היצירה, אפשר לשלוח בקשת GET ל-List organizations API של Apigee, כמו בדוגמה הבאה:

   curl -H "$AUTH" "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID"

   אם אתם רואים את התשובה הזו, סימן שיצירת הארגון עדיין לא הושלמה:

   {
     "error": {
       "code": 403,
       "message": "Permission denied on resource \"organizations/apigee-docs-m\" (or it may not exist)",
       "status": "PERMISSION_DENIED"
     }
   }

   אם הפעולה בוצעה ללא שגיאות, אובייקט התגובה יציין "state": "ACTIVE", ותוכלו להמשיך לשלב הבא.

שלב 4: הגדרת הניתוב

בשלב הזה מגדירים איך אפליקציות לקוח מתקשרות עם Apigee. תנועה מלקוח אל Apigee נקראת גם תנועה 'צפונית'. אפשרויות ההגדרה של Northbound כוללות את האפשרויות הבאות:

סוג הגישה	תיאור של תהליך ההגדרה והפריסה
פנימי עם Private Service Connect	אפשר לאפשר גישה פנימית בלבד לשרתי ה-proxy של ה-API מכל הפרויקטים שלכם ב-Google Cloud באמצעות Private Service Connect. ‫Private Service Connect מאפשר חיבור פרטי בין בעלים של שירות מנוהל (Apigee) לבין צרכן השירות (פרויקט ה-VPC המקושר ו/או פרויקט אחד או יותר אחרים בענן שאתם שולטים בהם). בשיטה הזו, הבקשות עוברות דרך נקודת קצה של שירות או דרך מאזן עומסים פנימי אזורי לנקודת צירוף יחידה שנקראת צירוף שירות. ההגדרה הזו מאפשרת ללקוחות פנימיים לשלוח בקשות ל-proxy ל-API של Apigee מכל מכונה שמחוברת לרשת.
חיצוני עם Private Service Connect	מאפשרים גישה חיצונית לשרתי proxy של API באמצעות Private Service Connect. משתמשים ב-Private Service Connect כדי להפעיל חיבור פרטי בין בעלים של שירות מנוהל (Apigee) לבין צרכן השירות (פרויקט ה-VPC המקושר ו/או פרויקט בענן אחד או יותר שאתם שולטים בהם). בשיטה הזו, הבקשות עוברות דרך מאזן עומסים חיצוני גלובלי או מאזן עומסים חיצוני אזורי לנקודת צירוף יחידה שנקראת צירוף שירות. ההגדרה הזו מאפשרת לשלוח בקשות ל-proxy של Apigee API מכל מכונה שמחוברת לרשת.

כל אחת מגישות הניתוב האלה מוצגת בכרטיסייה בהוראות שלמטה.

ניתוב פנימי (Private Service Connect)

בקטע הזה מוסבר איך לאפשר גישה פנימית בלבד לשרתי proxy של API מכל הפרויקטים שלכם ב-Google Cloud באמצעות Private Service Connect.

יש שתי אפשרויות להגדרת גישה פנימית באמצעות Private Service Connect:

• נקודת קצה של שירות: הבקשות עוברות דרך נקודת קצה של שירות לנקודת צירוף יחידה שנקראת צירוף שירות.
• מאזן עומסים פנימי אזורי: הבקשות עוברות דרך מאזן עומסים פנימי אזורי מסוג HTTP(S). ראו גם איזון עומסים גלובלי לעומת איזון עומסים אזורי.

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

נקודת קצה של שירות

ההרשאות שנדרשות למשימה הזו

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

יצירת נקודת קצה של שירות Private Service Connect לקובץ המצורף עם השירות

1. מקבלים את קובץ השירות ממופע Apigee:

   curl -i -X GET -H "$AUTH" \
     "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   בדוגמת הפלט הבאה, הערך serviceAttachment מוצג בטקסט מודגש:

   {
     "instances": [
       {
         "name": "us-west1",
         "location": "us-west1",
         "createdAt": "1645731488019",
         "lastModifiedAt": "1646504754219",
         "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
         "state": "ACTIVE",
         "runtimeVersion": "1-7-0-20220228-190814",
         "consumerAcceptList": [
           "my-project"
         ],
         "serviceAttachment": "projects/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1"
       }
     ]
   }

   הערה: המזהה של הפרויקט שבו השתמשתם כדי ליצור את הארגון שלכם ב-Apigee תמיד מופיע ברשימה consumerAcceptList. בדוגמה של הפלט שמוצגת למעלה, זה הפרויקט היחיד ברשימה.
2. יוצרים נקודת קצה של שירות Private Service Connect שמפנה לקובץ המצורף עם השירות שקיבלתם מגוף התגובה של המופע בשלב הקודם, כמו שמוסבר במאמר יצירת נקודת קצה של Private Service Connect.
3. חשוב לרשום ולזכור את כתובת ה-IP של נקודת הקצה של השירות. תצטרכו את כתובת ה-IP בהמשך, כשבודקים את ההגדרה באמצעות קריאה ל-proxy ל-API. (לדוגמה: 10.138.0.2)

הקצאת הרשאות ל-Apigee הושלמה. עוברים אל פריסת שרת proxy לדוגמה.

מאזן עומסים פנימי אזורי

ההרשאות שנדרשות למשימה הזו

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

הגבלות: חשוב לשים לב להגבלות הבאות בהגדרת Private Service Connect:

• אין תמיכה במאזן עומסים גלובלי חיצוני מסוג HTTP(S) (קלאסי) בהגדרה הזו.
• במעבר אוטומטי לגיבוי עם כמה קבוצות של נקודות קצה ברשת פרטית (Private Service Connect), לא נתמכות בדיקות תקינות פעילות. במקום זאת, צריך להשתמש בזיהוי חריגים.
• יש מגבלות על מספר הפרויקטים ב-Google Cloud שאפשר לחבר למופע Apigee באמצעות Private Service Connect, ועל מספר החיבורים של Private Service Connect NEG שאפשר ליצור לכל פרויקט. פרטים נוספים זמינים במאמר מגבלות של Private Service Connect.
• אם פרויקט בענן של Google יוסר מ-consumerAcceptList, ה-NEGs הקיימים של Private Service Connect באותו פרויקט שהוסר ימשיכו לפעול. עם זאת, כל קבוצת NEG חדשה תידחה. אם מסירים פרויקטים משויכים מ-consumerAcceptList, צריך למחוק את ה-NEGs הקיימים. אפשרות אחרת היא ליצור מחדש את מופע Apigee, וכך ליצור מחדש את קובץ השירות בפרויקט Apigee.

שלב 8א: הגדרת משתני סביבה

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

בנוסף, מגדירים את משתני הסביבה הבאים:

מגדירים את משתני הסביבה הבאים במסוף הפקודות:

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

NEG_NAME=YOUR_NEG_NAME"
TARGET_SERVICE=YOUR_TARGET_SERVICE"
NETWORK_NAME=YOUR_NETWORK_NAME"
SUBNET_NAME=YOUR_SUBNET_NAME"

כאשר:

• ‫NEG_NAME: שם לקבוצת נקודות הקצה ברשת.
• ‫TARGET_SERVICE: קובץ השירות שאליו רוצים להתחבר. לדוגמה: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
• ‫NETWORK_NAME: (אופציונלי) שם הרשת שבה נוצר ה-NEG. אם לא מציינים את הפרמטר הזה, נעשה שימוש ברשת של פרויקט default.
• ‫SUBNET_NAME: השם של תת-הרשת שמשמשת לקישוריות פרטית אל היצרן. גודל תת-הרשת יכול להיות קטן: ה-NEG של Private Service Connect צריך רק כתובת IP אחת מתת-הרשת. ב-Apigee, נדרש רק NEG אחד של Private Service Connect לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות. אם לא מציינים רשת משנה, נקודות קצה ברשת יכולות להיות שייכות לכל רשת משנה באזור שבו נוצרה קבוצת נקודות הקצה ברשת.
  הערה: אם מציינים את הפרמטר --network,צריך לציין גם את הפרמטר --subnet.

שלב 8ב: יצירת רשת משנה לשרת proxy בלבד

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

gcloud compute networks subnets create testproxyonlysubnet \
  --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$RUNTIME_REGION --network=$NETWORK_NAME \
  --range=100.0.0.0/24 --project=$PROJECT_ID

שלב 8c: יצירת קבוצת נקודות קצה ברשת (NEG)

1. מקבלים את קובץ השירות מהמכונה שיצרתם קודם:

   curl -i -X GET -H "$AUTH" \
   "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   בדוגמת הפלט הבאה, הערך serviceAttachment מוצג בטקסט מודגש:

   {
   "instances": [
     {
       "name": "us-west1",
       "location": "us-west1",
       "createdAt": "1645731488019",
       "lastModifiedAt": "1646504754219",
       "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
       "state": "ACTIVE",
       "runtimeVersion": "1-7-0-20220228-190814",
       "consumerAcceptList": [
         "my-project"
       ],
       "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
     }
   ]
   }

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

2. יוצרים Private Service Connect NEG שמצביע על קובץ השירות שקיבלתם מגוף התגובה של המופע בשלב הקודם.

   gcloud compute network-endpoint-groups create $NEG_NAME \
   --network-endpoint-type=private-service-connect \
   --psc-target-service=$TARGET_SERVICE \
   --region=$RUNTIME_LOCATION \
   --project=$PROJECT_ID

שלב 8ד: הגדרת מאזן עומסים פנימי אזורי

1. שומרים כתובת IPv4 פנימית למאזן העומסים.

   gcloud compute addresses create ADDRESS_NAME \
   --ip-version=IPV4 --subnet=$SUBNET_NAME \
     --region=$RUNTIME_LOCATION --project=$PROJECT_ID

   מחליפים את ADDRESS_NAME בשם של משאב כתובת ה-IP.

   מריצים את הפקודה הבאה כדי לראות את כתובת ה-IP השמורה:

   gcloud compute addresses describe ADDRESS_NAME \
   --format="get(address)" --region=RUNTIME_LOCATION --project=$PROJECT_ID

2. יוצרים שירות לקצה העורפי עבור ה-NEG.

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=HTTPS \
   --region=$RUNTIME_REGION \
   --project=$PROJECT_ID

מחליפים את BACKEND_SERVICE_NAME בשם של שירות ה-Backend.

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

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
   --network-endpoint-group=NEG_NAME \
   --region=$RUNTIME_LOCATION \
   --project=$PROJECT_ID

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

   • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
   • ‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת.

4. כדי להשתמש ב-proxy יעד מסוג HTTPS, צריך משאב של אישור SSL.

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

   הערה: מאזני עומסים אזוריים פנימיים לא תומכים באישור שמונפק על ידי Google.

   gcloud compute ssl-certificates create CERTIFICATE \
   --certificate LB_CERT \
   --private-key LB_PRIVATE_KEY
   --region=RUNTIME_LOCATION --project=$PROJECT_ID

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

   • ‫CERTIFICATE: שם לאישור.
   • ‫LB_CERT: הנתיב לקובץ האישור בפורמט PEM של האישור בניהול עצמי.
   • ‫LB_PRIVATE_KEY: הנתיב לקובץ המפתח הפרטי בפורמט PEM של האישור בניהול עצמי.

5. יוצרים מפת URL למאזן העומסים.

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

   gcloud compute url-maps create URL_MAP_NAME \
       --default-service=DEFAULT_BACKEND_SERVICE_NAME \
       --global --project=$PROJECT_ID

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

   • ‫URL_MAP_NAME: שם למפת URL.
   • ‫DEFAULT_BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי שמוגדר כברירת המחדל במאזן העומסים. ברירת המחדל משמשת כשאין כלל מארח שתואם לשם המארח המבוקש.

6. משתמשים במשאב של אישור SSL כדי ליצור proxy יעד של HTTPS.

   gcloud compute target-https-proxies create PROXY_NAME \
   --url-map=URL_MAP_NAME \
   --ssl-certificates=CERTIFICATE \
   --region=$RUNTIME_LOCATION --project=$PROJECT_ID

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

   • ‫PROXY_NAME: שם ל-proxy ל-HTTPS עם יעד.
   • ‫URL_MAP_NAME: השם של מפת URL.
   • ‫CERTIFICATE: השם של משאב האישור.
7. יוצרים את כלל ההעברה.

   gcloud compute forwarding-rules create FWD_RULE \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --address=ADDRESS_NAME \
   --target-https-proxy=PROXY_NAME \
   --ports=443 \
   --target-https-proxy-region=$RUNTIME_REGION \
   --region=$RUNTIME_REGION
   --project=$PROJECT_ID

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

   • ‫FWD_RULE: שם לכלל ההעברה.
   • ‫ADDRESS_NAME: משאב כתובת ה-IP שהזמנתם לשימוש בכלל ההעברה.
   • ‫PROXY_NAME: השם של שרת ה-proxy ל-HTTPS של היעד.

הקצאת הרשאות ל-Apigee הושלמה. עוברים אל פריסת שרת proxy לדוגמה.

ניתוב חיצוני (Private Service Connect)

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

ההרשאות שנדרשות למשימה הזו

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

הגבלות: חשוב לשים לב להגבלות הבאות בהגדרת Private Service Connect:

• אין תמיכה במאזן עומסים גלובלי חיצוני מסוג HTTP(S) (קלאסי) בהגדרה הזו.
• במעבר אוטומטי לגיבוי עם כמה קבוצות של נקודות קצה ברשת פרטית (Private Service Connect), לא נתמכות בדיקות תקינות פעילות. במקום זאת, צריך להשתמש בזיהוי חריגים.
• יש מגבלות על מספר הפרויקטים ב-Google Cloud שאפשר לחבר למופע Apigee באמצעות Private Service Connect, ועל מספר החיבורים של Private Service Connect NEG שאפשר ליצור לכל פרויקט. פרטים נוספים זמינים במאמר מגבלות של Private Service Connect.
• אם פרויקט בענן של Google יוסר מ-consumerAcceptList, ה-NEGs הקיימים של Private Service Connect באותו פרויקט שהוסר ימשיכו לפעול. עם זאת, כל קבוצת NEG חדשה תידחה. אם מסירים פרויקטים משויכים מ-consumerAcceptList, צריך למחוק את ה-NEGs הקיימים. אפשרות אחרת היא ליצור מחדש את מופע Apigee, וכך ליצור מחדש את קובץ השירות בפרויקט Apigee.

שלב 8ב: יצירת NEG והגדרת מאזן העומסים

אפשר ליצור מאזן עומסים גלובלי או אזורי.

מאזן עומסים חיצוני גלובלי

הגדרת מאזן עומסים חיצוני גלובלי מסוג HTTP(S) (סכימת איזון העומסים מוגדרת לערך EXTERNAL_MANAGED).

למרות ש-NEG של Private Service Connect הוא אזורי, כל שאר רכיבי איזון העומסים בהגדרה הזו הם גלובליים.

1. מוודאים שהגדרתם את משתני הסביבה לפי ההוראות שבמאמר הגדרה של משתני סביבה.
2. מקבלים את קובץ השירות מהמכונה שיצרתם קודם:

   curl -i -X GET -H "$AUTH" \
         "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   בדוגמת הפלט הבאה, הערך serviceAttachment מוצג בטקסט מודגש:

   {
         "instances": [
           {
             "name": "us-west1",
             "location": "us-west1",
             "host": "10.82.192.2",
             "port": "443",
             "createdAt": "1645731488019",
             "lastModifiedAt": "1646504754219",
             "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
             "state": "ACTIVE",
             "peeringCidrRange": "SLASH_22",
             "runtimeVersion": "1-7-0-20220228-190814",
             "ipRange": "10.82.192.0/22,10.82.196.0/28",
             "consumerAcceptList": [
               "875609189304"
             ],
             "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
           }
         ]
       }

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

3. יוצרים Private Service Connect NEG שמפנה לקובץ המצורף עם השירות שקיבלתם מגוף התגובה של המופע בשלב הקודם.

       gcloud compute network-endpoint-groups create $NEG_NAME \
         --network-endpoint-type=private-service-connect \
         --psc-target-service=$TARGET_SERVICE \
         --region=$RUNTIME_LOCATION \
         --network=NETWORK_NAME \
         --subnet=SUBNET_NAME \
         --project=$PROJECT_ID
       

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

   • ‫NETWORK_NAME: (אופציונלי) שם הרשת שבה נוצר ה-NEG. אם לא מציינים את הפרמטר הזה, נעשה שימוש ברשת של פרויקט default.
   • ‫SUBNET_NAME: השם של תת-הרשת שמשמשת לקישוריות פרטית אל היצרן. גודל תת-הרשת יכול להיות קטן: ה-NEG של Private Service Connect צריך רק כתובת IP אחת מתת-הרשת. ב-Apigee, נדרש רק NEG אחד של Private Service Connect לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות. אם לא מציינים רשת משנה, יכול להיות שנקודות קצה ברשת ישתייכו לכל רשת משנה באזור שבו נוצרה קבוצת נקודות הקצה ברשת.
     הערה: אם מציינים את הפרמטר --network,צריך לציין גם את הפרמטר --subnet.
   • PROJECT_ID פרויקט בענן שכבר משויך לארגון Apigee, או פרויקט בענן שנכלל ב-consumerAcceptlist כשנוצר מופע זמן הריצה של Apigee.
4. שומרים כתובת IPv4 חיצונית גלובלית למאזן העומסים.

   gcloud compute addresses create ADDRESS_NAME \
     --ip-version=IPV4 --global --project=$PROJECT_ID

   מחליפים את ADDRESS_NAME בשם של משאב כתובת ה-IP.

   מריצים את הפקודה הבאה כדי לראות את כתובת ה-IP השמורה:

   gcloud compute addresses describe ADDRESS_NAME \
     --format="get(address)" --global --project=$PROJECT_ID

5. יוצרים שירות לקצה העורפי עבור ה-NEG.

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme=EXTERNAL_MANAGED \
     --protocol=HTTPS \
     --global --project=$PROJECT_ID

מחליפים את BACKEND_SERVICE_NAME בשם של שירות ה-Backend.

6. מוסיפים את שירות לקצה העורפי ל-NEG.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --network-endpoint-group-region=$REGION \
     --global --project=$PROJECT_ID

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

   • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
   • ‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת.
   • ‫REGION: האזור של קבוצת נקודות הקצה ברשת.

7. יוצרים מפת URL למאזן העומסים.

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

   gcloud compute url-maps create URL_MAP_NAME \
     --default-service=DEFAULT_BACKEND_SERVICE_NAME \
     --global --project=$PROJECT_ID

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

   • ‫URL_MAP_NAME: שם למפת URL.
   • ‫DEFAULT_BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי שמוגדר כברירת המחדל במאזן העומסים. ברירת המחדל משמשת כשאין כלל מארח שתואם לשם המארח המבוקש.

8. יוצרים את שרת ה-proxy של HTTPS ליעד.

   כדי להשתמש ב-proxy יעד מסוג HTTPS, צריך משאב של אישור SSL. אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. מומלץ להשתמש באישורים שמנוהלים על ידי Google, כי Google Cloud מקבלת, מנהלת ומחדשת את האישורים האלה באופן אוטומטי.

   כדי ליצור אישור שמנוהל על ידי Google, צריך להיות לכם דומיין.

   משתמשים בפקודה הזו כדי ליצור משאב של אישור SSL בניהול Google:

   gcloud compute ssl-certificates create CERTIFICATE \
     --domains DOMAIN --project=$PROJECT_ID

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

   • ‫CERTIFICATE: שם לאישור.
   • ‫DOMAIN: שם הדומיין של מאזן העומסים.

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

   gcloud compute ssl-certificates create CERTIFICATE \
     --certificate LB_CERT \
     --private-key LB_PRIVATE_KEY --project=$PROJECT_ID

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

   • ‫CERTIFICATE: שם לאישור.
   • ‫LB_CERT: הנתיב לקובץ האישור בפורמט PEM של האישור בניהול עצמי.
   • ‫LB_PRIVATE_KEY: הנתיב לקובץ המפתח הפרטי בפורמט PEM של האישור בניהול עצמי.

   משתמשים במשאב של אישור SSL כדי ליצור proxy יעד של HTTPS.

   gcloud compute target-https-proxies create PROXY_NAME \
     --url-map=URL_MAP_NAME \
     --ssl-certificates=CERTIFICATE --project=$PROJECT_ID

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

   • ‫PROXY_NAME: שם ל-proxy ל-HTTPS עם יעד.
   • ‫URL_MAP_NAME: השם של מפת URL.
   • ‫CERTIFICATE: השם של משאב האישור.
9. יוצרים את כלל ההעברה.

   gcloud compute forwarding-rules create FWD_RULE \
     --load-balancing-scheme=EXTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --address=ADDRESS_NAME \
     --target-https-proxy=PROXY_NAME \
     --ports=443 \
     --global --project=$PROJECT_ID

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

   • ‫FWD_RULE: שם לכלל ההעברה.
   • ‫ADDRESS_NAME: משאב כתובת ה-IP שהזמנתם לשימוש בכלל ההעברה.
   • ‫PROXY_NAME: השם של שרת ה-proxy ל-HTTPS של היעד.

הקצאת הרשאות ל-Apigee הושלמה. עוברים אל פריסת שרת proxy לדוגמה.

מאזן עומסים חיצוני אזורי

הגדרת מאזן עומסים חיצוני אזורי מסוג HTTP(S). מידע נוסף סקירה כללית של מאזן עומסים חיצוני מסוג HTTP(S)

1. חשוב לוודא שהגדרתם את המשתנים בקטע הגדרת משתני סביבה.
2. יוצרים תת-רשת של שרת proxy בלבד:
   הערה: זו פעולה חד-פעמית. את רשת המשנה הזו שכוללת רק שרת proxy צריך ליצור רק פעם אחת לכל פרויקט בענן ב-Google Cloud, לכל איזון עומסים אזורי שמבוסס על Envoy. מידע נוסף זמין במאמר בנושא תת-רשתות של שרת proxy בלבד למאזני עומסים מבוססי Envoy.

   gcloud compute networks subnets create SUBNET_NAME \
     --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE \
     --region=$RUNTIME_LOCATION --network=NETWORK_NAME \
     --range=100.0.0.0/24 --project=$PROJECT_ID

   • מחליפים את SUBNET_NAME בשם של רשת המשנה.
   • (אופציונלי) מחליפים את NETWORK_NAME בשם הרשת שבה נוצרת רשת המשנה. אם לא מציינים את הפרמטר הזה, נעשה שימוש ברשת הפרויקט שמוגדרת כברירת מחדל.
3. מקבלים את קובץ השירות מהמכונה שיצרתם קודם:

   curl -i -X GET -H "$AUTH" \
           "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   בדוגמת הפלט הבאה, הערך serviceAttachment מוצג בטקסט מודגש:

   {
           "instances": [
             {
               "name": "us-west1",
               "location": "us-west1",
               "host": "10.82.192.2",
               "port": "443",
               "createdAt": "1645731488019",
               "lastModifiedAt": "1646504754219",
               "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
               "state": "ACTIVE",
               "peeringCidrRange": "SLASH_22",
               "runtimeVersion": "1-7-0-20220228-190814",
               "ipRange": "10.82.192.0/22,10.82.196.0/28",
               "consumerAcceptList": [
                 "875609189304"
               ],
               "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
             }
           ]
         }

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

   gcloud compute network-endpoint-groups create NEG_NAME \
           --network-endpoint-type=private-service-connect \
           --psc-target-service=TARGET_SERVICE \
           --region=$RUNTIME_LOCATION --project=$PROJECT_ID

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

   • ‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת.
   • ‫TARGET_SERVICE: השם של קובץ השירות שאליו רוצים להתחבר. לדוגמה: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
5. יוצרים שירות לקצה העורפי עבור ה-NEG.

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme=EXTERNAL_MANAGED \
     --protocol=HTTPS \
     --region=$RUNTIME_LOCATION  \
     --project=$PROJECT_ID

מחליפים את BACKEND_SERVICE_NAME בשם של שירות ה-Backend.

6. מוסיפים את שירות לקצה העורפי ל-NEG.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --region=$RUNTIME_LOCATION  \
     --project=$PROJECT_ID

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

   • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
   • ‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת.

7. יוצרים מפת URL למאזן העומסים.

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

   gcloud compute url-maps create URL_MAP_NAME \
     --default-service=DEFAULT_BACKEND_SERVICE_NAME \
     --region=$RUNTIME_LOCATION  \
     --project=$PROJECT_ID

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

   • ‫URL_MAP_NAME: שם למפת URL.
   • ‫DEFAULT_BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי שמוגדר כברירת המחדל במאזן העומסים. ברירת המחדל משמשת כשאין כלל מארח שתואם לשם המארח המבוקש.

8. יוצרים את שרת ה-proxy של HTTPS ליעד.

   כדי להשתמש ב-proxy יעד מסוג HTTPS, צריך משאב של אישור SSL.

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

   הערה: מאזן עומסים אזורי חיצוני לא תומך באישורים שמנוהלים על ידי Google.

   gcloud compute ssl-certificates create CERTIFICATE \
     --certificate LB_CERT \
     --private-key LB_PRIVATE_KEY --region=$RUNTIME_LOCATION \
     --project=$PROJECT_ID

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

   • ‫CERTIFICATE: שם לאישור.
   • ‫LB_CERT: הנתיב לקובץ האישור בפורמט PEM של האישור בניהול עצמי.
   • ‫LB_PRIVATE_KEY: הנתיב לקובץ המפתח הפרטי בפורמט PEM של האישור בניהול עצמי.
9. מוסיפים את הדומיין לקבוצת הסביבות של Apigee שנוצרה בשבילכם. השם של קבוצת הסביבות הוא eval-group:

   curl "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups/eval-group" \
         -H "$AUTH" \
         -X PATCH \
         -H "Content-Type:application/json" \
         -d '{
           "hostnames":["'"DOMAIN"'"]
         }'

10. בודקים את הסטטוס של הפעולה בקבוצת הסביבות:

    curl -H "$AUTH" \
          "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups/eval-group/attachments"
        

11. משתמשים במשאב של אישור SSL כדי ליצור proxy יעד של HTTPS.

    gcloud compute target-https-proxies create PROXY_NAME \
      --url-map=URL_MAP_NAME --region=$RUNTIME_LOCATION \
      --ssl-certificates=CERTIFICATE --project=$PROJECT_ID

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

    • ‫PROXY_NAME: שם ל-proxy ל-HTTPS עם יעד.
    • ‫URL_MAP_NAME: השם של מפת URL.
    • ‫CERTIFICATE: השם של משאב האישור.
12. שמירת כתובת חיצונית אזורית למאזן העומסים. הערה: צריך להגדיר את רמת הרשת ל-STANDARD.

    gcloud compute addresses create ADDRESS_NAME \
          --region=$RUNTIME_LOCATION --network-tier=STANDARD \
          --project=$PROJECT_ID

    מחליפים את ADDRESS_NAME בשם של משאב כתובת ה-IP.

    מריצים את הפקודה הבאה כדי לראות את כתובת ה-IP השמורה:

    gcloud compute addresses describe ADDRESS_NAME \
          --format="get(address)" --region=$RUNTIME_LOCATION \
          --project=$PROJECT_ID

13. יוצרים את כלל ההעברה.

    gcloud compute forwarding-rules create FWD_RULE \
      --load-balancing-scheme=EXTERNAL_MANAGED \
      --network-tier=STANDARD \
      --address=ADDRESS_NAME \
      --target-https-proxy=PROXY_NAME \
      --ports=443  --region=$RUNTIME_LOCATION \
      --target-https-proxy-region=$RUNTIME_LOCATION --project=$PROJECT_ID

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

    • ‫FWD_RULE: שם לכלל ההעברה.
    • ‫ADDRESS_NAME: משאב כתובת ה-IP שהזמנתם לשימוש בכלל ההעברה.
    • ‫PROXY_NAME: השם של שרת ה-proxy ל-HTTPS של היעד.

הקצאת הרשאות ל-Apigee הושלמה. עוברים אל קריאה ל-proxy לדוגמה של ה-API.

שלב 5: קוראים ל-proxy ל-API לדוגמה

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

ההרשאות שנדרשות למשימה הזו

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

קריאה ל-proxy ל-API עם ניתוב פנימי

אם בחרתם באפשרות ניתוב פנימי עם נקודת קצה של שירות בשלב 5, פועלים לפי השלבים במאמר קריאה ל-proxy ל-API עם גישה פנימית בלבד.

קריאה ל-proxy ל-API עם ניתוב חיצוני

אם בחרתם באפשרות ניתוב חיצוני בשלב 5, צריך לפעול לפי השלבים שבקטע הזה.

1. מגדירים רשומת DNS לדומיין. יש שתי דרכים לעשות את זה:
   • אצל הרשם, יוצרים רשומת A שמפנה לדומיין. לדוגמה, אם הדומיין שלכם הוא sales.example.com וכתובת ה-IP היא 10.23.0.2, צריך להפנות את הרשומה של sales.example.com לכתובת 10.23.0.2.

     מריצים את הפקודה הבאה כדי לראות את כתובת ה-IP השמורה:

     gcloud compute addresses describe ADDRESS_NAME \
         --format="get(address)" --region=$RUNTIME_LOCATION \
         --project=$PROJECT_ID

   • אפשר להשתמש ב-Cloud DNS של Google כדי למפות כתובת URL לכתובת IP.
2. מוודאים ששרת ה-proxy‏ hello-world נפרס:

   curl -i -H "$AUTH" \
     "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/environments/eval/apis/hello-world/revisions/1/deployments"

3. קוראים ל-proxy ל-API:

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

   curl -i -H "Host: DOMAIN" \
     https://DOMAIN/hello-world

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

   curl -i -H "$AUTH" \
     "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups"

   אם הפעולה מצליחה, proxy ה-API לדוגמה מחזיר את התגובה:

   Hello, Guest!

   טיפים לפתרון בעיות:

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

   חשוב לוודא שלדומיין הרשום יש רשומת A שמפנה לכתובת ה-IPv4 החיצונית הגלובלית שנוצרה בשלב 5. מריצים את הפקודה הבאה כדי לראות את כתובת ה-IP השמורה:

   gcloud compute addresses describe ADDRESS_NAME \
                 --format="get(address)" --region=$RUNTIME_LOCATION \
                 --project=$PROJECT_ID

   אם לא הצלחתם לפתור את הבעיה בהגדרת הדומיין, נסו להפעיל את ה-proxy באמצעות הפקודה הבאה:

   curl  -H Host:DOMAIN --resolve \
     DOMAIN:443:EXTERNAL_IP_ADDRESS  \
     https://DOMAIN:443/hello-world -k

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

המאמר הבא: מידע נוסף על בנייה ופריסה של שרתי proxy ל-API זמין במאמר סקירה כללית על בניית שרת ה-proxy הראשון ל-API.