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