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

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

לקוח Cloud עם חשבון בתשלום יכול ליצור מארח וירטואלי בארגון.

• מידע על מארחים וירטואליים
• הגדרה של מארחים וירטואליים
• הגדרת TLS
• מאגרי מפתחות ומאגרי אישורים

מי יכול ליצור ולשנות מארחים וירטואליים בענן

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

לדוגמה, לקוחות בתשלום יכולים:

• הפעלה של TLS חד-כיווני ודו-כיווני
• מציינים את מאגר המפתחות או מאגר האישורים שמשמשים את המארח הווירטואלי

בחשבונות בחינם ובחשבונות ניסיון אי אפשר ליצור או לשנות מארחים וירטואליים, והם מוגבלים למארחים וירטואליים שנוצרו עבורם בזמן ההרשמה ל-Edge. מידע נוסף על תוכניות התמחור של Edge זמין בכתובת https://apigee.com/api-management/#/pricing.

דרישות להגדרת מארח וירטואלי בענן

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

יצירת מארח וירטואלי באמצעות דפדפן

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

כדי ליצור מארח וירטואלי באמצעות ממשק המשתמש של Edge:

1. נכנסים לחשבון בכתובת apigee.com/edge.
2. בוחרים באפשרות ניהול > מארחים וירטואליים.
3. בוחרים את הסביבה, למשל prod או test.
4. בוחרים באפשרות + Virtual Host כדי ליצור מארח וירטואלי, או בוחרים את השם של מארח וירטואלי קיים כדי לערוך אותו.
5. בטבלה שלמעלה מפורט מידע על מילוי השדות של המארח הווירטואלי.

הגדרת מארח וירטואלי ל-TLS חד-כיווני

אובייקט XML שמגדיר את המארח הווירטואלי. לדוגמה, אובייקט ה-XML הבא מגדיר מארח וירטואלי עבור TLS חד-כיווני:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

בהגדרה הזו:

• מציינים את השם כ-myTLSVHost. משתמשים בשם כדי להפנות למארח וירטואלי ב-proxy ל-API או בקריאה ל-API.
• מציינים את הכינוי למארח בתור api.myCompany.com. זהו הדומיין שפונה לציבור ומשמש לגישה לממשקי ה-API שלכם, כפי שמוגדר בהגדרת DNS וברשומת CNAME.
• מציינים את מספר היציאה כ-443. אם לא מציינים יציאה, ברירת המחדל היא יציאה 443.
• מפעילים את TLS לפי הצורך.
  
  האלמנט <Enable> מוגדר כ-true כדי להפעיל TLS חד-כיווני, והאלמנטים <KeyStore> מציינים את מאגר המפתחות ואת הכינוי של המפתח שמשמשים את חיבור ה-TLS.
  
  כדי להפעיל TLS דו-כיווני, מגדירים את <ClientAuthEnabled> כ-true ומציינים מאגר אישורים באמצעות הרכיב <TrustStore>. מאגר האישורים המהימנים מכיל את הרשות המנפיקה של אישור הלקוח ואת שרשרת רשות האישורים של האישור, שנדרשים.
  
  הערה: מכיוון ש-Edge תמך במקור ב-SSL, התג שמשמש להגדרת TLS נקרא <SSLInfo>.

שימו לב, יש מאפיינים נוספים שאפשר להגדיר במארח הווירטואלי. רשימה של כל המאפיינים זמינה במאמר מאפייני מארח וירטואלי.

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

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

    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>

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

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

הגבלות על השימוש בהפניות למאגרי מפתחות ולמאגרי אישורים

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

• אפשר להשתמש בהפניות למאגר מפתחות ולמאגר אישורים במארחים וירטואליים רק אם אתם תומכים ב-SNI ומסיימים את ה-SSL בנתבי Apigee.
• אם יש לכם מאזן עומסים לפני נתבי Apigee, ואתם מסיימים את ה-TLS במאזן העומסים, אתם לא יכולים להשתמש בהפניות למאגר מפתחות ולמאגר אישורים במארחים וירטואליים.

הגדרת מארח וירטואלי ל-TLS דו-כיווני

כדי להפעיל TLS דו-כיווני, מגדירים את הרכיב <ClientAuthEnabled> לערך true ומציינים חנות מהימנה באמצעות reference עם הרכיב <TrustStore>. מאגר ה-truststore מכיל את הרשות המנפיקה של האישור של הלקוח ואת שרשרת רשות האישורים של האישור, שנדרשים. בנוסף, הלקוח צריך להיות מוגדר בצורה נכונה ל-TLS דו-כיווני.

כדי ליצור מארח וירטואלי ל-TLS דו-כיווני, יוצרים אובייקט XML שמגדיר את המארח הווירטואלי:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTestTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

בהגדרה הזו:

• כדי להפעיל TLS דו-כיווני, מגדירים את <ClientAuthEnabled> לערך true.
• מציינים את ההפניה אל מאגר האישורים באמצעות הרכיב <TrustStore>. מאגר האישורים המהימנים מכיל את הרשות המנפיקה של אישור הלקוח ואת שרשרת רשות האישורים של האישור, שנדרשים.

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

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

אישור תקופת הניסיון בחינם של Apigee מוגדר לדומיין *.apigee.net. לכן, גם <HostAlias> של המארח הווירטואלי חייב להיות בפורמט *.apigee.net.

אם אתם מבצעים TLS דו-כיווני, אתם עדיין צריכים להגדיר את הרכיב <ClientAuthEnabled> לערך true, ולציין מאגר אישורים באמצעות הפניה עם הרכיב <TrustStore>, כפי שמתואר למעלה במאמר הגדרת מארח וירטואלי ל-TLS דו-כיווני.

אובייקט XML שמגדיר את המארח הווירטואלי באמצעות האישור והמפתח של תקופת הניסיון בחינם של Apigee, משמיט את הרכיבים <KeyStore> ו-<KeyAlias> ומחליף אותם ברכיב <UseBuiltInFreeTrialCert>, כמו שמוצג בהמשך:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

ערך ברירת המחדל של הרכיב <UseBuiltInFreeTrialCert> הוא false.

ל-TLS דו-כיווני, מגדירים את המארח הווירטואלי כך:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <TrustStore>ref://myTestTruststoreRef</TrustStore>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

בממשק המשתמש של Edge, בוחרים באפשרות Use built-in free trial certificate (שימוש באישור מובנה של תקופת ניסיון בחינם) כשיוצרים את המארח הווירטואלי כדי להשתמש באישור ובמפתח של Apigee בחינם:

יצירת מארח וירטואלי

כדי ליצור את המארח הווירטואלי:

1. יוצרים רשומת DNS ורשומת CNAME לדומיין שפונה לציבור, api.myCompany.com בדוגמה הזו, שמפנה אל [org]-[environment].apigee.net.
2. יוצרים ומגדירים מאגר מפתחות בשם myTestKeystore בדוגמה הזו, באמצעות התהליך שמתואר כאן: יצירה של מאגרי מפתחות ומאגרי אישורים באמצעות ממשק המשתמש של Edge. בדוגמה הזו, צריך לוודא שבמאגר המפתחות נעשה שימוש בשם כינוי myKeyAlias עבור האישור והמפתח הפרטי.
3. מעלים את האישור והמפתח למאגר המפתחות. מוודאים ששם הדומיין שצוין באישור תואם לכינוי המארח שבו רוצים להשתמש עבור המארח הווירטואלי.

4. יוצרים הפניה למאגר המפתחות באמצעות ממשק המשתמש או ה-API של Edge. ההפניה מציינת את השם של מאגר המפתחות ואת סוג ההפניה כ-KeyStore. מידע נוסף על יצירה ושינוי של קובצי עזר זמין במאמר עבודה עם קובצי עזר.

5. יוצרים את המארח הווירטואלי באמצעות API‏ Create a Virtual Host. חשוב לציין את ההפניה הנכונה למאגר המפתחות ואת הכינוי של המפתח. כדי להשתמש ב-API, שולחים את קריאת ה-API הבאה מסוג POST כדי ליצור את מאגר המפתחות בשם myTLSVHost:

   curl -X POST -H "Content-Type:application/xml" \
     https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts \
     -d '<VirtualHost name="myTLSVHost">
       <HostAliases>
         <HostAlias>api.myCompany.com</HostAlias>
       </HostAliases>
       <Port>443</Port>
       <SSLInfo>
         <Enabled>true</Enabled>
         <ClientAuthEnabled>false</ClientAuthEnabled>
         <KeyStore>ref://myTestKeystoreRef</KeyStore>
         <KeyAlias>myKeyAlias</KeyAlias>
       </SSLInfo>
     </VirtualHost>' \
     -u orgAdminEmail:password

   אם מבצעים TLS דו-כיווני עם הלקוח, מגדירים את <ClientAuthEnabled> ל-true ומציינים את מאגר האישורים באמצעות הרכיב <TrustStore>. הלקוח צריך להיות מוגדר בצורה נכונה ל-TLS דו-כיווני, כלומר ל-Edge יש truststore שמכיל את מנפיק האישור של הלקוח ואת שרשרת האישורים. יוצרים את מאגר האישורים באמצעות התהליך שמתואר כאן.

6. אם יש לכם שרתי proxy קיימים של API, מוסיפים את המארח הווירטואלי לרכיב <HTTPConnection> ב-ProxyEndpoint. המארח הווירטואלי נוסף אוטומטית לכל ה-API Proxy החדשים. מידע נוסף זמין במאמר הגדרת proxy ל-API לשימוש במארח וירטואלי.

אחרי שמעדכנים את proxy ל-API לשימוש במארח הווירטואלי, ויוצרים את רשומת ה-DNS ורשומת ה-CNAME של כינוי המארח, אפשר לגשת ל-proxy ל-API כמו שמוצג בהמשך:

https://api.myCompany.com/v1/{project-base-path}/{resource-path}

לדוגמה:

https://api.myCompany.com/v1/weather/forecastrss?w=12797282

שינוי של מארח וירטואלי

לקוחות Cloud בתשלום מבצעים שתי משימות עיקריות כדי לשנות מארח וירטואלי קיים:

1. שינוי הערך של הפניה למאגר מפתחות או למאגר אישורים.
   
   הערה: אחרי שמגדירים <KeyStore> או <TrustStore> לשימוש בהפניה, אפשר לשנות את ערך ההפניה בכל שלב. עם זאת, אם תרצו לשנות את <KeyStore> או את <TrustStore> כדי להשתמש בהפניה אחרת, או לשנות את <KeyAlias> כדי להשתמש בכינוי אחר, תצטרכו לפנות לתמיכה של Apigee Edge.
2. שינוי מאפייני ה-TLS של המארח הווירטואלי.

שינוי הערך של הפניה

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

לפני שמשנים את הערך של ההפניה:

1. יוצרים מאגר מפתחות חדש ומעלים אישור ומפתח כמו שמתואר במאמר יצירת מאגרי מפתחות ומאגרי אישורים באמצעות ממשק המשתמש של Edge. במאגר המפתחות החדש, חשוב להשתמש באותו שם לכינוי המפתח שבו השתמשתם במאגר המפתחות הקיים.
2. אם צריך, יוצרים מאגר אישורים חדש ומעלים אישור כמו שמתואר במאמר יצירת מאגרי מפתחות ומאגר אישורים באמצעות ממשק המשתמש של Edge.
3. משנים את ההפניה כמו שמתואר במאמר עבודה עם הפניות.

שינוי מאפייני ה-TLS של המארח הווירטואלי

לקוחות בתשלום יכולים להשתמש ב-API‏ Update a Virtual Host כדי לעדכן מארח וירטואלי. ה-API הזה מאפשר להגדיר את כל הנכסים של המארח הווירטואלי שמתוארים במאמר הפניה לנכס של מארח וירטואלי.

כשמשנים את המארח הווירטואלי, Edge מבצע אימות דומה לזה שמתבצע כשיוצרים מארח וירטואלי. כלומר, כשמבצעים שינוי, Edge מאמת את הדברים הבאים:

• הדומיין שצוין על ידי הכינוי של המארח לא נמצא בשימוש בארגון אחר ובסביבה אחרת.
• אתם הבעלים של שם הדומיין. באופן ספציפי, Edge בודק שהמידע הבא באישור זהה לכינוי המארח:
  • CN – שם נפוץ
  • SAN - Subject Alternative Name
  • דפדפן Edge מאמת שתוקף האישור לא פג.

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

1. מעדכנים את המארח הווירטואלי באמצעות ה-API‏ Update a Virtual Host. כשמשתמשים ב-API, צריך לציין את ההגדרה המלאה של המארח הווירטואלי בגוף הבקשה, ולא רק את הרכיבים שרוצים לשנות. בדוגמה הזו, הגדרתם את הערך של המאפיין proxy_read_timeout:

   curl -X PUT -H "Content-Type:application/xml" \
     https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts/{vhost_name} \
     -d '<VirtualHost name="myTLSVHost">
       <HostAliases>
         <HostAlias>api.myCompany.com</HostAlias>
       </HostAliases>
       <Port>443</Port>
       <SSLInfo>
         <Enabled>true</Enabled>
         <ClientAuthEnabled>false</ClientAuthEnabled>
         <KeyStore>ref://myTestKeystoreRef</KeyStore>
         <KeyAlias>myKeyAlias</KeyAlias>
       </SSLInfo>
       <Properties>
          <Property name="proxy_read_timeout">50</Property>
            </Properties>
     </VirtualHost>' \
     -u orgAdminEmail:password

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

כל המארחים הווירטואליים החדשים ב-Edge in the Cloud משתמשים בהפניה אל Keystore ו-Truststore. הפניות מאפשרות לשנות את מאגר המפתחות ואת מאגר האישורים בלי לפנות אל התמיכה של Apigee Edge.

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

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

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

1. אם נדרש, יוצרים מאגר מפתחות חדש ומעלים אישור כמו שמתואר במאמר יצירת מאגרי מפתחות ומאגרי אישורים באמצעות ממשק המשתמש של Edge. אם כבר יש לכם מאגר מפתחות, אתם יכולים להגדיר הפניה שתצביע אליו.
2. יוצרים הפניה חדשה למאגר המפתחות.
3. אם נדרש, יוצרים מאגר אישורים חדש ומעלים אישור. אם כבר יש לכם חנות אישורים, אתם יכולים להגדיר הפניה שתצביע אליה.
4. יוצרים הפניה חדשה למאגר האישורים.
5. מעדכנים את המארח הווירטואלי כדי להגדיר את מאגר המפתחות, הכינוי, מאגר האישורים וכל מאפיין אחר של TLS. המטען הייעודי (payload) של השיחה הוא:

   curl -X PUT -H "Content-Type:application/xml" \
     https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts/{vhost_name} \
     -d '<VirtualHost  name="myTLSVHost">
           <HostAliases>
             <HostAlias>api.myCompany.com</HostAlias>
           </HostAliases>
           <Port>443</Port>
           <OCSPStapling>off</OCSPStapling>
           <SSLInfo>
             <Enabled>true</Enabled>
             <ClientAuthEnabled>true</ClientAuthEnabled>
             <KeyStore>ref://myKeyStore2Way</KeyStore>
             <KeyAlias>keyAlias</KeyAlias>
             <TrustStore>ref://myTrustStore2Way</TrustStore>
             <IgnoreValidationErrors>false</IgnoreValidationErrors>
           </SSLInfo>
         </VirtualHost>' \
       -u orgAdminEmail:pWord

6. כדי להפעיל מחדש את נתבי Edge ולהשלים את התהליך, צריך לפנות אל התמיכה של Apigee.