Iis смена домашнего каталога

Содержание

Iis смена домашнего каталога

Добрый день уважаемые читатели и гости блога. Для меня было большим удивлением, что в Америке и в Европе, очень много хостинов используемых людьми, построены на Windows Internet Information Services, и ее доля там больше чем Linux Apache или nginx. В сегодняшнем посте я бы хотел рассказать, начинающим системным администраторам, как создавать сайты iis в Windows Server 2012 R2, точнее административную часть, так как там уже вы сами будите выбирать, будет ли это ресурс на движке Werdpress или же статический сайт, вариантов очень много.

Подготовка IIS для развертывания сайта в IIS

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

Я хочу создать отдельный сайт, пускай это будет iis.pyatilistnik.org, для этого переходим в пункт сайты и через правый клик ,выбираем пункт «Добавить веб-сайт»

Само создание сайта iis состоит из вот таких не хитрых пунктов. Во первых, вы задаете:

  • Имя сайта — у меня это iis.pyatilistnik.org
  • Указываете физический путь — это та папка в которой будет лежать контент для сайта, например, картинки, документы, html странички, если сайт с базой данных, то многое будет лежать в ней.

Далее вы производите привязку сайта к нужному ip адресу, делается это после того, как вы на своем DNS сервере создали A или Cname запись для ресурса. Так же задаем тип привязки, имеет ввиду протокол, тут их всего два обычный незащищенный http и защищенный сертификатом шифрования https, о нем я подробно говорил.

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

Пробуем запустить ваш сайт. И так, сайт в диспетчере IIS на Windows Server 2012 r2 мы создали, пробуем его запустить, для этого у вас есть в пункте управление веб-сайтом, отдельный пункт «Обзор»

Если все хорошо, то вы получите доступ к ресурсу, если же нет, то увидите запрещающее сообщение:

Тут два варианта:

  • У вас пустая папка с сайтом, попробуйте поместить в нее, хотя бы картинку, для тестирования
  • У вас просто нет прав на чтение данного каталога на уровне Windows

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

Перейдите на вкладку «Безопасность > Изменить > Добавить > Проверить имя» и через поиск найти нужную группу.

Назначаем нужный уровень прав для созданного сайта IIS, у меня это чтение и выполнение.

Открываем в браузере ваш сайт и проверяем.

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

Следующим шагом, у вас встанет вопрос какого типа будет ваш сайт и нужно ли для его настройки добавлять новые компоненты или же устанавливать сторонние, по типу PHP или MySQP для WordPress. Далее я вам советую, разобраться в вопросе проверки подлинности IIS и как она настраивается.

Как установить Web сервер IIS 10 в Windows Server 2020?

Сегодня мы с Вами научимся устанавливать веб сервер IIS в операционной системе Windows Server 2020 нескольким способами, а именно с помощью графического инструмента и, конечно же, с помощью Windows PowerShell.

Что такое IIS 10?

IIS (Internet Information Services) — это набор служб, предназначенный для реализации web сервера в операционной системе Windows с поддержкой сайтов HTML и приложений на ASP.NET или ASP. В Windows Server он распространяется в виде отдельной роли с достаточно большим количеством служб роли. Ранее в материале «Описание и назначение ролей сервера в Windows Server 2020» мы рассмотрели краткое описание всех ролей сервера и их служб, в том числе и роли «Веб-сервер (IIS)» поэтому повторяться сейчас, т.е. описывать каждую из служб роли, я не буду.

В актуальной на данный момент версии серверной операционной системе Windows Server 2020 присутствует также самая новая версия веб сервера, а именно – IIS 10.

Версии веб сервера IIS

Версия IIS Версия операционной системы
10 Windows 10; Windows Server 2020
8.5 Windows 8.1; Windows Server 2012 R2
8.0 Windows 8; Windows Server 2012
7.5 Windows 7; Windows Server 2008 R2
7.0 Windows Vista; Windows Server 2008
6.0 Windows Server 2003
5.1 Windows XP Professional
5.0 Windows 2000

Установка Web сервера IIS 10

Итак, давайте переходить к рассмотрению процесса установки, и для примера давайте просто установим основные компоненты, которые необходимы для функционирования веб сервера и его администрирования (средства управления), а также разместим на нем простую HTML страничку, т.е. по сути HTML сайт, для проверки работы web сервера. Если Вам необходимо размещать приложения, например на ASP.NET, то Вам необходимо также установить соответствующие службы роли из раздела «Разработка приложений».

Установка веб сервера IIS с помощью мастера

Сначала давайте разберем процесс установки web сервера IIS 10 с помощью «Диспетчера серверов», а конкретней «Мастера добавления ролей и компонентов».

Шаг 1

Открываем диспетчер серверов «Пуск ->Диспетчер серверов».

Затем запускаем «Мастер добавления ролей и компонентов», меню «Управление ->Добавить роли и компоненты».

Шаг 2

Шаг 3

Потом выбираем тип установки «Установка ролей или компонентов», жмем «Далее».

Шаг 4

Затем выбираем целевой сервер и жмем «Далее».

Шаг 5

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

И сразу жмем «Далее».

Шаг 6

Все необходимые компоненты мы уже отметили, поэтому на этом шаге также сразу жмем «Далее».

Шаг 7

Теперь нам необходимо настроить установку роли «Веб-сервер IIS», сначала жмем «Далее».

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

Шаг 8

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

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

Установка web сервера IIS с помощью Windows PowerShell

Для того чтобы установить web сервер IIS с помощью PowerShell запускайте оболочку Windows PowerShell и вводите следующие команды (перечисленные ниже команды установят все те же службы, которые мы установили с помощью мастера чуть выше).

Документ по умолчанию

Ведение журнала http

Сжатие статического содержимого

Консоль управления службами IIS

Размещаем HTML сайт на веб сервере IIS

Первое что нужно сделать — это создать корневую директорию нашего тестового сайта, для этого в каталоге С:\inetpub\ создаем папку TestSite и в нее для проверки добавляем файл index.html со следующим содержимым, например

Затем открываем «Диспетчер служб IIS», это можно сделать, например, из диспетчера серверов «Средства ->Диспетчер служб IIS».

Потом щелкаем правой кнопкой мыши по пункту «Сайты ->Добавить веб-сайт».

Откроется окно добавления веб сайта, заполняем необходимые поля и жмем «ОК» (TestSite в моем случае это название сайта).

Теперь можем проверить работу веб сервера и только что созданного сайта, для этого открываем любой веб браузер и переходим на сайт TestSite (только помните, для того чтобы у Вас также как у меня открылся сайт по имени, он должен быть добавлен на DNS сервере (создана A запись) или хотя бы для тестов добавлена запись в файл HOSTS локального сервера).

Удаление веб сервера IIS с помощью мастера

Для удаления web сервера IIS открываем диспетчер серверов, затем в меню нажимаем «Управление ->Удалить роли и компоненты».

В итоге запустится «Мастер удаления ролей и компонентов», где мы делаем практически то же самое, что и при установке, только галочки мы не ставим, а снимаем.

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

Удаление web сервера IIS с помощью PowerShell

Для удаления web сервера IIS на PowerShell запускаем оболочку Windows PowerShell и используем командлет Uninstall-WindowsFeature. Для удаления следующих служб ролей веб сервера IIS, можно использовать вот такие команды:

Документ по умолчанию

Ведение журнала http

Сжатие статического содержимого

Консоль управления службами IIS

Вот мы с Вами и научились устанавливать и удалять web сервер IIS в операционной системе Windows Server 2020 и на этом у меня все, пока!

Iis смена домашнего каталога

Опубликовано: Февраль 2012 г.

Обновлено: Февраль 2012 г.

Назначение: Windows Server 2012, Windows Server 2012 R2

В этом документе описан процесс установки веб-сервера IIS и его настройки для обслуживания статического содержимого. Статическим содержимым является веб-страница (HTML), которая доставляется пользователю в том виде, в котором она хранится. И наоборот, динамическое содержимое формируется веб-приложением, таким как ASP.NET, классическим приложением ASP или приложением PHP. Статическое содержимое отображает одинаковые сведения для всех пользователей; динамическое содержимое может отображать сведения о конкретном пользователе, например имя пользователя.

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

Содержание документа

Чтобы получить максимум от этого учебника, необходимо иметь компьютер, который работает под управлением одной из следующих операционных систем:

    Windows Server® 2012

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

Эту процедуру можно также выполнить с помощью пользовательского интерфейса Windows или командной строки.

На начальной странице щелкните плитку Диспетчер сервера, а затем нажмите кнопку ОК.

В диспетчере сервера выберите Панель мониторинга и щелкните Добавить роли и компоненты.

В мастере добавления ролей и компонентов на странице Перед началом нажмите кнопку Далее.

На странице Выбор типа установки выберите Установка ролей или компонентов и нажмите кнопку Далее.

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

На странице Выбор ролей сервера укажите Веб-сервер (IIS) и нажмите кнопку Далее.

На странице Выбор компонентов просмотрите выбранные по умолчанию компоненты, а затем нажмите кнопку Далее.

На странице Роль веб-сервера (IIS) нажмите кнопку Далее.

На странице Выбор служб ролей просмотрите выбранные службы и нажмите кнопку Далее.

Примечание
Установите службы ролей IIS 8 по умолчанию для веб-сервера статического содержимого.

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

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

Чтобы убедиться, что службы IIS успешно установлены, введите в веб-браузере следующее:

http://localhost

Должна отобразиться страница приветствия служб IIS по умолчанию.

На начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления.

В панели управления выберите Программы, а затем Включение и отключение компонентов Windows.

В диалоговом окне Компоненты Windows щелкните Службы IIS, а затем нажмите кнопку ОК.

Будет установлен набор компонентов IIS 8 по умолчанию. Установите только компоненты по умолчанию для веб-сервера статического содержимого.

Чтобы убедиться, что службы IIS успешно установлены, введите в веб-браузер следующее:

http://localhost

Должна отобразиться страница приветствия служб IIS по умолчанию.

В командную строку с повышенными привилегиями или в скрипт введите следующую команду:

Start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools;IIS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

На этом шаге поясняется, как добавить веб-сайт для служб IIS с помощью пользовательского интерфейса диспетчера служб IIS или путем запуска команд Appcmd.exe в окне командной строки

Откройте диспетчер служб IIS.

    При работе в Windows Server 2012 на начальной странице щелкните Диспетчер сервера, а затем нажмите кнопку ОК. В диспетчере сервера выберите меню Сервис, а затем выберите Диспетчер служб IIS.

При работе в Windows 8 на начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления. На экране Панель управления выберите Системы и безопасность, затем Администрирование, после чего выберите Диспетчер служб IIS.

На панели Соединения правой кнопкой мыши щелкните узел Сайты, а затем выберите Добавить веб-сайт.

В диалоговом окне Добавление веб-сайта в поле Имя сайта введите понятное имя веб-сайта.

Щелкните Выбрать, если нужно выбрать пул приложений, отличный от пула, указанного в поле Пул приложений. В диалоговом окне Выбор пула приложений в списке Пул приложений выберите пул приложений, а затем нажмите кнопку ОК.

В поле Физический путь введите физический путь к папке веб-сайта или нажмите кнопку обзора (. ), чтобы перейти к файловой системе для поиска папки.

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

В списке Тип выберите протокол для веб-сайта.

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

В поле Порт введите номер порта.

Дополнительно введите имя заголовка узла для веб-сайта в поле Заголовок узла.

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

Нажмите кнопку ОК.

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

Примечание
Чтобы этот синтаксис работал, необходимо либо находиться в следующем каталоге, либо иметь каталог в пути: %windir%\system32\inetsrv

appcmd add site /name:string /id:цел_чис_без_зн /physicalPath:строка /bindings:строка

Переменная name является именем, а переменная id — положительным целым числом, которое следует назначить сайту. Переменные name и id являются единственными переменными, которые требуются для добавления сайта с помощью команды appcmd. Но при добавлении сайта без задания значений атрибутов bindings и physicalPath сайт будет невозможно запустить.

Переменная physicalPath является абсолютным путем к содержимому сайта в файловой системе.

Переменная bindings содержит сведения, используемые для доступа к сайту. Она должна иметь вид протокол/IP_адрес:порт:заголовок_узла. Например, если указать для веб-сайта привязку http/*:85: , то это будет означать, что он прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменных имен (также известных как заголовки узлов или имена узлов). С другой стороны, привязка http/*:85: marketing.contoso.com настраивает сайт для прослушивания HTTP-запросов на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com.

Чтобы добавить веб-сайт contoso с идентификатором 2 и содержимым в папке c:\contoso, который прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com, введите в командную строку следующее:

appcmd add site /name:contoso /id:2 /physicalPath:c:\contoso /bindings:http/*:85:marketing.contoso.com

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

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

На странице Проверка подлинности выберите Анонимная проверка подлинности.

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

В диалоговом окне Изменение учетных данных анонимной проверки подлинности выберите один из следующих параметров.

    Если нужно настроить определенную учетную запись пользователя, которую службы IIS используют для доступа к вашему сайту или приложению, выберите Указанный пользователь. Затем нажмите Установить, чтобы открыть диалоговое окно Задание учетных данных, и введите имя пользователя и пароль для удостоверения. Затем нажмите кнопку ОК.

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

Важно
При использовании учетной записи IUSR анонимным пользователям предоставляется возможность с помощью этой учетной записи осуществлять доступ ко всей внутренней сети.

Нажмите кнопку ОК, чтобы закрыть диалоговое окно Изменение учетных данных анонимной проверки подлинности.

Используйте следующий синтаксис, чтобы изменить учетную запись по умолчанию для анонимного доступа:

appcmd set config /section:anonymousAuthentication /userName:строка /password:строка

Переменная username является учетной записью, используемой службами IIS для анонимного доступа, а переменная password — это пароль, который хранится в файле конфигурации по умолчанию в зашифрованном виде. Например, чтобы использовать учетную запись Moe и пароль pssword1 для анонимного доступа, в командной строке введите следующее:

appcmd set config /section:anonymousAuthentication /userName:Moe /password:pssword1

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

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

На панели Действия нажмите кнопку Добавить.

В поле Имя введите имя файла, которое необходимо добавить в список документов по умолчанию, затем нажмите кнопку ОК. Это имя файла будет добавлено в верхнюю часть списка документов по умолчанию.

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

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

Чтобы добавить имя файла в список документов по умолчанию, используйте следующий синтаксис:

appcmd set config /section:defaultDocument /+files.[value=’строка‘]

Переменная string является добавляемым в список именем файла. Например, чтобы добавить файл home.html в список документов по умолчанию, в командной строке введите следующее:

appcmd set config /section:defaultDocument /+files.[value=’home.html’]

Чтобы удалить файл home.html из списка документов по умолчанию, в командной строке введите следующую команду и нажмите клавишу ВВОД:

appcmd set config /section:defaultDocument /-files.[value=’home.html’]

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

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

Выберите Включить сжатие статического содержимого для сжатия службами IIS статического содержимого.

В поле Статическое содержимое настройте следующие параметры:

    Выберите Сжимать только файлы размером более (в байтах) и введите минимальный размер файла, при котором файлы будут сжиматься службами IIS (необязательный шаг). Размер по умолчанию — 256 байт.

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

Кроме того, можно установить флажок Лимит места на диске на пул приложений (в МБ) и ввести максимальный размер дискового пространства (в мегабайтах), отводимого для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Например, если существует 20 пулов приложений на сервере и параметр Лимит места на диске равен 100, максимальный объем дискового пространства будет равен 2 ГБ. Если выбрать параметр Лимит места на диске на пул приложений (в МБ) и ввести в текстовом поле определенное значение, то при достижении порогового значения службы IIS автоматически очистят временную папку в соответствии с правилом удаления наиболее давно использовавшихся файлов. Значение по умолчанию — 100 МБ для каждого пула приложений.

Нажмите кнопку Применить на панели Действия.

Чтобы включить сжатие HTTP статического содержимого, в командной строке введите следующую команду и нажмите клавишу ВВОД:

appcmd set config /section:urlCompression /doStaticCompression:True

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

appcmd set config /section:urlCompression /minFileSizeforComp:цел_чис /directory:строка /maxDiskSpace:цел_чис

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

%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

Переменная maxDiskSpace служит для определения максимального количества места на диске (в мегабайтах) для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Значение по умолчанию — 100 МБ для каждого пула приложений.

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

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

Для повышения защищенности веб-сервера настройте фильтрацию запросов. Инструкции см. в статье Настройка фильтрации запросов в IIS.

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

Привет. Давайте установим ISS. А для начала узнаем что такое IIS?

Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.

Отлично. Теперь мы знаем что мы будем ставить . Приступим.

Установка

Первым делом идем в главное меню «Пуск» (Start) далее

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

Находим в списке «Службы IIS» и выбираем нужные компоненты

Где-то рекомендовалось следующее:

  • Безопасность. Все компоненты кроме «Проверка подлинности с сопоставлением сертификата …».
  • Компоненты разработки приложений. Для PHP нужна компонента CGI.
  • Общие функции HTTP. Отмечаем все пункты.
  • Проверка работоспособности и диагностика. Выбираем «Ведение журнала HTTP» и «Монитор запросов».
  • Функции повышения быстродействия. Отмечаем все пункты.
  • Средства управления веб-сайтом. Отмечаем только «Консоль управления IIS».

Лично я немного отступил от этого описания и добавил FTP, так как мне для моих нужд потребуется тестировать работу с FTP.

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

все. Можно сказать что наш ISS Сервер установлен. Перейдем к его начальному конфигурированию .

Конфигурирование

Идем в управление компьютером (правой кнопкой мыши по значку «Компьютер» -> Управление), далее «Службы и приложения» -> «Диспетчер служб IIS» или счастливые обладатели Windows 7 могут пойти по другому «Пуск» и в поле «Найти программы и файлы» ввести «IIS» и в списке отобразится заветная «Диспетчер служб IIS»

Идем в сайты. Сайт по умолчанию я удалил сразу, решив что он мне не нужен и для наглядности я создам новый .

Правой кнопкой мыши по «сайтам» -> «Добавить web сайт»

Создание динамических поддоменов через Windows / IIS: обзор

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

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

  • должна быть возможность изменения DNS;
  • доступ к серверу ISS;
  • ISAPI_Rewrite (для реализации 2 способа).

Реализация первого метода: настройка сервера IIS

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

Управление группой поддоменов: добавьте следующую запись в ваш DNS и измените домен вместе с IP следующим образом:

*.example.com IN A 1.2.3.4

Объявление вручную: добавьте запись для каждого из поддоменов.

В sub1.example.com 1.2.3.4
В sub2.example.com 1.2.3.4
В sub3.example.com 1.2.3.4

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

d:\inetpub\wwwroot\example.com\sub1\
d:\inetpub\wwwroot\example.com\sub2\
d:\inetpub\wwwroot\example.com\sub3\
d:\inetpub\wwwroot\example.com\js\
d:\inetpub\wwwroot\example.com\css\
d:\inetpub\wwwroot\example.com\img\

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

  • Откройте консоль IIS (IIS Management Console);
  • Щелкните на Web Sites и выберите New: Web-site;
  • Нажмите Next, чтобы продолжить;
  • Введите описание сайта и нажмите кнопку Next. Пример того, как это выглядит: sub1.example.com;
  • IP-адрес и Settings: введите sub1.example.com в Host header.
  • На следующей странице введите путь d:\inetpub\wwwroot\example.com\sub1\
  • На следующей странице, выберите подходящие настройки и нажмите кнопку Next.

Теперь начинается самое интересное: созданы отдельные сайты для каждого поддомена, но у них есть общие файлы (скрипты, CSS, картинки). Проблема состоит в том, как сделать так, чтобы каждому сайту были доступны эти файлы.

  • Кликните правой кнопкой мыши на поддомен, который вы только что создали в консоль управления IIS и выберите New : Virtual Directory;
  • В качестве примера будем использовать папку CSS. Кликните на Next и введите в css псевдонимом;
  • Укажите путь d : \ inetpub \ wwwroot \ example.com \ css \ и нажмите кнопку Next.

Реализация первого метода: подведение итогов

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

Реализация первого метода: использование ISAPI_Rewrite

Сразу перейдем к сравнению первого метода со вторым.

Добавьте следующую запись в ваш DNS и измените домен вместе с IP следующим образом:

*.example.com IN A 1.2.3.4

  • Откройте консоль управления IIS выберите Web-site;
  • Щелкните правой кнопкой мыши по нему и выберите Properties;
  • Нажмите кнопку Advanced;
  • Убедитесь, что имеется одна запись для множества сущностей для данного веб-сайта с заполненным Host Header Name. Данная запись будет перехватывать все запросы, которые адресуются IP-адрес;
  • Убедитесь, что IP-адрес используется только этим сайтом

Настройка httpd.ini по ISAPI_Rewrite

Добавьте следующий код в httpd.ini в корне директории. Убедитесь, что они в правильном порядке.

# Конвертировать http://example.com к http://www.example.com/
RewriteCond Host: ^example.com
RewriteRule (.*) http\://www\.example.com$1 [I,RP]

# ограничимся рядом общих папок.
# будем выполнять их соответственно вне зависимости от поддомена.
# Example: http://sub1.example.com/img/logo.jpg -> /img/logo.jpg
# Example: http://www.example.com/img/logo.jpg -> /img/logo.jpg
RewriteRule (/css/.*) $1 [I,O,L]
RewriteRule (/js/.*) $1 [I,O,L]
RewriteRule (/img/.*) $1 [I,O,L]

# Перенаправлять все остальные подкаталоги, не соответствующие
# вышеупомянутому списку, как поддомены.
#example: www.example.com\sub1 -> sub1.example.com
RewriteCond Host: www\.highspeed\.com
RewriteRule /(\w*)/(.*) http\://$1\.example\.com$2 [I,RP]

# Если веб-сайт начинается с www, то обязательно укажите файл в корневой папке.
# Если вы специально создали папки / www /, то вы можете закомментировать этот раздел.
RewriteCond Host: (?:www\.)example.com
RewriteRule (.*) $1 [I,O,L]

# url сайта, начинающийся без www, будет переправлен на поддомен
# Example: http://sub1.example.com/default.asp -> /sub1/default.asp
# Note: if the folder does not exists, then the user will get a 404 error automatically.
RewriteCond Host: (.*)\.example.com
RewriteRule (.*) /$1$2 [I,O,L]

# исправление недостающего символа
# выдача 404 ошибки
RewriteCond Host: (.*)
RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [I,RP]

Предположим, что корпоративный сайт состоит из двух поддоменов sub1, sub2.

URI ¦ Расположение на сервере

http://www.example.com ¦ /
http://sub1.example.com/img/logo.jpg ¦ /img/logo.jpg
http://sub2.example.com ¦ /sub2/
http://abc.example.com ¦ /abc/ -> 404 Not Found

Реализация второго метода: подведение итогов

Второе решение легкое в реализации, однако нужно быть осторожным в создании директорий. Так, например, пользователь не может создавать папки d:\inetpub\wwwroot\example.com\sub1\img\ потому, что она противоречит ISAPI_Rewrite (/ img / *.). Поэтому файлы в этой папке не будут доступны.

Multiple IIS- плюсы

  • Вся информация из всех папок доступна, противоречий нет.
  • Отделены log-файлы для отслеживания их по отдельности.
  • Может быть осуществлена настройка для группы серверов и произведена балансировка нагрузки на них.

Multiple IIS сеть — минусы

  • Необходимость создания нового сайта на поддомене.
  • Требует доступа к серверу IIS.
  • Простота установки.
  • Легкость просмотра log-файлов.
  • Для добавления поддомена просто необходимо добавить новую папку
  • Необходимость отслеживания каталогов во избежание конфликтов.
  • Нужна выделять IP-адрес.
  • Требуется дополнительный ресурс для обработки каждого файла.
  • Необходимость подбора сервера, который поддерживает ISAPI_Rewrite.

Хотя ISAPI_Rewrite гораздо проще в реализации, все-таки, использовать его рекомендуется на не очень больших сайтах, с которыми работает группа разработчиков. Это объясняется тем, что группа разработчиков должна постоянно отслеживать добавление и удаление ресурсов. Для большого сайта администратор должен будет произвести все настройки на нескольких серверах только один раз. Поддомены, созданные различными командами разработчиков, в этом случае будут функционировать практически одинаково с одинаковыми настройками.

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

Iis смена домашнего каталога

Подходит ли данный гайд на 100% для переноса каталога IIS 7.5 на другой диск?

  • Разделено Dmitry Davydov Moderator 10 июля 2012 г. 16:32

Все ответы

Eurisco, этот ресурс и его блог содержат, безусловно, очень полезную информацию для пользователей. Кроме того, судя по позиции человека, написавшего этот пост, он знает, что говорит. Но как бы там не было, такие посты не представляют официальной позиции компании, в противовес KB и библиотекам TechNet / MSDN. Поэтому, даже если автор поста забыл дисклеймер, стоить иметь ввиду: все это вы делаете самостоятельно на свой страх и риск.

Я бы еще обратил внимание на концовку поста в красном цвете — мне она, например, совсем не нравится; может стоит ограничиться переносом только каталогов сайтов, а не тащить все функциональные части IIS-а?

а скрипты, говорят, еще и с очепятками

Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий.

  • Изменено Dmitry Davydov Moderator 6 июля 2012 г. 13:51

В общем-то, я тоже склоняюсь к тому, что весь IIS переносить, наверное, не нужно: у меня после переноса директорий и переименования папки С:\Inetpub служба активации Windows (WAS) вообще перестала запускаться, а служба веб-публикаций, как известно, всецело зависит от нее. Пришлось сделать откат и пока отложить перенос.

Собственно, по этому поводу меня беспокоят несколько вопросов:

1. Речь в Вашем предложении идет о переносе всех каталогов пользовательских сайтов IIS или каталогов всех сайтов? Попадают ли под перенос служебные каталоги сайта по умолчанию, такие как app_data и aspnet_client?

2. Насколько опасна для безопасности IIS публикация статической веб-странички в одном из пользовательских виртуальных каталогов сайта по умолчанию в его дефолтном расположении?

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

4. Надо ли беспокоиться о переносе FTP-сайта в другое место? Насколько надежны его фильтры ограничения доступа по IP?

Тема, на мой взгляд, заслуживает отдельного треда. Разделил.

1. Речь в Вашем предложении идет о переносе всех каталогов пользовательских сайтов IIS или каталогов всех сайтов? Попадают ли под перенос служебные каталоги сайта по умолчанию, такие как app_data и aspnet_client?

Я не совсем понял классификацию сайтов IIS, которую Вы произвели; но, тем не менее, мои рекомендации касались переноса каталога сайта по умолчанию wwwroot. И да, со всеми его служебными каталогами. Название этого каталога присутствует везде, путь к нему хорошо известен — все это не прибавляет надежности Вашему веб-серверу. Кроме того, расположение контентных каталогов сайтов за пределами системного раздела на других дисковых массивах положительно влияет не только на безопасность, но и на производительность.

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

2. Насколько опасна для безопасности IIS публикация статической веб-странички в одном из пользовательских виртуальных каталогов сайта по умолчанию в его дефолтном расположении?

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

  • статическая веб-страничка не содержит ни одной строчки клиентских скриптов
  • к этой веб-страничке имеют доступ только авторизованные пользователи в файловой системе веб-сервера
  • на IIS выданы права только на чтение и запрещен Directory Browsing
  • IIS хотя бы элементарно защищен от распределенных атак на случай, если информация на Вашей веб-страничке представляет интерес в корыстных целях всему человечеству :D

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

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

4. Надо ли беспокоиться о переносе FTP-сайта в другое место? Насколько надежны его фильтры ограничения доступа по IP?

Вот это я бы даже не обсуждал — выполнять в первую же очередь! FTP в IIS вообще только в последней своей версии вышел на приемлемый уровень безопасности. Фильтры ограничения по IP адресам могут выступать лишь как дополнительный уровень защиты в связке с механизмами аутентификации и шифрования. Я бы не стал полагаться только на них. Кроме того, Вы же сами обнаружили несостыковки при их конфигурации

Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий.

  • Изменено Dmitry Davydov Moderator 10 июля 2012 г. 17:45

Я не совсем понял классификацию сайтов IIS, которую Вы произвели; но, тем не менее, мои рекомендации касались переноса каталога сайта по умолчанию wwwroot. И да, со всеми его служебными каталогами. Название этого каталога присутствует везде, путь к нему хорошо известен — все это не прибавляет надежности Вашему веб-серверу. Кроме того, расположение контентных каталогов сайтов за пределами системного раздела на других дисковых массивах положительно влияет не только на безопасность, но и на производительность.

Что касается классификации. Собственно, сразу после развертывания IIS в нем создается только один сайт — сайт по умолчанию (Default Web Site). Все остальные Web-сайты, которые добавляются пользователем (и которые потом могут привязываться к разным доменам) условно я обозначил как пользовательские. Есть и другие, служебные сайты. Например, если в организации развернут WSUS, то он создает свой сайт в ISS (Администрирование WSUS), а также добавляет виртуальные подкаталоги ClientWebService и SelfUpdate в вышеуказанный сайт по-умолчанию (они, правда, физически указывают на папки в рабочем каталоге WSUS).

Вы можете с достаточной степенью уверенности относиться к безопасности этого решения ровно до тех пор, пока:
• статическая веб-страничка не содержит ни одной строчки клиентских скриптов
• к этой веб-страничке имеют доступ только авторизованные пользователи в файловой системе веб-сервера
• на IIS выданы права только на чтение и запрещен Directory Browsing
• IIS хотя бы элементарно защищен от распределенных атак на случай, если информация на Вашей веб-страничке представляет интерес в корыстных целях всему человечеству :D

Скажем так, статическая веб-страничка не доступна по стандартному расположению C:\inetpub\wwwroot — извне она доступна по адресу виртуального каталога, который на диске физически расположен в другом подкаталоге в папке C:\inetpub. Сам же корневой каталог переадресовывает на другой ресурс в Интернете и обращения к дефолтной веб-странице IIS (C:\inetpub\wwwroot\iisstart.htm) не происходит.

К рассматриваемой же веб-страничке на уровне ACL файловой системы (помимо стандартного набора прав в лице системы, администраторов, TrustedInstaller и пользователей) имеет доступ только для чтения группа IIS_IUSRS. Пользователи тоже имеют доступ только для чтения. Никто из пользователей домена на сервере не авторизируется, т.к. данный сервер используется для служебных нужд.

Компонент Directory Browsing вообще не установлен, как и Веб-публикация DAV.

IIS находится в отдельной подсети внутри периметра, защищенного IDS/IPS.

Вот это я бы даже не обсуждал — выполнять в первую же очередь! FTP в IIS вообще только в последней своей версии вышел на приемлемый уровень безопасности. Фильтры ограничения по IP адресам могут выступать лишь как дополнительный уровень защиты в связке с механизмами аутентификации и шифрования. Я бы не стал полагаться только на них.

Здесь, опять-таки сюрприз: в стандартном каталоге C:\inetpub\ftproot лежит скромный текстовичок, повествующий его потенциальному читателю, что он-то на сервер зашел, но доступа ни к чему не имеет, раз читает этот файл. А рабочие каталоги FTP физически лежат вообще на другом сервере в локальной сети, куда на них указывают соответствующие логинам пользователей виртуальные каталоги сайта FTP. На сервере не используется режим изоляции пользователей, но при этом им назначаются сеансы в каталоге имени пользователя. Из механизмов аутентификации на IIS-сервере установлена и используется windows-проверка подлинности (используется для FTP) и проверка подлинности с сопоставлением сертификатов клиентов. Шифрования пока нет. Но зато во всю работают фильтры ограничения по IP. Реально работают по другой схеме настройки (описана там же), пока инженеры Майкрософт исследуют проблемы их не стыковок.

Поэтому, всё-таки, надо ли переносить C:\inetpub\ftproot в другое место?

Что Вы скажете насчет SFTP? Реально его внедрить для отдельных подкаталогов или он работает только для сайта в целом? Можно ли использовать стандартный windows explorer при доступе к такому сайту по SFTP?

Как подменить текущую директорию для процесса IIS?

Для работы сайта под IIS потребовалась старая нативная библиотека, написанная на С. В этой библиотеке есть баг, пару временных файлов она создаёт в текущей директории.
Можно ли при помощи фич IIS или Windows-а сделать так, чтобы файлы писались в другую директорию?

P.S. Когда работал под Vista-ой заметил, что процессы, установленные в поддиректорию «Program Files» и пытающиеся писать в эту же директорию без админских прав, на самом деле, писали в папку «%LOCALAPPDATA%\Program files\MyProgram».

2 ответа 2

НЕ факт что сработает, но можно попробовать:

Вариант 1

В вашей рабочей папке (та кот должна редиректить) добавить web.config :

Вариант 2 через GUI:

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками windows iis или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2020 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2020.11.11.35402

Основы архитектуры 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 на одном порту и IP

По умолчанию во время установки сервера IIS (Internet Information Services) создается пустой веб-сайт “Default Web Site”, который отвечает на стандартном веб порту – TCP 80. В терминах IIS это означает, что выполнена привязка этого сайта (Binding) к порту 80. Чтобы открыть этот сайт, достаточно в браузере набрать имя сервера IIS (“http://web-srv1”) или его IP адрес (“http://10.10.0.88”). Один веб сервер IIS может обслуживать десятки и сотни сайтов, и технически можно запустить несколько веб-сайтов, которые слушают и отвечают на одном и том же порту (80 или 443). Однако из интерфейса IIS Manager, совсем не очевидно, что можно запустить второй сайт на этом же хосте без привязки его к другому порту (например, 8080). В этой статье мы разберёмся, как на одном сервере IIS запустить сразу несколько сайтов, чтобы они были привязаны к одному и тому же порту и IP адресу.

Итак, как мы уже говорили ранее, на одном сервере IIS может быть запущено множество сайтов, однако чтобы IIS мог корректно распределять HTTP запросы, каждый сайт должен идентифицироваться неким уникальным значением. Для веб сайта IIS оно формируется из трех атрибутов, комбинация которых для каждого сайта должна быть уникальной. Это:

  • номер TCP порта
  • IP адрес
  • имя узла (host header)

Информация о запущенных сайтах хранится в атрибуте ServerBindings метабазы IIS в формате IP:Port:Hostname. Таким образом, если нужно запустить несколько сайтов на одном порту и IP адресе, нужно использовать уникальный Host header. Что это такое? Host header – это часть HTTP запроса к серверу, который отправляет клиент, указывая к какому конкретно сайту он хочет обратиться. Соответственно, данный host header должен быть указан на стороне веб сервера, а в DNS содержаться корректная запись, осуществляющая соответствие между именем хоста и ip адресом веб-сервера.

Итак, предположим, что у нас на IIS уже запущен один веб сайт на 80 порту. Нам нужно добавить второй сайт на этом же порту.

В консоли управления IIS создадим второй сайт (Add Website). С именем TestSite , файлы которого будут храниться в каталоге c:\inetpub\TestSite (имя хоста пока не указываем).

После того, как вы нажмете “OK”, появится предупреждение, в котором говорится, что вы не можете использовать привязку *:80 для двух сайтов, т.е. одновременно может работать только один из них.

Согласимся с этим предупреждением. Итак, у нас появился второй сайт, также привязанный к 80 порту, но запустить его без остановки первого сайта нельзя.

Чтобы создать уникальную привязку, укажем для второго сайта другое имя (Host Name). Щелкните ПКМ по сайту TestSite и выберите пункт меню Edit Bindings. Выберите нужную привязку и нажмите Edit.

В поле Host Name укажите уникальное имя хоста, к которому должны обращаться пользователи, например TestSite.

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

C:\Windows\System32\inetsrv\appcmd.exe set site /site.name:»TestSite» /+bindings.[protocol=’http’,bindingInformation=’*:80:TestSite’]

Теперь можно запустить и второй веб сайт.

Все, что осталось сделать – добавить в DNS алиас для сервера (запись типа A или CNAME), указывающую на IP адрес веб-сервера или его имя.

Создать CNAME запись для имени TestSite можно с помощью консоли DNS (dnsmgmt.msc), в качестве FQDN target host указать доменное имя вашего IIS сервера.

Создать такую запись также можно с помощью PowerShell :

Add-DnsServerResourceRecordCName -HostNameAlias web-srv1.contoso.loc -Name testsite -ZoneName contoso.loc

Теперь в браузере попробуйте открыть сайт http://TestSite . Он должен успешно открыться.

Еще несколько полезных моментов, которые стоит упомянуть.

В том случае, если у вас используется локальный сервер IIS, сопоставление имен сайтов с IP адресом сервера выполняется через файл C:\Windows\system32\drivers\etc\hosts .

Настройки привязок хранятся в конфигурационном файле IIS ( C:\Windows\System32\inetsrv\config\applicationHost.config ) в секции

В нашем примере эта секция содержит такие данные :

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

Установка и настройка IIS 7 на Windows 2008

Приложения и сайты, разработанные на ASP.NET, должны размещаться на веб-сервере Internet Information Services (далее IIS). Это оснастка Windows, отвечающая за размещение веб-приложений, распараллеливание http-запросов, хранение сессий пользователей и многое-многое другое.

В Windows 2008 IIS по умолчанию отсутствует, и прежде чем настроить сайт, необходимо установить IIS. Поэтому статья разбита на две части:

В каждой операционной системе есть свои нюансы в установке и настройке IIS. Если у вас другая ОС, посмотрите схожие статьи Установка и настройка IIS 5.1 на Windows XP и Установка и настройка IIS 6 на Windows 2003.

Как установить IIS 7 на windows 2008

Сервер приложений IIS 7 устанавливается с дистрибутива операционной системы. Желательно устанавливать IIS с того же дистрибутива ОС, который установлен на данном компьютере. По опыту скажу, бывают прецеденты некорректной работы, в случае установки IIS с «неродного» дистрибутива. Вставьте диск с Windows 2008 в дисковод и начинайте установку IIS:

1. Нажмите «Пуск» и нажмите правой кнопкой мыши по «Компьютер», зайдите в «Управление»:

2. В диспетчере сервера выберите «Компоненты» и нажмите «Добавить компоненты»:

3. В дереве выбираем «Средства веб-сервера (IIS)» и жмем «Далее»:

После этого начнется установка IIS 7 с диска операционной системы Windows 2008. Дождитесь завершения и перезагрузите компьютер. Все! Установка IIS завершена!

Как настроить IIS 7 на windows 2008

Итак, у нас есть сайт, условно назовем его Security. Он представляет собой каталог Security и набор файлов в этом каталоге. Сайт имеет главную страницу, которая должна загружаться по умолчанию. Назовем ее index.aspx. Первым делом необходимо установить и зарегистрировать .Net Framework. Нужно ставить тот же .Net Framework, под который написан ваш сайт. Версию можно посмотреть в файле web.config вашего сайта. Мы будем считать, что наш сайт написан на Net.Framework v.4.0.

Установке и настройке Net.Framework посвящена отдельная статья Как установить Asp.Net и зарегистрировать его в IIS. Здесь опишу кратко: чтобы зарегистрировать .Net Framework в IIS, нужно в командной строке из каталога C:\WINDOWS\Microsoft.NET\Framework\ версия вашего Framework\ выполнить команду aspnet_regiis.exe –i;

Каталог Security разместите в C:\Inetpub\wwwroot\. Это рабочий каталог диспетчера служб IIS.

Теперь займемся непосредственно настройкой IIS:

1. Запустим Диспетчер служб IIS. Нажмем «Пуск», «Выполнить». В появившемся окне введем inetmgr.exe и нажмем «ОК»:

2. Первым делом создадим группу приложений для нашего сайта. Вообще, группа приложений создается для того, чтобы разнести приложения, работающие на разных версиях .Net Framework. В принципе, если у вас на машине будет располагаться только один сайт, то данный шаг можно пропустить. В диспетчере служб IIS выберите правой кнопкой мыши пункт «Группы приложений», меню «Создать», пункт «Группа приложений…». В появившемся окне введите название группы приложений и нажмите «ОК». Т.к. мы решили, что наш сайт написан на .Net Framework v.4.0, то и назовем нашу группу приложений «Net 4.0»:

3. После того, как мы скопировали наш сайт в C:\Inetpub\wwwroot, у нас в диспетчере IIS в Веб-узлах появился каталог Security. Щелкните правой кнопкой мыши и выберите «Преобразовать в приложение»:

4. В появившемся окне выбираем наш пул приложения и нажимаем «ОК»:

5. На вкладке «Документы» нужно добавить нашу главную страницу. Тогда при доступе к сайту не нужно будет обращаться по адресу http://имя_сервера/Security/ndex.aspx, достаточно будет написать http://имя_сервера/Security и мы попадем на главную страницу сайта. На вкладке «Документы» удалите все страницы, которые там заведены по умолчанию и добавьте свою стартовую страницу index.aspx:

6. На этом настройка IIS завершена, осталось настроить права доступа на каталог Security. Откройте общий доступ на вкладке «Доступ» и дайте полный доступ группе IIS_IUSRS и пользователю IUSR (они создаются при установке IIS). На вкладке «Безопасность» также дать полный доступ указанной группе и пользователю:

Илон Маск рекомендует:  Faq обработка событий от клавиатуры
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL