[FIXED] How to get Service Fabric Reverse Proxy to work on Azure

Issue

I created a Azure Service Fabric Web API and planned to reach it through Service Fabric's built in Reverse Proxy.

All was working well locally but when I published to Azure, trying to access the route through Reverse Proxy would time out.

I thought it might be my app, so I just popped open a new solution with the default template and published to my local. Everything worked fine Reverse Proxy and all. So I published to Azure and again had the same issue.

I could access the Web API on azure through the normal route (through the endpoint of the service) for example:

xxxx.east.cloudapp.azure:8080/api/values

But going through the Reverse Proxy port of 19081 times out:

xxxx.east.cloudapp.azure:19081/[app]/[service]/api/values

I did make sure to tick off Enable Reverse Proxy when setting up the cluster resource on Azure, and set the port to 19081. Both of the above works fine on localhost, but only the normal route works on Azure.

Was wondering if there's some extra editing of the manifest or something I had to do to make it work on Azure correctly?

Solution

Did you see the documentation on how to configure it?

If you're going to expose services on the internet, be aware that the built-in one causes every service to become exposed, it's not hardened, it's vulnerable to DOS attacks. Docs

I recommend having a look at Traefik as a reverse proxy and load balancer. You can run it as a (containerized) ingress routing service inside the cluster, and direct HTTP calls to your services.

• Here's the documentation.
• Here's how to get started.
• Here's an example.

Alternatively, you can use Api Gateway, which integrates with SF too. Or even Nginx.

Answered By - LoekD

Answer Checked By - Mary Flores (PHPFixing Volunteer)

Read More

[FIXED] Why should I use the Service Fabric Reverse Proxy instead of the Azure App Gateway to talk to SF Cluster?

Issue

It's a long question and there are trade-offs, I'm sure. The documentation in this area:

Doesn't give me enough to answer the question above confidently.

So, they say: "Azure Application Gateway (AG) attempts to resolve a service address again and retry the request when a service cannot be reached".

I know how the Service Fabric Reverse Proxy (RP) does this by encapsulating the resolve loop. Does the AG have this capability too? The AG is a reverse proxy too, by all accounts.

So, crucially for external traffic into a SF cluster, why would I use one over another (I am aware that the RP allows intra-cluster comms too and this is a good fit).

Solution

Well, for external traffic into the cluster you will get an Azure Load Balancer / Reverse Proxy combination out-of-the-box. But whether it is sufficient is another question. We had the same decision to make, we ended up using the Application Gateway.

The differences between the Azure Load Balancer and Application Gateway are outlined in this document.

Some takeaways:

• Azure Load Balancer works at the transport layer (Layer 4 in the OSI network reference stack). It provides network-level distribution of traffic across instances of an application running in the same Azure data center.
• Application Gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.

So, Application Gateway additionally supports SSL termination, SSL end to end and URL-based routing which makes it a good candidate for Service Fabric applications that have external clients.

Answered By - Peter Bons

Answer Checked By - Mildred Charles (PHPFixing Admin)

Read More