Clarification: Naming Service

[senj]

Hello,

first, congratulation to service fabric, it's a great product.

I need clarification about the naming service so I'll describe how I see its role and functions.

• Nameing Service is only for "service fabric internal" use and can't be called by clients outside of SF.
• I can query a service's address by it's namespace

 ResolvedServicePartition partition = await client.ServiceManager.ResolveServicePartitionAsync(new Uri(name));
ICollection<ResolvedServiceEndpoint> resolvedEndpoints = partition.Endpoints;

• What I did: build a discovery service that wraps this functionality in REST to allow clients (my API Gateway like Azure Api Management) to resolve the dynamically assigned addresses.
• My Services do not use the "port" part of

 <Endpoint Name="ServiceEndpoint" Type="Input" Protocol="http" Port="80" />

as I don't want collisions or provide a service-port mapping, these ports are assigned dynamically and that's fine.

Is there an easiert way or am I using it completly wrong?
I don't know what the "HTTP Gateway" described in the ClusterManifest has to do with it?
The documentation is only about "internal" address resolution, as far as I saw.

I'm using the "old" ASP.NET 5 Template but will now move to https://github.com/weidazhao/Hosting as rc2 got released.

Thanks..

[cwe1ss]

AFAIK (I'm not from the SF team) that's correct! Note that there are already two http based gateway projects ( weidazhao/Hosting and c3-ls/ServiceFabric-Http ) so you don't have to write your own gateway if they fit your scenario.

I don't know what the "HTTP Gateway" described in the ClusterManifest has to do with it?

that's the web-based "Service Fabric Explorer" on port 19080

[vipul-modi]

In addition to the HTTP management endpoint (Http Gateway), the product now includes HTTP Application Gateway as well. The HTTP application gateway provides a simple HTTP based resolve and forward (reverse proxy) with SSL termination. This allows you to address your HTTP based micro-services from outside the cluster using http://:/applicationName/serviceName

[cwe1ss]

really? that would be awesome - are there any docs for this??

[senj]

Yes that's what I meant the Application Gateway.
In my ClusterManifest there is a different port for each node

<HttpApplicationGatewayEndpoint Port="19081" Protocol="http" />
...
<HttpApplicationGatewayEndpoint Port="19087" Protocol="http" />

so for service fabric:/DealerApplication/DealerService I tried:
http://localhost:19087/dealerapplication/dealerservice/swagger/ui
but I got empty page, although
http://localhost:33002/swagger/ui
works.

[vipul-modi]

We are working on detailed documentation of the application gateway functionality. The application gateway will append the URI that you provide after the service name to the resolved address of the service. So in your case the request will get forwarded to the micro-service as http://localhost:33003/swagger/ui/swagger/ui. The recommended approach is to just listen on the port on the micro-service or adjust the URI when sending the request.

[seanmck]

Closing this for now. When the doc(s) Vipul is referring to are published, we'll update this issue.

[senj]

Any update on this?

[cwe1ss]

seems like there now is a document for this. thanks for documenting it!

https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/

[senj]

There is a follow-up question at http://stackoverflow.com/questions/38881031/how-to-configure-and-enable-azure-service-fabric-reverse-proxy-for-on-premises-c/39020576#39020576 for on-premise configuration. Would be great to have this one answered.

[achibus]

senj, thank you for referring to this post. Hope someone can give us a clarifying answer to this question.

[boarmanc]

I updated the StackOverflow question mentioned above with instructions on how I got the reverse proxy working on my Service Fabric on-premises multi-vm cluster. Long story short: add the needed HttpApplicationGateway settings to the ClusterManifest and upgrade the cluster.