Стратегия взаимодействия между несколькими развертываемыми средами в Azure

Question

Я ищу наилучшую практику взаимодействия между несколькими ролями в Azure в нескольких средах развертывания.

Мы имеем следующие среды развертывания

1. Разработчики локального развертывание
2. Доли развертывания разработки в лазурном развертывании
3. QA в лазури
4. развертывание Предварительного производства
5. развертывание производства
6. и т.д. .

Во всех этих развертываниях у нас есть несколько веб-ролей, а также рабочие роли.

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

Если, например, я использую azure Queue или Service bus, как я могу однозначно идентифицировать каждое развертывание, чтобы сообщения не переходили из одной среды в другую?

Спасибо, Ноама

Answer 1

Скорее всего, вы хотите посмотреть в глобальное статическое переменном называется RoleEnvironment.DeploymentId доступного из Azure Service исполнения.

Эта переменная будет уникальной для каждой развернутой службы Azure (обратите внимание, а не на роль).

Предостережение:

1), если вам нужен уникальный номер на каждую роль, добавьте RoleName этой переменный: RoleEnvironment.CurrentRoleInstance.Role.Name

2) развертывание в локальном режиме Dev следует разные и не возвращать Guid для идентификатора развертывания. Возможно, потребуется реализовать для них стратегию генерации руководства.

Answer 2

Лучший вариант, который мы используем через наш Dev, Test & Prod environment - это просто создать Dev, Test & Продольные контейнеры для хранения и служебные шины. Мы используем определения конфигурации службы для каждой среды сборки, чтобы контролировать, какой контейнер/шина используется. Это особенно важно, если вы используете диагностику, вы действительно должны использовать отдельный контейнер для диагностики.

Answer 3

Возможно, вам захочется сгруппировать набор сервисов в единую облачную службу (или, возможно, VNet), а затем использовать только WCF (net.tcp).

Пример здесь: http://tk.azurewebsites.net/2013/03/06/burst-up-to-the-cloud-with-a-preconfigured-ip-address-and-vpn/

Игнорируйте «VPN» часть картины - что связано с какой-то конкретной вещи я упоминанием в статье.