4
votes

We try to migrate our Platform from classical IIS hosting to a service fabric micro service architecture. So fare we learned that a service fabric lives in a virtual machine scale set and uses Load balancer to communicate to the outside world.

The Problem we now facing is that we have different access points to our application. Like one for browser, one for mobile app. Both use the standard https port, but are different applications.

In iis we could use host headers to direct traffic to one or the other application. But with service fabric we can’t. easiest way for us would be multiple public IP’s. With that we could handle it with dns. We considered a couple solutions with no success.

  1. Load balancer with Multiple public ip’s. Problem: it looks like that only works with Cloud Services and we need to work with the new Resource Manager World there it seems to be not possible to have multiple public ip’s.

  2. Multiple public load balancer. Problem: Scale Sets accept only on load balancer instance pert load balancer type.

  3. Application Gateway. Seems not to support multiple public ip’s or host header mapping.

  4. Path mapping. Problem: we have the same path in different applications.

My questions are:

Is there any solution to use multiple IP’s and map the traffic internally to different ports?

Is there any option to use host header mapping with service fabric?

Any suggestion how I can solve my problem?

2
According to this doc, it is possible: "Front end IP configuration – a Load balancer can include one or more front end IP addresses, otherwise known as a virtual IPs (VIPs). These IP addresses serve as ingress for the traffic." azure.microsoft.com/en-us/documentation/articles/…itaysk

2 Answers

2
votes

Piling on some Service Fabric-specific info to Eli's answer: Yes you can do all of this and use an http.sys-based self-hosted web server to host multiple sites using different host names on a single VIP, such as Katana or WebListener in ASP.NET Core 1.

The piece to this that is currently missing in Service Fabric is a way to configure the hostname in your endpoint definition in ServiceManifest.xml. Service Fabric services run under Network Service by default on Windows, which means the service will not have access to create a URL ACL for the URL it wants to open an endpoint on. To help with that, when you specify an HTTP endpoint in an endpoint definition in ServiceManifest.xml, Service Fabric automatically creates the URL ACL for you. But currently, there is no place to specify a hostname, so Service Fabric uses "+", which is the strong wildcard that matches everything.

For now, this is merely an inconvenience because you'll have to create a setup entry point with your service that runs under elevated privileges to run netsh to setup the URL ACL manually.

We do plan on adding a hostname field in ServiceManifest.xml to make this easier.

1
votes

It's definitely possible to use ARM templates to deploy a Service Fabric cluster with multiple IPs. You'll just have to tweak the template a bit:

  • Create multiple IP address resources (e.g. using copy) - make sure you review all the resources using the IP and modify them appropriately
  • In the load balancer:
    • Add multiple frontendIPConfigurations, each tied to its own IP
    • Add loadBalancingRules for each port you want to redirect to the VMs from a specific frontend IP configuration
    • Add probes

As for host header mapping, this is handled by the Windows HTTP Server API (see this article). All you have to do is use a specific host name (or even a URL path) when configuring an HTTP listener URL (in OWIN/ASP.NET Core).