我有一种情况必须在下面遵循。
让我知道您是否对此有任何解决方案。
我不确定为什么您需要这样的设置并且您的要求不清楚,但是您是否看过Azure前门?这将能够使用您想要的任何域名来呈现您的应用程序,并且具有内置的智能负载平衡功能。
如果无法使用Front Door,则需要将xyz.com作为自定义域添加到每个App Service,并且需要使用TXT记录验证方法(与CNAME方法相对)。为此,请在xyz.com的权威区域中为每个应用程序服务FQDN创建TXT资源记录。例如,如果您的应用程序称为my-appX,其中X是实例编号,则您将在xyz.com(主机@)的根目录下创建8条TXT记录,其中包含条目my-appX.azurewebsites.net。
您可以通过多种方式在这8个实例之间实现负载平衡。如果您不需要任何智能的负载分配,则只需在xyz.com根目录中创建8条单独的CNAME记录,并为App Service的FQDN(DNS Round Robin)创建值。您需要检查DNS提供商是否在域的根目录支持CNAME资源记录,除非您使用的是Azure DNS,而我知道它使用@作为主机名来支持它。如果确实需要适当的负载分配,那么Azure Front Door还是最好的选择,或者Traffic Manager,尽管它不那么智能或功能丰富。
如果您的应用程序需要SSL,则除非您使用Azure Front Door的SSL卸载功能,否则您需要分别将证书安装到每个应用程序。您可以使用自动化帐户和PowerShell来从KeyVault部署证书,但是对于8个实例,这可能是过大了。
我认为您不能在不同的应用程序服务中添加相同的自定义域,因此您必须在每个应用程序服务(如xyz.com
)中添加根域sub1.xyz.com
的每个子域。 This is the way通过CNAME
记录映射应用程序服务中的子域。
或者,您可以在所有应用程序服务的顶部使用Azure Front Door,然后将xyz.com
添加到Azure前门的自定义域中。您可以按照this在前门上安装根域或顶点域。如果是这样,您可以通过自定义域访问前门,然后您的前门会通过匹配的路由规则将接收请求传递到后端。参见How Front Door matches requests to a routing rule。
希望这可以帮助您。