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

Posted 2023-03-27

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

【英文标题】：Can (and should) Traefik be used in "file" mode in a Service Fabric cluster?Traefik 是否可以（并且应该）在 Service Fabric 群集中以“文件​​”模式使用？

【发布时间】：2019-04-05 06:01:44

【问题描述】：

我正在研究在运行 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 按名称解析服务）

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

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

【问题讨论】：

据我所知 - 这应该可以正常工作。您打算在 Azure 中还是在本地托管它？

@OlegKarasik - 这是托管在 Azure 上的。我有一个原型设置，它似乎也可以正常工作。

【参考方案1】：

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

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

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

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

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

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

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

【讨论】：

是的，关于将文件存储在某种易于访问且不属于 Docker 映像的共享存储中的好建议。使用其他提供商也可能是一个不错的选择。我相信我可以从这个设置开始，如果我们发现我们正在编辑服务配置太多并且需要一种简单的方法来完成它，然后再进行更改。谢谢！

除了 etcd 和 dynamodb 之外，文件是迄今为止最方便的手动编辑。 Rest 通常用于集成目的，etcd 通常用于 HA。如果您不需要这些，则没有理由选择其他文件。