Мультидоменный сервер nginx -> apache

[@SaintSerge]

Увы, не хватает кармы перенести в web разработку.

[@SaintSerge]

перенес. Спасибо.

[@akira]

Интересно.
От себя добавлю, что использование $_SERVER[«DOCUMENT_ROOT»] — редкостное зло, имхо лучше указывать относительные пути.

[@clops]

а ещё лучше в приложении указывать ручками полный абсолютный :)

[@SaintSerge]

как вариант.
Но т.к. на сервере уже пара десятков работающих проектов…….
(Автор текста)

[@d1m]

ниразу не лучше — первый перенос на другой сервер Вам это докажет

[@clops]

за последние два месяца перенёс около 50ти сайтов — проблем не испытывал

[@d1m]

Это в случае если и там и там пути совпадают. А если нет — то тогда почувствуете.

[@clops]

я всё равно сайты единично переношу — конфиг с коннектом к базе в любом случае надо править/настраивать — так что правка пути это мелочь

[@d1m]

но зачем ей вообще существовать если ее можно избежать в принципе?

[@clops]

ах, ну и перенос сайтов ведь дело довольно редкое :)

[@d1m]

я админ и программер. К сожалению, для меня это не редкость (

[@vladon]

почему редкостное зло?

а относительные не всегда прокатывают, например, скрипт (например, из библиотеки) будет лежать не там, где хочет разработчик…

[@akira]

library/megalib/lib.php — относительный путь относительно запущенного index.php
Сменили путь к папке на ../factory/library/megalib/lib.php
../library/megalib/lib.php — относительный путь относительно запущенного index.php

Можно и без абсолютного пути.

Зато когда вы будете перекидывать с девелоп машины на продакшн, то проблем будет меньше.

[@SaintSerge]

А если у нас структура например аж 5тиуровневая? :)
А если система модульная?
в общем относительные пути — отличный вариант когда проект невелик.

[@d1m]

У правильного приложения одна точка входа — index.php в корне. И соответственно все относительные пути строить не вызывает проблем.
Лучше устанавливать все пути в конфигурационном файле, в котором использовать __FILE__ — и никаких проблем не будет.

[@SaintSerge]

Не считаю такое приложение правильным. Даже наоборот сторонюсь такой архитектуры. Аналогии почему то с «Всё через ж...»

[@d1m]

Вы домой тоже ведь не только через парадное, но и через балкон и форточки заходите?

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

[@SaintSerge]

Так сделано у большинства. Да. Но считаю перным использовать mod_rewrite и именно через него направлять разные запросы нужным скриптам…

[@d1m]

Хотите скажу почему куча правил для mod_rewrite зло для такой задачи? А перенесите все это добро под lighttpd / nginx + php-cgi.
И я очень радуюсь когда приложения написаны действительно грамотно — их при этом не приходится пилить напильником.

Насчет единой точки входа — так и у больших фреймворков на php, так и у django/rails/merb.

[@SaintSerge]

в nginx есть модуль rewrite.

[@d1m]

Угу, есть, конечно. Только вот задолбаетесь переделывать пачку реврайтов в его формат. А потом захотели попробовать lighttpd — а у него описание правил опять отличается…

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

[@adek]

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

Опять же php не так эффективно потребялет ресурсы как mod_rewrite. так что для проекта имеющего большую нагрузку вы скорее всего будете рады написать правила для rewrite которые разрулят обращения к максимально урезанным скриптам.

[@adek]

если вы не согласны, то можете ответить аргументированно или просто выразить несогласие, а вот хамить не надо.

[@adek]

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

[@d1m]

Загрузку библиотек надо делать с умом — и все будут довольны.

Естественно PHP не настолько быстр как mod_rewrite. Но знаете что? Под нагрузкой и апач весьма убойная штука. Потому оно у меня бегало бы на nginx/lighttpd + fastcgi. А в таком случае я бы долго проклинал того разработчика, благодаря которому я бы сидел и давился над регекспами при переводе их для nginx/lighttpd.

[@adek]

вероятно вы не были в ситуации, когда прирост производительности на разницу между rewrite и рулением запросов внутри php стоили кучи денег, а также потраченного времени и сил на регекспы и переод с apache на nginx. желаю вам и дальше не испытывать с этим проблем.

[@SaintSerge]

Лучше сравнить не с личным домом(для домашней стринички это нормально да)…
лучше сравнить с гипермаркетом типа АШАН…

Приедставьте что там 1 касса…

[@d1m]

Некорректно. Это выдача запросов. А ее выдает несколько процессов/тредов вэб-севреров. У Вас же не 1 процесс апача ;)

Скорее как одтельный вход возле для каждого стеллажа. Что не так уж удобно.

[@snnwolf]

Можно добавить нужные пути в include_path

[@crocodile2u]

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

$dir = dirname(__FILE__);

Абсолютные пути бывают лучше относительных. Не всегда можно быть уверенным, что та или иная базовая директория (ну, например, "." — текущая директория) указана в include_path. Кроме того, поиск относительного пути в include_path — это медленнее, нежели точно указать абсолютный путь. Впрочем, такая спичечная экономия часто не нужна.

[@SaintSerge]

На сервере практически все проекты на CMS Битрикс.
А он требует правильного ДОКРУТа…

Притом мне нравится такой подход… это даёт затруднения только при кривых конфигах и если проект лежит не в корне…

[@akira]

Упаси Бог меня работать с Битрикс :)

[@SaintSerge]

Отчего так?
Слышу много негативных отзывов… но считаю что это просто от ленности поковырять и разобраться.
Если Битрикс изучить то он становится лучшим другом.

Я разрабатываю преимущественно под него уже около 4х лет… ещё с 3ей версии…

[@akira]

Проприетарный тяжелый, неподъемный, да много чего есть у его.
Что можно сделать на нем, чего нельзя сделать на том же Друпале?
А если человек знаком с ZF\Cake\etc то передним вообще нет преград.

Как можно разработать web-service на основе Битрикс?

Вообщем, флейм это все.

[@SaintSerge]

Думаю не стоит действительно разводить флейм на эту тему :) Везде свои плюсы везде свои минусы )
Про Битрикс напишу пару статей когда получу инвайт. Возможно чтото проясниться.

[@Sserge]

Вообщем, Вы знаете, не совсем правильно говорить «то можно сделать на нем, чего нельзя сделать на том же Друпале?».
Т.е. это совсем не правильно. Это похоже на юношеский максимализм (надеюсь на адекватное восприятие).
Есть инструмент, компании с помощью него решают свои задачи. Все довольны.

[@akira]

Назовите мне 3 солидных компании.
ИМХО компании покупающие Битрикс, хотят сэкономить на разработчиках.

Чем отличается Битрикс от любой другой CMS?
Монструозностью разве что.

Битрикс — закрытая система, что мне уже не нравится.

[@Sserge]

> ИМХО компании покупающие Битрикс, хотят сэкономить на разработчиках.
И что в этом не правильного?

> Назовите мне 3 солидных компании.

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

[@akira]

Если можно сделать такой же продукт на другой CMS, то зачем платить за Битрикс?
На разработчиках нельзя экономить ;)

[@Sserge]

Ваша позиция однобока.

[@akira]

Конечно однобока! Это позиция разработчика :)
Вот скажите, почему rutube не на битриксе? Почему vkontakte.ru не на битриксе?
Потому, что неудобно и не гибко.

Хотя с них станется сделать дистрибутив: «1С-Битрикс: Видео-портал», «Запустите свой youtube за 4 часа!»

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

Каждый проект ИМХО должен быть написан именно под него.

[@Sserge]

> Конечно однобока!
О чем вообще можно с Вами разговаривать?
Тем более я об одном, вы о другом.
Прощайте.

p.s.
Кстати, для справки, в интернете много больше сайтов.

[@SaintSerge]

Вы правы. Битрикс это система для решения только 95% задач…
Притом задач корпоративных заказчиков.

Я с Вами абсолютно согласен, что не стоит разрабатывать на Битрикс эксклюзивные проекты. Эксклюзивные проекты лучше разрабатывать с нуля используя какиелибо фрэймворки.

У Битрикса свои задачи :) Это корпоративные сайты, интернет магазины, порталы… не более…

[@IlVin]

За Битрикс платят потому, что это хорошо отлаженный бизнес.
И в ситуации, когда не понравилась одна фирма, поддерживающая сайт компании, сайт безболезненно переходит на поддержку к другой фирме, потому что другая фирма знает эту платформу и не начнет вытворять чудеса переноса сайта на никому не известную платформу.
А в остальном битрикс ничуть не лучше всех остальных говно CMS.
Все равно под большие нагрузки пишут специализированный софт, работающий на кластере серверов…
Хотя, если все закешировать на фронтэндах, то и битрикс можно использовать в качестве генератора…

PS: На битриксе ничего не делаю по причине аллергии к PHP.

[@SaintSerge]

Закрытая??? Т.е.? Исходники у меня все есть… они выдаются при покупке лицензии…

Компании покупающие Битрикс? Махаон, QSoft это те с которыми я лично сотрудничал.
А вообще студий более 2500(две с половиной тысячи): www.1c-bitrix.ru/partners/index.php

Это разработчики! Т.е. каждый из них разработал КАК МИНИМУМ 1 проект.

Кстати разработка на битрикс — ДОРОГАЯ! :) Тем и живём.

Чтобы понять плюсы Битрикса нужно его понять…

Вот чем отличается C# от любого другого языка программирования? )

Битрикс лично мне предоставляет удобный framework и сильную гибкость… а клиенту — удобную админку.

Но вообще — всё это офтопик. Пост про многосайтовый сервер :) В частности и для Битрикс как для неповоротливой ресурсоёмнкой и капризной CMS.

[@pratavetra]

«редкостное зло»?
а я вот конфиги и прочее которые у меня над htdocs на уровень выше висят вот так подключаю, к примеру так: (ну, не совсем так, я утрирую)
$foo = include(dirname($_SERVER['DOCUMENT_ROOT']). "/req/config.inc.php");
И что мне, в случае смены сервера вручную переделывать проекты?

[@nekt]

В config.php ежели он лежит в корне сайта, вполне можно прописать
$_SERVER[«DOCUMENT_ROOT»] = dirname(__FILE__)

[@Dreid]

Меня всегда спасает такая вот конструкция:

$inc_path = 'путь'; // если не нравится $_SERVER[«DOCUMENT_ROOT»] его можно вырезать например из __FILE__
set_include_path(get_include_path().PATH_SEPARATOR.$inc_path);

После этого скрипт ищет файлы именно там, где нужно.

[@SaintSerge]

Тоже хорошо. Но тут есть минусы. Если система досточно большая то работать это будет медленнее чем при указании абсолютных путей относительно ДОКРУТа…
(Автор статьи)

[@crocodile2u]

/offtopic: звучит-то как! «абсолютные пути относительно ДОКРУТа»

[@SaintSerge]

:) Ну ДОКРУТ ведь может меняться… а получилось забавно да.

[@AlexeyK]

«Модель системы: linux -> nginx -> apache -> php -> mysql.»
Пытался представить логику, сломал голову :)

[@SaintSerge]

Запрос получает Линукс… ) отправляет в Nginx и т.д…

[@AlexeyK]

Да вы что, а nginx висит на 80 порту и не подозревает, что запросы приходят ему совсем с другого конца…
Продолжайте в том же духе :)

[@Sserge]

Ну строго говоря nginx висит там потому что эту возможность дает ему система. В данном случае linux.

[@SaintSerge]

Давайте тогда уж начнем Большой взрыв -> милиарды лет -> земля -> первые бактерии.

Я к тому что не надо утрировать, не идиоты собрались.

[@SaintSerge]

Да нет, нисколько не в тему.
Все хорошо в меру.

[@AlexeyK]

Эта милая шутка была высказана просто для того, чтобы вы вспомнили, что здесь не дураки-то сидят, все всё прекрасно знают и понимают, а изобретать лишний велосипед или придумывать новое название в данном случае не очень уместно :)

[@nertz]

В моем случае еще была проблема с субдоменом www.
www.example.com по хорошему должен вести в ту же папку что и example.com.
У себя решил так:

set $p $host;
if ($host ~ www\.(.*)) { set $p $1; }

location / {
proxy_pass 127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $p;
}

location ~* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xl
root /home/htdocs/$p/www;
gzip on;
sendfile on;
}

[@junqed]

Для Апача можно использовать mod_macro — это для удобства.
А про конструкции типа «if (!-d /home/htdocs/$host/www ) {» в рассылке nginx-ru сообщали, что это — признак плохого тона, но если без этого никак нельзя — то можно.

[@Mandor]

Мне кажется, что нужно поискать решение без
php_admin_value auto_prepend_file /home/htdocs/fix_doc_root.php

[@d1m]

Таки не у всех php как mod_php стоит ;)

[@SaintSerge]

Это да. Это чит.
Если найду более верный вариант — отпишу.
(Автор текста)

[@AstonMartin]

и еще, по-моему, логи апача и нгинкса удобнее класть отдельно каждому домену в попапку Logs

[@SaintSerge]

Ну да. тут пока рассмотрена ситуация без использования сторонних продуктов…
Также есть СиПанели и т.д…

[@ColorPrint]

ну CPanel денег стоит )
у нас вот на массовом хостинге (точне с выделенными серверами) такой же подход используется сейчас с mod_vhost_alias и скриптом для добавления новых доменов в named. Но все же иногда с mod_vhost_alias бывают проблемы.

[@ColorPrint]

еще mod_rewrite может глючить при использовании mod_vhost_alias (причина все в том же docroot только тут его никак не поправить) :(

[@Azy]

А зачем Вам apache? Может убрать его вообще и запустить PHP как FastCGI?

[@glukas]

Дело в том, что не всё пока может работать без Апача… Но я над этим работаю. Скоро думаю сделаю инструкцию как поставить связку Nginx FastCGI-PHP Bitrix

[@rapaman]

Толково, если доработать, то уже решение.

[@ajaxtelamonid]

Очень полезный топик, но конфиги безжалостно покоцаны хабрапарсером.