如何在nginx中设置海量动态虚拟主机?

发布于 2024-12-16 21:41:37 字数 107 浏览 0 评论 0原文

使用 nginx 玩了大约一个小时,试图设置大量动态虚拟主机。 如果你曾经在 apache 中做过这件事,你就会明白我的意思。

目标是为办公室中的少数人(超过 50 人)提供动态子域

Been playing with nginx for about an hour trying to setup mass dynamic virtual hosts.
If you ever done it in apache you know what I mean.

Goal is to have dynamic subdomains for few people in the office (more than 50)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

遥远的她 2024-12-23 21:41:37

也许这样做会让你到达你想要的地方:

server {

    root /sites/$http_host;

    server_name $http_host;

    ...

}

我喜欢这个,因为我可以实时创建站点,只需创建以域命名的新目录并将 DNS 指向服务器 IP。

Perhaps doing this will get you where you want to be:

server {

    root /sites/$http_host;

    server_name $http_host;

    ...

}

I like this as I can literally create sites on the fly, just create new directory named after the domain and point the DNS to the server ip.

无需解释 2024-12-23 21:41:37

您需要一些脚本知识才能将它们组合在一起。我会使用 PHP,但如果您擅长 bash 脚本编写,请使用 PHP。我会这样做:

  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 文件,其中应设置所有虚拟主机。这可能会更好,这样 nginx 不需要加载 50 个文件,而只需要加载一个......

如果您在脚本编写方面遇到问题,请提出有关该问题的问题......

You will need some scripting knowledge to put this together. I would use PHP, but if you are good in bash scripting use that. I would do it like this:

  1. First create some folder (/usr/local/etc/nginx/domain.com/).

  2. In main nginx.conf add command : include /usr/local/etc/nginx/domain.com/*.conf;

  3. Every file in this folder should be different vhost names subdomain.conf.

You do not need to restart nginx server for config to take action, you only need to reload it : /usr/local/etc/rc.d/nginx reload

OR you can make only one conf file, where all vhosts should be set. This is probably better so that nginx doesn't need to load up 50 files, but only one....

IF you have problems with scripting, then ask question about that...

ぇ气 2024-12-23 21:41:37

基于 user2001260 的答案,后来由partlov编辑,这是我的结果。

请记住,这是针对位于本地虚拟机上的开发服务器,其中每个域的末尾都使用 .dev 前缀。如果您想删除它或使用其他内容,可以编辑或完全删除 server_name 指令中的 \.dev 部分。

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 中的正则

表达式捕获变量 subdomaindomainsubdomain 部分是可选的,可以为空。我已将其设置为默认情况下,如果您有子域(例如 admin.mysite.com),则根目录将设置为与 mysite.com 相同的根目录。这样,相同的前端控制器(在我的例子中 index.php)可以基于子域进行路由。但是,如果您想在子域中保留完全不同的应用程序,则可以拥有一个 admin.mysite.com 目录,它将使用该目录来调用 admin.mysite.com代码>.

小心:在当前的 nginx 版本中不鼓励使用 if,因为它会为每个请求增加额外的处理开销,但在开发环境中使用应该没问题,这就是这个配置的好处。在生产环境中,我建议不要使用大量虚拟主机配置并单独配置每个站点,以获得更多控制和更好的安全性。

Based on user2001260's answer, later edited by partlov, here's my outcome.

Bear in mind this is for a dev server located on a local virtual machine, where the .dev prefix is used at the end of each domain. If you want to remove it, or use something else, the \.dev part in the server_name directive could be edited or altogether removed.

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;
    }

}

The regex in server_name captures the variables subdomain and domain. The subdomain part is optional and can be empty. I have set it so that by default, if you have a subdomain, say admin.mysite.com the root is set to the same root as mysite.com. This way, the same front-controller (in my case index.php) can route based on the subdomain. But if you want to keep an altogether different application in a subdomain, you can have a admin.mysite.com dir and it will use that directory for calls to admin.mysite.com.

Careful: The use of if is discouraged in the current nginx version, since it adds extra processing overhead for each request, but it should be fine for use in a dev environment, which is what this configuration is good for. In a production environment, I would recommend not using a mass virtual host configuration and configuring each site separately, for more control and better security.

一影成城 2024-12-23 21:41:37
server_name ~^(?<vhost>[^.]*)\.domain\.com$;
set $rootdir "/var/www/whatever/$vhost";
root $rootdir;
server_name ~^(?<vhost>[^.]*)\.domain\.com$;
set $rootdir "/var/www/whatever/$vhost";
root $rootdir;
つ低調成傷 2024-12-23 21:41:37

正如 @Samuurai 在这里建议的那样,这是一个带有 nginx 构建集成的简短版本 Angular 5:

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;
}

As @Samuurai suggested here is a short version Angular 5 with nginx build integration:

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;
}
无声情话 2024-12-23 21:41:37

另一种选择是包含几个深度级别,以便可以根据您认为合适的方式对目录进行分类。例如:

include sites-enabled/*.conf;
include sites-enabled/*/*.conf;
include sites-enabled/*/*/*.conf;
include sites-enabled/*/*/*/*.conf;

Another alternative is to have includes a few levels deep so that directories can be categorized as you see fit. For example:

include sites-enabled/*.conf;
include sites-enabled/*/*.conf;
include sites-enabled/*/*/*.conf;
include sites-enabled/*/*/*/*.conf;
困倦 2024-12-23 21:41:37

只要您熟悉脚本编写,编写一些在 nginx 中快速设置虚拟主机的脚本并不难。 这篇 slicehost 文章介绍了设置几个虚拟主机,并以易于编写脚本的方式进行,并使配置保持独立。唯一的缺点是必须重新启动服务器,但这在配置更改中是可以预料的。


更新:如果你不想自己维护任何配置,那么你唯一的两个选择(无论如何都是安全的)就是找到一个程序,让你的用户管理他们自己的 nginx 配置块(其中让他们创建他们想要的所有子域),或者自己创建这样一个面向用户的管理控制台。

自己做这件事并不会太难,特别是如果您已经有了脚本来完成设置工作。基于 Web 的界面可以调用脚本来完成实际工作,因此 Web 界面必须处理的就是管理谁有权访问哪些内容。

As long as you are comfortable with scripting, it is not very hard to put together some scripts that will quickly set up vhosts in nginx. This slicehost article goes through setting up a couple of vhosts and does it in a way that is easily scriptable and keeps the configurations separate. The only downside is having to restart the server, but that's to be expected with config changes.


Update: If you don't want to do any of the config maintaining yourself, then your only 2 options (the safe ones anyways) would be to either find a program that will let your users manage their own chunk of their nginx config (which will let them create all the subdomains they want), or to create such a user-facing management console yourself.

Doing this yourself would not be too hard, especially if you already have the scripts to do the work of setting things up. The web-based interface can call out to the scripts to do the actual work so that all the web interface has to deal with is managing who has access to what things.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文