שאלות נפוצות לגבי הגדרת מארחים וירטואליים

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X.
info

לקוחות Edge Cloud יכולים עכשיו ליצור, לשנות ולמחוק מארחים וירטואליים. בעבר, התמיכה של Apigee Edge הייתה צריכה לבצע את הפעולות האלה.

מי יכול להגדיר מארח וירטואלי ב-Edge Cloud?

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

לתפקיד בהתאמה אישית נדרשות הרשאות GET,‏ PUT ו-DELETE ב-/environments/*/virtualhosts או בכל אחד ממשאבי ההורה שלו. מידע נוסף זמין במאמר יצירת תפקידים באמצעות ה-API.

מה קורה אם כבר יש לי מארח וירטואלי שנוצר על ידי Apigee?

ללקוחות קיימים של Edge Cloud כבר יש מארחים וירטואליים שנוצרו על ידי Apigee. עכשיו אפשר לשנות את המארחים הווירטואליים האלה.

עם זאת, לפני שמבצעים שינויים, כדאי לעיין בדרישות לשינוי מארח וירטואלי במאמר הגדרת מארחים וירטואליים ב-Cloud. לדוגמה, אם המארח הווירטואלי הקיים מוגדר להשתמש ביציאה שאינה 443, לא תוכלו לשנות את מספר היציאה או את הגדרת ה-TLS. כלומר, אי אפשר לשנות את הגדרת ה-TLS מ'מופעלת' ל'מושבתת', או מ'מושבתת' ל'מופעלת'.

באיזו יציאה אפשר להשתמש במארח וירטואלי ב-Cloud?

אפשר להשתמש ביציאה 443 רק במארח וירטואלי ב-Cloud. אי אפשר להשתמש ביציאה 80 או בכל יציאה אחרת.

למה אי אפשר להשתמש ביציאה 80 במארח וירטואלי ב-Cloud?

אנחנו ממליצים ללקוחות Apigee להפסיק להשתמש במארחים וירטואליים של יציאה 80 לתעבורת נתונים בזמן ריצה של API, כי יציאה 80 לא מאובטחת. שנית, אנחנו לא יכולים לאמת את הבעלות על הדומיינים, ולכן לא ניתן להפוך את המארחים הווירטואליים של יציאה 80 לשירות עצמי ב-Cloud. שינויים במארחים הווירטואליים של יציאה 80 נחשבים לשינויים לא סטנדרטיים, ולכן צוות התמיכה של Apigee Edge שומר לעצמו את הזכות לדחות שינויים כאלה.

האם נדרש TLS בכל המארחים הווירטואליים החדשים ב-Cloud?

כדי ליצור מארח וירטואלי, חובה להפעיל את TLS במארח הווירטואלי. כלומר, קודם צריך ליצור מאגר מפתחות עם אישור ה-TLS והמפתח שלו, ואז ליצור את המארח הווירטואלי.

צריך אישור חתום על ידי ישות מהימנה, כמו Symantec או VeriSign. אי אפשר להשתמש באישור בחתימה עצמית או באישורי קצה שנחתמו על ידי רשות אישורים בחתימה עצמית.

מידע נוסף מופיע במאמר הגדרת מארחים וירטואליים בענן.

האם אפשר להצמיד את האישור לתקופת הניסיון בחינם ב-Apigee?

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

האם אפשר לעדכן את אישור ה-TLS שמשתמש בו מארח וירטואלי?

אם יש לכם מארח וירטואלי עם אישור TLS שתוקפו עומד לפוג, תוכלו לעדכן את המארח הווירטואלי כך שישתמש במאגר מפתחות אחר שמכיל אישור תקף.

מהו קובץ עזר?

הפניה היא משתנה שמכיל את שם מאגר המפתחות. כדי לשנות את מאגר המפתחות שבו מארח וירטואלי משתמש, צריך לעדכן את משתנה ההפניה ולא את המארח הווירטואלי עצמו.

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

איך אפשר לבדוק אם המארח הווירטואלי משתמש ב-reference?

כדי לראות מידע על מארח וירטואלי ספציפי, משתמשים ב-API Get Virtual Host:

curl -X GET -H "accept:application/xml" \
  https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts/{vhost_name} \
  -u orgAdminEmail:pWord

כאשר vhost_name הוא השם של המארח הווירטואלי. לדוגמה, אפשר לציין את vhost_name כ-secure כדי לראות את ההגדרה של המארח הווירטואלי המאובטח שמוגדר כברירת מחדל:

<VirtualHost name="secure">
    <HostAliases>
        <HostAlias>orgname-prod.apigee.net</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>443</Port>
    <Properties/>
    <SSLInfo>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <KeyAlias>freetrial</KeyAlias>
        <KeyStore>ref://freetrial</KeyStore>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
    </SSLInfo>
</VirtualHost>

שימו לב שבדוגמה הזו, הערך של הרכיב <KeyStore> בתגובה מתחיל ב-ref://. הקידומת הזו מציינת שבמאגר המפתחות נעשה שימוש בהפניה.

אם הערך של האלמנט <KeyStore> הוא מחרוזת ליסטרית, לא נעשה בו שימוש בהפניה. לדוגמה:

<KeyStore>mykeystore</KeyStore>

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

מידע נוסף זמין במאמר הגדרת מארחים וירטואליים ב-Cloud.

איך יוצרים מארח וירטואלי?

כדי ליצור את המארח הווירטואלי, פועלים לפי השלבים הבאים:

  1. יוצרים רשומת DNS ורשומת CNAME לדומיין שגלוי לכולם, שמפנות אל [org]-[environment].apigee.net. מידע נוסף זמין בקטע 'מידע על כתובות אימייל חלופיות של מארחים ושמות DNS' במאמר מידע על מארחים וירטואליים.
  2. יוצרים ומגדירים מאגר מפתחות לפי התהליך שמתואר במאמר יצירת מאגרי מפתחות ומאגרי אמון באמצעות ממשק המשתמש של Edge.
  3. מעלים את האישור והמפתח למאגר המפתחות.
  4. יוצרים הפניה למאגר המפתחות, כפי שמתואר במאמר הגדרת מארחים וירטואליים בשביל הענן.
  5. יוצרים את המארח הווירטואלי באמצעות ה-API Create a Virtual Host, כפי שמתואר במאמר הגדרת מארחים וירטואליים ב-Cloud. חשוב לציין את ההפניה הנכונה למאגר המפתחות.
  6. אם יש לכם שרתים proxy קיימים של API, צריך להוסיף את המארח הווירטואלי לרכיב <HTTPConnection> ב-ProxyEndpoint. המארח הווירטואלי מתווסף באופן אוטומטי לכל שרת ה-proxy החדש של ה-API. מידע נוסף מופיע בקטע הגדרת שרת proxy ל-API לשימוש במארח וירטואלי.

האם אפשר לבקש מ-Apigee לחסום את יציאות ה-TCP‏ 80,‏ 443 או 15999 ב-Apigee Edge Cloud?

הלקוחות שלנו מגדירים מארחים וירטואליים ביציאת TCP 443 ולפעמים ביציאת TCP 80 (למרות שלא מומלץ להשתמש ביציאה 80), אנחנו לא יכולים לחסום את היציאות האלה כי פעולה כזו עלולה לגרום לכשל בכל תעבורת זמן הריצה של ה-API.

יציאת ה-TCP 15999 משמשת באופן פנימי ב-Cloud כדי לקבוע אם הנתב תקין או לא, ולכן אסור לחסום אותה כי זה עלול לגרום להשפעה בלתי צפויה על זמן הריצה של ה-API.