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

מוצג התיעוד של Apigee Edge.
נכנסים למסמכי התיעוד של Apigee X.
מידע

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

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

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

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

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

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

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

באיזו יציאה אפשר להשתמש במארח וירטואלי בענן?

אפשר להשתמש ביציאה 443 רק במארח וירטואלי בענן. לא ניתן להשתמש ביציאה 80 או בכל יציאה אחרת.

למה אי אפשר להשתמש ביציאה 80 במארח וירטואלי בענן?

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

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

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

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

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

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

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

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

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

מהו קובץ עזר?

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

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

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

כדי להציג מידע על מארח וירטואלי ספציפי, יש להשתמש ב-API של קבלת מארח וירטואלי:

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 מעדכן את המארח הווירטואלי כך שישתמש בהפניה, אפשר לשנות את מאגר המפתחות על ידי עדכון משתנה ההפניה.

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

כיצד יוצרים מארח וירטואלי?

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

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

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

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

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