用于激活 nginx 配置/网站的小型服务器

Question

我有一个带有冷部署（未运行）网站的备份服务器。

这些网站也在多台生产服务器上，有时其中一些会出现故障。我为我的生产服务器配置了一个 DNS 回退，所以如果出现问题 - 请求将被传递到我的备份服务器，在那里它们由 nginx + uwsgi 处理。

当请求被传递到备份服务器时，nginx 使用默认的 nginx 配置（/etc/nginx/conf.d/default_site.conf）

（因为没有与 URL 匹配的网站正在运行，并且 /etc/nginx/sites-enabled 中没有符号链接

注意：我在 /etc/nginx/sites-available 和 /etc/uwsgi/apps-available 中的所有网站都有 nginx 和 uwsgi 配置）

我想编写一个 Python（或 Perl 或 bash 脚本）：

每当对默认 nginx 配置发出请求时：

1. 检查sites-available 中是否有匹配的nginx 配置以及apps-available 中是否有匹配的uwsgi 进程。如果是这样：
2. 在已启用应用程序中创建指向 uwsgi 记录的链接并启动服务
3. 在启用了站点的站点中创建指向 nginx 记录的链接并重新启动 nginx

这是我目前所拥有的：

我的 /etc/nginx/conf.d/default_site.conf：

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name backup.server.com;

    location / {
       include uwsgi_params;
       uwsgi_modifier1 5;

        #SOCKET for the app
        uwsgi_pass unix:///var/run/uwsgi/app/backupprocessor/socket;

        add_header Vary Accept-Encoding;
        add_header Cache-Control private;
    }

}

我有一个启用网站的 bash 脚本（我的问题中的第 2 + 3 点）

#!/bin/sh

if [ $# -ne 1 ]; then
    echo "Wrong ammount of arguments supplied"
    echo "Usage: ./enable_website.sh website_name"
    exit 33
fi

WEBSITE_NAME="$1"
echo "Linking apps-available/${WEBSITE_NAME}.ini to apps-enabled/${WEBSITE_NAME}.ini"
sudo ln -s /etc/uwsgi/apps-available/${WEBSITE_NAME}.ini /etc/uwsgi/apps-enabled/${WEBSITE_NAME}.ini

echo "Linking sites-available/${WEBSITE_NAME} to sites-enabled/${WEBSITE_NAME}"
sudo ln -s /etc/nginx/sites-available/${WEBSITE_NAME} /etc/nginx/sites-enabled/${WEBSITE_NAME}


echo "Starting website ..."
sudo service uwsgi restart ${WEBSITE_NAME}
echo "Started !"

我还配置了一个带有 Python Hello Word 应用程序的 uWSGI，我想将其用于第 1 点，但我的方法可能是错误的。 （nginx 甚至无法在端口 80 上启动它......这就是请求的来源）

测试：

uwsgi --http-socket 127.0.0.1:80 --wsgi-file app.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191

得到：

probably another instance of uWSGI is running on the same address (127.0.0.1:80).
bind(): Address already in use [core/socket.c line 769]

任何关于我的选择的帮助/建议将不胜感激！圣诞快乐！！

Answer 1

我认为您为实现目标采取了错误的步骤。在请求特定站点收入时激活适当的 uWSGI 应用程序和 nginx 站点的解决方案，在*-enabled 目录中创建符号是可能的，但有更好的解决方案。

我提出解决方案：

1. "one to rule them all" nginx 配置，它将简单地将您的请求传递给适当的 uWSGI 应用程序。
2. uWSGI 皇帝/附庸系统，按需生成附庸。

在该配置中，您的所有项目都必须以相同的方式处理静态和媒体文件（或者足够类似，因此我们可以对所有项目使用相同的 nginx 配置）。或者你可以配置uWSGI来处理它们。

1。 nginx配置：

server {
    server_name   ~^(www\.)?(?<domain>.+)$;
    # server_name can contain any regular expression. Just remember that it should start with `~` and contain `^` and `$`
    # as you can see, we can use named capture group as an variable later
    # you can add any named capture group for later use

    root   /sites/$domain/public;

    location @default {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        include /etc/nginx/uwsgi_params;

        uwsgi_pass unix:/run/uwsgi/${domain}.sock;
        break;
    }

    location /static/ {
        try_files $uri @default;
    }

    location /media/ {
        try_files $uri @default;
    }

    location ~* ^/(android-(?:chrome|icon)[-0-9x]*\.png|ms(?:tile|-icon)[-0-9x]*\.png|browserconfig.xml|apple-(?:touch-)?icon[-0-9x]*\.png|favicon[-0-9x]*.png|favicon\.ico|manifest.json|apple-touch-icon-precomposed\.png)$ {
        try_files $uri /static/favicon$uri @default;
    }   

    error_page 500 502 503 504 /500.html;
    location = /500.html {
        try_files /500.html /error.html /error500.html;
    }

    location / {
        try_files /maintenance.html @default;
    }
}

此配置将简单地将来自任何域的请求传递到位于/run/uwsgi/domain_name_without_www.sock 的套接字。如果它不存在，nginx 会抛出一些标准错误。它还将尝试直接从/sites/domain_name_without_www/public/ 目录提供静态和媒体文件。如果失败，它们将通过 uWSGI 提供服务。

2。 uWSGI皇帝配置

uWSGI 有它自己的多应用部署系统，称为Emperor。它还可以在访问特定套接字时启动 vassals（uWSGI 实例）。皇帝的示例配置可能如下所示：

uwsgi --emperor /etc/uwsgi/apps-enabled --emperor-on-demand-directory /run/uwsgi --emperor-on-demand-extension .sock

这将从/etc/uwsgi/apps-enabled 加载配置，为/run/uwsgi 上的每个配置创建套接字，并仅在nginx（或其他）尝试访问该应用程序的套接字时为特定应用程序启动uWSGI 服务器。因此，它的行为几乎与您在启用应用程序中创建的符号链接的概念完全相同。

在接下来的步骤中，您可以将每个 vassal 配置为在一段时间内没有请求时自行关闭。您还可以在 vassal 中创建一些预启动和预停止钩子，以便它们可以在应用程序的 vassal 启动时为 nginx 创建符号链接，并在 vassal 关闭时删除它们（每次都重新加载 nginx），以便您的 nginx 将请求路由到那个应用程序更快（使用虚拟主机路由会更有效）。