Развертывание новой версии приложения в приложении IIS без простоя

Развертывание новой версии приложения в приложении IIS без простоя

У меня есть небольшое веб-приложение AngularJS, которое работает в киосках в интрасети. Мне было поручено выполнять развертывания без простоев и автоматизированным способом, который можно контролировать удаленно с помощью веб-интерфейса. Поскольку это небольшое приложение, у нас нет балансировщиков нагрузки или подобных установок. Я рассмотрел два варианта:

Опция 1: Загрузите версии приложения в папку и измените физический путь виртуального каталога на путь к папке новой версии. Это можно сделать с помощью библиотеки Microsoft.Web.Administration с помощью следующего кода:

            ServerManager sm = new ServerManager();
            Site site = sm.Sites["Default Web Site"];            
            site.Applications[virtualDirectory].VirtualDirectories["/"].PhysicalPath = newPath;
            sm.CommitChanges();

При таком подходе

  1. Как быстро отразится переключение?
  2. Каковы шансы, что некоторые киоски все еще работают со старой версией приложения?
  3. Есть ли вероятность простоя в течение короткого периода времени между переключением?
  4. Будут ли какие-либо запросы к IIS, сделанные в этот период времени, возвращать ошибки?

Вариант 2:Использование функции URL Rewrite IIS. По сути, я буду программно добавлять новые правила перезаписи в web.config приложения для перенаправления в другую подпапку, которая будет новой версией приложения.

При таком подходе

  1. Как быстро отразится правило перезаписи URL и начнется переписывание?
  2. Каковы шансы, что некоторые киоски все еще работают со старой версией приложения?
  3. Есть ли вероятность простоя в период между добавлением правила перезаписи в web.config?
  4. Будут ли какие-либо запросы к IIS, сделанные в этот период времени, возвращать ошибки?
  5. Возникнут ли какие-либо затраты на производительность при переписывании URL?

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

решение1

MSDeploy должен уметь справляться с автоматизированной и удаленной частью развертывания. Если у вас нет другого сервера или другого способа отправлять трафик приложений в другой виртуальный каталог в автоматическом режиме, отсутствие простоя — непрактичный запрос. Это как сказать, что у меня есть 1 машина, но я хочу иметь возможность продолжать ездить на ней, пока она находится в мастерской. Если вы хотите, чтобы машина ездила, пока ваша машина находится в мастерской, вам понадобится другая машина, временная или иная.

Связанный контент