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

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

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)
  • דפדפן 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. כדי להשלים את התהליך, צריך לפנות אל התמיכה של Apigeeכדי להפעיל מחדש את נתבי Edge.