Поделиться через

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

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

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

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

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

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

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

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

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

Следующее видео дополняет шаги, описанные в этой статье, иллюстрируя, как настроить тестовые среды в Azure App Service.

Предпосылки

  • Разрешения для выполнения нужной вам операции с слотами. Для получения информации о необходимых разрешениях см. Операции поставщика ресурсов. Ищите slot, например.

Добавить слот

Для того чтобы включить несколько слотов развертывания, приложение должно работать на уровне Standard, Premium или Isolated.

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

  2. В левом меню выберите Deployment>Deployment slots. Затем выберите Добавить.

    Примечание

    Если приложение еще не находится на уровне Standard, Premium или Isolated, выберите Обновить. Перейдите на вкладку Scale в вашем приложении, прежде чем продолжить.

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

    Снимок экрана, показывающий варианты настройки нового слота размещения с именем 'staging' в портале.

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

    Примечание

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

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

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

    Снимок экрана, показывающий, как открыть страницу управления слотом развертывания в портале.

    У слот карантинования есть страница управления, как и у любого другого приложения службы приложений. Вы можете изменить конфигурацию слота. Чтобы напомнить вам, что вы просматриваете слот развертывания, имя приложения и имя слота отображаются в URL-адресе. Тип приложения — App Service (Slot). Вы также можете рассматривать этот слот как отдельное приложение в вашей группе ресурсов с теми же обозначениями.

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

Новый слот развертывания не содержит контента, даже если вы клонируете настройки из другого слота. Например, вы можете опубликовать в этот слот с помощью Git. Вы можете развернуть в слот из другой ветки репозитория или из другого репозитория. Статья Get a publish profile from Azure App Service может предоставить необходимую информацию для развертывания в слот. Visual Studio может импортировать профиль для размещения содержимого в слоте.

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

Поймите, что происходит во время обмена

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

Когда вы меняете два слота, служба приложений выполняет следующие действия, чтобы гарантировать, что целевой слот не испытывает простоя:

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

    • Настройки приложения, специфичные для слотов, и строки подключения, если применимо
    • Continuous deployment настройки, если включено
    • Настройки аутентификации сервиса приложений, если включено

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

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

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

  4. Если автоматическая смена включена с пользовательским прогревом, запустите пользовательскую инициализацию приложения на каждом экземпляре исходного слота.

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

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

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

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

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

Примечание

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

Этапы, как сделать слот недоступным для замены

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

Когда вы меняете слоты, эти настройки также меняются:

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

При обмене слотами эти настройки не меняются:

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

Примечание

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

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

Чтобы настроить параметр приложения или строку подключения таким образом, чтобы они были привязаны к определенному слоту, который не заменяется:

  1. Перейдите в Настройки>Переменные среды для этого слота.

  2. Добавьте или измените настройку, а затем выберите Настройка слота развертывания. Выбор этого флажка сообщает службе приложений, что настройка не может быть заменена.

  3. Выберите Применить.

Скриншот, показывающий флажок для настройки параметра приложения как настройки слота в портале Azure.

Поменять местами слоты развертывания

Вы можете поменять местами слоты развертывания на странице Слоты развертывания и на странице Обзор вашего приложения.

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

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

    Снимок экрана, показывающий выборы для инициирования операции обмена в портале.

    Диалоговое окно Swap отображает параметры в выбранных исходных и целевых слотах, которые нужно изменить.

  2. Выберите нужные слоты Source и Target. Обычно целью является производственный слот. Также выберите вкладки Изменения исходного слота и Изменения целевого слота и проверьте, что изменения конфигурации соответствуют ожиданиям. Когда вы закончите, вы можете сразу поменять местами слоты, выбрав Start Swap.

    Скриншот, показывающий варианты настройки и завершения обмена в портале.

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

  3. Нажмите кнопку Закрыть, чтобы закрыть диалоговое окно.

Если у вас возникнут какие-либо проблемы, посмотрите Устранение неполадок замены в конце этой статьи.

Замена с предварительным просмотром (многоэтапная замена)

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

Когда вы выполняете обмен с предварительным просмотром, App Service выполняет ту же операцию обмена, но делает паузу после первого шага. Затем вы можете проверить результат на промежуточном слоте перед завершением обмена.

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

Примечание

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

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

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

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

    Когда первая фаза завершается, диалоговое окно уведомляет вас.

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

    Скриншот, показывающий, как настроить обмен с предварительным просмотром в портале.

    Чтобы отменить ожидаемую замену, выберите Отменить замену, а затем нажмите кнопку Отменить замену.

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

Если у вас возникнут какие-либо проблемы, посмотрите Устранение неполадок замены в конце этой статьи.

Откатить своп

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

Настроить автоматическую замену

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

Примечание

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

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

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

  2. В левом меню выберите Настройки>Конфигурация>Общие настройки.

  3. Для включения автоматического переключения выберите Вкл. Для слота развертывания с автоматической заменой выберите целевой слот. Затем выберите Save на командной панели.

    Снимок экрана, показывающий выборы для настройки автоматической замены в рабочем слоте на портале.

  4. Запустите отправку кода в исходный слот. Автоматическая замена происходит через короткое время. Обновление отражено в 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> является частью запуска каждого приложения, в то время как настройки приложения для поведения при прогреве применяются только к обмену слотами.

Если у вас возникнут какие-либо проблемы, посмотрите Устранение неполадок замены в конце этой статьи.

Контролировать обмен

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

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

  2. Операция обмена появляется в запросе журнала как Swap Web App Slots. Чтобы просмотреть детали, вы можете развернуть её и выбрать одну из подопераций или ошибок.

Маршрутизируйте производственный трафик автоматически

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

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

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

    Скриншот, показывающий выбор на портале для маршрутизации процента трафика запросов на слот развертывания.

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

После того как клиент автоматически направляется в определённый слот, он будет прикреплён к этому слоту на один час или до тех пор, пока файлы 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. Эта конфигурация представляет собой расширенный сценарий, в котором вы можете скрыть демонстрационный слот от общественности, позволяя внутренним командам тестировать изменения на этом слоте.

Удалить слот

  1. Найдите и выберите ваше приложение.

  2. Выберите Развертывание>Слоты развертывания>слот для удаления>Обзор. Тип приложения отображается как App Service (Slot), чтобы напомнить вам, что вы просматриваете слот развертывания.

  3. Прекратите слот и установите трафик в слоте на ноль.

  4. В панели команд выберите Удалить.

Скриншот, показывающий варианты удаления слота развертывания в портале.

Автоматизация с помощью шаблонов диспетчера ресурсов

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

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

Пример шаблона диспетчера ресурсов

Следующий шаблон диспетчера ресурсов изменяет два слота, обновляя значение buildVersion слота staging и устанавливая значение 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-запроса и повторяет попытку до пяти раз. Если все попытки повторной отправки завершатся по тайм-ауту, операция обмена будет остановлена.

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

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

    • Отмените операцию обмена, которая возвращает сайт в прежнее состояние.
    • Завершите операцию обмена, обновляющую сайт до нужного нового состояния.

    Чтобы узнать, как отменить или завершить операцию обмена, см. раздел Обмен с предварительным просмотром (многоэтапный обмен) ранее в этой статье.

  • Во время пользовательской разминки 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).

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

Настройте ограничения доступа для Azure App Service