Один конфиг Nginx для работы с кучей разных сайтов

[VBart]

Для разработки наверное кому-нибудь пригодится, но в продакшене такое лучше не использовать.

[unwrecker]

Почему нет, если продакшн состоит из 10000 сайтов с 10 хитами в день на каждом?

[VBart]

У кого десятки тысяч сайтов — скорее всего знают, как настраивать nginx. Я предостерегаю новичков от использования таких конфигов.

[unwrecker]

А можно всё-таки услышать хоть один агрумент против такого конфига?
Пусть это будет не 10000 сайтов, а просто 10. Допустим, что способы вызова скриптов везде одинаковые. Чем такой конфиг будет хуже десяти отдельных?

[VBart]

1. Он не читабелен. Подобные вопросы так часто всплывают в рассылке, что привело к появлению в FAQ данного пункта: nginx.org/en/docs/faq/variables_in_config.html Не надо программировать на конфигах nginx.

2. Он будет работать медленнее, потреблять больше ресурсов, чем 10 отдельных. Лучше написать скрипт, который вам сгенерирует N конфигов перед стартом nginx, чем использовать такие конструкции.

Из этого есть одно исключение: ооочень, очень много сайтов. Для 10к сайтов потребление памяти будет заметно выше со статическими конфигами.

[webknjaz]

И еще не забываем об If Is Evil.

[gouranga]

И еще не забываем, что php-fpm будет работать от одного пользователя: группы в одном пуле.

[unwrecker]

Ну так оно на самом деле и существует. На всякие приличные сайты свой конфиг (без злостных ifов :)) и свой пул (ибо нефиг). На многотысячную свалку — этот конфиг и сэйфмод в PHP.

[student_ivan]

server {
    server_name ~^(www\.)?(?<domain>.+)$;

    location / {
        root /sites/$domain;
    }
}

[student_ivan]

Добавить в это include и вполне себе рабочее продакшн решение

[samally]

server_name ~^(?:www\.)?(?<domain>.+)$;

Не зачем лишнюю группу создавать.

[unwrecker]

Нет предела совершенству ^) Спасибо

[TiGR]

В логах при таком конфиге server_name страшно выглядит. А именно — "^(www\.)?(?.+)$". Не информативно абсолютно.

[Suvo]

Ура! Вы, получили первый уровень в nginx, теперь получите еще 30 и вперед делиться конфигами

[Nc_Soft]

location ~ /\.ht
а какже .git, .svn, .ftpaccess? Добро пожаловать милости просим?
Все файлы с точкой в начале нужно считать скрытыми

location ~ /\. {
deny all;
access_log off;
log_not_found off;
}

Реврайт на www у вас 302, а обычно надо 301 чтобы происходила склейка (и обратите внимае тут в регулярке используется 1 карман, вы же почему-то www в скобки тоже взяли)

if ($host ~* www\.(.*)) {
set $host_without_www $1;
rewrite ^(.*)$ http://$host_without_www$1 permanent;
}

Вместо if (-e $request_filename) рекомендуется try files.
И вообще, в конфиге много магии, вкупе с 1 пуллом и юзером это делает его малопригодным для продакшена.

[unwrecker]

Ну, пожалуй, от магии автоматического разбиения на пулы я бы не отказался :)

Реврайт 301 нужен именно что для склейки, а в моём варианте её нет.

[symbix]

>> rewrite ^(.*)$ http://$host_without_www$1 permanent;

Не нужен тут реврайт (он вообще практически никогда не нужен).

return 301 http://$host_without_www$1

Ну и уже выше показали, как имя хоста без www получить регуляркой в server_name, безо всяких if-ов.

[slang]

А так?

set $logName $sathost"_access.log";
access_log /var/log/nginx/all/$logName;

А вообще, Вам бы ещё не мешало разобраться с try_files, вместо этого огорода, ну и да, полистать чужие конфиги. Новичкам бы я этот не советовал.

[Krio]

Сработает, и так тоже (не надо доп. переменную создавать).

access_log "/var/www/$sathost/logs/access.log";

а вот с «error_log» такое уже не пройдет.

[Zelgadis]

    server_name _;  # хитрый ключик, обозначающий, что этот конфиг применим для любого сайта

Нет. Это имя выбирают, чтобы с другими server не пересекалось.

    listen 80 default; # этот конфиг - умолчательный для 80 порта

Вот этот ключ говорит nginx, что если подходящий server не найдет, использовать этот.

[Paskal]

Вместо default нужно использовать default_server.

До версии 0.8.21 этот параметр назывался просто default.

[Zelgadis]

Это уже детали. Просто много людей думают, то "_" в качестве имени сделают этот сервер по-умолчанию, а потом пишут много вопросов на всяких askdev и.т.д.

[alekciy]

        fastcgi_param  SCRIPT_FILENAME  /var/www/all/$sathost/$fastcgi_script_name;
        include fastcgi_params;

Потенциально бажный кусок. include после всех директив приведет к переопределению ранее инициированных значений.

Правильно делать в include на файл в который вынесены общие правила и дальше ниже по конфигу для конкретного location задать требуемые значения.

Вот кусок из моих конфигов:

server {
	...
    location / {
        index       index.php;
        try_files   $uri $uri/ @backend;
    }

    location ~ \.php$ {
        try_files       $uri @backend;
        fastcgi_pass    unix:/var/www/tmp/$server_name.fastcgi.socket;
        fastcgi_index   index.php;

        include         /etc/nginx/fastcgi_params;

        fastcgi_param   SCRIPT_FILENAME     /www/$server_name/public$fastcgi_script_name;
        fastcgi_param   QUERY_STRING        q=$uri&$args;
        fastcgi_param   REQUEST_URI         q=$uri&$args;
        fastcgi_param   DOCUMENT_ROOT       /www/$server_name/public;
    }

    location @backend {
        fastcgi_pass    unix:/var/www/tmp/$server_name.fastcgi.socket;
        fastcgi_index   index.php;

        include         /etc/nginx/fastcgi_params;

        fastcgi_param   SCRIPT_FILENAME     /www/$server_name/public/index.php;
        fastcgi_param   SCRIPT_NAME         index.php;
        fastcgi_param   QUERY_STRING        q=$uri&$args;
        fastcgi_param   REQUEST_URI         q=$uri&$args;
        fastcgi_param   DOCUMENT_ROOT       /www/$server_name/public;
    }
}

[VBart]

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

[alekciy]

Что отправит как есть на бэкэнд это-то понятно. Но в данном контексте мы говорим о связке с PHP который переопределит данные. В результате конфига как у автора возможна ситуация, когда после добавления данных в общий конфиг который include-тся сломается один из location-ов. Что для не очень опытного админа чревато долгим чесанием головы.

[Aesma]

Если вам приходилось настраивать Nginx под нужды… сеошников…
…
3. Делает стандартный редирект на index.php в корне сайта при запросе несуществующего пути.

Что-то бред какой-то. Такой редирект явно не на пользу сео.
Если путь не существует — надо на 404 страницу слать людей.

[Aesma]

Хотя блин, вопрос конечно спорный. С точки зрения пользы для юзера — полезнее показать ему главную. С точки зрения поисковой системы — лучше не смешивать и на ошибки отдавать специальную страницу с 404 ответом сервера.

[alekciy]

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