Стоит ли останавливать Azure Web App во время обновления? - PullRequest
0 голосов
/ 22 октября 2018

Я обновляю свое веб-приложение Azure из DevOps Azure.В настоящее время мой выпуск выглядит так:

  1. Остановите веб-приложение,
  2. Обновите веб-приложение и
  3. Запустите приложение.

У меня вопрос: разумно ли останавливать веб-приложение во время обновления?Когда я выбираю шаблон выпуска в DevOps Azure для Azure Web App, нет никаких шагов остановки / запуска, только шаг обновления.Так что я думаю, что остановка / запуск даже необходим.

Ответы [ 4 ]

0 голосов
/ 19 апреля 2019

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

  1. Run-from-Package + 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 ).

Примечание. Если вы используете DevOps Azure - он поддерживает почти все эти параметры - использует задачу развертывания службы приложений Azure

0 голосов
/ 22 октября 2018

То, что мы в основном сделали, это:

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

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

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

0 голосов
/ 22 октября 2018

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

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

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

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

enter image description here

0 голосов
/ 22 октября 2018

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

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

enter image description here

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...