SF endpoint resolution

[jjcollinge]

I'd like to see our default resolution of endpoints handle a little differently I think - currently we just grab the first endpoint that has contains http (

traefik-extra-service-fabric/servicefabric.go

Line 226 in 6e90a9e

func getReplicaDefaultEndpoint(replicaData *sf.ReplicaItemBase) (string, error) {

). Making the default behavior completely dependent on the endpoint order returned by the SF API. I'll try spend some time investigating how we can do this better.

[lurock]

The big issue I see on this is that you cannot have a primary listening endpoint that you want Traefik to serve web request through and a secondary endpoint on a different port that you use to point health checks to.

I use this method to stop serving web traffic to my service when an upgrade is happening. When I get a cancellation notification from service fabric I then shutdown my health check listener so that web request from Traefik will stop coming to my service while I keep open my primary listener for just a little while longer to finish up existing request. It is a great way to have zero down time with your services.

I would really like to see a way to configure the listener I want Traefik to use to serve request through.

[nokjuh]

We are also interested in getting multiple endpoint support with Service Fabric.

Our use case would be to actually be able to direct e.g. /path1 to endpoint1 and /path2 to endpoint2.

[jjcollinge]

@nokjuh multiple endpoints was added in #47

[nokjuh]

@jjcollinge I'm sorry, I don't quite understand how the traefik.servicefabric.endpointname will allow the use case I'm looking for. It seems like it would just allow specifying that a specific endpoint is used as the default, although it's quite possible I'm not understanding it correctly.

I have a Windows Server container that is running in Service Fabric, and Traefik is running on the cluster on each node, redirecting traffic to correct container based on the hostname of the request. What I'd like to have is the possibility to connect to multiple services on the container based on the path.

E.g. call comes to cluster with address https://contoso1.example.com/webui/sample
=> fabric:/Contoso1 is selected based on the DNS name (this is already possible)
=> Based on /webui path, the call is directed to the WebUiEndpoint (corresponding to 80 on the container)

Another call comes in with address https://contoso1.example.com/desktop/sample
=> fabric:/Contoso1 is selected based on the DNS name
=> Based on /desktop path, the call is directed to the DesktopEndpoint (corresponding to 8080 on the container)

In the container configuration:

    <Endpoints>
      <Endpoint Name="WebUiEndpoint" UriScheme="http" Port="80" Protocol="http" Type="Input" />
      <Endpoint Name="DesktopEndpoint" UriScheme="http" Port="8080" Protocol="http" Type="Input" />
    </Endpoints>

It looks like traefik.servicefabric.endpointname would allow me to specify that I want to use e.g. DesktopEndpoint for all traffic, without needing to worry that it would select WebUiEndpoint because it happens to be the first in the endpoint order returned by Service Fabric. But I don't see how I could use it to define "this path goes to this endpoint, while this other path goes to this other endpoint".

[jjcollinge]

Sorry @nokjuh, you are correct, I quickly glanced at the issue and didn't fully appreciate what you were trying to do. I don't believe this is currently possible as each SF service resolves to a single backend endpoint. To serve both endpoints via traefik, I think you'd need to either an internal redirect from your default endpoint to your secondary, or customise the code/template to create a backend per service endpoint rather than per service. Is there any possibility of splitting these 2 web services out into separate containers?

[lawrencegripper]

I agree I think your options are either to customize the template here https://github.com/containous/traefik-extra-service-fabric/blob/master/servicefabric_tmpl.go to add multiple backends per services or split the services out into different containers.

Here is a guide to overriding the template https://docs.traefik.io/configuration/commons/#override-default-configuration-template

[nokjuh]

Thanks for the tips. The architecture doesn't really allow splitting the services to separate containers. Currently we have implemented an internal redirect (another Traefik instance running inside the container) to handle the path redirection.

So far it seems like we can live with that, but it would be good to get rid of the extra redirect and extra complexity. Having Traefik support multiple endpoints each resolving to a separate backend would make that possible.

Editing the template might also work, although it didn't seem to be very simple. I might take a more detailed look at some point if we run into further issues with the current setup.