Следует ли останавливать службу приложений Azure во время обновления?

Вероятно, это зависит от вашего приложения. Если у вас нет проблем, когда вы просто обновляете свое приложение (например, проблема с используемым файлом), вы можете рассмотреть возможность использования флага Перевести приложение в автономный режим, который поместит файл app_offline.htm в корневой каталог службы приложений во время обновление (потом оно будет удалено). Таким образом пользователь узнает, что с приложением что-то происходит.

Однако я часто делал то же самое, что и вы: Стоп, Обновить, Старт ?

В основном мы сделали:

1. Остановить промежуточный слот
2. Развернуть в слот
3. Начальный слот
4. Поменять стадию на производство
5. Остановить промежуточный слот

Предложение Мартина о переводе приложения в автономный режим тоже хорошее!

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

Согласны и с Мартином, и с юунасом. Если вы хотите выполнить развертывание, не оказывая влияния на пользователей, вам необходимо использовать подход с заменой слотов. juunas также поднимает важный вопрос, как легко откатиться назад. Наш подход включает еще один слот, который мы называем «исправлением». Это добавляет несколько преимуществ:

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

2. Откатывайтесь в продукте, даже если разработчики уже развернули его в тестовой среде.

3. Позволяет тестировать ошибки в текущей и предыдущей версиях кода. Полезно, когда кто-то говорит: «Хорошо, это работало до этого развертывания» ...

Вот как это выглядит.

Есть (5) вариантов безопасного развертывания (атомарные обновления) для Веб-приложения Azure. Вот мой предпочтительный порядок, ранжированный по приоритету и функциональности:

1. Запуск из пакета + ZipDeploy (делает сайт доступным только для чтения)
2. ZipDeploy (с использованием kudu REST api - автоматически переводит сайт в автономный режим)
3. Azure CLI (az webapp)
4. msdeploy (-enableRule:AppOffline или остановить / запустить сайт для обеспечения атомарности)
5. FTP (используя профиль публикации, обязательно загрузите appoffline.htm)

Существует множество других вариантов развертывания, таких как облачная синхронизация, github непрерывный, локальный git и т. д., Но все они построены на API Kudu (как Azure CLI).

Note: If you're using Azure DevOps - it's supports nearly all these options - leverage the Azure App Service Deploy task