Настройка промежуточных сред в Службе приложений Azure

  • Статья

Когда вы развертываете свое веб-приложение, веб-приложение в Linux, мобильную серверную часть или приложение API в Службе приложений Azure, вы можете использовать отдельный слот развертывания вместо производственного слота по умолчанию, когда вы работаете в Стандартный, Премиум или Изолированный уровень плана службы приложений. Слоты развертывания представляют собой работающие приложения с собственными именами хостов. Элементы конфигурации и содержимое приложений можно переключать между двумя слотами развертывания, включая рабочий слот.

Развертывание приложения в непроизводном слоте имеет следующие преимущества:

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

Каждый уровень плана службы приложений поддерживает разное количество слотов развертывания. Дополнительная плата за использование слотов развертывания не взимается. Чтобы узнать, сколько слотов поддерживает уровень вашего приложения, см. Ограничения службы приложений.

Чтобы масштабировать приложение на другой уровень, убедитесь, что целевой уровень поддерживает количество слотов, которые ваше приложение уже использует. К примеру, если в вашем приложении более пяти слотов, вы не можете масштабировать его до уровня Стандартный, поскольку Стандартный уровень поддерживает только пять слотов развертывания.

В этом видео показано, как настроить промежуточные среды в службе приложение Azure.

Действия в видео также описаны в следующих разделах.

Необходимые компоненты

Сведения о разрешениях, необходимых для выполнения операции слота, см. в разделе " Операции поставщика ресурсов" (например, поиск слота).

Добавление слота

Чтобы включить несколько слотов развертывания, приложение должно быть ценовой категории Стандартный, Премиум или Изолированный.

  1. На порталеAzure перейдите на страницу вашего приложения.

  2. На левой панели выберите Слоты развертывания>Добавить слот.

    Примечание.

    Если приложение еще не в уровне "Стандартный", "Премиум" или "Изолированный ", выберите "Обновить " и перейдите на вкладку "Масштаб " приложения, прежде чем продолжить.

  3. В диалоговом окне Добавить слот присвойте слоту имя и выберите, следует ли клонировать конфигурацию приложения из другого слота развертывания. Чтобы продолжить, выберите Добавить.

    A screenshot that shows how to configure a new deployment slot called 'staging' in the portal.

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

    Примечание.

    В настоящее время частная конечная точка не клонируется между слотами.

  4. После добавления слота выберите Закрыть, чтобы закрыть диалоговое окно. Новый слот теперь отображается на странице Слоты развертывания. По умолчанию для нового слота % трафика установлено значение 0, при этом весь клиентский трафик направляется в производственный слот.

  5. Выберите новый слот развертывания, чтобы открыть страницу ресурсов данного слота.

    A screenshot that shows how to open deployment slot's management page in the portal.

    Страница управления для промежуточного слота ничем не отличается от страницы для любого приложения Службы приложений. Здесь вы можете изменить конфигурацию слота. В целях напоминания, что вы просматриваете слот развертывания, имя приложения отображается как <app-name>/<slot-name>, а тип приложения — Служба приложений (слот). Вы также можете увидеть слот как отдельное приложение в своей группе ресурсов с теми же обозначениями.

  6. Выберите URL-адрес приложения на странице ресурсов слота. Слот развертывания имеет собственное имя хоста и также является действующим приложением. Чтобы ограничить общий доступ к слоту развертывания, см. Ограничения IP-адреса Службы приложений Azure.

Новый слот развертывания не имеет содержимого, даже если вы клонировали параметры из другого слота. Например, вы можете опубликовать в данном слоте с помощью Git. Вы можете выполнять развертывание в слот из другой ветви репозитория или даже из другого репозитория. Получение профиля публикации из службы приложение Azure может предоставить необходимые сведения для развертывания в слоте. Профиль можно импортировать в Visual Studio для развертывания содержимого в слоте.

URL-адрес слота имеет формат http://sitename-slotname.azurewebsites.net. Чтобы сохранить длину URL-адреса в пределах необходимых ограничений DNS, имя сайта будет усечено на 40 символов, а объединенное имя сайта и имя слота должно быть меньше 59 символов.

Что происходит во время обмена

Шаги операции обмена

При переключении двух слотов (обычно из промежуточного слота в качестве источника в рабочий слот в качестве целевого), Служба приложений выполняет следующие действия, чтобы обеспечить время простоя целевого слота:

  1. Примените следующие настройки из целевого слота (например, производственного слота) ко всем экземплярам исходного слота:

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

  2. Подождите, пока каждый экземпляр в исходном слоте завершит перезапуск. Если какой-либо экземпляр не перезапускается, операция подкачки отменяет все изменения в исходном слоте и останавливает операцию.

  3. Если включен локальный кэш, инициируйте инициализацию локального кэша, отправив HTTP-запрос к корню приложения ("/") для каждого экземпляра исходного слота. Подождите, пока каждый экземпляр не вернет какой-либо ответ HTTP. Инициализация локального кэша вызывает повторный перезапуск каждого экземпляра.

  4. Если автоматическая замена включена с настраиваемым прогревом, активируйте запуск приложения, отправив HTTP-запрос в корень приложения ("/") для каждого экземпляра исходный слот.

    Если applicationInitialization не указан, инициируйте HTTP-запрос к корню приложения исходного слота для каждого экземпляра.

    Если экземпляр возвращает какой-либо ответ HTTP, он считается прогретым.

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

  6. Теперь, когда в исходном слоте присутствует приложение предварительной замены, которое ранее находилось в целевом слоте, выполните ту же операцию, применив все настройки и перезапустив экземпляры.

В любой момент операции подкачки вся работа по инициализации переставленных приложений происходит в исходном слоте. Целевой слот остается в сети, пока исходный слот готовится и прогревается, независимо от того, где произошла замена. Чтобы заменить промежуточный слот рабочим, необходимо убедиться, что рабочий слот всегда является целевым. Таким образом, операция переключения не влияет на рабочее приложение.

Примечание.

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

Какие параметры переносятся?

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

Переносимые параметры:

  • Общие параметры, например версия платформы, 32/64-разрядная версия, веб-сокеты
  • Параметры приложения (их также можно привязать к слоту)
  • Строки подключения (их также можно привязать к слоту)
  • Сопоставления обработчиков
  • Открытые сертификаты
  • Содержимое веб-заданий
  • Гибридные подключения *
  • Конечные точки служб *
  • Сеть доставки содержимого Azure *
  • Сопоставления путей

Функции, отмеченные звездочкой (*), в дальнейшем планируется сделать непереключаемыми.

Параметры, которые не переносятся:

  • Конечные точки публикации
  • Личные доменные имена
  • Непубличные сертификаты и параметры TLS/SSL
  • Настройки масштабирования
  • Планировщики веб-заданий
  • Ограничения IP-адресов
  • Всегда включено
  • Параметры диагностики
  • Общий доступ к ресурсам независимо от источника (CORS)
  • Интеграция виртуальной сети
  • Управляемые удостоверения и связанные параметры
  • Параметры, заканчивающиеся суффиксом _EXTENSION_VERSION
  • Параметры, созданные Подключение службы

Примечание.

Чтобы вышеупомянутые параметры можно было переключить, добавьте параметр приложения WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS в каждый слот приложения и присвойте ему значение 0 или false. Эти параметры либо все переключаемые, либо все непереключаемые. Нельзя сделать одни параметры переключаемыми, а другие — нет. Управляемые удостоверения нельзя переключить. Эти переопределяющие параметры приложения на них не влияют.

Некоторые параметры приложения, применяемые к непереключаемым параметрам, также не переключаются. Например, поскольку параметры диагностики не переключаются, связанные параметры приложения, такие как WEBSITE_HTTPLOGGING_RETENTION_DAYS и DIAGNOSTICS_AZUREBLOBRETENTIONDAYS, также не переключаются, даже если они не отображаются как параметры слота.

Чтобы настроить параметр приложения или строку подключения для привязки к определенному слоту (без замены), перейдите на страницу Конфигурация для этого слота. Добавьте или измените параметр, после чего выберите параметр слота развертывания. При выборе этого поля проверка отображается Служба приложений, что параметр не переключен.

A screenshot that shows how to configure an app setting as a slot setting in the Azure portal.

Переключение двух слотов

Вы можете поменять местами слоты развертывания на странице приложения Слоты развертывания и на странице Обзор. Технические подробности о замене слотов см. в разделе Что происходит в процессе замены.

Важно!

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

Чтобы поменять местами слоты развертывания:

  1. Перейдите на страницу приложения Слоты развертывания и выберите Обмен.

    A screenshot that shows how to initiate a swap operation in the portal.

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

  2. Выберите исходный и целевой слоты. В качестве целевого чаще всего используется рабочий слот. Также необходимо выбрать вкладки Исходные изменения и Целевые изменения и убедиться, что изменения конфигурации будут внесены. По завершении вы можете сразу же поменять местами слоты, выбрав Обмен.

    A screenshot that shows how to configure and complete a swap in the portal.

    Чтобы увидеть, как будет работать ваш целевой слот с новыми настройками до фактического обмена, не выбирайте Обмен, а следуйте инструкциям в разделе Обмен с предварительным просмотром.

  3. По завершении закройте диалоговое окно, выбрав Закрыть.

В случае возникновения проблем см. раздел Устранение неполадок подкачки.

Переключение с предварительным просмотром (многофазное переключение)

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

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

Если вы отмените обмен, служба приложений повторно применит элементы конфигурации к исходному слоту.

Примечание.

Переключение с предварительной версией нельзя использовать, если один из слотов включает проверку подлинности сайта.

Чтобы произвести обмен с предварительным просмотром:

  1. Следуйте инструкциям в разделе Обмен слотов развертывания, но в данном случае выберите Выполнить обмен с предварительным просмотром.

    A screenshot that shows how to configure a swap with preview in the portal.

    В диалоговом окне показано, как изменяется конфигурация исходного слота на этапе 1 и как изменяется исходный и целевой слот на этапе 2.

  2. Когда вы будете готовы начать обмен, выберите Начать обмен.

    Когда этап 1 завершится, вы получите уведомление в диалоговом окне. Вы можете предварительно просмотреть результат обмена в исходном слоте, перейдя к https://<app_name>-<source-slot-name>.azurewebsites.net.

  3. Когда вы будете готовы завершить отложенный обмен, выберите Завершить обмен в разделе Действие обмена и выберите Завершить обмен.

    Чтобы отменить ожидающий переключение, выберите "Отмена переключения " вместо этого и нажмите кнопку "Отмена переключения " в нижней части экрана.

  4. По завершении закройте диалоговое окно, выбрав Закрыть.

В случае возникновения проблем см. раздел Устранение неполадок подкачки.

Откат результатов обмена

Если в целевом слоте (обычно это рабочий слот) будут обнаружены ошибки после переключения слотов, немедленно восстановите прежнее (до переключения) состояние слотов, выполнив обратное переключение.

Настройка автоматического переключения

Примечание.

Автоматическое переключение не поддерживается в веб-приложениях на Linux и Веб-приложении для контейнеров.

Функция автоматического обмена упрощает сценарии Azure DevOps, в которых вы хотите непрерывно развертывать приложение с нулевым холодным запуском и нулевым временем простоя для клиентов приложения. Когда автоматический обмен включен из слота в рабочий, каждый раз, когда вы отправляете изменения кода в этот слот, служба приложений автоматически переводит приложение в рабочий слот после того, как оно нагревается в исходном слоте.

Примечание.

Перед настройкой автоматического переключения для рабочего слота рассмотрите возможность автоматического переключения в целевом слоте, отличном от производства.

Для настройки функции автоматического обмена:

  1. Перейдите на страницу ресурсов вашего приложения. Выберите Слоты развертывания><Требуемый исходный слот>>Конфигурация>Общие параметры.

  2. Для параметра Автоматическая замена включена выберите Включить. После этого выберите нужный целевой слот для слота развертывания с автоматической заменой и выберите Сохранить на панели команд.

    A screenshot that shows how to configure auto swap into the production slot in the portal.

  3. Передайте код в исходный слот. Автоматическая замена происходит через короткое время, при этом обновление отражается в URL-адресе вашего целевого слота.

В случае возникновения проблем см. раздел Устранение неполадок подкачки.

Укажите индивидуальную процедуру прогрева

Некоторым приложениям перед обменом могут потребоваться специальные действия для прогрева. Элемент конфигурации applicationInitialization в web.config позволяет указать настраиваемые действия инициализации. Операция обмена ожидает завершения настраиваемой процедуры прогрева перед заменой на целевой слот. Ниже приведен пример фрагмента web.config.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Дополнительные сведения о настройке элемента applicationInitialization см. в записи блога о распространенных сбоях переключения слота развертывания и способах их устранения.

Вы также можете настроить поведение при прогреве с помощью одного или обоих из следующих настроек приложения :

  • WEBSITE_SWAP_WARMUP_PING_PATH: путь к пингу по HTTP для прогрева вашего сайта. Добавьте этот параметр приложения, указав настраиваемый путь, который начинается с косой черты в качестве значения. Например, /statuscheck. Значение по умолчанию — /.
  • WEBSITE_SWAP_WARMUP_PING_STATUSES: действительные коды ответа HTTP для операции прогрева. Добавьте этот параметр приложения со списком кодов HTTP, разделенным запятыми. Пример: 200,202. Если возвращенного кода состояния нет в списке, операции прогрева и обмена останавливаются. По умолчанию все коды ответов являются допустимыми.
  • WEBSITE_WARMUP_PATH: относительный путь на сайте, который следует проверять при каждом перезапуске сайта (не только во время смены слотов). Примеры значений включают /statuscheck или корневой путь, /.

Примечание.

Элемент конфигурации <applicationInitialization> является частью каждой процедуры запуска приложения, в то время как две настройки приложения для поведения при прогреве применяются только к замене слотов.

В случае возникновения проблем см. раздел Устранение неполадок подкачки.

Мониторинг процедуры обмена

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

На странице ресурсов вашего приложения на портале на левой панели выберите Журнал активности.

Операция переключения отображается в запросах журнала в виде Swap Web App Slots. Вы можете развернуть этот элемент и выбрать вложенные операции или ошибки, чтобы увидеть подробные сведения о них.

Автоматическая маршрутизация рабочего трафика

По умолчанию все клиентские запросы, поступающие на URL-адрес приложения (http://<app_name>.azurewebsites.net), направляются в рабочий слот. Вы можете перенаправить часть этого трафика в другой слот. Это очень удобно, когда вам нужно собрать отзывы пользователей о новой версии, но вы пока не готовы публиковать ее в рабочей среде.

Для автоматической маршрутизации производственного трафика:

  1. Перейдите на страницу ресурсов вашего приложения и выберите Слоты развертывания.

  2. В столбце Процент трафика для слота, в который нужно направить часть трафика, укажите значение в процентах (от 0 до 100) от общего объема распределяемого трафика. Выберите Сохранить.

    A screenshot that shows how to route a percentage of request traffic to a deployment slot, in the portal.

После сохранения параметра указанный процент клиентов случайным образом направляется в непроизводный слот.

После автоматического перенаправления клиента в определенный слот он закрепляется в этом слоте в течение одного часа или пока файлы cookie не будут удалены. Вы можете проверить, к какому слоту прикреплен клиент, просмотрев значение параметра cookie x-ms-routing-name в заголовках HTTP средствами браузера. Если запросы направляются в промежуточный слот, этот параметр имеет значение x-ms-routing-name=staging. Если запросы направляются в рабочий слот, этот параметр имеет значение x-ms-routing-name=self.

Маршрутизация рабочего трафика вручную

Кроме автоматической маршрутизации трафика, Служба приложений поддерживает направление запросов в конкретные слоты. Это полезно в тех случаях, когда вы хотите, чтобы ваши пользователи могли включить или отключить ваше бета-приложение. Для маршрутизации рабочего трафика вручную применяется параметр запроса x-ms-routing-name.

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

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Строка x-ms-routing-name=self определяет рабочий слот. После того, как клиентский браузер получает доступ к ссылке, она перенаправляется в рабочий слот. Каждый последующий запрос содержит файл cookie x-ms-routing-name=self, который прикрепляет сеанс к производственному слоту.

Чтобы разрешить пользователям входить в бета-приложение, задайте тот же параметр запроса именем непроизводного слота. Приведем пример:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

По умолчанию новые слоты получают правило маршрутизации 0%, выделенное серым цветом. Если вы явным образом установите для данного значения значение 0% (выделено черным текстом), ваши пользователи смогут получить доступ к промежуточному слоту вручную при помощи параметра запроса x-ms-routing-name. Однако они не будут перенаправлены в слот автоматически, потому что процент маршрутизации установлен на 0. Это расширенный сценарий, в котором вы можете «скрыть» свой промежуточный слот от других пользователей, позволяя внутренним командам тестировать изменения в слоте.

Удаление слота

Найдите и выберите свое приложение. Выберите Слоты развертывания><Слот, который нужно удалить>>Обзор. Тип приложения отображается как Служба приложений (слот) для напоминания того, что вы просматриваете слот развертывания. Перед удалением слота обязательно остановите слот и установите трафик в слоте равным нулю. Выберите Удалить на панели команд.

A screenshot that shows how to delete a deployment slot in the portal.

Автоматизация с использованием шаблонов Resource Manager

Шаблоны Azure Resource Manager представляют собой декларативные файлы JSON, используемые для автоматизации развертывания и настройки ресурсов Azure. Чтобы заменить слоты с помощью шаблонов Resource Manager, необходимо задать два свойства в ресурсах Microsoft.Web/sites/sites и Microsoft.Web/sites :

  • buildVersion: это строковое свойство, представляющее текущую версию приложения, развернутого в слоте. Например: "v1", "1.0.0.1" или "2019-09-20T11:53:25.2887393-07:00".
  • targetBuildVersion: это строковое свойство, определяющее, что для buildVersion должен иметься слот. Если текущий targetBuildVersion параметр не равен текущему buildVersion, он активирует операцию переключения, найдя слот с указанным buildVersion.

Пример шаблона Resource Manager

Следующий шаблон Resource Manager переключит два слотаstaging, обновив buildVersion слот и задав targetBuildVersion рабочий слот. Предполагается, что вы создали слот с именем staging.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Данный шаблон Resource Manager является идемпотентным, что означает, что он может выполняться многократно и приводить к тому же состоянию слотов. Без каких-либо изменений в шаблоне последующие запуски одного и того же шаблона не активируют переключение слотов, так как слоты уже находятся в нужном состоянии.

Устранение неполадок в процессе обмена

Если во время обмена слотов возникает какая-либо ошибка, она регистрируется в файле D:\home\LogFiles\eventlog.xml. Ошибка также регистрируется в журнале ошибок конкретного приложения.

Ниже приведены несколько распространенных ошибок в процессе обмена:

  • HTTP-запрос к корню приложения рассчитан по времени. Операция переключения ожидает 90 секунд для каждого HTTP-запроса и повторяется до пяти раз. Если время всех повторных попыток истекло, операция обмена останавливается.

  • Инициализация локального кэша может завершиться ошибкой, если содержимое приложения превышает квоту локального диска, указанную для локального кэша. Для получения дополнительной информации см. Обзор локального кэша.

  • Во время пользовательской процедуры прогрева запросы HTTP выполняются внутри (без прохождения через внешний URL). Они могут завершиться ошибкой при определенных правилах перезаписи URL в Web.config. К примеру, правила перенаправления доменных имен или принудительного применения HTTPS могут препятствовать тому, чтобы запросы на прогрев доходили до кода приложения. Для обхода данной проблемы необходимо изменить правила перезаписи, добавив следующие два условия:

    <conditions>
  <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>

  • Без пользовательской процедуры прогрева правила перезаписи URL все равно могут блокировать HTTP-запросы. Для обхода данной проблемы необходимо изменить правила перезаписи, добавив следующее условие:

    <conditions>
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>

  • После замены слотов приложение может неожиданно перезагрузиться. Это связано с тем, что после обмена конфигурация привязки имени хоста не синхронизируется, что само по себе не вызывает перезапусков. Однако определенные базовые события хранилища (например, отработка отказа тома хранилища) могут обнаруживать эти несоответствия и заставлять все рабочие процессы перезапускаться. Чтобы свести к минимуму такие типы перезапусков, установите WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 настройку приложения на все слоты. Однако этот параметр приложения не работает с приложениями Windows Communication Foundation (WCF).

Следующие шаги

Блокировка доступа к непроизводным слотам