Настройка nginx

[alhames]

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

1) Директива include - какие пути она понимает? Абсолютный путь понимает - это понятно, а как быть с относительными?
Если nginx.conf расположен в папке /etc/nginx, то эта папка и будет корневой для всех относительных путей и изменить ее никак нельзя?

2) Обязательные параметры для server - насколько я понимаю необходимо указать listen и server_name? Но столкнулся с тем что у меня сервер отказался запускаться без access_log и error_log. Не понимаю в чем их необходимость, если сразу после server_name у меня стоял rewrite.

3) Задание правил для location и вообще логика и последовательность обработки меня немного вводит в ступор. С апачем как-то проще было.
location = /img/ - соответствует только адресу «/img/»
location ~ /img/ - соответствует любому адресу, содержащему «/img/»
location ~* /img/ - соответствует любому адресу, содержащему «/img/», либо «/iMg/», либо «/ImG/» и т.п.
location /img/ - соответствует любому адресу, начинающемуся с «/img/»
location ~ ^/img/ - соответствует любому адресу, начинающемуся с «/img/»
location ^~ /img/ - соответствует любому адресу, начинающемуся с «/img/»
В чем отличия последних трех?
В чем особенности использования break?

4) Как лучше редиректить с субдоменов?

server {
	listen  80;
	server_name  www.example.ru *.example.ru;
	rewrite ^ example.ru$request_uri? permanent;
}

Такое кстати у меня не сработало из-за отсутствия заданых путей к логам. Что значит «^» после rewrite? Обычно ставили .*, что означало любой набор символов.
Либо так:

location / {
    if ($http_host != "example.com") {
        rewrite ^/(.*)$ example.com/$1 permanent;
	}
}

5) Как перенаправлять все запросы, не начинающиеся со /static/ и не соответствующие реальному файлу (типа robots.txt) на index.php?
Для апача это выглядит примерно как:

<IfModule mod_rewrite.c>
  RewriteEngine on

  RewriteRule ^/static/ - [L]
	
  RewriteCond %{REQUEST_FILENAME} !-f [OR]
  RewriteCond %{REQUEST_FILENAME} !-s
    RewriteRule .* index.php [L]
</IfModule>

А для nginx:

# сначала
location /static/ {
	break;
}

# потом
location / {
	error_page   404  =200  /index.php;
}
location = /index.php {
	include fastcgi.conf;
}

# либо
location / {
	try_files $uri /index.php;
}
location = /index.php {
	include fastcgi.conf;
}

# либо
location / {
	try_files $uri @php;
}
location @php {
	include fastcgi.conf;
}

Что лучше? или быть может как-то иначе?

6) Директива fastcgi_pass - в чем отличие указания стандартного localhost:9000 и unix:/tmp/fastcgi.socket? Насколько оправдано создавать upstream, если в принципе все обрабатывает только один сервер?

@темы: Вопрос

Comments

[https]

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

1) Как следует из примера в ссылке, include относительные пути понимает. Папка /etc/nginx будет в указанном случае являться не корневой, а рабочей и пути можно указывать относительно неё как вниз, так и вверх при помощи нужного количества "..\". Судя по описанию, сменить рабочий каталог процесса можно директивой working_directory

2) У меня сложилось впечатление, что самой необходимой директивой является listen; server_name служит лишь для различения запросов, пришедших на один и тот же порт с указанием разных адресов.
Что nginx не хочет запускаться без указания логов - это очень странно. Какую именно ошибку он выводит? Возможно используются стандартные/унаследованные пути, к которым нет доступа?
С другой стороны, логи - дело полезное, и причин не добавить данные директивы не вижу. rewrite мне кажется тут должен быть не при чём, как он может влиять?

3) Приведённые примеры выглядят вполне соответствующими документации:
location = /img/ — при помощи "=" задаётся точное соответствие url
location ~ /img/ — поиск по регулярному выражению с учётом регистра
location ~* /img/ — поиск по регулярному выражению без учёта регистра

location /img/ — поиск по префиксу
location ~ ^/img/ — поиск по регулярному выражению (с учётом регистра), в котором якорем "^" указано, что /img/ должно стоять в начале строки
location ^~ /img/ — поиск по префиксу, модификатор “^~” указывает что при совпадении с данным префиксным location'ом проверять регулярные выражения не нужно.
Особенности break мне неизвестны, судя по описанию, прекращает выполнение всех последующих директив; для конфигурировании поиска по location выглядит не особо применимым.

4) «^» — Обозначение начала строки. Насколько понимаю, будет искать "любую строку, у которой есть начало". Регулярное выражение, кстати не полностью идентично второму примеру "^/(.*)$" (начало строки, слэш, любое количество любых символов, конец строки) — первое не обязательно должно начинаться со "/". Не знаю насколько это принципиально, возможно именно отсутствие и слэша и в RE и location'a с ним же приводит к тому, что первый пример работает не так, как второй?

5) Судя по назначению директивы try_files, для задачи "для несуществующих файлов вернуть index.php" она подходит больше, чем error_page (концептуально ведь index.php ни разу не страница с сообщением об ошибке?) Вариант с именованным location выглядит симпатичнее, но, видимо, это уже дело вкуса.

6) Если всё установлено на одной nix-машине — очевидно, разницы никакой. Но у нас, например, nginx стоит перед виндовым сервером с IIS, тут бы юниксовая нотация уже не сработала. В upstream'е при отсутствии группы серверов и балансировки нагрузки тоже особого смысла нет.

[alhames]

https, спасибо, добрый человек!) Я уж прям в смятении - нигде в сети не могу найти ресурса, где бы мне детально пояснили что к чему. Последняя надежда - хабр
Я не пояснил в чем именно у меня сложности: дело в том что у меня есть nginx на vps (centos) и есть локальный сервер NIMPix (windows). Конфиги сайтов я вынес в отдельную папку, из которой создал репозиторий, чтобы как и скрипты сайтов nginx можно было бы перенастраивать через git. upstream, в частности, юзался просто как алиас для разных адресов, которые опеределены в nginx.conf вне репозитория.
Я так и не дошел до запуска конфигов на vps, т.к. 2 дня бодаюсь с локальным сервером - то ему относительные пути не нравились, то стал ругаться на отсутствие access_log (которая не определена в корневом конфиге, а попытка ее определить приводит к тому что nginx не запускается). И главная проблема - эта сволочь не показывает ошибки. Вообщем, сейчас займусь сборкой собственного локального сервера по кускам. Либо вообще виртуалку подниму...

сменить рабочий каталог процесса можно директивой working_directory

Да в том то и дело, что мне не сменить надо, а расширить, как в php include_path расширяется..

«^» — Обозначение начала строки.

А разве ^ и $ могут работать без дополнительных указаний? У любой не пустой строки есть начало, следовательно это идентично .+
И да, в nginx вроде нет RewriteBase, а значит все uri всегда начинаются с /

Судя по назначению директивы try_files, для задачи "для несуществующих файлов вернуть index.php" она подходит больше

Ну, концептуально то понятно - мне интересны именно различия обработки. Особенно как это отражается на больших нагрузках.

Спасибо за отзыв )

[https]

alhames, Если искать в сети информацию по it-тематике, то, определённо, лучше это делать на английском. В русскоязычных источниках сейчас остаётся всё меньше дельной информации. Вот даже в документации к nginx написано "Этот перевод может быть устаревшим. Смотрите английскую версию для ознакомления с последними изменениями."
Хабр хабром, но едва ли с конкретной задачей помогут даже там — просто потому что удалённо понять, что должно быть и что идёт не так — нереально. Посоветовала бы начать с минимальной конфигурацией nginx и стандартным расположением файлов, чтобы хотя бы для начала убедиться, что сам NIMPix настроен и работает корректно, а потом уже постепенно накручивать функциональность.

сменить рабочий каталог процесса можно директивой working_directory
Да в том то и дело, что мне не сменить надо, а расширить, как в php include_path расширяется..

Думаю, в nginx так нельзя. Всё-таки указываемый ему путь, абсолютный или относительный, всё равно должен быть единственным и однозначным; проводить поиск как в php с include_path он не будет.

А разве ^ и $ могут работать без дополнительных указаний? У любой не пустой строки есть начало, следовательно это идентично .+
И да, в nginx вроде нет RewriteBase, а значит все uri всегда начинаются с /

Судя по тому, что используется — может (Точно может, потому что у нас тоже есть работающие примеры с rewrite ^). Да, оно будет работать идентично и «.+» и «/(.*)» Но в чём смысл использовать более длинную нотацию, если можно использовать короткую? Во втором вашем примере стоит «/(.*)» просто потому что группа в скобках используется потом для составления нового url:

rewrite ^/(.*)$ example.com/$1 permanent;

(в первом случае для этого используется $request_uri)
Про RewriteBase не знаю, поэтому сказать ничего не могу.

Судя по назначению директивы try_files, для задачи "для несуществующих файлов вернуть index.php" она подходит больше
Ну, концептуально то понятно - мне интересны именно различия обработки. Особенно как это отражается на больших нагрузках.

В любом нормальном источнике, затрагивающем вопросы оптимизации, написано, что вначале следует получить рабочий вариант, удобный в сопровождении, и только потом, если выяснится, что он не удовлетворяет по параметру производительности, искать более быстрый.
Если назначение директивы error_page — задавать страницу с user-friendly сообщением об ошибке, то для других целей, имеющих свои средства, имхо, лучше использовать именно их.

[alhames]

https, блин, надо доучивать английский, как ни крути
NIMPix то работал, в дефолтной конфигурации - но меня то она не устраивает.. Так что будем мучиться)