可以（也应该）在服务矩阵群集中以“文件​​”模式使用Traefik吗？

Question

我正在研究使用Traefik作为运行Docker化微服务的Service Fabric集群中的反向代理。在Service Fabric中运行Traefik的official方法是使用Service Fabric提供程序。不建议according to the Github readme在Docker容器中运行Traefik，因为您无法通过localhost：19080访问Service Fabric API，而必须通过其公共IP来访问它。这要求您安装SSL证书以安全地与API通讯，这有点麻烦。

我很好奇，使用Traefix Service Fabric提供程序（需要复杂的设置）是否有任何优势，而不仅仅是在与File提供程序一起运行的容器中运行Traefix。如果您的服务在ApplicationManifest中具有ServiceDnsName个属性，从而使Service Fabric DNS可以找到它们，这似乎是一种很多的简单方法。 Traefik配置如下所示：

[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"

您将端口80映射到Traefix服务，然后该服务将根据URL前缀将HTTP调用分派到适当的内部服务。

优势：

• 无需与Service Fabric API进行对话，这在容器内很难实现。
• 可能更安全；一切都是内部的，无需担心安装证书

缺点：

• 您的服务路由现已绑定到Docker容器内的TOML文件，而不是集成到服务和应用程序清单文件中。如果不重新部署该容器，则无法修改它。
• 除非所有服务都在容器中运行，否则我认为这不会起作用（尽管我相信如果启用了保留代理，则可以使用http://localhost:19081/AppName/ServiceName通过名称解析服务）

对我来说，如果您不一直在更改和添加服务，那么这似乎是一种更清洁的方法。通常，这些东西通常保持静态。

是否有我没有考虑的陷阱，或者是否有反对这样做的强烈论点？

Answer 1

我将把两美分添加到您的考虑中

是动态和静态配置之间的首选项。

好处是，每当服务与Traefik配置一起出现时，它将重新加载所有新配置。今天，您说“它不会改变”，但是在几个月，几周甚至几天后，您可能会面临新的要求，并且必须更新文件，如果系统快速发展（例如在微服务解决方案上），您很快就会面对手动更新此文件的艰苦工作。

如果您确定它几乎不会改变，不受服务结构配置或文件的限制，那么Traefik可以从REST，ETCD，DynamoDB和{ {3}}加载规则。

对于文件方法，您可以在Azure FileShare中创建文件并将其作为卷安装在容器中，因此无需重建容器即可生效。

然后，您只需更新文件即可：

• 重新启动容器以重新加载文件，或者。
• 一种更好的方法是使用file.watch设置，您无需重新启动容器，它将监视文件中的任何更改。