Публикация сайта ASP.NET MVC2 с помощью веб-развертывания

Question

В настоящее время я использую Web Deploy, http://learn.iis.net/page.aspx/346/web-deploy/ для публикации моего приложения MVC2.Раньше он работал хорошо, но теперь дошел до того, что я не могу продолжать его использовать:

Когда приложение MVC было маленьким и имело всего несколько пользователей, его было легко опубликовать.Просто щелкните правой кнопкой мыши проект в Visual Studio и выберите «Опубликовать».И поскольку было всего несколько пользователей, было легко найти время, когда никто не использовал сайт для быстрого обновления.

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

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

Затем действие «Опубликовать» начиналось по тайм-ауту каждый раз, и мне пришлось переключиться на ручное развертывание в соответствии с этим ранее оставшимся без ответа вопросом: Visual Studio 2010 - время веб-развертывания - что делать?

Теперь ручное развертывание занимает все больше и больше, от 5 до 20 минут.И количество пользователей значительно выросло, поэтому развертывание всегда влияет на кого-либо (медленное время отклика, время ожидания, сайт недоступен и т. Д.)

Так что я могу сделать?Есть ли лучшая альтернатива использованию веб-развертывания?

Редактировать:

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

Еще несколько вопросов, которые могут привести к решению:

• Почему это займет так много времени, когда тольконесколько файлов было изменено?
• Почему zip-код для веб-развертывания всегда включает в себя всю кодовую базу, а не только измененные файлы?
• Почему я не могу просто вручную скопировать измененные файлы и пропуститьвесь веб развернуть?Но трудно вручную определить, какие файлы изменились.Я использую SVN - есть ли способ выводить только файлы, которые изменились между двумя ветвями?
• Какие еще вопросы я должен задать, но еще не подумал?

В ответ на ответы:

Re: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html Это именно то, как я делал развертывание, и это был бы идеальный метод.Веб-развертывание правильно определяет, какие файлы были изменены, однако время ожидания истекло, и публикация не происходит.В решении около 2500 файлов, возможно, потребуется слишком много времени, чтобы определить, какие из них изменены?Или может случиться так, что публикация имеет короткое время ожидания, и просто загрузка 15-мегабайтного zip-файла использует все это время.

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

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

Edit # 2

Мне удалось сузить его и найти именно там, где это медленно - но не почему.Это из журнала развертывания:

[9/02/2011 12:11:56 a.m.] Performing synchronization pass #1.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/1' is applicable to 'iisApp/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'Add write permission to App_Data Folder/1' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data' because of its scope.
[9/02/2011 12:11:56 a.m.] Source createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True']). Update pending.
[9/02/2011 12:11:56 a.m.] Update operation on createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) skipped because of rule CreateApplicationRule.
[9/02/2011 12:11:56 a.m.] Source filePath (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data\Create.sql) does not match destination (Default Web Site/virtual-dir/App_Data\Create.sql) differing in attributes (size['259691','259697'],lastWriteTime['02/08/2011 10:45:20','02/06/2011 03:48:16']). Update pending.

[400 lines of file updates skipped, time expired 2 seconds ....]

[9/02/2011 12:11:58 a.m.] Delete operation on filePath (Default Web Site/v2/zzz_app_offline.htm) skipped because of rule DoNotDeleteRule.
[9/02/2011 12:11:58 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:11:58 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:13:47 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:13:47 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:17:11 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data) does not match destination (Default Web Site/virtual-dir//App_Data) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:17:11 a.m.] Updating setAcl (Default Web Site/virtual-dir//App_Data).
[9/02/2011 12:17:11 a.m.] The dependency check 'DependencyCheckInUse' found no issues.
[9/02/2011 12:17:11 a.m.] The synchronization completed in 1 pass(es).

Причиной замедления является "Updating setAcl" компонент.Я изучаю списки ACL блока разработки и блока сервера, чтобы увидеть, что отличается.Однако кажется, что копировать ACL из коробки разработчика в коробку с сервером кажется крайне плохой идеей!Я уже настроил ACL на сервере.

Answer 1

@ JK из предоставленной вами информации, похоже на проблему тайм-аута. Я согласен с @TroyHunt 2500 файлов в 15 мегабайтах должны делплои быстро. В частности, выходные данные показывают задержку при применении ACL (нужно ли их менять). Если бы это был я, я бы начал делать некоторые проверки работоспособности без веб-развертывания. Несколько мыслей приходят на ум

• находятся ли веб-серверы в домене или рабочей группе?
• что показывает dcdiag?
• что показывает netdiag
• являются ли ящики для разработчиков и ящики для продуктов в одном домене?

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

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

НТН, -eric

Answer 2

Я бы начал с попытки определить, где происходит тайм-аут.Вы упомянули 15-мегабайтный zip-архив с 2500 файлами, что не кажется мне особенно большим.Вы пытались создать пакет развертывания в Visual Studio и запустить его непосредственно на сервере?Это исключит сетевую задержку из картинки, которая является довольно фундаментальной переменной, когда речь идет о тайм-аутах.

Что касается необходимости загрузки zip-файла со всем приложением, вам необходимо запомнить фактическую идентификацию того, чтоизменилось, и последующее развертывание в IIS все происходит на сервере.Это не Visual Studio или msdeploy на вашем локальном компьютере, вызывающие снимки на этом.

Что касается того, почему вы не просто копируете измененные файлы вручную, это кратко изложено в моем сообщении в блоге, на которое вы ссылались, но вкратцетрудоемко и подвержено ошибкам.Это означает, что вам нужно сознательно проработать мыслительный процесс «какой из моих 2500 файлов только что изменился», а не просто сказать «заставить мой целевой сайт соответствовать моей версии разработки».Вы не упомянули, публикуете ли вы web.config или нет, но очевидно, что преобразования конфигурации являются еще одной важной причиной, по которой простой подход CTRL-C, а затем CTRL-V является громоздким.

Попытка просто внести изменениянапрямую из SVN тоже рискованно.Ваша первая проблема - вы должны быть полностью уверены в целостности и точности редакции, которую вы обновляете с , если вы хотите опубликовать соответствующие изменения.Затем вы пытаетесь синхронизировать их с целью, и вы возвращаетесь к тем же проблемам, что и в предыдущем абзаце.Другая большая проблема заключается в том, что управление версиями объектного кода всегда неприятно;вы будете находиться в постоянном конфликте с кем-либо еще в проекте, и VCS просто не предназначен для такой работы.

Мой совет будет сосредоточиться на устранении основной причины проблемы - Web Deployвремя ожидания, а не просто пытаться обойти симптомы.Публикация только изменений вручную или работа с привязками IIS только создаст для вас больше проблем в долгосрочной перспективе и намного больше работы в ближайшей перспективе.Посмотрите, как вы делитесь результатами создания пакета, копируете его на сервер, затем выполняете его локально, и мы возьмем его оттуда.После того, как вы настроите его так, как задумано, вы должны увидеть развертывания не более нескольких минут, а время простоя сайта должно измеряться в секундах.

Кстати: вам также может понадобиться добавить тип задержки между вашим ПК исервер и сколько времени обычно требуется для передачи 15 МБ файла по HTTP.

Answer 3

У меня просто была похожая проблема, когда webdeploy начал занимать очень много времени, особенно когда он доходил до "Updating setAcl". Я не хотел отключать обновление ACL, как было предложено в некоторых предыдущих ответах, особенно, когда оно работало нормально при развертывании того же проекта на другом сервере.

Итак, я посмотрел на различия между двумя целевыми машинами, и решение было довольно очевидным в ретроспективе. На производственной машине у нас было много временных локальных файлов, которые создавались и хранились в течение месяца (проектно). Я уменьшил количество файлов, и время публикации увеличилось с 30 минут до 15 секунд.

Answer 4

Вот как я делаю публикацию:

1. У меня есть команда teamcity, и каждый раз, когда я делаю коммит с svn, он использует rakefile для копирования файлов в папку dropbox, где у меня также есть git-репозиторий.
2. Сделайте коммит / push для файлов, которые были изменены (для этого git-репозитория). У меня также есть Dropbox, установленный на сервере
3. Перетащите изменения из Dropbox (с Git) в промежуточное приложение, чтобы проверить вещи снова.
4. Когда все готово для промежуточного приложения, я переключаю его на производственное приложение из iis
5. Когда я хочу снова опубликовать, как только все синхронизируется с Dropbox, я снова выполняю извлечение на предыдущей постановке, которая теперь становится промежуточной, и я снова переключаю приложения.

Результат-> Пользователи получают 0 секунд простоя.

Если вы хотите сократить некоторые углы. Вы можете сделать git pull прямо на производственной площадке. Результат-> 1 2 секунды простоя для пользователей

Если вы действительно хотите обрезать углы. Вы можете установить папку Dropbox прямо в рабочую папку, и Dropbox будет синхронизировать все. Результат 5 6 или более секунд простоя для пользователей.

Answer 5

Некоторые другие параметры, которые вы могли бы рассмотреть:

1) Развертывание в новый каталог каждый раз, а затем переключение между каталогами с использованием IIS.

2) Использование отдельного репозитория Subversion для ваших двоичных файлов.svn-load-dirs.pl может загружать двоичные файлы в Subversion и может правильно отмечать файлы, которые были добавлены, удалены или изменены.Вы можете запустить svn load-dirs в конце вашего автоматизированного процесса сборки.Процесс сборки - это единственная «пользовательская» проверка в этом хранилище, а производственный сервер - единственное место, где он проверяется, поэтому нет конфликтов версий.

Для развертывания вы просто svn обновляете рабочий каталог из бинарной подрывной деятельности.репозиторий.Он эффективно копирует только измененные файлы атомарным способом (то есть, если загрузка не удалась, он не заменяет никакие файлы).Если вы обнаружите проблему сразу после развертывания, вы можете быстро вернуться к предыдущей версии.Если вы хотите обновить один файл aspx, вы можете выполнить целевое обновление svn для этого отдельного файла.

Если у вас установлен TortoiseSVN на сервере, вы также можете сразу увидеть, изменил ли кто-нибудь какие-либо файлы на сервере безпроходя правильный путь build-> checkin-> deploy.

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

Еще один плюс в том, что у вас есть полная запись каждой развернутой версии.

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

Answer 6

Если у вас есть контроль над сервером, то действительно хорошим вариантом является загрузка zip-файла вручную.Разархивируйте его, а затем используйте диспетчер IIS, чтобы указать на новую кодовую базу.Таким образом, время простоя должно быть минимальным.И если что-то пойдет не так, у вас будет последняя версия без изменений, и вы можете просто снова указать IIS на эту папку.

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

В любом случае, похоже, что веб-развертывание должно поддерживать отправку только измененного контента.Но я думаю, что в этом случае вам необходимо поддерживать Web-развертывание: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html

Если у вас его нет, я думаю, вы могли бы использовать скрипт для обнаружения изменений в SVN.Вот некоторая информация о том, как найти измененные файлы: http://blog.lysender.com/2010/11/svn-list-modified-files-between-revisions/ Вы должны помнить, что файлы кода скомпилированы в файлы dll, поэтому я мог бы представить что-то вроде этого:

1. Опубликовать сайт(Или используйте файлы с промежуточного сервера в зависимости от того, что наиболее целесообразно в вашем случае)
2. Сценарий должен создать список файлов для изменения (перевод файлов кода в их dll)
3. Использование ftpэтим можно управлять через командную строку, чтобы выдвинуть изменения.

Answer 7

Почему бы не использовать Dropbox ?!Серьезно ....

ВНИМАНИЕ: ЭТО НЕ ПРОПИСАЛ МНЕ, ПРОСТО ГИПОТЕТИЧЕСКИЙ ОТВЕТ

Решение 1: В не-Профессионально, я бы установил Dropbox на всех серверах, включая промежуточный сервер.И только веб-развертывание из Visual Studio до подготовки.

Dropbox очень быстро синхронизирует файлы, особенно когда вы включаете «Сетевую загрузку», когда файлы загружаются с локальных серверов, а не из Dropbox!

Решение 2: Создайте пакет развертывания из Visual Studio и сохраните его в локальной папке, которая синхронизируется с Dropbox.Затем создайте запланированную задачу, которая автоматически запускает deploy.cmd и очищает содержимое папки развертывания, чтобы избежать повторного развертывания снова и снова.

Проблемы с использованием Dropbox

• ACL не будет синхронизироваться: (
• Сеанс удаленного рабочего стола всегда должен быть активным, так как Dropbox запускается в трее (не в службе)
• Папки не должны содержать никаких "data "файлы, которые изменяются или возникают конфликты

Answer 8

Проблема в том, что вы развертываете с VS, а не с сервера сборки / непрерывной интеграции.

Answer 9

В окне build / dev используйте командную строку MSBuild для создания SLN проекта (или wdproj). Убедитесь, что все предварительно скомпилировано. Используйте отдельный выходной путь, который вы очищаете перед сборкой. Получите результаты в архиве и перенесите их на веб-сервер вне диапазона (через UNC-путь, FTP-сервер или любой другой). На сервере разархивируйте и выполните развертывание xcopy.

Чтобы минимизировать время передачи, используйте rsync (есть версии для Windows) или используйте 7-zip с максимальными настройками для сжатия двоичных файлов.

Время простоя сервера сведено к минимуму, так как это будет только копирование с локального диска на локальный диск. Несмотря на то, что это быстро, пул приложений IIS будет перезагружен, чтобы восполнить это, вам потребуется две машины за балансировщиком нагрузки, чтобы вы могли обновить одну, пока другая обслуживает запросы. (Может быть, излишне, исследовать, используя веб-сады IIS)

Чтобы автоматизировать процесс, используйте Powershell или, возможно, даже проще, с пакетными файлами и PSExec для запуска удаленных команд.