הדף הזה מתייחס ל-Apigee, אבל לא ל-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
במסמך הזה מוסבר איך להשתמש ב-Apigee כדי להגדיר בדיקת תקינות פעילה כשמשתמשים ב-Private Service Connect לניתוב תנועה ברשת צפונה (תנועה מלקוחות אל Apigee). בדיקת תקינות פעילה שימושית למניעת אובדן של תנועת רשת במקרה של כשל אזורי.
סקירה כללית
אם אתם מתכננים להשתמש ב-Private Service Connect לניתוב רשת צפוני של Apigee, עליכם לפעול לפי ההוראות במסמך הזה כדי להגדיר בדיקת תקינות פעילה. בשלב הזה, Private Service Connect לא תומך בניטור של בדיקת תקינות פעילה, אבל אתם יכולים לשנות את ההגדרה של Apigee כדי להשתמש בקבוצת מופעי מכונה מנוהלים (MIG), שכן היא מספקת יכולת של בדיקת תקינות פעילה.
אפשר להשתמש בזיהוי חריגות לניטור תקינות, אבל במהלך כשלים אזוריים יכול להיות שתאבדו חלק מהתנועה מעת לעת, כי זיהוי חריגות משתמש בתנועה בזמן אמת כאינדיקטורים. זיהוי חריגויות מעביר חלק מהתנועה החיה באופן תקופתי כדי לבדוק את התקינות של האזור שנכשל.
איור 1 מציג את הארכיטקטורה המוצעת. נקודת קצה של שירות מתחברת לצירוף השירות במופע Apigee, וקבוצת מופעים מנוהלת (MIG) מעבירה את התנועה לנקודת הקצה של השירות. מפעילים מעקב אחר בדיקות תקינות ב-MIG.
גישה לבדיקת תקינות שמבוססת על MIG
דרישות מוקדמות
אפשר להשתמש בטכניקה שמתוארת במסמך הזה בהתקנות של Apigee שמשתמשות בקישור (peering) בין רשתות VPC שכנות או שלא משתמשות בקישור כזה. אבל במקרה של התקנה עם VPC peering, טכניקת בדיקת תקינות פעילה שמתוארת כאן רלוונטית רק אם משתמשים ב-Private Service Connect להגדרת הניתוב.
לפני שמבצעים את השלבים שבקטע הזה:
- במקרים של התקנות שלא מבוססות על קישור בין רשתות VPC:
- משלימים את שלבי הקצאת הרשאות ל-Apigee 1 עד 6 עבור מינויים או התקנות בתשלום לפי שימוש. בשלב הזה, האפשרות היחידה היא לבצע את השלבים האלה באמצעות ממשק שורת הפקודה.
- מדלגים על שלב 7: הגדרת ניתוב, ומבצעים במקומו את השלבים הבאים.
- במקרים של התקנות קישור בין רשתות VPC שכנות (peering) שבהן נעשה שימוש ב-Private Service Connect לניתוב:
- משלימים את שלבי הקצאת ההרשאות של Apigee 1 עד 7 עבור מינויים או התקנות של תשלום לפי שימוש. בשלב הזה, האפשרות היחידה היא לבצע את השלבים האלה באמצעות ממשק שורת הפקודה.
- מדלגים על שלב 8: הגדרת ניתוב, ומבצעים במקום זאת את השלבים הבאים.
1. הגדרת נקודת קצה של שירות Private Service Connect לקובץ מצורף עם שירות Apigee
בשלב הזה, יוצרים נקודת קצה של שירות Private Service Connect שמצביעה על קובץ מצורף של שירות במופע Apigee:
- מקבלים את קובץ ה-Service Attachment ממופע Apigee שיצרתם קודם:
curl -i -X GET -H "Authorization: Bearer $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/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1" } ] }
- יוצרים נקודת קצה של שירות Private Service Connect שמפנה לקובץ המצורף של השירות שהתקבל מגוף התגובה של המכונה בשלב הקודם, כמו שמוסבר במאמר בנושא יצירת נקודת קצה של Private Service Connect.
2. הגדרת קבוצת מופעים מנוהלת שמפנה לנקודת הקצה של השירות
בשלב הזה יוצרים קבוצת מופעים מנוהלת (MIG) שמשמשת כפרוקסי לתעבורה לנקודת הקצה של השירות. לאחר מכן אפשר להפעיל בדיקת תקינות פעילה ב-MIG.
2א. הפעלת גישה פרטית ל-Google ברשת משנה של רשת ה-VPC
כדי להפעיל גישה פרטית ל-Google עבור רשת משנה של רשת ה-VPC, פועלים לפי השלבים שמפורטים במאמר הפעלת גישה פרטית ל-Google.
2ב. הגדרה של משתני סביבה
ההוראות בקטע הזה משתמשות במשתני סביבה כדי להתייחס למחרוזות שנעשה בהן שימוש חוזר. מומלץ להגדיר אותם לפני שממשיכים:
MIG_NAME=YOUR_MIG_NAME # A name you provide for the MIGVPC_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 instanceSERVICE_ENDPOINT_IP=YOUR_SERVICE_ENDPOINT_IP. ## The endpoint IP of the service endpoint you just created
תשתמשו במשתנים האלה כמה פעמים במהלך התהליכים שנותרו. אם רוצים להגדיר כמה אזורים, צריך ליצור משתנים עם ערכים ספציפיים לכל אזור.
2ג. יצירת קבוצות של מופעי מכונה מנוהלים
בשלב הזה, יוצרים ומגדירים קבוצה של מופעי מכונה מנוהלים (MIG).
- מריצים את הפקודה הבאה כדי ליצור תבנית של הגדרות מכונה.
gcloud compute instance-templates create $MIG_NAME \ --project $PROJECT_ID \ --region $REGION \ --network $VPC_NAME \ --subnet $VPC_SUBNET \ --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \ --machine-type e2-medium --image-family debian-12 \ --image-project debian-cloud --boot-disk-size 20GB \ --no-address \ --metadata ENDPOINT=$SERVICE_ENDPOINT_IP,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh
כמו שאפשר לראות מהפקודה הזו, המכונות הן מסוג
e2-medium. הם מריצים את Debian 12 ויש להם 20GB של דיסק. סקריפטstartup-script.shמגדיר את ה-MIG לניתוב תעבורת נתונים נכנסת ממאזן העומסים למופע Apigee. - כדי ליצור קבוצה של מופעי מכונה מנוהלים, מריצים את הפקודה הבאה:
gcloud compute instance-groups managed create $MIG_NAME \ --project $PROJECT_ID --base-instance-name apigee-mig \ --size 2 --template $MIG_NAME --region $REGION
- מגדירים התאמה אוטומטית לעומס לקבוצה על ידי הפעלת הפקודה הבאה:
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \ --project $PROJECT_ID --region $REGION --max-num-replicas 3 \ --target-cpu-utilization 0.75 --cool-down-period 90
- מגדירים יציאה עם שם באמצעות הפקודה הבאה:
gcloud compute instance-groups managed set-named-ports $MIG_NAME \ --project $PROJECT_ID --region $REGION --named-ports https:443
3. הגדרת מאזן העומסים עם מעקב אחרי בדיקות תקינות
בשלבים הבאים מוסבר איך להגדיר מאזן עומסים עם מעקב אחר בדיקות תקינות.
3א. יצירת אישור ומפתח SSL למאזן העומסים
צריך ליצור את פרטי הכניסה רק פעם אחת, בין אם מתקינים באזור יחיד או במספר אזורים. בשלב מאוחר יותר, תקשרו את פרטי הכניסה האלה עם פרוקסי ה-HTTPS של מאזן העומסים.
אפשר ליצור את פרטי הכניסה באמצעות:
- אישור משלכם מרשות אישורים
- אישור SSL בניהול Google
- אישור עם חתימה עצמית (לא מומלץ לשימוש בסביבת ייצור).
מידע נוסף על יצירה ושימוש באישורי SSL למאזן עומסים ב-Google Cloud זמין במאמרים אישורי SSL וסקירה כללית על אישורי SSL.
בדוגמה הבאה אנחנו יוצרים אישור SSL בניהול Google:
- יוצרים את משתני הסביבה הבאים:
CERTIFICATE_NAME=YOUR_CERT_NAME
DOMAIN_HOSTNAME=YOUR_DOMAIN_HOSTNAMEמגדירים את
DOMAIN_HOSTNAMEלשם מארח חוקי של דומיין שרשמתם. בשלב מאוחר יותר תקבלו את כתובת ה-IP של מאזן העומסים ותעדכנו את רשומת A של הדומיין כך שתפנה לכתובת הזו. לדוגמה, שם מארח של דומיין יכול להיראות כך:foo.example.com. - מריצים את הפקודה
gcloud compute ssl-certificates create:
gcloud compute ssl-certificates create $CERTIFICATE_NAME \ --domains=$DOMAIN_HOSTNAME \ --project $PROJECT_ID \ --global
יכול להיות שיעברו עד שעה עד שהאישור יוקצה. כדי לבדוק את סטטוס ההקצאה, מריצים את הפקודה הבאה:
gcloud compute ssl-certificates describe $CERTIFICATE_NAME \ --global \ --format="get(name,managed.status, managed.Status)"
3ב. יצירת בדיקת תקינות
- יוצרים בדיקת תקינות:
gcloud compute health-checks create https HEALTH_CHECK_NAME \ --project $PROJECT_ID --port 443 --global \ --request-path /healthz/ingressתשתמשו בבדיקת התקינות הזו כדי לוודא ששירות לקצה העורפי פועל. כדי להגדיר בדיקות תקינות מתקדמות יותר עבור שרת proxy ספציפי, אפשר לעיין במאמר בנושא ביצוע בדיקות תקינות.
- יוצרים שירות לקצה העורפי:
gcloud compute backend-services create PROXY_BACKEND_NAME \ --project $PROJECT_ID \ --protocol HTTPS \ --health-checks HEALTH_CHECK_NAME \ --port-name https \ --timeout 302s \ --connection-draining-timeout 300s \ --global - מוסיפים את קבוצת המכונות המנוהלת לשירות הקצה העורפי באמצעות הפקודה הבאה:
gcloud compute backend-services add-backend PROXY_BACKEND_NAME \ --project $PROJECT_ID --instance-group $MIG_NAME \ --instance-group-region $REGION \ --balancing-mode UTILIZATION --max-utilization 0.8 --global
- יוצרים מפת URL לאיזון עומסים באמצעות הפקודה הבאה:
gcloud compute url-maps create MIG_PROXY_MAP_NAME \ --project $PROJECT_ID --default-service PROXY_BACKEND_NAME - יוצרים שרת proxy של HTTPS ליעד איזון עומסים באמצעות הפקודה הבאה:
gcloud compute target-https-proxies create MIG_HTTPS_PROXY_NAME \ --project $PROJECT_ID --url-map MIG_PROXY_MAP_NAME \ --ssl-certificates $CERTIFICATE_NAME
3ג. קבלת כתובת IP שמורה ויצירת כללים לחומת האש
צריך להקצות כתובת IP למאזן העומסים ואז ליצור כללים שמאפשרים למאזן העומסים לגשת ל-MIG. צריך לבצע את השלב הזה רק פעם אחת, בין אם מתקינים באזור אחד או בכמה אזורים.
- שומרים כתובת IP למאזן העומסים:
gcloud compute addresses create ADDRESSES_NAME \ --project $PROJECT_ID \ --ip-version=IPV4 \ --global - יוצרים כלל העברה גלובלי באמצעות הפקודה הבאה:
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --project $PROJECT_ID --address ADDRESSES_NAME --global \ --target-https-proxy MIG_HTTPS_PROXY_NAME --ports 443 - מריצים את הפקודה הבאה כדי לקבל את כתובת ה-IP השמורה:
gcloud compute addresses describe ADDRESSES_NAME \ --project $PROJECT_ID --format="get(address)" --global - שלב חשוב: עוברים לאתר, למארח ה-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 של המקור עבור Cloud Load Balancing. כלל חומת האש הזה מאפשר ל-Cloud Load Balancing לשלוח בקשות לבדיקת תקינות אל ה-MIG.
הקצאת הרשאות ל-Apigee הושלמה. עוברים אל פריסת שרת proxy לדוגמה.