Случайные ошибки 401 на автоматически скомпилированном сайте asp.net при нажатии обновленных страниц - PullRequest
2 голосов
/ 22 февраля 2012

У нас есть веб-сайт asp.net, который развернут на нескольких серверах IIS. Сайт компилируется по требованию, а не скомпилированным веб-приложением.

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

Единственный способ исправить это - снова развернуть ту же страницу.

Списки ACL отлично выглядят для самих файлов, поэтому предполагается, что при перекомпиляции конкретной страницы возникает проблема с блокировкой файлов в папке Temporary ASP.NET Files.

Кто-нибудь видел это раньше или есть предложения, как этого избежать?

Примечание: похоже, что это произошло только после того, как мы перешли на .net 4.0

Насколько я могу судить, мы получаем 401.3 Отклонено ресурсным ACL http://support.microsoft.com/kb/907273 Но я не смог подтвердить это.

Ответы [ 4 ]

1 голос
/ 26 апреля 2012

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

Мы применяем стратегию Blue / Green развертывания на 4-уровневой архитектуре, в которой веб-сайт имеет более 4 серверов на верхнем уровне. Из-за сложности архитектуры, представленной для развертываний, нам был необходим способ развертывания, не мешающий трафику на «живой» сайт. Следуя совету Фаулера, но не совсем так, мы пришли к решению, которое означает, что у нас есть 2 сайта на каждом сервере (синий и зеленый, или в нашем случае сайт A и сайт B). Живой сайт имеет соответствующий заголовок хоста, и после того, как мы развернем и протестируем его на не-живом сайте, мы перевернем заголовки двух сайтов, чтобы то, что когда-то было живым, теперь было не живым сайтом, и наоборот. , Результатом является надежное развертывание, которое может быть выполнено за часы и с высочайшим уровнем достоверности.

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

0 голосов
/ 08 мая 2012

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

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

0 голосов
/ 02 мая 2012

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

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

На моей работе мы пишем сценарии Power Shell для развертывания веб-сайтов. Сценарий powers shell создает новый каталог с отметкой времени, копирует туда новое развертывание, а затем сообщает IIS указать веб-сайту новый каталог (оставив старые каталоги «потерянными», но все еще находящиеся там).

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

Этот метод работает хорошо, потому что вы никогда не пишете поверх файла, когда он используется. Однако это все равно приводит к нулевому времени простоя. Единственный эффект, который вы увидите, - это обычное «прогревание» .net, которое происходит каждый раз, когда вы меняете код или сборки.

0 голосов
/ 30 апреля 2012

При развертывании на сервере я отключаю сайт на минуту (или сколько бы времени ни занимало развертывание) - в любом случае он может быть недоступен в течение этого времени, поскольку страницы перекомпилируются, поэтому это не слишком много для хита.Вы можете сделать это, создав файл в корневом каталоге приложения с именем app_offline.aspx (его длина должна быть не менее 512 символов). После создания этого файла вы можете скопировать ресурсы из папки, зная, что проблем с блокировкой не будет.,затем, когда копия будет завершена, удалите файл app_offline.

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