Подтвердить что ты не робот

Публикация сайта ASP.NET MVC2 с помощью Web Deploy

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

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

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

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

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

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

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

Edit:

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

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

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

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

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

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

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

Изменить # 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 из окна dev в серверную коробку! У меня уже был настроен ACL на сервере.

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

BTW. Возможно, вы также захотите добавить, какая у вас латентность между ПК и сервером, и как долго это обычно требуется для переноса файла с 15 МБ через HTTP.

Ответ 2

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

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

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

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

НТН, -eric

Ответ 3

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

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

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

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

  • Публикация веб-сайта (или использование файлов с сервера отчетов, что имеет наибольшее значение в вашем случае)
  • Создайте script список файлов для modifiy (перевод файлов кода в их DLL)
  • Используйте ftp, который можно управлять через командную строку, чтобы внести изменения.

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

  • У меня есть крючок на teamcity, и каждый раз, когда я делаю фиксацию с помощью svn, он использует файл rakefile для копирования файлов в папку Dropbox, где у меня также есть репозиторий git.
  • Сделайте фиксацию/нажатие для файлов, которые были изменены (для этого репозитория git). У меня также установлен Dropbox на сервере
  • Извлеките изменения из Dropbox (с помощью git) в промежуточное приложение, чтобы проверить что-то еще.
  • Как только все будет в порядке для промежуточного приложения, я переключу его с производственной версией из iis
  • Когда я хочу опубликовать снова, как только все будет синхронизировано с Dropbox, я снова сделаю попытку, в предыдущем выпуске, который теперь становится промежуточным, и я снова переключаю приложения.

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

ПРЕДУПРЕЖДЕНИЕ: ЭТО НЕ ИСПЫТАЕТСЯ МЕНЯ, ТОЛЬКО ГИПОТЕТИЧЕСКИЙ ОТВЕТ

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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