Сначала на новый камп следует выставить виндузню. Это тут описано не будет. Надо конечно накатить все сервис-паки, ибо Web-сервер - наиболее подвергаемый атакам компонент любой системы.

Единственная хитрость, которая тут будет упомянута - это установка сервера терминалов. Ясное дело - Web-сервер работает где-то, и доступ к нему делается УДАЛЕННО, поэтому эта система должна работать безукоризненно четко - иначе с малейшими проблемами придется ездить неизвестно куда (заранее заказывая пропуск) - в общем сплошные проблемы.

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

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

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

FTP в IIS тоже следует добавлять отдельно и вручную, по умолчанию он не ставится. При необходимости Web-сервер совмещается с DNS-сервером, который устанавливается по умолчанию и конфигурится отсюда. Естественно имя сайта надо сначала получить либо прямо на хостинге либо у любого независимого регистратора(Гарант-Парк-Телеком, Демос, Фринет, Регтайм, Совинтел, Libris, РосНИИРОС, RU-CENTER).

Итак, предварительные работы выполнены. Идем дальше. Этот Web-сервер я делаю для хостинга ASP2-сайтов. Для начала сгружаем Microsoft .NET Framework 3.0 Redistributable Package и cтавим его. Добавляем поддержку ASP2 в Web-сервер. После этого накатываем обновление KB928365 и не забываем включить движок ASP.NET и ASP. И, если все было сделано верно, то наслаждаемся созерцанием вкладки ASP2 в конфигурации Web-сервера.

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

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

Отдельных усилий требует установка SSL-сертификата и конфгурирование сайта под SharePoint'ом. Всего этого, однако можно избежать, если воспользоваться услугами SHARED-хостинга, когда конкретному логину предоставляется лишь папка в DocumentAndSetting, куда можно только грузить по FTP странички и логин для доступа к SQL. Однако SHARED-хостинг имеет множество ограничений, и подходит только для простейших ASP2-приложений.

Далее следует накатить AJAX. Он накатывается в виде двух пакетов - ASP.NET AJAX 1.0 и ASP.NET 2.0 AJAX Futures January CTP. И если все получилось правильно - начинают оживать AJAX-сайты.

Важнейшим файлом для работы хостинга ASP.NET является файл Machine.config - который в случае моего девелоперского кампа выглядит вот так. При установке хостинга я в первую очередь сразу же конфигурю правильно SQL-сервер для хостинга, что вы можете увидеть на приведенном листинге конфига. Значения этого конфига переопределяются в Web.Config для всего хостинга в целом, ну а уже для каждого сайта - конфигурационным файлом в каталге приложения. К сожалению, тут не все так просто и значения в маchine.config или web.config НЕ ВСЕГДА перекрываются настройками в web.config конкретного сайта, ну для примера возьмем <deployment retail="true"/>, который в конфиге машины перекрывает <customErrors /> в конкретном каталоге сайта. Кроме того, в ряде случаев требуется дополнительная настройка IIS.

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

В-общем, правильный подъем хостинга - это не такое простое дело. Ведь ошибиться можно даже на SHARED-хостинге Паркинга, если неправильно выбрать там версию NET или загрузить туда конфиг не в той кодировке. А вот если вы еще поднимаете на своем хостинге SQL - вот тут настоящий простор для игр разума. В первую очередь надо конечно разнести TEMPDB, MDF и LDF по разным дискам. Это совершенно обязательно. Ну а дальше можно начинать играться со статистикой, индексами, секционированием, только читаемыми группами файлов и тд... Правильный подъем SQL тут описан не будет. Зато...

Зато далее я опишу на этой страничке методику развертывания ASP2-сайтов на одном конкретном примере. Микрософтовская документация стыдливо умалчивает об этом, вяло бормоча что-то невнятное на это тему про окно студии Copy Site. Поэтому этот бред мы оставим без внимания и посмотрим как это делается на практике.

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

Начинается эта работа с того, что мы пытаемся вычислить ВСЕ используемые сайтом библиотеки. К сожалению, убогая VS2005 не содежит ВООБЩЕ НИКАКИХ инструментов для того. Поэтому это приходится делать вручную.

• Для начала находим все файлы OUT во временной директории компиляции приложения. Фактически в этих файлах OUT и аккумулированы все вызовы необходимых для линковки сайта библиотек.
• Далее я делаю импорт этих файлов OUT в EXCEL. Получаю примерно вот такой файлик, в котором задействованы ВСЕ OUT-файлы этого конкретного проекта. Как вы видите, в данный виртуальный каталог мне надо развернуть около 300 библиотек. Но... это с дублированием одних и тех же имен в разных OUT-файлах.
• Поэтому я далее импортирую все 303 ссылки, необходимые мне для развертывания сайта в данном конкретном виртуальном каталоге, в SQL и оттуда делаю запрос с GROUP BY. Таким образом я избавляюсь от ссылок, дублированных в разных OUT-файлах.
• И вот только теперь я могу отдать админам перечень итоговых (в данном случае 73-х) библиотек, которые им надо выкатить в данный конкретный виртуальный каталог на хостинге. Как вы понимаете, девелоперы не имеют доступа в боевые зоны, поэтому вся переписка с админами требуется обязательно. Ибо админы должны не только точно знать что именно у них работает в боевых зонах, но и уметь самостоятельно их восстанавливать в любой момент.
• К сожалению, работа по развертыванию сайта на этом обычно не заканчивается для девелопера. Ему приходится готовить для админов еще вот такие списки - какие именно пакеты админы должны накатывать на хотинг.

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

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

Comments ( )