Iis вкладка сопоставление приложений

Расширение встроенного конвейера IIS

ASP.NET — Веб-сайты ASP.NET — Расширение встроенного конвейера IIS

В IIS 8 реализованы два режима обработки запросов. Первый, называемый классическим ( >IHttpHandler. Встроенный режим конвейера должен применяться по умолчанию. В этой статье будет показано, как встроенный конвейер HTTP можно расширить с помощью того же самого обработчика, который был создан в статье «Расширение конвейера HTTP».

Создание обработчика

Для простоты мы создали проект Visual Studio, который содержит только класс SimpleHandler, построенный ранее. Чтобы создать обработчик с нуля, последовательно выберите пункты New (Создать), а затем Project (Проект) из меню File (Файл) в Visual Studio. Затем укажите вариант Class Library (Библиотека класса). Назначьте проекту имя SimpleHandler. Переименуйте файл кода C# на SimplerHandler.cs и вставьте в него код, приведенный ниже. Функционирование этого кода подробно объяснялось в статье, ссылка на которую дана выше:

В меню Build (Сборка) выберите пункт Build Solution (Построить решение), чтобы скомпилировать код и создать файл DLL.

Развертывание обработчика

Найдите файл DLL, созданный Visual Studio. Он будет помещен в каталог bin\Debug или bin\Release проекта и будет называться SimpleHandler.dll. Скопируйте этот файл на сервер, поместив его в каталог bin в корневом каталоге приложения. Если каталог bin не существует, создайте его. Например, если обработчик должен применяться к приложению FileCopy, которое было ранее развернуто, файл DLL необходимо поместить в каталог C:\inetpub\wwwroot\WebsiteDeployment\FileCopy\bin.

Конфигурирование обработчика

Используя IIS Manager, выберите приложение, которое требуется изменить. В моем случае им будет ранее развернутое приложение TestAspNet расположенное в виртуальном каталоге с псевдонимом virtual. Дважды щелкните на значке Handler Mappings (Сопоставления обработчика), чтобы открыть итоговый экран Handler Mappings (Сопоставления обработчиков), показанный на рисунке ниже:

Щелкните на действии Add Managed Handler (Добавить управляемый обработчик) в правой части окна, чтобы открыть диалоговое окно Add Managed Handler (Добавление управляемого обработчика), показанное на рисунке ниже. В поле Request Path (Путь запроса) укажите запросы, которые будет обслуживать обработчик. В примере требуется, чтобы наш простой обработчик использовался только для запросов, которые заканчиваются расширением .htest. В поле Type (Тип) введите имя класса обработчика. Если для данного класса используется пространство имен, его также нужно включить в это поле:

В поле Name (Имя) введите имя, которое можно будет распознать на странице сведений обработчика. В примере обработчик получил имя SimpleHandler. Щелкнув на кнопке Request Restrictions (Ограничение запроса), можно сконфигурировать дополнительные параметры, но для данного простого обработчика они не требуются. Щелкните на кнопке OK чтобы создать сопоставление обработчика.

Тестирование обработчика

Чтобы протестировать обработчик, запросите URL-адрес, который заканчивается строкой .htest и обслуживается вашим приложением. Я использовал следующий адрес:

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

Как настроить сопоставление обработчика в каталог в IIS 6.0?

У меня IIS 7.0 на моей машине разработки и IIS 6.0 на моем сервере. На моей машине разработки я смог установить карту обработчика в каталоге на моем сайте под названием /ViewHtml/, и я сопоставил его с asp.net. В моем global.asax я проверяю запрос, отправленный в asp.net для /ViewHtml/, и я обслуживаю соответствующий html файл (html-версию файла Doc, Power Point или Excel), расположенного вне этого виртуального каталога приложений. Я делаю это так, потому что все файлы защищены защитой, мы не хотим помещать эти файлы в базу данных из-за масштабируемости, и мне нужно скрыть путь к этому файлу на сервере. Это все работает в IIS 7.0 именно так, как мне хотелось бы. Хотя я не смог настроить сервер IIS 6.0 для сопоставления всех запросов в этот каталог на asp.net.

Любые идеи? Спасибо, ребята?

Я создал веб-приложение, используя ту же конфигурацию, которую вы используете, и я также получаю 404. Я не знаю, почему она работает в IIS 7, но вот что мне нужно было сделать, чтобы исправить ее.

Создайте класс, который реализует класс System.Web.IHttpHandler. переместите код из Application_BeginRequest в вашу реализацию IHttpHandler.ProcessRequest.

Теперь вам просто нужно зарегистрировать свой обработчик HTTP с помощью ASP.NET. Для этого добавьте запись в свой Web.config в /configuration/system.web/httphandlers.

Эта запись сообщает ASP.NET обрабатывать HTTP-запросы с любым расширением и любым HTTP-методом, запустив код в вашем HTTP-hander. Обратите внимание, что я также очищаю все ранее обработанные обработчики (определенные в машине web.config).

Обратите внимание, что вам все равно потребуется сопоставление приложений, настроенное в IIS.

как добавить новое сопоставление приложений в iis

Как добавить новое сопоставление приложений в IIS с помощью vbscript?

2 ответа

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

В основном вы могли бы использовать adsutil.vbs манипулировать ScriptMaps в MetaBase.

К несчастью, adsutil.vbs не может установить отдельные элементы в свойствах LIST, таких как ScriptMaps. Вы можете только установить или удалить список в целом. Любая дополнительная обработка потребует вашего собственного кодирования.

Человек по имени Дэвид Ванг создал сценарий VB, который имеет эту возможность. Он объяснил более подробно в его запись в блоге по теме. Сценарий, который он сделал, можно скопировать оттуда. Вы также можете изменить другие свойства LIST.

Обеспечить WEB-доступ к данной странице средствами IIS по протоколу HTTP.

Установка и настройка WEB-сервера средствами IIS (информационные службы Интернет) на базе операционных систем Windows XP/2000.

Разместить на WEB-сервере HTML-код следующей страницы [Default.html] :

Hello! My name is Ivanoff Ivan Ivanovich! This is my first web server

Обеспечить WEB-доступ к данной странице средствами IIS по протоколу HTTP.

a) Произвести установку Microsoft Internet Information Server версии 4.0 если в качестве операционной системы используется Windows NT Server 4.0 или 5.0, если Windows 2000 Pro/Server или Windows XP.

b) Скопировать файл default.html в директорию на жесткий диск (к примеру: C:\Ivanoff)

c) Настроить IIS, выполнив следующие действия:

· Открыть «Диспетчер Служб Интернета», находящийся во вкладке «Администрирование» «Панели Управления»:

· Выбрать пункт «Веб-узел по умолчанию» и в свойствах указать каталог с дистрибутивом программы (к примеру C:\ Ivanoff). Другие параметры следует установить, как показано на следующем рисунке:

· По усмотрению администратора WEB-сервера доступ к программе может быть ограничен NT аутентификацией.

Для этого необходимого проделать следующие действия:

§ Открыть «Диспетчер Служб Интернета», находящийся во вкладке «Администрирование» «Панели Управления».

§ Выбрать свойства виртуального каталога куда была установлена программа.

§ открыть вкладку «Безопасность каталога» и выбрать пункт «Изменить», выставить галочки, как показано на рисунке:

При правильной установке безопасность программы будет обеспечена встроенной защитой Windows NT служб.

Как добавить новое сопоставление приложений в iis

Как добавить новое сопоставление приложений в IIS с помощью vbscript?

По сути, вы можете использовать adsutil.vbs для манипулирования ScriptMaps в MetaBase.

К сожалению, adsutil.vbs не может установить отдельные элементы в свойствах LIST, таких как ScriptMaps. Вы можете только установить или удалить список в целом. Любая дополнительная обработка потребует вашего собственного кодирования.

Человек по имени Дэвид Ванг создал сценарий VB, который имеет эту возможность. Он объяснил более подробно в своей записи в блоге на эту тему . Сценарий, который он сделал, можно скопировать оттуда. Вы также можете изменить другие свойства LIST.

Iis вкладка <сопоставление приложений>

В нашем примере будет использоваться 1C с локальной файловой базой

Установка IIS на Windows 7

Пуск — Панель управления — Программы и компоненты — Включение или отключение компонентов Windows

Выбираем необходимые компоненты: Службы IIS, ASP.NET, Консоль управления IIS и нажимаем ОК

Установка IIS на Windows Server

Установка IIS на Windows Server происходит аналогично через Добавление Ролей и компонентов

Настройка IIS под 1С

Добавление пользователя IUSR в группу IIS_IUSRS

Для настройки прав доступа необходимо добавить пользователя IUSR в группу IIS_IUSRS, иначе при попытке публикации 1С на сервер Вы будете получать ошибку

Запускаем оснастку управление компьютером Win+R -> compmgmt.msc или через меню пуск:

В оснастке выбираем: Локальные пользователи и групп -> Группы -> IIS_IUSRS открываем свойства группы двойным щелчком ЛКМ

В эту группу нам необходимо добавить пользователя IUSR, для того чтобы предоставить необходимые права доступа, для этого жмем кнопку Добавить

Набираем имя пользователя IUSR и нажимаем кнопку Проверить имена, если пользователь будет найден, то он станет подчеркнутым, нажимаем ОК. Если пользователь не находится нажмите кнопку Размещение… и смените место поиска.

Проверяем, что наш пользователь появился и жмем ОК

Настройка сайта и приложения в IIS

Запускаем Диспетчер служб IIS удобным для Вас способом, например: Win+R -> InetMgr

В левой части экрана раскрываем ветку с сайтами. Останавливаем сайт по умолчанию Default Web Site или модифицируем его, я предпочитаю делать отдельный.

Жмем ПКМ на сайты и выбираем пункт Добавить веб-сайт

Заполняем параметры сайта

Имя сайта: Любое
Физический путь: Создаем каталог где будет храниться наш сайт (файлы сайта)
Тип: Выбираем протокол HTTP или HTTPS
Порт: Задаем порт, порт может быть любой свободный. Стандартный порт для HTTP — 80, для HTTPS 443
Сертификаты SSL: Сертификаты нужны если Вы используете защищенный протокол HTTPS. Если у Вас нет сертификата для Вашего узла, можно использовать серверный самоподписанный IIS Express Development Certificate.

Проверяем, что наш сайт появился и запустился

Вместе с сайтом так же должен был создаться пул приложений с таким же названием.
Переходим выше по ветке в раздел Пулы и приложений и находим наше приложение, в данном случае 1с

Выбираем наш пул приложений 1с и нажимаем в правой части Дополнительные параметры…

В Дополнительных параметрах находим строки:
Версия среды .NET Framework — выбираем версию v.4.0+
Разрешены 32-разрядные приложения и выбираем значение True
Внимание! Если Вы будете публиковать x64 битную платформу 1С данное значение оставляем False,иначе будете получать ошибку 0x800700c1
(Эта проблема возникает из-за неверного сопоставление сценариев. Убедитесь в том, что сопоставление сценария указывает на ISAPI DLL-файл, который может обработать запрос. Чтобы сделать это, выполните следующие действия.)
Режим управляемого конвейера — выбираем значение Classic

Настройка доступа для группы IIS_IUSRS

Настройка необходимого доступа для группы IIS_IUSRS, для корректной работы нашего сайта (1с) и корректной публикации.

Для начала необходимо дать права группе IIS_IUSRS к каталогу в котором находятся (будут находиться) файлы нашего сайта. В нашем примере файлы сайта находятся в C:\inetpub\www\1c.
Переходим в каталог C:\inetpub\www\ -> нажимаем ПКМ на каталоге 1с -> в меню выбираем пункт Свойства -> переходим на вкладку Безопасность -> жмем кнопку Изменить… -> кнопку Добавить… -> в поле вписываем название группы IIS_IUSRS (при необходимости меняем место Размещения) -> нажимаем кнопку Проверить имена.

Если группа найдена она станет подчеркнутой, жмем ОК.

Далее проставляем галочки необходимых прав:

— Чтение и выполнение
— Список содержимого папки
— Чтение

Тоже самое с правами, мы делаем для каталога куда установлена 1с и каталога куда развернута наша файловая база. Если Вы используете базу SQL, то Вам НЕ нужно задавать права на каталог с базой.
Обращаем внимание, что для каталога с базой так же нужны права на запись!

Расположение файловой базы Вы можете посмотреть запустив 1С Предприятие

Публикация 1с

Запускаем 1с Предприятие -> Конфигуратор -> Администрирование -> Публикация на веб-сервере…

Выбираем каталог где будут файлы сайта и жмем Опубликовать

Проблемы при настройке веб-приложения «Форсайт. Аналитическая платформа» на ASP.NET

При возникновении проблем в работе веб-приложения «Форсайт. Аналитическая платформа» в первую очередь проверьте следующие настройки:

Откройте «Диспетчер служб IIS» и выберите корневой элемент дерева «Подключения», дважды кликните «Ограничения ISAPI и CGI»:

Для строк «ASP.NET v4.0.30319» и «Axis2 v9.2 x64» в столбце «Ограничение» должно отображаться «Разрешено»:

Если это не так, то для каждой строки откройте диалог редактирования и установите флажок «Разрешить выполнение пути расширения».

Если отсутствуют строки «ASP.NET v4.0.30319», то выполните настройку Microsoft .NET Framework 4.5.2.

Если нет строки «Axis2 v9.2 x64», значит не зарегистрировалась библиотека продукта «Форсайт. Аналитическая платформа», добавьте ее вручную:

Откройте «Диспетчер служб IIS» и для виртуального каталога BI-сервера дважды кликните «Сопоставления обработчиков»:

В открывшемся списке должна быть строка:

Если ее нет, то создайте ее вручную, как показано ниже:

Проверьте, установлен ли флажок « Для всех пользователей на компьютере » в настройках подключения к серверному репозиторию в настольном приложении «Форсайт. Аналитическая платформа».

Возможные проблемы и решения при настройке приложений под IIS

Установите поддержку статического содержания в IIS.

Для этого откройте «Диспетчер сервера», перейдите в раздел «Роли — Веб-сервер (IIS)» и нажмите на ссылку «Добавить службы роли». В открывшемся окне установите флажок «Статическое содержимое»:

Нажмите кнопку «Установить».

Установите дополнительные опции в IIS.

Для этого откройте «Диспетчер сервера», перейдите в раздел «Веб-сервер (IIS)» и нажмите на ссылку «Добавить роли и компоненты». На странице «Роли сервера» установите флажки на компонентах как указано на скриншоте:

После отметки необходимых компонентов в конце мастера установки нажмите кнопку «Установить» и дождитесь окончания установки компонентов.

При открытии веб-приложения ответ содержит «Значение не может быть пустым» при условии, что BI-сервер работает корректно.

в настройках подключения к серверному репозиторию установите переключатель « Для всех пользователей на компьютере »:

IIS подтягивает информацию о существующих репозиториях только при старте процесса. Если параметры подключения были прописаны позже, то перезапустите процесс IIS;

если первые два варианта не помогают, то проверьте, прописаны ли настройки в ветке реестра: [HKEY_LOCAL_MACHINE\SOFTWARE\Foresight\Foresight Analytics Platform\9.0 \Metabases] .

В процессе авторизации в веб-приложении возникает ошибка: HTTP 500.21 — Internal Server Error IIS 7 и WCF. Обработчик «ppService» содержит поврежденный модуль «ManagedPipelineHandler» в списке модулей.

Если работа с веб-приложением ведется на удаленном от BI-сервера компьютере, то вместо текста ошибки BI-сервера в веб-приложении может отображаться ошибка «The page cannot be displayed because an internal server error has occurred». Чтобы вместо этого текста отображался текст ошибки BI-сервера, выполните следующие настройки IIS:

Запустите диспетчер служб IIS и перейдите в раздел «Страницы ошибок».

Для строки с кодом ошибки 500 выполните команду контекстного меню «Изменить параметры».

В открывшемся окне установите переключатель «Подробные сообщения об ошибках».

В процессе авторизации в веб-приложении возвращается сообщение об ошибке « Доступ запрещен », при этом авторизация в настольном приложении проходит без ошибок.

Решение: при использовании парольной авторизации необходимо в конфигурационном файле SQLNET.ORA, расположенном по пути S\oracle\ora92\network\admin\, где S — путь до места установки Oracle, заменить SQLNET.AUTHENTICATION_SERVICES = (NTS) на SQLNET.AUTHENTICATION_SERVICES = (NONE).

Если BI-сервер и серверная часть конструктора бизнес-приложений расположены в одном домене, а обращение к серверной части осуществляется из другого домена, то может возникнуть ошибка: « Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. »

Для исправления ошибки на веб-сервере IIS выполните следующие действия:

Откройте «Диспетчер служб IIS» и в дереве подключений выберите приложение, соответствующее BI-серверу — fp BI_App_v9.2×64.

Среди доступных функций выберите «Заголовки ответов HTTP».

Добавьте следующие заголовки:

« Access-Control-Allow-Headers » со значением « content-type, accept-language, get-ppbi-time, cache-control, soapaction »;

« Access-Control-Allow-Origin » со значением « * ». Для предоставления доступа только из определённых доменов вместо «*» можно указать наименования необходимых доменов: «http://www.a.com http://www.b.com».

Перезагрузите веб-сервер IIS.

Возможные проблемы и решения при настройке приложений под Apache

Если BI-сервер и серверная часть конструктора бизнес-приложений расположены в одном домене, а обращение к серверной части осуществляется из другого домена, то может возникнуть ошибка: « Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. »

Для исправления ошибки на веб-сервере Apache выполните следующие действия:

Откройте на редактирование файл httpd.conf.

Раскомментируйте следующие строки:

LoadModule rewrite_module modules/mod_rewrite.so

LoadModule headers_module modules/mod_headers.so

В блоке . для директивы AllowOverride задайте значение All , а также внутри блока добавьте следующие строки:

Header always set Access-Control-Allow-Headers «content-type, accept-language, get-ppbi-time, cache-control, soapaction»

Header always set Access-Control-Allow-Origin «*»

Использование FastCGI для хостинга PHP приложений на IIS 7.0

Использование FastCGI для хостинга PHP приложений на IIS 7.0

Автор: Руслан Якушев

Данная статья описывает конфигурацию модулей FastCGI и PHP для хостинга PHP приложений на IIS 7.0

Важно: Данная статья содержит инструкции по установке компонента FastCGI в операционных системах Windows Server 2008 и Windows Vista SP1. Обратите внимание: на Windows Vista должен быть установлен SP1.

Содержание

• Краткий Обзор
• Включение поддержкиFastCGIвIIS7.0
  • Windows Server 2008
  • Windows Vista SP1
  • Обновление модуляFastCGI
  • Administration Pack для IIS 7.0
• Установка и настройка PHP
• НастройкаIIS7.0 для обработкиPHPзапросов
  • Используя консоль управления IIS
  • Используя командную строку
• Рекомендуемые руководства по конфигурированиюFastCGIиPHP
  • Безопасная изоляция для PHP Web сайтов
  • Режим рециркуляцииPHPпроцессов
  • Версионность PHP
  • Рекомендации по безопасностиPHP
• Конфигурирование PHP на уровне сайтов
• МодульURLrewritingдляPHPприложений
• Полезные ресурсы

Благодаря модулю FastCGI в IIS поддерживается большинство популярных приложений коллективной работы, которые используют протокол FastCGI для хостинга на Web сервере IIS высокопроизводительных и надёжных средств. FastCGI предоставляет высокопроизводительную альтернативу CGI (Common Gateway Interface), стандартного средства, являющегося интерфейсом между внешними приложениями и Web серверами, которые поддерживаются как часть возможностей IIS начиная с первых версий сервера.

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

FastCGI является более производительным по сравнению с CGI, механизм его работы выглядит так – один и тот же процесс используется для обработки множество поступивших запросов. FastCGI так же поддерживает работу с библиотеками не умеющими безопасно работать в многопоточной среде. При работе с набором повторно используемых процессов мы можем быть уверены в том, что каждый процесс будет обрабатывать не более одного запроса в каждый момент времени.

Добавьте роль CGI сервиса через меню Server Manager -> Roles -> Add Role Services. Этим мы включим поддержку двух сервисов CGI и FastCGI:

Windows Vista SP1

Добавьте расширение CGI, используя Control Panel -> Programs and Features -> Turn Windows features on or off. Этим мы включим поддержку двух сервисов CGI и FastCGI:

Важно: Установка обновлений для модуля FastCGI

Установка пакета администрирования для IIS 7.0

Примечание: Данный шаг не обязателен (опционален).

Из большого числа полезных функций административного пакета IIS 7.0 можно выделить интерфейс конфигурирования модуля FastCGI. Административный пакет может быть установлен из следующих источников:

• Административный пакет для IIS 7.0 CTP2 — x86
• Административный пакет для IIS 7.0 CTP2 — x64

Установка и настройка PHP

Рекомендуется использовать сборку non-thread safe PHP с модулем FastCGI сервера IIS 7.0. Эта сборка PHP дает значительный прирост производительности в отличие от стандартной сборки, т.к не производит проверок thread-safety, которые не требуются, так как сам FastCGI гарантирует однопоточное исполнение процессов, в окружении сервера.

1. Загрузите последнюю версию non-thread safe пакета, включая бинарные файлы, по следующей ссылке http://www.php.net/downloads.php.
2. Распакуйте файлы в директорию (например C:\PHP). Переименуйте файл php.ini-recommended в php.ini.
3. Откройте переименованный файл php.ini, уберите комментарии с нижеперечисленных строк и измените значения в соответствии с предложенными:
   • Установите fastcgi.impersonate= 1. Модуль FastCGI для IIS может исполнять роль выдачи ключей безопасности для вызовов клиента. Это позволяет IIS определять контекст безопасности для выполняемых запросов.
   • Значение cgi.fix_pathinfo=1. cgi.fix_pathinfo обеспечивает поддержку *реальных путей* PATH_INFO/PATH_TRANSLATED для CGI. В предыдущих версиях PHP значение PATH_TRANSLATED указывало на SCRIPT_FILENAME, и не затрагивало директивы PATH_INFO. Дополнительную информацию о PATH_INFO смотрите в документации cgi. Установка данного значения в 1 решает проблему задаваемых путей PHP CGI изменяя пути так чтобы они соотвествовали спецификации.
   • Установите cgi.force_redirect = 0.
   • Установите для директивы open_basedir путь к папке или сетевому ресурсу на котором расположены Web сайт(ты).
   • Директива extension_dir определяет расположение расширений для PHP. Обычно, для PHP версий 5.2.X значение для данной директивы устанавливается в extension_dir= «./ext«
   • Для включения необходимых расширений PHP уберите комментарии в файле php.ini с соответствующих строчек, к примеру:
     extension=php_mssql.dll
     extension=php_mysql.dll
4. Для проверки удачной установки PHP выполните следующую команду:

Если PHP вместе со всеми компонентами от которых он зависит был установлен корректно, то данная команда выдаст информацию о текущей конфигурации PHP.

Настройка IIS 7.0 для обработки PHP запросов

Для того чтобы приложения PHP корректно работали на IIS 7.0 необходимо настраивать привязку к запрашиваемым файлам, посредством которых IIS будет пропускать специфические PHP запросы к PHP приложениям, используя протокол FastCGI.

Прим.переводчика: при запросе клиентом файла с расширением *.php с Web сайта/сервера, расположенного на IIS 7.0, сервер будет «отдавать» обработку php файлов приложению, отвечающему за обработку php файлов.

Используя консоль управления IIS

Откройте IIS Manager и выберете “Handler Mappings” на уровне управления сервером:

Запустите “Add Module Mapping” для конфигурации, представленной на рисунке ниже:

Нажмите OK. На запрос о создании приложения FastCGI нажмите Yes.

Протестируйте корректную привязку заголовков, созданием файла phpinfo.php в папке C:\inetpub\wwwroot, используя следующий код:

Откройте браузер и перейдите по ссылке http://localhost/phpinfo.php. Если установка прошла корректно, то вы увидите стандартную страницу конфигурации PHP:

Примечание: Если Вы не видите в списке модулей «FastCgiModule», то это означает, что модуль не зарегистрирован, либо не включен. Для того, чтобы проверить, зарегистрирован ли модуль FastCGI откройте конфигурационный файл IIS по следующему адресу: %WINDIR%\windows\system32\config\applicationHost.config и проверьте присутствие значения в следующей секции:

Также, в этом же файле, убедитесь в том, что модуль FastCGI добавлен в секцию :

Используя командную строку

Альтернативой предыдущим шагам может служить использование команды appcmd.

Для создания пула приложений FastCGI выполните следующую команду:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\\php-cgi.exe’]

После этого создайте привязку заголовков:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+[name=’PHP_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\\php-cgi.exe’,resourceType=’Unspecified’]

Примечание: Если вы используете PHP версий 4.X,то вместо php-cgi.exe необходимо использовать php.exe.

Рекомендуемые руководства по конфигурированию FastCGI и PHP

Данная ссылка содержит zip архив с файлом презентаций руководств, по разворачиванию хостинга PHP приложений в среде общего хостинга .

Безопасная изоляция для PHP Web сайтов

Рекомендации по изоляции PHP Web сайтов в среде общего хостинга согласуются с общей безопасностью изоляции, рекомендованной для IIS 7.0. В особенности следует обратить внимание на следующее:

• Используйте один пул приложений на один Web сайт
• Используйте выделенный аккаунт пользователя для пула приложений
• Используйте анонимного пользователя для идентификации пула приложений
• Убедитесь в том, что реализация FastCGI включена в файле php.ini (fastcgi.impersonate=1)

Более подробно о безопасной изоляции в окружении общего хостинга написано в документации «Изолирование сайтов с пулами приложений»

Режим рециркуляции PHP процессов

Убедитесь в том, что FastCGI всегда рециркулирует (перезагружает — прим.перевод) процессы php-cgi.exe, прежде чем завершается работа основного PHP процесса. Режим рециркуляции процессов FastCGI контролируется параметром конфигурации, который называется instanceMaxRequests (максимальное кол-во запросов на экземпляр приложения — прим.перевод). Данное значение определяет, какое кол-во запросов выполнит FastCGI, прежде чем произойдёт рециркуляция. В PHP так же существует функция рециркуляции, которая контролируется параметром PHP_FCGI_MAX_REQUESTS. Установка наименьшего значения для instanceMaxRequests или подобного параметра PHP_FCGI_MAX_REQUESTS, гарантирует, что основной PHP процесс не будет закончен преждевременно.

Свойства для FastCGI могут быть изменены при помощи IIS Manager или командной строки, используя приложение appcmd.

Для настройки процесса рециркуляции FastCGI, используя IIS Manager, вам необходимо установить Административный пакет для IIS 7.0 и выбрать на уровне севера меню FastCGI settings (параметры FastCGI):

Далее необходимо выбрать приложение FastCGI, которое вы хотите настроить и нажать «Edit. » в панели Actions:

В окне «Edit FastCGI application» установите для параметра instanceMaxRequest значение 10000 нажмав кнопку обзора в меню EnvironmentVariables:

Добавьте переменную PHP_FCGI_MAX_REQUESTS,установив для неё значение в 10000:

Примечение: Если вы не установите данные значения, то по умолчанию они будут следующими: instanceMaxRequests = 200, PHP_FCGI_MAX_REQUESTS = 500 (для большинства сборок PHP).

Использование командной строки:

Для конфигурирования процессов рециркуляции FastCGI и PHP посредством appcmd, используйте следующие команды:

C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath=’c:\\php-cgi.exe’].instanceMaxRequests:10000
C:\>%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+»[fullPath=’C:\\php-cgi.exe’].environmentVariables.[name=’PHP_FCGI_MAX_REQUESTS’,value=’10000′]»

Большинство PHP приложений могут зависеть от функций или расширений доступных только в определённой версии PHP. Если такие приложения должны быть размещены на одном сервере хостинга, то необходимо чтобы на данном сервере одновременно поддерживались и работали разные версии PHP. Обработчик FastCGI в IIS 7.0 полноценно поддерживает одновременную работу различных версий PHP на одном сервере.

К примеру, допустим что на своём Web сервере вы планируете поддерживать следующие сборки: PHP 4.4.8, PHP 5.2.1 и PHP 5.2.5 non-thread safe. Для включения данной возможности вы должны положить соответствующие исполняемые файлы PHP в различные папки на файловой системе (к примеру C:\php448\, C:\php521\ и C:\php525nts) и создать соответствующие пулы приложений для каждой версии:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\php448\php.exe’]
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\php521\php-cgi.exe’]
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\php525nts\php-cgi.exe’]

Так, если у вас есть 3 Web сайта (site1, site2, site3), каждый из которых должен использовать различные версии PHP, вы можете задать соответствие заголовков для каждого из сайтов, создав соответствующий пул приложений FastCGI.

Примечание: Каждый пул приложений процессов FastCGI будет идентифицируется уникально — комбинацией полного пути и свойствами аргументов.

C:\>%windir%\system32\inetsrv\appcmd set config site1 –section:system.webServer/handlers /+”..[name=’PHP448_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php448\php.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site2 –section:system.webServer/handlers /+”..[name=’PHP521_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php521\php-cgi.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site3 –section:system.webServer/handlers /+”..[name=’PHP525nts_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php525nts\php-cgi.exe’,resourceType=’Either’]

Рекомендации по безопасности PHP

Следующие настройки могут быть использованы для улучшения безопасности установленного PHP. Следуя рекомендациям найдите и измените в файле php.ini следующие значения:

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

Определение директории, в которой процессы PHP могут читать и записывать на файловой системе.

safe_mode=Off
safe_mode_g >

Ограничение безопасного режима.

Лимит времени выполнения

Лимит на использование размеров памяти и файлов.

Настройка сообщений об ошибках и ведения логов.

Модуль FastCGI для IIS может обрабатывать запросы с ошибками, если PHP отправляет данные в stderr (стандартный поток ошибок – прим.перевод) используя протокол FastCGI. Отключение ведения логов FastCGI предотвращает отправку приложением PHP сообщений об ошибках, используя stderr, генерируя при этом ошибку с кодом 500 для клиентов.

Скрытие присутствия PHP

Конфигурирование PHP на уровне сайтов

Данная секция описывает процедуры, которые необходимы для настройки PHP на уровне сайтов. Хочется обратить внимание на то, что данная рекомендация обнародована и проверена Radney Jasmin совместно с хостинг провайдером GoDaddy.com, который официально поддерживает PHP хостинг на Windows Server 2008 посредством FastCGI.

Пулы процессов PHP на уровне сайтов

Когда каждый Web сайт имеет собственный пул приложений (это является рекомендованной практикой для IIS 7.0), появляется возможность ассоциировать выделенный пул процессов FastCGI с каждым Web сайтом. Пул приложений процессов FastCGI идентифицируется уникально — комбинацией полного пути и атрибутами аргументов. Итак, если необходимо создать несколько процессорных пулов FastCGI для некоторого исполняемого процесса, такого как php-cgi.exe,то атрибуты аргументов могут использоваться для разграничения процессорных пулов. В дополнении процессы php-cgi.exe с применением ключа командной строки «-d», могут использоваться для определения INI записи в процессе PHP. Данный ключ может быть использован для установки различных значений PHP, которые позволяют задавать уникальность аргументов для каждого пула.

К примеру, если двум Web сайтам «website1» и «website2» необходимо использовать собственные настройки PHP, то нужно изменить пул процессов FastCGI следующим образом:

В данном примере настройки PHP, в частности директива open_basedir, используются для разграничения процессорных пулов. В дополнении это заставляет PHP процесс выполняться для каждого пула процессов только в той директории, в которой расположен корневой Web сайт.

Тогда website1 может иметь сопоставление PHP заголовков, как показано ниже:

и website2 может иметь следующее сопоставление PHP заголовков:

Определение месторасположения файла php.ini

Во время запуска процесс PHP определяет месторасположение файла конфигурации php.ini используя различные настройки. В официальной документации PHP детально описан процесс инициализации (начального запуска) процесса PHP. Так, одним из мест поиска процессом PHP своего файла конфигурации (php.ini) может быть директива PHPRC (PHPRC – это переменная среда ОС, как TMP или Temp – прим.перевод). Если процесс PHP находит файл конфигурации, определённый в вышеописанной директиве, то он начинает использовать данный файл конфигурации, игнорируя путь заданный по умолчанию в файле php.ini. Данная директива полезна для пользователей хостинга, они могут применять свои собственные настройки php.ini на уровне своих сайтов.

К примеру, существует два Web сайта: website1 и website2; расположенных по следующим путям C:\WebSites\website1 и C:\WebSites\website2, тогда пул процессов php-cgi.exe в секции файла applicationHost.config должен иметь следующий вид:

В данном случае WebSite1 имеет свои настройки php.ini файла, который расположен в директории C:\WebSites\website1, тогда как WebSite2 имеет свои настройки файла php.ini, который расположен в директории C:\WebSites\website2. Данная конфигурация так же предполагает что значение PHPRC не задано, иначе сделать уникальные установки файла php.ini на уровне сайтов не представляется возможным.

Большинство популярных PHP приложений используют функциональность URL rewriting на Web серверах, которая предоставляет отображение дружественных ссылок и более корректное предоставление информации для поисковых машин (ссылки вида http://site.name/page123,а не http://site.name/mod_content/page.php=id123&disp — прим.перевод). В IIS 7.0 поддержка URL rewriting (перезапись ссылок) поддерживается посредством модуля URL rewrite.

В следующих статьях представлено подробное описание данного модуля:

• Работа с модулем Microsoft URL Rewrite. Описывается метод настройки модуля URL Rewrite.
• Детальное описание конфигурации модуля Microsoft URL Rewrite. Описывается функционал данного модуля и возможность всех опций.
• Настройка популярных PHP приложений совместно с модулем URL Rewrite:
  • WordPress
  • MediaWiki
  • b2Evolution
  • Mambo
  • Drupal

Основы архитектуры IIS, или запросопровод для ASP.NET

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

1. Общий план
2. Крупный план
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Пул приложений
2.5. Домен приложения, приложение
3. Что дальше?
Источники

1. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.
8. HTTP.SYS отправляет ответ браузеру.

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

2. Крупный план

2.1. HTTP.SYS

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.

Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

• Администрирование драйвера HTTP.sys.
• Управление рабочими процессами.
• Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с .NET Framework и интегрированные с IIS:

• NetTcpActivator для протокола TCP;
• NetPipeActivator для Named Pipes;
• NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

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

• Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
• Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
• Исполняемый файл w3wp.exe – шаблон рабочего процесса.
• Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
• Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

Ниже на рисунке представлен пример схемы компонентов внутри некоего экземпляра рабочего процесса приложения. Когда служба WAS запускает рабочий процесс, она загружает в него согласно конфигурации приложения требуемые обработчики протоколов процессов (PPH) и посредством менеджера приложений создаёт внутри рабочего процесса домен приложения, в котором будет хоститься приложение. Менеджер приложений загружает код приложения в домен приложения и требуемые обработчики протоколов уровня приложения (ADPH) для обработки сообщений по соответствующим сетевым протоколам.

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).

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

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

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс My >
Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

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

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Руководство по техническому обслуживанию

Настройка веб-сервиса для IIS

1. Установка IIS выполняется стандартными средствами. Необходимо установить следующие компоненты:

Web Management Tools:

• IIS 6 Scripting Tools

• IIS 6 WMI Compatibility

• IIS Metabase and IIS configuration compatibility

• IIS Management Console

• IIS Management Scripts and Tools

World Wide Web Services:

• Static Content Compression

Набор достаточных компонент приведен на скриншоте ниже.

Набор достаточных компонент IIS.

2. Если при установке платформы «1С:Предприятие» не были установлены компоненты работы с веб-сервером, их надо установить (через установку платформы):

Элементы платформы «1С:Предприятие», которые должны быть установлены.

Далее от имени администратора зайдите в «Конфигуратор» — «Администрирование» — «Публикация на веб-сервере. «. Укажите имя базы в поле «Имя». (используйте только буквы латинсого алфавита). Выберите пустой каталог (путь к нему также не должен содержать кириллических символов, см. пример ниже). Включите флажок «Публиковать Web-сервисы», в списке веб-сервисов включите флажок у сервиса » rg1CTCService «. Нажмите Опубликовать .

Публикация веб-сервиса «Первой Формы».

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

3. Укажите права для обработчика веб-сервисов «1С:Предприятие» . Права на запуск (Execute) модулей добавляются для группы IIS_IUSRS на папку . 1cv81\BIN\

Права на выполнение для обработчика веб-сервисов «1С:Предприятие».

4. Если база «1С:Предприятие» файловая, добавьте права на изменение (Modify) на папку и подпапки базы для той же группы.

Права на изменение для обработчика веб-сервисов «1С:Предприятие».

5. В консоли IIS щелкните правой кнопкой мыши на строку с созданной папкой. Преобразуйте её в приложение.

Преобразование сервиса в приложение.

6. Добавьте MIME типы для приложения «1С:Предприятие» . Сделать это можно для сервера, для сайта или для папки (наследование присутствует).

Добавление типов MIME.

7. Добавьте настройки для обработки файлов «1С:Предприятие». На вкладке Handler Mappings добавьте скрипты (не скрипты со звездочкой) для каждого расширения -«*.1cws» и «*.1crs». Для этого последовательно выберите каждую строку, в которой указано одно из нужных расширений, затем справа в разделе «Actions» нажмите «Add Script Map…».

В открывшемся окне нажмите кнопку Request Restrictions . Во втором открывшемся окне

• перейдите на вкладку «Access» и выберите тип доступа «Execute». Имя правила можно задать любое.

Настройка типа доступа Executive.

• там же перейдите на вкладку «Mapping» и отключите флажок «Invoke handler only if request is mapped to»

Настройка вызова обработчика .

Альтернативой является добавление обработчика из командной строки:

C:\>cscript C:\inetpub\AdminScripts\adsutil.vbs SET /W3SVC/1/ROOT/MyApp/ScriptMaps «.1cws,с:\Program Files\1cv81\Bin\wsisapi.dll,5» «.1crs,

На экране отобразится текст:

Microsoft (R) Windows Script Host Version 5.8

Copyright (C) Microsoft Corporation. All rights reserved.

ScriptMaps: (LIST) «.1cws,с:\Program Files\1cv81\Bin\wsisapi.dll,5» «.1crs,с:\Program Files\1cv81\Bin\wsisapi.dll,5»

Важно указать правильный путь: /W3SVC/1/ROOT/MyApp/ScriptMaps

8 . Для обработчиков укажите дополнительные параметры: выберите действие «Edit Feature Permissions» и в открывшемся окне установите флажки запуска скриптов и приложений, как на скриншоте ниже:

Настройка запуска скриптов и приложений.

9. Проверьте наличие обработчика веб-сервисов «1С:Предприятие» на вкладке ISAPI and CGI Restrictions для сервера.

Проверка наличия обработчика web-сервисов «1С:Предприятие».

Если установка идет в 64-разрядном окружении, то для обработчика включите режим Alpplication Pool -> DefaultAppPool -> Enable 32-bit Application -> True .

Настройки для 64-разрядного окружения.

10. Перейдите по ссылке:

Например, для примера на скриншоте выше адрес будет выглядеть следующим образом: http://ip/BP/ws/1CTCService.1cws?wsdl

11. Анонимная аутентификация на IIS и доступ к базе

В случае неудачной настройки доступа нужно создать пользователя вручную:

• Создать пользователя на компьютере (сервере) с IIS и указать ему пароль. Ни в какие группы не добавлять.

• В консоли IIS. Имя_сервера -> Autentification -> AnonymousAutentification -> Edit -> Set -> User name -> Password -> Confirm password.

Если используется аутентификация «1С:Предприятие» : создайте пользователя с именем, которое создано на компьютере и введено в IIS. Задайте пароль и поставьте флаг «Аутентификация 1С:Предприятия».

Если используется Windows аутентификация : создайте пользователя с неким именем (лучше не использовать имя, которое создано на компьютере и введено в IIS). Установите флаг «Аутентификация Windows».

Выберите или введите пользователя в формате \\имя_компьютера\имя_пользователя . Флаг «Аутентификация 1С:Предприятия» в этом случае лучше снять.