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

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

הקוד הבא מציג דוגמה להגדרת שינויים שמתבצעים על ידי המשתמש, שבה מוגדרות כמה סביבות. שימו לב שלסביבות prod ו-test יש כינויי מארח שונים: 

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
...
  • מוסיפים נכס virtualhosts שממפה את routingRules לסביבות. 
    virtualhosts:
  - name: default
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: test
     
    virtualhosts:
  - name: external
    hostAliases: ["apiprod.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: prod

    נניח ששרת 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 ל-API. פרטים נוספים מופיעים במאמר בנושא הגדרת מארח וירטואלי.

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

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

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

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

    הפניה להגדרת הסביבה

    רשימה מלאה של רכיבי הגדרת הסביבה מופיעה בenvs במאמר חומר עזר בנושא מאפייני הגדרה.

    עבודה עם סביבות

    מידע נוסף על הגדרות זמין בנושאים הבאים: