במאמר הזה מוסבר איך להתקין ולהגדיר את Apigee משורת הפקודה
עם VPC peering. השלבים האלה רלוונטיים גם למודלים של מינוי וגם למודלים של תשלום לפי שימוש בארגונים בתשלום, עם או בלי שמירת נתונים במדינה מסוימת.
סיכום השלבים
אלה השלבים להקצאת הרשאות:
שלב 1: הגדרת משתני סביבה:
מגדירים את gcloud ומגדירים משתני סביבה.
הכלי Google Cloud CLI מנהל את האימות, ההגדרה המקומית, תהליך העבודה של המפתחים והאינטראקציות עם ממשקי Google Cloud APIs.
שלב 4: הגדרת Service Networking: Service Networking מאפשר אוטומציה של הגדרת הקישוריות הפרטית (באמצעות קישור בין רשתות VPC שכנות – peering) בין הרשת שלכם לבין Apigee.
שלב 5: יצירת ארגון: ארגון Apigee (לפעמים נקרא org) הוא מאגר ברמה העליונה ב-Apigee. הוא כולל את כל הסביבות וקבוצות הסביבות, המשתמשים, פרוקסי ה-API והמשאבים הקשורים.
שלב 6: יצירת מופע של זמן ריצה: מופע, או זמן ריצה, הוא המקום שבו הפרויקט והשירותים שקשורים אליו מאוחסנים. הוא מספק את נקודת הקצה שפונה למשתמשים עבור השירותים שלכם.
שלב 7: יוצרים סביבה: צריך לפרוס proxy ל-API בסביבה ולהוסיף אותו לקבוצת סביבות כדי שה-API שהוא חושף יהיה נגיש ברשת.
AUTH מגדיר את הכותרת Authentication עם טוקן bearer. תשתמשו בכותרת הזו כשתיגשו לממשקי Apigee API. שימו לב שהטוקן יפוג אחרי פרק זמן מסוים, ואז תוכלו פשוט ליצור אותו מחדש באמצעות אותה פקודה. מידע נוסף זמין בדף העיון בנושא
הפקודה print-access-token.
PROJECT_NUMBER הוא מספר פרויקט בענן שיצרתם כחלק מהדרישות המוקדמות.
RUNTIME_LOCATION הוא המיקום הפיזי שבו נמצא מופע Apigee שתיצרו בהמשך. רשימת המיקומים הזמינים של סביבות זמן ריצה מופיעה במאמר בנושא מיקומי Apigee.
ANALYTICS_REGION הוא המיקום הפיזי שבו יאוחסנו נתוני הניתוח של Apigee. רשימת האזורים שבהם אפשר להשתמש ב-Apigee API Analytics זמינה במאמר מיקומי Apigee.
הערכים של RUNTIME_LOCATION ו-ANALYTICS_REGION יכולים להיות זהים, אבל הם לא חייבים להיות זהים.
BILLING_TYPE הוא סוג החיוב של הארגון שאתם יוצרים. הערכים החוקיים הם:
AUTH מגדיר את הכותרת Authentication עם טוקן bearer. תשתמשו בכותרת הזו כשתיגשו לממשקי Apigee API. שימו לב שהטוקן יפוג אחרי פרק זמן מסוים, ואז תוכלו פשוט ליצור אותו מחדש באמצעות אותה פקודה. מידע נוסף זמין בדף העיון בנושא
הפקודה print-access-token.
PROJECT_NUMBER הוא מספר פרויקט בענן שיצרתם כחלק מהדרישות המוקדמות.
RUNTIME_LOCATION הוא המיקום הפיזי שבו נמצא מופע Apigee שתיצרו בהמשך. רשימת המיקומים הזמינים של סביבות זמן ריצה מופיעה במאמר בנושא מיקומי Apigee.
המיקום של זמן הריצה חייב להיות בתוך
המיקום של מישור הבקרה.
CONTROL_PLANE_LOCATION הוא המיקום הפיזי שבו יאוחסנו נתוני מישור הבקרה של Apigee.
רשימת המיקומים הזמינים של מישור הבקרה מופיעה במאמר מיקומי Apigee.
CONSUMER_DATA_REGION הוא אזור משנה של אזור מישור הבקרה. חובה לציין גם את CONTROL_PLANE_LOCATION וגם את CONSUMER_DATA_REGION.
רשימת האזורים שבהם אפשר לאחסן נתונים של צרכנים זמינה במאמר בנושא מיקומי Apigee.
BILLING_TYPE הוא סוג החיוב של הארגון שאתם יוצרים. הערכים החוקיים הם:
YOUR_TOKEN
my-cloud-project
1234567890
us-west1
us
us-west1
SUBSCRIPTION
שלב 2: הפעלת ממשקי API
ההרשאות שנדרשות למשימה הזו
אפשר לתת למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או לתת הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות שנדרשות. מידע נוסף זמין במאמרים בנושא
תפקידים מוגדרים מראש ו
הרשאות להפעלת API.
כדי להשתמש ב-Apigee, צריך להפעיל כמה ממשקי Google Cloud API. מפעילים אותם על ידי הפעלת הפקודה services enable הבאה:
מוודאים שהסוכן נוצר בהצלחה. התשובה צריכה להציג את שם הסוכן בפורמט הבא:
service-PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com.
לדוגמה:
Service identity created: service-1234567890@gcp-sa-apigee.iam.gserviceaccount.com
שלב 4: הגדרת רשתות שירות
בשלב הזה, מקצים זוג טווחים של כתובות IP (טווח CIDR של /22 ו- /28) ל-Apigee ומבצעים קישור בין רשת ה-VPC לרשת של Apigee. כל מופע של Apigee
דורש טווח CIDR לא חופף של /22 ו- /28. למישור זמן הריצה של Apigee מוקצות כתובות IP מתוך טווח ה-CIDR הזה. לכן חשוב שהטווח יהיה שמור ל-Apigee ולא ישמש אפליקציות אחרות ברשת ה-VPC שלכם. מידע נוסף ושיקולים חשובים מפורטים במאמר הסבר על טווחי peering.
שימו לב שאתם יוצרים טווח מספיק של כתובות IP ברשת עבור מופע אחד של Apigee. אם אתם מתכננים ליצור עוד מופעים של Apigee, תצטרכו לחזור על השלב הזה לכל אחד מהם. אי אפשר לשתף את הטווחים בין מופעים. אפשר לקרוא גם על הרחבת Apigee למספר אזורים.
ההרשאות שנדרשות לביצוע המשימה הזו
אפשר להקצות למנהל ההקצאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות לביצוע המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות. מידע נוסף זמין במאמרים בנושא
תפקידים מוגדרים מראש ו
הרשאות של Service Networking.
RANGE_NAME הוא השם של טווח כתובות ה-IP שאתם יוצרים.
אפשר לתת לטווח כל שם שרוצים. לדוגמה: google-svcs
NETWORK_NAME הוא השם של משאב הרשת שבו צריך לשריין את הכתובות.
Google יוצרת רשת שמוגדרת כברירת מחדל (בשם default) לכל פרויקט חדש, כך שאפשר להשתמש בה. עם זאת,
Google לא ממליצה להשתמש ברשת שמוגדרת כברירת מחדל למטרות אחרות מלבד בדיקות.
יוצרים טווח של כתובות IP ברשת עם אורך CIDR של /22:
כש---addresses מאפשר לציין טווח כתובות. לדוגמה, כדי להקצות את בלוק ה-CIDR 192.168.0.0/22, צריך לציין 192.168.0.0 לכתובת ו-22 לאורך הקידומת. אפשר לעיין גם במאמר בנושא
יצירת הקצאת כתובות IP.
אם לא תציינו את הפרמטר --addresses, gcloud תבחר בשבילכם טווח כתובות זמין.
אם הפעולה מצליחה, gcloud משיב עם הפרטים הבאים:
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs].
אחרי שיוצרים טווח של כתובות IP, הכתובות משויכות לפרויקט עד שמבטלים את השיוך שלהן.
מוודאים שטווח כתובות ה-IP של הרשת נוצר עם אורך CIDR של /22:
כש---addresses מאפשר לציין טווח כתובות. לדוגמה, כדי להקצות את בלוק ה-CIDR 192.168.0.0/28, צריך לציין 192.168.0.0 לכתובת ו-28 לאורך הקידומת. אפשר לעיין גם במאמר בנושא
יצירת הקצאת כתובות IP.
אם לא תציינו את הפרמטר --addresses, gcloud תבחר בשבילכם טווח כתובות זמין.
מוודאים שטווח כתובות ה-IP של הרשת נוצר עם אורך CIDR של /28:
Apigee יוצר חיבור בין הרשת שלכם לבין השירותים של Google. באופן ספציפי,Apigee מקשר את הפרויקט שלכם ל-Service Networking API באמצעות קישור VPC.Apigee גם משייך כתובות IP לפרויקט שלכם.
אחרי כמה דקות, בודקים אם ה-VPC Peering הצליח:
gcloud services vpc-peerings list \
--network=$NETWORK_NAME \
--service=servicenetworking.googleapis.com \
--project=$PROJECT_ID
שלב 5: יצירת ארגון
ההרשאות שנדרשות למשימה הזו
אתם יכולים לתת למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או לתת הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות. מידע נוסף:
לפני שיוצרים ארגון, צריך ליצור מחזיק מפתחות ומפתח להצפנת מסד נתונים בזמן ריצה (ראו שלב 1). אם משתמשים ב
שמירת נתונים באזור מסוים, צריך ליצור מחזיקי מפתחות ומפתחות להצפנת מישור הבקרה (ראו שלב 2). המפתחות האלה של
Cloud KMS מצפינים נתונים שמאוחסנים ומשוכפלים במיקומים של זמן ריצה ושל מישור בקרה. Apigee משתמש בישויות האלה כדי להצפין נתוני אפליקציות כמו KVM, מטמון וסודות לקוח, ואז מאחסן אותם במסד הנתונים. מידע נוסף זמין במאמר בנושא
מפתחות ההצפנה של Apigee.
יצירה של אוסף מפתחות ומפתח להצפנת מסד נתונים בזמן ריצה.
מגדירים משתנה סביבה למיקום של טבעת ההצפנה והמפתח של מסד הנתונים של זמן הריצה. כך תוכלו לשמור על עקביות כשאתם יוצרים אותם, ויהיה לכם קל יותר לעקוב אחרי ההוראות במסמכים.
הערך הוא המיקום הפיזי שבו מאוחסנים מחזיק המפתחות והמפתח של הצפנת מסד הנתונים בזמן הריצה.
אם הבקשה הזו תושלם בהצלחה, gcloud ישיב עם תגובה שדומה לזו:
Updated IAM policy for key [runtime].
bindings:
- members:
- serviceAccount:service-1234567890@gcp-sa-apigee.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter
etag: BwWqgEuCuwk=
version: 1
אם מופיעה שגיאה כמו זו:
INVALID_ARGUMENT: Role roles/cloudkms.cryptokms.cryptoKeyEncrypterDecrypter is not supported for this resource.
חשוב לוודא שהשתמשתם במספר הפרויקט ולא בשם הפרויקט בכתובת האימייל בחשבון השירות.
אם אתם משתמשים ב
שמירת נתונים במדינה מסוימת, צריך ליצור מחזיק מפתחות ומפתח להצפנת מישור הבקרה. אם אתם לא משתמשים בשמירת נתונים במדינה מסוימת, אפשר לדלג אל שלב 3.
כדי ליצור אוסף מפתחות ומפתח להצפנת מישור הבקרה, פועלים לפי השלבים הבאים.
מגדירים משתנה סביבה למיקום של טבעת ההצפנה ומפתח ההצפנה של מסד הנתונים במישור הבקרה:
CONTROL_PLANE_LOCATION הוא המיקום הפיזי שבו יאוחסנו נתוני מישור הבקרה של Apigee.
רשימת המיקומים הזמינים של מישור הבקרה מופיעה במאמר מיקומי Apigee.
CONSUMER_DATA_REGION הוא אזור משנה של אזור מישור הבקרה. חובה לציין גם את CONTROL_PLANE_LOCATION וגם את CONSUMER_DATA_REGION.
רשימת האזורים שבהם אפשר לאחסן נתונים של צרכנים זמינה במאמר בנושא מיקומי Apigee.
מגדירים משתני סביבה עבור מחזיקי מפתחות ושמות מפתחות של מסד הנתונים של מישור הבקרה.
-d מגדיר את מטען הנתונים של הבקשה. ה-payload צריך לכלול את הפרטים הבאים:
name: מזהה את הארגון החדש. השם צריך להיות זהה למזהה הפרויקט.
analyticsRegion: מציין את המיקום הפיזי שבו יישמרו נתוני הניתוח.
runtimeType: מגדירים את הערך הזה ל-CLOUD.
billingType: מציין את סוג החיוב של הארגון שנוצר.
authorizedNetwork: מזהה את רשת ה-peering שציינתם בהגדרת רשת שירותים.
runtimeDatabaseEncryptionKeyName: המזהה של מפתח ההצפנה של האפליקציה שיצרתם בשלב הקודם. כדאי לזכור שהמזהה בנוי כמו נתיב של קובץ. לדוגמה: projects/PROJECT_ID/locations/YOUR_RUNTIMEDBKEY_LOCATION/keyRings/YOUR_DB_KEY_RING_NAME/cryptoKeys/YOUR_DB_KEY_NAME
-d מגדיר את מטען הנתונים של הבקשה. ה-payload צריך לכלול את הפרטים הבאים:
name: מזהה את הארגון החדש. השם צריך להיות זהה למזהה הפרויקט.
runtimeType: מגדירים את הערך הזה ל-CLOUD.
billingType: מציין את סוג החיוב של הארגון שנוצר.
controlPlaneEncryptionKeyName: מזהה המפתח של מישור הבקרה.
apiConsumerDataLocation: צריך לציין גם אזור משנה לשימוש של משאבים פנימיים. במאמר
אזורים גיאוגרפיים לאחסון נתונים מפורטים הערכים הנתמכים.
apiConsumerDataEncryptionKeyName: המזהה של המפתח לאזור הנתונים של הצרכן.
authorizedNetwork: מזהה את רשת ה-peering שציינתם בהגדרת רשת שירותים.
runtimeDatabaseEncryptionKeyName: המזהה של מפתח ההצפנה של האפליקציה שיצרתם בשלב הקודם. כדאי לזכור שהמזהה בנוי כמו נתיב קובץ. לדוגמה: projects/your-project/locations/your_runtime_db_key_location/keyRings/your-key-ring/cryptoKeys/your-key
אחרי שמריצים את הפקודה הזו, Apigee מתחיל פעולה ארוכת טווח, שיכולה להימשך כמה דקות.
אם מוצגת שגיאה, צריך לבדוק את השימוש במרכאות סביב ערכי המשתנים במטען הנתונים. חשוב לוודא שמשתנה $PROJECT_ID מוקף במירכאות כפולות, מירכאות בודדות ומירכאות כפולות, כמו בדוגמה הבאה:
"'"$PROJECT_ID"'"
אם משתמשים במחרוזות פשוטות (לא במשתני סביבה) לערכי הבקשה, אפשר להוסיף מירכאות כפולות למחרוזת המטען הייעודי (payload) עם המירכאות הבודדות, כמו בדוגמה הבאה:
'{ "name":"my-gcp-project", ... }'
מחכים כמה דקות.
כדי לבדוק את הסטטוס של בקשת היצירה, אפשר לשלוח בקשת GET אל List organizations API של Apigee, כמו בדוגמה הבאה:
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
אם אתם רואים את התשובה הזו, סימן שיצירת הארגון עדיין לא הושלמה:
{
"error": {
"code": 403,
"message": "Permission denied on resource \"organizations/apigee-docs-m\" (or it may not exist)",
"status": "PERMISSION_DENIED"
}
}
אם Apigee יצליח ליצור ארגון חדש, תקבלו תגובה שדומה לזו:
אם Apigee מחזיר תגובת שגיאת HTTP, כדאי לעיין במאמר בנושא
יצירת ארגון Apigee.
שלב 6: יצירת מופע של זמן ריצה
ההרשאות שנדרשות למשימה הזו
אפשר לתת למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או לתת הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות. מידע נוסף זמין במאמרים בנושא
תפקידים מוגדרים מראש ו
הרשאות של מכונות זמן ריצה.
בסביבת ריצה מאוחסנים פרויקט Apigee והשירותים שקשורים אליו. היא מספקת את נקודת הקצה שפונה למשתמשים של השירותים שלכם. כדי ליצור מופע חדש של זמן ריצה:
צריך לוודא ש-Apigee סיים ליצור את הארגון. שלחת בקשה ליצירת ארגון חדש במאמר יצירת ארגון Apigee, אבל צריך לוודא שהפעולה הסתיימה לפני שממשיכים.
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
אם הארגון קיים (ויש לכם את ההרשאות המתאימות לצפייה בו), Apigee משיב עם פרטים לגביו. אם Apigee משיב עם שגיאה, צריך לחכות כמה דקות ולשלוח את הבקשה שוב.
בדומה למשימה הקודמת שבה יצרתם מפתח הצפנה למסד הנתונים, עכשיו אתם צריכים ליצור מפתח
Cloud KMS שמשמש להצפנת נתונים בצד השרת.
כדי להתחיל, מגדירים את משתני הסביבה הבאים:
INSTANCE_NAME: השם של המכונה החדשה. לדוגמה,
my-runtime-instance. השם צריך להתחיל באות קטנה, יכול להיות באורך של עד 32 תווים, ויכול לכלול רק אותיות קטנות, מספרים ומקפים. הוא לא יכול להתחיל או להסתיים במקף, והוא חייב להיות באורך של שני תווים לפחות.
RUNTIME_LOCATION הוא המיקום הפיזי שבו מתארח האשכול.
הערכים התקינים הם כל מיקום שמותר ב-Compute Engine. (ראו אזורים ותחומים זמינים). בדוגמה הזו נשתמש ב-us-west1.
DISK_KEY_RING_NAME הוא השם של אוסף המפתחות להצפנת הדיסק.
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
כאשר:
consumerAcceptList (אופציונלי) מציין רשימה של מזהי פרויקטים בענן של Google שיכולים להתחבר באופן פרטי ל
שירות המצורף של ה-VPC של Apigee. קובץ מצורף של שירות הוא ישות שמשמשת עם
Private Service Connect של Google Cloud כדי לאפשר לספקי שירותים (במקרה הזה, Apigee) לחשוף שירותים לצרכנים (במקרה הזה, פרויקט אחד או יותר ב-Cloud שבבעלותכם).
כברירת מחדל, אנחנו משתמשים בפרויקט בענן שכבר משויך לארגון שלכם ב-Apigee. לדוגמה:
"consumerAcceptList": ["project1", "project2", "project3"]
שימו לב שאפשר גם להגדיר ולשנות את רשימת הפרויקטים המקובלים בממשק המשתמש של המופע. פרטים נוספים זמינים במאמר בנושא
ניהול מופעים.
While the /22 IP range is used for running Apigee core workloads,
the /28 range is used by Apigee to access the instance for troubleshooting purposes.
אפשר לעיין גם במאמר בנושא
יצירת מכונות.
הבקשה הזו יכולה להימשך עד 20 דקות כי Apigee צריך ליצור ולהפעיל אשכול Kubernetes חדש, להתקין את משאבי Apigee באשכול הזה ולהגדיר איזון עומסים.
אם Apigee מחזיר שגיאה, אפשר לעיין במאמר בנושא
יצירת מופע חדש.
כדי לבדוק את הסטטוס של הבקשה ליצירת מופע של זמן ריצה, מריצים את הפקודה הבאה. כשהסטטוס הוא פעיל, אפשר לעבור לשלב הבא.
אין מיקום נתונים
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$INSTANCE_NAME"
המיקום של נתונים
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://REGIONAL_ENDPOINT/v1/organizations/$PROJECT_ID/instances/$INSTANCE_NAME"
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
שלב 7: יצירת סביבה
ההרשאות שנדרשות למשימה הזו
אתם יכולים לתת למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או לתת הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות. מידע נוסף זמין במאמרים הבאים:
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
שלב 8: הגדרת הניתוב
בשלב הזה מגדירים איך אפליקציות לקוח מתקשרות עם Apigee. תנועת נתונים מלקוח אל Apigee
נקראת גם תנועת נתונים 'צפונה'. אפשרויות ההגדרה של Northbound כוללות את האפשרויות הבאות.
עוברים לאפשרות ההגדרה שרוצים להשתמש בה ומבצעים את השלבים שמתאימים לאפשרות הזו:
משתמשים בקבוצת מופעי מכונה מנוהלים (MIG) כדי לשלוח תעבורת נתונים של API משירות קצה עורפי של מאזן עומסים גלובלי אל Apigee. במקרה כזה, Apigee יכול להתחבר רק ל-VPC המקושר. ההגדרה הזו מאפשרת לשלוח בקשות לשרת proxy של Apigee API מכל מכונה שמחוברת לרשת.
אפשר לאפשר גישה פנימית בלבד לשרתי ה-proxy של ה-API מכל הפרויקטים שלכם ב-Google Cloud באמצעות Private Service Connect.
Private Service Connect מאפשר חיבור פרטי בין בעלים של שירות מנוהל (Apigee) לבין צרכן השירות (פרויקט ה-VPC המקושר ו/או פרויקטים אחרים ב-Cloud שאתם שולטים בהם). בשיטה הזו, הבקשות עוברות דרך נקודת קצה (endpoint) של שירות או דרך מאזן עומסים פנימי אזורי לנקודת הצמדה יחידה שנקראת קבצים מצורפים לשירות. ההגדרה הזו מאפשרת ללקוחות הפנימיים שלכם לשלוח בקשות ל-proxy ל-API של Apigee מכל מכונה שמחוברת לרשת.
משתמשים ב-Private Service Connect כדי להפעיל חיבור פרטי בין בעלים של שירות מנוהל (Apigee) לבין צרכן השירות (פרויקט ה-VPC המקושר ו/או פרויקט אחד או יותר אחרים בענן שאתם שולטים בהם). בשיטה הזו, הבקשות עוברות דרך מאזן עומסים חיצוני גלובלי או מאזן עומסים חיצוני אזורי לנקודת הצמדה יחידה שנקראת service attachment. ההגדרה הזו מאפשרת לשלוח בקשות ל-proxy ל-API של Apigee מכל מכונה שמחוברת לרשת.
ההוראות שלמטה מתייחסות לכל אחת מהגישות האלה לניתוב.
ניתוב פנימי (VPC)
כדי לנתב תנועה מלקוחות פנימיים אל Apigee, אפשר לבחור להשתמש בסיום TLS או לא:
אפשרויות TLS: יש שתי אפשרויות אם רוצים לשלוח קריאות ל-proxy ל-API מלקוחות פנימיים עם TLS מופעל:
(אפשרות 1) הגדרת מאזן עומסים פנימי (ILB):
יוצרים קבוצת מופעי מכונה מנוהלים (MIG) בפרויקט. כדי ליצור את ה-MIG, פועלים לפי השלבים 8a, 8b ו-8c בכרטיסייה ניתוב חיצוני (MIG).
(אפשרות 2) שימוש בשם דומיין שמוגדר במלואו, שמוגדר כברירת מחדל ופנימי, ובכתובת ה-IP של מאזן העומסים הפנימי של מכונת Apigee. מומלץ להשתמש באפשרות הזו רק למטרות בדיקה, ולא בסביבת ייצור. במקרה הזה, נעשה שימוש באישורים בחתימה עצמית שנוצרו על ידי Apigee, עם מאזן העומסים הפנימי של Apigee, ואי אפשר לשנות אותם. ראו
קריאה ל-proxy ל-API עם גישה פנימית בלבד.
אפשרות ללא TLS: אם לא נדרש סיום TLS, אפשר להפעיל קריאה ל-proxy ל-API על ידי דילוג על אימות אישור TLS. לדוגמה, האפשרות -k בכלי curl של שורת הפקודה משביתה את אימות האישור, אבל פרוטוקול ה-TLS נשאר פעיל במהלך החיבור. שימו לב שגישה ל-Apigee Ingress באמצעות HTTP רגיל ביציאה 80 לא אפשרית, בדומה ל-Apigee Hybrid. אפשר לעיין במאמר בנושא
קריאה ל-proxy ל-API עם גישה פנימית בלבד.
ניתוב חיצוני (MIG)
בקטע הזה נסביר איך להגדיר ניתוב כדי לאפשר גישה חיצונית לשרתי proxy של API באמצעות קבוצת מופעי מכונה מנוהלים (MIG) לשליחת תעבורת API משירות קצה עורפי של מאזן עומסים גלובלי אל Apigee. צריך לבצע את הפעולה הזו לפני ששולחים בקשה מלקוח חיצוני למופע זמן הריצה של Apigee.
ההרשאות שנדרשות למשימה הזו
אתם יכולים להקצות למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות.
ראו תפקידים מוגדרים מראש והרשאות לניתוב גישה.
ההוראות בקטע הזה משתמשות במשתני סביבה כדי להתייחס למחרוזות שנעשה בהן שימוש חוזר. מומלץ להגדיר אותם לפני שממשיכים:
MIG_NAME=apigee-mig-MIG_NAME # You can choose a different name if you like
VPC_NAME=default # If you are using a shared VPC, use the shared VPC nameVPC_SUBNET=default # Private Google Access must be enabled for this subnetREGION=RUNTIME_REGION # The same region as your Apigee runtime instanceAPIGEE_ENDPOINT=APIGEE_INSTANCE_IP # See the tip below for details on getting this IP address value
תשתמשו במשתנים האלה כמה פעמים במהלך התהליכים שנותרו. אם רוצים להגדיר כמה אזורים, צריך ליצור משתנים עם ערכים ספציפיים לכל אזור.
שלב 8c: יצירת קבוצה של מופעי מכונה מנוהלים
בשלב הזה, יוצרים ומגדירים קבוצה של מופעי מכונה מנוהלים (MIG). בשלב מאוחר יותר,
מוסיפים את ה-MIG לשירות לקצה העורפי שמצורף למאזן עומסים גלובלי. נדרש MIG כדי לשלוח תנועת API משירות הקצה העורפי של מאזן העומסים הגלובלי אל Apigee.
כמו שאפשר לראות מהפקודה הזו, המכונות הן מסוג e2-medium. הם מריצים את Debian 12 ויש להם 20GB של דיסק. סקריפט startup-script.sh מגדיר את ה-MIG לניתוב תעבורת נתונים נכנסת ממאזן העומסים למופע Apigee.
צריך ליצור את פרטי הכניסה רק פעם אחת, בין אם מתקינים באזור יחיד או במספר אזורים. בשלב מאוחר יותר, משייכים את פרטי הכניסה האלה לשרת ה-proxy של HTTPS שמשמש כיעד של מאזן העומסים.
מגדירים את DOMAIN_HOSTNAME לשם מארח חוקי של דומיין שרשמתם. בשלב מאוחר יותר, תקבלו את כתובת ה-IP של מאזן העומסים ותעדכנו את רשומת A של הדומיין כך שתפנה לכתובת הזו. לדוגמה, שם מארח של דומיין יכול להיראות כך: foo.example.com.
תשתמשו בבדיקת התקינות הזו כדי לוודא ששירות לקצה העורפי פועל. כדי להגדיר בדיקות תקינות מתקדמות יותר עבור שרת proxy ספציפי, אפשר לעיין במאמר בנושא ביצוע בדיקות תקינות.
שלב 8f: קבלת כתובת IP שמורה ויצירת כללים לחומת האש
צריך להקצות כתובת IP למאזן העומסים ואז ליצור כללים שמאפשרים למאזן העומסים לגשת ל-MIG. צריך לבצע את השלב הזה רק פעם אחת, בין אם מתקינים באזור אחד או בכמה אזורים.
שלב חשוב: עוברים לאתר, למארח ה-DNS או לספק האינטרנט שדרכו מנוהלות רשומות ה-DNS, ומוודאים שרשומת ה-DNS של הדומיין מפנה לכתובת ה-IP של איזון העומסים ב-Google Cloud. הכתובת הזו היא ערך ה-IP שמוחזר בשלב האחרון. פרטים נוספים זמינים במאמר בנושא
עדכון רשומות ה-DNS A ו-AAAA כך שיפנו לכתובת ה-IP של מאזן העומסים.
יוצרים כלל של חומת אש שמאפשר למאזן העומסים לגשת לקבוצת ה-MIG באמצעות הפקודה הבאה:
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy
שימו לב שטווחי כתובות ה-IP 130.211.0.0/22 ו-35.191.0.0/16 הם טווחי כתובות ה-IP של המקור עבור Google Load Balancing. כלל חומת האש הזה מאפשר ל-Google Cloud Load Balancing לשלוח בקשות לבדיקת תקינות אל ה-MIG.
בוחרים את הכרטיסייה שלמטה לפי ההגדרה הרצויה ופועלים לפי השלבים:
נקודת קצה של שירות
ההרשאות שנדרשות למשימה הזו
אתם יכולים להקצות למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות.
ראו תפקידים מוגדרים מראש והרשאות לניתוב גישה.
יצירת נקודת קצה של שירות Private Service Connect לקובץ המצורף של השירות
מקבלים את קובץ השירות מהמכונה שיצרתם קודם:
אין מיקום נתונים
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
המיקום של נתונים
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://REGIONAL_ENDPOINT/v1/organizations/$PROJECT_ID/instances"
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
בדוגמת הפלט הבאה, הערך serviceAttachment
מוצג באותיות מודגשות:
יוצרים נקודת קצה של שירות Private Service Connect שמפנה לקובץ המצורף לשירות שקיבלתם מגוף התגובה של המכונה בשלב הקודם, כמו שמוסבר במאמר יצירת נקודת קצה של Private Service Connect.
אתם יכולים להקצות למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות.
ראו תפקידים מוגדרים מראש והרשאות לניתוב גישה.
שלב 7א: הגדרת משתני סביבה
ההוראות בקטע הזה משתמשות במשתני סביבה כדי להתייחס למחרוזות שמשמשות שוב ושוב. חשוב לוודא שהגדרתם את המשתנים בהגדרת משתני סביבה.
NETWORK_NAME: (אופציונלי) שם הרשת שבה נוצרת קבוצת ה-NEG. אם לא מציינים את הפרמטר הזה, נעשה שימוש ברשת של פרויקט default.
SUBNET_NAME: שם רשת המשנה שמשמשת לקישוריות פרטית לספק. גודל רשת המשנה יכול להיות קטן: קבוצת נקודות הקצה של Private Service Connect צריכה רק כתובת IP אחת מרשת המשנה. ב-Apigee, נדרשת רק קבוצת נקודות קצה אחת של Private Service Connect לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות. אם לא מציינים רשת משנה, נקודות הקצה של הרשת יכולות להיות שייכות לכל רשת משנה באזור שבו נוצרת קבוצת נקודות הקצה של הרשת.
TARGET_SERVICE: קובץ מצורף של שירות שרוצים להתחבר אליו. לדוגמה: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
כדי ליצור מאזן עומסים ב-HTTPS, צריך משאב של אישור SSL לשימוש בשרת proxy יעד מסוג HTTPS.
משתמשים בפקודה הזו כדי ליצור משאב של אישור SSL בניהול עצמי. כדי ליצור אישור SSL בניהול עצמי, צריך קובץ מפתח פרטי מקומי וקובץ אישור מקומי. אם אתם צריכים ליצור את הקבצים האלה, תוכלו לעיין בשלב 1 של שימוש באישורי SSL בניהול עצמי.
בקטע הזה מוסבר איך להגדיר ניתוב חיצוני באמצעות
Private Service Connect כדי לאפשר תקשורת בין Apigee לבין רשתות VPC שאתם שולטים בהן. צריך לעשות את זה לפני ששולחים בקשה מלקוח חיצוני למופע זמן הריצה של Apigee.
ההרשאות שנדרשות למשימה הזו
אתם יכולים להקצות למקצה ההרשאות של Apigee תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות.
ראו תפקידים מוגדרים מראש והרשאות ניתוב גישה.
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 לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות. אם לא מציינים רשת משנה, נקודות הקצה ברשת יכולות להיות שייכות לכל רשת משנה באזור שבו נוצרת קבוצת נקודות הקצה ברשת.
$PROJECT_ID: פרויקט בענן שכבר משויך לארגון Apigee, או פרויקט בענן שכלול ב-consumerAcceptlist כשנוצר מופע זמן הריצה של Apigee.
אם עדיין לא עשיתם את זה, כדאי ליצור משתנה סביבה שיכיל את מזהה הפרויקט, כי הוא נמצא בשימוש ברוב הפקודות הבאות.
DEFAULT_BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי שמוגדר כברירת המחדל במאזן העומסים.
ברירת המחדל משמשת כשאין כלל מארח שתואם לשם המארח המבוקש.
יוצרים את ה-proxy של HTTPS ליעד.
כדי ליצור מאזן עומסים ב-HTTPS, צריך משאב של אישור SSL לשימוש בשרת ה-proxy של יעד HTTPS. אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. מומלץ להשתמש באישורים שמנוהלים על ידי Google, כי Google Cloud מקבלת, מנהלת ומחדשת את האישורים האלה באופן אוטומטי.
משתמשים בפקודה הזו כדי ליצור משאב של אישור SSL בניהול עצמי. כדי ליצור אישור SSL בניהול עצמי, צריך קובץ מפתח פרטי מקומי וקובץ אישור מקומי. אם אתם צריכים ליצור את הקבצים האלה, תוכלו לעיין בשלב 1 של שימוש באישורי SSL בניהול עצמי.
TARGET_SERVICE: השם של שירות ה-Attachment שאליו רוצים להתחבר. לדוגמה: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
DEFAULT_BACKEND_SERVICE_NAME: השם של שירות לקצה העורפי של ברירת המחדל של מאזן העומסים.
ברירת המחדל משמשת כשאין כלל מארח שתואם לשם המארח המבוקש.
יוצרים את ה-proxy של HTTPS ליעד.
כדי ליצור מאזן עומסים ב-HTTPS, צריך משאב של אישור SSL לשימוש בשרת ה-proxy של יעד HTTPS.
משתמשים בפקודה הזו כדי ליצור משאב של אישור SSL בניהול עצמי. כדי ליצור אישור SSL בניהול עצמי, צריך קובץ מפתח פרטי מקומי וקובץ אישור מקומי. אם אתם צריכים ליצור את הקבצים האלה, תוכלו לעיין בשלב 1 של שימוש באישורי SSL בניהול עצמי.
כדי ליצור ולפרוס שרתי proxy, צריך להגדיר לפחות את קבוצת ההרשאות הבאה. אם יש לכם תפקיד אדמין בארגון Apigee, תוכלו לבצע את המשימה הזו. מידע על תפקידים אחרים שאפשר להשתמש בהם זמין במאמר
תפקידים ב-Apigee.
מורידים את
הפרוקסי לדוגמה מ-GitHub. יעד הפרוקסי הוא השירות httpbin.org, שהוא שירות ציבורי נפוץ לבקשות ותגובות.
מעלים את חבילת ה-proxy ל-API לסביבת זמן הריצה באמצעות Apigee
apis API:
REGIONAL_ENDPOINT הוא נקודת הקצה האזורית שנדרשת כדי לתמוך במיקום הנתונים.
אם מופיעה שגיאה כמו:
CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure, צריך לוודא
שאישור ה-SSL שיצרתם קודם הוקצה.
משתמשים בפקודה הזו כדי לבדוק את
סטטוס ההקצאה. כשהאישור מוקצה, הסטטוס שלו הוא ACTIVE.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["התוכן קשה להבנה","hardToUnderstand","thumb-down"],["שגיאות בקוד לדוגמה או במידע","incorrectInformationOrSampleCode","thumb-down"],["חסרים לי פרטים או דוגמאות","missingTheInformationSamplesINeed","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2026-06-06 (שעון UTC)."],[],[]]