Как установит internet information service. Windows Server

Что, если нам понадобилось развернуть веб сайт на компьютере или виртуальной машине под управлением ОС windows? Конечно можно воспользоваться сторонними программными продуктами такими как:

  • Apache — популярный веб сервер с огромным кол-вом фунций, изначально был написан под Linux, на данный момент имеется редакция под Windows.
  • Endels — Новый веб сервер для локального тестирования, для веб разработки.
  • Denwer — Пакет для разработчика, веб сервер с PHP 5.3.13, MySQL 5.1, PostgreSQL 8.4 etc.

Скачать их просто с интернета, дальше конфигурация у каждого своя. Но что делать если наш ПК не имеет выход в интернет и нам нужно развернуть простенький сайт на html без заморочек. Можно воспользоваться встроенным IIS в Windows 7 .

В данной статье мы рассмотрим процесс установки IIS на Windows 7 и запуск обычного веб сайта.

Заходим пуск\панель управления

После этого слева нажимаем кнопку «включение или отключение компонентов Windows «. Отмечаем галочкой службы IIS и дальше можно выбрать необходимые компоненты. Можете выбрать все далее по ситуации вы сможете удалить ненужные.

Ждем пока пройдет установка.

После этого проверяем, что наш сайт открывается. Набираем в строке браузера http://localhost (напоминаю localhost — это адрес локальной машины, он соответствует IP 127.0.0.1 и создан для тестов)

Что зайти в консоль управления сайтом, нужно зайти пуск панель управления\администрирование\Диспетчер служб IIS

Тут вы можете установить настройки по своему усмотрению. По умолчанию IIS использует каталог «C:\inetpub\wwwroot » для размещение стандартного сайта. Через диспетчер служб IIS вы можете создать новый сайт или использовать уже имеющийся заменив файлы в папке на свои.

Посмотреть раздел посвященный

Продолжаем изучать web сервера и сегодня мы рассмотрим установку и основные настройки Internet Information Services (IIS) версии 7.0 на платформе Windows Server 2008. А также научимся привязывать такие отдельные технологии как PHP к нашему web серверу.

Как Вы знаете, PHP отлично работает с Apache и MySql, но вдруг у Вас возникла необходимость использовать именно IIS в связке с PHP, то тогда данная статья именно для Вас. Сегодня мы рассмотрим основы IIS 7.0, научимся устанавливать данный web сервер и привязывать к нему PHP. Мы будем рассматривать IIS 7 версии, но не расстраивайтесь, если у Вас, например, стоит Windows Server 2008 R2, где устанавливается IIS версии 7.5, он практически не отличается от 7 версии.

Для начала давайте немного поговорим об архитектуре IIS 7.0. Данный Web-сервер полностью построен на модульной основе, т.е. в отличие от IIS 6.0, который просто устанавливался как роль сервера и все. В IIS 7 более гибко можно настроить свой веб сервер, путем установки только необходимых модулей, которые Вам нужны. Это огромный плюс так как:

  • ненужные модули отключены, тем самым увеличивается производительность;
  • чем меньше модулей задействовано, тем выше безопасность Web сервера, другими словами, так называемых «дырок » становится меньше.

Установка Web-Сервера IIS 7.0 на Windows Server 2008

Перед установкой хочу дать небольшой совет, устанавливайте данную роль сервера на полностью «голый » сервер, т.е. помимо службы IIS там ничего недолжно быть установлено (имеется в виду из ролей сервера ) исключением может быть только DNS сервер. Существует даже отдельная редакция Windows Server 2008 Web Server, которая полностью ориентирована именно на Web сервер, кстати, она намного дешевле других редакций этой операционной системы.

Существует несколько вариантов установки данной роли в Windows:

  • Через графический интерфейс (мы будем использовать );
  • Через командную строку (на мой взгляд, не удобно, так как приходиться полностью вручную писать все необходимые модули, которые Вам нужны, причем их названия регистрозависимые );
  • Также через командную строку, но уже с использованием XML файла (удобно, если Вам необходимо поднять много web серверов, Вы просто один раз повозитесь с xml файлом, а потом просто будете запускать одну команду в командной строке и все ).

Теперь давайте перейдем непосредственно к самой установки этого сервера. Предполагается, что у Вас уже установлена операционная система Windows Server 2008.

Нажимаем Пуск -> Администрирование -> Диспетчер сервера -> переходим на пункт роли и жмем «Добавить роли».

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

В моем случае мы будем прикручивать PHP и для поддержки этого нужно выбрать пункт CGI, а если Вы вдруг используете asp.net, то выбирайте соответствующие пункты, да и вообще почитайте, что там есть еще (описание располагается справа ), чтобы потом не удивляться, «почему у меня нет этого и не работает вот это ». Жмите далее.

А теперь жмем «Установить ». Ждем несколько минут, и после того как мастер добавления ролей скажет, что «Установка прошла успешно », жмем закрыть. И сразу же можем проверить работоспособность нашего web сервер, путем простого открытия браузера и набора в адресной строке http://localhost и если у Вас появилась следующая картинка, то Ваш сервер работает!

Как администрировать IIS?

Для управления web сервером используется графический интерфейс, но сразу могу сказать, что управлять можно также и напрямую редактировав xml файлы. Все настройки web сервера IIS7 хранятся в виде xml файлов. Настройки сразу для всего сервера IIS (сразу для всех сайтов ) хранятся в файле applicationHost.config , который располагается по следующему пути:

Но для конфигурации отдельного сайта можно использовать файл web.config , он создастся автоматически при изменение любой настройки применительно к одному сайту. Мне такая схема напомнила конфигурирование web сервера Apache, где для конфигурации отдельно взятого сайта можно использовать файл.htaccess.

Кстати, по умолчанию корневая директория вашего web сервера располагается по адресу: C:\inetpub , в которой и располагаются все Ваши сайты, когда Вы открыли сайт по умолчанию, то у Вас открылись файлы из папки wwwroot.

Перейдем непосредственно в нашу графическую панель управления web сервером IIS 7, для этого откройте «Пуск->Администрирование->Диспетчер служб IIS ». В итоге у Вас откроется, вот тая панель:

Где, слева будет дерево Ваших сайтов (у нас пока только сайт по умолчанию ) и приложений, по центру сгруппированы все настройки, а справа свойства той или иной настройки.

Привязываем PHP к IIS

Теперь нам необходимо установить PHP, для этого нужно скачать дистрибутив php с официального сайта (http://windows.php.net/download/) в виде msi пакета (нажав на ссылку installer ), я скачал версию php-5.3.10-nts-Win32-VC9-x86.msi, но Вы можете скачать версию и поновей.

Перейдем к установке PHP, вообще проблем возникнуть не должно, только на одном окне обязательно выберите следующий пункт: IIS Fast CGI .

Создание нового сайта в IIS

После этого давайте создадим новый сайт (в IIS это будет узел ), щелкнем правой кнопкой по пункту «Узлы » и нажмем «Добавить веб-узел ». Заполняем как на картинке, локальную директорию для нового сайта я создал в папке C:\inetpub\my , но Вы можете создать ее хоть на другом диске.

Если у Вас будет не один сайт, то у Вас возникнет необходимость отделять их друг от друга. Существует несколько способов, первый, например, посадить их на разные порты, но в некоторых случаях это не удобно. У сайта по умолчанию он 80, а у нового сайта 8080, но если у Вас будет много сайтов и Вы хотите чтобы они работали на одном порту, скажем на 80, то Вам необходимо заполнять поле «Имя узла », другими словами, это домен сайта. После того как Вы указали здесь, например, как я mysite, Вам необходимо сделать соответствующую запись на DNS сервере или, если у Вас мало компов и просто нет DNS сервера, или Вы просто разработчик, то пропишите это соответствие в файле hosts (например, 10.10.10.2 mysite )

Теперь создайте в папке нового сайта (C:\inetpub\my) файл, например, index.php с таким содержимым

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

Как Вы заметили никаких специальных действий на сервере IIS 7, для привязки php, мы не делали (за исключением того, что мы при установке добавили компонент CGI ), за нас это сделал сам дистрибутив php и сервер iis.

Полезные настройки IIS

Теперь рассмотрим пару настроек сервера IIS 7, например, мы хотим, чтобы у нас на одном сайте по умолчанию открывался документ mydoc.php. Для этого перейдите на нужный сайт и откройте настройки «Документ по умолчанию » и добавьте нужный Вам документ, причем Вы можете указать несколько документов, задав им необходимый приоритет.

И после этого Вы сразу же увидите, что в Вашей папке с новым сайтом Mysite, появился файл web.config (как я раньше и говорил ). Для того чтобы проверить, что Вы сделали все правильно, создайте файл mydoc.php с любым содержимым, и откройте в браузере адрес Вашего сайта, и по умолчанию должен загрузиться этот документ.

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

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

Открываем заново «Диспетчер служб IIS » и мы замечаем, что в пункте «Проверка подлинности» у нас появился еще один пункт «Обычная проверка подлинности ». Для того чтобы ее включить, Вам необходимо отключить «Анонимная проверка подлинности » и соответственно включить «Обычная проверка подлинности ». Не забудьте создать пользователей, в данном случае «Локальных пользователей ». «Диспетчер сервера ->Конфигурация ->Локальные пользователи » щелкаем правой кнопкой мыши «Создать пользователя », я создал пользователя test. Теперь при обращении к нашему сайту будет появляться форма для аутентификации.

Вводите своего пользователя и если Вы все сделали правильно, то Вы опять попадете на свой сайт!

Теперь поговорим о самой любимой связке — это PHP+MySql. Для того чтобы добавить поддержку MySql, достаточно просто установить эту СУБД (подробная установка рассматривается в статье — Установка сервера MySql и обзор средств его управления и администрирования ) и все! Можете создавать сайты в связке IIS 7+PHP+MySql.

Я думаю для основы этого вполне достаточно, если возникают вопросы, пишите в комментариях, постараюсь помочь. Удачи!

В прошлом году мне пришлось отсобеседовать около 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. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в 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, в которой определён класс MyClass1 со статическим полем Field1. Итак, оба сайта работают под управлением одного пула приложений и используют одну и ту же библиотеку MyLib.dll. Веб-сайт-1 записывает в MyClass1.Field1 = 16 (рис. 7). Вопрос: увидит ли веб-сайт-2 сделанные изменения? Напрашивается ответ «Нет». Но почему? Потому что, для IIS-приложений выделяются непересекающиеся адресные пространства, даже если они работают внутри единого рабочего процесса, поэтому в память веб-приложений загружаются свои копии сборок (прошу не придираться к возможным неточностям в терминах работы с памятью в.NET Framework).

Рис. 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 бывают 2 типов: нативные и управляемые. Точный список модулей вы можете почерпнуть в MSDN-е или в статье Риган Темплин. Вы всегда можете написать свой модуль, например, для редиректов. Чаще всего, конечно, делают управляемые модули, т.к. их проще всего реализовать. К слову, ASP.NET WebForms и MVC работают в виде таких вот управляемых модулей. Т.ч. лично у меня холивары WebForms vs. MVC вызывают улыбку и трудно сдерживаемое желание потроллить. Зная принципы работы IIS и ASP.NET, вы сами сможете реализовать любой понравившийся вам паттерн.

На следующем уровне рассмотрения мы столкнёмся уже с составляющими ASP.NET, такими как HttpHandler-ы и события обработки страницы. Про это написана масса статей, т.ч. не вижу смысла сколько-нибудь задерживаться на этом. Единственное, позволю себе посоветовать идущим на собеседования забить в поисковике «ASP.NET page lifecycle» перед встречей – этого уж точно по моему глубокому убеждению стыдно не знать специалистам, считающих себя разработчиками на ASP.NET.

Пример дефолтных настроек нативных модулей в applicationHost.config

ИТ-поддержка

Настройка веб-публикации 1С, подключение кассового оборудования

1. Настройка веб-сервера в IIS

Устанавливаем веб-сервер Internet Information Server, который по умолчанию входит в поставку Microsoft Windows Server. При установке обязательно выбираем компоненты:

  • Общие функции HTTP (Common HTTP Features)
    • Статическое содержимое (Static Content)
    • Документ по умолчанию (Default Document)
    • Обзор каталогов (Directory Browsing)
    • Ошибки HTTP (HTTP Errors)
  • Разработка приложений (Application Development)
    • ASP.NET 3.5
    • Расширяемость.NET 3.5 (.NET Extensibility 3.5)
    • Расширения ISAPI (ISAPI Extensions)
    • Фильтры ISAPI (ISAPI Filters)
  • Исправление и диагностика (Health and Diagnostics)
    • Ведение журнала HTTP (HTTP Logging)
    • Монитор запросов (Request Monitor)
  • Средства управления (Management Tools)
    • Консоль управления IIS (IIS Management Console)

2. Публикации базы в 1С

На этот же сервер, где развернут веб-сервер IIS, устанавливаем «1С:Предприятие» (32-разрядные компоненты), обязательно выбрав при установке компоненты:

  • 1С:Предприятие
  • Модули расширения веб-сервера

Если планируется настроить 64-разрядный модуль расширения веб-сервера, то необходимо дополнительно запустить программу установки 64-разрядного сервера из соответствующей поставки «1С:Предприятие» и установить компоненту:

  • Модуль расширения веб-сервера


Теперь необходимо установить необходимые права на ключевые папки, используемые при работе веб-доступа к базам данных «1С:Предприятие». Для каталога хранения файлов веб-сайтов, опубликованных на веб-сервере (по-умолчанию: C:\inetpub\wwwroot\ ), необходимо дать полные права группе «Пользователи» (Users). В принципе, этот шаг можно пропустить, но тогда для публикации или изменения публикации базы данных надо будет запускать «1С:Предприятие» от имени администратора. Для настройки безопасности данного каталога, кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Свойства» (Properties).

В открывшемся окне свойств, переходим на вкладку «Безопасность» (Security) и нажимаем кнопку «Изменить» (Edit…), для изменения действующих разрешений. Появится окно разрешений для данного каталога. В списке Групп или пользователей (Groups or user names) выделим группу «Пользователи» (Users) и в списке разрешений для выбранной группы установим флаг «Полный доступ» (Full control). Затем нажмем «Применить» (Apply) для записи изменений и закроем все окна при помощи кнопки «ОК» .


Далее необходимо дать полные права на каталог с установленными файлами «1С:Предприятие» (по-умолчанию: C:\Program Files (x86)\1cv8\ для 32-разрядного модуля расширения и C:\Program Files\1cv8\ для 64-разрядного) группе IIS_IUSRS . Для этого выполняем аналогичные описанным выше действия, с той лишь разницей, что для того, чтобы необходимая группа появилась в списке «Группы или пользователи» (Groups or user names), необходимо нажать расположенную под списком кнопку «Добавить» (Add..), а в окне выбора групп или пользователей нажать «Дополнительно» (Advanced…).


Затем нажимаем расположенную справа кнопку «Поиск» (Find Now), после чего выбираем необходимую группу IIS_IUSRS в таблице результатов поиска и нажимаем «ОК» .


И, наконец, если публикация выполняется для файловой базы, необходимо также дать группе IIS_IUSRS полные права на каталог с расположенными файлами данной информационной базы.


Переходим к непосредственной публикации базы данных на веб-сервере. Для этого запускаем «1С:Предприятие» в режиме Конфигуратор для той базы, которую требуется опубликовать. Затем в меню выбираем «Администрирование» - «Публикация на веб-сервере…»


Откроется окно настройки свойств публикации на веб-сервере. Основные поля, необходимые для публикации, уже заполнены по-умолчанию:

  • Имя виртуального каталога - имя, по которому будет происходить обращение к базе данных на веб-сервере. Может состоять только из символов латинского алфавита.
  • Веб-сервер - выбирается из списка найденных на текущем компьютере веб-серверов. В нашем случае это Internet Information Services.
  • Каталог - физическое расположение каталога, в котором будут располагаться файлы виртуального приложения.
  • Соответствующими флагами можно указать типы клиентов для публикации, а также указать возможность публикации Web-сервисов. В расположенной ниже таблице можно отредактировать список Web-сервисов, которые будут опубликованы, а также в столбце «Адрес» изменить синоним, по которому будет происходить обращение к данному Web-сервису.
  • Также для веб-сервера IIS есть возможность указать необходимость выполнения аутентификации на веб-сервере средствами ОС, установив соответствующий флаг.

Выбрав необходимые настройки публикации, нажимаем «Опубликовать» .


Если публикация прошла без ошибок, увидим соответствующее сообщение.

2.3 Подключение к опубликованной информационной базе через веб-браузер


К данной информационной базе также можно подключиться и с любого компьютера в сети, обратившись к веб-серверу по его внутреннему (или если прокинут порт 80 - по внешнему) IP-адресу.

3. Создание бесплатного SSL-сертификата Let’s Encrypt на IIS

Наличие SSL-сертификата для сайта позволяет защитить данные пользователей, передаваемые по сети от атак человек-посередине (man-in-the-middle) и гарантировать целостность переданных данных.

Let’s Encrypt – это некоммерческий центр сертификации, позволяющий в автоматическом режиме через API выпускать бесплатные SSL/TLS сертификаты. Выдаются только сертификаты для валидации доменов (domain validation) со сроком действия 90 дней, что не является проблемой из-за наличия встроенной возможности автоматического перевыпуска сертификата, в результате чего обеспечивается непрерывность защиты.

Далее описан способ получить SSL-сертификат от Let’s Encrypt при помощи консольной утилиты LetsEncrypt-Win-Simple . Она представляет собой простой мастер, который позволяет выбрать один из сайтов, запущенных на IIS и автоматически выпустить и привязать к нему SSL-сертификат.

3.1 Создание SSL-сертификата

Скачиваем последний релиз клиента со страницы проекта на GitHub https://github.com/PKISharp/win-acme/releases

Распакуем его в каталог на сервере с IIS: c:\inetpub\letsencrypt


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


Затем нужно будет выбрать, что необходимо создать новый сертификат (N: Create new certificate ) и выбрать тип сертификата (в нашем примере нет необходимости использовать сертификат с несколькими SAN), поэтому достаточно выбрать пункт 1. Single binding of an IIS site .


Следующий этап – выполнение валидации домена. Доступно несколько вариантов валидации: TLS, через запись в DNS или через HTTP). Самый простой вариант - выбрать пункт 4 Create temporary application in IIS (recommended) . В этом случае на веб-сервере будет создано небольшое приложение, через которое серверы Let’s Encrypt смогут провести валидацию.


Примечание. При выполнении TLS/HTTP проверки ваш сайт должен быть доступен снаружи по полному DNS имени по протоколам HTTP (80/TCP) и HTTPS (443/TCP).

После валидации утилита letsencrypt-win-simple автоматически отправит запрос на генерацию сертификата, скачает его (все необходимые файлы, а также закрытый ключ сохраняются в каталог C:\Users\User\AppData\Roaming\letsencrypt-win-simple) и создаст привязку на сайте IIS. В том случае, если на сайте уже установлен SSL-сертификат, он будет заменен новым. Кроме того, будет создано правило в планировщике заданий Windows, которое запускается каждый день и автоматически выпускает и устанавливает новый сертификат каждые 60 дней.

3.2 Создание отдельного пула и сайта с подключенным с SSL-сертификатом.

Создаем отдельный пул в IIS для letsencrypt



Добавляем сайт в новый пул. Порт указываем 443 (или другой на который позже сделаем проброс на 443 порт).

Указать новый сертификат в «Сертификаты SSL»:


Настроить привязку к нашему сайту:



Проверяем.


4. Подключение кассового оборудования. Проброс COM-портов через TCP/IP с помощью Virtual Serial Ports Emulator (VSPE).

4.1 Настройка VSPE на сервере

Запустить программу VSPE. Нажать на кнопку «Создать новое устройство».


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

В открывшемся окне в выпадающем меню выбрать TcpServer . Нажать кнопку «Далее» .


Установить локальный номер tcp-порта, который будет прослушиваться. Выбрать COM-порт, к которому подключено оборудование через преобразователь интерфейсов. Нажать на кнопку «Настройки» .

Обычно, когда говорят о web-сервере, подразумевают решения на базе платформы Linux. Но если ваша инфраструктура развернута на основе Windows Server то логично будет использовать веб-сервер IIS. Вопреки распространенному мнению, это весьма популярная платформа, которая позволяет работать как с большинством популярных CMS, так и имеет широкий спектр систем, предназначенных для работы именно на Windows и IIS.

Несомненным достоинством IIS является его тесная интеграция с другими технологиями и средствами разработки Microsoft. В частности веб-решения для IIS могут использовать богатые возможности.NET и легко взаимодействовать с настольными приложениями на этой платформе. Если же вас это пока не интересует, то к вашим услугам богатый выбор готовых CMS, в том числе написанных специально для IIS. Сегодня мы рассмотрим как установить и настроить IIS для работы с веб-решениями на базе ASP.NET и установим одну из популярных CMS для этой платформы.

Для установки веб-сервера на платформе Windows перейдем в оснастку Роли в Диспетчере сервера и выберем установку ролей Веб-сервер (IIS) и Сервер приложений .

Но не спешите нажимать Далее, слева, под названием каждой роли, доступна опция Службы ролей , перейдем на нее и установим для Сервера приложений следующие опции: Поддержка веб-сервера (IIS), Общий доступ к TCP-портам и Активация через HTTP.

А для веб-сервера установите службу FTP-сервер.

После чего установите выбранные роли. Для проверки работоспособности IIS наберите в браузере IP-адрес вашего сервера, вы должны будете увидеть стандартную страницу-заглушку веб-сервера.

Теперь перейдем в к настройке сервера, для этого откроем Диспетчер служб IIS (находится в Пуск - Администрирование).

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

В открывшемся окне укажите имя сайта, путь к корневой папке (по умолчанию сайты пользователей располагаются в C:\inetpub\wwwroot ), которую следует предварительно создать и укажите имя узла (доменное имя сайта), в нашем случае iissite.local

Не забудьте добавить A-запись с именем вашего сайта на DNS-сервер или пропишите необходимые строки в файлы hosts тех рабочих станций, откуда будете обращаться к сайту

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

Далее укажите привязку FTP-cлужбы к сетевым интерфейсам и портам, а также настройте параметры безопасности. Если вы собираетесь использовать SSL, то учтите что вам потребуется сертификат, хотя если вы будете использовать FTP-доступ только для собственных нужд, то можно обойтись самоподписанным сертификатом. Не забудьте поставить галочку для автоматического запуска FTP-сайта.

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

Веб-сервер настроен и вы можете использовать его для размещения HTML-страниц, однако современные сайты используют для хранения своих данных СУБД, поэтому следующим шагом установим MS SQL Express 2012 , возможностей которого с лихвой хватит для наших задач. Установка производится со значениями по умолчанию, кроме Режима проверки подлинности , который следует переключить в Смешанный режим и задать пароль суперпользователю SQL-сервера sa .

Теперь попробуем установить какую либо популярную CMS созданную на базе технологии ASP.NET, обширный выбор таких решений представлен в галерее web-приложений Microsoft. Обратите внимание, что по кнопке скачать вы получите пакет для установки через Web PI, для установки на IIS вам потребуется перейти на сайт разработчика и скачать полный пакет с CMS

Мы будем устанавливать Orchard CMS , для получения пакета пройдите по ссылке и выберите Загрузить как zip , распакуйте полученный архив и закачайте в корень сайта содержимое папки Orchard.

Данная CMS создана на базе ASP.NET 4, поэтому настроим наш сайт на использование необходимых технологий. Для этого щелкните правой кнопкой на имени сайта в боковом меню и выберите Управление веб-сайтом - Дополнительные параметры

В открывшемся окне измените параметр Пул приложений , указав там ASP.NET v.4

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

Также не забудьте создать базу данных для сайта, для этого зайдите в SQL Server Management Studio и, щелкнув правой кнопкой на пункте Базы данных в боковом меню, создайте новую базу.

 

Возможно, будет полезно почитать: