Для развертывания новой версии нашего веб-сайта мы делаем следующее:
Этот процесс написан на всех сценариях и происходит довольно быстро, но при удалении старых файлов и развертывании новых файлов все еще может быть время простоя 10-20 секунд.
Любые предложения по методу простоя в течение 0 секунд?
Вам нужно 2 сервера и балансировщик нагрузки. Здесь в шагах:
Дело в том, что даже в этом случае у вас все еще будут перезагрузки приложений и потеря сеансов, если вы используете "липкие сеансы". Если у вас есть сеансы базы данных или сервер состояний, все должно быть хорошо.
Microsoft Web Deployment Tool в некоторой степени поддерживает это:
Включает файл транзакции Windows Поддержка системы (TxF). Когда поддержка TxF, файловые операции неделимый; то есть они либо преуспевают или полностью сбой. Это обеспечивает данные целостность и предотвращение данных или файлов от существующего в "на полпути" или поврежденного состояния. В MS Deploy TxF является отключено по умолчанию.
Кажется, транзакция для всей синхронизации. Кроме того, TxF является особенностью Windows Server 2008, поэтому эта функция транзакций не будет работать с более ранними версиями.
Я считаю возможным изменить ваш script для 0-downtime, используя папки как версии и метабазу IIS:
Этот метод предлагает следующие преимущества:
Я просмотрел это недавно, и решение, которое я придумал, состояло в том, чтобы создать два сайта в IIS и переключаться между ними.
Для моей конфигурации у меня был веб-каталог для каждого сайта A и B, например: c:\Intranet\Live A\Interface c:\Intranet\Live B\Interface
В IIS у меня есть два одинаковых сайта (одинаковые порты, аутентификация и т.д.), каждый из которых имеет собственный пул приложений. Один из сайтов работает (A), а другой остановлен (B). у живого есть также заголовок главного хоста.
Когда дело доходит до развертывания для жизни, я просто публикую его на сайте STOPPED. Поскольку я могу получить доступ к сайту B с помощью своего порта, я могу предварительно разогреть сайт, чтобы первый пользователь не вызывал запуск приложения. Затем, используя пакетный файл, я копирую заголовок главного хоста в B, останавливаю A и запускаю B.
Используя класс Microsoft.Web.Administration ServerManager, вы можете разработать собственный агент развертывания.
Хитрость заключается в том, чтобы изменить PhysicalPath VirtualDirectory, что приводит к интерактивному атомному коммутатору между старыми и новыми веб-приложениями.
Имейте в виду, что это может привести к тому, что старые и новые AppDomains будут выполняться параллельно!
Проблема заключается в том, как синхронизировать изменения в базах данных и т.д.
Опросом для существования AppDomains со старыми или новыми PhysicalPaths можно обнаружить, когда старые AppDomain завершились, и если новый AppDomain запущен.
Чтобы заставить AppDomain запускаться, вы должны сделать HTTP-запрос (IIS 7.5 поддерживает функцию автозапуска)
Теперь вам нужен способ блокировать запросы для нового AppDomain. Я использую именованный мьютекс, который создается и принадлежит агенту развертывания, который ждет приложение Application_Start нового веб-приложения и затем освобождается агентом развертывания после того, как были сделаны обновления базы данных.
(Я использую файл маркера в веб-приложении, чтобы включить режим ожидания мьютекса) После запуска нового веб-приложения я удаляю файл маркера.
Вы можете достичь нулевого времени простоя на одном сервере, используя Маршрутизацию запросов приложений в IIS в качестве балансировки нагрузки программного обеспечения между двумя локальными сайтами IIS на разных портах. Это называется стратегией развертывания с синим зеленым цветом, где только один из двух сайтов доступен в балансировщике нагрузки в любой момент времени. Разверните узел "вниз", прогрейте его и введите в балансировщик нагрузки (обычно, пропустив проверку работоспособности запроса на запрос приложения), затем возьмите исходный сайт, который был вверх, из "пула" (снова путем проверки работоспособности).
ОК, так как каждый из нас занижает ответ, который я написал еще в 2008 году *...
Я расскажу вам, как мы это делаем в 2014 году. Мы больше не используем веб-сайты, потому что теперь мы используем ASP.NET MVC.
Мы, конечно, не нуждаемся в балансировщике нагрузки и двух серверах для этого, это прекрасно, если у вас есть 3 сервера для каждого веб-сайта, который вы поддерживаете, но это полный избыток для большинства веб-сайтов.
Кроме того, мы не полагаемся на последнего мастера из Microsoft - слишком медленно и слишком много скрытой магии и слишком склонны к изменению его имени.
Вот как мы это делаем:
У нас есть шаг пост-сборки, который копирует сгенерированные DLL файлы в папку "bin-pub".
Мы используем Beyond Compare (превосходно **) для проверки и синхронизации измененных файлов (по FTP, потому что это широко поддерживается) до производственного сервера
У нас есть безопасный URL-адрес на веб-сайте, содержащий кнопку, которая копирует все в "bin-pub" в "bin" (сначала берет резервную копию, чтобы включить быстрый откат). На этом этапе приложение перезагружается. Затем наш ORM проверяет, есть ли какие-либо таблицы или столбцы, которые необходимо добавить и создает.
Это всего лишь миллисекундное время простоя. Перезапуск приложения может занимать секунду или два, но во время запросов на перезагрузку буферизуется, поэтому есть фактически нулевое время простоя.
Весь процесс развертывания занимает от 5 секунд до 30 минут, в зависимости от количества файлов и количества изменений.
Таким образом, вам не нужно копировать весь сайт в другой каталог, а только в папку bin. Вы также имеете полный контроль над процессом и точно знаете, что меняется.
** Мы всегда делаем быстрый обзор изменений, которые мы развертываем, - как двойная проверка в последнюю минуту, поэтому мы знаем, что тестировать, и если что-то сломается, мы готовы. Мы используем Beyond Compare, потому что он позволяет вам легко сравнивать файлы по FTP. Я бы никогда не делал этого без BC, вы понятия не имеете, что вы переписываете.
* Прокрутите вниз, чтобы увидеть его:( BTW Я бы больше не рекомендовал веб-сайты, потому что они медленнее строить и могут сильно пострадать с помощью скомпилированных файлов temp. Мы использовали их в прошлом, потому что они позволяли создавать более гибкие файловые файлы, по файловому развертыванию. Очень быстро исправить незначительную проблему, и вы можете точно определить, что вы развертываете (если вы используете Beyond Compare, конечно, иначе забудьте об этом).
Единственные нулевые методы простоя, о которых я могу думать, включают хостинг на не менее 2 серверах.
Я бы уточнил Джордж немного, как указано ниже, для одного сервера:
Шаг 4 приведет к переработке рабочего процесса IIS.
Это только нулевое время простоя, если вы не используете сеансы InProc; вместо этого используйте режим SQL, если вы можете (даже лучше, полностью исключить состояние сеанса).
Конечно, это немного больше связано с несколькими серверами и/или изменениями базы данных....
Чтобы расширить ответ на sklivvz, который основывался на наличии какого-то балансировщика нагрузки (или просто резервной копии на том же сервере)
Можно ввести немного тестирования дыма, создав моментальный снимок/копию базы данных, но это не всегда возможно.
Если возможно и необходимо использовать "различия в маршрутизации", например, разные URL-адреса арендатора: s (customerX.myapp.net) или разные пользователи, сначала развертывать группу незнакомых морских свинок. Если ничего не получается, отпустите всех.
В связи с миграцией базы данных возврат к предыдущей версии часто бывает невозможным.
Есть способы сделать приложения более приятными в этих сценариях, например, использовать очереди событий и механизмы воспроизведения, но поскольку мы говорим о развертывании изменений в том, что используется, действительно нет дурака.
Вот как я это делаю:
Абсолютные минимальные системные требования:
1 сервер с
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
Я бы предложил сохранить старые файлы и просто перезаписать их. Таким образом, время простоя ограничено однократными перезаписываемыми файлами, и только один файл отсутствует за раз.
Не уверен, что это помогает в "веб-приложении", хотя (я думаю, вы говорите, что вы используете), поэтому мы всегда используем "веб-сайты". Кроме того, развертывание "веб-сайтов" не перезапускает ваш сайт и не отбрасывает все сеансы пользователя.