Service Fabric Provider for Traefik 2

[clausndk]

Do you want to request a feature or report a bug?

Feature

What did you expect to see?

A Service Fabric provider for version 2 of Traefik.

How can I help with a Provider, if I'm able to help?

[johnib]

Hi folks -- when can we expect a predict date for this feature?

[JustinKaffenberger]

My team would also benefit greatly from this. We love Traefik's integration with Service Fabric, and are excited to try Traefik 2.

[lawrencegripper]

Hi,

I currently can’t commit any time to picking this up. Happy to help answer questions, when possible, for anyone we does take this on.

[nokjuh]

The lack of Service Fabric provider is completely blocking us from taking Traefik 2.x into use. This would be a great feature.

[fgo2000]

Hello,
Any idea if there is any documentation on how to implement a provider ? Or is the code the documentation ?
Thanks

[lawrencegripper]

@ldez any good guides for someone looking to take on updating this provider to v2?

[Mahons]

Hi @fgo2000, I'm happy to work on this with you if you're interested. Caveat, no experience with Go but keen to learn!

[ldez]

The Docker provider is good example.

[fgo2000]

Hi @fgo2000, I'm happy to work on this with you if you're interested. Caveat, no experience with Go but keen to learn!

Same for me, so I cannot commit on anything yet. Thanks for proposal.

[gheibia]

If the containous has internalized and supported Service Fabric as a provider for V1.x, I assume there will be an item on their V2 board for this. @ldez Is that not going to be the case?

[lawrencegripper]

I'm not sure this is too fair. They were nice enough to review and help me/Joni ship support in V1 and merged it. I don't think this means they are duty bound to continue to support it forever. Based on the docs there are quite a few providers that aren't in V2 which where in V1.

[gheibia]

That doesn't mean there can't be community contribution (in fact I'll be more than happy to help), but I'd like to clarify how actually the team at containous approach the problem of supporting providers. How are they prioritized for instance? Basically, I'm trying to get an insight into their milestones.

[geraldcroes]

Hi everyone,

we've heard the Service Fabric community asking for options to migrate to Traefik 2.X and perfectly understand why they'd like to switch to this new version. As you know, Service Fabric hasn't yet been ported to the 2.X branch. This support was brought to Traefik by the Microsoft team (thanks), and we're currently studying options with Microsoft to bring this support back to 2.X (even though we can't yet commit to it and can't provide any ETA).

In the meantime, Traefik 1.X is still supported, and we'll keep you updated.

[wasabii]

I am taking a stab at investigating this right now. However, I'm not a Go developer, and for whatever reason Go mystifies me. So, my first go-around (hah) is going to be using the File provider and a side-car that updates a YAML file. Obviously, not an ideal situation. Not something to contribute to Traefik.

However, this is fine as a proving ground, and has raised several questions with how labels have changed in 2.0 providers.

2.0 began explicitly declaring router, middleware and service names within the labels for containers. That is, instead of just specifying traefik.frontend and traefik.backend we would now include the service name and router name directly in the label. This introduces an issue for my current usage of Traefik: I don't want developers submitting application upgrades that have the potential to cause conflicts between multiple services between applications running in my Service Fabric clusters. For instance, DevGroupA could deploy a router with traefik.http.routers.router0.foo and DevGroupB could deploy a router with traefik.http.routers.router0.foo. And Traefik would consider these the same.

So, I am trying to come up with a strategy to mitigate this.

My current line of thinking is to consider router, middleware and service names as 'local to the application'. That is, even if the user specifies traefik.http.routers.router0 it would be munged to something like AppName_router0. The names would continue to be partially auto-generated but scoped to the Application boundary, which is the deployable unit.

I also wonder if they should just be "local to the service" instead of the application. This would prevent the sharing of middleware. But maybe that's okay.

The rules specified in the Docker documentation would continue to apply, though a bit different. If the user specifies no router labels, then one will be auto-generated, but named for the service specifically. Same with service.

Second, I would like to get in explicit support of some sort of multiple ServiceEndpoints specified in relation to services. In this, I'm considering adding a new magic value to each service, something like: traefik.http.service.service0.endpoint which would be set to the name of the ServiceEndpoint. Like traefik.servicefabric.endpoint, but now declarable multiple times for a single service.

Failure to explicitly define the endpoint would result in the service using the first known endpoint with a HTTP protocol, or with HTTP UriScheme. For TCP the first tcp protocol endpoint. And the same for UDP.

Third, I am considering changing the name of the Extension block to Traefik2 in order to allow labels for both Traefik v1 and Traefik v2 to exist simultaneously. I would need this to effect a smooth rolling upgrade between versions. This one concerns me, as it is somewhat unlike anything done for any other provider.

When development on a Go version of this happens, I think these are still important questions to think through.

[venkimakthal]

Please prioritize this feature, this is stooping us to upgrade to 2.0

[abarger-bss]

@geraldcroes According to this blog post, we are nearing the end of support for Traefik 1.x. Can we expect an announcement on Service Fabric integration with Traefik 2.x in time for interested users to migrate? Or should Service Fabric customers begin planning to build custom integrations using the File or HTTP providers?

[ldez]

Hello, with the new version (v2.5.0) of Traefik, we introduced a new kind of plugin (provider).
There is a plugin for Service Fabric here: https://github.com/dariopb/traefikServiceFabricPlugin

[abarger-bss]

Thanks for letting us know, I'm very happy to see this. We'll start evaluating the new plugin for a migration path. At first glance, many elements seem similar to the 1.x integration.

[nokjuh]

The Service Fabric plugin for Traefik 2.x is still in development (version 0.2.2). Is there any information about when it will be published?

[nokjuh]

Has there been progress with the Service Fabric plugin for Traefik 2.x? There hasn't been a new development release since September, and only a few commits at least in the plugin main branch.

The plugin version 0.2.2 is missing features which are critical for us, such as sticky session support.

[Mahons]

hi @nokjuh, I haven't tried it myself yet, but I had spotted that stickiness is defined within the code but isn't documented.

case "traefik.http.loadbalancer.stickiness":
	setLoadbalancerSticky(s.LoadBalancer, val)

func setLoadbalancerSticky(lb *dynamic.ServersLoadBalancer, val string) error {
	v, err := strconv.ParseBool(val)
	if err != nil {
		v = false
	}

	if v {
		lb.Sticky = &dynamic.Sticky{}
	}
	return nil
}

I also need stickiness for some legacy APIs; I'll revert here when I get a chance to test it. Could you do the same?

[Mahons]

@abarger-bss I spoke with Traefik Labs last Friday and they are selling an option to extend support of 1.7 for one year if that's an option for you.

[nokjuh]

@Mahons Thanks for the suggestion, but I could not get the stickiness to work.

I added label true to the ServiceManifest.xml like I did with pass host header option (true). The cookie isn't set when I browse to the service, and the stickiness option isn't shown in the Traefik dashboard (but e.g. pass host header option is shown as enabled).

In any case even if the basic stickiness would work, there are still some related options such as samesite=none for the stickiness cookie which we would need, and which are supported in 1.7 plugin.

[Mahons]

@Mahons Thanks for the suggestion, but I could not get the stickiness to work.

I added label true to the ServiceManifest.xml like I did with pass host header option (true). The cookie isn't set when I browse to the service, and the stickiness option isn't shown in the Traefik dashboard (but e.g. pass host header option is shown as enabled).

In any case even if the basic stickiness would work, there are still some related options such as samesite=none for the stickiness cookie which we would need, and which are supported in 1.7 plugin.

@nokjuh, good to know it's not working as I mentioned, it's something I also need but haven't got around to testing yet. I've already pushed some changes relating to custom entry points and I have an open PR relating to the assigned load balancers. I may take a look at stickiness over the coming days time permitting.

[nokjuh]

@Mahons Thanks, it would be great if you could take a look at this.

When I set the label, in the Traefik debug log it shows:
{"loadBalancer":{"sticky":{}, [...],"passHostHeader":true}

Based on http_config.go the loadBalancer setting may be expecting more JSON content, such as { "sticky": { "cookie": {} } } or { "sticky": { "cookie": { "sameSite": "none", "secure": true } } }. This would match what I would expect based on https://doc.traefik.io/traefik/routing/services/#sticky-sessions .

But function setLoadbalancerSticky expects the input from the label to be just a boolean, and will throw away any other values.

[ddtmachado]

👋 FYI the SF provider plugin moved officially to a Microsoft repo and is now available as a pre-release beta at https://github.com/microsoft/service-fabric-traefik/releases/tag/v0.1.0-beta

[nokjuh]

@ddtmachado It seems that is a separate repository for a different thing.

If I understand correctly, https://github.com/dariopb/traefikServiceFabricPlugin is for the Service Fabric plugin which can be enabled as part of Traefik 2.x.

https://github.com/microsoft/service-fabric-traefik looks like it's a template for a Service Fabric application which can be deployed on a Service Fabric cluster, so that you can get Traefik 2.x running on the cluster.

[nokjuh]

Also looks like the 0.2.2 plugin version does not work at all correctly if there is more than one application on the Service Fabric cluster. All applications get the same "servers" list for routing in Traefik, this seems to be whatever application was last updated.

So if I have e.g. 3 different applications, all routing randomly ends up in just one of them, with 2 of them never getting any traffic. Each application has its own routing rules and its own backend servers (in this case container instances), but seems that the plugin ignores all but one of them.

I suspect the issue is in serviceFabricPlugin.go: generateConfiguration, but I'm not familiar enough with Go to tell what could be wrong.

[Mahons]

Also looks like the 0.2.2 plugin version does not work at all correctly if there is more than one application on the Service Fabric cluster. All applications get the same "servers" list for routing in Traefik, this seems to be whatever application was last updated.

So if I have e.g. 3 different applications, all routing randomly ends up in just one of them, with 2 of them never getting any traffic. Each application has its own routing rules and its own backend servers (in this case container instances), but seems that the plugin ignores all but one of them.

I suspect the issue is in serviceFabricPlugin.go: generateConfiguration, but I'm not familiar enough with Go to tell what could be wrong.

Hi @nokjuh, I spotted that the other day and have already fixed it with a PR waiting for review.

[Mahons]

Also not sure you're if you're aware but you can run the plugin locally and not have to go through the pilot website, therefore you are not stuck to using the 0.2.2 version.

[experimental.localPlugins.ServiceFabric]
    moduleName = "github.com/dariopb/traefikServiceFabricPlugin"

[providers]
   [providers.plugin]
      [providers.plugin.ServiceFabric]
        clusterManagementUrl = "https://localhost:19080"
        pollInterval = "5s
        .
        .

You just need to copy the repository into a local folder '/plugins-local/src/github.com/dariopb/traefikServiceFabricPlugin' in the same folder as the traefik executable

[Mahons]

@nokjuh I got the sticky sessions working by initiating the Cookie struct within the Sticky struct in the labels.go file for now. It's worth noting that the dashboard doesn't show that sticky sessions are turned on; however, I can see in Postman that the cookie is created and more importantly, NTLM authentication is working when I have two instances of a service running. I will look to tidy up the code over the coming days and push a PR.

[ddtmachado]

@ddtmachado It seems that is a separate repository for a different thing.

If I understand correctly, https://github.com/dariopb/traefikServiceFabricPlugin is for the Service Fabric plugin which can be enabled as part of Traefik 2.x.

https://github.com/microsoft/service-fabric-traefik looks like it's a template for a Service Fabric application which can be deployed on a Service Fabric cluster, so that you can get Traefik 2.x running on the cluster.

@nokjuh You're right, the repo I linked contains templates for managed service fabric clusters, which will deploy Traefik with the plugin while the code for the plugin itself is hosted on the other repo. Thanks for pointing that out.

[nokjuh]

@Mahons Thanks, I was able to try the local plugin and got it working. The fork you have for the fix for load balancer duplicate servers worked for me, the servers were now defined correctly in Traefik.

I also got the sticky sessions working by adding lb.Sticky.Cookie = &dynamic.Cookie{} to setLoadbalancerSticky method, I can see the cookie with browser tools and the functionality requiring sticky sessions works. Traefik dashboard also shows "Sticky: Cookie" for me in Service Details.

Still, I think the main issue is whether someone such as dariopb (can't apparently reference them to notify) is actively developing the plugin to reach feature parity with 1.7 plugin and to release a fully supported plugin, and with what schedule.

Even if the currently discussed fixes are merged, there are still further missing features in the plugin such as secure, httpOnly, and sameSite settings for sticky sessions. The new plugin also does not at this point read the service properties from Service Fabric, which are needed to be able to update the routing rules without updating the application itself.

More issues may appear with further investigation but I don't want to do duplicate work in case someone is actively working on developing feature parity already, and I probably won't be able to find all issues with the time I have available.

[Mahons]

@Mahons Thanks, I was able to try the local plugin and got it working. The fork you have for the fix for load balancer duplicate servers worked for me, the servers were now defined correctly in Traefik.

I also got the sticky sessions working by adding lb.Sticky.Cookie = &dynamic.Cookie{} to setLoadbalancerSticky method, I can see the cookie with browser tools and the functionality requiring sticky sessions works. Traefik dashboard also shows "Sticky: Cookie" for me in Service Details.

Still, I think the main issue is whether someone such as dariopb (can't apparently reference them to notify) is actively developing the plugin to reach feature parity with 1.7 plugin and to release a fully supported plugin, and with what schedule.

Even if the currently discussed fixes are merged, there are still further missing features in the plugin such as secure, httpOnly, and sameSite settings for sticky sessions. The new plugin also does not at this point read the service properties from Service Fabric, which are needed to be able to update the routing rules without updating the application itself.

More issues may appear with further investigation but I don't want to do duplicate work in case someone is actively working on developing feature parity already, and I probably won't be able to find all issues with the time I have available.

@nokjuh We're in the same boat as yourself!

I have an open ticket with Microsoft Support on this and they were the ones who first pointed me to Dario's repo; I also spoke to Traefik late last week around commercial support which, in fairness they are offering to extend v1.7 for 2022. They also confirmed that they are in discussions with Microsoft around the SF provider, a GA in Q1 was mentioned. I take that date with a pinch of salt though!

Ps. I'll have to check my dashboard again (I definitely didn't spot it last night!)

[nokjuh]

Seems that Microsoft has for some reason abandoned the plugin development at https://github.com/dariopb/traefikServiceFabricPlugin . This is based on discussions with Traefik, although I haven't been able to get the full picture.

Instead they are apparently using https://github.com/microsoft/service-fabric-traefik as the main repository. It had 1.0.0 release a few days ago. Although the new repository appears to be mostly just a template for Service Fabric application, which can be used for running Traefik.

This is helpful in getting started but is not the actual logic for Traefik Service Fabric integration. That logic is in https://github.com/dariopb/serviceFabricDiscoveryService which is compiled as "server.exe" in the service-fabric-traefik release. It uses Service Fabric API to read the current SF application info and creates Traefik file provider configuration based on that.

So it seems that the main change is that instead of a Traefik plugin, the new approach is to have a separate application which writes the routing rules as Traefik file provider dynamic configuration file. So far I haven't been able to find any advantages in the new approach compared to the plugin approach.

I haven't yet had time to try the new approach but it looks like it has some blocker bugs at the moment, such as crashes.

[ddtmachado]

@nokjuh we recently had a sync meeting with Microsoft on the progress and future of the new service fabric plugin.

They confirmed there is a new team taking ownership of the plugin development and that it will be done entirely on this new repository, as you noted at: https://github.com/microsoft/service-fabric-traefik

I see you already opened a few issues there and that's great to give MS visibility and feedback on what's missing and what can be improved.

I'm closing this issue as the provider is being implemented by a partner in its own repo now. And I encourage everyone following this to go there if you find any bugs, missing features or just want to propose improvements.