Каковы возможные недостатки сайта IIS 7, имеющего соединение NTFS в качестве веб-корня?


13

Я пытаюсь найти способ развертывания кода ASP.NET с минимальным нарушением работы сайта. Одна мысль состояла в том, чтобы настроить сайт для обслуживания с узла NTFS, c:\www\example.comгде

c:\www\example.com -> c:\www\example.com_r1234

Затем, когда новый код развернут, он копируется c:\www\site.com_r1235и узел перенаправляется на

c:\www\example.com -> c:\www\example.com_r1235

Итак, мой вопрос: как это может повлиять на текущие запросы в IIS? Какие еще недостатки это может иметь с точки зрения реакции IIS на изменение (если есть)? Будет ли это так же легко для конечного пользователя сайта, как я надеюсь?

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

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


1
Сброс веб-корня. Любая переработка (не думаю, что это произойдет) и перезапуск пула приложений в таком случае а), вероятно, не являются "ненужными", и б) помогают рабочему процессу сохранять реалистичное представление о состоянии его содержимого и кэшей. Это умное решение, конечно, но умное редко означает стабильность. Узнайте, что делает большинство людей, затем сделайте это.
TristanK

Это отличный вопрос, я долго искал ответ на него. Все, что я когда-либо видел, это либо развертывание по мере развертывания под балансировщиком нагрузки (которого у меня нет), либо простое копирование / svn файлов в веб-корень (что мне не нравится).
Jayrdub

1
Итак, попробуйте сначала перенастроить веб-корень.
TristanK

Ответы:


3

способ развертывания кода ASP.NET с минимальным нарушением работы сайта.

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

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


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

1
«Дополнительная работа и задействованные сценарии» не являются проблемой, мы полностью автоматизированы
jayrdub

Думаю, честно, беспокойство и требуемая работа - это не одно и то же
Марк Хендерсон

Беспокойство конечного пользователя моего сайта - это то, на что я
ссылаюсь

2

Я создал папку позади моего веб-корня с именем _images

C:\DEV\_IMAGES

затем скопировал в него кучу gif-файлов. Затем я создал символическую ссылку NTFS в моем корне, используя

C:\DEV\PROJECT\ROOT mklink /D webimages ..\_images

В Visual studio 2010 я «Показать все файлы» затем обновляю… и включаю новые «изображения» в свой проект. Теперь я могу указать на ...

img src='webimages/icon.gif'

Когда я запускаю приложение, оно прекрасно работает и на моей локальной машине.

Я не буду знать, работает ли он на реальном сервере (IIS 7), пока инфраструктура не справится с этим, кто-нибудь знает какие-либо вопросы о том, почему это не будет работать в производстве?

Я чувствую, что права есть, и если да, то какой отличный способ упростить общий доступ к папкам (всех типов) между веб-приложениями.

Я еще не пытался выразить это в TFS, поэтому, если у кого-то есть отзывы по этому поводу, дайте нам знать!


0

Это не будет работать, потому что IIS может подумать, что web.config изменился другой программой. IIS, вероятно, будет выдавать исключение System.Configuration.ConfigurationErrorsException. Я бы предложил написать какой-нибудь скрипт, чтобы просто поменять домашний каталог сайта.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.