Допустим, у меня есть кластер Service Fabric с 5 узлами.На одном из этих узлов я запускаю службу под названием Cache:
<Service Name="Cache" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="CacheType" InstanceCount="1">
<SingletonPartition />
</StatelessService>
</Service>
CacheType - это некоторый контейнер Docker, который предоставляет порт 8080 и обеспечивает некоторую внутреннюю службу для моего приложения.В этой ситуации мне просто нужен один из них, поэтому я устанавливаю InstanceCount равным 1. При развертывании моего приложения в кластере App Fabric выберет один узел для установки «Кэша».Мой вопрос заключается в том, как мое приложение может узнать, что это за узел, чтобы он мог к нему подключиться?
Я обнаружил, что на узле <ContainerHostPolicies> есть атрибут Hostname, поэтому я могу сделать что-то вроде этого:
<ContainerHostPolicies CodePackageRef="Code" Hostname="Cache">
Теперь из контейнера Docker я могу PING Cache и подключиться к контейнеру, на котором работает мой сервис.Это замечательно, однако только работает, если я нахожусь на том же узле.Если я на узле 1 и моя служба кэширования работает на узле 3, это не сработает.
Здесь есть пример здесь , который представляет собой приложение для голосования, которое вроде какЯ ищу.Они создают отдельный пул балансировки нагрузки, который отображает некоторый общедоступный IP-адрес в бэкэнд-пул служб голосования.Затем приложение может просто подключиться к этому общему IP-адресу.Однако в моем случае мне нужно, чтобы это было полностью внутренним делом, когда моя служба кэширования недоступна где-либо за пределами виртуальной сети кластера.Я также предпочел бы избежать накладных расходов на балансировщик нагрузки.
Другая идея - использовать какое-то ограничение размещения, чтобы сказать: «Эй, я только хочу, чтобы эта служба была установлена на узле с этим DNS-именем» или что-то в этом роде,но это кажется довольно глупым.Есть ли рекомендуемый подход к этому?