如何使用Nginx反向代理使用SSL配置Buildbot

介绍

Buildbot是一个基于Python的持续集成系统，用于自动化软件构建，测试和发布流程。 在之前的教程中，我们安装了Buildbot并创建了systemd Unit文件 ，以允许服务器的init系统来管理进程。 Buildbot自带的内置Web服务器监听端口8010，为了使用SSL保护Web界面，我们需要配置一个反向代理。

在本教程中，我们将演示如何将Nginx配置为反向代理，以便将SSL保护的浏览器请求定向到Buildbot的Web界面。

先决条件

要遵循本教程，您将需要：

• 一个具有至少1 GB RAM的Ubuntu 16.04服务器，通过遵循Ubuntu 16.04初始服务器设置指南配置非根sudo用户和防火墙

另外，您需要在服务器上完成以下教程：

• 如何在Ubuntu 16.04上安装Buildbot
• 如何为Buildbot创建Systemd单元文件
• 如何在Ubuntu 16.04上安装Nginx
• 如何使用Ubuntu 16.04加密Nginx 。

完成这些要求后，即可开始。

第1步-配置Nginx

在前提教程中， 如何使用Ubuntu 16.04加密 Nginx，我们将Nginx配置为在/etc/nginx/sites-available/default文件中使用SSL。 在我们开始之前，我们将备份我们的工作配置文件：

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.ssl.bak

接下来，我们将打开default并添加我们的反向代理设置。

sudo nano /etc/nginx/sites-available/default

首先，我们将在SSL server块中添加特定的访问和错误日​​志。

. . . 
server {
        # SSL Configuration
        #
. . .
         # include snippets/snakeoil.conf;
         access_log            /var/log/nginx/buildbot.access.log;
         error_log            /var/log/nginx/buildbot.error.log;
. . .        

接下来，我们将配置代理设置。

由于我们向try_files发送所有请求，因此我们需要删除或注释掉默认的try_files行，这些行在请求到达Buildbot之前将返回404错误。

注意：与大多数应用程序不同， try_files启用了try_files设置的文档根目录返回200个响应。 如果资源被浏览器缓存，Buildbot可能看起来正在工作。 没有缓存的资产，它将返回一个空白页。

然后我们将添加反向代理配置。 第一行包括Nginx提供的proxy_params ，以确保主机名，客户端请求的协议和客户端IP地址等信息在我们的日志文件中可用。 proxy_pass设置代理服务器的协议和地址，在我们的例子中，是在8010端口上localhost上访问的Buildbot服务器。

. . .
        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                # try_files $uri $uri/ =404;

                # Reverse proxy settings
                include proxy_params;
                proxy_pass http://localhost:8010;
             }
. . . 

在本节之后，我们将配置两个附加位置， /sse和/ws ：

• 服务器发送事件（SSE）设置 服务器发送事件是比WebSockets更简单，更符合REST的协议，允许客户端订阅事件。 proxy_pass SSE端点需要自己的proxy_pass设置，并从关闭proxy_buffering 。

• WebSocket设置 WebSocket是用于在Web服务器和Web浏览器之间进行消息传递的协议。 像SSE协议一样，它需要自己的proxy_pass设置。 还需要额外的配置来传递标题信息。 您可以从Nginx WebSocket代理文档中了解更多这些设置。

. . .
        # Server sent event (sse) settings
        location /sse {
                proxy_buffering off;
                proxy_pass http://localhost:8010/sse/;
        }

        # Websocket settings
        location /ws {
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
              proxy_pass http://localhost:8010/ws;
              proxy_read_timeout 6000s;
        }
 . . .

完成这些更改后，请保存并退出该文件。

最后，我们将编辑ssl_params.conf ，并将ssl_session_timeout增加到项目推荐的1440分钟（24小时）设置，以适应更长的版本：

sudo nano /etc/nginx/snippets/ssl-params.conf

在文件的底部，添加以下行：

 . . . 
ssl_session_timeout 1440m;

完成后，保存并退出文件。

注意： Buildbot文档的示例Nginx文件包含一条将ssl_session_cache大小设置为1,440兆字节的线，允许超过500万个连接。 我们选择保留少于10 MB的内存密集型设置。 每兆字节可以存储大约4000个会话，所以这将存储大约40,000个会话，这对于大多数用例是足够的。

在配置Buildbot之前，我们不会重新启动Nginx，但是如果我们发生任何错误，我们将会测试我们的配置：

sudo nginx -t

如果一切顺利，命令将返回：

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

如果没有，请修复报告的错误，直到测试通过。

第2步 - 配置Buildbot

Buildbot在其Web界面中使用根相关链接，并且需要在master.cfg中定义基本URL以使链接正常工作。

sudo nano /home/buildbot/master/master.cfg

找到buildbotURL设置，将http更改为https ，并将localhost更改为您的域。 重要提示：协议必须是https ，并且必须包含尾部的斜杠。

 . . .
 c['buildbotURL'] = "https://your.ssl.domain.name/"
 . . .

我们还将确保主机不接受通过绑定到本地环回接口在其他主机上运行的员工的直接连接。 注释或替换现有的协议行， c['protocols'] = {'pb': {'port': 9989}} ，具体如下：

. . .
c['protocols'] = {"pb": {"port": "tcp:9989:interface=127.0.0.1"}}
. . .

完成后，保存并退出文件。

现在我们使用HTTPS和域名，我们将安装service_identity模块 ，该模块提供了确定证书的工具是否符合预期目的。

sudo -H pip install service_identity

如果我们跳过此步骤，Buildbot仍然会重新启动，但是会发出UserWarning“您没有可用的service_identity模块的安装”，这将在systemd的status命令的输出中status 。

第3步 - 重新启动服务

现在我们准备重启Nginx了：

sudo systemctl restart nginx

由于systemctl不提供输出，我们将使用其status命令来确保Nginx正在运行。

sudo systemctl status nginx

输出应突出显示“活动：活动（运行）”，并以如下结尾：

OutputMay 08 18:07:52 buildbot-server systemd[1]: 
Started A high performance web server and a reverse proxy server.

接下来，我们将使用上述教程中配置的systemctl重新启动buildmaster和worker：

sudo systemctl restart buildbot-master
sudo systemctl status buildbot-master

输出应突出显示“活动：活动（运行）”，并以如下结尾：

OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot master service.

接下来，我们将重新启动worker：

sudo systemctl restart buildbot-worker
sudo systemctl status buildbot-worker

同样，输出应该突出显示“活动：活动（运行），在这种情况下结束如下：

OutputMay 10 21:28:05 buildbot-server systemd[1]: Started BuildBot worker service.

现在我们重新启动了Nginx，buildmaster和worker，我们准备好验证反向代理是否按预期工作。 当我们通过http访问该网站时，我们应该重定向到https并成功访问我们的Buildbot网站。

在您的网络浏览器中，输入“http：// your.ssl.domain.name ”，将您的域your.ssl.domain.name为your.ssl.domain.name 。 按Enter键后，URL应以https开头，位置栏应该指示连接是安全的。

接下来，我们将花一点时间，看到Web Socket和Server Sent事件被正确地代理。

首先，访问/sse目录。 如果重定向正常工作，浏览器应该返回以下页面。 请注意，该页面将继续尝试加载，这是正常的行为：

接下来，访问/ ws目录。 如果代理重定向不正确，访问/ws目录将返回404 Not Found错误。 如果一切顺利，浏览器应该返回以下页面：

最后，由于内置Web服务器在所有接口上监听，因此我们将阻止端口8010，以防止通过IP地址访问服务器时出现未加密的连接：

sudo ufw deny 8010

OutputRule updated
Rule updated (v6)

我们现在已将Nginx配置为反向代理，并阻止用户使用HTTP Buildbot。

结论

在本教程中，我们将Nginx配置为Buildbot的内置Web服务器的反向代理，以确保通过Web界面传输的凭据和其他信息。 如果您是Buildbot的新手，您可能需要浏览Buildbot项目的“快速导览”指南。