Псевдомногосайтовость… Для чего такое нечленораздельное нагромождение букв? Вы к примеру о чём подумали? Я бы сюда отнесла и мульти-кеи, и многозадачность, и масштабирование, и конечно мультисайтинг. И это только макушка айсберга, который я попробую немного обнажить в хорошем смысле этого слова. Начну с того, что впервые завесу тайны для себя про мульти-сайты я приоткрыла на блоге, залпом прочитав замечательную статью о развёртывании сетки блогов на вордпресс – «Блогофермы на WordPress MU: атака клонов…». Скажу я вам, это статья перевернула моё мировозрение на сайтостроение, тем что в самые кратчайшие сроки без дорогостоящих доргенов, на фришной платформе можно было развернуть сотни и более сайтов, технология с лёгкостью адаптировалась как под белое, серое, так и чёрное. Судя по выдаче в те годы, я была в этом начинании не одна, так как Google стали массово кошмарить сетками на WordPress. Шли дни, вордпресс терял свои позиции и как всегда своевременно на блоге был опубликован пост – «Создание дорвеев на Drupal сайтах», прочитав который вы не найдёте ни одного явного намёка на мультисайты, но как обычно советуют старожилы: «…читайте между строк!».
Drupal – эта CMS априори является тем инструментом, где надо быть настроенным на масштабируемость своих проектов на многочисленных доменах к примеру с одной общей базой данных и в Друпал с задачей мультисайтинга легко справляется модуль — DomainAccess, его задача сводится к тому, чтоб создать логические связи между несколькими сайтами (affiliated sites) на единственной установке Друпала с одной общей БД. Оптимизация очевидна, как и бесспорны преимущества перед Вордпресс-блогами, далее ещё из плюсов это, то что можно создавать сетки сайтов на сабдоменах для экономии на регистрации самих доменов и в те дни это было отличным прорывом для дорвейщиков. Вся хитрость заключалась в незамысловатых настройках в панели управления доменов(Cpanel, ISPmanager или Vesta и т.д., кстати домены в панель на хостинге комфортно добавлять через плагины от PandoraBox:
Если нет этого инструментария, но вы обладаете Zennoposter-ом то легко можно автоматизировать это дело, составив шаблон-аддурилку, вот к примеру добавлялка доменов в ISPmanager), где надо было прикрепить имена сабдоменов, далее создать символические ссылки(symlink – файл, содержащий ссылку на другой файл или папку в виде абсолютного или относительного пути, который явно указывает разрешенные связи доменных имен), примерно так:
<?php
symlink('/home/site/viagra/','bestprice');
symlink('/home/site/viagra/','numberone');
?>
После чего требовалась маленькая правка .htaccess, где надо было раскомментировать следующую строку:
# RewriteBase/
Удалив знак «решетки» (#) и добавить несколько строк кода, сохранив изменения:
RewriteBase /
RedirectMatch 301^/bestprice/(.*)$http://bestprice.viagra.com/$1
RedirectMatch 301^/numberone/(.*)$http://numberone.viagra.com/$1
Всё это в купе даёт переадресацию с поддоменов на основной сайт.
Параллельно с мультисайтами на Вордпресс, Друпал и других платформах вышла из сумрака в паблик технология, получившая название «Революционный метод» — Revmethod, если коротко о её сути, то при помощи всего двух файликов «.htaccess» — его структура весьма интересна, так как в ней были использованы скрытые возможности mod_rewrite, при помощи вставки всего нескольких хитрых строчек реврайтов.
AddDefaultCharset UTF-8
Options +FollowSymlinks
RewriteEngine On
RewriteBase /folder/path/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)\?*$ index.php?_request_=$1 [L,QSA]
И с хитрой начинкой файла «index.php», контент доров подгружался или как лаконично сформулировали – проксировался со стороннего внешнего хоста на сайт-донор, такие доры были не просто жизнеспособны, а долгожителями! Revmethod успешно позволял обходить повторную инсталляцию, необходимость в ней просто отпадала, используя забаненые домены как рабочие хосты, а на свежереги с этих хостов шла трансляция основного забекапенного или свежеспарсенного контента. Но атмосфера сообщества дорвейщиков была наэлектроризованна новой навязчивой идеей, которая удачно материализовалась в технологию обратного синтеза (шутка)… Хотя на Нобелевскую премию она потянет, так как она вобрала в себя всё самое лучшее и передовое.
Прежде всего надо было уйти от рутины статики(статических дорвеев с долгоиграющей отложенной публикацией): парсинг контента(текстовка, картинки и т.д.), подготовка шаблонов, генерация доров и дальнейшая их заливка на сервер, всё это в купе без лишней скромности сказать – жрёт время, хотя стоит оговорится что и здесь нашли пути обхода узких мест путём пакетной генерации доров. Выход сам напрашивался, перейти на динамику(динамические дорвеи с регулируемым разрастанием), где доргену стоит в настройках только указать какие шаблоны и спарсенные ключевики использовать, на выходе дорвеи генерируются уже на серверах, преимущества в полный рост. Динамика чем ещё хороша, так это тем что нам на выбор доступно несколько хитрых режимов генерации дорвеев: режим мультидоменов а-ля классик стайл(о нём я упоминала в начале статьи, хотя как вариант можно проявить находчивость и генерировать доры на сабдоменах по-хитрому, где главная страница корневого домена оформлена как обычный лендинг, а на самих сабдоменах размещены доры, решается это на уровне шаблона) и режим «Клиент-Сервер».
Остановимся на втором варианте – о этом режиме в сети очень мало информации, хотя пару статей заслуживающих нашего внимания есть, одна из них «Режим Remote (Клиент-Сервер)» — описывает основы и практическая статья «Подготовка клиентов для сеодора». Прочитав их можно иметь уже полную картину того, как реализована на разных доменах псевдомногосайтовость. В двух словах, дорвеи логически размещённые на разных доменах, но фактически обслуживаемые одним общим сервером Apache(практичнее конечно если на сервере будет стоять nginx поверх апача, чтобы на выходе была статика). И вся эта многосайтовость вращается на уже старых знакомых двух файликах, правда содержанием они отличны от Ревметода(за счет кода индексной страницы «index.php» и лёгкой правки настроек конфигурации сервера Apache в «.htaccess»), которые отлично справляются с поставленной задачей. Хотя бывает и так, что в случае ошибочных настроек адресов имеют место ситуации, что контент одного дора отображен в шаблоне другого, хотя для доров это некритично.
Как могли заметить успех режима «Remote» целиком зависит от отказоустойчивости к стрессовым нагрузкам хост-сервера, где будет размещён сам дорген, к которому будут обращаться «клиенты», поэтому не экономьте на сервере, выбирая дешёвые тарифы, иначе при падении будет не доступна вся сетка дорвеев, хотя если не экономить, то можно вообще спрятаться за услуги CloudFlare, от этого только плюсы: меньше нагрузка на сервер и самое наверно приятное, так можно замаскировать IP-адрес своего сервера. Если вы выбрали вариант, как описывает Странник в своей статье, то будьте готовы к тому, что админы фришек сейчас активно борятся с дорами, поэтому надо быть очень осторожными, давая отстояться фришкам-свежерегам хотя бы неделю — две. Другая деталь о которой стоит задуматься, это где брать большое количество своих доменов? Тут приходит в голову такая опция, как Alias(Алиас) – псевдонимы, которые позволяют не менее эффективный обходной манёвр, чтоб по разным доменам открывался один и тот же сайт. Схематично это выглядит вот так:
Более развёрнуто можно ознакомиться в этой статье «Как прописать псевдонимы (алиасы) к своему домену». Только помните, что для безупречной работы конструкции с псевдонимами, необходимо чтобы Alias-ы были направлены на тот же хостинг, что и основной домен. Конечно же на начальном этапе при выборе хостера, не забудьте предварительно узнать, имеется ли у них по правилам лимитирование альясов, так у рушных хостеров в норме каждый альяс считать, как отдельный полноценный домен, для нас это не вариант, а вот у западных хостеров такого квотирования нет. Итак, после всего прочитанного у вас должна сложиться вот такая незамысловатая блок-схема:
- Root server – основной сервер, где установлен генератор.
- Client Domain – домены-клиенты, которые подключаются к основному серверу.
- Alias Domain – домены-псевдонимы, которые создаются отдельно для каждого домена-клиента, к примеру в количестве от 10 до 15 штук.
Базисный же функционал всей этой сетки сводится к элементарной схемотехнике. К примеру, создаю десяток дорвеев в режиме Remote (Клиент-Сервер) на 10 разных айпишках, для каждого клиента регистрирую домен в панели на хосте с А-записью, указывающей на тот или иной IP, с необходимыми мне NS-записями. После того, как NS-записи аукнуться, добавляю Alias-домены(не забыв в настройках сервера-доргена прописать добавленные алиас-домены, как клиентские). Тут просто надо понять характер всего происходящего и избежать будущих разочарований, чтоб вся сетка доров не была сеткой клонов(с одним дизайном и контентом), поэтому надо заранее подготовить для каждого клиента свой отдельный шаблон и файл ключей, как закономерность получаем в результате дорвеи с различным дизайном и контентом в каждой отдельной ветке клиентов. После поднятия сетки доров можно сконфигурировать слив трафика через TDS в зависимости от домена-клиента (по рефереру).
Псевдомногосайтовость даёт экономию дискового пространства на хостинге, при этом зеркалируя сотни сайтов с одного сервера, а развернуть такую сетку можно в кратчайшие сроки. Из минусов, пожалуй, есть только один – это ещё сырая поддержка мультиязычности, но и эта проблема будет в скором времени решена.
Автор статьи: Alisa.
