במאמר הזה מוסבר איך להתקין ולהגדיר את 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 מוגדרת עם אסימון Bearer.Authentication
תשתמשו בכותרת הזו כשתיגשו לממשקי 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 מוגדרת עם אסימון Bearer.Authentication
תשתמשו בכותרת הזו כשתיגשו לממשקי 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 provisioner תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות. אפשר לעיין במאמרים בנושא
תפקידים מוגדרים מראש ו
הרשאות של רשתות שירות.
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 משיב עם הפרטים הבאים:
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, המערכת תבחר בשבילכם טווח כתובות זמין.
מוודאים שטווח כתובות ה-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 provisioner תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות להשלמת המשימה הזו, או להקצות הרשאות מפורטות יותר כדי לספק את ההרשאות המינימליות הנדרשות.
תפקידים מוגדרים מראש ו
הרשאות של מופע בזמן ריצה
בסביבת ריצה מאוחסנים פרויקט 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"]
שימו לב שאפשר גם להגדיר ולשנות את רשימת הפרויקטים המקובלים בממשק המשתמש של המופע. פרטים נוספים זמינים במאמר בנושא
ניהול מופעים.
בעוד שטווח כתובות ה-IP /22 משמש להרצת עומסי עבודה של ליבת Apigee,
טווח כתובות ה-IP /28 משמש את Apigee כדי לגשת למכונה לצורכי פתרון בעיות.
אפשר לעיין גם במאמר בנושא
יצירת מכונות.
הבקשה הזו יכולה להימשך עד 20 דקות כי Apigee צריך ליצור ולהפעיל אשכול Kubernetes חדש, להתקין את משאבי Apigee באשכול הזה ולהגדיר איזון עומסים.
כדי לבדוק את הסטטוס של הבקשה ליצירת מופע של זמן ריצה, מריצים את הפקודה הבאה. כשהסטטוס הוא ACTIVE, אפשר לעבור לשלב הבא.
אין מיקום נתונים
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 המקושר ו/או פרויקט אחד או יותר אחרים בענן שאתם שולטים בהם). בשיטה הזו, הבקשות עוברות דרך נקודת קצה של שירות או דרך מאזן עומסים פנימי אזורי לנקודת הצמדה יחידה שנקראת הצמדת שירות.
ההגדרה הזו מאפשרת ללקוחות פנימיים לשלוח בקשות ל-proxy ל-API של Apigee מכל מכונה שמחוברת לרשת.
משתמשים ב-Private Service Connect כדי לאפשר חיבור פרטי בין בעלים של שירות מנוהל (Apigee) לבין צרכן השירות (פרויקט ה-VPC המקושר ו/או פרויקט אחד או יותר אחרים בענן שאתם שולטים בהם). בשיטה הזו, הבקשות עוברות דרך מאזן עומסים חיצוני גלובלי או מאזן עומסים חיצוני אזורי לנקודת צירוף יחידה שנקראת צירוף שירות.
ההגדרה הזו מאפשרת לשלוח בקשות ל-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 ספציפי, אפשר לעיין במאמר ביצוע בדיקות תקינות.
(אופציונלי) מגדירים תיקון אוטומטי לקבוצת ה-MIG באמצעות בדיקת התקינות החדשה שנוצרה.
כך מובטח שכל מכונה וירטואלית ב-MIG שלא מגיבה תיווצר מחדש באופן אוטומטי.
שלב 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. כלל חומת האש הזה מאפשר ל-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: שם רשת המשנה שמשמשת לקישוריות פרטית אל שירות המפיק.
גודל תת-הרשת יכול להיות קטן: ה-NEG של Private Service Connect צריך רק כתובת IP אחת מתת-הרשת.
ב-Apigee, נדרש רק Private Service Connect NEG אחד לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות.
אם לא מציינים רשת משנה, נקודות קצה ברשת יכולות להיות שייכות לכל רשת משנה באזור שבו נוצרה קבוצת נקודות הקצה ברשת.
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, נדרש רק Private Service Connect NEG אחד לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות.
אם לא מציינים רשת משנה, נקודות קצה ברשת יכולות להיות שייכות לכל רשת משנה באזור שבו נוצרה קבוצת נקודות הקצה ברשת.
$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: השם של קובץ השירות שאליו רוצים להתחבר.
לדוגמה: 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-21 (שעון UTC)."],[],[]]