Traefik 是否可以（并且应该）在 Service Fabric 群集中以“文件​​”模式使用？

Question

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

我很好奇使用 Traefix Service Fabric 提供程序（需要复杂的设置）而不是仅在使用文件提供程序运行的容器中运行 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 对话，这在容器内有点hacky。
• 可能更安全；一切都是内部的，无需担心安装证书

缺点：

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

对我来说，如果您不一直更改和添加服务，这似乎是一种更简洁的方法。但通常情况下，这些东西保持相当静态。

是否有任何我没有考虑的陷阱，或者有什么强烈反对这样做的理由？

Answer 1

我会在您的考虑中添加我的两分钱：

是动态和静态配置之间的偏好。

好处是每次服务提供 Traefik 配置时，它都会重新加载所有新配置。今天你说“它不会改变”，但在几个月、几周或几天后，你可能会面临一个新的需求，你必须更新文件，如果系统快速发展，比如微服务解决方案，你很快就会手动更新此文件是一项艰巨的工作。

如果你确定它几乎不会改变，不要被Service Fabric配置或文件限制，Traefik可以从REST、ETCD、DynamoDB和many other configuration providers获取配置来加载规则.

对于文件方式，您可以在 Azure FileShare 中创建文件并作为卷挂载到容器中，因此无需重新构建容器即可生效。

然后你可以更新文件并且：

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