Azure endpoints - различные развертывания

Question

В настоящее время мы запускаем веб-роль пользовательского интерфейса и веб-роль веб-сервиса (WCF REST) ​​на Azure. Каждая роль содержит 2 экземпляра (для балансировки нагрузки и удовлетворения требований SLA). Веб-роль веб-роли и веб-службы веб-сервиса находятся в пределах одной подписки, но в разных вариантах развертывания. Мы не хотим объединять базы кода (ремонтопригодность и т. Д.). Таким образом, слой пользовательского интерфейса находится на странице xyz.cloudapp.net, а уровень веб-службы - на abc.cloudapp.net.

В настоящее время необходимо сделать веб-роль веб-службы внутренней конечной точкой, доступной только для слоя пользовательского интерфейса. Литература о настройке внутренних конечных точек и доступе к ней из другого развертывания не очень ясна.

Я предполагаю, что две разные роли должны быть частью одного развертывания, чтобы это работало. Можно ли это сделать, не затрагивая развертывание? Любые указатели в правильном направлении были бы весьма полезны.

Answer 1

Внутренние конечные точки доступны только в рамках одного развертывания и не маршрутизируются через балансировщик нагрузки (поэтому, если у вас есть два экземпляра ваших услуг wcf, доступных на внутренней конечной точке, вам необходимо распределить вызовы между экземплярами). Это, конечно, потребовало бы, чтобы вы включили как свою веб-роль, так и веб-роль wcf в одно и то же развертывание.

Возможно, вы захотите рассмотреть служебную шину для безопасного доступа к вашим услугам wcf из ваших экземпляров веб-роли. Или ... выставлять службы wcf через конечную точку ввода, но защищать службу.

Answer 2

Рассматривали ли вы использование ACS (Access Control Services) для ограничения доступа using claims-based authentication к вашей конечной точке WCF?

Существует множество схем защиты, которые вы могли бы предоставить via WCF bindings.

Internal Endpoints может взаимодействовать только с разными ролями в одном и том же развертывании. Если у вас есть 2 отдельных развертывания (abc.cloudapp.net и xyz.cloudapp.net, внутренние конечные точки не помогут вам).

Answer 3

Там же подход, который я хотел бы назвать виртуальную DMZ, что sould удовлетворения ваших потребностей: http://brentdacodemonkey.wordpress.com/?s=virtual+dmz

Он использует привязки ACS и WCF, чтобы создать контроль доступа к входным конечным точкам (которые затем балансировка нагрузки). Конечно, если вы не хотите что-то надежное, вы можете пойти только с обычным старым сценарием WCF.

Это говорит о том, что Давид делает отличную оценку. Внутренние конечные точки доступны только с одной развернутой службой. Это связано с тем, что эта служба представляет собой границу изоляции (думает виртуальная ветвь lan), и единственные входные конечные точки могут быть адресованы из-за пределов этой границы.