Как настроить массовые динамические виртуальные хосты в nginx? - PullRequest
Новая
       24

Как настроить массовые динамические виртуальные хосты в nginx?

18 голосов
/ 20 ноября 2011

Примерно час играл с nginx, пытаясь настроить массовые динамические виртуальные хосты.Если вы когда-либо делали это в Apache, вы понимаете, о чем я.

Цель состоит в том, чтобы иметь динамические поддомены для нескольких человек в офисе (более 50)

Ответы [ 7 ]

59 голосов
/ 22 января 2013

Возможно, это поможет вам достичь желаемого: 

server {

    root /sites/$http_host;

    server_name $http_host;

    ...

}

Мне это нравится, так как я могу буквально создавать сайты на лету, просто создайте новый каталог с именем домена и укажите DNS для IP-адреса сервера.

14 голосов
/ 03 декабря 2011

Вам понадобятся некоторые знания сценариев, чтобы собрать это воедино, я бы использовал php, но если вы хорошо разбираетесь в bash-сценариях, используйте это. Я бы сделал это так:

  1. Сначала создайте какую-нибудь папку ( / usr / local / etc / nginx / domain.com / ).

  2. В основной команде добавления nginx.conf: include /usr/local/etc/nginx/domain.com/*.conf;

  3. Каждый файл в этой папке должен иметь разные имена хостов subdomain.conf.

Вам не нужно перезапускать сервер nginx, чтобы конфигурация начала действовать, вам нужно только перезагрузить его: / usr / local / etc / rc.d / nginx reload

ИЛИ вы можете создать только один conf-файл, в котором должны быть установлены все vhosts. Это, вероятно, лучше, так что nginx не нужно загружать 50 файлов, а только один ....

Если у вас проблемы со сценариями, задайте вопрос об этом ...

6 голосов
/ 20 августа 2016

Основываясь на ответе пользователя user2001260, позже отредактированном partlov, вот мой результат.

Имейте в виду, что это для сервера разработки, расположенного на локальной виртуальной машине, где префикс .dev используется в конце каждого домена. Если вы хотите удалить его или использовать что-то еще, часть \.dev в директиве server_name может быть отредактирована или полностью удалена. 

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # Match any server name with the format [subdomain.[.subdomain...]].domain.tld.dev
    server_name ~^(?<subdomain>([\w-]+\.)*)?(?<domain>[\w-]+\.[\w-]+)\.dev$;

    # Map by default to (projects_root_path)/(domain.tld)/www;
    set $rootdir "/var/www/$domain/www";

    # Check if a (projects_root_path)/(subdomain.)(domain.tld)/www directory exists
    if (-f "/var/www/$subdomain.$domain/www"){
        # in which case, set that directory as the root
        set $rootdir "/var/www/$subdomain.$domain/www";
    } 

    root $rootdir;

    index index.php index.html index.htm index.nginx-debian.html;

    # Front-controller pattern as recommended by the nginx docs
    location / {
        try_files $uri $uri/ /index.php;
    }

    # Standard php-fpm based on the default config below this point
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }

}

Регулярное выражение в server_name захватывает переменные subdomain и domain. Часть subdomain является необязательной и может быть пустой. Я установил его так, что по умолчанию, если у вас есть поддомен, скажем, admin.mysite.com корень имеет тот же корень, что и mysite.com. Таким образом, один и тот же фронт-контроллер (в моем случае index.php) может маршрутизировать на основе субдомена. Но если вы хотите хранить совершенно другое приложение в поддомене, вы можете иметь каталог admin.mysite.com, и он будет использовать этот каталог для вызовов на admin.mysite.com.

Осторожно: Использование if не рекомендуется в текущей версии nginx, так как оно добавляет дополнительные накладные расходы на обработку для каждого запроса, но это должно подойти для использования в среде разработчиков, что и является эта конфигурация хороша для. В производственной среде я бы порекомендовал не использовать массовую конфигурацию виртуального хоста и настраивать каждый сайт отдельно, для большего контроля и большей безопасности.

1 голос
/ 06 октября 2017 
server_name ~^(?<vhost>[^.]*)\.domain\.com$;
set $rootdir "/var/www/whatever/$vhost";
root $rootdir;
0 голосов
/ 10 января 2018

Как подсказал @Samuurai, здесь есть короткая версия Angular 5 с интеграцией сборки nginx: 

server {
    server_name ~^(?<branch>.*)\.staging\.yourdomain\.com$;
    access_log /var/log/nginx/branch-access.log;
    error_log /var/log/nginx/branch-error.log;
    index index.html;
    try_files $uri$args $uri$args/ $uri $uri/ /index.html =404;
    root /usr/share/nginx/html/www/theft/$branch/dist;
}
0 голосов
/ 02 марта 2014

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

include sites-enabled/*.conf;
include sites-enabled/*/*.conf;
include sites-enabled/*/*/*.conf;
include sites-enabled/*/*/*/*.conf;
0 голосов
/ 02 декабря 2011

Пока вы знакомы со сценариями, не очень сложно собрать несколько сценариев, которые быстро настроят vhosts в nginx. Эта статья slicehost посвящена настройке пары vhosts и делает это так, чтобы ее можно было легко создавать с помощью сценариев и сохранять отдельные конфигурации.Единственный недостаток - перезапуск сервера, но этого следует ожидать с изменениями конфигурации.

Обновление: если вы не хотите поддерживать какой-либо конфигурационный файл самостоятельно, тогда у вас есть только 2 варианта(в любом случае безопасными) будет либо найти программу, которая позволит вашим пользователям управлять своими собственными порциями своей конфигурации nginx (которая позволит им создавать все поддомены, которые они хотят), либо создать такую ​​консоль управления, ориентированную на пользователя, самостоятельно.

Делать это самостоятельно не составит особого труда, особенно если у вас уже есть сценарии для настройки.Веб-интерфейс может вызывать сценарии для выполнения реальной работы, поэтому весь веб-интерфейс должен управлять тем, у кого есть доступ к каким вещам.

...