Довольно часто приходится сталкиваться с проблемой, когда информации на сайте, размещенном на 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 Добавьте следующую запись в ваш 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. ISAPI_Rewrite - плюсы * Простота установки. * Легкость просмотра log-файлов. * Для добавления поддомена просто необходимо добавить новую папку ISAPI_Rewrite - минусы * Необходимость отслеживания каталогов во избежание конфликтов. * Нужна выделять IP-адрес. * Требуется дополнительный ресурс для обработки каждого файла. * Необходимость подбора сервера, который поддерживает ISAPI_Rewrite. Заключение Хотя ISAPI_Rewrite гораздо проще в реализации, все-таки, использовать его рекомендуется на не очень больших сайтах, с которыми работает группа разработчиков. Это объясняется тем, что группа разработчиков должна постоянно отслеживать добавление и удаление ресурсов. Для большого сайта администратор должен будет произвести все настройки на нескольких серверах только один раз. Поддомены, созданные различными командами разработчиков, в этом случае будут функционировать практически одинаково с одинаковыми настройками. В конце концов, выбор способа разделения сайта на поддомены зависит от администратора, который обслуживает сайт. (с)Эдвард Льюис
