共用方式為

在多租用戶解決方案中使用 Azure Front Door

  • 發行項

Azure Front Door 是一種現代化雲端內容傳遞網路（CDN），可在使用者與應用程式在全球靜態和動態 Web 內容之間提供快速、可靠的存取。 本文說明在多租用戶系統中工作時，Azure Front Door 的一些功能很有用。 它也提供其他指引和範例的連結。

當您使用 Azure Front Door 作為多租使用者解決方案的一部分時，您必須根據解決方案的設計和需求做出一些決策。 您必須考慮下列因素：

  • 您有多少租使用者，以及您未來預期有多少租使用者？
  • 您是否在多個租用戶之間共用應用層、部署許多單一租使用者應用程式實例，或部署多個租用戶共用的個別部署戳記？
  • 您的租戶想要攜帶自己的網域名稱嗎？
  • 您會使用通配符網域嗎？
  • 您需要使用自己的 TLS 憑證，還是Microsoft管理 TLS 憑證？
  • 您是否已考慮適用於 Azure Front Door 的 配額和限制？ 您知道隨著你成長，會接近哪些限制嗎？ 如果您懷疑您將接近這些限制，請考慮使用多個 Azure Front Door 配置檔。 或者，請考慮您是否可以變更使用 Azure Front Door 來避免限制的方式。 請注意，進階 SKU 的限制高於標準 SKU。
  • 您或租使用者是否有IP位址篩選、地理封鎖或自訂WAF規則的需求？
  • 您所有租使用者的應用程式伺服器都面向因特網嗎？

支援多租戶的 Azure Front Door 功能

本節說明適用於多租用戶解決方案的 Azure Front Door 幾個重要功能。 它說明 Azure Front Door 如何協助您設定自定義網域，包括通配符網域和 TLS 憑證的相關信息。 它也概括說明如何使用 Azure Front Door 的路由功能來支援多租戶。

自訂網域

Azure Front Door 會為您建立的每個端點提供預設主機名，例如，contoso.z01.azurefd.net。 針對大部分的解決方案，您會將自己的網域名稱連結到 Azure Front Door 端點。 自定義功能變數名稱可讓您使用自己的商標，並根據用戶端要求中提供的主機名來設定路由。

在多租戶解決方案中，您可以使用租戶特定的網域名稱或子網域，並設定 Azure Front Door 將租戶的流量路由至該租戶工作負載的正確原始群組。 例如，您可以設定自訂網域名稱，例如 tenant1.app.contoso.com。 使用 Azure Front Door，您可以在單一 Azure Front Door 設定檔上設定多個自定義網域。

如需詳細資訊，請參閱 將自訂網域新增至 Front Door。

通配符網域

當您使用共用的主幹網域和租使用者特定子域時，通配符網域可以簡化 DNS 記錄和 Azure Front Door 流量路由設定的配置。 例如，假設您的租使用者使用 tenant1.app.contoso.com 和 tenant2.app.contoso.com等子域來存取其應用程式。 您可以設定通配符網域，*.app.contoso.com，而不是個別設定每個租使用者特定的網域。

Azure Front Door 支援建立使用通配符的自定義網域。 然後，您可以為抵達通配符網域的請求設定路由。 當您將新租用戶上線時，您不需要重新設定 DNS 伺服器、發出新的 TLS 憑證，或更新 Azure Front Door 設定檔的設定。

如果您將所有流量傳送至單一原始群組，通配符網域會正常運作。 但是，如果您有解決方案的個別標籤，單層通配符網域就不足。 例如，您必須使用多層級字幹網域或提供額外的設定，例如覆寫要用於每個租用戶的子域的路由。 如需詳細資訊，請參閱在多租戶解決方案中使用網域名稱時的考量。

Azure Front Door 不會發行通配符網域的受控 TLS 憑證，因此您必須購買並提供您自己的憑證。

如需詳細資訊，請參閱 通配符網域。

受控 TLS 憑證

取得和安裝 TLS 憑證可能會複雜且容易出錯。 TLS 憑證會在一段時間後到期，通常是一年，而且需要重新發出並重新安裝，以避免應用程式流量中斷。 當您使用 Azure Front Door 受控 TLS 憑證時，Microsoft會負責發行、安裝及更新自定義網域的憑證。

您的源應用程式可能裝載於另一個也提供受控 TLS 憑證的 Azure 服務上，例如 Azure App Service。 Azure Front Door 會透明地與其他服務搭配使用，以同步處理 TLS 憑證。

如果您允許租使用者提供自己的自訂網域，並且希望 Azure Front Door 發行這些網域名稱的憑證，您的租使用者不應該在他們的 DNS 伺服器上設定可能會阻止 Azure Front Door 頒發憑證的 CAA 記錄。 如需詳細資訊，請參閱TLS/SSL 憑證。

如需有關 TLS 憑證的詳細資訊，請參閱 使用 Azure Front Door 端對端 TLS。

路由

多租戶應用程式可能有一或多個為租戶提供服務的應用程式副本。 郵票經常用於支持多區域部署，並協助將解決方案擴展至大量租戶。

Azure Front Door 有一組功能強大的路由功能，可支援許多多租用戶架構。 您可以使用路由在戳記內的來源之間散發流量，或將流量傳送至特定租用戶的正確戳記。 您可以根據個別網域名稱、通配符網域名稱和網址路徑來設定路由。 您可以使用規則引擎進一步自定義路由行為。

如需詳細資訊，請參閱 路由架構概觀。

規則引擎

您可以使用 Azure Front Door 規則引擎來自定義 Azure Front Door 如何處理邊緣網路的請求。 規則引擎可讓您在 Azure Front Door 要求處理管線內執行小型邏輯區塊。 您可以針對各種工作使用規則引擎，包括下列各項：

  • 擷取 HTTP 要求的相關信息，包括 URL 和路徑的區段，並將資訊傳播至要求的另一個部分。
  • 在傳送至來源之前，請先修改 HTTP 要求的元素。
  • 先修改 HTTP 回應的某些部分，再傳回用戶端。
  • 覆寫請求的路由配置，例如變更請求應該傳送到的來源群組。

以下是在多租用戶解決方案中使用 Azure Front Door 規則引擎的一些範例方法：

  • 假設您部署多租用戶應用層，其中您也會使用租使用者特定的通配符子域，如下列範例案例所述。 您可以使用規則引擎從要求子域擷取租用戶標識碼，並將它新增至要求標頭。 此規則可協助應用層判斷請求是來自哪個租戶。
  • 假設您部署多租用戶應用層，並使用路徑型路由（例如，租使用者 1 和 2 分別 https://application.contoso.com/tenant1/welcome 和 https://application.contoso.com/tenant2/welcome）。 您可以使用規則引擎從 URL 路徑區段擷取租使用者標識元區段，並重寫 URL 以在查詢字串參數或要求標頭中包含租用戶識別符，以供應用程式取用。

如需詳細資訊，請參閱 什麼是 Azure Front Door 規則引擎？。

範例案例

下列範例案例說明如何在 Azure Front Door 中設定各種多租用戶架構，以及您所做的決策如何影響 DNS 和 TLS 設定。

許多多租戶解決方案會實施 部署戳記模式。 當您使用此部署方法時，通常會部署單一共用的 Azure Front Door 配置檔，並使用 Azure Front Door 將連入流量路由傳送至適當的戳記。 此部署模型是最常見的部署模型，本文中的案例 1 到 4 說明如何使用它來滿足各種需求。

不過，在某些情況下，您可能會在解決方案的每個版本中部署 Azure Front Door 設定檔。 案例 5 描述此部署模型。

案例 1：提供者管理的通配符網域、單一戳記

Contoso 正在建置小型多租用戶解決方案。 該公司會在單一區域中部署單一戳記，且該戳記會為其所有租使用者提供服務。 所有要求都會路由傳送至相同的應用程式伺服器。 Contoso 決定對所有租使用者使用通配符網域，例如 tenant1.contoso.com 和 tenant2.contoso.com。

Contoso 會使用此設定來部署 Azure Front Door：

顯示 Azure Front Door 設定的圖表，其中包含單一自定義網域、路由和原始群組，以及 Azure Key Vault 中的通配符 TLS 憑證。

DNS 組態

一次性設定： Contoso 設定了兩個 DNS 記錄：

  • *.contoso.com的通配符 TXT 記錄。 它會在 Azure Front Door 的自訂網域設置過程中被設定為指定的值。
  • 通配符 CNAME 記錄 *.contoso.com，這是 Contoso Azure Front Door 端點的別名：contoso.z01.azurefd.net。

新租用戶上線時： 不需要額外的設定。

TLS 組態

一次性設定： Contoso 購買通配符 TLS 憑證、將其新增至密鑰保存庫，以及授與 Azure Front Door 對保存庫的存取權。

新租用戶上線時： 不需要額外的設定。

Azure Front Door 設定

單次設定：Contoso 會建立 Azure Front Door 配置檔和單一端點。 他們會新增一個具有名稱 *.contoso.com 的自定義網域，並將其通配符 TLS 憑證與自定義網域資源產生關聯。 然後，他們會設定單一原始群組，其中包含其應用程式伺服器的單一原始來源。 最後，他們會設定路由，將自定義網域連線到原始群組。

新租用戶上線時： 不需要額外的設定。

好處

  • 此設定相對容易設定，併為客戶提供 Contoso 品牌 URL。
  • 此方法支援大量租戶。
  • 當新的租用戶上線時，Contoso 不需要變更 Azure Front Door、DNS 或 TLS 憑證。

缺點

  • 這種方法在超出單一應用程式標識或區域時不容易擴展。
  • Contoso 需要購買通配符 TLS 憑證，並在憑證到期時更新並安裝憑證。

案例 2：提供者管理的通配符網域、多個戳記

Proseware 正在建置一個跨澳大利亞和歐洲多個站點的多租用戶解決方案。 單一區域內的所有要求都會由該區域中的戳記提供。 和 Contoso 一樣，Proseware 決定對所有租使用者使用通配符網域，例如 tenant1.proseware.com 和 tenant2.proseware.com。

Proseware 會使用此設定來部署 Azure Front Door：

顯示 Azure Front Door 設定的圖表，其中包含多個自定義網路變數、路由和來源群組，以及 Key Vault 中的通配符 TLS 憑證。

DNS 組態

單次設定： Proseware 會設定兩個 DNS 記錄：

  • *.proseware.com的通配符 TXT 記錄。 它會被設定為 Azure Front Door 在自訂網域啓用過程中所指定的值。
  • 通配符 CNAME 記錄 *.proseware.com，這是 Proseware Azure Front Door 端點的別名：proseware.z01.azurefd.net。

新租用戶上線時： 不需要額外的設定。

TLS 組態

一次性設定： Proseware 購買通配符 TLS 憑證、將其新增至密鑰保存庫，並將 Azure Front Door 存取權授與保存庫。

新租用戶上線時： 不需要額外的設定。

Azure Front Door 設定

單次設定：Proseware 會建立 Azure Front Door 配置檔和單一端點。 公司為每個區域中的每個應用程式標籤或伺服器配置多個源站群組。

新租用戶上線時： Proseware 會將自定義網域資源新增至 Azure Front Door。 他們會使用名稱 *.proseware.com，並將其通配符 TLS 憑證與自定義網域資源產生關聯。 然後，他們會建立路由來指定租戶的請求應導向至哪個來源群組（標識）。 在上圖中，tenant1.proseware.com 路由至澳大利亞區域中的原始群組，tenant2.proseware.com 路由至歐洲區域中的原始群組。

好處

  • 當新的租用戶上線時，不需要 DNS 或 TLS 設定變更。
  • Proseware 維護單一 Azure Front Door 實例，用來將流量路由到多個區域的多個站點。

缺點

  • 每次新租用戶上線時，Proseware 都必須重新設定 Azure Front Door。
  • Proseware 必須注意 Azure Front Door 配額和限制，特別是路由數目和自定義網域，以及 複合路由限制。
  • 散文軟體需要購買通配符 TLS 憑證。
  • Proseware 負責在憑證到期時更新及安裝憑證。

情境 3：提供者管理的憑證型通配符子域

Fabrikam 正在開發多租戶解決方案。 該公司在澳大利亞和美國發行郵票。 單一區域內的所有要求都會由該區域中的戳記提供。 Fabrikam 將使用以戳記為基礎的字幹定義域，例如 tenant1.australia.fabrikam.com、tenant2.australia.fabrikam.com和 tenant3.us.fabrikam.com。

公司會使用此設定來部署 Azure Front Door：

圖表顯示 Azure Front Door 的組態，包含多個自定義的戳記型基幹網域、路由、原始群組以及存放於 Key Vault 中的通配符 TLS 憑證。

DNS 組態

一次性設定： Fabrikam 會為每個站點設定下列兩個通配符 DNS 記錄。

  • 每個戳記對應的通配符 TXT 記錄：*.australia.fabrikam.com 和 *.us.fabrikam.com。 這些值在自訂功能網域導入過程中，被設定為 Azure Front Door 所指定的。
  • 每個戳記的通配符 CNAME 記錄，*.australia.fabrikam.com 和 *.us.fabrikam.com，這兩者都是 Azure Front Door 端點 fabrikam.z01.azurefd.net的別名。

新租用戶上線時： 不需要額外的設定。

TLS 組態

一次性設定： Fabrikam 為每個戳記購買通配符 TLS 憑證、將它們新增至密鑰保存庫，以及授與 Azure Front Door 對保存庫的存取權。

新租用戶上線時： 不需要額外的設定。

Azure Front Door 設定

一次性設定： Fabrikam 會建立 Azure Front Door 配置檔和單一端點。 他們會為每個戳記設定原始群組。 他們會針對每個以戳記為基礎的子域，使用通配符建立自定義網域：*.australia.fabrikam.com 和 *.us.fabrikam.com。 他們為每個郵票的自訂網域建立路由，以將流量傳送至相應的來源群組。

新租用戶上線時： 不需要額外的設定。

好處

  • 此方法可讓 Fabrikam 擴展至多個集區的大量租戶。
  • 當新的租用戶上線時，不需要 DNS 或 TLS 設定變更。
  • Fabrikam 會維護單一 Azure Front Door 實例，以將流量路由傳送至多個區域的多個戳記。

缺點

  • 由於 URL 採用多層次的網域名稱結構，因此使用起來較為複雜。
  • Fabrikam 需要購買多個通配符 TLS 憑證。
  • Fabrikam 負責在 TLS 憑證到期時更新及安裝憑證。

案例 4：虛名網域

Adventure Works Cycles 正在建置多租用戶解決方案。 該公司在澳大利亞和美國等多個地區部署郵票。 單一區域內的所有要求都會由該區域中的戳記提供。 Adventure Works 將允許租戶使用自己的網域名稱。 例如，租使用者 1 可能會設定自訂網域名稱，例如 tenant1app.tenant1.com。

公司會使用此設定來部署 Azure Front Door：

顯示 Azure Front Door 設定的圖表，其具有多個自定義虛名網域、路由和原始群組，以及 Key Vault 中 TLS 憑證和 Azure Front Door 所管理的 TLS 憑證組合。

DNS 組態

一次性設定： 無。

新租用戶上線時： 租用戶必須在自己的 DNS 伺服器上建立兩筆記錄：

  • 網域驗證的 TXT 記錄。 例如，租使用者 1 必須設定名為 tenant1app.tenant1.com 的 TXT 記錄，並在自定義網域上線程式期間將它設定為 Azure Front Door 所指定的值。
  • CNAME 記錄，其別名為 Adventure Works Azure Front Door 端點。 例如，租使用者 1 必須設定名為 tenant1app.tenant1.com 的 CNAME 記錄，並將它對應至 adventureworks.z01.azurefd.net。

TLS 組態

Adventure Works 及其租用戶必須決定簽發 TLS 憑證的人員：

  • 最簡單的選項是使用 Azure Front Door 來發行和管理憑證，但租用戶不應該在其 DNS 伺服器上設定 CCA 記錄。 如果這樣做，這些紀錄可能會防止 Azure Front Door 憑證授權機構頒發憑證。
  • 或者，承租人可以提供自己的憑證。 他們需要使用 Adventure Works 將憑證上傳至密鑰保存庫，並提供 Azure Front Door 的存取權。

Azure Front Door 設定

一次性設定： Adventure Works 會建立 Azure Front Door 配置檔和單一端點。 他們會為每個戳記設定原始群組。 它們不會建立自定義網路網域資源或路由。

當新的租用戶上線時： Adventure Works 會將自定義網域資源新增至 Azure Front Door。 他們會使用租用者提供的網域名稱，並將適當的 TLS 憑證與自訂網域資源產生關聯。 然後，他們會建立路由，以指定租使用者要求應導向至哪個原始群組（戳記）。 在上圖中，tenant1app.tenant1.com 會路由至澳大利亞區域中的原點群組，而 tenant2app.tenant3.com 會路由至美國區域中的原點群組。

好處

  • 客戶可以提供自己的網域名稱。 Azure Front Door 會以透明方式將要求路由傳送至多租戶解決方案。
  • Adventure Works 會維護 Azure Front Door 的單一實例，以將流量路由傳送至多個區域的多個戳記。

缺點

  • Adventure Works 必須在每次新租用戶上線時重新設定 Azure Front Door。
  • 租戶必須參與入職流程。 他們需要進行 DNS 變更，並可能發出 TLS 憑證。
  • 租戶會控制其 DNS 記錄。 DNS 記錄的變更可能會影響其存取 Adventure Works 解決方案的能力。
  • Adventure Works 必須注意 Azure Front Door 配額和限制，特別是路由數目和自定義網路變數，以及 複合路由限制。

案例 5：每個戳記的 Azure Front Door 配置檔

您可以為每個戳記部署 Azure Front Door 設定檔。 如果您有 10 個戳記，則會部署 10 個 Azure Front Door 實例。 如果您需要限制每個戳記的 Azure Front Door 組態的管理存取，此方法會很有用。 如果您需要使用多個 Azure Front Door 配置檔，以避免超過資源配額或限制，它也很有用。

提示

Azure Front Door 是全域資源。 即使您部署區域範圍的戳記，每個 Azure Front Door 配置檔都會全域散發。 您應該考慮您是否真的需要部署多個 Azure Front Door 配置檔，以及您藉由執行此動作而獲得哪些優點。

如果您有供多個租戶使用的身份驗證憑證，則必須考慮如何將流量引導至每個租戶。 檢閱上述案例中所述的方法，並考慮結合方法以符合您的需求。

好處

  • 如果您跨多個配置檔擴充設定，則不太可能達到 Azure Front Door 資源限制。 例如，如果您需要支援大量自定義網域，您可以將網域分成多個 Azure Front Door 配置檔，並保留在每個配置檔的限制內。
  • 此方法可讓您設定 Azure Front Door 資源管理許可權的範圍。 您可以使用 Azure 角色型存取控制 （RBAC） 將單一戳記設定檔的存取權授與系統管理員。

缺點

  • 這種方法通常成本較高，因為您會部署更多的設定檔。 如需詳細資訊，請參閱 瞭解 Front Door 計費。
  • 您可以部署到單一 Azure 訂用帳戶的 Azure Front Door 配置檔數目有限制。 如需詳細資訊，請參閱 Front Door 配額和限制。
  • 您必須個別設定每個戳記的 Azure Front Door 配置檔，而且您必須管理每個戳記的 DNS 設定、TLS 憑證和 TLS 組態。

貢獻者

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主要作者：

其他參與者：

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

後續步驟