В чем главное отличие лазурной разметки и производственной среды, особенно для задачи запуска?

Question

Может ли кто-нибудь сказать мне, что происходит внутри, когда мы перешли с постановки на производственную среду?

причина спросить это, Когда я тестирую в своей рабочей среде, все работает хорошо. Но когда я делаю изменения в файле web.config и в файле конфигурации моего exe-файла, который выполняется в фоновом режиме (задача запуска) при постановке, а затем переключается на производство, он не работает должным образом.

Пример: У меня есть настройки почты, где в постановке это что-то вроде Mystaging.cloudapp.net который я изменяю на MyLive.cloudapp.net, а затем переключаюсь, когда получаю почту, отображается mystaging.cloudapp.net

В общем, я хочу знать, что происходит в web.config и каталоге Bin ?????

Answer 1

Среды идентичны, за исключением одной вещи: у них разные VIP-адреса (IP-адрес, выставленный внешне на loadbalancer). Когда вы меняете VIP-своп, балансировщик нагрузки перепрограммируется для переключения VIP между промежуточным и рабочим развертыванием - вот и все. Нет никаких изменений в DNS.

Есть еще несколько нюансов. Например, существующие соединения не должны быть разорваны. Таким образом, если у вас длительное открытое соединение, оно будет продолжаться во время VIP-свопинга. Это может привести к случаям, когда a.) Соединение попадает в «более старую» среду после замены и b.) Это также может в некоторых случаях привести к тому, что сама операция VIP-свопинга будет продолжаться некоторое время (обычно это довольно быстро).

Первоначальное намерение двух сред состояло в том, чтобы упростить обновление развертываний. Вы могли бы ускорить другое обновленное развертывание в стадии подготовки, провести некоторое тестирование и затем переключиться. Пользователи по большей части никогда не заметят ничего. Однако есть несколько причин, по которым вы бы не использовали этот шаблон:

1. Вы не можете использовать этот шаблон, если вы изменяете внешние конечные точки (например, добавляете порт 443 в стадии подготовки). В этом случае вы должны удалить / новое развертывание - помните, что балансировщик нагрузки просто перепрограммируется, поэтому конечные точки должны совпадать. Это ограничение может исчезнуть в будущем, кто знает.
2. Если у вас давно работают службы с отслеживанием состояния. VIP-свопы, очевидно, перенесут все развертывания в производство. Если у вас была часовая работа в рабочей роли, которая должна была каким-то образом взаимодействовать с клиентским интерфейсом, вы можете столкнуться с проблемами здесь.
3. Ограничения версий. Представьте себе, если вы добавляете другую среду в стадию, которая работает с теми же / подобными данными, что и производственная. Теперь, когда вы готовитесь к переключению, вы подключаете свои соединительные строки, чтобы среды были готовы к работе. Когда вы это сделаете, у вас будет два разных развертывания, которые начнут работать с одними и теми же данными. Например, это становится очень очевидным при использовании одной и той же очереди. Рабочие роли при подготовке начинают обрабатывать производственные сообщения до того, как интерфейсные изменения изменяются для обновления формата сообщения или какой-либо другой несовместимости. Вы получаете проблему управления версиями, так как более новое развертывание начинает работать со старыми данными и ошибками и тому подобным. Это не является непреодолимым, просто надо подумать.
4. Если у вас (очень) большие развертывания. Представьте, если у вас есть несколько сотен экземпляров. В этом случае сложно сделать VIP-своп, потому что а.) Требуется много времени, чтобы раскрутить такое количество этапов, б), что обходится дорого, потому что вы запускаете в 2 раза больше экземпляров, и в) вы можете не быть в состоянии сделать это из-за ограничений квоты подписки. Ваша квота должна быть как минимум в 2 раза больше, чем ваши текущие экземпляры. Когда вы смотрите на тысячи случаев, это нецелесообразно. Однако для простых смертных квота может вас получить.

Answer 2

При переключении происходит только одно - изменяется URL-адрес, по которому развертывание принимает входящие HTTP-запросы. Ничего другого - никаких перезагрузок, никаких изменений конфигурации, ничего. Это просто изменение маршрута запроса.

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