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

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

1. Поверните весь трафик на сервере 2
2. Развертывание на сервере 1
3. Тест-сервер 1
4. Поверните весь трафик на сервере 1
5. Развертывание на сервере 2
6. Тест-сервер 2
7. Поворот трафика на обоих серверах

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда дело доходит до развертывания, я просто публикую его на сайте STOPPED. Поскольку я могу получить доступ к сайту B с помощью своего порта, я могу предварительно разогреть сайт, чтобы первый пользователь не вызывал запуск приложения. Затем, используя командный файл, я копирую заголовок главного хоста в B, останавливаю A и запускаю B.

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

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

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

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

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

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

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

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

Хорошо, так как каждый из них откладывает ответ, который я написал еще в 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, вы понятия не имеете, что вы переписываете.

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

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

Я бы уточнил ответ Джорджа, как показано ниже, для одного сервера:

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура:

начать транзакцию 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  OR apt-get install --only-upgrade  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 

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

Не уверен, что это помогает в «веб-приложении», хотя (я думаю, вы говорите, что это то, что вы используете), поэтому мы всегда используем «веб-сайты». Кроме того, развертывание «веб-сайтов» не перезапускает ваш сайт и не отбрасывает все сеансы пользователя.