в чем основное отличие поэтапной и производственной среды Azure, специально для задачи запуска?

#azure #azure-sql-database #azure-storage

#azure #azure-sql-database #azure-хранилище

Вопрос:

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

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

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

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

Комментарии:

1. С вашим кодом ничего не происходит. Это разные развертывания на разных виртуальных машинах. Если вы видите неправильные настройки в VIP swap, это еще одна проблема, совершенно не связанная с самим VIP swap. Подробнее см. Мой более подробный ответ.

2. Да, отлично, оба ответа действительно полезны.

Ответ №1:

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

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

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

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

Ответ №2:

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

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

Комментарии:

1. 1, хорошо сказано, но бесшовно немного сильно; поскольку часто какая-то DNS-магия не срабатывает, и всем моим предыдущим посетителям приходится ждать час, прежде чем сайт снова начнет работать. : o

2. Эй, кажется, ваш ответ верен, и я предполагаю то же самое.

3. Но я только что обнаружил, что мои настройки конфигурации были изменены, поэтому позвольте мне протестировать с небольшим ответом b4 отметьте этот ответ.

4. @Gleno — смотрите мой ответ — DNS не изменился.