Как развернуть приложение ASP.NET с нулевым временем простоя

Question

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

1. Заархивируйте новый код и загрузите его на сервер.
2. На действующем сервере удалите весь действующий код из каталога веб-сайта IIS.
3. Извлеките новый zip-файл кода в теперь пустой каталог IIS

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

Какие-либо предложения по методу простоя 0 секунд?

Answer 1

Вам нужно 2 сервера и балансировщик нагрузки. Вот в шагах:

1. Включите весь трафик на сервере 2
2. Развертывание на сервере 1
3. Тестовый сервер 1
4. Включите весь трафик на сервере 1
5. Развертывание на сервере 2
6. Тестовый сервер 2
7. Включение трафика на обоих серверах

Дело в том, что даже в этом случае у вас все равно будут перезапуски приложений и потеря сеансов, если вы используете "липкие сеансы". Если у вас есть сеансы базы данных или сервер состояний, то все должно быть хорошо.

Answer 2

Microsoft Web Deployment Tool поддерживает это до некоторой степени:

Включает транзакционный файл Windows Поддержка системы (TxF). Когда поддержка TxF включен, файловые операции неделимый; то есть они либо преуспевают или потерпеть неудачу полностью. Это гарантирует данные целостность и предотвращает данные или файлы от существующего на полпути или испорченное состояние. В MS Deploy TxF это по умолчанию отключено.

Кажется, транзакция для всей синхронизации. Кроме того, TxF является функцией Windows Server 2008, поэтому эта функция транзакции не будет работать с более ранними версиями.

Я считаю, что можно изменить сценарий на время простоя 0, используя папки в качестве версий и метабазу IIS:

• для существующего пути / URL:
  • путь : \ web \ app \ v2.0 \
  • url : http://app
• Копировать новый (или измененный) веб-сайт на сервер в
  • \ Web \ приложение \ v2.1 \
• Изменение метабазы ​​IIS для изменения пути к сайту
  • из \ web \ app \ 2.0 \
  • до \ web \ app \ v2.1 \

Этот метод предлагает следующие преимущества:

• В случае возникновения проблем с новой версией, вы можете легко вернуться к v2.0
• Для развертывания на нескольких физических или виртуальных серверах вы можете использовать свой сценарий для развертывания файлов. Как только все серверы получат новую версию, вы можете одновременно изменять метабазы ​​всех серверов с помощью Microsoft Web Deployment Tool.

Answer 3

Вы можете добиться нулевого времени простоя развертывания на одном сервере, используя маршрутизацию запросов приложений в IIS в качестве программного балансировщика нагрузки между двумя локальными сайтами IIS на разных портах. Это известно как сине-зеленая стратегия развертывания , когда только один из двух сайтов доступен в балансировщике нагрузки в любой момент времени. Разверните сайт, который не работает, прогрейте его и перенесите его в балансировщик нагрузки (обычно, пройдя проверку работоспособности маршрутизации запроса приложения), затем выведите исходный сайт, который был запущен, из «пула» (снова путем проверки его работоспособности).

Полный учебник можно найти здесь.

Answer 4

Используя класс ServerManager Microsoft.Web.Administration, вы можете разработать свой собственный агент развертывания.

Хитрость заключается в том, чтобы изменить PhysicalPath VirtualDirectory, что приводит к онлайн-атомарному переключению между старыми и новыми веб-приложениями.

Имейте в виду, что это может привести к параллельной работе старых и новых доменов приложений!

Проблема в том, как синхронизировать изменения в базах данных и т. Д.

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

Чтобы принудительно запустить домен приложений, необходимо выполнить HTTP-запрос (IIS 7.5 поддерживает функцию автозапуска)

Теперь вам нужен способ блокировать запросы на новый домен приложений. Я использую именованный мьютекс, который создается и принадлежит агенту развертывания, ждет от Application_Start нового веб-приложения и затем освобождается агентом развертывания после обновления базы данных.

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

Answer 5

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

Для моей конфигурации у меня был веб-каталог для каждого сайта A и B, например: c: \ Intranet \ Live A \ Interface c: \ Intranet \ Live B \ Interface

В IIS у меня есть два идентичных сайта (одинаковые порты, аутентификация и т. Д.), Каждый со своим собственным пулом приложений. Один из сайтов работает (A), а другой остановлен (B). у живого также есть заголовок живого хоста.

Когда дело доходит до развертывания, я просто публикую публикацию на месте ОСТАНОВЛЕННОГО сайта. Поскольку я могу получить доступ к сайту B через его порт, я могу предварительно подогреть сайт, чтобы первый пользователь не вызвал запуск приложения. Затем с помощью командного файла я копирую заголовок живого хоста в B, останавливаю A и запускаю B.

Answer 6

ОК, так как каждый отрицает ответ, я написал еще в 2008 году * ...

Я расскажу вам, как мы это делаем сейчас в 2014 году. Мы больше не используем веб-сайты, потому что сейчас мы используем ASP.NET MVC.

Нам, конечно, не нужен балансировщик нагрузки и два сервера для этого, это хорошо, если у вас есть 3 сервера для каждого поддерживаемого вами сайта, но это для большинства сайтов излишнее.

Кроме того, мы не полагаемся на последний мастер от Microsoft - слишком медленный, слишком много скрытой магии и слишком склонный к изменению его имени.

Вот как мы это делаем:

1. У нас есть шаг после сборки, который копирует сгенерированные библиотеки DLL в папку bin-pub.

2. Мы используем Beyond Compare (что отлично **) для проверки и синхронизации измененных файлов (через FTP, потому что это широко поддерживается) до рабочего сервера

3. У нас есть защищенный URL-адрес на веб-сайте, содержащий кнопку, которая копирует все данные из «bin-pub» в «bin» (сначала сделайте резервную копию, чтобы включить быстрый откат). На этом этапе приложение перезапускает себя. Затем наш ORM проверяет наличие каких-либо таблиц или столбцов, которые необходимо добавить, и создает их.

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

Весь процесс развертывания занимает от 5 секунд до 30 минут, в зависимости от того, сколько файлов изменено и сколько изменений нужно просмотреть.

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

** Мы всегда делаем быстрый взгляд на изменения, которые мы внедряем - как двойную проверку в последнюю минуту, поэтому мы знаем, что тестировать, и если что-то сломается, мы готовы. Мы используем Beyond Compare, потому что он позволяет легко различать файлы по FTP. Я бы никогда не сделал этого без BC, ты не представляешь, что перезаписываешь.

* Прокрутите вниз, чтобы увидеть его :( Кстати, я бы больше не рекомендовал веб-сайты, потому что они медленнее создавались и могли плохо работать с полускомпилированными временными файлами. Мы использовали их в прошлом, потому что они позволяли более гибкие развертывание по файлам. Очень быстро устранить незначительную проблему, и вы сможете точно увидеть, что вы развертываете (если, конечно, используете Beyond Compare - иначе забудьте об этом).

Answer 7

Единственные методы с нулевым временем простоя, о которых я могу думать, включают хостинг как минимум на 2 серверах.

Answer 8

Вот как я это делаю:

Абсолютные минимальные системные требования:
1 сервер с

• 1 балансировщик нагрузки / обратный прокси-сервер (например, nginx), работающий на порту 80
• 2 ASP.NET-Core / моно-реверси-прокси / fastcgi chroot-jails или docker-контейнеры, прослушивающие через 2 разных порта TCP (или даже только два приложения обратного прокси на 2 разных портах TCP без какой-либо изолированной программной среды)

Workflow:

начать транзакцию myupdate

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

Answer 9

Чтобы расширить ответ sklivvz, который основывался на том, чтобы иметь какой-то балансировщик нагрузки (или просто резервную копию на том же сервере)

1. Направлять весь трафик на сайт / сервер 2
2. При желании немного подождите, чтобы как можно меньше пользователей ожидали выполнения рабочих процессов в развернутой версии
3. Разверните на сайте / сервере 1 и максимально прогрейте его
4. Выполнение миграций базы данных транзакционно (стремитесь сделать это возможным)
5. Немедленно направить весь трафик на сайт / сервер 1
6. Развертывание на сайте / сервере 2
7. Прямой трафик на оба сайта / сервера

Можно ввести небольшое тестирование дыма, создав снимок / копию базы данных, но это не всегда выполнимо.

Если возможно и необходимо, используйте «различия в маршрутизации», такие как разные URL-адреса арендаторов: (customerX.myapp.net) или разных пользователей, чтобы сначала развернуть группу неизвестных морских свинок. Если ничего не получится, отпустите всех.

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

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

Answer 10

Я бы немного уточнил ответ Джорджа следующим образом:

1. Использование проекта веб-развертывания для предварительной компиляции сайта в одну DLL
2. Заархивируйте новый сайт и загрузите его на сервер
3. Распакуйте его в новую папку, расположенную в папке с правами доступа для сайта, чтобы разархивированные файлы правильно наследовали разрешения (возможно, e: \ web, с подпапками v20090901, v20090916 и т. Д.)
4. Используйте IIS Manager, чтобы изменить имя папки, содержащей сайт
5. Сохраните старую папку на некоторое время, чтобы вы могли использовать ее в случае проблем

Шаг 4 приведет к перезагрузке рабочего процесса IIS.

Это просто нулевое время простоя, если вы не используете сессии InProc; используйте режим SQL, если можете (даже лучше, полностью избегайте состояния сеанса).

Конечно, это немного сложнее, когда происходит изменение нескольких серверов и / или баз данных ...