מידע על סביבות

סביבה מספקת הקשר מבודד או 'ארגז חול' להרצת פרוקסי של API. באותו ארגון, אפשר ליצור כמה סביבות.

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

namespace: my-namespace
org: my-organization
...
envs:
  - name: test
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json


  - name: prod
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json
...

נניח ששרת proxy עם נתיב בסיס /foo1 נפרס בסביבה test. אפשר לקרוא לשרת ה-proxy כך: 

curl -k https://api.example.com/foo1

כשהשיחה הזו מגיעה ל-ingress, הוא יודע לשלוח אותה למעבד ההודעות שמשויך לסביבת test, שמטפל בבקשה.

באופן דומה, אם foo1 נפרס גם בסביבת prod, אפשר לשלוח בקשת proxy כמו זו, לכינוי המארח apiprod.mydomain.net: 

curl -k https://apiprod.example.com/foo1

השיחה מנותבת על ידי ה-ingress אל ה-MP שמשויך למארח הזה.

אנטי-תבנית: פריסת כל שרתי ה-proxy בסביבה היברידית אחת.

שיטה מומלצת: כדאי ליצור כמה סביבות ולפרוס מספר מוגבל של שרתי proxy בכל אחת מהן.

הגבלת מספר הפריסות של שרת ה-proxy

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

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

בעיה שכדאי לבדוק תיאור
זמן האתחול של מעבד ההודעות יש קשר ישיר בין משך הזמן שלוקח למעבד הודעות (MP) להפעיל אתחול לבין מספר השרתים הפרוקסי שנפרסו באותו MP. בסביבת Kubernetes עם התאמה אוטומטית לעומס, עלייה בזמן האתחול עלולה להיות בעייתית. ככל שיותר שרתי proxy נפרסים ב-MP, כך ייקח יותר זמן להפעיל את ה-MP אם צריך לשנות את הגודל שלו או ליצור אותו מחדש.
שיפור הביצועים אם יש לכם כמה שרתי proxy שפרוסים בסביבה מסוימת, ואחד מהם מקבל הרבה תנועה ולכן הוא עובר לעיתים קרובות שינוי גודל אוטומטי, כל שרתי ה-proxy באותה סביבה ישנו את הגודל שלהם יחד איתו. יכול להיות שתהיה בעיה בהשפעה על הביצועים של הרחבת מספר שרתי proxy באמצעות שרת proxy יחיד עם תנועה גבוהה.
שכן רועש אם יש לכם כמה שרתי proxy שפרוסים באותה סביבה, ואחד מהם קורס, כל שרתי ה-proxy בסביבה יושבתו בזמן שה-MPs יופעלו מחדש. הגבלת מספר ה-proxies שנפרסים בסביבה מסוימת מאפשרת למזער את ההשפעה של קריסת proxy יחיד.

קבוצות סביבות ומארחים וירטואליים

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

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

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

gcp:
  region: us-central1
  projectID: hybrid-example


k8sCluster:
  name: apigee-hybrid
  region: us-central1


org: hybrid-example

contractProvider: https://us-apigee.googleapis.com # if using data residency

instanceID: "my_hybrid_example"


virtualhosts:
  - name: group-1  # the name of an environment group
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key

virtualhosts:
  - name: group-2
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
...

מקורות מידע נוספים