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

סביבה מספקת הקשר מבודד או 'ארגז חול' להרצת פרוקסי של 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) לאתחל לבין מספר השרתים הפרוקסי שנפרסו במעבד הזה. בסביבת Kubernetes עם התאמה אוטומטית לעומס, עלייה בזמן האתחול עלולה להיות בעיה. ככל שיש יותר שרתי פרוקסי שנפרסו במעבד ההודעות, כך ייקח יותר זמן עד שהמעבד יפעל אם צריך לשנות את הגודל שלו או ליצור אותו מחדש.
שיפור הביצועים אם יש לכם כמה שרתי proxy שפרוסים בסביבה מסוימת, ואחד מהם מקבל הרבה תנועה ולכן מתבצע בו שינוי גודל אוטומטי לעיתים קרובות, כל שרתי ה-proxy באותה סביבה ישנו את הגודל שלהם יחד איתו. יכול להיות שתהיה בעיה בהשפעה על הביצועים של הרחבת מספר שרתי proxy באמצעות שרת proxy יחיד עם תנועה גבוהה.
שכן רועש אם יש לכם כמה שרתי proxy שפרוסים באותה סביבה, ואחד מהם קורס, כל שרתי ה-proxy בסביבה יושבתו בזמן שה-MPs יופעלו מחדש. הגבלת מספר שרתי ה-proxy שנפרסים בסביבה מסוימת מאפשרת למזער את ההשפעה של קריסת שרת proxy יחיד.

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

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

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

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

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

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

org: hybrid-example

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
...

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