Как использовать переменные из server_name nginx?

Question

[RokeAlvo]

суть задачи есть несколько сайтов isa.site.com, isb.site.com ... isz.site.com
есть локальный папки /home/user/sites/a, /home/user/sites/b и т.д...
в конфиге nginx

server {
  listen 443;
  server_name ~^is(?<subdomain_suffix>.+?)\.(site\.com.+)$;
  set $root /home/user/sites/$subdomain_suffix;
  root $root;
  ...
}

но все запросы типа isa.site.com ведут в локальную директорию /home/user/sites, как будто $subdomain_suffix==""

Что не так?

Comments

[Lynn «Кофеман»]

В данном коде синтаксические ошибки. Запостите настоящий код.
Если это и есть настоящий, то вы забыли перезапустить сервер.

[RokeAlvo]

Lynn «Кофеман», ну точки с запятой не запостил.
нет, не забыл и перед перезапуском nginx запускаю nginx -t

[RokeAlvo]

на самом деле решил автогенерацией конфига

server {
  listen 443;
  server_name isa.site.com;
  set $root /home/user/sites/a;
  include /..../front.nginx;
}
server {
  listen 443;
  server_name isb.site.com;
  set $root /home/user/sites/b;
  include /.../front.nginx;
}

....

но почему первоначальный конфиг не работает ума не приложу

[dodo512]

RokeAlvo, просто в шаблоне .+ означает один и более символов.
Для успешного совпадения (site\.com.+)$ тут после com нужен ещё как минимум один символ.
https://regex101.com/r/tjGHYc/1

^is(?<subdomain_suffix>.+?)\.site\.com$
https://regex101.com/r/tjGHYc/2

[RokeAlvo]

dodo512, точно, но так я то же пробовал,
в итоге должно быть что-то вроде ^is(?<subdomain_suffix>.+?)\.site\.com?.+$
что бы isa.site.com/ru?param=34 то же попадали
но $subdomain_suffix все равно пустое. М.б. дело в версии nginx, но мне не хватает прав посмотреть, что у нас стоит на сервере

Answer 1

[Виктор Таран]

не выдумывайте велосипед
1. у вас 3 сайта сделайте три конфига как и положено, не изобретайте велосипед тем более на пустом месте.
2. У вас 300 сайтов, тут вам поможет шаблонизатор или веб морда, собственно всего этого тоже навалом. и бесплатно и хорошего качества, зачем крутить костыли опять же непонятно.
3. У вас динамичекие имена доменов, но тут доложено управлять ядро проекта и тут строго индивидуально.

Comments

[RokeAlvo]

не 3, а 30 - по крайне мере сейчас
это не велосипед и не костыль, а вполне себе штатная возможность из доки https://nginx.org/ru/docs/http/server_names.html (секция Имена, заданные регулярными выражениями)

повторюсь, решил генерацией 30 конфигов, что, по моему мнению, как раз костыль

[Виктор Таран]

RokeAlvo,
Ок займусь просветительской деятельностью
В свое время nginx не плохо а практически никак не работал с переменными.
И даже разраб давал интерьвью именно почему их нет, он долго доказывал что это ваще идиотская идея на 20 сайтов делать конфиги с переменными постоянно получая баги при кастомизации и тд.
Философия nginx всегда проще скопировать кусок кода чем использовать сложлные конфиги
Но поскольку многие товарщи упорно пытались" оптимизироват" по их мнению конфиги то все-же использование переменных было расширено в nginx ( я входил в их число)

И так привожу пример зачем это нужно
1. явно обьявленные значения работают быстрей чем переменные.
2. Отдельные конфиги позволяют более удобно управлять сайтами, к приеру тебе нужно отключить один из сайтов, изменить настройки пхп для конкретного сайта, для этого тебе прийдется натыкать ифок вместо удаления линки или 1 строчки.

3. кастомизация под каждый сайт, и та такое бывает притом достаточно часто.
В результате вместо просто + 1 строчка в конфиге , ты получаешь очередной костыль с ифкой, который в свою очередь усложняет конфиг и снижают стабильность.

3. 30 конфигов- даже не смешно ты в винде риестр видил?
У меня по 600 конфигов на сервак, и это с объединение для ссл, так было бы 1200. и никаим костылем это не пахнет.
поскольку я прикручиваю или веб морду или генератор, посколкуь как ни странно в реальной работе важно время а не мое самолюбие что я такой красивый все могу править руками, да и человеческий фактор на потоке тоже имеет место, ибо управлять веб сайтами это не только вкл -выкл но и множество мелочей которые опять же будут через ифку.

4. Мало того я лет 7 назад исходил точно из твоего мнения, но практика показала несоостятельность моей идеи, мало того пришлось отказаться от своего рабочего конфига и использовать шаблонизатор ( от чего в свое время пытался откосить как и ты) - доволен как слон кучи проблем просто не стало существовать.
Мало того я избавился вообще от всех переменных кроме $host да и то только по тому что при nginx+apache мне проще исползовать ее.
Не забыайте что конфиг демон это не язык программирования! ( да тут есть лула и тд) но в общем уловите мысль тут другая философия работы.
И она не оторвана от реальности а имеет под собой реальную базу. Если вы ее на данный момент не понимаете не говорит о том что она не правильна.

И того у тебя:
у каждого сайта отдельный конфиг php.ini притом если представления пхп разные то x количество представлений и x количество версий пхп, к примеру при 600 сайтах это около
5000 конфигов php.ini - в моем случае, и да разница есть нельзя один конфиг на все версии пхп кинуть поскольку там тоже есть тонкости.
600 конфигов для nginx ( а учитывая что я переключаю представление для некоторых сайтов к примеру с nginx+apache+fpm на nginx+fpm то генератор создает в корне другой конфиг.
600 конфигов для apache ( тут опционально)
600 конфигов для fpm - и да они в 99.8% одинаковые
600 конфигов для fail2ban
и тд и тп.
суть в чем все демоны предпочитают такой способ работы, так куда как проще работать.
да и исправлять проблемы тоже.