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

Question

Я исследую использование Traefik в качестве обратного прокси в кластере Service Fabric, работающем с Dockerized microservices. Официальный способ запуска 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)

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

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

Answer 1

Я добавлю два ваших цента к вашим соображениям:

Предпочтение от Динамическая до Статическая конфигурация.

Преимущество состоит в том, что он будет перезагружаться со всеми новыми конфигурациями каждый раз, когда служба запускается с конфигурацией Traefik. Сегодня вы говорите «это не изменится», но через несколько месяцев, недель или, возможно, дней, вы можете столкнуться с новым требованием, и вам придется обновить файл, если система развивается быстро, как в случае решения Microservices, вы скоро будете предстоит тяжелая работа по обновлению этого файла вручную.

Если вы уверены, что он вряд ли изменится, не ограничивайтесь конфигурацией Service File или файлом, Traefik может получить конфигурацию из REST , ETCD , DynamoDB и многие другие поставщики конфигурации для загрузки правил.

Для файлового подхода вы можете создать файл в Azure FileShare и смонтировать его как том в контейнере, поэтому вам не нужно перестраивать контейнер для вступления в силу.

Тогда вы можете просто обновить файл и:

• Перезапустите контейнер, чтобы перезагрузить файл, или.
• Еще лучшим подходом является использование параметра file.watch, при котором вам не нужно перезапускать контейнер, и он будет следить за любыми изменениями в файле.