Можно ли (и нужно) использовать Traefik в "файловом" режиме в кластере Service Fabric?

Mike Christensen спросил: 07 октября 2018 в 11:48 в: azure-service-fabric

Я исследую использование Traefik в качестве обратного прокси-сервера в кластере Service Fabric, на котором запущены микросервисы Dockerized. Официальный способ запуска Traefik в Service Fabric - использование поставщика Service Fabric. Запуск Traefik в контейнере Docker не рекомендуется в соответствии с readme Github, потому что вы не можете получить доступ к API Service Fabric через localhost: 19080, но вместо этого вам нужно получить доступ к нему через его общедоступный IP-адрес. Это требует, чтобы вы установили SSL-сертификаты для безопасного общения с API, что немного хлопотно.

Мне любопытно, есть ли какое-либо преимущество в использовании провайдера Traefix Service Fabric (который требует сложной настройки). чем просто запуск Traefix в контейнере с провайдером файлов. Если ваши сервисы имеют атрибуты ServiceDnsName в ApplicationManifest, что позволяет DNS Service Service их находить, это выглядит как намного более простой подход. Конфигурация 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, которая затем отправит HTTP-вызов соответствующей внутренней службе на основе префикса URL. .

Преимущества:

  • Нет необходимости общаться с API Service Fabric, что несколько хакерски , чтобы делать это из контейнера.
  • Возможно, более безопасный; Все внутреннее, не нужно беспокоиться об установке сертификатов

Недостатки:

  • Маршрутизация вашего сервиса теперь связана с файлом TOML внутри контейнера Docker, а не с интегрированы в файлы манифеста службы и приложения. Нет способа изменить это без повторного развертывания этого контейнера.
  • Я не верю, что это сработает, если не все службы будут работать в контейнере (хотя я полагаю, что если вы включили резервный прокси-сервер, вы можете разрешить службу с помощью имя, используя вместо этого http://localhost:19081/AppName/ServiceName)

Мне кажется, что это более чистый подход, если вы не меняете и не добавляете сервисы все время. Обычно, материал остается довольно статичным.

Есть ли какие-либо уловки , которые я не рассматриваю, или какие-либо веские аргументы против этого?

0 ответов