Can (and should) Traefik be used in "file" mode in a Service Fabric cluster?

I'm investigating using Traefik as a reverse proxy within a Service Fabric cluster running Dockerized microservices. The official way of running Traefik within Service Fabric is to use the Service Fabric provider. Running Traefik within a Docker container is not recommended according to the Github readme because you can't reach the Service Fabric API through localhost:19080, but instead have to reach it through its public IP. This requires you to install SSL certs to securely talk to the API, which is a bit of a hassle.

I'm curious if there's any advantage using the Traefix Service Fabric provider (which requires complex setup) rather than just running Traefix in a container running with the File provider. Provided your services had ServiceDnsName attributes in the ApplicationManifest, thus allowing Service Fabric DNS to find them, it seems like a much simpler approach. The Traefik configuration would look something like:

[frontends]
  [frontends.api]
  backend = "api"
  passHostHeader = true
  [frontends.api.routes.forwarder]
  rule = "PathPrefixStrip: /api/"

  [frontends.someservice]
  backend = "someservice"
  passHostHeader = true
  [frontends.someservice.routes.forwarder]
  rule = "PathPrefixStrip: /SomeService/"


[backends]
  [backends.api]
    [backends.api.servers.endpoint]
    url = "http://Api:11080"
  [backends.someservice]
    [backends.someservice.servers.endpoint]
    url = "http://SomeService:12080"

You'd map port 80 to your Traefix service, which would then dispatch the HTTP call to the appropriate internal service based on the URL prefix.

Advantages:

No need to talk to the Service Fabric API, which is somewhat hacky to do from within a container.
Possibly more secure; Everything is internal, no need to worry about installing certificates

Disadvantages:

Your service routing is now tied to a TOML file within a Docker container rather than integrated into service and application manifest files. No way to modify this without redeploying that container.
I don't believe this would work unless all services were running in a Container (Though I believe if you enabled the reserve proxy, you can resolve the service by name using http://localhost:19081/AppName/ServiceName instead)

To me, it seems like a cleaner approach provided you're not changing and adding services all the time. Usually, the stuff stays fairly static though.

Are there any gotchas that I'm not considering, or any strong argument against doing this?

Solution

I will add my two cents to your considerations:

Is a preference between Dynamic and Static configuration.

The benefit is that it will reload with all the new configurations every time a service comes up with Traefik configuration. Today you say "it won't change", but in a few months, weeks or perhaps days, you might face a new requirement and you have to update the file, if the system evolves quickly, like on Microservices solution, you soon will face a hard work of updating this file by hand.

If you are sure it will hardly change, don't be limited by the Service Fabric Configuration or File, Traefik can get the configuration from REST , ETCD, DynamoDB and many other configuration providers to load the rules.

For the File approach, you can create the file in an Azure FileShare and mount as a volume in the container, so you don't need to rebuild the container to take effect.

Then you can just update the file and:

Restart the container to reload the file, or.
An even better approach is using the file.watch setting you don't need to restart the container and it will watch for any changes in the file.