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

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

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

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

אפשרות הקצאת הרשאות	אפשרות Networking	שלבי הקצאת ההרשאות
מינוי בתשלום	עם קישור בין רשתות VPC שכנות (peering)	ניתוב פנימי (VPC) ניתוב פנימי (Private Service Connect)
Pay-as-you-go	עם קישור בין רשתות VPC שכנות (peering)	ניתוב פנימי (VPC) ניתוב פנימי (Private Service Connect)
הערכה	עם קישור בין רשתות VPC שכנות (peering)	הגדרת ניתוב (פנימי)
הערכה	ללא קישור בין רשתות VPC שכנות (peering)	ניתוב פנימי (Private Service Connect)

אפשר לעיין גם במאמר בנושא אפשרויות רשת.

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

מבצעים את שלבי ההגדרה המקדימים הבאים:

1. אם עדיין לא עשיתם זאת, מפעילים את Cloud SDK כמו שמתואר במאמר הפעלת ה-CLI של gcloud, או מוודאים שהפרויקט ב-Google Cloud שיצרתם בשלב דרישות מוקדמות הוא פרויקט ברירת המחדל עבור gcloud.

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

   export PROJECT_ID=YOUR_PROJECT_ID
   export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
   export SUBNET=NETWORK_NAME
   export INSTANCE_NAME=INSTANCE_NAME
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

   כאשר:

   • ‫PROJECT_ID הוא מזהה הפרויקט בענן שיצרתם במסגרת הדרישות המוקדמות.
   • ‫AUTH מגדיר את הכותרת Authentication עם אסימון Bearer. תשתמשו בכותרת הזו כשתיגשו לממשקי Apigee API. שימו לב שהאסימון יפוג אחרי פרק זמן מסוים, ואז תוכלו פשוט ליצור אותו מחדש באמצעות אותה פקודה. מידע נוסף זמין בדף העיון בנושא הפקודה print-access-token.
   • ‫SUBNET היא רשת המשנה שצוינה במהלך הקצאת המשאבים. לדוגמה: default.
   • ‫INSTANCE_NAME: השם של המופע החדש. לדוגמה, my-runtime-instance. השם חייב להתחיל באות קטנה באנגלית, יכול להיות באורך של עד 32 תווים, ויכול לכלול רק אותיות קטנות, מספרים ומקפים. הוא לא יכול להתחיל או להסתיים במקף, והוא חייב להיות באורך של שני תווים לפחות.
     טיפ: שם המופע צריך להתאים לביטוי הרגולרי הבא:

     ^[a-z][a-z\-\d]{0,30}[a-z\d]$

   • ‫PROJECT_NUMBER הוא מספר הפרויקט ב-Cloud שיצרתם במסגרת הדרישות המוקדמות. בדוגמה הזו מריצים את הפקודה gcloud כדי לקבל את מספר הפרויקט.
3. מקבלים את הערך של הנכס location ממופע Apigee. הערך הזה הוא האזור שבו נמצאת מכונת ה-VM, למשל us-west1:

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

4. בוחרים אזור בתוך האזור של המכונה, ומציבים את שם האזור במשתנה. האזור חייב להיות בתוך המכונה. לדוגמה:

   export VM_ZONE="us-west1-b"

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

   VM_ZONE=$(gcloud compute zones list | grep "us-west1" | head -n 1 | awk '{print $1}')

יצירת VM והפעלת proxy ל-API

בשלב הבא, יוצרים מכונה וירטואלית חדשה בתוך רשת VPC באמצעות הפקודה gcloud beta compute: המכונה הווירטואלית פועלת כגשר שמאפשר לכם לשלוח בקשות לכתובת ה-IP של מאזן העומסים הפנימי. אחרי שה-VM מוגדר, אפשר לקרוא ל-proxy ל-API שנפרס:

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

   gcloud beta compute --project=$PROJECT_ID \
     instances create $INSTANCE_NAME \
     --zone=$VM_ZONE \
     --machine-type=e2-micro \
     --subnet=$SUBNET \
     --network-tier=PREMIUM \
     --no-restart-on-failure \
     --maintenance-policy=TERMINATE \
     --preemptible \
     --service-account=$[e-mail] \
     --scopes=https://www.googleapis.com/auth/cloud-platform \
     --tags=http-server,https-server \
     --image=debian-12-bookworm-v20240701 \
     --image-project=debian-cloud \
     --boot-disk-size=10GB \
     --boot-disk-type=pd-standard \
     --boot-disk-device-name=$INSTANCE_NAME \
     --no-shielded-secure-boot \
     --shielded-vtpm \
     --shielded-integrity-monitoring \
     --reservation-affinity=any

2. פותחים חיבור מאובטח למכונה הווירטואלית החדשה שיצרתם.

   gcloud compute ssh $INSTANCE_NAME --zone=$VM_ZONE --project=$PROJECT_ID

   הערה: אם הפקודה ssh נכשלת או נתקעת, מריצים את הפקודה הבאה כדי ליצור כלל בחומת האש שיאפשר גישה, ואז חוזרים על הפקודה gcloud compute ssh:

   gcloud compute --project=$PROJECT_ID firewall-rules create allow-ssh \
           --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp:22 \
           --source-ranges=0.0.0.0/0

3. במעטפת של המכונה הווירטואלית, מתקינים את כלי השירות jq. הוא משמש בשלבים הבאים:

   sudo apt-get update -y
   sudo apt-get install -y jq
   

4. במעטפת של מכונת ה-VM, יוצרים את משתני הסביבה הבאים כדי שיהיה קל להעתיק ולהדביק את בקשת ה-proxy ל-API:

   export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
   export PROJECT_ID=YOUR_PROJECT_ID
   export ENV_GROUP_HOSTNAME=$(curl -H "$AUTH" https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups -s | jq -r '.environmentGroups[0].hostnames[0]')
   

5. מוודאים שהמשתנים מוגדרים בצורה נכונה:

   echo $AUTH
   echo $PROJECT_ID
   echo $ENV_GROUP_HOSTNAME

6. שליחת קריאה ל-proxy ל-API. בוחרים באחת מהאפשרויות שלמטה בהתאם לאופן שבו הגדרתם את הניתוב במהלך הקצאת הרשאות ב-Apigee.

   אפשרויות להתקנות שמשתמשות בקישור בין רשתות VPC שכנות (peering)

   • (אפשרות TLS מספר 1) אם הגדרתם מאזן עומסים פנימי (ILB) בפרויקט, כמו שמוסבר במאמר ניתוב פנימי (VPC), צריך לקרוא לשרת ה-proxy באמצעות כתובת ה-IP של מאזן העומסים הפנימי הזה. באפשרות הזו נעשה שימוש באישור CA שנמצא בשליטתכם ושנוצר כשנוצר מאזן העומסים הפנימי:
     שימו לב: בגלל מגבלה במאזן העומסים הפנימי של אפליקציות ב-Google Cloud, אפשרות הניתוב הפנימי של Apigee לא תומכת בבקשות HTTP 1.0. בקשות נכנסות של לקוחות שמציינות את פרוטוקול HTTP 1.0 ייכשלו. יש תמיכה בגרסאות מאוחרות יותר של HTTP.
     1. מקבלים את כתובת ה-IP של ILB בפרויקט, כמו שמוסבר במאמר הגדרת איזון עומסים פנימי של HTTP(S) עם עורפי קצה של קבוצת מכונות וירטואליות.
     2. שליחת קריאה ל-proxy ל-API:

        curl -H "Host: $ENV_GROUP_HOSTNAME" \
          https://INTERNAL_LOAD_BALANCER_IP/PROXY_BASEPATH

   • (אפשרות TLS מספר 2) שימוש בשם הדומיין המוגדר במלואו שמוגדר כברירת מחדל, שמפנה למאזן העומסים הפנימי בפרויקט Apigee. באפשרות הזו, נעשה שימוש ב-TLS באמצעות אישורים בחתימה עצמית של Apigee שנוצרו באופן פנימי. אין לכם שליטה על האישורים האלה.
     שימו לב: בגלל מגבלה במאזן עומסים פנימי של אפליקציות ב-Google Cloud, אפשרות הניתוב הפנימי של Apigee לא תומכת בבקשות HTTP 1.0. בקשות נכנסות של לקוחות שמציינות את פרוטוקול HTTP 1.0 ייכשלו. יש תמיכה בגרסאות מאוחרות יותר של HTTP.
     1. מקבלים את כתובת ה-IP של מאזן העומסים הפנימי בפרויקט Apigee:

        export INTERNAL_LOAD_BALANCER_IP=$(curl -H "$AUTH" https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances -s | jq -r '.instances[0].host')

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

        curl -H "$AUTH" https://apigee.googleapis.com/v1/organizations/$PROJECT_ID | jq -r .caCertificate | base64 -d > cacert.crt

     3. שולחים את הבקשה ל-proxy ל-API שפרסו, כאשר example.$PROJECT_ID.apigee.internal הוא שם דומיין שמוגדר במלואו, שמוביל למאזן העומסים הפנימי.

        curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
          https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
          --cacert cacert.crt \
          --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP

   • (אפשרות ללא TLS) אם נתקלתם בבעיות באימות אישורי SSL/TLS, אתם יכולים להשתמש בדגל -k (או --insecure) עם הפקודה curl. הפעולה הזו עוקפת את אימות האישור ומאפשרת להמשיך את החיבור. חשוב לדעת שגם אם התקשורת נשארת מוצפנת, לאפשרות הזו יש השלכות על האבטחה כי לא מתבצע אימות של האותנטיות של השרת.
     1. מקבלים את כתובת ה-IP של מאזן העומסים הפנימי בפרויקט Apigee:

        export INTERNAL_LOAD_BALANCER_IP=$(curl -H "$AUTH" https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances -s | jq -r '.instances[0].host')

     2. שליחת קריאה ל-proxy ל-API:

        curl -i -k \
          -H "Host: $ENV_GROUP_HOSTNAME" \
          https://$INTERNAL_LOAD_BALANCER_IP/PROXY_BASEPATH

   • (אפשרות של נקודת קצה של שירות) אם הקציתם ארגון בתשלום או ארגון לצורך הערכה עם Private Service Connect ובחרתם באפשרות הניתוב של נקודת קצה של שירות:
   1. מקבלים את כתובת ה-IP של נקודת הקצה של השירות. אם אתם צריכים לחפש את כתובת ה-IP של נקודת הקצה, תוכלו לעיין במאמר בנושא רשימת נקודות קצה.
   2. שליחת קריאה ל-proxy ל-API:

      curl -i -k \
         -H "Host: $ENV_GROUP_HOSTNAME" \
         https://SERVICE_ENDPOINT_IP/PROXY_BASEPATH

      לדוגמה:

      curl -H "Host: $ENV_GROUP_HOSTNAME" https://10.138.0.2/helloworld -k

   אפשרויות להתקנות שלא משתמשות בקישור בין רשתות VPC שכנות (peering)

   • (אפשרות של נקודת קצה של שירות) אם הקציתם ארגון בתשלום או ארגון לצורך הערכה באמצעות Private Service Connect ובחרתם באפשרות הניתוב של נקודת הקצה של השירות:
   1. מקבלים את כתובת ה-IP של נקודת הקצה של השירות. אם אתם צריכים לחפש את כתובת ה-IP של נקודת הקצה, תוכלו לעיין במאמר בנושא רשימת נקודות קצה.
   2. שליחת קריאה ל-proxy ל-API:

      curl -i -k \
          -H "Host: $ENV_GROUP_HOSTNAME" \
          https://SERVICE_ENDPOINT_IP/PROXY_BASEPATH

      לדוגמה:

      curl -H "Host: $ENV_GROUP_HOSTNAME" https://10.138.0.2/helloworld -k

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

   השלב הבא

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

   (מתקדם) אם אתם מתכננים להפוך את ההגדרה הזו להגדרת ייצור, אתם יכולים להגדיר היקף אבטחה סביב האשכול החדש ושירותי ה-Cloud הקשורים. אפשר לעשות את זה באמצעות VPC Service Controls.