Повторное развертывание сайта ASP.NET в IIS7 без использования используемых файлов. - PullRequest
8 голосов
/ 12 марта 2010

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

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

Мне интересно, есть ли у кого-нибудь обходной или альтернативный подход к этому, о котором я даже не думал. В настоящее время мои идеи:

  1. Просто повторите каждый файл, пока он не заработает. Это приведет к ошибкам в течение короткого времени, хотя это и не так хорошо.
  2. Развертывание в новой папке и обновление webroot IIS в новой папке. Я не уверен, как это сделать, за исключением запуска приложения от имени администратора и запуска командных файлов, что очень неопрятно.

Кто-нибудь знает, каков наилучший способ сделать это, или если это возможно сделать # 2, не запуская приложение публикации как пользователь с правами администратора (готов предоставить ему специальные привилегии, но я бы предпочел прекратить если не считать администратора)?

Редактировать
Разъяснение инфраструктуры ... У нас есть 2 веб-сервера IIS 7 в NLB, которые запускают свои веб-корни с общего NAS (чтобы быть более понятным, они используют точно такой же веб-корень на NAS). Мы выполняем много развертываний, так что любой подход, который мы не можем автоматизировать, не будет жизнеспособным.

Ответы [ 6 ]

12 голосов
/ 12 марта 2010

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

ASP.NET имеет функцию , предназначенную именно для этого сценария . По сути, это сводится к временному созданию файла с именем App_Offline.htm в корне вашего веб-приложения. Как только файл появится, IIS отключит рабочий процесс для вашего приложения и выгрузит все используемые файлы. После того как вы скопируете свои файлы, вы можете удалить файл App_Offline.htm, и IIS с радостью снова начнет сбивать.

Обратите внимание, что пока этот файл существует, IIS будет использовать его содержимое в качестве ответа на любые запросы к вашему веб-приложению. Так что будьте осторожны с тем, что вы положили в файл. : -)

2 голосов
/ 18 марта 2010

Другим решением является программное администрирование IIS.

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

Однако требуется некоторая настройка разрешений ...

Вы можете сделать это через ADSI или WMI для IIS 6 или Microsoft.Web.Administration для IIS 7.

О вашем 2. обратите внимание, что WMI не требует прав администратора, как ADSI. Вы можете настроить права по объектам. Проверьте консоль WMI (mmc).

1 голос
/ 19 марта 2010

Поскольку вы уже распределяете нагрузку между двумя веб-серверами, вы можете:

  1. В балансировщике нагрузки переведите веб-сервер A в автономный режим, поэтому используется только веб-сервер B.
  2. Разверните обновленный сайт на веб-сервере A.
  3. (В качестве бонуса вы можете выполнить дополнительный тестовый тест на веб-сервере A, прежде чем он будет запущен в производство.)
  4. В балансировщике нагрузки переведите B в автономный режим и переведите A в оперативный режим, поэтому используется только веб-сервер A.
  5. Развернуть обновленный сайт на веб-сервере B.
  6. (В качестве бонуса вы можете сделать дополнительный тестовый проход на веб-сервере B, прежде чем он будет запущен в производство.)
  7. В балансировщике нагрузки верните B в оперативный режим. Теперь оба веб-сервера обновлены и снова используются в производстве.
  8. Элемент списка
0 голосов
/ 15 декабря 2010

У нас был тот же сервер (2003) и та же проблема.Некоторые библиотеки DLL были заблокированы, и размещение App_Offline.htm в корне веб-сайта сделало нас неуместными.

Решение:

Права доступа к файлам!

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

Мы предоставили пользователям Network Service и IIS_WPG доступ на чтение / запись ко всему корневому веб-каталогу, что позволило решить проблемы с используемым файлом, файлом заблокированным, тайм-аутом и отказом в доступе.

0 голосов
/ 16 марта 2010

Если вы вручную не открываете дескриптор файла на своем веб-сервере, IIS не будет блокировать ваши файлы.

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

  • Поиск Windows
  • Поиск Google Desktop
  • Windows Backup
  • любое другое антивирусное или индексное программное обеспечение
0 голосов
/ 12 марта 2010

Вы также можете попытаться изменить временную метку web.config в корневой папке перед попыткой скопировать файлы. Это позволит выгрузить приложение и освободить использованные файлы.

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